The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

About time somebody wrote this, C++ is defective with a FQA?

http://yosefk.com/c++fqa/index.html

"This page summarizes the major defects of the C++ programming language (listing all minor quirks would take eternity)."

Now, we need one for java, php and ruby.
Bot Berlin
Friday, October 26, 2007
 
 
Wow. A line-by-line rebuttal of the entire C++ FAQ? Somebody *seriously* needs to get a life.

I mean, come on. Criticizing languages is fine -- we all do it, and it's fun in moderation -- but there's a whole world outside the computer room.
clcr
Friday, October 26, 2007
 
 
Most of it is BS.
Developers are defective - not C++.
Simply, do not use questionable practices.

Also, who cares how many times the files gets compiled or 'passed' by the compiler. What's important is a quality of produced binary at the end of the process.

The very first C++ standard included all what's needed for object-oriented programming. The "features" accumulated over the years are just useless gunk.
asmguru62 Send private email
Friday, October 26, 2007
 
 
"Also, who cares how many times the files gets compiled or 'passed' by the compiler."

People who get build times measured in hours.
Roman Werpachowski Send private email
Friday, October 26, 2007
 
 
Second that *wow*.  I don't like C++ very much either, and programmed in it full time for about a couple years.  But damn, I just stay away from it.

It takes dedication to *learn* that much C++, simply to trash it.

Life is short.  Find a new job before that much bile builds up in your blood. : )
Moosebumps Send private email
Friday, October 26, 2007
 
 
Somebody actually sat down and came up with a special fringe case for every single thing in the C++ FAQ??

I'm not impressed. Everybody knows that C++ isn't perfect.

But let's call the developers of all the major working C++ programs in the world and ask them what they think about it.

They all say that they know about that problems but that C++ works for them. Weird. How can that possibly be...?
Jimmy Jones
Friday, October 26, 2007
 
 
"People who get build times measured in hours."

If you're getting full rebuilds every time you make a minor change then you're doing it wrong.
Jimmy Jones
Friday, October 26, 2007
 
 
*Now, we need one for java*

Where have you been? Go to programming.reddit.com and you can just sink your teeth in the Java-hatred.

Christ, what a total waste. A huge fraction of serious applications are written in C++. I wouldn't be surprised if that stupid thing had been typed in one C++ app, uploaded through another C++ app, persisted by a third C++ app, transmitted around by 15 different C++ apps, and served, downloaded, and viewed nearly every time by C++ apps.
my name is here
Friday, October 26, 2007
 
 
This seems like something that should have been written around 1995. It's a little late now for a scathing critique of C++.
Bored Bystander Send private email
Friday, October 26, 2007
 
 
One more confirmation that there are only two kinds of programming languages: those people always complain about, and those nobody uses.
Jeff Zanooda Send private email
Friday, October 26, 2007
 
 
Use Python. Be happy.
Victor N. Send private email
Friday, October 26, 2007
 
 
Interesting. The author's position seems to be that if you care about performance you should use C instead of C++, and if you don't care about performance you should use something managed like Java or C# instead of C++.

He's got a good point about the second thing, but he's way off on the first one.

There are certainly areas of C++ that can cause performance problems compared to C, it can take some experience and care to make sure that you don't cause excessive object copying, etc...

Once you have that experience you can write equally performant code with C++.

Then at that point you get to benefit from the many mechanisms in C++ that let you re-use existing debugged code - one of the best of these is templates.

That's why Java and C# have needed to add template-type mechanisms to their own languages after starting out initially without them.
Michael G
Friday, October 26, 2007
 
 
I think it's actually rather a good document. It's always valuable to approach a programming language in a critical way, and a detector that shows you where some of the land mines are hiding is very welcome.
Mark Pearce Send private email
Friday, October 26, 2007
 
 
"I'm not impressed."

Well I sure am impressed, that is an awesome effort by that guy. Hats off to him!
Scott
Friday, October 26, 2007
 
 
>> I mean, come on. Criticizing languages is fine -- we all do it, and it's fun in moderation -- but there's a whole world outside the computer room. <<

On a surface reading, this document appears to be as much about techniques and language features to avoid as about an actual critique of C++.
Mark Pearce Send private email
Friday, October 26, 2007
 
 
I've been reading through it and it is tied for the best and most thoughtful analysis and discussion of C++ I have seen. It's like Meyers' Effective C++ books, but with much more detail and breadth.

A seminal work.
Scott
Saturday, October 27, 2007
 
 
I've got the C++ FAQ book in hardcopy and it is a THICK book which was written by hundreds of different people.

This guy has gone through it and debunked the whole thing line by line. Not just debunked, but elucidated, clarified, and pointed out the omissions and pitfalls.

How awesome is that?

Those of you who fail to completely appreciate the brilliance of this work have no business working as programmers.

