Wed, 28 Jan 2009
C++ Woes
I wonder why even these days people start new open source projects in C++. C++ is - as far as I know - by far the least portable compiled language. I would understand using C++ in big proprietary projects, where everything including the compile-time environment is fixed. But for open source projects, where compiler versions, header file features, etc. vary greatly? No way.
The project I hate today is named IMMS. While trying to compile it I had to edit
11 different files, adding #includes all over the code. I wonder
how this could have been buildable anywhere at all - there were missing
prototypes/definitions for things like memcpy(),
INT_MAX, abs(), etc.
I cannot imagine how could it be possible at all for these symbols to end up defined in the author's build environment. The problem (one out of many) of C++ is that it is very strict about missing prototypes, but in turn it does nothing for preventing the namespace pollution, i.e. symbols being defined "accidentally", and thus the project being unbuildable elsewhere. I ran into the same problem a week or so ago when trying to compile a few months old version of Valknut.
Recommended reading: Linus' response to a question why Git is not written in C++. Morale: stay away from C++, or your projects will end up unbuildable after only few months.
14 replies for this story:
Hynek (Pichi) Vychodil wrote: Which one?
I wonder which one other compiled language you recommend to use? ANSI C, Haskell, Forth, Java, Erlang ;-) ??? I'm agree with you that C++ is one of the worst language to choose for open source project not only for portability issues. But which one? D, Objective C, CL, Clojure, Scala, Qi II, Oz, Perl ;-) ?
Yenya wrote: Re: Which one?
I would go with plain old C for compiled languages, or Perl for scripting languages. They are both mature languages with wide range of available libraries. Of course the surrounding environment would matter too - for OpenStep project ObjectiveC is definitely a valid choice, for example. I would not use any "niche" language like Haskell or Forth, and I hope my opinion on Java and Python is widely known :-)
Milan Zamazal wrote:
There is no single universal all-purpose programming language. Just choose a fitting language or a combination of languages for each particular project. "Fitting" means one of those you like, you understand, are suitable to the problem you try to solve, allow writing efficient and maintainable code efficiently, are known to your coworkers, provide useful libraries and development tools, etc. There is no inherent reason to avoid niche languages as long as a good free compiler and the necessary set of libraries are available. C, Haskell, Forth, Java, Erlang, Objective C, CL, C++ can all be good languages to choose from. I use several very good applications written in C++, although I wouldn't choose C++ for any of my own projects.
michal wrote: portability
imho c++ is well portable languege indeed. But there is no abstraction layer between the language and an OS (platform). So it's the programmers job, to keep his code portable. He has to know, that he can and what he can not do on target platforms. There support for namespaces is very good in C++. Gues what std::cout does? And the conclusion? Programmers shoud use their tools visely :-)
Yenya wrote: Re: portability
"In theory, there is no difference between theory and practice. But in practice, there is.". Yes, it is programmers' job to keep the code portable. But in fact, C++ makes it very hard. How can programmer know (or even notice) that he uses memcpy() without #including string.h first, when in his own environment string.h is #included from some other system file, and thus everything works for him? C++ is _not_ portable (in practice, I mean).
avakar wrote:
Well, LT's response regarding the quality of C++ programmers is (sadly) pretty accurate. An incompetent programmer is just more likely to choose C++ over C. That's also the reason why C++ projects tend to be crappier than C projects in average. As with everything, it comes down to the quality of contributors. That C++ may be less suited for open source development is certainly not caused by it being "a horrible language". Admittedly, it is much more difficult and time-consuming to learn to use it correctly (emphasis on correctly). Regarding IMMS, the real problem isn't the missing prototype for memcpy, it's the very use of memcpy in a C++ project. Regarding namespace pollution, C++ provides namespaces to deal with that. In fact, C suffers from exactly the same defect (even worse since C does not provide namespaces at all). Regarding "varying header file features": those have been fixed for more than 10 years now. The fault is again on the shoulders of programmers whose code use toolset-dependent features.
avakar wrote: Re: portability
Let me ask you in return: How can a C programmer know (or even notice) that he uses memcpy() in his C project without #including string.h first, when in his own environment string.h is #included from some other system file, and thus everything works for him?
Yenya wrote: Re: avakar
C does not have this problem, because in C, prototypes are optional. So C compiler would never barf on missing prototype.
GM wrote:
In my opinion, C++ has very poor concept from the beginning, all its features are the proof (look at templates, you wouldn't be able to work with collections because of broken design of C++). However at least Trolltech guys shown me with their QT, it is possible to write good and portable application even in C++. But I would also never say, perl is good scripting language. I see same lack of design as it is with C++, so many features and just because of features itself (like it is in C++). Portability of perl programs is very similar to portability of C++ in my eyes, I struggled tough with perl script to let it run on different systems. The other point, anything what could be called "scripting" is *not* portable at all (web vs. system, Unix vs. other Unix, etc). The only advantages of perl are these two: 1) it is real programming language in the opposite to sh/awk/sed combo, 2) you can write good oneliners in opposite to other real programming languages. Neither one of these two is a good reason for such weird design. Well, everybody has its greatest candidate for the most shitty popular language. ;-)
avakar wrote: Re: missing prototypes
[... in C, prototypes are optional.] Fair enough. Missing prototypes are, however, a disaster waiting to happen (fabs(1)).
Hynek (Pichi) Vychodil wrote: Re: Re: Which one?
I don't know if your opinion on Java and Python is widely known but hasn't know for me. When you wrote it in those manner I think it is very similar to mine ;-)
Hynek (Pichi) Vychodil wrote:
@GM: Perl programs are far better portable than C++ ones. I haven't ever felt in memcpy() like problem. You should just keep using modules which are in standard perl distribution and keep your file paths manipulation with File::Spec and some other thinks. See perlport - Writing portable Perl Be aware of two important points: Not all Perl programs have to be portable There is no reason you should not use Perl as a language to glue Unix tools together, or to prototype a Macintosh application, or to manage the Windows registry. If it makes no sense to aim for portability for one reason or another in a given program, then don’t bother. Nearly all of Perl already is portable Don’t be fooled into thinking that it is hard to create portable Perl code. It isn’t. Perl tries its level-best to bridge the gaps between what’s available on different platforms, and all the means available to use those features. Thus almost all Perl code runs on any machine without modification. But there are some significant issues in writing portable code, and this document is entirely about those issues.
Sten wrote:
It is not C++'s fault that the programmer of the IMMS does not know how to programm in it, since there's no such thing like memcpy or INT_MAX in (strict) C++. Namespace pollution can be avoided by using anonymous namespaces - again, programmer's fault not to do so. The same that would cause namespace pollution in C when he/she would forget to write "static".
wrote: Yenya
The point is, that with C, the program would compile and run without #including the proper file (or forgetting static), while in C++ it does not even compile. And there is no way for the programmer to know that the program compiles on his own machine only accidentally.