Why don't C++ and free software mix?

I mean, let's just assume, for the sake of argument, that all the participants here are informed people with some taste differences. some like C, others like C++, yet others like neither.

what is the reason to discuss it yet again? there won't be any converts, you can quote me on this.

for now, i'm going to limit my comments to c++ and the gnu project. first, let me see something...

$ lynx -dump -nolist http://www.gnu.org/software/ | grep [cC]++

      * adns is a resolver library for C and C++ programs.
     * Binutils includes these programs: `addr2line', `ar', `c++filt',
     * Cgicc is a C++ class library for writing CGI applications.
     * CommonC++ is a C++ framework offering portable support for
     * cpp2html s a simple program that, given a source C/C++ file,
     * GCC is a free compiler collection for C, C++, Fortran, Objective C
     * gdb is a source-level debugger for C, C++ and Fortran.
       small, self-contained C++ library of 3D Widgets that support
     * Goose is a C++ library for statistical calculations.
     * libxmi is a C/C++ function library for rasterizing 2-D vector
     * Mifluz provides a C++ library to build and query a full text
       C++. OBST supports incremental loading of methods.
     * The Plotutils package contains `libplot', a C/C++ library that can
     * ACS is an core class extensible C++ state engine and IVR
     * APE is a highly portable C++ framework for the development of
     * CLN is a C++ class library for numbers. It provides arbitrary
     * The Epeios project provides C++ libraries for multiple use.
     * Fltk is a LGPL'd C++ graphical user interface toolkit for X,
     * GiNaC is a framework of C++ classes to perform some symbolic
     * NURBS++ is a C++ library that hides the basic mathematics of

hmm, you're right -- not a lot of stuff.

three immediate thoughts come to mind: first, i have a vague recollection of an old version of the gnu coding standards recommending that programs be written in c rather than c++ because of c's greater mindshare at the time. second, it has taken g++ a long time to reach its current state of maturity. third, c++ did not become an iso standard until quite recently, especially compared to c, no? these would all be contributing factors, though obviously i'm not an official mouthpiece of the gnu project. also noteworthy, perhaps, is that neither richard stallman nor miguel de icaza programs in c++

Seriously. My current major project is a Jabber client for GNOME. Dave Smith, the developer of a general Jabber client library called jabberoo, which was written in C++ decided to start hacking on the code for the user interface I designed in glade. He decided on C++ because jabberoo was already in C++ and there are gtk and gnome bindings for C++, so it seemed logical. Unfortunately, now that the project is more mature, we're still having trouble getting Gabber working on many machines. The problem is the binary incompatibilities between g++ versions. Some people get binaries of libsigc++ and gtkmm from Helix GNOME compiled on gcc 2.95.2, but then gnomemm compiled on egcs 1.1.2. SEGFAULT. Any possible combination of one lib not being compiled on the proper compiler results in segfault. Just look at bugs.gnome.org, package gabber. We don't even use the GNOME bug system, so those are reports from people who just hit the 'submit bug report' button in GNOME after it segfaults. I'm pretty sure most of them are because of library incompatibilities. Until gcc 3.0 comes around, I can't imagine that many developers would put up with this. Supposedly this won't happen after 3.0, but we'll see.

Not only are there binary incompatibilities, but g++ is SLOW... Look at how loing it takes to compile Mozilla. Have you ever seen it compiled on a windows machine with a decent compiler? Much much faster. Until it's optimized, people will have a tough time rationalizing the incredible amounts of time it takes to compile for just a few nicer programming features. I know I do...

To sum it up, we need to get g++ fixed - and get the fixed version on most of the popular *nixes...

The article does a good job of explaining the laundry list of problems most folks have.

All the problems of "makes it easier for dumb programmers to write bad code," et al, are relatively minimal. Good programers can write good stuff with C++, like they even can with *shudder* Tcl. Folks will notice good programs, and then those programs will be used.

But "the standard has been finalized" means nothing. Nada. How long was it until C89 was supported everywhere? How long will it be until ANSI C++ is? That's the question.

g++ is not the answer. I know how good gcc is on some plaforms, and how bad it is on others. when g++ is ready on Linux/*BSD, that will only be the beginning. We cannot rely on g++ to suffice for other platforms, because not enough folks care to make g++ (or even gcc) work well there. I know that when I was using other Unices, I avoided C++ programs merely because of this problem.

So I, for one, will probably avoid C++ until ANSI C++ compilers are ubiquitous.

Another possible factor is the fact that with C, the interested, knowledgeable, and otherwise helpful group of folks that will help debug and patch your code is much larger.

I went through a similar process to what egnor describes, avoiding C++ for years, then suddenly waking up when the generic programming features became available that this was a (high level) language I'd actually want to use.

apgarcia already said this, but for me the issue was very much about maintaining the lowest possible barrier to entry. This must be changing with so many people learning C++ as part of their university degree, but in my generation C was the lowest common denominator. Largely because C++ is such a large language, using it for open development reduces the pool of people likely to contribute. In contrast, I always liked ObjectiveC because you could explain it to any C programmer in 20 minutes. Even Java is similarly intelligible.

It's also much easier to share code if you share languages. If you're writing in C++, you don't want to import crufty C code from some other project and end up doing more work reimplementing stuff. Likewise, I know I've personally avoided perfectly functional code because it was in C++ because I didn't want the hassle of wrapping/backporting it. I wonder if that has something to do with the popularity of GTK over QT or FLTK, or SDL over Clanlib (despite most games being in C++ these days).

Maybe there's a balkanization issue here as well. I'm much less threatened by high-level scripting languages, or experimental ones. But to the extent that C++ tries to "be a better C" it feels like a religious issue.

To add to the list, there are a couple of successful-ish open source projects using C++. Worldforge and CrystalSpace come to mind.

apgarcia: I can't tell if you're being sarcastic or not with your conclusion "you're right -- not a lot of stuff".

julian: I agree that binary portability is a problem, and I agree that gcc is somewhat slow to process C++ files (especially templates), but I'm not sure the statement that "it sucks" is fair. It's certainly not fair to talk about egcs 1.1.2, since that's quite old by now. Still, you may be answering my question; perhaps the big reasons nobody uses C++ are that it has been poorly supported until recently (if so, we should expect the situation to change) and that binary linking doesn't work (is there any hope that the "new ABI" will be stable?). Interesting.

jlbec: Does g++'s support for C++ features really vary from platform to platform? I'm surprised; I would have thought that for the most part, the C++ compiler implementation is at a "higher level" than most platform-specific details (with some exceptions, like, uh, exceptions, and thread-safety).

I also wonder how important portability is to free software developers. On the one hand, it's often cited here as a reason to avoid C++ and to support cross-platform solutions like GLib, but on the other hand many of the free software programs I use seem proudly POSIX- or perhaps even Linux-specific.

I'm not sure I buy the "inertia"/"developer mindshare" argument brought up by jlbec; that hasn't stopped anyone from adopting Perl, for example. But rillian makes the interesting claim that the barrier to entry is different for a "scripting language". Can you expand on that?

It's interesting that C++ seems to be adopted by game developers first (this happenned in the commercial world, and may be happenning here as well). I've been told that commercial game development leapt directly from assembler to C++. If free software game developers are adopting C++, then perhaps we can look there for the shape of things to come.

I can only agree with julian there: g++, even in 2.95.2, sucks. Badly. On the alpha, which I'm primarily working on, it generates incorrect code and broken virtual function tables. If I turn off code optimization. With optimization, it usually dies with an internal compiler error. Things may become better with the 2.95.3 interim release, but right now I'm stuck with Compaq's cxx. This compiler works, but doesn't like the Debian system header files, which use some g++ magic (e.g. to automagically map stuff into the std:: namespace). Also, it's proprietary and binary only.

Anyway, ignoring the compiler issue, there's another point why C++ isn't used that commonly among free software authors (and I'm not just talking about "compared to C" here): If absolute portability (and, therefore, C) or restricted portability (C++) and performance (either of them) aren't an issue for your project, those languages aren't neccessarily among the obvious choices. For example, for something related to text processing, you might use Perl. For a clean, functional OO program, Python would be an appropriate choice. If your program has to be robust and should handle unexpected choices, you might want to build a language of your own, or use reasoning languages like Mercury or Prolog. If you're working with mathematically inclined people, you might want to have a look at Haskell. Many of these offer features not present in either C or C++, thus decreasing the time spent in development.

(For example, a researcher I know wrote a theorem proving program in Prolog; it was exactly 333 bytes long and beat many of the worlds' professional theorem provers in benchmarks).

Of course, I'm not saying that C++ is obsolete, or shouldn't be used. I just wanted to point out that, in a free software world, your boss isn't forcing you to use C++ or Java because he read that it's a good language.

at work, most sub-senior level people are basically limited to what the boss chooses or what the organization uses. we might as well deal with it, pretty much.

for hobbies/crusades/learning, other considerations come, thankfully, into the picture. but then, you don't really care whether the language you choose is the most popular. all you care about is a vibrant community. and there are plenty of such languages. lessee: Python, ML, Haskell, Prolog, Scheme, Lisp, etc etc. don't worry your heads about which of these languages has the longest d^W^W^W^W is the most popular. just use the one you like.

Most successful C++ programmers I know had extensive background in C programming and a functional object-oriented programming language like CLOS/LOOPS/Flavors (LISP variants) or Smalltalk before picking up C++. Nowadays I think it would be programmers who are experienced in both C and Java or C and Python who would be ready to try C++.

On top of that, you need an XP-like mentality to be able to deal with the evolution of large object-oriented applications, which was something not found in any textbook until recently.

Err, how about http://xprograming.com

Curiously, no one has mentioned the granddaddy of free software c++ apps, Mozilla. The also nicely provided us with the c++ portability guide. And they seem to be a current succes (they can handle this diary entry). And no one has mentioned KDE.

But as I don't know anything about Mozilla, other than that it works, I'll talk about AbiWord, a Free software C++ application that works quite nicely. We use basically two kinds of C++ features:

• Better C features
• Classes and inheritance

For the second kind, C++ make our lives much much easier. AbiWord is designed from the ground up to be an XP GUI app, which isn't easy. The way we do this is to have base classes in the XP code, and then the actually implemented classes as derived classes in the platform-specific code. This allows everyone to share code cleanly and nicely, and people doing platform specific work to stay out of each other's hair.

As for C++ not being portable, all I can say is that we are about to ship a binary release for 7 operating systems on 4 different architechtures. Granted, we don't use advanced C++ features. But we probably could.

Of those people who hate C++ currently, how many of you have actually worked on a serious C++ project?

I think most "free software" projects don't start with a clean slate design. They are much more of a "stone soup" kind of thing, you almost always start with something that's close to what you want and hack on it until it does want you need. You do this a bunch of times and build up a set of internal mental programming tools. When you do get a chance ( or make a chance ) to work from scratch, you grab from your already built set of design tools.

So until there is a significant amount of C++ to hack on, there won't be lots of C++ hacking.

Personally, I've tried to give C++ a serious look a few times and decided not to bother until there is a rich stable set of underlying class libraries. OO is generally useless until there is a broad underlying STABLE[1] set of class objects. That and the lack of run-time binding ( has this been fixed?) made it seem not worth my time.

- Booker C. Bense

[1]- I define STABLE to mean that I can still compile the same code five years down the road.

One reason for the preference to C over C++ may be that libraries may be written in C more often than C++ because of a desire to cater to as wide an audience as possible. If I write a library in C++ it will only be really usable in other C++ programs, partly due to the C++ name mangling and partly to the use of OO features. If, however, I write my library in C, then it can be used in both C and C++ programs with equal utility without any extra effort. If I'm feeling really nice I might write a set of wrapper classes in C++, but it just makes more sense to put the real meat of the code in pure ISO C.

If more libraries are written in C than in C++, the result will be more programs written in C than in C++ because it is easier to write the programs in a language with more support in libraries. If more programs are written in C than in C++ then you will have a greater impetus to write future libraries in the more commonly used language. It looks like something of a catch-22.

Persoanally, I don't like C++ for the same reasons mentioned by egnor (baroque language design, assorted misfeatures, non-portable compiler features, etc.) and just find it much easier to concieve programs in simpler languages (e.g. C or Java). When I worte my library of standard utilities I used C rather than C++, even though the library has some object-like features, because I knew that I would need to use the library in both C and C++ programs.

Aside from the already mentioned problems of no good C++ compiler existing and it being relatively useless to write a library in C++ since that lowers the number of prospective users...

How about the hypothesis that a larger portion of the opensource hackers out there prefer languages where its relatively obvious what's going on underneath (ie: low level languages like C) or just don't bother with such an "arcane" concept as a machine-code-compiled languages that can do such evil things as segfault and not run on more than one platform so they pick modern languages (python, perl, etc..)?

just a thought.

I've never met any c++ programmer that I found impressive. I'm sure they do exist, but, they are pretty rare too. Most of the c++ code I've seen was trying to use the c++ features, which made it unreadable (for me non-c++-litterate programmer) and bloated. I would end up rewriting it in straight c and make it twice faster in the process. So much for the "it does not hurt the performance" - maybe when you're really really good at c++, but, most people arent.

I know I'm not good at c++. Most of the code that I write (codecs, compression/decompression stuff, engines for whatever) has to be efficient. When I write them I have to think about what the compiled code will look like, and c++ just makes it hard for me. Also whats the deal with templates - when I write the code I know what types it will have to play with, and I dont remember having to switch them afterwards. I may have to use a hash table or something at times, but, its not like I will take days to write one, and in the process I'll adapt the implementation to what I actually need. For example, if I'm hashing strings you can bet I will use a more complex hash function than if I'm hashing pgp key IDs that are already pretty uniformly distributed... I think the c++ genericity argument falls on his face here again, because, all hash tables do not have the same requirements.

So, I don't think c++ would be a huge advantage for the stuff that I do, and I think I would need to invest a massive amount of time to become maybe half-decent at it. It just does not seem to be worth it IMHO.

When I dont want to worry about the lowlevel implementation, I'd rather use python or another "proper" high-level language. But, c++ just looks like a bad hack to me.

C++ and free software have nothing in conflict. Unix and C++ don't really mix as well as Unix and C since Unix and C were developed and designed with one another.

And the GNU C++ compiler which is the most popular on free opertaing systems happens to suck...

I'm not sure what all the fuss is about. The Exult project is written in C++, has nearly 69K lines of code, and compiles/runs on Linux, Win32, Mac and BeOS. G++ is used for all platforms except for the Mac, and I haven't heard of any problems caused by the compiler.

In my opinion, C++ is a natural choice for a game, since a game is full of objects:-) And, in fact, it appears that the original Ultima7 (which Exult reverse-engineers) was itself written using Borland C++.

dutky: Again, it does seem reasonable to write libraries in C, when they will be used by coders working in multiple languages. However, there is no reason not to use C++ for your application, if your library is written in C. The C interface can be used identically in either C or C++. Granted, it is often nicer to have a C++ wrapper around the library, but this is by no means a requirement.

walken: You just haven't seen enough C++ code. I assure you there are pople with beautiful coding skills out there. The AbiWord piecetable implementation, for example, hasn't been changed in 20 months. And we haven't found a bug in it yet. The author of that code has retired to enjoy the fruits of his labors, and deservedly too.

As for you comments about templates, they are totally clueless. First, a template bears no relation whatsoever to a hash table. Sure, you could have a hash table implemented as a template, but there's no intrinsic connection. Furthermorethe idea of templates is to be able to use them with any time, even types that you didn't think of (or hadn't even been created). An vector library that uses arrays can be linked to a app using it, even if the datatypes put in the array were invented years after the lib was compiled. Let's see you do that with a hash table.

aaronl: I think we should cut GNU C++ a little bit of slack. Lots of people are happy to say "g++ sucks". It's true, there are some problems: C++ support on non-Intel platforms is broken, compilation is slow, and C++ lacks binary compatibility between compiler versions. Still, try using, say, MSVC++ for a while for real C++ work (as opposed to "C with classes"), and you'll come running back; at least g++ makes a pretty solid effort to implement the entire standard.

Still, I can definitely see why people would be unimpressed with C++ compiler support, especially compared to C (which has been stable for decades, and enjoys rock-solid compiler support on just about every platform ever).

In summary, the reason seems to be primarily a combination of network-effect inertia and poor compiler support. Thanks to everyone for your comments; this feedback is just what I was hoping for.

Ok, I was perhaps too harsh on g++, but there are definitely inconsistancies, even between linux and FreeBSD. Right now, in fact, Gabber CVS simply won't work on FreeBSD. It's crashing on text.c_str()... I'm trying to figure out why, but with little luck. Once we get that sorted out, then there are other crashes on FreeBSD we have to deal with - some sort of problems writing files. sigh.

samth: You are totally correct that I have not seen enough (good) c++ code. I'm sure c++ does make sense in some situations, but I also think it requires very skilled coders so that it does not get abused. I take your word that AbiWord might be one of these places where c++ makes sense and where the developpers are competent enough to use it. But, my point was that few people are, and that the investment to get there might be too important for a lot of people.

My talk about genericity was not directly related to c++, it would apply to generic libraries written in C too. I do not believe that a generic library can be as efficient as one written specifically for your data type and your application. That does not make the generic library useless, far from it, but, people who pretend this genericity comes for free are IMHO misguided.

I agree with several others that C++ isn't really the appropriate language in many cases. If you want low-level, fast, small, portable, language-bindable code, C is ideal. If you're just writing an app, especially a GUI app, then C++ is slightly higher-level than C but still a low-level language. You still get segfaults, no garbage collection, slow compile times, blah blah. And portability problems, extra bloat, and complexity overload to boot. Java, Python, Perl, VB, and C# are all better choices than C or C++ for most GUI apps at least. In the spectrum of programming languages I think of C/C++ as basically one language.

I find that C++ saves me some typing but requires lots of extra thinking about the language itself on top of thinking about the problem space. A high-level language saves me more typing than C++ and also saves me thinking about the language, so I can think about the code I'm writing. Thinking is the limiting factor in getting the software written.

C++'s current popularity (which isn't even that great; Java and VB are contenders for more popular languages) is probably mostly because it's C-compatible and practical for projects that still require the speed of C but want to be slightly higher-level. And "slightly" is how C++ is most often used; Mozilla, etc. use "C with classes," not the language described in Stroustrup's 900-page book. With Microsoft pushing C#/VB and Sun pushing Java, it's hard to see C++ growing much in the future, though no doubt C/C++ will persist for code that needs to be low-level and least-common-denominator.

I started working in C++ back in early cfront days (1.2, maybe earlier), and the commercial softare company that I worked for (color prepress software, SGI hardware) quickly adopted it for virtually everything: by all accounts it was very successful. So when I started to write ftwalk, C++ seemed to be the obvious implementation language. I do think it made the implementation easier, clearer, cleaner, and more correct.

However, it's been a pretty bumpy road from there. In the early days (I started ftwalk in 1994) C++ was pretty portable, but the platform header files were awful, and I ran into horrible compiler bugs pretty much everywhere I went. (Mostly destructors called or not called inappropriately, leading to memory corruption.) When templates were introduced, I found that the template code itself was nicely portable on three different platforms, but that the compiler command line options were completely incompatible. Then came Standardization, and ever since that started it seems like almost every new compiler release breaks something or other.

Maybe people are going from C to Java. I don't have any real stats to back this idea up, and I realise that many free software proponents are ideologically oppossed to Java. However, it has many of the benefits of C++, plus it really is cross platform (as well as that little flavour of the months thing...)

There are a number of large free Java projects around: jBoss for one.

Keep in mind that this comes from someone whose favorite languages are Python and Java, and is an unrepentant usability snob, so if it sounds like I find C++ just plain aesthetically displeasing, it's because I do.

I've had a small amount of C++ experience, and can mostly describe it by a list of problems -

- I can't for the life of me keep straight what the compiler is doing mixing pointers and references, it just doesn't make sense, and the syntax is totally funky and weird.

- It's a pain calling C++ from Python, although, to be fair, this is because Python was designed to call C.

- It takes *forever* to compile, and the resulting classes are *huge*.

- C++ operator overloading is a mess - I don't think this is due to anything inherent in operator overloading, since I've never had a problem doing it in Python. Not sure why it's so difficult in C++.

- Above all, it just plain isn't cross-platform - for Mojo Nation we have two separate downloads for Debian and Redhat, and the only reason is the C++ code.

Sure, C++ is 'getting there', but how long has that been going on? ten years? By the time it actually 'works' other languages will have long since obsoleted it - Java is killing it in 'enterprise' software, and Python is killing it in free software.

Notably, many of these problems were just plain avoidable - everyone seemed happy with just pointers, parametrized types can be done without making multiple binary copies (albeit with a slight performance hit) Overloading could have been restricted to the operators you started with a la Python, and all the other problems are related to nonstandard name-mangling. The name-mangling this is, frankly, just plain stupid. One of the wonderful things about C (and, not coincidentally, Python) is it's transparency. There was never, ever any good reason to mess that up.

Why C++ is such a mess I don't know - I wasn't around when it was created, and didn't see the battles between it and Objective C (or even use Objective C.) It's just one of those parables, like Mozilla, of how software projects can drag on forever.

I have some interesting ideas for a C-ish language which is based on references, has parametrized types, continuations, powerful garbage collection/reference counting/manual memory management options, and is very very fast. The problem is that I don't see a place for a language like this - Everything is moving towards being in a high-level language like Python with little bits in C.

I used to work at a closed-source shop, where I worked in C++ because that's what I was told to do -- I still think most of the problems there could have been avoided has we used Python. In my most recent free software (PMS, Python Mail System -- http://moshez.org), I'm using Python exclusively because *I* need it as soon as possible, and it seemed like the quickest way. In general, I can't imagine a project which C++ would be the right choice for -- if its performance needs are low (and an MUA's performance needs *are* low: a human is so slow...) then Python is usually best (IMHO). If you absolutely need performance, it's usually in some critical part, and you can usually simply write a Python C extension for that part. However, there are projects for which Python at all would be an overkill -- but those are usually small and simple, and C would outdo C++ here. I'm talking about things like kernel device drivers, programs that have to be in embedded devices, things like that.

egnor: Can you give an example of a project that you think C++ would have been the best choice for? (Keep in mind that for libraries that are intended for general use, C is the best choice -- that's why GNOME has so much more language bindings, for example)

I didn't mean that g++ is different on other platforms. It's just as good/bad from a completeness perspective. G++ on IRIX will implement as much of the standard as g++ on Linux.

But g++ (and gcc) often produce horrible code on those platforms. I rarely use gcc/g++ on machines outside the Linux and *BSD pantheon. The native C compilers just work. But with C++, you don't have anything close to standards agreement. So the choice is to use "C with classes" and hand-coax a native build, or use g++ and accept the crashes. And I've never done a C++ build of anything without hand-coaxing. It just isn't a win for me.

You also spoke of projects being POSIX-centric, or even "proudly Linux only." POSIX-centric covers most platforms. I've never had a problem with a POSIX C program. They all build clean. But Linux-only programs I generally ignore. I can't use them on other platforms. So while on other platforms I get used to alternatives. And then I just use the alternatives on Linux as well.

These days, I'm pretty much on Linux only, so that isn't a big issue, but I still think that being "Linux-only" is just as limiting as being "Windows-only." Bad Idea Jeans.

In the end, the C++ I can use in my daily life -- the stuff that is basically in the Moz guidelines -- is not enough of a win, and the other disadvantages are a large lose. That's my personal opinion, and why I don't use C++.

I agree with a lot of what egnor has said here. A lot of the problems with using C++ have to do with the relatively poor quality of implementation available to us. Now that g++ shows some hope of morphing into a high quality C++ implementation, it's starting to look like a somewhat pleasant language.

But I want to take a moment here to step back one level and ask why it's been so hard to get a good implementation. I think the complexity of the language is a direct culprit here. I think the complexity is also responsible for other issues, such as the long time it's taken to get a standard, the difficulty in agreeing on an ABI, and even the relative paucity of truly skilled C++ programmers. On this last topic, Stroustrup has said, "Poor educations is part of the problem and better education must be part of the solution" (in his /. interview). It seems to me quite plausible that the complexity of the language adds to the time and cost of a full education in C++.

Another factor noted by many is the abundance of good alternatives. Depending on the exact requirements, I could easily imagine using Python or Java, especially when down-to-the-wire performance was not an issue. You can actually get decent performance out of both of these platforms, and in some cases you might end up with better end-to-end system performance because you can spend resources on a good design, rather than having to worry about memory allocation and data structure layout issues. Of course, for the kind of low-level graphics stuff I enjoy programming, it's hard to beat pure C.

Probably the biggest reason for the popularity of C is that it's basically the only member of the intersection of the sets of platforms reasonable to program in and stable platforms. Everything else is either not powerful enough to do real work in, or changing regularly, or both. Thus, programs written in C are considerably more resistant to bit rot than in most other languages. This has traditionally been important in free software, although that might be changing. In the more modern view of software as a stream, rather than a collection of durable artifacts, the fact that the platform is changing may not be so important.

Also, thanks to everyone for the quality of discussion. Language wars are traditional stronghold for juvenile flaming. I'm glad our community seems to be able to get past that.

i started out on c, self-taught because imperial college didn't want its students learning such a horribly unstructured language. they taught us sensible things like modula-2 and hope [the elec-eng'ers got taught c :)]

my first serious introduction to c++ was in 1993 - 3 years of working on a dos-running Graphical OS. window clipping, sliders with class-based mouse-selection (logarithmic and scalar), meters, a 2-d graph (including fully scalable, class-based axes). it was really, really enjoyable work and to have considered implementing this in c would have been insane. i.e. the task fit the tool etc.

i then went to msdev, for another company - 3 more years. c++, again, fit the task - a gui interface to do real-time display and input to a data-logging device [similar to what i had done before, but this time win32 not DOS]. the programmers were all top-quality software engineers. we even managed to get real-time data logging out of windows 95, which is considered to be impossible.

now i have heard of people who attempt to use neat features of c++. for example, overloading operator[]. showing these people exactly what happens when single-stepping through with a debugger tends to make them very, very depressed.

i have been trying to compile worldforge on linux mandrake 7. first thing i noticed was that whilst autoconf detects that #include <string> fails, lib/varconf still goes ahead and tries to #include it, which causes a compile error. perhaps i should include my COMPILE-NOTES i am building, it will best demonstrate that the task is taking a hell of a lot more than just ./configure; make:

hi,

 i wanted to compile worldforge, because i think it is a very cool
project.

 i have practically nothing that is needed, and have some things that
are at higher revisions than the default.  this is my notes, so far....

 1) i had to upgrade linux mandrake 7.1 gcc 2.95.2 to gcc 2.95.2
by downloading and compiling it.  why?  because mdk 7.1 doesn't
install libstdc++ by default!!!!

 include <string> failed, etc.

 2) i had to obtain libsig++ from sourceforge.net, version 1.0.0-2
i think.  this was missing sig++-config.h from its installation,
so i had to copy that

 3) i have xml 2.2.5 because i am developing some xml-related stuff.
lib/lemon/src/lemonXML.cpp fails to compile because it expects
node->child not node->children.

 i modified lemonXML.cpp, it was quicker: i refuse to downgrade to
libxml 1.8.x because it is highly discouraged.

 there is a compatibility compile option for developers to use
either 2.2.x or 1.8.x, i recommend this be investigated, and that
you move from 1.8.x as soon as possible.

 4) ODBC???? stage uses ODBC????  aaaaaaaagh!

 i have spent _days_ trying to track down odbc drivers, it is a
_complete_ pain.

 odbc is currently not being used enough.

 i will write more, but the README was not enough: the odbc lib
is needed _and_ the source for an open source odbc-driver for
it to load, and at the moment, most of the odbc-drivers are
commercial [that i could find...]


 5) lemon.  lemon, it looks like it depends on glibc 2.1.

 either that, or upgrading from gcc 2.95.2 rpm to gcc 2.95.2 compiled
has caused something AWOL.  i will download/compile glibc 2.1.3
and see what happens...

 [i get a dreaded clog@@GLIBC2_1 undefined linker error.]

 well, compiling glibc 2.1.3 didn't work.  so i tried glib 2.2.
that's messed up the gcc compiler, right now, so i have to
sort _that_ out.

my quest for the stdc++ library took a few hours. i was not happy with this. in my quest, i discovered that egcs does not exist any more, it is part of gcc; that gcc latest cvs is broken w.r.t. link to past _and_ future libraries (!); that stdc++ is now included as part of gcc, you do not want to download the separate libc++ and compile it into libc or whatever.

basically, this is far more than i need to know. if i was working _on_ gcc, g++ etc, i would be fascinated by this process. what i _really_ need is just a working compiler.

Several people have stated that C++ is more popular in the commercial (closed-source) world. My reply is: not really, or not for the good reasons.

In my (limited) experience as a software engineer and through some conversations with friends working in various companies, I would say that C++ is often selected for the wrong reasons:

• In the Windows world, the developers want MS Visual C++, not C++ itself. This is a totally different thing. The developers want a nice development environment that is supported by a well-known company and can use the Windows API and other goodies like MFC. Some of them choose Visual C++, some of them choose Visual Basic. But the choice of C++ over C is not based on the pros and cons of each language, but rather on the environment provided by Microsoft. Some interfaces are easier to use from C++ than from C (because that is how MS has designed them), so the developers choose C++. The fact that the Visual C++ compiler deviates significantly from the current C++ standard (or any earlier version) is irrelevant: VC++ is the de facto standard on Windows platforms, for those who do not use Java or VB.
• In the commercial UNIX world, the bias towards C++ is less obvious. Still, in many cases C++ is more popular but for the wrong reasons. Initially, the developers choose C++ because they want to benefit from the STL or other nice features of the language. But in the end, the limitations of the compiler (even more if multiple compilers have to be supported) force the developers to abandon the more advanced features and fall back to a subset of C++ that is nothing more than "C with classes". This could also be done in ANSI C (as shown by Glib and GTK), but the initial decision was to use C++ to the development goes on with that even if most of the reasons for prefering C++ are less relevant when the actual implementation starts.
• In the EPOC world (Psion/Symbian), C++ is selected because the whole OS is implemented in C++ and makes good use of object orientation. Some of the interfaces are simply not available in ANSI C (some parts of stdlib are provided, but the support for C is very limited). EPOC is probably the only commercial environment that I know in which C++ is more or less unavoidable, but this is a good thing because the system is well designed.
• In many companies, the programming language is not selected by the developers, but by the boss or by some expert/advisor/consultant/comittee who is convinced that C++ is the silver bullet because other companies are using it.

As a matter of fact, I do not know any large commercial project that uses C++ for more than "C with classes". This may be due to the fact that even the commercial compilers do not follow the standard very closely, causing portability problems between different platforms or linkage problems when using different compilers on the same platform.

C++ has some nice features (e.g. STL), but in practice most of them are not used as they should. It looks like the free software community is more resistant to the change from C to C++, when the latter is not able (yet) to provide any significant advantages in practice. It will be interesting to see how if this evolves when the compilers (especially g++) become more mature, when the same code can be compiled with all C++ compilers (including VC++) and when it is possible to link together some C++ objects that have been produced by different compilers.

We use c++ at work for a ground system/satellite control/monitoring application, and we use it at much more than the "C with classes" level. STL, partial specialization, CORBA, etc. and we do it on Win2K, Solaris, HP-UX, IRIX (and Linux =). There is a platform independence layer, but *any* program that hopes to work on Windows (non-cygwin) and any unix platform needs one. C++ makes it particularly easy to provide a consistent programming interface, regardless of which platform you're actually operating on, for example, opening a shared library is usually dlopen() on most unix platforms, however, on hp-ux it's shl_open(), and on windows, it's LoadLibrary() Using our base platform-independence layer, ACE, regardless of the platform, this is available as ACE_OS::dlopen(). The C++ compilers on our supported platforms are now at the stage where compatibility is possible with very little work on the part of the programmer. There are still a few quirks here and there, but they are disappearing faster with each release. My only point here is that we abuse the hell out of c++ on a daily basis, and it holds up to the abuse quite nicely.

As for why c++ isn't frequently used in free software projects, I suspect that there are several reasons. It's only been in the last year or so that compilers from different vendors have been able to compile the same code base without serious platform independence work. This has certainly hampered portability of c++ projects. Until very recently (egcs-1.1.1), use of templates tended to horribly bloat the final executable image size. Not that this typically made a "make or break" difference on most systems (what's another megabyte between friends), but c++ still carries that "bloated" stigma to this day. Also, vendor c++ compilers cost a lot of money, and g++ support for non-Linux platforms is *really* lacking. For Solaris, it's adequate, but we've had major problems on hp-ux and irix for quite some time. A lot of the established free software projects that required portability (apache, sendmail, etc) did not have sufficient c++ capabilities available to them. Since the bulk of the "important" established code base is written in c, the younger crowd tends to learn how to think in c. Learning to program in c is pretty much a trial by fire process, and it becomes a matter of pride among anyone who doesn't also know assembly progamming, what I refer to as the "studly factor" (which I suspect is also responsible for a large part of the perl user base).

Programming effectively in c++ is a vastly different beast than programming in c. The c++ programming environment has just recently progressed to the point where useful code can be portable with minimal effort, and will still compile years down the road. Projects like Mozilla and AbiWord (previous post) will provide much useful hack potential in c++ land.

Tjo!

I've had quite some experiences with c++. After all, I've implemented a compiler in it and done work on another in it as well (both compilers were university class stuff). And I kind of like it. It's typesafe, runs fast and object oriented design becomes less of a hassle than with straight C. And I don't have to use multiple inheritance and operator overloading (I, for one, hate that stuff).
Binary compatibility issues aside; the reason I avoid it for my own little projects are the lack of C++ wrappers for the libraries one wants to use. For instance, the C++ wrappers for GTK+ never seem quite up to date with what is wrapped. This is a barrier for anyone who just want to write a C++ program (and maybe not care very much about portability for the first few versions) where libraries have to be used extensively.
Right now I'm eagerly awaiting the finalization of GTK+ 1.4 and Inti, so I can go on and write some larger, actually useful stuff in C++. Doing all the (void*) work in C quickly becomes very boring and error prone with large programs.

harebra / M

I think the reasons why C++ and free software don't mix too much are mostly cultural.

C has this "Holy Unix Language" aura which makes it impossible to displace from the hearts and minds of hackers, especially young, relatively inexperienced ones ("de-facto Unix programming language", "no language mixes better with Unix because they've been created together", etc...). This is a cultural problem more than a technical one. Unix hackers love C. There's noting rational here. C is cool, C++ is not.

Once a programmer has been crowned "hacker" by his peers (which is quite often what he was aspiring at in the first place) that makes it even harder for him to ever reconsider his technical choices (especially if that involves significant effort like learning C++ is). So if he's ever had bad experiences with C++, he'll stay firmly on his positions that the language just isn't good.

There's also the fact that many of the "masters" (Miguel, Linus, RMS) have publicly stated that they don't like the language. What's more, no hacker as high-profile as Linus' or RMS' is using C++. And as egnor says, almost all successful Free Software projects use C, and thus somehow prove that C is "good enough".

So C is definitely a likeable language. If you like a language, you will happily suffer through its quirks and shrug at them, and every feature will look absolutely essential. If you don't like it, you will consider its features as useless or outright bad, and even the tiniest oddity will look fatal.

For instance, see how many people hate multiple inheritance and operator overloading, two features which are actually incredibly useful. But they don't mind going through the syntactic peculiarities of the void* and casting marathon which constitutes any OO framework in C.

Note that in most cases they haven't ever used these bad features, they only heard horror stories about them. But the fact that you can shoot yourself in the foot using them is enough to tag them as utter evil, even though C provides a wealth of similarly dangerous features which they happily use daily (void* is not evil, it adds flexibility :-).

Another reason is that it seems many hackers fail (or refuse) to see how languages are evolving to constantly higher levels of abstraction, probably because it obsoletes their craft (assembly, C, C++, Java, C# see this article), and that programming paradigms (structured, OO, generic) have to be implemented at the language level. Yes, you can build an OO framework in C and draw a huge benefit from it, but it will never be just as good as any language with built-in OO facilities.

Implementing such features through syntax conventions can work, but it's much harder to make it scale, because it's up to the programmer to enforce the required "structure", instead of the compiler. But if you like it, you'll just say "so I just have to be careful, big deal" :-). But in practice what seems like "a little bit more verbosity" can quickly get in the way of the comprehension of the code.

This is the same reasoning which makes you write a function to wrap a sequence of actions which occur often in your code. Or more generally which makes people create new words for new concepts as soon as the concept is used often enough. People don't say "portable tape recorder", they say "walkman", it's more efficient and easier to understand. Likewise, it's more efficient to type "class foo : public bar" than "typedef struct foo { bar _bar }".

See this interview for a similar reflection on that point, about properties.

The other problem with this approach, aside of the added strain on the programmer, is that however well done the framework is, it's heavier than the equivalent feature built in a language. This means both the mem/cpu and code typing overheads. For instance, compare the cost of creating and deriving a class with the GTK+ OO framework to the same thing in C++.

Because of this, you're much less likely to create classes in C with an OO framework than in C++. So your code often ends up having just a few huge classes (but it's still better, more efficient, easier to read, etc... than having tons of very small classes like you would obviously have in C++, will you reply :-).

Also, such a framework tends to not be very scalable both up and down. To implement things like OO Design Patterns is quite hard. To implement a simple string or vector class is not worth it, because of the framework's overhead.

Note that this works all the way upward : C++ programmers try to implement Java features with the same mitigated results.

About wrappers, a C++ wrapper over a C library most of the time won't be as good as a full C++ library, because there are many languages features which you won't be able to use. This is true for any other language than C++, though. Wrapping is just that, wrapping. It doesn't automagically endow the wrapped language with the qualities of the wrapping one.

You can see how much of a cultural problem it is : suppose a language C-- which has only 'if' and 'goto' keywords, no functions, and only global variables. Then someone says he's implemented for(), while(), do...while() and function calls with macros on which the compiler can't perform any checks. It's just up to you to be careful. Now would you consider using it rather than C ?

I believe that even if C was less portable than this imaginary C--, and would produce bigger executables, most of us would still take C any time.

Still on the cultural side, C++ being quite used in the Industry doesn't help too much either. Almost by definition the Industry is Wrong, the Hackers are Right. As Raphael said, C++ is popular in the Industry only because it's pushed by consultants or clueless bosses (seriously :-).

Yet another reason is that C++ is indeed too complex, and so is OO programming in itself. See this advogato discussion for an example of someone who totally mistakes OO programming for inheritance and class hierarchies.

The performance/bloat issue is also quite often brought up. This is also part of the problem. For one thing this is no longer as big a problem as it used to be. But also hackers often give way too much importance to these questions, at the expense of maintainability and reliability. Taking more time to write a smaller program in C than a larger one in C++ is highly regarded. Even though in many cases the end user doesn't care about the saved mem or improved speed, unless it's really very significant. The same performance/bloat problem was said about C by assembly buffs, and is being said now by C++ programmers about Java.

I'm also surprised that so few people have mentionned KDE. C++ under Gnome isn't easy, but under under KDE it's a sheer joy. Having only a few hours per week to devote to my own projects, I really appreciate how productive I can be, no matter how corny out-of-a-MS-advert that sounds :-). KDE truly is a showcase of what you can achieve with C++. See how large-scale applications like koffice, konqueror or kdestudio could be written by a small number of people in a relatively short time.

A few more specific replies :

walken : You need to open a book about the STL and template specialisation. Of course you can specify the hash function when you create a hash table. And adapting it to your needs while remaining efficient is precisely what the STL is so good at. You can do it while keeping the interface intact, which is all that matters.

About switching directly to a "better" higher level language : that is certainly a good option, but which one ? For desktop apps, Java is still way too resource-hungry (although this won't last for ever). As for portability, anyone working in a Java shop will tell you that it's quite often the usual nightmare as well. Python along with GTK+ or Qt is possible, but still much bigger than C++. I'm not sure how scalable that solution is as well.

It's true though, that if Java was ready for the desktop I would use it instead. But the tremendous success of C++, IMHO, shows that it precisely has the "right balance". C++ is a practical language, not an academic or aesthetically pleasant one.

Languages are like houses : no matter how beautiful and well designed they can be, if you want to actually live in it and not just visit, you need a place to shit. Because in real life, you *will* need it. You will need 'goto', you will need to wrap that legacy C struct and turn it into a class without changing its size, you will need a plain old function and not just elegant classes, you will need a global variable. As soon as you tackle real problems, you will need these "dirty" features. And if your house doesn't have such a place where you can be dirty, you'll end up taking a crap in the living room and it will stink even more. That is, you'll bend the "clean features" of your "clean language" to something really ugly.

lkcl : So, what depressing stuff happens when you single-step through an overloaded operator[] ? Nothing that you didn't write. It's just a function call. It can even be inlined to a good old '[]'.

About your building problems, it seems you just needed to install the libstdc++-devel rpm. You might also consider trying to build a program which doesn't depend on so many libraries. Every stable KDE program I've ever built was as simple as './configure; make'. This has nothing to do with C++.

While I do understand that there are many reasons that C++ has not been widely accepted in the Free Software community, I do not feel that it is necessarily the case, and it should not always be so.

I've seen some posts above which said that much of the free software written in C++ they've encountered has been of poor quality.

I think this is the case because C++ is indeed a hard language to master, and I've been programming in it continuously for four years now, with a few months spent in it back in 1990 (after which I gave it up), and only now do I feel that I am becoming proficient in it.

I'd like you to at least examine one shining example of C++ architecture and implementation - the ZooLib cross-platform application framework. It allows you to write a single set of C++ sources and build native executable binaries for POSIX platforms with XWindows (such as Linux), Mac OS, BeOS, and Windows.

I've spent the last year helping ZooLib author Andy Green prepare it for open source release under the MIT license. A lot of free software writes something to the 0.0.0.1d1 level and it ends up in production use on some distribution. Andy worked on ZooLib for nine years and wouldn't release it until he felt it was of the utmost quality.

C++ creator Bjarne Stroustrup feels that the problem with C++ is not that it's a bad language, but that it's taught poorly. Please see his papers page and download Learning Standard C++ as a New Language as a simple introduction to this argument.

The most common way C++ is taught is also the worst way it could imaginably be done - learning C first, then slowly extending into C++.

When I was working on teaching a class on object oriented programming at San Jose State U Professional Development, I proposed that we teach object-oriented concepts before teaching any programming language, while possibly using only the minimal amount of some programming language (any language would do) to get those concepts across.

The real difficulty in any large software project is how to make a good choice of how to partition your problem space so that you can readily design a solution to each subproblem without thinking hard - and also designing the communications channels between those subsolutions.

I feel that this is not taught well at all, anywhere.

I'm doing my own work, albeit slowly, to help this situation with GoingWare's Bag of Programming Tips. You can get a sneak preview at my next tip, still incomplete, Pointers, References and Values.

This has always been my feeling about C vs. C++: a bad programmer will write worse C++ than C. It's pretty hard to write C code that someone else has no hope of unmangling, unless you're really trying to be bad, but it's pretty easy to write a hopeless mess in C++.

But a good programmer who takes the pain to learn the best of all the tools available, will write better C++ than he could hope to write in C.

With my recent experience writing large projects in C++, I just love how expressive and efficient it is. I can make code sing in C++.

But I was a long time getting there.

Well, when Debian's famous apt program is at least partly written in C++, I think it becomes a little hard to support the claim that free software and C++ don't mix. :-)

One could also ask, why don't free software and Ada mix? We have a first class Ada compiler, it's a clean, readable language, far more elegant than C++ IMO. But, like C++, it has a (largely undeserved) reputation for bloat.

Really, I think C++ is competing more with java and perl and python and ada and scheme and guile and haskell and eiffel and smalltalk than it is with C. C is in a completely separate class. C is the glue language, the portable assembler that makes things work and ties things together; it's the lingua franca, where C++ and all those other languages are each just another application development language.

Note that I am not saying that C is a better language than C++ or Ada or Scheme or whatnot. I'm merely saying that it's in a different class entirely, and can't be compared directly. I do think that C is overused in areas where it shouldn't be, but I suspect that that's merely a side effect of the fact that it's become a lingua franca.

I've written a lot of C++ for pay, but for my own purposes, for high level code, I'd rather use Python or Ada or Scheme or even Perl. Lisp-like languages in particular have a strong following in the hacker community.

Also, there is the factor that several people have mentioned, that free C++ compilers have not really been up-to-snuff until pretty recently. So, I wouldn't expect to see much C++ in older free software projects.

But I suspect that as more people come to Linux/BSD from the MSWin world, we will see a steadily growing number of C++ projects. I'm not sure if I think that's a good thing, but I'm sure it won't be any worse than having huge programs written in fragile C. But bottom line, the world does not consist of just C and C++. There are a myriad of wonderful languages out there, and you all owe it to yourselves to investigate some of them. Remember, free software means you get to write it the way you want to! :-)

cheers

A lot of people seem to be making an issue of the difference between C++ and simply `C with classes'. I think that the reason that so many people misunderstand C++ because of the way it is generally introduced.

When I was a student, we had software engineering lectures, although they were strictly just trying to teach everyone to hack things together. The first course taught C, and the second taught C++ as an extension.

This isn't just about universities - how many people in the business world have had training courses on C++ from the ground up? Not many I suspect, since most managers seem to think that you need to learn C first (and the people who get paid for doing two training courses aren't going to tell them otherwise). How many C++ books `lead you in gradually' by showing some procedural programming for the first couple of chapters and then slipping in a bit of OO?

My motivation for learning C++ (ignoring the lecture course I had, which was useless) was because I wanted to. I got a decent book, and over the past couple of months I've been making a serious effort to learn C++ properly, rewriting rCalc as I go. After the initial rough patch it was scary how quickly things started to come together and how easy it was to add new features without introducing bugs.

Quite how much of this is due to the fact that the new rCalc is much better designed I'm not sure: the original version kind of coagulated from a couple of other programs. But the fact remains that, even if I designed it like it is now, it would be a hell of a mess if it was written in C.

Not that I'm saying that C++ is right for everything: I've done stuff in C, Lisp, Perl, Php and shell. Each has their own advantages and disadvantages and these must be taken into account when you are considering what you are trying to code and where it fits in the grand scheme of things. Python is my next target - anyone know a good book?

Quite simply, the reason I don't use C++ as much as I'd like is that if I want a high-level language, then I'm more likely to go all the way and use something like Perl or Python. The compile-edit-debug cycle is just too painful for me to ever want to work on a large C++ program again.

I find that using a mixture of a very high level language and C is generally a more agreeable way to program than writing the whole thing in a 'mid-level' language like C++. (okay, strictly speaking, C++ is high-level)

My general rule of thumb is that anything above libc (having worked a bit on libc I can say that :-) gets written in object oriented Perl first, and if possible, the structure (class hierarchy, etc) stays written in Perl. In fact programming in C is not too bad when you also have all of the internals of a dynamic, object-oriented language at your disposal. Pity that perlguts are so obscure and undocumented...

As to why C++ is rare in the free software world, I think it's because C++ was designed for programming very large, highly integrated systems (at least, that's what my Stroustrup book says :-), which are a rarity in the free software world. KDE and Mozilla are exceptions that prove the rule. As we see the free software community tackle these sorts of applications, we will inevitably see them using more C++... it works really well for enforcing consistency and correctness within a large, homogeneous system.

However, a lot of useful programs are small, or they are made by gluing together a bunch of heterogeneous libraries and components from different sources. In these cases C++ provides little, no, or negative benefit, not just because of the ABI incompatibilities, but also because the fundamental principles of type safety and compile-time binding, which are essential in the types of systems described above, become liabilities in this case.

Someone is going to mention RTTI, and someone else is going to mention CORBA (and mang will kill me if I do not also mention XPCOM :-) I am skeptical, but curious as to whether these alleviate the problem of C++ not playing nicely with others. In particular I wonder if anyone actually uses RTTI - anyone care to enlighten me?

As for people using it, well, just about every C++ programmer these days, unless you explicitly disable it at the compiler level (which is really not recommended). The typical use is dynamic_cast.

Also, C++ success is very much due to the fact that it's so flexible that you can use it as a glue language to integrate various components and libraries. I often think of C++ as the Perl of compiled OO languages. :-)

I have used C++ for, well, ever. Back when it really was just C with objects!

In general I have to agree with the general belief that G++ has harmed the chances of C++ being more than a niche language. Initial G++ support (back in 2.2.7) was really bad compared to state of the art compilers in that time, period. The general pre-egcs gcc dev slowdown also happened around that time which damned us all to a really poor compiler for way too long. I think that turned alot of people off of the language, it was just too painfull to work around all the compiler flaws.

These days the language support is pretty good, but the generated output has some alarming size issues. I think these are all slovable eventually, but right now you pay a fair bainary size penalty for using parts of the standard C++ library and to a lesser degree exceptions. Fortunately this is generally just fixed overhead and is only important if you have lots of binaries.

For instance, I think nothing about compiling APT on every arch Debian supports, Solaris, the BSDs and HP-UX, as long as g++ 2.8 or better is installed it is fine. I don't really have any portabilty hacks except to work around statfs and the HP-UX sockets lossage. However, I am not confident that it will work on a non G++ compiler without some changes - primarly due to G++ not enforcing the standard as it should. CVS G++'s are better in this regard.

I have seen several people mention that it is hard to bind C++ to other languages - thats is a total crock in my opinion. It is just as much work to build a Python binding by hand for a C++ and C implementation - I've done it. The key observation is that for any given design the Python API should be fixed -if the interface is to C++ or C it doesn't matter because the majority of LOC is spent on the Python side.

On this issue I would encourage peolpe to ask 'What if Python was in C++?' - I very much supect the answer would be that it would be a magnitude easier to make binary Python objects, that nasty refcounting problem can be nicely solved by the compiler, and you have a good chance of seemlessly integrating execptions across the two. I would really like to sit down with that Java Python and see how nice it could possibly be.

Is this a big win for people who want to write optimized code for otherwise pure Python projcets? Yeap.

Guess I should first explain my history with C++. I first started learning C++ out of the Borland Turbo C++ 3.1 users manual around 1992. After a couple years of doing projects in it, I found out that C++ classes didn't support static initalization, only C structs support it. I also "realized" that C had the +=, etc operators which I considered important. Once I realized that the features that I wanted were in C I dropped C++.

It wasn't till a couple years ago that I found out how you "staticly" initalize a C++ class. It was a complete hack, and still is, but this is how: <code> myclass &statmyclass(void) { static myclass a; static int i = 0;

if (i == 0) a.intialize(whatever); return a; }</code>

Now that is a major hack just to get static initalization. You can of course use similar approches for arrays, but still, it's a hack around something that should be part of the language. Maybe this has been fixed in the final standard, but there are parts that make C++ just to difficult to use.

I can never remeber how/why/when a destructor is called, and if I want to handle the allocation of the object (which C++ is proud to say you can), how do you? Do you override the new operator? Or do you allocate the memory in your constructor and assign it to this? There were just too many ambiguities for me. I shouldn't have to sweat over a language to make sure it's working properly. Sure you could do spiffy things for things like B-trees by making sure that all your nodes come out of the same memory pool, but if you're worring about such things, you might as well write it in C.

Also, C gets a bad rap because people don't know how to design clean interfaces. One of the biggest misfeatures is a class for cgi forms! If you initalize more than one cgi class (which is very easy to do) you could end up corrupting data, or getting invalid data. In order to avoid this, you should use a similar method to above to staticly initalize a single cgi form per program instance. Hack after hack. :) At least in my opinion.

I will admit that I haven't written any large software applications, I'm sure C++ has it's advantages, but if I need to prototype something, I'll use Python. If I need to get some extra perforance out of something, I'll code it in C.

Yes, Guillaume, I know what RTTI is. I'm sorry that I juxtaposed it with two things which are mostly unrelated to it, which seems to have obscured my point. The one thing that it (as a language feature) has in common with things like CORBA is that it adds run-time binding functionality (as in Perl, Python, Smalltalk, etc, etc) to C++'s object system, which otherwise relies entirely on static type information.

When I asked if anyone uses it, I meant, does anyone actually use dynamic_cast. I know (all too well - it's often broken in GCC snapshots) that it is on by default. The question is, is it useful, and who uses it, and for what. I haven't seen much code that uses any of the new-style casts let alone dynamic_cast.

It's a perfect example of a feature which is easily abused, frowned upon by purists ("if your inheritance tree was well done you wouldn't need it" yada yada yada), yet quite often indispensable when you write code in real life.

As for who's using it, I am. In some methods taking QWidget* arguments, I sometimes need to perform a specific action if the QWidget actually points to a widget of some specific type. I've also seen it used in KMail, I suspect many KDE programs use it as well if they need it (even though Qt has its own RTTI system, but it's seldom used).

About other new-style casts, it's quite simple : I never use C-style casts anymore, and most reasonably recent code I see does the same.

That this pattern should be part of the language is debatable, though. Patterns are one abstraction level higher, and C++ already encompasses quite a few (layers). May be some new language would have it, though.

About handling allocation : you seem to be confusing issues here (constructors and placement new). Given the rest of your comments it seems you tried to grasp every feature of C++ at once and were overwhelmed. You say that C get a bad rap because people don't know how to design clean interfaces. What I like in C++ is that it allows me to easily design much cleaner interfaces than what would be possible in C.

C++ was conceived and developed originally at AT&T, in a wprld of million-line C projects.

An intrinsic property of large commercial projects is control by management and I think that with such control, C++ has shown to be effective. The project develops what is in effect its own programming language.

In open source software development, people need to get up and running with low learning time, and will generally contribuite patches without regard for architecture or style. Of course, the project team will yell, but the more restrictive the project's code guidelines, the fewer patches they'll get.

Meyers' Effective C++ books are a sobering read.

I use C for the freely available software I write for portability, but also so that people can change the code more easily. You have to consider the kind of people who might be editing your code and ask what are their abilities. I try to write code that is very clear, and that does not have any hidden interactions: I would generally avoid operator overloading, for example, because an inexperienced reader would be unlikely to understand what was happening.

I'd like to see a simple object oriented C, a C With Classes Done Right, with maybe a five-page addendum to the C spec being all that was needed. In the meantime, I am sticking with C for most things, and Perl, Scheme or some other scripting or interpreted language for others. I prefer to have as much compile-time checking as possible for anything I give to other people, though, so I'm afraid people say my Perl looks like C, full of error checking code. Such is life.

1. That you need to make things simpler if you want to get a greater number of contributions. The point of Free Software is still to be of better quality and to be used by normal people, not to require or even rely on participation by other developers. Ten average contributors are less useful than a single really good one.

2. That C++ makes it harder : I recently contributed a patch to kmail. KMail's code which is around 43 KLOC long. The patch adds the special handling of mailing-lists by folders. It involves remodelling a config dialog, and changing how reply-to addresses are handled. It took me about three hours to write the first version of the patch. This with almost no prior knowledge of KDE2 development, and having never seen KMail's code before. But the code was very readable, and I could find my way through very easily.

Ankh: you project a poor image of the culture surrounding Free Software, i.e. what is referred to as 'OSS'. You make it sound as if those projects can't put as much efford as is needed on design.
I think OSS is still a very young (but evolving) culture. The freedom and possibility to develop projects collectively over the internet is a wonderful thing, which develops it's own dynamics, quite independently from success (however you define that term in this context).
And yes, C provides a lower barrier of entry to that new universe. So what ? Project management will evolve and we will see much more research done which focusses on OSS. Brooks is not outdated. And as long as C++ helps enforce practical engineering principles it won't be replaced by OO C.

Working on Berlin, I'm thrilled by Fresco's design. We use C++ and CORBA heavily. The paradoxical thing is that a lot of people seem to 'know' the project, but we have very few people working on it. I definitely wish we had more contributions. But should I drop all the design to get more people involved ? Isn't the right thing (as Stroustrup points out) to educate each other better ? As it appears I spend a lot of time explaining berlin's design. I think this is a better (long term) solution to contribute to OSS culture.

And just to sum my comment up: each culture has its own gods. Others have mentioned Linus, RMS, Miguel. So let me throw in here Vlissides, Coplien, Stroustrup.

ankh writes:

I'd like to see a simple object oriented C, a C With Classes Done Right, with maybe a five-page addendum to the C spec being all that was needed.

- This sounds much like Objective-C to me. I'd switch to Objective-C in a minute. I really liked it on NeXTStep, I have no idea how well it works in the gcc version of the runtime.

- Booker C. Bense

The subset of C++ you describe sounds an awful lot like GJ

http://www.cs.bell-labs.com/who/wadler/pizza/gj/

Personally, I work on closed and open source software. I do it in C++, in the main. I find platform-independance easier to achieve, than working in just C.

The basic reason though, is why we good C++ guys get paid so damn much for what we do: The average C++ programmer is crap. Most of them that I've worked with really have no more than a nodding acquaintenceship with the language and simply write C with a .cc

extension, or manage to grossly misuse whatever C++ features they do use.

C++ is a much bigger language than C, and because C++ can compile much C code without modification, many people either (a) do not bother to learn it, and (b) don't use the paradigms that the language allows to minimise coding, effort and complexity.

The average C++ programmer is a bad programmer. Good ones are rarer, though in the open source projects I've worked on, I have found the average to be much higher than in closed-source industries. Still, we get paid big bags of cash for being good at this stuff. If you're good at this language, then performance hits are few, SEGfaults are all but unknown, and development times are much shorter (at the expense of a bit of extra design time, but you still save a lot over the life of the project).

Trying to hire C++ programmers for closed-source projects is nightmarish. The 'average' potential hire did maybe one C++ assignment at uni and has never looked at the language since. OO design? Never heard of it. Etc..Saddening.

I agree that good C++ should get paid boatloads of money (and I'm glad you are), but I'm sorry to say that I haven't observed this phenomenon first hand. How does one go about finding situations where those paying can tell the difference between quality and crap, and are willing to pay for the former, I wonder.

Aye. Agreed again on what dancer said... but, also, in counterpoint to mkc:

I've had the experience of working on a large (0.5 mloc) C++ project (closed source, but never mind)... and it used STL, exceptions, RTTI, iostreams, multithreading, the works... and this was being done while the standard had not yet finalised.

It pretty much worked and was clean. Why? Because there were two of us who were exceptional C++ programmers, and that was well recognised, and we basically had control over all of the architectural reused components of the system.

As a result, the other 10 programmers, who were mostly average, could use our well defined, clean components that didn't have exposed bits that can break.

OTOH, architectural grade C++ programmers are hard to find. It took me somewhere between 3-6 months of thinking so hard about C++ that serious amounts of English fell out of my head during that time to get good enough in C++ that I felt I could write sensibly clean code that was effectively bulletproof... and that's a serious amount of time investment for a professional programmer to make.

On the Gripping Hand, if you do have at least one or two software architects who've spent the time to learn C++, it can be possible to structure your project so that average programmers are not in danger of using things in broken ways.

This applies as much to Open Source projects as anywhere else... the bigger the project, the more you need to ensure that there is software architecture, and that critical sections are under the sole control of people that grok how to make clean, sensibly named, sensibly designed, sensibly functional interfaces.

To slide back to the main point of this thread... The size and complexity at which a project begins to require software architects varies from language to language, and for C++, the threshold is actually very low, in that to write clean base classes that are robust under many circumstances is a difficult task. This is why people tend fall into using "C with classes", because that reduces the complexity vastly to the point where you don't need a software architect to build most of your base classes.

I tend to find a similar phenomenon in Perl... Good programmers do really well with the language, while average to poor programmers fumble around and do way more harm than good... but this harm can be mitigated a great deal by putting good abstractions in place in a project from the start, and building the core parts of a system to be robust... vis-a-vis the core Perl library modules particularly as an example of that.

C projects, in comparison, do have to get pretty large before they start to actually require serious amounts of architecture... the language complexity is a lot lower.

Free software has to work on everybody's system. It must be buildable on all sorts of systems. C++ programs have strong requirements on the system -- yoiu need a working C++ compiler and you also need a working C++ library. The two things need to be in sync. You can't use G++ with the vendor's C++ library either. Also at one point I think that libg++ (now libstdc++) required glibc; I'm not sure that is the case any more, however.

If as the author of a free piece of C++ software you have to work out which jsubset of the language to use -- too much and your program will not work on many systems. Too little and where's the advantage?

Guillaume:
Thanks for the pointer to the book. Considering the time/age when I learned C++ you are probably correct. I didn't throw it out after a short period of time. I did spend at least a year (it's hard to remeber that far back) with it, but I wasn't a very good programmer back then.

As for the Singleton method, I don't think that it should be an external part of the lanaguage. It should be a part of the language. The C++ spec is already large enough, why didn't this get condensed to something more usable? If it was part of the language early on, I probably wouldn't of abandoned C++ and actually tried to learn it, but since I was ending up writing C code in C++, I decided that I shouldn't delude myself and learn pure C.

Now I might go back to learn more, but I've never had a real large project to really need the full power of C++. Plus, I'll have to relearn all the new spiffy things about C++ that have gotten added in the past 8+ years.

Patterns are one of the possible next abstraction step over objects, just like objects are the abstraction step over functions and data structures. James Coplien used to think so, but he later changed his mind.

As for not using C++ unless you have a big project which "needs its full power", this is again an old myth. As soon as you're using strings and arrays, you'll be happier to use std::string and std::vector<> rather than pointers.

Guillaume: I don't agree. You don't integrate patterns into a language. Patterns as well as idioms or paradigms live in a particular design, without being materialized in terms of concrete instantiation. An object can play different roles at once, depending on the perspective you take. Also, there are a lot of variations possible on a single theme. Just read Vlissides' Pattern Hatching. In this respect I agree with Coplien that the whole architecture is important, and its idiomatic coherence. Much as Brooks already pointed out in The Mythical Man-Month.

If you don't know what's wrong with C++, try writing a C++ parser. -russ