You are in the presence of greatness and yet you can not even see it.
Scott
Saturday, October 27, 2007
 
 
Not to me it doesn't.  It appears to be a guy who really wanted to bash C++ and/or get lots of pageviews for whatever reason.
Fake Programmer
Saturday, October 27, 2007
 
 
@Jimmy Jones

"If you're getting full rebuilds every time you make a minor change then you're doing it wrong."

You're talking about developers. Package maintainers in a Linux distro rebuild packages from the scratch each time they change something (that's how RPM packages are made: by building from the scratch).
Roman Werpachowski Send private email
Saturday, October 27, 2007
 
 
There are a lot of good points, but also a huge amount of it is just railing about difficulties involved with programming in general. Sure, programming is difficult and there is a lot to keep in mind when doing it, that isn't surprising.

In many spots he goes on and on about how you have to have garbage collection. So any of these numerous sections can be used to rule out using the C language which doesn't have garbage collection either.

Then in other parts he extols the virtues of plain C. If you followed these parts you would rule out any type of managed environment.

Taken as a whole, he has pretty well ruled out every possible language.


I guess that he doesn't like the underlying nature of C++, that it is a compromise to add a lot of functionality but maintain a really tight integration with C.
Michael G
Saturday, October 27, 2007
 
 
As a mainstream C++ developer who actually likes the language most of the time, I'd say this is someone who seriously used C++, and came to hate it. Essentially all the criticisms of the language are valid ones rather than just the rantings of some newbie who doesn't know how to do things properly.

You can write some very nice things in C++, but it's showing its age.
Duncan Sharpe
Saturday, October 27, 2007
 
 
Yes, that's a good analysis. I think his inspiration was to realize that a FAQ is an organized list of things that people are confused about. He used this as a framework to categorize his own dissent and approached it point by point, explaining the exact design flaws that lead to people's confusion for each point. Which is simply brilliant.
Scott
Saturday, October 27, 2007
 
 
C++ has a lot of problems. Sometimes C# and Java are all you want, sometimes not. I've found that for the types of problems I'm interested in, they're not the best choice.

I really like some of the ideas behind D, too bad it probably won't take off.
to_be_defined
Saturday, October 27, 2007
 
 
"I guess that he doesn't like the underlying nature of C++, that it is a compromise to add a lot of functionality but maintain a really tight integration with C."

The designers of C++ knew this was inevitable even before they were started. One of the design goals was to keep all that legacy C code running. Read "The Design and Evolution of C++" if you want the details of why C++ is like it is.


For the pedants: Yes, there's some minor things which break compatibility but not much which can't be fixed by search/replace.
Jimmy Jones
Saturday, October 27, 2007
 
 
"C++ has a lot of problems."

But years of experience has shown how to solve most of them.

C++ is the only language I've used which has never run out of steam.

Garbage collection sounds cool but when I tried it on a serious program it was a total performance killer.

Try running your toy garbage collection benchmarks when you've got enough objects in memory to cause paging...all that scanning of the whole address space every few seconds? Not good.

Even without paging it's a performance hog. Try running your toy benchmarks with/without a million objects in memory and see what difference it makes to the performance of the garbage collector.

Neither Java nor C# do RAII properly, and in my book that rules them out as serious languages.
Jimmy Jones
Saturday, October 27, 2007
 
 
"Package maintainers in a Linux distro rebuild packages from the scratch each time they change something."

That's not the fault of C++...
Jimmy Jones
Saturday, October 27, 2007
 
 
>> But years of experience has shown how to solve most of them. <<

That's true for every language, including C# and Java. This sort of detailed critique is the accumulation of years of experience, so it moves forward the body of knowledge about C++'s problems and how to deal with them.

I find it ironic that your response to this critique of C++ and typical C++ techniques is to launch your own critique of other languages. You do realise that this isn't a zero-sum game?
Mark Pearce Send private email
Saturday, October 27, 2007
 
 
Someone here able to compare with Matthew Wilson's "Imperfect C++" ( http://tinyurl.com/36dulw ) ?
Micha Send private email
Saturday, October 27, 2007
 
 
"That's not the fault of C++..."

I never claimed it is. But it still is a problem when packaging C++ programs. And you can't really do it otherwise, because the build proven to work in "clean" environment, without older builds lying around.
Roman Werpachowski Send private email
Saturday, October 27, 2007
 
 
"I find it ironic that your response to this critique of C++ and typical C++ techniques is to launch your own critique of other languages."

They weren't randomly chosen, I'm just pointing out some major pitfalls in the languages he advocates to replace C++.
Jimmy Jones
Saturday, October 27, 2007
 
 
>> They weren't randomly chosen, I'm just pointing out some major pitfalls in the languages he advocates to replace C++. <<

You yourself pointed out that years of experience has taught us how to deal with language pitfalls.
Mark Pearce Send private email
Saturday, October 27, 2007
 
 
> You yourself pointed out that years of experience
> has taught us how to deal with language pitfalls.

A language pitfall is some particular quirk or design flaw that you avoid working yourself into in your own program's design.

