Hacker News new | past | comments | ask | show | jobs | submit login

I use C and C++ extensively (30+ years writing C, 25 or so writing C++).

I much prefer C when writing systems-level code. It's simpler and a lot more predictable. You don't get the illusion that things like memory management are free.

I /have/ written drivers in C++. Here you have to be very careful about memory allocation (calling 'new' in an interrupt handler is usually death, though I've also written very specialized allocators that work in IRQ contexts). STL isn't going to cut it, especially if you're writing something real-time that needs very predictable performance.

So, my basic prejudice is that while you can use C++ for systems stuff, you still really need to be close to C semantics, so you're basically buying namespaces and "C with classes" at the risk that some yahoo later on is going to #include <map> and utterly hose things . . .




Honestly one of my favorite things about C are that the symbols resolve uniquely. Efficient C++ code often involves templates, and good luck trying to get a tag-lookup tool that can resolve template specialization rules...


My own experience is that RAII has been very useful in low-level work when used to capture cleanup/finalization. Results in fewer if-statements and SLOC.

Issues of real-time performance and new vs malloc vs in-place/nothrow new also seem like orthogonal concerns here. The larger problem is that yahoo who's using the wrong algorithm and/or maintaining driver code w/o benefit of code review ;)


My (admittedly short) experience writing kernel drivers with C++ was that RAII could be great help, but there's no way you can rely on any library you did not write yourself (and one that you wrote with the express intent to use for low-level work at that).

C++ code just tends to assume it's fine to do whatever crazy stuff it assumes needs to be done, like allocating 4 bytes at a time using new. C code is usually more careful about that, and quite a few packages offer control of their memory allocation in C. (Yes, C++ does allow you to overload new and delete, and have allocator traits, and more. Come back when you've actually implemented this for a library you did not write, and we'll discuss war stories if I can remember them. It was 2001, it was ugly back then, and I'd be surprised if it is better looking now).


For my low level stuff I use C with namespaces. Seriously. C with namespaces beats the hell out of both C and C++ for most stuff. You can still link to C and C++, and you don't need to worry about the myriad of quirks you have in C++ and its compilers, while you can have some decent organisation in your code.


As a c/c++ novice, can you elaborate on what you mean?


He probably means he uses a C++ compiler, but the only C++ feature used that isn't also in plain C is the namespace syntax.

This makes it easier to package up code into modules, since you can have namespace foo { bar } and namespace baz { bar }, without worrying that the two bar symbols will collide.


That's correct, and I use GCC for this. For some time I've also used m4 to pre-process namespaces and output C99-standard code. That would be my preferred way when I can get away with it because C++ compilers introduce uncanny little differences that can haunt you in some hedge cases, but it adds an extra step and then I'm doing something that doesn't work in the outside world.

For me, the biggest argument against C++ is that programmers can make much better use of their time than learning the massive list of quirks in C++ compilers. Having more features is not a deal breaker per se, even if it does cater to messy code. In real world situations you can usually choose a compiler for the whole team and a style for the whole team. This works in my company. But you have to be aware that this doesn't have to work in all situations, or even most situations.

With inline functions and dynamic variable declarations already in C99, I really think the complexity/usefulness compromise of adding anything else that is also available in C++ is very, very negative.

For other higher level features there are many other languages I'd take over C++. Ruby, LISP, Python, even Java or C# if you're that fond of C-ish syntax. For low-level stuff and speed, nothing higher level than what I said above. In my team C++ is nobody's favourite language but it's still what we use the most. Sadly, there are many other factors other than personal preference.


I'm interested in your comment about m4. I've never really used it except for sendmail configuration. The idea of using it to pre-process namespaces is interesting.

Would you mind expanding on how you set things up and what you do to use m4?


Sorry for not responding to this earlier, I just missed it.

In m4 I simply created some sort of preprocessor that renamed variables to have some sort of prefix depending on namespace. I haven't used this for a good while because then I have the issue that MSVC doesn't support other modern C99 things that I consider basic unless you compile in C++ mode, thus negating this. At work I need MSVC compatibility...

Hope you get to read this.

If I were to do this again today, I'd use OMeta. Give it a look, it's dead simple if you have the time to read through it.


#include <map> is hardly going to work at the first insertion that will call the allocator.

The argument "let's use a castrated language to avoid mistakes" falls short. What about communication within the team?

Properly used and tailored, the STL is extremely adequate to kernel development. The power of the template engine enables the compiler to do some very clever optimizations.

More information: http://www.osronline.com/article.cfm?article=490


Huh? That link claims "The STL will not work in kernel mode and cannot be used", which is not much of a surprise given the STL's use of exceptions and dynamic allocation.

In any case, kernel guys seem to prefer their data structures in intrusive style rather than the container style ubiquitous throughout the C++ standard library. (For an example, see the intrusive list and red-black tree implementations in the Linux kernel.) Intrusive structures allow for exactly the kind of low allocation, very memory friendly layout that kernel developers are looking for - no clever optimisations necessary.

C++ features like stronger type checking, more careful casts and RAII are a more compelling argument for the language.


Indeed, I've seen a talk from Bjarne recently where he said that by considering what is required to make RAII work in the presence of exceptions you can basically derive the entirety of C++..


Intrusive structures can be done in nice clean ways in C++. See policy based design.


Sure, I wasn't arguing against C++.


Everything that C is, C++ is as well. The single simple feature that I don't have to declare all my variables in the beginning of the method but where it's actually used is enough to kick the ass of C to the curb. Then there's the rest of the features including the little thing known as OO...

To object against C++ with the argument that incompetent coders can do bad things... well, it's nonsense. Incompetent coders can do bad things in ANY language. For competentt coders thugh, C++ means increased productivity and resusability, and in the end, that's what counts.


The single simple feature that I don't have to declare all my variables in the beginning of the method but where it's actually used is enough to kick the ass of C to the curb.

You're about twelve years outdated: https://en.wikipedia.org/wiki/C99


Also, you could declare variables at the start of any block in C, not just the start of a function, prior to C99.


Still didn't make it a good idea though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: