C++? Are You Crazy?

But Bertrand Meyer's Eiffel is quite appealing (clean, simpler), but what we would need is a good GNU Eiffel environment, which does not exist yet.

I mean a good compiler, debugger, profiler, and of course good libraries.
So far only mostly proprietary Eiffel exist, though there is a GNU small Eiffel, but the code generated is C, and unless I am mistaking there is no debugger.

Andre G-

Personally, I learned C++ after minimal exposure to C, but I have worked on several other languages with varying OO expressive power. I find that object oriented design seems to always eventually "come out" of whatever large project you happen to be working on anyway. You end up using structs and functions to act on the structs... but in the end it's much better to simply design a class. For one thing, you can build in error checking and try to best to guarantee that this part of the code will transparently integrate with other parts in a 100% predictable manner, and for another you can test it independently of anything else with much fewer inputs meaning it takes less time to test all possibilities.

Classes (or structs) can be annoying if you're entering your code into a text editor and don't realize you misspelled something until you try to compile, but they're absolutely wonderful if you're editor will pop up a list of member functions the moment you type a dot or arrow after a class variable/pointer and complete the text for you.

I agree, though, that C++ is a big language... I know quite a bit of it, but I still feel like there is much more to learn. I always wonder how much harder it must be for a non-English speaker to learn to program in these languages based on English words, abbreviations, and acronyms, especially since a good portion of the Open Source community does not reside in English-Speaking countries.

But in closing, I'd have to say that on today's machines, any performance complaints about C++ are pretty insignificant, especially since you can resort to C-style coding and optimization techniques in any mission-critical code areas. Of any OO language meant primarily for compiling stand-alone binaries, though, I can't think of any more widely supported and understood than C++.

--Shon

A few good reasons:

* Compiler and library support had been poor and non-standard for years. This has had a lingering effect on the reputation of the language in the free software world.

* It's a big, complex, downright intimidating language, and many people just haven't had the time or inclination to navigate through the potentially treacherous waters.

* the old "C plus classes" paradigm was not very compelling, yet this is still the approach of many texts on the market (see www.accu.org). The more STL driven approach has taken time to trickle down.

I do think things are improving, though, with hugely better compiler and library support, and much better books available (like _Accelerated C++_ and various STL tutorials).

Stepping around the various issues that people have already highlighted with the use of C++ runtime features in operating system kernels, I am not surprised that C++ hasn't been more widely adopted. It is arguably only the past couple of years that reliable standards compliant C++ compilers have become ubiquitous - "arguably" because C++ is one of those languages whose implementations always invite deviations from the standards-prescribed behaviour, if only by accident.

Meanwhile, higher-level programming languages have very much "stolen the clothes" of C++: Java may have been seen as a "dumbed down" C++, but it delivered the goods that interest developers the most (garbage collection, threading, extensive standard libraries); Python and other languages (such as Ruby) give you an even higher level of abstraction, garbage collection, threading, extensive and *useful* standard libraries (see the pattern?), with the possibility to integrate with C and C++ components natively. Whilst C++ has STL, and it may be efficiently and beautifully implemented, the developer gets to see code which isn't so beautiful, especially when their compiler starts to complain about...

some<strange_ &problem, with_<their *__templates> *they, did<not **even_know__, they &were> *_using_>

And I think you'll find that most object-oriented languages offer the wonders of constructors, destructors, encapsulation and inheritance. Reaching for C++ every time an application needs developing is like reaching for a heavy, slippery hammer from the toolbox every time some carpentry needs doing.

From Documentation/DocBook/kernel-hacking.tmpl:

Using C++ in the kernel is usually a bad idea, because the
kernel does not provide the necessary runtime environment
and the include files are not tested for it. It is still
possible, but not recommended. If you really want to do
this, forget about exceptions at least.

From the GNU coding standards, section 3.1:

When you want to use a language that gets compiled and runs at
high speed, the best language to use is C. Using another language
is like using a non-standard feature: it will cause trouble for users. Even
if GCC supports the other language, users may find it inconvenient to have
to install the compiler for that other language in order to build your
program. For example, if you write your program in C++, people will have
to install the GNU C++ compiler in order to compile your program.

C has one other advantage over C++ and other compiled languages: more
people know C, so more people will find it easy to read and modify the
program if it is written in C.

So in general it is much better to use C, rather than the comparable
alternatives.

Now my two cents: So the Linux kernel actively discourages C++ and the
GNU folks actively discourage C++. But Mozilla is a lot of C++. It is the
same as any other part of the programming industry: the project leaders
choose the language. If you want to program in C++, start your own
project or find a project that uses it.

i just farted