Garbage collection is not like that, in everything he mentions except for D it is baked in at a fundamental level, not some kind of optional construct.

Similar to a large runtime install - there isn't any real way to just avoid these problems with years of experience when they are fundamental parts of the platform, other than using your experience to know when to avoid using the platform entirely.
Michael G
Saturday, October 27, 2007
 
 
Finally, those WTF ... but why oh why? moments start making sense!
arrested developer
Saturday, October 27, 2007
 
 
c++ is the best language there is, it's just too powerful for the average retard. even hen i do it, i make sure i only use a subset of the language.
lemon obrien Send private email
Saturday, October 27, 2007
 
 
>> Garbage collection is not like that, in everything he mentions except for D it is baked in at a fundamental level, not some kind of optional construct. <<

GC may not be a language pitfall, but it's certainly an environmental pitfall. You certainly can (and sometimes must) deal with related performance implications. If I was writing a FQA on C#, there would definitely be a section on GC.

I have about 90% of Crafty (a C++ program) converted into C#, so I had to do some serious thinking about GC. I found that the major performance issue with GC (at least from a chess point of view) was never related to pauses for search-and-sweep. It was far more about violations of locality of reference, which can be a significant issue with modern processor caching.

I also found that GC can sometimes be *faster* than manual techniques for managing memory. I haven't figured out the details yet, but I've read that the C++ allocator sometimes has to hunt for free blocks of memory in a potentially fragmented heap. The CLR usually just has to increment a pointer in a previously allocated region of memory.
Mark Pearce Send private email
Saturday, October 27, 2007
 
 
I am a C++ programmer myself, but that doesn't stop me from noticing that there are some deep issues with the language, because I have come against them and had to work around them.

By the way, Microsoft had the chance to create a killer programming language that could have blown C++ and Java out of the water, but instead they came up with Java 2.0 aka C#.

1. They should have added the option to compile C# for a VM or to natively compile it.
2. They should have given programmers the possibility to compile C# or script it(similar to Python, Perl, etc).
3. They should have given programmers the possibility to do manual memory management when needed and use GC when needed.
4. They should have added automatic variables and RAII, not the using( bla = new Bla ){} crap.

Microsoft's strategy seems to be "don't bother, the hardware will improve anyway" and it has worked pretty well for them so far. Too bad that prevents them from creating something truly excellent.

Mark Pearce> Heap fragmentation is a big problem with manual memory management, but a GC can compact the memory so it becomes a continuous block. The program completely stops during this phase, and you get a lot of cache misses.

Micha> I've read part of that book, but haven't read the FQA :) The critiques in the book are valid, and the solutions seem interesting, but there's a lot of template tricks involved.
to_be_defined
Saturday, October 27, 2007
 
 
> I also found that GC can sometimes be *faster*
> than manual techniques for managing memory.

Well I would certainly hope there would be some benefit to churning through everything in memory and moving it around!

Yes, allocation itself is really fast with compacting GC.

The biggest problem that can't be "avoided with experience" is a big overall increase in the total amount of memory that is being consumed.

There are additional more avoidable problems with GC as well so certainly just like any system if you're going to use it, it is a good idea to know the system thoroughly.
Michael G
Saturday, October 27, 2007
 
 
Way to go Lemon!  You have largely negated further discussion with such thought provoking insight as usual.  Yossi's work, subject of this thread which I am sure you read, pales in comparison.  In fact, so much so that I don't think I will need to keep an eye on http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/870d15c57e831fc5/5868fd6e57f6ae2c?hl=en#5868fd6e57f6ae2c for follow up discussion which I initially thought would prove quite interesting in comparison to the regular opinions here.

Since I am off-topic with meaningful discussion as well I will go ahead and admit Bot Berlin, I largely ignore you.  I am, admittedly, thankful you kept up with your crusade of C++ bashing over the years on JoS because this is actually a gem of a find that you shared.

Scott has been portrayed as arrogant and abrasive in other threads on JoS however:

"Those of you who fail to completely appreciate the brilliance of this work have no business working as programmers."

...Is the definitive understatement in this thread.  Until you have actually read the FQA completely with comprehension you probably shouldn't be commenting on it.  To quote Scott again,

"A seminal work." 

Accurately succinct.

A side note pertaining to the FQA:  http://yosefk.com/c++fqa/io.html#fqa-15.1 a snippet from that section:

"iostream. The only thing you'll gain from all this extra typing is extra long build cycles and error messages and extra large program image. This is what you get when you shift a file object by an integer."

Absolute gold!  I giggled about that commentary through most of the next section as I read it last night.  Great stuff, IMHO.
Chris Send private email
Saturday, October 27, 2007
 
 
> Microsoft's strategy seems to be "don't bother,
> the hardware will improve anyway" and it has
> worked pretty well for them so far.

Actually that strategy worked extremely poorly for them in the Longhorn development cycle.

They bought into this strategy big time at the beginning of Longhorn, and wrote tons of new CLR code for the OS because by the time it was going to ship they thought everyone would have 14 GHz CPUs and vast amounts of memory.

When that didn't happen, Longhorn crashed down under its own weight and they threw out a vast vast quantity of work.

Looking at Vista it seems like they may not have thrown out quite enough even.
Michael G
Saturday, October 27, 2007
 
 
I have to agree with Chris and Scott. This "FQA" is absolutely excellent. It's kind of the evil twin of "Effective C++".

However, it's still 12+ years too late and therefore is absolutely pointless except as something else to argue over. At this point, C++ is almost at legacy stage - yeah, I know that will start a new flame war similar to the "C is dead" premise. But there's not a lot of new stuff being written in C++, and yeah, I know that invites mass bombardment of the thread with YES IT IS STILL BEING USED YOU DUMBA$$ AND HERE IS WHERE...  C++ is on a declining, and not flat or ascending curve.
Bored Bystander Send private email
Saturday, October 27, 2007
 
 
The author's complaints mostly seem to be "How can absolutely avoid all the advice in the Meyers books".  Everything he says is true.  But he's typically talking about doing things that you shouldn't be doing. 

Because C, Delphi, Java, Python, Ruby, Lisp and PHP all suck too.  They've all got problems.  That's why we get paid money to do this work people.  If it was easy, if any buffoon could do it, they wouldn't pay us much to do it.
Clay Dowling Send private email
Saturday, October 27, 2007
 
 
> Everything he says is true.  But he's typically talking
> about doing things that you shouldn't be doing.

I don't agree, it is excellent. Even for C++ lovers it (re-)opens eyes for some rather annoying recent developments and even old flaws of the language.
I spent the last two hours reading the site and like it so far - even and in particular the exaggerated and polemic language.

> Because C, Delphi, Java, Python, Ruby, Lisp and PHP all suck too.

It makes sense of course, to consider how C++ sucks in his own way...
Micha Send private email
Saturday, October 27, 2007
 
 
"You yourself pointed out that years of experience has taught us how to deal with language pitfalls."

There's no way to work around the pitfalls of the garbage collector. It cannot be turned off or worked around and it can be a complete brick wall for programs which need a lot  of memory.


"allocation itself is really fast with compacting GC."

Allocation yes...but not deallocation.

C++ has zero overhead stack based objects for temporaries - no allocation or deallocation needed. In Java a single Window redraw in Java generates hundreds (or thousands) of temporary objects which will all need to be cleaned up at some point.


"Heap fragmentation is a big problem with manual memory management"

All C++ memory management is tweakable. You can have a different allocator for every single object if yiu want to. Each one can use an algorithm based on known usage patterns.

"a GC can compact the memory so it becomes a continuous block"

So can C++ - just use a smart enough pointer with a double dereference (which is actually what Java does under the hood...). With double pointers you can move objects around in memory without the main program being aware of it and because they're objects the syntax of the main program will be exactly the same as with any other smart pointer.

Abilities like this are why I say that "C++ never runs out of steam".
Jimmy Jones
Saturday, October 27, 2007
 
 
If we didn't have language designers who could show what kinds of mistakes to avoid repeating, would we still be programming in Fortran and Cobol?  Nope.  Would we still be programming in Lisp?  Nope.  Would we still be programming in assembly languages?  Nope.  We'd still be programming in each machine's raw numerical machine languages.

Yes every language is defective.  Around every 10 years we get a pretend paradigm shift and around every 30 years we get a real one.  Let's hope the next one will be meaningful.
Norman Diamond
Saturday, October 27, 2007
 
 
Howdy!

The FQA now has it's own FAQ, which is sort of stupid, but I have to deal with the kind of questions it lists:

http://yosefk.com/c++fqa/faq.html

I think it takes care of most of the criticism I've skimmed through, except for the "page views" motivation. If this persists, I'll add it to the FAQ; for now, note the lack of sponsored links at the site, and the fact that my employer has nothing to do with the FQA. A related item:

http://yosefk.com/c++fqa/faq.html#faq-12

To people who liked the thing: thanks!

BTW, you can send me criticism both of C++ and the C++ FQA, and I'll publish the best pieces (if you correct factual errors in the FQA, I'll probably leave the original text unchanged and link to your correction).

"Appropriate for 1995": there's a huge world of embedded applications, not represented very well in the blogging world. C++ only starts to penetrate it now. Also, check out SystemC.

"Get a life" people: you're writing this at a site about software, which makes it sort of self-referential.

-- Yossi Kreinin of yosefk.com/c++fqa
Yossi Kreinin Send private email
Saturday, October 27, 2007
 
 
Yossi, did you write all of that today?  That is some prolific writing.
Bot
Saturday, October 27, 2007
 
 
I was reading back over the fqa and liked this line.

"If your question is "Can I compile C code with a C++ compiler?", the answer is "no" because of numerous differences in the way code is interpreted (some things will be reported by the compiler, some will be silently misinterpreted). However, this is not a real problem, since you can compile C code with a C compiler. "

Hehe.
Bot
Saturday, October 27, 2007
 
 
> I think it takes care of most of the criticism
> I've skimmed through,

Well, as far as I can tell it doesn't seem to have taken care of mine...

I'll simplify it a bit:

There are many sections where you talk about the need to use a safe execution environment with garbage collection.

Why do you come to the conclusion that these arguments rule out the use of C++ but not C, to which they also apply?
Michael G
Sunday, October 28, 2007
 
 
Very entertaining. Even though I know little about C++, as a matter of fact, I know little about anything, it's written with style and I could read it all just like the folks who read Bibles -- a little bit at a time. :-)

Thanks all involved for making this happen, including Bot Berlin the OP! :-)

This text does represent a sign of the times as they say.
Joao Pedrosa
Sunday, October 28, 2007
 
 
To people who's criticism I didn't answer: sorry, I didn't read the discussion that carefully, just quickly skimmed through it. If you send me e-mail, your chances of getting an answer are high, definitely higher than on Web 2.0.

To Michael G:

"Why do you come to the conclusion that these arguments rule out the use of C++ but not C, to which they also apply?"

Defective C++ explicitly mentions that sometimes you have no choice but settle for unmanaged execution and manual memory management, and explains why C++ is a bad choice if that's your situation. /These/ arguments (about C++ being bad here) don't apply to C.

The first paragraph of Defective C++ talks about how the combination of the design choices in C++ makes them all problematic, while in a different context some of them can be perfectly legitimate, and uses manual memory management as an example.

To Bot: Yeah, I wrote all that in 2-3 hours, after spending an hour or so on looking at the breakdown of the flames/questions directed at the FQA... I wish I did some QA and usability testing before publishing it, but I chose the favorite path of our industry and shortened the time to market instead :)
Yossi Kreinin Send private email
Sunday, October 28, 2007
 
 
I thought this time I would certainly find enough points against C++ to make me discard the language (I've finally decided to move away from C# and Java towards C++ for the rest of my life (except for projects which make it mandatory to use Java) as far as the imperative side of my toolkit is concerned) but once again a disappointment (on cursory reading) and I am beginning to come to the conclusion that C++ really is the most 'powerful' language when it comes to programming the machine (despite its flaws).
I really don't want to be one of those guys who cite the popularity of a language to substantiate their claims for its popularity but I am tempted to ask all the language zealots that when their language starts doing the equivalent of flying the JSF-35, running the chunk of most operating systems/low level applications like KDE etc, running the most powerful trading platforms in the world, the backbone of google super-computing cluster/architecture, the run time/VM of their favourite language....basically most of what really matters; only then start criticizing C++.
It fills a unique niche in computing and if you really want to criticize it then your time is probably best spend writing some killer applications in you favourite language then making half-baked claims against other languages.
sonu
Sunday, October 28, 2007
 
 
"Defective C++ explicitly mentions that sometimes you have no choice but settle for unmanaged execution and manual memory management, and explains why C++ is a bad choice if that's your situation. /These/ arguments (about C++ being bad here) don't apply to C."

Huh?

C is a better choice for manual memory management than C++? What exactly can C do that C++ can't?
Jimmy Jones
Sunday, October 28, 2007
 
 
"I am beginning to come to the conclusion that C++ really is the most 'powerful' language"

Believe it, it's true.


"if you really want to criticize it then your time is probably best spend writing some killer applications in you favourite language then making half-baked claims against other languages."

Show us the applications! After ten years I still haven't seen a single mainstream desktop application written in Java.

(And it's not for lack of trying - plenty of people whave tried to write the "Office Killer" in Java).
Jimmy Jones
Sunday, October 28, 2007
 
 
"running the chunk of most operating systems"

Except for the Linux kernel, written in C ;-)
Roman Werpachowski Send private email
Sunday, October 28, 2007
 
 
For effects of comparison, I bring up this one. Linus created that VCS dubbed "Git" (after himself, hehe), and whenever folks ask him "what about Subversion?", he answers that Subversion started wrongly by trying to make a better CVS, so there's a lot of CVS "baggage" in it. In the same vein, Java started wrongly by trying to make a better C++, so there's a lot of C++ "baggage" in it.

Let's say a challenge between two very good programmers, one specialized in C++ and the other one in Java. They have one year to make something good just so time is not the limiting factor and the program can be slightly bigger and is not meant as a throw away. I even have problem pretending here that the Java programmer would be twice as productive as the C++ one, so if you are C++ biased, you could probably imagine the C++ programmer kicking the Java guy's butt.

For effects of comparison, the other day I learned that a couple of guys at Google wrote a new set of Collection classes for Java using the "Generics" provided by Java 5 because as the default ones didn't seem to use it enough. :-) Isn't that a little like C++ to you? Isn't Subversion a little too similar to CVS to you? :-)

The fact that Java has suffered on the Desktop actually is just more proof that we collectively haven't been able to extract the power of the Desktop for applications more than anything else. It pains me personally how difficult it is not to create a little Desktop program, but to make it manageable, easy to access, install, load, uninstall... It's as if we couldn't make use of thousands of little Desktop programs and instead had to use these big fellows consuming hundreds of megabytes per instance, sometimes called IDEs for instance. :-)

Java is not guilty of not being the holy grail for the Desktop.
Joao Pedrosa
Sunday, October 28, 2007
 
 
I think the FQA is brilliant. I have run into a lot of those deficiencies myself.

Another problem with C++ is that every programmer has his own subset. Jack does not like references and const-correctness, but he uses templates a lot. Pete does not really understand templates, but he is religious about const-correctness and not using pointers. And they have been assigned to the same team.

Those who think they can pay the price for garbage collection and a virtual machine have already gone to Java or C#. Simpler alternatives like Delphi and Visual Basic 6 are perishing.
Onno Hovers
Sunday, October 28, 2007
 
 
> Jack does not like references and const-correctness ... Pete does not really understand templates ... And they have been assigned to the same team.

So, maybe C++ should be used where:

* There's reason to use it: e.g. there's a lot of existing C++ already, and/or it's a platform (e.g. embedded or kernel) or application (e.g. real-time) that doesn't support GC languages,
* There are good C++ programmers on staff,
* Other staffers are also good C++ programmers, or mentored and willing to become good.

By the way I don't understand why you might prefer C over C++ (especialy where a compile-time flag can eliminate support for exception-handling in code where exceptions needn't be supported: because exception-handling support injects invisible object-code bloat around subroutine calls).
Christopher Wells Send private email
Sunday, October 28, 2007
 
 
C doesn't have exceptions, you say?


longjmp
Roman Werpachowski Send private email
Sunday, October 28, 2007
 
 
"Google wrote a new set of Collection classes for Java using the "Generics" provided by Java 5"

I actually invented Java generics.

Or, at least, for many months I proposed a scheme for getting rid of typecasts in comp.lang.java.advocacy, and later on the exact same scheme appeared in Java.

Is there a connection? You decide...


"Jack does not like references and const-correctness, but he uses templates a lot. Pete does not really understand templates, but he is religious about const-correctness and not using pointers."

That can happen in *any* language, not just C++.


The "sane subset" of C++ isn't hard to grasp:
* Use STL (or lookalikes) for data storage - NOT arrays
* Use smart pointers (NEVER use a raw pointer for RAII)
* Pay attention to const correctness
* Use references where possible, pointers otherwise

Even if you write procedural code you can do those things, and it will make all the difference in the world to the quality of your code.

If you add objects into the mix (even if it's just for data storage, not program logic) then all memory management becomes automatic - the compiler will write the destructors for you. You'll almost never have to write "delete", that's the big 'advantage' of Java wiped out simply by writing good code.

Stray pointers and buffer overflows will be a thing of the past when you use containers/iterators for data storage/processing. Java's other "advantage"? Also gone. Jave now has nothing left to offer.

And contrary to the FQA: If you do the above then exceptions aren't scary - that's what stack unwinding is for. The mixture of exceptions and stack unwinding is a powerful tool for not leaking memory (keeping track of error flags and freeing up temporary memory in a C program can get very messy - in C++ it can be done for you by the compiler).
Jimmy Jones
Sunday, October 28, 2007
 
 
"longjmp"

Good look sorting out all the temporary memory allocations before you can actually use it.

I mean...imagine you're in the deepest part of your file parser, calling malloc, creating strings, etc., and suddenly you get an EOF, "NO CARRIER", or whatever.

In C you're completely screwed. In C++ you just throw an exception and the memory cleanup is automatic.
Jimmy Jones
Sunday, October 28, 2007
 
 
@Jimmy

I did not mean to tout that longjmp is a merit of C. Some people bashed C++ for having exceptions, so I just wanted to show that C has a feature with similar nonlocality and need for longjmp-safety. We don't do it, because longjmp is rarely used in C.

"In C++ you just throw an exception and the memory cleanup is automatic."

Only when the exception is caught.
Roman Werpachowski Send private email
Sunday, October 28, 2007
 
 
> Defective C++ explicitly mentions that sometimes
> you have no choice but settle for unmanaged execution
> and manual memory management, and explains why C++ is
> a bad choice if that's your situation.

Sorry Yossi - I find your explanations in this area to be particularly weak and unconvincing.

For example, in your summary page http://yosefk.com/c++fqa/defective.html, at the end of the "Manual memory management" section you try to relate the creation of smart pointer classes to template metaprogramming and then continue to talk about problems with operator<<.

Creating a smart pointer class does not have anything to do with problems with operator<<, yet you have tried to give the appearance of stringing these problems together as if they were interconnected somehow.


Specifically, your arguments against the use of RAII are particularly weak.

The only thing that I can really find is that you argue that if you use a simple smart pointer class, you can't share the same object between different owners and you'll have to make a copy.

I'll forget for the moment about reference counting as the solution.

What about all the instances where you do not need to share the same object between different owners? For example when you're using a resource that is localized to a particular function? In this case with RAII you can put the resource at the site where it was created into something that will clean it up for you without you writing extra code.

What is bad about that? .... Increased compile time?  .... Seriously?
Michael G
Sunday, October 28, 2007
 
 
Hi!

After about a week of experience, I decided to avoid (most) discussions on the web. If you want to talk to me, send me e-mail; I'll publish the interesting bits, criticizing either C++ or the C++ FQA. If you want to demonstrate the superiority of your arguments under the dubious spotlight that is a flame war, you'll have to talk to someone else.

Clarification: I am very thankful to everybody who took the side of the FQA in any online discussion, especially if they didn't personally attack their opponents. That's because it's important to demonstrate that lots and lots of people dislike C++. Many people will not listen to criticism voiced by a tiny minority, and on some level they'd be right. However, I can't and shouldn't imitate "lots and lots of people"; what I want to do is to gather and publish quality material on the subject. And e-mail is a great way to do that. So stay tuned for FQA updates.

This "discussion group" in particular is apparently explicitly designed to prevent the creation of threads (no quoting, no nesting, you can't even see the previous comments when you post yours). Not a bad idea, that, considering the distribution of the signal/noise ratio in online conversations.
Yossi Kreinin Send private email
Sunday, October 28, 2007
 
 
Yossi I think you'll find *lots and lots of people* simply do not understand C++, and therefore are more than willing to bash it.

You yourself demonstrate technical knowledge of C++, but at the same time, a blissful ignorance of modern C++ idioms, as evidenced by your opposition to exceptions and RAII. They are the central tenet of writing robust error handling code, and allow C++ programmers to automate the tedious manual coding that C, C# and Java programmers have to put up with.

And BTW, nobody's stopping you from using garbage collection in C++.
FoxThree
Sunday, October 28, 2007
 
 
"Many people will not listen to criticism voiced by a tiny minority"

We'll listen if it's valid criticism, but the "FQA" isn't!

eg. The section on "Freestore management" goes on and on about the nuances of "delete", malloc() vs. new[], etc.

NOBODY should be using malloc() or new[], they should be using std::vector for all dynamic storage.

NOBODY should be using raw C pointers to control resources. Smart pointers are standard fare these days and they make all the comments about "delete" moot - you don't use "delete" with these pointers you just let them do their thing.

Garbage collectors? Not really needed when you let the compiler delete things for you but you state many times that "C++ has no garbage collection, which makes 'memory' a manually managed 'resource'" - not true, most of it can be automated (and this also makes your reasons for disliking exceptions moot as well).

So...that whole section can be scrapped. It simply doesn't apply to new C++ code.


"If you want to demonstrate the superiority of your arguments under the dubious spotlight that is a flame war, you'll have to talk to someone else."

If you go writing inflammatory untruths about C++ then you should expect some heat.

...especially when you seem to know enough C++ to know that that FQA is deceptive (or a very elaborate troll).

Why don't you dedicate all that energy and knowledge to writing about how to write clean, modern C++ which neatly avoids all those 1990's C++ problems mentioned in the FAQ?
Jimmy Jones
Sunday, October 28, 2007
 
 
Although I did defend the FQA, I like C++. When you do use the right idioms, it's very possible to overcome its drawbacks.

My own feeling is that the very idea that a program consists of a series of text files containing instructions is inherently primitive. Why can't I take multiple views of the same piece of code? Why can't the computer give me different views of an algorithm depending on which part I've selected?

Why can't I make algorithms by taking different semi-algorithms and bolting them together? Templates are only a start, and are a long way from being intuitive as a programmers interface.

Programs shouldn't be text files. They're data structures. Why should I need to care how the computer represents it? Instead I want help seeing how the parts fit together. The whole idea of writing programs which don't understand themselves at all until you compile them is primitive. The idea of writing programs that don't compile because I've left out a semi-colon or the brackets don't balance is primitive. I ought to be working at a higher level of abstraction.
Duncan Sharpe
Sunday, October 28, 2007
 
 
Mr. Kreinin:

1) About time!  I did not like C++, because I kept having to dive into details.  Most of the time, I do not care about destructors' details, but C++ forces you to deal with them regardless.

2) The FQA FAQ says:
"But you could do this to any language. Doesn't it make the whole thing meaningless?

Well, nobody did do this to other languages."

I do know of one (only one) other case.  Brian Kernighan wrote "Why Pascal Is Not My Favorite Programming Language".  I have not read your full FQA, but it appears it could be as hilarious as Mr. Kernighan's work.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Sunday, October 28, 2007
 
 
> In the same vein, Java started wrongly by trying to make
> a better C++, so there's a lot of C++ "baggage" in it.

In the same vein, C++ started wrongly by trying to make a better C, so there's a lot of C "baggage" in it.

In the same vein, C started [*] by trying to make a better assembly language, so there's a lot of assembly "baggage" in it.

In the same vein, PL/I started by trying to make a better bastard of Fortran + Cobol, so there's a lot of Fortran + Cobol "baggage" in it.

In the same vein, C# started wrongly by trying to make a better Java, so there's a lot of Java "baggage" in it.

I'm still trying to find the exception.

[* Actually this is one goal that didn't start out wrong, but later it got corrupted.  Actually this needs fixing anyway, since C started out trying to be a better B, B started out trying to be a better BCPL, and BCPL started out trying to be a better assembly language unless Bliss sneaked into the middle of that relationship.]
Norman Diamond
Sunday, October 28, 2007
 
 
> NOBODY should be using malloc() or new[], they should be
> using std::vector for all dynamic storage.

There are some pretty popular platforms that don't have STL in them.
Norman Diamond
Sunday, October 28, 2007
 
 
Hi Yossi, sorry if this seems like a "flame", but it really seems to me like you are backing out of the discussion rather than argue about the points that you seem to know are just not defensible (the parts about choosing C over C++).

Just because a simple smart pointer does not share ownership easily does not mean that RAII is not useful in a large number of other situations.

Using destructors to handle simple cleanup of resources used within a function and using templated container classes instead of C-style void* containers are some of the basic bread-and-butter advantages to C++. I cannot find any information inside the FQA for why these basic things in C++ are bad, other than adding some small amount to compile time. It is great to reduce build time when possible but I'm afraid that it is just not the highest thing on my list to optimize!

The discussion here does not seem to be excessively vitriolic, I'm surprised that you find this level of flame war to be so objectionable given the content you have written yourself.
Michael G
Sunday, October 28, 2007
 
 
"* Use STL (or lookalikes) for data storage - NOT arrays
* Use smart pointers (NEVER use a raw pointer for RAII)
* Pay attention to const correctness
* Use references where possible, pointers otherwise"

That's a funny list because I would say that the sane  subset of C++ includes the opposite of all of those.

* Do not use the STL, Boost, or any other popular template libraries
* Mind your memory.
* Avoid consts.
* Avoid references unless necessary for semantics.
Scott
Monday, October 29, 2007
 
 
"NOBODY should be using malloc() or new[], they should be using std::vector for all dynamic storage."

This feels a little awkward when what you need is a std::map, for example.
Roman Werpachowski Send private email
Monday, October 29, 2007
 
 
Gee Scott, maybe the difference has something to do with the fact that one of you uses C++ successfully...
Fox Three
Monday, October 29, 2007
 
 
Well as I've said before, my use of C++ nets me personally in the mid 7 figures because I know how to use it properly - and that is without the STL. STL bad.
Scott
Monday, October 29, 2007
 
 
I used to earn seven figures in my "pre STL" days. Now I'm pulling in eleven and it's all thanks to std::pair.
Jimmy Jones
Monday, October 29, 2007
 
 
Pfft. I'm earning fifteen digits...


in binary!
Roman Werpachowski Send private email
Monday, October 29, 2007
 
 
++Scott
Jussi Jumppanen
Monday, October 29, 2007
 
 
I see no justification for engaging in a hair splitting of details regarding the FQA nor disputing subjects point by point.  Instead I will quote a significant statement of insight that Dr. Stroustrup delivers in his book "The C++ Programming Language".

From Chapter 2 Section 2.1:

"Detailed understanding of language features - even of _all_ features of a language - cannot compensate for a lack of an overall view of the language and the fundamental techniques for using it."

This quote aptly describes my thoughts regarding the FQA.
results of my review Send private email
Tuesday, October 30, 2007
 
 
I read a Polish edition of Stroustroup's book (waaay cheaper than buying the English one) and noticed that in some places he seems to enter the defensive mode, trying to refute some criticisms of C++. Funny.
Roman Werpachowski Send private email
Tuesday, October 30, 2007
 
 
Really? I must not be paying attention.

The Design and Evolution of C++, maybe. His online writing? More so.

You have to retort to the attacks from Java fanboys :)

He is sort of right; Java is getting more complicated day by day. And finally they introduce Enums in Java 5.0!
Rick Tang
Tuesday, October 30, 2007
 
 
"Detailed understanding of language features - even of _all_ features of a language - cannot compensate for a lack of an overall view of the language and the fundamental techniques for using it."

I think this can also be applied to the "I hate OO" thread...
Jimmy Jones
Tuesday, October 30, 2007
 
 
I'm a session C++ programmer, and yet I now understand C++  even more after reading this so-called "critic" article. It's an excellent piece of work. This guy himself must be a C++ guru to write such good critics of C++. Salute!!
Joe Send private email
Friday, November 02, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz