Bjarne Stroustrup Reflects On 25 Years of C++

eldavojohn writes "Today roughly marks C++'s first release 25 years ago when about six years of Bjarne Stroustrop's life came to fruition in the now pervasive replacement language for C. It achieved ISO standardization in 1998 and its creator regularly receives accolades. Wired's short interview contains some nice anecdotes including 'If I had thought of it and had some marketing sense every computer and just about any gadget would have had a little 'C++ Inside' sticker on it' and 'I'll just note that I consider the idea of one language, one programming tool, as the one and only best tool for everyone and for every problem infantile. If someone claims to have the perfect language he is either a fool or a salesman or both.' There's some surprising revelations in here, too, as his portable computer runs Windows."

Comments

Olde Saying

[Anonymous Coward]

C++ is to C as Lung Cancer is to Lung.

Truer words have never been spoken.

Re:Olde Saying

[Anonymous Coward]

Look on the bright side, C++ keeps dilettantes and fudge-packing quiche eaters away from serious projects.

Re:Olde Saying

[greentshirt]

lol

Re:Olde Saying

[Anonymous Coward]

The funny part is, he's ultimately blaming the language for coder's problems. My guess is he just happens to be one of those guys that doesn't really grasp OO or C++. By his own damnation of C++, he's also covering just about every other language, including C. Seems to speak more poorly of Linus than the language.

that a lot of substandard programmers use it

Yes, because substandard coders use it, it means every coder is substandard. Of course.

but keep the C++ programmers out

Basically validating he doesn't understand C++, is not a C++ coder, and thinks poorly of anyone who does. So his argument is thus far, its beyond me, scares me, I've seen poor coders using it, therefore, all coders are poor. What a bunch of stupidity.

The rest follows equally dumb damnation, which at every turn, seems to stem from "I don't understand, therefore its evil".

Re:Olde Saying

[ELitwin]

Did anybody else read it initially as "the now perverted replacement language for C." besides me?

Re:Olde Saying

[pelotom]

I like this one (can't remember who said it): "C++ is an octopus made by nailing extra legs to a dog."

Re:Olde Saying

[JamesP]

And then came Java, which is C++ minus C

Hence, Java == Cancer

Re:Olde Saying

[Anonymous Coward]

The funny part is, he's ultimately blaming the language for coder's problems.

No he isn't, he's saying that good programmers avoid C++. He's far from the only knowledgable person to hold this opinion and the most telling quotes on that page are from Stroustrup himself.

Re:Olde Saying

[fbjon]

More like a big nuke missile, but with the warhead removed. It's still big, bulky, and not very nimble, but it goes exactly where you want it to go, and it doesn't blow everything up.

Re:Olde Saying

[euyis]

I read this as: like cancer, C++'s stronger and much more powerful than its old host; taking all the nutrition and grows bigger and bigger at mindblowing speed; changes (mutates) quickly and spreads to everywhere expanding its influence. Unfortunately all these things come at the expense of C and other languages.

Re:Olde Saying

[aiht]

More like a big nuke missile, but with the warhead removed. It's still big, bulky, and not very nimble, but it goes exactly where you want it to go, and it doesn't blow everything up.

Which isn't a good as it sounds, if what you are trying to do is nuke something.

Re:Olde Saying

[Anonymous Coward]

Reputed Academics have been less shy:

"C++ is an insult to the human brain" (Niklaus Wirth)

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind" (Alan Kay)

"There are only two things wrong with C++: The initial concept and the implementation" (Bertrand Meyer)

"C++: an octopus made by nailing extra legs onto a dog" (Eric S. Raymond)

"Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, 'OK, we'll do them both'. So the language is too baroque for my taste" (Donald E Knuth)

PROOF?

Compare the BOOST C++ library to htt://gwan.ch/ ANSI C scripts (footprint, reliability, performances, ease of use...)

Re:Olde Saying

[e70838]

In fact, Linus has tried to move the kernel to C++ in 1992. At that time, g++ was a piece of crap.
The lessons learned from this experience (outside the fact that g++ was unstable) is that C++ has some strong limitations when used in a kernel and that he would never use again C++.
Good C++ compilers have appeared only recently (before 2000, Comeau C++ was the single almost standard compliant compiler). Comprehension on what is good coding style in C++ is more recent. We keep many garbage from the previous era: bad libraries, bad coding style guides, ...
For people that have discovered C++ recently, Linus opinion may look exaggerated, but do not accuse him of not understanding C++. You will look very misinformed.

For some reason....

[kellyb9]

For some reason, I read that as "Bjarne Stroustrup Comments On 25 Years of C++".

// I had a reply all set to go...

Re:For some reason....

[RDW]

For some reason I (really!) thought I read 'the now perverse replacement language for C'. I was probably thinking of his earlier interview:

http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html

(about which Stroustrup is apparently Not Amused: http://www2.research.att.com/~bs/bs_faq.html#IEEE ).

Re:For some reason....

[gerddie]

For some reason I (really!) thought I read 'the now perverse replacement language for C'. I was probably thinking of his earlier interview:

http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html

Nice try, but did you also read it to the end?

Reflect?

[ciscoeng]

No, no. You're thinking of C#!

Re:Reflect?

[Monkeedude1212]

Sometimes I hate being the kind of person who gets those jokes...

You know, when you chuckle, and then the guy across the room asks, "What?". And you say "Oh, just a programming joke" and then you feel bad because it makes you sound smug about it but really you're just saving each other some time by not explaining something that they wouldn't get initially to finally resolve to a joke that wouldn't be so funny after you explain it.

I almost made a try/catch 22 joke, but I think we can all agree those have been overdone.

Re:Reflect?

[ari_j]

Ultimately, the only good try/catch 22 joke is the one about not making one.

Re:Reflect?

[Anonymous Coward]

saving each other some time by not explaining something that they wouldn't get initially to finally resolve to a joke that wouldn't be so funny after you explain it.

Or before.

Re:Reflect?

[Xiph]

Yes, but those are the Exception

Re:Reflect?

[GuldKalle]

Just say "It's a Jersey thing"

Re:Reflect?

[StikyPad]

Finally someone said it.

Let's put an end to Trying.

Re:Reflect?

[Anonymous Coward]

Ultimately, the only good try/catch 22 joke is the one about not making one.

Oh, I caught that.

the best.

[bhcompy]

My first language and I wish my only. I don't know if it is because it was my first, but it's the only one that I feel like can accomplish everything I need in a very logical and clean fashion. Java comes close because it feels close, but the extra layer of syntax pisses me off. Anyways, I remember the project in high school that I was working on when it clicked in my mind as a language I can read rather than a bunch of mumbojumbo that I had to try to interpret. Thank you, recursive merge sort project.

Re:the best.

[kellyb9]

Thank you, recursive merge sort project.

That's good and all but Bubble Sort FTW!

Re:the best.

[Anonymous Coward]

My first language and I wish my only. I don't know if it is because it was my first, but it's the only one that I feel like can accomplish everything I need in a very logical and clean fashion.

Out of the mouths of babes and sucklings...

Re:the best.

[Ethanol-fueled]

The only time a bong hit helped me better understand algorithms...

Re:the best.

[ledow]

I grew up with C and various other languages (I actually learned Z80 assembler after BASIC but before anything else) and I was forced to do Java for university despite the fact that I never attended a single "Programming in Java" lecture for two years and just downloaded the coursework and submitted it online the same day.

I can't stand C++, it's all but unreadable to me. I'm not saying that C is always readable but C++ makes it much easier to create a mess and jumping into any large C++ project is more an exercise in reading than doing (sometimes that can be a good thing, sometimes that just gets in the way of what should just be a simple fix). And in the end it's just a clever macro / preprocessor trick over C99 to turn various "objects" into sets of function pointers that get called at creation / destruction. I honestly find C++'s syntax quite hideous, and I always thought that Java did a slightly better job at it. The trouble with Java is, unfortunately, far too much verbosity for some very simple things.

I wouldn't necessarily recommend C to a beginner either but if you're intent on starting down the C++ line, you do actually have to learn 99.9% of C before you ever really understand anything "C++" in a given program. Thus it's a nice *extension* to a language but I don't like it being classed as a language in itself. It is "C with classes", after all.

It very much depends where you start, I suppose, but I'm loathe to recommend anyone to start with either C or C++ until they know they want to program and will enjoy doing it.

Re:the best.

[betterunixthanunix]

C++ was my first language too, and until I started teaching it to other people, it was my favorite. Then I saw all the things that make no sense in C++, which never tripped me up because I happened to have been using the language for so long. I also noticed that a lot of idioms and design patterns that I used to think were really cool hacks were just ways to avoid serious design flaws in the language itself.

What really killed C++ for me was when a student created a situation like this:

std::string somefunction(){}

The fact that such a thing can compile is a glaring error. A function that declares a return type should have a return statement in it, and that should be beyond question. In C, failing to actually return will cause you to have corrupt data; in C++, it can cause a crash, when a temporary object that was never created is destroyed (and happens to have a virtual destructor, which is common).

It is true, there is no on right language, but on the flip side, there certainly are languages that should be avoided if possible, and I would say that C++ is one of them. I understand that there is a lot of legacy code and that using C++ is often unavoidable, and I have found myself in that situation, but if I were starting a new project with a fresh codebase, C++ would be pretty far down the list of languages that I would consider.

Re:the best.

[Monkeedude1212]

My first language and I wish my only. I don't know if it is because it was my first, but it's the only one that I feel like can accomplish everything I need in a very logical and clean fashion.

I think its that way with everyone's first language.

I just hate that my first language was VB, because after doing years of C++ and finally getting used to it, it comes back to haunt me when I'm the only one on the team comfortable enough with VB to go through the old VB6 code and figure out why Invoicer A can run functions that will break for Invoicer B.

Well, I'm not the ONLY one who can, but once you get that label as "The guy who is better at it" all that stuff gets dumped on you. You know how it goes.

Re:the best.

[Jorl17]

I was thirteen when I learned how to program. I jumped right into C++ and never looked back. Only later did I dive deeper in the machine with Assembly. Learning Assembly was on par with learning C itself. For me, "C itself" are the lower-level components that C++ programmers can easily avoid. These days I pick C++ when I can, but I do just fine with C. I only miss templates and operator/function overloading, because I can create most of the rest given some time (even polymorphism can be done to a certain degree). C has the advantage of avoiding implicit constructors and destructors.

Sometimes, though, it's just simpler to go with Python, Ruby or (death coming) Perl. But I think that *real* projects use either C or C++. I do not go deep into C# and all other shitty C-ish things. They may be conquering the market, but I curse the fucktards who started using it and promoting it.

Re:the best.

[cheekyjohnson]

"but I'm loathe to recommend anyone to start with either C or C++"

I see this said often, but I don't really agree with it. While it's great to know other programming languages, learning a completely different language for the sole purpose of getting used to programming in general instead of just learning the language you want to learn seems like a waste of time. Learning that other language probably isn't going to help you learn the syntax of the language you really want to learn. I tried learning other languages, as people often suggest, but in the end it didn't really help me 'get' C++ more. From that point on I merely studied C++, because I feel that that's the best thing to do.

Re:the best.

[betterunixthanunix]

I think that *real* projects use either C or C++

Well, there is this:

http://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool

I would certainly call that a "real project." Really, C and C++ are pretty terrible programming languages, with C++ being a bit worse than C, and I say that as someone who also started programming in middle school using C++.

Re:the best.

[Anonymous Coward]

> I also noticed that a lot of idioms and design patterns that I used to think were really cool hacks were just ways to avoid serious design flaws in the language itself.

Yes, C++ is full of those, and I think people are blind to them because they've never learnt anything better. If the only tool you've ever used is a hammer, you won't understand that there's a radial arm saw that's a much better tool for certain kinds of tasks.

Re:the best.

[zombieChan51]

But I think that *real* projects use either C or C++.

That is a terrible way to view the world. I've worked on several *real* projects that were not written in C or C++. Hell there's quite a bit of popular software out there used in the real world that were not written in C or C++.

Re:the best.

[The Moof]

std::string somefunction(){}

The fact that such a thing can compile is a glaring error.

Here's something interesting: Visual Studio wouldn't compile it for me (error C4716, complains about no return value, as you had expected), but it compiled on my FreeBSD box without any complaints. Perhaps this is more of a compiler problem than a C++ problem.

Re:the best.

[smallfries]

Basic, Z80 assembler and Java for university. I sense another 80s child in the room. Put down your copy of Devpac and back away from the keyboard slowly...

Re:the best.

[Anonymous Coward]

C is an excellent language when it's used for the purpose it was designed for.

C++ was not designed for any one specific purpose, and so it's never a good language. Occasionally it's the least bad of all the options available.

Re:the best.

[91degrees]

Is that legal C++? I'm sure any compiler I've used would give an error there.

Re:the best.

[betterunixthanunix]

Actually, if you look at the standard, it is not defined. The standard says what a return statement does, and it was what a function declaration should mean, but it says nothing about functions that have a non-void return type being required to have a return statement in the function body. The fact that Visual C++ won't compile that code means that (1) Visual C++ implements a language that is not exactly C++ and (2) Visual C++ corrects an error in the C++ standard. On the other hand, g++ does not try to correct errors in the standard; in fact, on at least one occasion, they have relied on omissions to justify changes to their implementation of the STL (specifically, they changed the implicit include structure, which is not defined in the standard, and which caused a lot of code to break; the right way to do things in C++ is to explicitly include all headers and never rely on implicit includes, but there are certain common implicit include structures that people have come to rely on, like fstream implicitly including iostream).

Re:the best.

[Moridineas]

I think I would be tempted to agree that this should be an error, not a warning, but if you use the -Wall flag it's caught.

Re:the best.

[Anonymous Coward]

What really killed C++ for me was when a student created a situation like this:

std::string somefunction(){}

The fact that such a thing can compile is a glaring error. A function that declares a return type should have a return statement in it, and that should be beyond question.

Uhhh.... Sorry to break this to you since you "taught" C++. That function doesn't compile. Maybe next time learn the language you are teaching.
"error C4716: 'somefunction' : must return a value"

Also you don't seem to know what you are talking about. C++ is a fine language and it has its place. Depending on the *type* of project with a fresh code base C++ might or might not be appropriate. Based on your whole post and the glaring bias and inaccuracies I don't think you should comment on anything software related.

Re:the best.

[betterunixthanunix]

Try it with g++:

% cat blah.cpp
#include <string>

std::string func(){}
% g++ blah.cpp -c
%

Or, look at the standard, which is what I did when I first saw this bizarre bug, and yes, the standard says nothing about that code failing to compile (the standard defines errors, not warnings, although at the default warning level, g++ doesn't even warn about that one).

Re:the best.

[Chris Burke]

Uh g++ catches that error for me. Though on the other hand, I consider -Wall -Werror to be basically non-optional arguments.

Re:the best.

[betterunixthanunix]

Except that:

1. The standard says nothing about warnings, only errors
2. The fact that you asked g++ to consider warnings as errors means that you are asking g++ to only accept a subset of C++

Re:the best.

[Fnkmaster]

You should try out D. It's the power of C or C++ with the readability of something like Java or Python, sans Java's forced verbosity (or virtual machine considerations).

It supports templates and operator overloading, but it's got garbage collection (which you can control in a fairly fine-grained way if you want).

You can use C libraries fairly easily, and apparently link with C++ code if you want. You can also export stuff via extern C {} that can be called from standard C code.

I don't have tons of experience with the standard library stuff in D and have just done some toy work in it, but it seems really nice to me.

I learned C++ ages ago when it was relatively new, and I didn't know any better at the time. These days I just hate it. Mostly reading code that other people wrote in it - my own code I can handle.

Re:the best.

[Chris Burke]

Except what? It means g++ is essentially doing the same thing as Visual C++ -- fixing problems with the standard in logical ways. The subset of C++ where you can't have a non-void function not explicitly return anything is a good subset of C++.

Obviously I'm taking it as given that the C++ standard has flaws. :)

Re:the best.

[Anonymous Coward]

Yes indeed, someone who compiles without /Wall or /W4 can't really be called a C++ programmer... they're relying on obscurity for correct program behavior.

Re:the best.

[Anonymous Coward]

Any C or C++ compiler that doesn't flag that as an error is broken. End of story.

Re:the best.

[Anonymous Coward]

on the other end

std::string somefuntion(){
exit(0);
return someshit;
}

never returns and shouldn't need a return statement.

Re:the best.

[Anonymous Coward]

I hear you smoke a mean pole? Can we meet up at the glory hole later tonight?

Re:the best.

[martyw]

C++ is about freedom, features and performace. That is what makes it special and what matters in producion environments.

Objective, generic, functional -- its all there and accompained with the best preprocessor, macros and code generators by leading Intel, Microsoft, AMD and even Apple C++ compilers, but again the most important thing is that nothing is really forced upon you. No "automatic memory manager" or other "nany" and "dumb things down" features that create artificial limits, slow execution, unpredictable behavious and most importantly do not restricts you to somebody's elses narrow minded coding practices.

Re:the best.

[Sancho]

The fact that Visual C++ won't compile that code means that (1) Visual C++ implements a language that is not exactly C++

I don't understand. If the behavior is undefined, doesn't that mean that it's up to the compiler to decide what to do in those cases? That doesn't mean that VC++ implements a language that is not exactly C++, it means that it chose to throw an error when this particular undefined behavior occurs. A compiler which doesn't throw that error is still deciding how to handle behavior undefined by the standard.

Re:the best.

[ultranova]

While it's great to know other programming languages, learning a completely different language for the sole purpose of getting used to programming in general instead of just learning the language you want to learn seems like a waste of time.

If you're new to programming, start with line-number Basic. When you start inventing weird workarounds for the weaknesses of that language - namely, the lack of stack - graduate to C and the world of Block Programming. When that starts seeming small to you, graduate to C++/Java.

The thing is, each and every programming paradigm has been invented to solve problems. You can't really understand it if you don't understand the problem(s) it was invented to solve, and those problems are really only apparent once you push the language to its limits and try make up your own ways to escape them.

And hey, who knows, maybe you'll invent something better.

Re:the best.

[Anonymous Coward]

Omission doesn't imply forbidded, otherwise there would be no purpose for non-model compiler implementations.

Re:the best.

[scamper_22]

Actually, if that is all C++ was, it would be a great language.
We will always need a systems level language.

What screws up C++ is when it tries to be more than 'C with classes'

While I am no stranger to the STL, templates, copy constructors, operator overloading... I try and avoid many of these as it creates too many bugs otherwise. I mean I'll use the premade STL containers. But I avoid going any deeper than superficially using them. Not because I can't... but just because it is so error prone and confuses everyone that reads it.

I think we will pretty much end up there. C with classes being the glue and systems layer. Java/.NET/whatever else for application level programming where you actually want to make good use of OO language contructs or generics...

Re:the best.

[HonIsCool]

What you are saying is not correct. The C++ standard says:

"6.6.3 The return statement
[...]
A return statement without an expression can be used only in functions that do not return a value, that is, a function with the return type void, a constructor (12.1), or a destructor (12.4).
[...]
Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function."

It is perfectly legal for a compiler to issue a warning for this or even an error. I consider a compiler refusing to compile it a superior compiler.

Re:the best.

[Anonymous Coward]

well and what do you do with something like this :

string function(){if(true){return new string("");}else{}}

Now replace, "true" by some non-trivial tautology. The code is legal but the compiler can't know. Should it issue a warning or an error ?

The point is, what you really want here is strong static typing, that enables this sort a feature. But requiring that "the-example-given-above" should not compile just makes no sense as your requirement is completely ill defined as to which programs should not compile.

Try a real language one of these day, you'll be enlightened (hint : try Haskell or OCaml).

Re:the best.

[david_thornley]

It's glaringly obvious that you don't know C++. You claim it's necessary to know almost all of C first, and that it's just C with Classes (the name of Stroustrup's original idea). Get a modern book to learn C++ (Stroustrup wrote one, there's others), and you'll just sail over a lot of C without touching it, and you'll be using many things that aren't classes. Nor is C++ a clever trick over C99. Stroustrup started with pre-standard C (and C++ inspired some of the standard), and C99 has moved away from C++.

I will agree that it's not a particularly good language for a beginner, and that some of the syntax is ugly.

Re:the best.

[Anonymous Coward]

it's all but unreadable to me.

It stands to reason that you would hate a language that is "all but unreadable" to you. However, there are a great many competent programmers who find it very readable.

C++ requires more skill to write properly (and to read and understand) than, say Visual Basic. But it also gives you a lot more control, greater resource efficiency, and problem-solving options that VB can never provide.

People who really aren't any good at programming, but think they are, can usually get stuff more-or-less working in VB (though they never get it working well). Such people can't even touch C++.

On the other hand, truly talented developers can work miracles with C++, and will always select it over VB when it is the right tool for the problem (which isn't always, of course, but is often enough).

Re:the best.

[betterunixthanunix]

It means that the code should compile but that the standard does not specify what exactly the program will do. This is something that is supposed to be reserved for situations where there is no good way to define what should happen, usually because factors that are beyond the scope of the standard can influence the behavior of the program. A good example is modifying a static string -- C++ is not intended for development only on platforms where such behavior is not allowed, nor is it intended for development only on platforms where such behavior is allowed, and there is no good way to define what the compiler should do when it sees such code (in fact, it is very easy for such a situation to arise without the compiler being able to detect it at all, if you pass pointers around a lot).

In this case, though, there is a proper definition: a function that is declared to return something should have a return statement, and nothing else makes sense.

Re:the best.

[betterunixthanunix]

Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function."

1. Undefined behavior does not mean that a compiler is supposed to stop with an error. In fact, it means that the compiler should accept the code, but that the standard does not mandate any particular behavior in the code that is generated.
2. This is not equivalent to saying that a function which declares a non-void return type must have at least one return statement.

Re:the best.

[Sancho]

I'm just going off of the definition of undefined behavior from the standard:

1.3.13 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [ Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a trans- lation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefinedbehavior;theyarerequiredtobediagnosed. —endnote]

Emphasis is mine.

Unless you weren't using the standard's definition of "undefined behavior", in which case please let me know, but feel free to otherwise ignore my question.

Re:the best.

[Anonymous Coward]

std::string somefunction(){}

Goes against the standard and should not compile. Do not blame the language for problems with your non-standards compliant compiler that probably inserted an implied return statement for you.

Re:the best.

[oneofthose]

How is this not beautiful:

template<class S1, class S2> struct cartesian_product_types
{
  template<class V, class S, class State>
  struct inner
  {
    typedef typename boost::mpl::fold<S
   , State
   , boost::mpl::push_back< boost::mpl::_1
              , std::pair<V
                     ,boost::mpl::_2
                     >
              >
   >::type type;
  };

  typedef typename boost::mpl::fold<S1
   , boost::mpl::vector<>
   , inner<boost::mpl::_2, S2, boost::mpl::_1>
   >::type type;
};

But seriously, I think the language is amazing. The fact that they built a turing-complete language inside the template engine essentially by accident (thus allowing meta programming and modern C++), the fact that by now we can write simple compile time compilers (see boost proto) and the fact that you can so radically change the syntax of the language that you can basically make it look like anything you want should convince someone who spends some time with a C++ compiler and a couple of Boost libraries of this fact.

Re:the best.

[Anonymous Coward]

That won't compile because you fail at C++.

Re:the best.

[HonIsCool]

1. Undefined behavior does not mean that a compiler is supposed to stop with an error. In fact, it means that the compiler should accept the code, but that the standard does not mandate any particular behavior in the code that is generated.
2. This is not equivalent to saying that a function which declares a non-void return type must have at least one return statement.

A compiler is certainly not required to stop with an error, but it is perfectly legal for it to do so:

"1.3.12 undefined behavior
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."

Perhaps you are thinking of unspecified behaviour?

Re:the best.

[David Greene]

Do you have some examples?

Re:the best.

[Anonymous Coward]

This exactly what the problem is. A relatively simple situation generates a long discussion of what the standard says and how compilers should implement the standard. Even a slightly more complex example can generate days of heated debate. And such debates are of absolutely no help in creating useful software.

Re:the best.

[Jorl17]

Yes, I am terrible.

Ha, Ha, Ha.

Now, shall we take this outside? Oh wait, this is slashdot, nobody cares.

Re:the best.

[Anonymous Coward]

First, turn on all warnings

Second, treat all warnings as errors

Third, if your compiler doesn't AT LEAST warn about this, get a better compiler

Re:the best.

[betterunixthanunix]

My apologies, I seem to have missed the definition of "undefined behavior." Still, the fact that a function can be declared to return a non-void type but reach the end of its body without a return statement is pretty bad...

Re:the best.

[Pinball Wizard]

FTW?

Maybe, if you're in a contest to find the slowest sorting algorithm. :)

Re:the best.

[betterunixthanunix]

auto_ptr comes to mind...

Re:the best.

[LSD-25]

What really killed C++ for me was when a student created a situation like this:

std::string somefunction(){}

The fact that such a thing can compile is a glaring error. A function that declares a return type should have a return statement in it, and that should be beyond question. In C, failing to actually return will cause you to have corrupt data; in C++, it can cause a crash, when a temporary object that was never created is destroyed (and happens to have a virtual destructor, which is common).

Corrupt data can just as easily crash a C program. Suppose the function should allocate and return a nul-terminated string, but it falls off the end:

char * somefunction()
{
}

// ...
char *s = somefunction()
printf("%s\n", s);
free(s);

Re:the best.

[The Moof]

This got me to pull my C++ book (Stroustrup's) off of the bookshelf and looked this up as well. The book also says that it should throw an error. Admittedly, I've never thumbed through the specification and relied on the books (this one and others) to get it right for me. Go figure that his own book isn't even 100% right on this subject...

Re:the best.

[GreatBunzinni]

C++ was my first language too, and until I started teaching it to other people, it was my favorite. Then I saw all the things that make no sense in C++, which never tripped me up because I happened to have been using the language for so long. I also noticed that a lot of idioms and design patterns that I used to think were really cool hacks were just ways to avoid serious design flaws in the language itself.

What really killed C++ for me was when a student created a situation like this:

std::string somefunction(){}

The fact that such a thing can compile is a glaring error.

If you had invested enough time to learn the language well enough to get to a position that you are competent enough to teach others how to use it then you would know that that is indeed a glaring error. For example, if you take the time to check out ISO IEC-14882 (i.e., the international standard which defines the C++ programming language) you will eventually stumble on section 6.6.3 - the return statement. In that section you can read the following definition:

Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.

If you also aren't familiar with the concept of "undefined behavior", then you can read up regarding that on section 1.3.12 - undefined behavior, where you can find the following quote:

behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or with-
out the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

So you see, what you tried to define as "not making sense in C++" is nothing more than ignorance of the language associated with the use of a compiler which fails to work well in this particular scenario. The standards may be a bit permissive in not declaring this to be illegal but the only parties dropping the ball are the ones in charge of specific compiler projects and/or ignorant users who fail to understand both this basic aspect and how to properly configure their compiler of choice.

Re:the best.

[Anonymous Coward]

Your reading comprehension is not working. Please reread that after looking at the definitions of the words you assume to know. You are also not an arbiter of the C++ standards.

Re:the best.

[Matheus]

My first language was C++ taught to me by a C developer. From talking to my peers in other classes/schools it became very clear early on that aside from basic OO we really didn't learn much ++. That being said the language that gave me that "I get it" feeling was actually Java. I'm not saying Java doesn't have it's issues (especially back then w/ Java 1.0) but WAY too often with C++ I would write an algorithm that was syntactically correct only to find out that due to some issue in the compiler or some quirk in the language it wouldn't work. With Java, when I reason out an algorithm it actually does what I think it should do.

These days I write code in whatever language is called for by the project at hand. When given a choice I tend to write Java but that's more of a comfort level than anything... someday I'll have some spare time to revisit C++ and see how much it has changed / I have changed.

Re:the best.

[Bengie]

C# itself isn't bad, but how many people use/abuse certain features of the language.

It's like me saying that C is a horrible language and ASM is better.

Each language has it's strong points. C#, like Java, allows for quick development and also very complex code that is strict yet flexible all the while being clean and easy to read.

C is great when you got time to develop and test and lots of documentation, but the abstract nature of Object oriented languages allows code to read more like pseudo-code which makes it easier for others to jump in.

I'm not saying that everyone codes well in OO languages, but I know the code I write is very easy to debug, very complex, easy to add features, and other programmers find it easy to follow.

I do miss programming in C/C++ though.

Re:the best.

[thegrassyknowl]

string function(){if(true){return string("");}else{}}

In your case here the compiler can easily tell that program flow will NEVER reach the end of the function. It (hopefully) won't even emit machine instructions to test true == true except with optimization completely disabled.

Regardless of the complexity of the conditional the compiler may or may not be able to make the call for you. If it can't decide it should definitely emit a warning. I know that GCC/G++ does with warnings enabled. The standard doesn't explicitly make this case an error so the compiler has no place emitting an error.

Also, in the case of this particular function, string has a default constructor so it's perfectly possible to return without actually instantiating a return value. The compiler knows how to give you the default one (even if that's not what you intended).

string *function() { if (true) return new string(""); else {} }

This case is much more dangerous because the compiler doesn't know how to instantiate a pointer type - there's no default constructor for it. You might get zero (and a corresponding segfault later) or you might get random jibberish that points into allocated memory (and probably crash because it's not a string type there). Who knows, you might fluke it and actually get a pointer to an existing string and not even know that you fucked up royally until weeks down the track. G++ doesn't warn you about this because it knows you'll never return uninitialized values. Change "true" to (a>10) and pass a to the function - G++ still won't warn you without enabling -Wall.

The moral of this story is always compile with warnings enabled and always fix the warnings where possible.

Re:the best.

[thegrassyknowl]

Uhhh.... Sorry to break this to you since you "taught" C++. That function doesn't compile. Maybe next time learn the language you are teaching.
"error C4716: 'somefunction' : must return a value"

I hate to break it to you, chump, but quoting only MSVC's error for this doesn't mean it compiles. It means that it fails to compile on MSVC. G++ certainly will compile that example just fine. It will warn you about it only if you turn on -Wall.

The standard left the behaviour in this case undefined and it's up to the compiler vendor what to do. Microsoft chose to default to an error. The G++ team decided to allow it and not even warn by default. Curiously, you will probably find that the default option set by the MSVC GUI explicitly enables all warnings. Try poking about and making sure that the default compiler warning level is set and not everything. You may find it compiles even on MSVC.

Re:the best.

[GreatBunzinni]

You are wrong. The C++ standard does cover the case of "flowing off the end of a function" without specifying a return value. It states that quite clearly in section 6.6.3 - the return statement. The thing is, as defining this scenario as "undefined behaviour" they are doing nothing more than giving compiler writer's leeway to implement whatever trick they believe to be correct, including the obvious behaviour of simply declaring this to be an error. The fact that Visual C++ refuses to compile that code means that a) Visual C++ does in fact follow the standard in this issue and b) Visual C++ implements the most reasonable, expected behaviour from any undefined behaviour: declaring an error.

So, you may wish to bash Visual C++ for failing to follow the C++ standards but in this case you simply don't have any standing and in fact you should complement it for doing the right thing.

Re:the best.

[GreatBunzinni]

well and what do you do with something like this :

string function(){if(true){return new string("");}else{}}

Now replace, "true" by some non-trivial tautology. The code is legal but the compiler can't know. Should it issue a warning or an error ?

That code is only legal C++ if it is possible to implicitly convert "true" (or any other type, for that matter) to that function's return type. Even then, that code consists, according to the standard, of undefined behaviour, which can and should be interpreted as a compiler error. Incidentally, that's exactly what compilers do.

Nonetheless, whoever writes code like that either has a very good reason to do so or doesn't know what he is doing.

Re:the best.

[Xtifr]

...the slowest sorting algorithm

Bubble sort's not even close. The shuffle sort beats it hands down:

do {
    random_shuffle(container);
} while (!sorted(container));

The initial shuffle helps avoid good performance even when the data is pre-sorted. :)

Re:the best.

[Jorl17]

Exactly, I agree about the abstract nature of Object oriented languages. In fact: http://cboard.cprogramming.com/c-programming/130159-why-so-many-typedefs-same-thing.html#post971331

I, however, am against most of the companies that support and force others to endorse C# and its evil friends. Call me fundamentalist -- it's what I call myself -- but Human Rights apologists were also called fundamentalists when it all started.

Re:the best.

[Anonymous Coward]

The thing is, each and every programming paradigm has been invented to solve problems.

Sometimes that problem is the shortcomings of the programmer rather than a problem with the other paradigms.

Re:the best.

[Gadget_Guy]

What really killed C++ for me was when a student created a situation like this:

std::string somefunction(){}

After all that discussion about whether it really is a problem with the language specification, I have to say that this example is the lamest reason to damn an entire programming language. It is like damning staplers because they shoot staples into your face when you hold it backwards. Here's a tip: don't do that.

Re:the best.

[David Greene]

While I am no stranger to the STL, templates, copy constructors, operator overloading... I try and avoid many of these as it creates too many bugs otherwise. I mean I'll use the premade STL containers. But I avoid going any deeper than superficially using them. Not because I can't... but just because it is so error prone and confuses everyone that reads it.

That's unfortunate because those tools really make it easy to write portable, safe, fast code. Techniques like RAII are indispensable. Yes, SFINAE is arcane but that really should only be used by library authors. All of the C++ features are there for a reason. They weren't just added willy-nilly. Ok, "export" but that's deprecated now. Everyone makes mistakes. :)

Re:the best.

[TranceThrust]

In case of gcc, consider using -Wall and it will pick up on such things. Apparently it's somehow just not really forbidden by the standard. Also realise that C++, for all its OO-ness, still is a language built to give the programmer ample low-level power. With all the ugliness and weirdness that may come from it.

Re:the best.

[Anonymous Coward]

In your case here the compiler can easily tell that program flow will NEVER reach the end of the function. It (hopefully) won't even emit machine instructions to test true == true except with optimization completely disabled.

I fear that you really missed the point of my previous post. The standard can't goes : any program that the static anaylisis of the compiler can't proove to be correct must result in a warning/error. Because then what you have is some code which compilation will heavily depends on the compiler used. That would suck. And the standard won't go into the detail of what analysis should be performed, because it would be outdated in no time.

So yes, your conclusion is true (one should fix the warning). But using good tools which won't produce a load of warning when there is no reason to do so is way better as the programmer will have more insensitives to fix the few warning that remain.

Re:the best.

[David Greene]

Well, auto_ptr is a library construct, not a language concept. I could point to scanf as an equally disgusting thing in C. Lots of standard libraries go through iterations. Look at Java.

Even so, I'll agree that auto_ptr didn't work out. But we've learned and C++ has moved beyond it. auto_ptr is deprecated in C++0x. Move semantics are nice.

Any language features to name? I'm genuinely curious. I always like to learn something I didn't grok before.

Re:the best.

[orezbus]

And in the end it's just a clever macro / preprocessor trick over C99 to turn various "objects" into sets of function pointers that get called at creation / destruction.

Wow - it must be an awful lot of fun debugging your code!

Re:the best.

[mattack2]

I can't stand C++, it's all but unreadable to me.

That's funny, because I think it's largely readable _because_ of the syntax. At least the way I look at it is "use the struct syntax for objects", which seems like a perfectly reasonable way to graft object orientedness onto a language.

Don't get me wrong, I actually prefer straight C, and learned C++ before templates, so don't actually know the syntax for those. But make it look a lot like regular C, or completely different? I choose "a lot like".

Re:the best.

[scamper_22]

Yeah... it's just that in a modern context, any time you would want to use the advanced features of c++, you're probably writing something more 'application' like that would be better written as .NET, Java.. which does all these things much cleaner and better.

Re:the best.

[mattack2]

The thing is, each and every programming paradigm has been invented to solve problems. You can't really understand it if you don't understand the problem(s) it was invented to solve, and those problems are really only apparent once you push the language to its limits and try make up your own ways to escape them.

Then can you explain the problems that Perl, Python, and Ruby were invented to solve? It seems strange to have so many different scripting languages that _seem_ very similar.

Yet I've used both Perl & Python. I learned the latter largely because it's used by some internal tools at work, so I thought I'd probably have to use it eventually. (I still disagree with the indentation=scope, but I like most of the syntax compared to Perl. It still _seems_ to me very similar to Perl functionality-wise, which is why I asked the question.)

Re:the best.

[betterunixthanunix]

Well, More Effective C++ lists the following three things (Effective C++ has more, but I loaned out my copy):

1. Overloading operator&&, operator||, or operator, (regarding operator, -- I have seen a single case where this was overloaded in a constructive and useful manner, the Boost Lambda Expression Library)
2. Propagating exceptions out of a destructors (can result in a crash)
3. Exception specifications (Meyers says to use them "judiciously")

Another one that comes to mind is overloading a function to take either an int or a pointer (because if you pass 0 as a null pointer, what happens? This might have been in Effective C++).

Re:the best.

[Mongoose Disciple]

I, however, am against most of the companies that support and force others to endorse C# and its evil friends. Call me fundamentalist -- it's what I call myself -- but Human Rights apologists were also called fundamentalists when it all started.

It's probable this loses something in translation, but this makes you sound less fundamentalist and more like somebody's special-needs cousin who hates the color blue for some reason.

Re:the best.

[b4dc0d3r]

That's exactly how I learned, and probably a lot of the pro coders. I started with GW-Basic, turbo pascal, visual basic, then hit a wall. Why won't my crc-32 work quickly? Use a .dll in C. So I learned C, and had some polymorphic class type stuff happening.

Then I decided to learn C++. Bloat I thought, but I basically used C syntax with a few C++ things like new. Then I had a reason to use polymorphism, and I have to say it made the code clean. I learned a lot by looking at various open source code bits, and there is a big difference between well-organized code and poorly organized. Without an intelligent IDE like MSVS 2005, where you can say "find definition" or "find references", C++ can be so poorly laid out that it's incomprehensible. But the compiler can figure it out.

At the same time I learned C++, I also regressed into x86 assembly and some 6502 as well. Now, when I debug poor C# or SQL performance, people are amazed that I can figure out where the bottlenecks are without even profiling or running the app. Knowing the language helps, but knowing what the computer has to do under the hood is priceless. You don't know the exact algorithm, but you know enough. When you see something like SqlCommandBuilder that magically knows the insert or update or delete commands for each table, you have to be able to know not to use it if you need performance. IF that's not obvious then you should really go back to the basics and unlearn.

Like when Java came out and everyone called it slow and bloated. Sure it was on some machines, but a lot of it was inefficient string concatenation. Using strings and putting them together instead of using StringBuilder or whatever it's called. Each append required allocation, copy, copy, and a free or two. The language could have helped clarify the intended usage, and examples could have been better, but lots of people don't learn the right way.

I see way too many posts on forums when I'm searching for information on poorly documented language features that indicate people don't read a single book or have any formal study of the language. They just start copying things they see, and re-use it because it worked last time. And it's even worse now, there are snippets everywhere on how to do things and no explanation on why, or what not to do. If I ever get to be a hiring interviewer, I'm going to have some very basic questions, not a programming exercise. Things like give me an example where a struct would be a better choice and where a class would be better. And for advanced positions, how to write a polymorphic class in C. Top-tier would have to modify the behavior of a program, without having the source code. Replacing me would require doing it without altering the binary.

In short, learn how the damned thing works and any language will be decent. More importantly, you can decide which one is most appropriate.

Re:the best.

[Anonymous Coward]

I used to think that way but of late my love affair has begun to wane. I guess I've reached a point where I understand it well enough (not fully, but well enough) that I'm starting to see the flaws, hacks and patches. Everything from small things like not being able to overload [] to things that have caused me pain like return value optimisation and not being able to declare template friend functions. Sure there are ways through but they also feel like hacks. Also the coding style of many C++ programmers makes my teeth hurt.

Re:the best.

[David Greene]

Generic programming. Nothing currently tops C++ for that.

Re:the best.

[David Greene]

Thanks, this could be an interesting discussion.

Overloading operator&&, operator||, or operator,

You said it yourself: lambda-like libraries. Phoenix and especially Proto are great examples. && and || are problematic because of the short-circuiting expectation but still, never say never.

Propagating exceptions out of a destructors (can result in a crash)

Yep. It's one of those "shoot yourself in the foot" moments. Of course, there's no way for a compiler to verify nothing in a destructor throws, so we'd have to get rid of exceptions, not what I'd want to do.

Exception specifications

Agreed. Fixed in C++0x. Learning from our mistakes is good. :)

Another one that comes to mind is overloading a function to take either an int or a pointer (because if you pass 0 as a null pointer

Also fixed in C++0x. Certainly C++ is not perfect. I'm glad the committee is still open to learning and making major language changes. The world is very different today than when C++ was first standardized.

Re:the best.

[Anonymous Coward]

Damn, your shop is stuck in the 1990's

Ok, ok, so I am a C#/ASP.NET guy who occasionally gets pulled into VB.NET and (gasp!) VB6

Re:the best.

[lgw]

I've seen several real world cases where bubble-sort was the best and fastest answer. Best because it was hand-coded assembly with a multi-decade maintenance lifetime, so complexity is bad. Fastest because the data was almost always sorted at input, so you were mostly just validating that.

Re:the best.

[lgw]

That's not an algorithm (alogrithms must terminate). Now if you did next_permutation(contianer), you'd have something!

Re:the best.

[lgw]

C++ is just C without memory leaks. You can use any language to write bad code, and many people think C++ is "C with Classes" and go on to make a mess of it, but it's the ability to have only one line of code in your entire project which frees resources (and then be quite sure that one line has no bugs) which makes it great. Resource management is a constant PITA with C, but it's even less of a worry in C++ done right than it is in C# or Java (unless you genuinely need a non-trivial dynamic cyclic data structure, but somehow that's never come up for me).

Re:the best.

[lgw]

"Advanced features" like adding two strings with the "+" operator? I think I'll keep doing that, thanks, along with using vectors and strings to avoid buffer overruns, and std::sort() to avoid writing my on. I've done "systems" programming for nearly 20 years, starting with assembly, and C++ lets me do what I need to without a lot of the error-prone tedium that C forced on me.

Re:the best.

[lgw]

I would expect the specific error "not all paths return a value". Goodness knows I've seen that error enough.

Re:the best.

[pizzach]

I usually find bubblesort works best on preorganized arrays personally.

Re:the best.

[Anonymous Coward]

Overloading operator&&, operator||, or operator, (regarding operator, -- I have seen a single case where this was overloaded in a constructive and useful manner, the Boost Lambda Expression Library)

At first glance these don't seem necessary, until they are. Then it's like complaining that Lisp allows you to define your own grammars. For example, see Boost.Spirit.

Propagating exceptions out of a destructors (can result in a crash)

This is a "nested exception" runtime problem during unwinding which is already correctly handled by aborting the program. The compiler can't very well predict and prevent this scenario.

Exception specifications (Meyers says to use them "judiciously")

Specification lists have been discouraged for quite some time (at least 8 years now). You won't (or didn't) find them outside of some STL implementations, that's for certain. They're deprecated in C++0x anyhow.

Another one that comes to mind is overloading a function to take either an int or a pointer (because if you pass 0 as a null pointer, what happens? This might have been in Effective C++).

It will match int because implicit conversion hasn't occurred yet. Use static_cast to convert it to the pointer type, or use the C++0x nullptr keyword which was made for this. std::nullptr_t implicitly converts to any ptr type (not integers).

Re:the best.

[Mongoose Disciple]

How is this not beautiful:

I'll tell you:

It's not beautiful unless you believe that code should be harder to read than write.

Re:the best.

[Espressor]

You've never seen C++ programs with memory leaks? Unfortunately, not every C++ coder is knowledgeable or disciplined enough to localize pointer memory deallocation in destructors only.

But when it's "done right" like you said, correct C++-style coding in C++ makes for absolute control over resource (de)allocation - and this is applicable not only for memory but other types of shared, limited resources as well. Very elegant, and very useful at times. I regret that in Java there are no destructors, but then again in Java you have no control over destruction of objects. This is convenient but limited. C++ provides control.

. I think in most cases though, it's best to avoid the risk of programmers forgetting to apply the idiom as they should. Of course, it's still way safer and more elegant than attempting the same thing in C. The Java approach of using a garbage collector doesn't shock me. Sure, it's not applicable to all application types, but it works well in most enterprise computing cases and it makes for increased productivity.

anyway why do I reply to a post I mostly agree with?

Re:the best.

[Anonymous Coward]

I'm not saying that C is always readable but C++ makes it much easier to create a mess and jumping into any large C++ project is more an exercise in reading than doing.

That's usually known as not knowing the language. When I pick up a book written in Korean, I have a hard time deciphering it. That's because I neither read or speak Korean. There are computer languages that to that to me, too. Prolog, for example, I never learned. I can't read it. Fortunately I don't need to. The other option, of course, is that you're reading C++ written by someone who doesn't know C++.

Re:the best.

[lgw]

Oh, I've certainly seen it done wrong. These days it's my job to create a culture where it's not done wrong within my organization. If I'm doing my job, C++ is the right language for my problem domain (we use a mix of C++ and C#, and where we're doing it right that's for systems code and business logic, respectively).

Re:the best.

[syousef]

After all that discussion about whether it really is a problem with the language specification, I have to say that this example is the lamest reason to damn an entire programming language. It is like damning staplers because they shoot staples into your face when you hold it backwards. Here's a tip: don't do that.

You failed to use a car analogy so I'll fix that for you. It's more like a driver crashing their car at high speed because the power stearing was made over-sensitive to aid in parking, then blaming the driver as they're dying on the side of the road. In this case it was a learner driver too.

There is a difference between a language handing you enough rope to hang yourself and actively tying the noose, constructing the gallows, putting the noose around your neck and kicking the bucket away from under you.

Go bad analogies! Go!

Re:the best.

[russotto]

The random sort (blort sort, bogosort, whatever) does terminate with probability 1, so it's a valid probabilistic algorithm.

Re:the best.

[Anonymous Coward]

uh!

What REALLY piss me off is that every body seems to see java( i do not drink JAVA, I drink Taster's Choice!!), php,c#, ruby, perl,bash, jscript ( should have been called `livescript` btw ).. etc ( i know there is other scripting languages ) .. as THE language and that is a language by itself...
#error all of those above languages are built from C or C++ or C/C++ or C++ only... F(&*^%(! Awake !!! How do you think java has been built ???????????/

" What really killed C++ " ??? then java and friends die with it!!!
DOH!!!

Re:the best.

[Psyrg]

I just checked this on g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3, and the error is suppressed until the -Werror option is given.

I shall add this to my makefiles, I think.

Re:the best.

[onionman]

I certainly understand your annoyance with C++. I also find it to be a "dirty" language with lots of kludging to get around defects. But, then I find something to grumble about with every language I've used.

FORTRAN was perfect for number crunching on machines that don't exist anymore. I never found any other use for it.

With C I used to get annoyed with its inconsistent handling of carry flags, endianness, floating point standards, default int sizes, etc., so I often found myself building huge #ifdef trees to handle platform and compiler idiosyncrasies.

Ada is great to read, but it's the most burdensome language to write that I have ever encountered.

Perl is great to write, but it's the most burdensome language to read that I have ever encountered.

Python could be really nice to code, but what's with the significant whitespace?

Java is a good language for beginners, but it's a little too Ada-like for my taste.

Lisp is a good language for masters, but it's a little too parenthetical for my taste.

I could go on... the point is, it's easy to grumble about any language, but all of the popular languages exist and are widely used because they solved a particular set of problems well enough that it was worthwhile for a large number of people to use them. When the problem set changes, then we see the balance shift (how may FORTRAN or Ada programmers do you know?) and new languages come along.

Now I hear the young kids talking about this rubies on train tracks thing... guess I better go look at it.

Re:the best.

[Osgeld]

OMG no NO!!

line number basic to total beginners installs bad habbits and nonsensical mumbo jumbo to get the simplest of flow done

its freakin 2010, basic is and has been crap since the 70's, and I cant figure out for the life of me why it still lingers like a stale fart

go with lua or python (which I dont like python) or any other interpreted language, its not 1978, my computer has more than 8k of ram, and the only reason I use basic anymore is for my Apple //C and I feel lazy to accomplish a simple task

Re:the best.

[Anonymous Coward]

yeah, without -Wall -Werror you are screwed. g++ allows all manner of crazy shit.

Re:the best.

[yyxx]

I remember the rise of both C and C++; I was part of it. In college and grad school, it was basically the only thing you could use; compilers for all other languages were hard to get or much more expensive. We knew that C and C++ sucked, we knew that there were better languages and better development environments, but we couldn't easily use them, and they often came with expensive runtime licenses attached.

So, it's not that C and C++ solved some grand problem that hadn't been solved before. If anything, they were just considered so worthless that nobody bothered charging much for them.

Re:the best.

[Gadget_Guy]

You failed to use a car analogy so I'll fix that for you.

Actually, mine was a Simpsons reference. That is an approved alternative to a car analogy.

Re:the best.

[growlingchaos]

You, sir, have nailed the point.

Re:the best.

[teh kurisu]

I think it's that way with everyone's first language.

True for me. Java is my first language, but I hadn't used it for a while as my recent work has been in Python and the Qt for Symbian brand of C++. However, I recently started working on a BlackBerry app (which uses an extension of J2ME) and I was astounded by how quickly I actually got things done, and how few time-consuming mistakes I made along the way.

That's not to say that it doesn't infuriate the hell out of me sometimes (I especially miss Qt's slots and signals), especially as J2ME is still stuck at Java's 1.4 source level.

Re:the best.

[21mhz]

But when it's "done right" like you said, correct C++-style coding in C++ makes for absolute control over resource (de)allocation - and this is applicable not only for memory but other types of shared, limited resources as well. Very elegant, and very useful at times. I regret that in Java there are no destructors, but then again in Java you have no control over destruction of objects. This is convenient but limited. C++ provides control.

This control is not absolute. Try static non-POD objects, possibly containing dynamically allocated data, and referencing one another. For more fun, try to have some of these objects live in dynamically loaded modules which are then unloaded.

Re:the best.

[lxs]

Not just you personally. It's a pathological though very common case where quicksort like algorithms perform poorly, and about the only case where bubble sort performs really well. Or so it says in this book I once read (I think it was numerical recipes in Fortran)

Re:the best.

[Anonymous Coward]

> Such people can't even touch C++.

I wished. They can touch it just fine. You just end up with code that works only on one machine (stack object they forgot to write a constructor for), has memory leaks all over (forgot to implement a destructor), is insanely slow (loop with a call to a virtual function and of course all those huge-class arguments are passed by value, maybe involving a nice deep copy) and impossible to understand because some operators have been overloaded with something that does not even come close to a mathematically consistent system.
Oh, in case you haven't noticed: I am no good at C++. But I have seen C++ code at a level of horribleness that even I easily could have done... What is a stronger word for vastly, vastly better? In particular "actually working"?

Re:the best.

[betterunixthanunix]

In fact, when I saw that bug in one of my students' programs, I did check the standard -- I was about to report it as a bug in the compiler itself.

The standards may be a bit permissive in not declaring this to be illegal but the only parties dropping the ball are the ones in charge of specific compiler projects and/or ignorant users who fail to understand both this basic aspect and how to properly configure their compiler of choice.

Not everyone is an expert. Why is it obvious that "-Wall -Werror" should be passed to the compiler, especially for people who have never used g++ before? My students were in their second year as undergrads, and in their first year they saw Java and Scheme, two languages where it is not necessary to ask your compiler to be stricter than the language standard just to avoid seemingly obvious issues.

Re:the best.

[Anonymous Coward]

I have no clue as to exactly how the C++ standard defines "undefined", but at least in C, "unspecified" means that the implementation has to decide, while "undefined" means that it doesn't have to anything at all. Undefined behaviour in a function can therefore do, or not do, anything, and there are no guarantees that the function will behave the same every time you call it, every time you run your program, or even every time you compile. (Different optimization levels, for example, are known to do this.) Of course, an implementation is free to define otherwise "undefined" behaviour. It can try to guess what you really want to do, it can abort with an error at run-time, it can log in to your facebook account and make you a fan of Justin Bieber, etc.

Re:the best.

[AmiMoJo]

A lot of C++ programmers pretty much just use it for memory allocation. It sounds like what we need is a robust memory allocation library for C.

Often memory deallocation bugs are missed because the OS cleans up when the program exits anyway.

Re:the best.

[syousef]

You failed to use a car analogy so I'll fix that for you.

Actually, mine was a Simpsons reference. That is an approved alternative to a car analogy.

Goddamn operator overloading ;-)

Re:the best.

[Anonymous Coward]

Well, maybe you should just go back to BASIC or become a janitor.

Re:the best.

[AmiMoJo]

Back when CPUs were designed by hand there were often lots of useful but undocumented instructions (op-codes). Some people even used them in their software, but it quickly became a problem because there was no guarantee that the next revision of the CPU would do the same thing as the last with an unsupported instruction.

Now that CPUs are designed with computer assistance that makes sure all op-codes that are not valid instructions cause an exception.

Re:the best.

[Kaz Kylheku]

One university professor called this "Bumble Sort".

Re:the best.

[scamper_22]

you seem to have missed the part about using the standard STL. Which is fine, as that as trusted and 'good' code.

You seem to be using it as C with classes, which is how most people use c++.

Re:the best.

[marcosdumay]

Unfortunately, it isn't just 1 line that frees the memory. If you ever have more than 1 step that could fail on your constructor, you'll need more deletes. And if you allocate some memory, you already have a line that can fail.

Yet, it is a long long way away from the mess that is C memory management. I agree with that.

Re:the best.

[marcosdumay]

I didn't understand it at first when the GP said that FreeBSD didn't complain. If he doesn't equate a warning with a complaint, what would he?

Also, -Werror is perfectly optional for me. When you don't consider keeping code that generates a warning, that flag will make no difference at all; and a few times you'll want code that generates warnings, altought for me that normaly happens with Java, and never happened with C/C++ code.

Re:the best.

[marcosdumay]

Well, my first language was BASIC (old BASIC, with numbered lines), and I don't think it lets me solve problems in a logical or clean fashion.

Re:the best.

[Fourier]

Objective, generic, functional -- its all there and accompained with the best preprocessor, macros and code generators

LOL

Re:the best.

[ultranova]

Then can you explain the problems that Perl, Python, and Ruby were invented to solve? It seems strange to have so many different scripting languages that _seem_ very similar.

Perl, Python and Ruby aren't programming paradigms, they are programming languages.

Re:the best.

[Teckla]

It is like damning staplers because they shoot staples into your face when you hold it backwards.

A stapler that prevents that error in usage would be very expensive, and thus impractical. Nobody would buy them. In other words: Your analogy is fail.

On the other hand, allowing a mistake like std::string someFunction() { } is a nearly unforgivable mistake in the specification of any programming language, and would be trivially easy to detect and reject in a compiler. There's no good reason to allow the mistake to happen at all.

It is a wart in C++, among many other warts. The flippant response:

Here's a tip: don't do that.

Is arrogant, at best, and harmful, at worst. It's like saying "don't leak memory, dummy", or "write your own hash table, lazy", or "don't overflow your buffers, asshat".

None of those comments are constructive or useful in the least, and neither is yours. Humans make errors, and programming languages that help humans prevent all of these kinds of errors are a good thing.

Re:the best.

[suy]

I would consider that the superior compiler is the one that outputs (at least) a warning, and the programmer that refuses to release code with warnings a superior coder.

As stated in a comment before, -Wall -Werror should not be optional.

Re:the best.

[hazah]

There is either something wrong with your memory or you haven't been paying attention. C and C++ STILL solve problems that hadn't been solved before. That is reality. The only people who consider them "worthless" are the people who do not comprehend them.

Re:the best.

[hazah]

Not funny at all if you reason this out. The key is that it does NOT hold your hand. That means that if you write nonobjective, non-generic, and nonfunctional code, you'll get exactly that. Why don't you try actually understanding the code you write then??

Re:the best.

[Chris Burke]

Yeah, well, -Werror means I notice the warning when I'm running a large parallel make and a hundred files go flying by. With -Werror, if the link completes I'm off to the races without worrying if there was a warning I missed. Works for me.

Re:the best.

[spyked]

No, C++ is not just "C with classes". It's "C with classes, templates and a whole load of other features" (some of them were even included in newer C standards). Don't underestimate its power. I prefer C to C++ myself, but only because I work on projects that are better suited for C rather than C++. The latter just scales better for larger stuff and is a lot better for abstraction, that's all. While I'd always pick C over C++ for low-level programming.

Re:the best.

[Fourier]

The LOL was aimed at the boldface text. The C++ preprocessor is an underdesigned relic of C which integrates very poorly with the C++ feature set. To describe it as "best" is laughable.

(C++ is also a piece of shit for writing functional-style code, but I'll give that one a pass.)

Re:the best.

[yyxx]

The only people who consider them "worthless" are the people who do not comprehend them.

You are absolutely right that I do not comprehend C++, after 25 years and writing hundreds of thousands of lines of code. I have yet to meet anybody who does, and I have yet to see a substantial piece of C++ code that I couldn't find serious problems in. If you think you comprehend C++, most likely you suffer from Dunning Kruger.

None of that prevents me from getting useful work done in C++ (the compilers and libraries are good), otherwise I wouldn't be using it. But as a language, C++ is a piss-poor design that has not advanced the state of the art in programming languages.

Re:the best.

[swilly]

Perl was invented to solve some problems with scripting, specifically text processing and system administration tasks on Unix machines. Perl is mostly a combination of the Bourne shell, sed, and C and it was a huge advance in the field of scripting (the biggest since the Bourne shell).

Then people started trying to do application development with Perl and while Perl's dynamic nature makes some things easy, it isn't a good language for GUIs or for web development. There are many reasons for this, but two of the most common given are its syntax and its poor support for object oriented programming. Both Python and Ruby attempt to address problems in Perl while keeping its strengths.

It is interesting that until Perl, you only saw regular expressions in specialty tools like sed, awk, and grep, but now every new language has Perl inspired regular expression support (sometimes in the language itself, more often in a standard library). It is still the first place I go if I need to do a lot of string mangling.

Re:the best.

[Espressor]

You're referring to the "static initialization fiasco" and other joys? Yes, a bit of a shame for C++ really.

Re:the best.

[larry bagina]

C without memory leaks? I hope your constructors don't throw an exception.

Re:the best.

[BKX]

It's my understanding that Python and Ruby were created to solve the problem of Perl being amazingly difficult to read (think, gratuitous use of regex). Perl was created to solve the problem of not having a ridiculously powerful scripting language in Unix. Having learned Perl, Python and bash, I find Perl to be quite a joy to use, so long as regular expression use is kept to a minimum. Python can just hurry up and die with it's retarded indents. Bash just isn't powerful enough as a scripting language to get anything really serious done (although for many scripting needs, it's still the best choice).

In case it still seems a bit fuzzy as to why you would need a scripting language that's as powerful as C/C++/Java/whatever-real-language-you-like, just try mocking up something that handles text files quickly in C/C++/whatever and then do it in Perl/Python. It takes half the time, half the effort and half the code.

Re:the best.

[Anpheus]

Err... C++ is not functional, C++0x will perhaps be able to claim that, but functions are not yet there, and certainly there are a large number of differences between C++ and the classic functional languages in the ML family and others.

Re:the best.

[Anonymous Coward]

QBasic is much nicer than C/C++. Switch statements on strings, anyone? Mouse I/O and graphics support built into the language? Meaningful loop constructs like DO...LOOP, FOR...NEXT, that make it easy to tell what a block of code actually does without a brace-matching IDE? Multidimensional arrays of data (not pointers) that can be redimensioned on the fly? That's why I use FreeBasic. It's compiled and allows pointers and inline assembly (which most DOS Basics also let you use with VARPTR/PEEK/POKE). C uses ugly hacks like setjmp/longjmp to do things that GW-BASIC had built-in with ON ERROR. If Basic, invented in 1964, has been crap since the 1970s, C has been crap since 1972. BASIC is even faster than C. BASIC can be interpreted (with memory management, like Java) on computers made in the 80s. C won't even run acceptably on those computers when compiled!

Re:the best.

[smellotron]

The only sensible way to report a failure on construction is to throw an exception. That doesn't result in memory leaks unless the constructor function is already incorrect.

C++. lol.

[Anonymous Coward]

And if anyone thinks C++ is the perfect language they're an idiot.

Re:C++. lol.

[grub]

I don't know why you were modded as a troll. FTA itself:

Stroustrup: I'll just note that I consider the idea of one language, one programming tool, as the one and only best tool for everyone and for every problem infantile. If someone claims to have the perfect language he is either a fool or a salesman or both.

Re:C++. lol.

[Migala77]

Stroustrup: I'll just note that I consider the idea of one language, one programming tool, as the one and only best tool for everyone and for every problem infantile. If someone claims to have the perfect language he is either a fool or a salesman or both.

And that coming from the guy who created a multi-paradigm language.

Re:C++. lol.

[Abcd1234]

Multi-paradigm does not imply "best tool for everyone and for every problem". I'd never write a quick text processor in C++, and I'd never write a kernel in Perl. But I might write a mixture of object-oriented, functional, and traditional procedural code in either one.

Re:C++. lol.

[Anonymous Coward]

I don't know why you were modded as a troll.

Allow me to demonstrate.

Insightful: "It's a shame that the C++ standard doesn't require that compilers search dependent base classes when looking up non-dependent names. This makes the rare and already very complex task of writing a C++ compiler very slightly simpler, while making the much more common task of writing C++ methods unnecessarily verbose."

Troll: "What kind of moron thinks that it's a good idea to make everyone write this->f() when f is obviously in my base class? Were templates just too damn confusing for you, Bjork?"

Re:C++. lol.

[Dystopian Rebel]

The parent is NOT a troll. As others have noted, BS says this himself.

I find one of the most unfortunate things about C++ is that for years a large number of self-important people considered C++ to be the only language that *good programmers* know.

I have sat for interviews that were in sum nothing but quizzes about the arcane features and misfeatures of C++. The interviewers thought that they were showing me that I didn't deserve to work with "geniuses".

What they were really showing me is that I didn't want to work with arrogant primates who had lost their way in the Software Engineering Forest.

Re:C++. lol.

[catbutt]

I agree that C++ is far from perfect, but I do think that we should strive for one language that is the only one you need to know. It may be a long ways off, but I think the inefficiencies of having to learn multiple languages, and having to port code between them, is one of the biggest things holding back progress. I'm sure everyone will disagree with me, but I'd be willing to bet that 25 years from now, 99% of programming (for computers, phones, and whatever devices they have then) will be done in a single language.

To me, it's like the metric system. Sure, using fractional inches might be better for some things, but that is far outweighed by the benefits of having a single unit for length (etc).

That said, I don't think any language in existence today would do it, since none is flexible enough to do both operating systems and dynamic web pages and everything in between. But saying that no language could do both, and do them well, simply shows a lack of imagination.

Re:C++. lol.

[pyrrho]

anyone that believes in perfection is an idiot.

It was never at all meant to be perfect, it was meant to be useful.

I'm surprised at all the whining about C++, especially the idea that C is somehow a more readable or organized language. Perhaps after all the general purpose programmers went elsewhere, the COMMUNITY of c programmers started writing cleaner code... ok, but the language... promoting that?

C++ aimed for complete-as-possible compatibility with C, especially static linking which helped ensure that C++ can follow C anywhere, a useful thing.

blaming C++ for the stupid things purists might like it odd, since purists have never been fond of C++ afaik, and if so, why are they in a multiparadigmed language that allows you to break most of it's rules at will (using C syntax).

It's like blaming Country Music Lyrics on English.

I learned C++ around 1993-94 I guess after having been a C programmer from about 84-85. This is the way to use it. The fact that you can have class hierarchies with structures is itself useful. I have converted C code to C++ simply by making a structure able to initialize itself, a safe fix for code which would have been a nightmare to fix some other way (go to every malloc of the structure and do it there, all throughout the code?)

But evidently such use of C++ provides too much temptation for some. That's too bad.

Also, as a C programmer at that time we all became aware of how the C compiled, what instructions you were really looking at, and in C++ at that time, my colleagues and I at least (in the game industry then) continued to view C++ this way. If I learned a new feature of C++, I studied how it would look in memory, how it would look if it was a C structure (or set of such), making it quite easy to avoid certain problems.

As a C programmer I expected myself to do this. Also, this revealed where the performance hits were, and what to avoid. C++ is multiparadigmed (or unparadigmed, or, a crazy toolbox)... so? man up and learn the tools including which ones you don't want.

As far as the problem of what OTHER programmers do with C++... if people have not seen crazy things done with C... confusing bad things... I cannot explain that. How can that be? Some historical accident because the language does not prohibit it, it's up to the programmer.

Then again, as long as it's not proprietary, I couldn't care less what languages other programmers like.

Re:C++. lol.

[pyrrho]

never

no offense, but that's like striving to integrate your hammer and screw driver.

Re:C++. lol.

[Anonymous Coward]

He was modded troll because of the subject line, obviously.

Re:C++. lol.

[Anonymous Coward]

c++ is AnAZinG!!

Re:C++. lol.

[Anonymous Coward]

The reason the AC was not modded as a troll is very simple: he was disparaging C++.

The world is full of halfway-competent programmers who just can't make C++ work. So, as a matter of ego-defense, they do everything they can to convince others (and themselves) that the problem is with the language, and not with them.

Such people love to give positive mods to others who will reinforce their comfortable self-image by also disparaging C++.

Re:C++. lol.

[sim82]

*warning: false dilemma ahead*
BUT: If I was, for any reason, forced to choose a single language to use (i.e. get work done) in the future, it would probably be c++.

Re:C++. lol.

[Anonymous Coward]

If someone claims to have the perfect language he is either a fool or a salesman or both.

Unless that language is Lisp, of course.

Re:C++. lol.

[Anonymous Coward]

You're right, he should have been modded redundant.

Re:C++. lol.

[hazah]

This reminds me of "the theory of everything" and Stephen Hawkins eventually saying something like "we will never see it". The reason, though philosophical does stand if you contemplate it long enough. The problem really stems from the fact that when you have a model that describes your problem, you'd be hard pressed to search for another model. Languages serve as models, and their ability to describe very different aspects that could potentially mean the same thing states that, well, you can describe the same thing in many differing ways. Just the other day there was a long debate on /. about how .9... is exctly 1 and .3... is exactly a third. I mean... we can have differing notations for one single value. This is just more of the same thing.

read with a fake Scots accent

[tverbeek]

Only 25 years? When I was in college, we learned C. No "plus plus", no "objective", no "sharp"... just "C".

Aye, as a matter of fact, I am feeling than a wee bit like Scotty in the TNG episode "Relics".

Re:read with a fake Scots accent

[pjt33]

Why would you want a fake Scots accent to do a ripoff of the Four Yorkshiremen sketch?

Re:read with a fake Scots accent

[blair1q]

In my day, you got a fake Scots accent and you liked it.

Re:read with a fake Scots accent

[robot_love]

Luxury! I used to dream of getting a fake Scots accent. In my day we had to yell through a bag of peat moss.

Re:read with a fake Scots accent

[Anonymous Coward]

Why would you want to do the four yorkshiremen sketch when you can instead rip off a trek scene in which the letter 'C' is used?

Re:read with a fake Scots accent

[Anonymous Coward]

C is for cookie, that's good enough for me!

Re:read with a fake Scots accent

[dbIII]

I learnt FORTRAN and was happy with it. Helped to fix hole in road.
The language was OK, typing it with only 300bps between the terminal and the VAX was not so everything got written on paper first.

Re:read with a fake Scots accent

[Vectormatic]

peat moss? you lucky bastard, in my day we got fake welsh accents

Re:read with a fake Scots accent

[Anonymous Coward]

Pshaw...you with you're new-fangled languages.

Back in my day, we used UCOBOL. ("U" because it was still "Un-Common") and FOR, because there were no computers to TRAN to (translate). In fact, it was all abacus-based.

Re:read with a fake Scots accent

[turgid]

*sits back smugly*

I am Scottish and have the genuine accent. What's more, when I was a small boy I used to watch Star Trek and want to be an engineer on a starship just like Scotty.

OK, so I'm an engineer and have the accent, but two out of three isn't bad and I'm working on the starship.

Re:read with a fake Scots accent

[Anonymous Coward]

Let me help you out there, then:

No, just C. No bloody "plus-plus", "sharp", or "objective".

The Dream Project

[oldhack]

For job security, that is, would be C++ modules glued together with Perl.

I've got a headache just typing this post.

Re:The Dream Project

[shutdown -p now]

For job security, that is, would be C++ modules glued together with Perl.

If you're really going for job security, I think it would be more advisable to go with Perl modules glued together with C++.

But, really, you can get creative enough with C++ as is. For example, implement Brainfuck using template metaprogramming, then write as much as you can in Brainfuck using those templates.

Re:The Dream Project

[obarel]

The nightmare of every manager: to wake up one day and find that every piece of software in the company is written in whitespace. Talk about job security... "What do you mean 'where is the source code'? This *is* the source code. But I'm here to talk about my raise, actually."

Re:The Dream Project

[MichaelSmith]

For job security, that is, would be C++ modules glued together with Perl.

For real job security use rhapsody to generate the perl and C++ and make everything an object. How's that headache now?

Re:The Dream Project

[dbIII]

You can document Perl, just nobody does because there ends up more lines of documentation than the program.

Then what's the point?

[Anonymous Coward]

'If I had thought of it and had some marketing sense every computer and just about any gadget would have had a little 'C++ Inside' sticker on it' and 'I'll just note that I consider the idea of one language, one programming tool, as the one and only best tool for everyone and for every problem infantile.

They why make a not-really-object-oriented language that seems to be the result of you getting really high and having programmer's munchies -- throwing in every single feature you could think up, no matter whether it fit or was redundant? Why not create something cleaner and with some sense of purpose and editorial discretion?

C++ inside

[Dan East]

I know he said it in jest, but the devices wouldn't have had any C++ in them at all. Only binaries, generated by assemblers, which took output from the C++ compiler. :) A couple layers of abstraction away is all...

Re:C++ inside

[RyuuzakiTetsuya]

You're being pedantic, and he's being a salesman. :)

Freedom

[FlawedLogic]

I've been writing C++ for 20 of those years and produced an awful lot of performance critical systems code in that time. To this day I find it the most liberating language, whatever is in your mind, you can express it, without the language compromising your intent. I can't see myself moving on until D becomes mainstream, and that may not be before I retire in ten years. I check out all the pretenders as they come and go, nothing else comes close.

Re:Freedom

[blair1q]

performance critical

Did you say "fast"?

Re:Freedom

[FlawedLogic]

Ok, I'm a verbose git. But yes - where 'fast' is a critical requirement of the system, or people may die.

Re:Freedom

[Anonymous Coward]

no, he said " has to be fast"
dumbkopf!

Re:Freedom

[shmlco]

How about when systems are hacked and they crash due to bad pointer manipulation and buffer overruns... and people die?

Performance isn't everything.

Re:Freedom

[Anonymous Coward]

Oh, you mean those things that happen in C and C-with-classes, and not real C++ code?

Performance depends on the domain you're in, unless you want to try and write an operating system in Python.

Re:Freedom

[swillden]

How about when systems are hacked and they crash due to bad pointer manipulation and buffer overruns... and people die?

Performance isn't everything.

That's why C++ is better than C. With C++ you can ban naked pointers from your code and use bounds-checking objects for buffers. With a little care, you can do it with negligible overhead, too -- preserving the "fast" part.

Of course, there's a lot of C++ code out there that uses naked pointers and fixed-sized unchecked buffers, but that's the programmer's choice. C++ makes it easy for programmers to be safe, but doesn't presume to force it on them. The only real complaint I have about the language is that its multi-paradigmatic approach and the practical constraints under which it was designed have led to a great deal of complexity. That's not an issue for me when I'm the only coder on a project, but when it comes time to build a team it can be hard to find a sufficiently-competent group, and training competent C++ programmers up from zero takes years.

Re:Freedom

[blair1q]

Actually I was being facetious. C++ is faster than Java, but slower than C.

"Performance critical" means real-time, and real-time does not mean "fast", and sometimes you have to reset a customer's expectations about that.

Re:Freedom

[Anonymous Coward]

Try using C# old man.

Re:Freedom

[Rakshasa Taisab]

Except C++ is not slower than C... It's actually equally fast, and can give a lot of performance optimizations with a fraction of the code needed to do the same on C.

You're just a troll who doesn't actually know C nor C++.

Re:Freedom

[Anonymous Coward]

I've been writing C++ for 20 of those years

And I'd bet you still regularly get memory leaks? It's a very capable language, but so hard to use correctly...

Re:Freedom

[BravoZuluM]

I have been writing with C++ for 20+ years as well. Started with cfront in 87.

I'll second what Flawed Logic just said. I know and use other technologies as necessary, i.e. PHP for web development, Python for scripting...ect. But for embedded and desktop, C++ rocks. Use a framework like QT with the language and you can be every bit as productive as C#. When developers talk about all of the pitfalls of C++, it just tells me that they lack design principles and discipline. I learned object orient design from Neil Goldstien at Apple Developer University. I just bought his book, "Objective C for Dummies" (never stop learning) and he conveys some of his coding principles in that book. Those ideas have served me well. I also learned C++ at Apple Developer University. I don't remember that instructor, but if I dug through the boxes in the garage, I'm sure I could find the course work. That guy rocked and taught the principles and techniques needed for coding sanely. I can't remember that last time I referenced a null pointer, double dereferenced a pointer, over wrote the stack or other things that people complain about C++. If you do these things, you have not developed a consistent set of rules of engagement. Yes you can have garbage collection but I find I just don't need it. People often ask how I get my programs to run so fast. C++ on today's processors are blinding fast. If someone were to say that they must not have been very complex application, I would tell you that they were consumer applications for large companies: Intuit, Wind River; Qualcomm, Sony Entertainment and others. (I was a contractor.) Many of you used applications that I wrote...along with other talented people.

What I see today are developers learning a niche and then railing against anything that might threaten that niche. What is lacking is passion and the desire to learn different technology solely because it is fun. The company I am currently has Java guys who insist that Java is the end all and be all. We have C# guys who insist that the language is the end all and be all. We have Python guys who swear it is the only language one needs. When I hear the language wars between them, I just sense that maybe they do it for the money, not because of the joy of it.

If you find yourself here pontificating that your language is superior to another, maybe technology isn't your thing.

Re:Freedom

[dbIII]

A Microsoft only version of Java? No thanks. It didn't work very well last time they did that.

Re:Freedom

[91degrees]

There is a Linux port. And it has several features mising from Java.

It's actually a pretty good language.

Re:Freedom

[21mhz]

One problem with C++ is, there are too many "don't do this" rules to remember. If you should not do these things, why were they made available in the first place?

Re:Freedom

[theCoder]

Because C and C++ are enabling, not disabling, languages. And while 99% of the time it's a bad idea to do something (like write a custom allocator for a class), occasionally, it is the right thing to do, and you're glad to have that option.

Re:Freedom

[21mhz]

No, no. C is an enabling language, that's right. C++ is a bewildering language, overloaded with features that, taken together, make it ridiculously complicated and unintuitive.

Happy Birthday

[Lord Lode]

Yay, happy birthday, my favorite language :)

The "Right Problem"

[Anonymous Coward]

Sometimes, it is more important to have the right problem than the best solution.

This is certainly true in more ways than he intended. C++ is as awful as it is useful: Extremely. I will remember this quote next time I have to make an implementation recommendation: "C++ is the right problem for this job." Fucking terrible syntax, loaded with gotchas, requires inordinate amount of expertise to avoid subtle errors--and utterly indispensable when a high-performance general purpose programming language is needed.

Re:The "Right Problem"

[Chris Burke]

C++ is as awful as it is useful: Extremely.

Ha! That's a pretty great quote there yourself Mr. AC.

For some critical views of the language...

[leonbloy]

C++ FQA (frequently questioned answers)
(Defective C++ is a summary)

'There are only two things wrong with C++: The initial concept and the implementation' - and other quotes

Why C++ sucks

And, previsibly: http://cplusplussucks.com/

Re:For some critical views of the language...

[turgid]

My favourite quote: c++; /* this makes c bigger but returns the old value */

Re:For some critical views of the language...

[cb123]

For some critical discussion of the "productivity", this recent thread might also be of interest. In the article in question Bjarne claims credit (dubiously IMO) for saving 'years of development time' on any complex project [ Google, DNA matching, etc. ] where people happened to use C++ instead of some alternative. http://www.reddit.com/r/programming/comments/cdncx/linus_about_c_productivity_again/?utm_source=web&utm_medium=twitter

Re:For some critical views of the language...

[shmlco]

The "Why C++ sucks" author is an idiot.

He states, "In Stroustrop's mind, making C++ compatible with C was instrumental, crucial to its success." And then tells you why it's a bad thing.

But, as someone who actually lived through that time frame, I'm here to tell you that he misses the point completely. C++ compatibility was in fact instrumental to it's success.

Why? Because C++ was originally a preprocessor that converted everything to C, and then fed the C code to the C compiler. And almost EVERY platform had a C compiler. By making it compatible, he got many C-language adherents to try it, and he got it on every platform so they could do so.

Re:For some critical views of the language...

[david_thornley]

The FQA is a sad hack job by somebody who doesn't know C++ all that well but is obsessed with criticizing it. I wouldn't go there. If you can filter out the actual valid stuff in it, you know it already.

Re:For some critical views of the language...

[Anonymous Coward]

Sorry David, the slashdot hive demands you get your hate on, so the FQA is gospel. Also remember, everything from Microsoft is bad.

Actually I find "Effective C++" to ironically be a sort of anti-advocacy in that it gives you something of a map to the minefield that the language is.

Re:For some critical views of the language...

[Vectormatic]

if i hadnt already posted in this thread, you would have gotten an extra +1 funny from me

Re:For some critical views of the language...

[HonIsCool]

Well, C++ was never a "preprocessor". Cfront was always a full-fledged compiler albeit the output was not native assembler but C code. The Comeau C++ compiler works on the same principle. There is no need for C compatibility in the language in order to do this though.

When Stroustrup says C compatibility was crucial for its success, it is your final sentence that's relevant: the userbase was originally very small, and they basically demanded C compatibility. In "Design and evolution", Stroustrup explains how he eg tried to fix function declaration to something saner, but his audience threatened to walk-out on him if he did, so he was basically forced to cater to their whims because otherwise the language would be dead.

Without actually having read the "why C++ sucks" argument, I tend to agree that C compatibility was not necessarily a good thing, even if pragmatic.

Re:For some critical views of the language...

[Anonymous Coward]

Indeed, it is so full of errors that you couldn't even point out a single one and had to resort to ad hom attacks.

Re:For some critical views of the language...

[nothings]

"But, as someone who actually lived through that time frame, I'm here to tell you that he misses the point completely. C++ compatibility was in fact instrumental to it's success."

Jeez, read the fucking article: "In Stroustrop's mind, making C++ compatible with C was instrumental, crucial to its success. I don't disagree."

It was instrumental to its success in the marketplace of languages. It doesn't help it succeed at being a good language. That's the whole point of the article, Mister point-misser.

"By making it compatible, he got many C-language adherents to try it, and he got it on every platform so they could do so."

Yes, I know this. That is exactly the point. I was there for the whole thing too. (And to this day I still program in C.) The essay itself is like ten years old at this point.

C++ is a language that, given the choice between a feature/goal that made a good language or a feature/goal that made a popular language, made the choice in favor of popular.

Lots of things, e.g. compatibility with C, or choosing not to rewrite the linker, or sticking with header files, can be seen through this lens. I think those choices were made with an eye towards what would make the language "succeed in the marketplace", not what would make for the best programs or the best programming experience.

Obviously some of the times those things are correlated, but they're not always (e.g. the linker situation).

Now, you might think that being popular is a good thing. But the upshot of this is that in the marketplace of computer languages, computer languages that are designed to be popular will beat out computer languages that are actually good. (C.f. 'Worse is Better', etc.)

I don't think that's a good thing.

Re:For some critical views of the language...

[Anonymous Coward]

That is also insightful as you could say that the C++ returns the values of the beloved C in bigger, more complex systems.

Re:For some critical views of the language...

[shmlco]

To me much of that rant smacks of reflexive counter-culture elitism, in that if it's popular, then it can't be any good.

It might not have been the "best" language possible, but for 95% of the use cases it was good enough. You don't get to be popular if you fail to do what the majority of people want done.

A tool for when you need to get the job done

[shutdown -p now]

C++ - the language which everyone loves to hate. Every time there is a story posted about it on /. (or any other technical forum), you see all kinds of posts ranting about how crappy it is, how Objective-C (or whatever is the fad of the day) is so much better etc.

And yet - it is still the language in which most desktop software and games are written to this day, and this doesn't show the signs of changing. Not only that, but some of the biggest and most prominent FOSS projects - Firefox, OpenOffice, KDE - are written in it.

Ever wondered why?

Re:A tool for when you need to get the job done

[betterunixthanunix]

C++ is popular for the same reason Windows is popular (and in fact, Windows' popularity probably fuels a lot of the popularity of C++): it is widely deployed, people know it, and there is a lot of legacy code that depends on it. Popularity does not make a language good, and I think we have enough examples: COBOL, FORTRAN, C++, etc. C++ has a number of glaring omissions from the standard, and worse yet, things in the standard that are now idiomatically avoided (see Effective C++ and Effective STL if you are interested -- auto_ptr certainly comes to mind). There are some really great languages out there, which just don't have the same non-technical advantages that C++ enjoys, and therefore never became popular among mainstream programmers.

Re:A tool for when you need to get the job done

[AnonymousClown]

C++ - the language which everyone loves to hate.

I thought it was Visual Basic.

Re:A tool for when you need to get the job done

[Abcd1234]

Ever wondered why?

Tradition, momentum, and the fact that it occupies a very specific niche (large, low-level, high-performance applications). But taken on its own, you could do far far better than C++.

Hell, by your logic, Windows must be the greatest operating system in the history of computing.

Re:A tool for when you need to get the job done

[Anonymous Coward]

Ever wondered why, at one point, Full House was the longest running active sitcom on TV? Was it its high quality?

C++ is the lowest common denominator language, and hence its entrenchment. Large companies, especially, are prone to entrenchment. For the first few years of OS X, Apple's devs all worked on C++ (i.e., Carbon) versions of the APIs before they worked on their Objective-C counterparts because both the Apple devs and outside companies were stuck in the era of C++. Even as they pushed Objective-C and Cocoa, it was prioritizing C++; it takes time to get away from old standards even when there are better options.

If not for entrenchment, how else can you explain why so many people who hate C++ bothered to learn it? I only learned it because it was prevalent, even though as I was learning it I saw how terrible it was.

Re:A tool for when you need to get the job done

[martyw]

There is no other language that comes even close to C++ in terms of performance, features and freedom of coding style, not to mention direct support by the hardware vendors like Intel, AMD and even Apple now (see Intel's compiler collection or AMD optimizing compilers). C++ is also patent problems free and IEEE's "gold" standard of a programming language.

Re:A tool for when you need to get the job done

[bonch]

And yet - it is still the language in which most desktop software and games are written to this day, and this doesn't show the signs of changing.

Huh? There are absolutely signs. Java's sudden popularity in the 90s was a sign. People learning languages like Ruby, C#, and Objective-C is a sign. Web development languages are a sign.

Your argument is like claiming Windows is awesome because it's still the most-used operating system. And calling Objective-C a fad of the day is amusing considering it's as old as C++.

Re:A tool for when you need to get the job done

[Threni]

> there is a lot of legacy code that depends on it.

Like..you know, Linux, and Windows and stuff. Which language do you believe Operating Systems should be written in? Or drivers, games... you know, stuff that has to work, conform to meaningful standards, be fast, unencumbered with legal bullshit, etc?

Re:A tool for when you need to get the job done

[shutdown -p now]

Popularity does not make a language good, and I think we have enough examples: COBOL, FORTRAN, C++

What's wrong with FORTRAN in its niche?

For that matter, what's wrong with COBOL for when it was widely used (rather than comparing it to the languages of today)?

C++ has a number of glaring omissions from the standard, and worse yet, things in the standard that are now idiomatically avoided (see Effective C++ and Effective STL if you are interested -- auto_ptr certainly comes to mind).

I'm not arguing that C++ is perfect, but most of its flaws are either sufficiently minor, or easy to work around. Eventually those workarounds make it in the Standard (as unique_ptr did in C++0x, deprecating auto_ptr), but nothing stops you from using them on their own.

Same for omissions in the standard library. Sure, it's very primitive, but there are mature and well-documented frameworks covering pretty much all the ground there is missing between C++ and the likes of Java (most notably, Qt).

There are some really great languages out there, which just don't have the same non-technical advantages that C++ enjoys, and therefore never became popular among mainstream programmers.

If you look at it that way, then pretty much all mainstream languages of today are mediocre. C++, Java, C#, PHP, Python... any of those have a long list of flaws and deficiencies.

Yes, ultimately, a language needs either a strong community drive, or corporate backing (or both) to succeed. Of those which had that, C++ is by far not the worst one.

Re:A tool for when you need to get the job done

[shutdown -p now]

Tradition, momentum, and the fact that it occupies a very specific niche (large, low-level, high-performance applications)

You're correct, except that I would argue that the niche is not all that specific, and, indeed, covers a huge chunk of apps out there.

But taken on its own, you could do far far better than C++.

Oh, of course. You could also do far better than Objective-C, or Java, or even C. In fact, many did.

Hell, by your logic, Windows must be the greatest operating system in the history of computing.

Of course not. What matters is that it (both Windows and C++) is either "good enough" or "sucks but better than all other options" for a large number of important applications.

Re:A tool for when you need to get the job done

[lennier]

And yet - it is still the language in which most desktop software and games are written to this day, and this doesn't show the signs of changing. Not only that, but some of the biggest and most prominent FOSS projects - Firefox, OpenOffice, KDE - are written in it.

Ever wondered why?

Completely coincidentally, the set of software (both FOSS and commercial) written in C++ seems to overlap closely with the set of software for which large and prominent security flaws are discovered every month.

Ever wonder why that is?

Re:A tool for when you need to get the job done

[shutdown -p now]

Huh? There are absolutely signs. Java's sudden popularity in the 90s was a sign. People learning languages like Ruby, C#, and Objective-C is a sign. Web development languages are a sign.

A sign of what? When Java came out in 1996, Sun was telling everyone that, come 2 years, no-one in would bother writing anything in C++, because Java was so clearly better. They were wrong.

When .NET came out in 2001, Microsoft claimed that all applications on Windows would be written in it real soon now. Remember the "all-managed" Longhorn? Riiight...

All those newcomer languages? They did take their niches, in some cases at the expense of C++. But they are not "C++ killers", even in aggregate, as the last 15 years of failed "C++ gonna die any day now" predictions have clearly demonstrated.

And calling Objective-C a fad of the day is amusing considering it's as old as C++.

Objective-C is the fad of the day because, regardless of its age, its popularity is a rather recent phenomenon. It was propelled up not even by OS X, but by iOS. In that sense, it is a very niche language since it is, effectively, a single-platform one (sure you can use it elsewhere, but hardly anyone does).

Re:A tool for when you need to get the job done

[grumbel]

There are some really great languages out there,

Actually, no, there aren't, when it comes to scripting languages you have tons of stuff and when it comes to virtual machine based things you also have plenty, but for the real low level there really isn't much beside C++. Ada and Objective-C would be pretty much the only established competition and while D or Go might one day become interesting, they are still rather fresh.

Re:A tool for when you need to get the job done

[Anonymous Coward]

Hell, by your logic, Windows must be the greatest operating system in the history of computing.

I know you were trying to be facetious, but.. it is.

Re:A tool for when you need to get the job done

[shutdown -p now]

Completely coincidentally, the set of software (both FOSS and commercial) written in C++ seems to overlap closely with the set of software for which large and prominent security flaws are discovered every month.

Ever wonder why that is?

Because it's not a memory-safe language. Both C and Objective-C also suffer from the same problem.

But here's another riddle. Memory-safe (which usually means "managed" - GC etc) languages have been around for several decades now, and effectively mainstream for about 15 years (Java and beyond) - and have been used very heavily in some niches, such as web development. And yet the number of desktop applications written in those languages is dwarfed by the number of apps written in C or C++.

Ever wonder why that is? ~

Re:A tool for when you need to get the job done

[betterunixthanunix]

what's wrong with COBOL for when it was widely used (rather than comparing it to the languages of today)?

Nothing was wrong with using COBOL back then, but COBOL remains in use today -- quite a lot of COBOL code is running right now. It is not being used because COBOL is a great language or because COBOL is the best solution in the situations where it is still used. It is in use because the cost of switching is still too high.

I'm not arguing that C++ is perfect, but most of its flaws are either sufficiently minor, or easy to work around.

Some flaws are minor, sure, and I would not begrudge any language a couple of minor flaws -- nothing is perfect. C++ has flaws, however, that are not at all minor. Control flow can reach the end of a non-void function, for example -- a situation which can cause a program to crash (this is a leftover from C, where such a situation could only cause corrupted data). If an exception is thrown while the stack is being unwound as part of the handling of another exception (e.g. an exception might propagate outside of a destructor), the program immediately aborts. The standard library has things like auto_ptr (fixed in C++0x, thankfully), return codes instead of exceptions (but only sometimes; in some cases, though, you need to ask for exceptions to be thrown instead, but in other cases it is part of the standard), allocators as template parameters (I hear this will be fixed too), etc.

Yes, some flaws are minor, like the weird syntax for overloading prefix operators, but there are other, more serious problems with C++.

Re:A tool for when you need to get the job done

[pyrrho]

actually, it's because if you know what you are doing you can make it run as fast as C, and access the hardware as easily as free, and also, if you know what you're doing you can make higher level and more flexible abstractions.

people seem to have an objection to the "know what you are doing" requirement, and seem to think that in C, you don't have to know and the code manifests well. If there is any truth to that... that C code is all nicely organized now, and naturally safe, then it's only because the C programmers have internalized certain idioms and avoided other possible ones... which is what you have to do in C++ as well to use it well.

the idea of a language which works well without knowing what you are doing is laughable to me. The illusion comes, for example, from languages where you can build a robust web server in five lines (or whatever)... yes, because it has a webserver built in! if you are going to do something besides say "run this program which was already written", then you need to understand logic and machines. There is no way around that.

C++ can be made as fast as C, don't deny it because I can write a C++ program that IS C. So it's a truism. That means you only need any feature that imposes any performance hit if it saves you some other way, like protecting memory or allowing one to save time in what is actually the most precious resource, developer time.

Re:A tool for when you need to get the job done

[Anonymous Coward]

a situation which can cause a program to crash (this is a leftover from C, where such a situation could only cause corrupted data)

Crashing instead of silently corrupting data is actually a feature.

Re:A tool for when you need to get the job done

[sjames]

But keep in mind the joke "Eat shit! A trillion flies can't be wrong!"

Re:A tool for when you need to get the job done

[Xtifr]

Completely coincidentally, the set of software (both FOSS and commercial) written in C++ seems to overlap closely with the set of software for which large and prominent security flaws are discovered every month.

Really? I'm not a C++ advocate, but I would have expected C, with its lack of exceptions or any straightforward way to implement RAII, to hold a commanding lead there.

Re:A tool for when you need to get the job done

[Anonymous Coward]

Simple, really. Desktop applications is not where new investments in apps are going right now. It is web apps for the most part and now increasingly apps for hand helds most of which are not developed in C++
The most familiar desktop apps mentioned ( Word processors, Web browsers, spreadsheets etc ) were created ages ago before Java, C# and the likes were mature enough.

Re:A tool for when you need to get the job done

[shutdown -p now]

The most app-rich handheld platform today is iOS, which uses Obj-C - which is also not memory-safe.

Re:A tool for when you need to get the job done

[Anonymous Coward]

Linux does not depend on C++.

Re:A tool for when you need to get the job done

[Vectormatic]

no, that would be:

VB - the language everyone looks down on with a level of contempt second only to that felt for "HTML programmers"

Re:A tool for when you need to get the job done

[Anonymous Coward]

.. it is widely deployed, people know it, and there is a lot of legacy code that depends on it.

It is widely deployed because it allows solving wide range of very different problems efficiently: other languages often lack same flexibility and efficiency.

Popularity does not make a language good, and I think we have enough examples ...

True, but to gain popularity usually means that it solves many different problems in a way that is appropriate for each problem: if most problems were "display text in GUI" then VB might be most popular.
As Stroustrup said himself there is no single "best for all" solution in existence: most popular language of each time is that it is most approriate for most problems at the time.

Re:A tool for when you need to get the job done

[master_p]

COBOL and FORTRAN are very good languages for their problem domain. That's why they succeeded. C++ is an extremely good language, for its problem domain: writing "large" software where performance is critical.

It does not matter if it's difficult to get into. Every good language is difficult to get into. Haskell, the uber language, is one of the most difficult languages to get into, but when you get it, you are extremely productive with it.

Re:A tool for when you need to get the job done

[Rockoon]

There is no other language that comes even close to C++ in terms of performance..

..sure, as long as you ignore the fact that most compilers for other languages are equal to or only slightly worse in performance that your typical C++ compiler (VC++, GCC) .. basically as long as you ignore the evidence that says you are full of shit here, you are right.

Re:A tool for when you need to get the job done

[Anonymous Coward]

> the C programmers have internalized certain idioms and avoided other possible ones... which is what you have to do in C++ as well to use it well.

There is the theory that it's an impossible task for C++ though. Seriously though, the vast majority of people will have to restrict themselves to a subset of C++ they can use efficiently because there's just too much too it and then they might end up having the "luck" of working on a project by someone who "specialized" on a different C++ subset.

Re:A tool for when you need to get the job done

[Anonymous Coward]

Programmers love nothing better than to throw away an old version and come up with something completely new from scratch. Witness Netscape 6.

Yet we know that usually the best course is to just fix what's wrong, and learn to deal with the somewhat suboptimal parts. Which is what C++0x is doing - evolution not revolution. auto_ptr broken? Sure. This time, the smart pointers will be based on the Boost ones which have gone through a number of iterations to get them right.

Popularity doesn't make a language good. People do, but there's only so many people that are willing to fix unpopular languages.

Re:A tool for when you need to get the job done

[m50d]

the idea of a language which works well without knowing what you are doing is laughable to me. The illusion comes, for example, from languages where you can build a robust web server in five lines (or whatever)... yes, because it has a webserver built in! if you are going to do something besides say "run this program which was already written", then you need to understand logic and machines. There is no way around that.

By that logic there's no point in any programming language, we should just write in assembly - you have to understand the machine, there's no way around that.

C++ can be made as fast as C, don't deny it because I can write a C++ program that IS C.

Sure, but if you compile it with g++ you'll find it runs substantially slower than with gcc.

Re:A tool for when you need to get the job done

[LizardKing]

Linux (the kernel) is written in C. Not C++.

Re:A tool for when you need to get the job done

[HonIsCool]

You are certainly insistent about the badness of that missed return statement :) But it is certainly not true that in plain C such a bug can only cause data corruption (if that were even desireable); just imagine the consequences if the return value is a pointer...

Re:A tool for when you need to get the job done

[HonIsCool]

If true, g++ is broken and needs to be fixed.

Re:A tool for when you need to get the job done

[Anonymous Coward]

it is widely deployed, people know it, and there is a lot of legacy code that depends on it.

And it's awesome!

Also its fast. And gives you superior control of your resources. And in the hands of a competent developer it can be used to make solutions that outperform similar solutions written in any competing language.

Re:A tool for when you need to get the job done

[pyrrho]

if I take a C program and make it C++ compliant (like no variable called "new") you are saying it will run slower compiled by g++ as C++? There is no excuse or valid reason for that. I have to agree that would be a bug in g++ if true.

Re:A tool for when you need to get the job done

[m50d]

A trivial (but relevant) example for why is that g++ will output extra information needed to propagate exceptions correctly; if you have a function that calls a function in another module, there's no way for g++ to know that the other module will never throw an exception, so it still writes that code. Of course, for that particular thing there's a flag to turn it off, but there are other cases. (Or were, last time I benchmarked it, which was admittedly some years ago)

Re:A tool for when you need to get the job done

[dave87656]

what's wrong with COBOL

I've been writing business applications for a while (since 1981). The most producive language for that was certainly COBOL. I use java exclusively now and its platform independence is excellent, but it takes longer to write and maintain the same business functionality in Java than in COBOL.

Re:A tool for when you need to get the job done

[jfz]

So in summary- critical mass.

Doom

[Purity Of Essence]

So, for me, the main satisfaction comes from interesting and challenging applications that just might not have been done without C++, or possibly been delayed for many years for lack of a language suitable for demanding real-world applications. ... Videogames like Doom

Doom was written in C, not C++.

Re:Doom

[Anonymous Coward]

Same difference right?

-Clueless Newswriter

Re:Doom

[Anonymous Coward]

Doom was written in C, not C++.

I guess that's what doomed it.

Re:Doom

[Chris Burke]

Doom was written in C, not C++.

The primary reason being that back then, C++ compilers were not good enough to produce sufficiently fast code when using any of the things that make C++ worth using over C (heck and a lot of the things that really make it useful like templates weren't even present). Not with the kind of constraints Doom was operating under (getting those graphics on a 386 was something of a miracle, even with all the clever tricks used).

Re:Doom

[Anonymous Coward]

That's what I remember from checking out the source for Doom too...

Re:Doom

[bonch]

From Doom to Quake 3, in fact.

Re:Doom

[Purity Of Essence]

Except when it isn't. Like the vast majority of iPhone/iOS stuff that is written in Objective-C, and every id game released before Doom III.

I'm not saying C++ isn't damn near ubiquitous, but the guy specifically suggested that Doom wouldn't have been possible without C++, and that's demonstrably bullshit.

Re:Doom

[Anonymous Coward]

& id tech 4 & 5 are written in C++. The last C game they did was Quake3...

Re:Doom

[Anonymous Coward]

True, but Doom 3 is written in C++ (well, at least the game code, for which the source code is available to the public).

Re:Doom

[Anonymous Coward]

So, for me, the main satisfaction comes from interesting and challenging applications that just might not have been done without C++, or possibly been delayed for many years for lack of a language suitable for demanding real-world applications. ... Videogames like Doom

Doom was written in C, not C++.

He means Doom 3 ofcourse...

Re:Doom

[walshy007]

Even when quake3 was made? (around 1999)

I've went through a reasonable chunk of quake3 source and I'd have to say it's extremely easy to read c.

because of the crazy number of valid things you can do in c++ a lot of code can be harder to read. Yes this is the programmers fault, but most c programmers code is usually quite clear unless they are aiming for the obfuscated c contest.

Re:Doom

[walshy007]

Which ironically was their last popular engine.

Re:Doom

[Chris Burke]

Yeah, even then, though to a lesser extent.

Carmack likely would have stuck with what he was familiar with unless he saw a need. Having seen code for Quake and Quake3, I am quite sure that they didn't avoid C++ because they were worried about their code being hard to read. Remember the inverse-square-root function that used integer bit manipulation of floating point values which nobody else could figure out how it actually worked until years later? :)

Written in C++?

[TejWC]

Videogames like Doom, ...

Correct me if I am wrong, but I am pretty sure the first Doom was written in C.

Re:Written in C++?

[Anonymous Coward]

So was Doom II, Quake, Quake II, and Quake 3 Arena. All straight C.

Dunno about Doom 3/Quake IV, they haven't released source code for those yet.

Re:Written in C++?

[Anonymous Coward]

Videogames like Doom, ...

Correct me if I am wrong, but I am pretty sure the first Doom was written in C.

Are you pretty sure because wikipedia.org says so?

"replacement language for C"

[Megaweapon]

trollface.jpg

Re:"replacement language for C"

[Anonymous Coward]

It's "coolface" you fucking troll.

Alan Kay said it best...

[RocketRabbit]

Alan Kay said "Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."

C++ seems like an awful stopgap solution that got out of control.

Re:Alan Kay said it best...

[russotto]

C++ seems like an awful stopgap solution that got out of control.

Yeah. And then they added templates.

Re:Alan Kay said it best...

[Anonymous Coward]

It's the deconstructionism of programming language.

Re:Alan Kay said it best...

[Rockoon]

Of all things I have seen languages become, C++ templates has got to be the single worst over-complication.

Pulling a figure out of my ass, I am guessing about 98% of templates are just implementing Generics.

The other languages that support Generics do so cleanly and simply, and then there is this C++ template monolith. Even BASIC has better generics now.

Another write-only language

[rbarreira]

So that's exaggerating a bit, but even if I enjoyed writing some C++ programs, I still find it hard to dive into C++ source code and understanding what it does.

For example... If you're reading a piece of C code and see a function call, you can find the function definition with a simple textual search. With C++ you have to look at the argument types (due to function overloading), you have to check what the object type due to derived classes, etc. What a mess it is just to find out precisely what code is behind a function call.

It's really a pain in the ass to read C++ code that you haven't written (or maybe even that you wrote some months ago).

Re:Another write-only language

[Anonymous Coward]

There are C++ IDEs that will do that for you and I have respect for the people that wrote them, because between the preprocessor and ambiguous syntax, parsing and analyzing C++ code reliably is nigh impossible.

Re:Another write-only language

[Anonymous Coward]

haha. now you appreciate why Linus Torvalds categorically refused allowing C++ into the Linux Kernel code. someone correct me if i'm wrong

Re:Another write-only language

[rbarreira]

There are C++ IDEs that will do that for you and I have respect for the people that wrote them, because between the preprocessor and ambiguous syntax, parsing and analyzing C++ code reliably is nigh impossible.

True, IDEs make it a bit easier, but they can't solve all the cases, for example when a variable's derived type isn't known.

There are also other features of C++ that make it hard to read, like the possibility of passing arguments by reference to a function. It can be pretty confusing since you're never quite sure if a variable is getting changed just by passing it to a function. With C at least you would have to explicitly pass its address, which is an immediate tell that something is going on.

Re:Another write-only language

[master_p]

You are exaggerating. Finding the appropriate function in modern IDEs is as simple as either doing text search over the function name or use autocomplete to guide you to the correct function.

Would you prefer a language that doesn't have overloading? then you would have to specify lots of different functions, all with the same purpose, but with different names. GTK is an example of this: create_button, create_button_with_text, create_button_with_text_and_image, create_button_with_image, etc.

Re:Another write-only language

[turgid]

Finding the appropriate function in modern IDEs is as simple as...

Therein lies the rub.

The point of high-level languages is to make ideas expressible clearly and simply so that the human can understand them and so that the compiler can translate them into efficient machine code.

That we need these huge, complicated, clever IDEs to be productive with many popular languages is very telling.

I've managed to get this far without an IDE. I write C every day at work, shell scripts, Makefiles and the occasional bit of C++. All I use is vim and the GNU command-line utilities. Luckily the C++ that I encounter is small enough (a few thousand lines of embedded stuff) that I don't need special tools to navigate through it. I can simply open a few files and read them.

We use CPPUNIT for unit testing, and again I don't need an IDE. I just read the header files.

Other people whose projects are completely in C++ struggle with Eclipse and SlickEdit.

I love coding. In own time I like reading about other languages. I've dabbled in scheme, Java and ruby, and one day I'll learn them properly. D looks very promising. I must try it out. C++, like PERL, is a necessary evil in our profession and I only do it when I'm paid.

The Best Language Is The One You Know The Best

[assertation]

That statement works as both a positive idea and as a negative one.

The positive being the more capable you are the more time you put in.

The negative being the trend towards techno dogmatism among programmers.

Programmers tend to be afraid of technology they are not used to, so everything that isn't their core thing tends to be labeled as "crap".

I would love to learn more languages........time!

Re:The Best Language Is The One You Know The Best

[Vectormatic]

Programmers tend to be afraid of technology they are not used to, so everything that isn't their core thing tends to be labeled as "crap".

The saddest thing is when you (as a programmer) get introduced to a new language/platform and are baited with stuff like modern OO features, and then it turns out it actually is crap...

my case.. Intersystems cache, which is basically Mumps (from pdp-7 fame) with OO tacked on, very poorly, shipped with a toolset that makes vi/gcc look like a usefull alternative...

Almost a great language.

[91degrees]

I think I'd actually like the language if it didn't try to do so much.

Adding classes to C was great. Operator overloads are really useful, virtual functions mean you can frequently avoid C's rather cryptic function pointer syntax. There are so many clever tricks you can do with scoping that makes C++ extremely useful.

After that things start to get a bit nasty. Template programming seems like such a nice idea, but it's so cryptic, and totally unreadable - and why use the triangular brackets!? . The syntax to differentiate pre and post increment seems completely arbitrary, and the headaches caused by multiple inheritance and default parameters make me wonder if they're really worth the trouble. The try/catch construct is also useful but it feels so unwieldy.

Re:Almost a great language.

[Zumbs]

Template programming seems like such a nice idea, but it's so cryptic, and totally unreadable - and why use the triangular brackets!?

Template programming is a great idea, and it is very useful in a number of cases. After heavy usage of C++ templates, I have been programming a bit in Java using generics, and, well, there are just so much stuff I can't do with generics. But I agree on your point about readability. The worst part, however, is the learning curve when you start out with your first template heavy project. Figuring out what functionality some_random_type has can be quite a challenge, particularly when there are typedefs all over. Compiler output can also be a challenge, but has improved significantly over the last few years.

Re:Almost a great language.

[loufoque]

Template programming seems like such a nice idea, but it's so cryptic

It's exactly the same syntax as the rest, except you may have to add "typename" or "template" in certain situations to help the parser.

Re:Almost a great language.

[serviscope_minor]

It's exactly the same syntax as the rest, except you may have to add "typename" or "template" in certain situations to help the parser.

Which is terrible. Given that every compiler seems to be able to compile such code without those keywords scattered around (usually as a compatibility option), it seems that they are unnecessary. They certainly make converting code in to templated code harder to do and harder to read.

Re:Almost a great language.

[loufoque]

Which is terrible. Given that every compiler seems to be able to compile such code without those keywords scattered around (usually as a compatibility option), it seems that they are unnecessary.

They are for the simple reason that at the point of definition of the template, you don't know what the parameters are.
You therefore cannot know if T::foo is a type, a value, or a template. It is assumed to be a value in the absence of any of the "typename" or "template" keywords.

Compilers that do not need them are those that do not parse template definitions until instantiation. Those that parse and generate a parametric AST, which has quite a few advantages, do.

Re:Almost a great language.

[noidentity]

C++ gives you the choice not to use those features, and doesn't make you pay for them just because the compiler supports them. So the problems with these must be because other people's code (mis)uses them.

Re:Almost a great language.

[91degrees]

It doesn't give me the choice though. It can't. Once someone else in the team uses these features, I'm obliged to use them as well.

Re:Almost a great language.

[master_p]

"and totally unreadable"

That's highly subjective. I never had any problem reading template code that is well formed.

"and why use the triangular brackets!?"

Because [] are taken for array, () are taken for functions and expressions and {} are taken for array/struct literals and blocks.

"The syntax to differentiate pre and post increment seems completely arbitrary"

Arbitrary in what degree? the whole language is arbitrary, in the way you put it. It was conceived in the mind of Stroustrup.

"and the headaches caused by multiple inheritance"

You don't have to use multiple inheritance, if you don't like it. It's not mandatory.

"and default parameters"

I've read all criticism there is online about c++, but I never saw anything about default parameters. What is your problem with them?

"The try/catch construct is also useful but it feels so unwieldy."

What's so unwieldy in it? if it could be implemented in any way that is more efficient, it would.

Re:Almost a great language.

[91degrees]

That's highly subjective. I never had any problem reading template code that is well formed.

Well, if I see some well formed template code I'll let you know...

Because [] are taken for array

< > are used for greater than, less than and bitwise shifts. Square brackets would make more sense, and not require special handling when you nest them.

Arbitrary in what degree?

What does that parameter do in the operator overload? Which one is a preincrement overload and which is the postincrement?

You don't have to use multiple inheritance, if you don't like it. It's not mandatory.

Not all of us are lucky enough to only use our own code.

I've read all criticism there is online about c++, but I never saw anything about default parameters. What is your problem with them?

base class contains virtual mymethod(int param=0). Subclass contains virtual mymethod(). Calling mymethod() gives different results if you call it on the subclass or the baseclass. What's so unwieldy in it? if it could be implemented in any way that is more efficient, it would.

Extra level of nesting and not immediately obvious where the code will jump to. Like I say, it's useful, but there has to be a better way to do this.

Re:Almost a great language.

[Rockoon]

Extra level of nesting and not immediately obvious where the code will jump to. Like I say, it's useful, but there has to be a better way to do this.

For exception handling, I am not sure that there actually is a better way. You can maintain readability with self-control, by never handling exceptions more than one call backwards from where they happened. The alternatives are error singletons/globals or the classic BASIC On Error Goto/Gosub (which is actually a super-set of modern exception handling methods, strangely enough, less structured but more powerful because of it)

Re:Almost a great language.

[91degrees]

Yes. You can do things very cleanly with goto if you know what you're doing. Here's an example

That sort of thing can't always be done though, and doesn't automatically unwind the stack or provide extra information. C++ style exception handling is so useful, I'm just sure there has to be a tidier way. I'd like something that looks more like switch/case but have no idea how this could be done.

Re:Almost a great language.

[master_p]

"Well, if I see some well formed template code I'll let you know..."

You should have already let me know, because there is plenty of well formed template code around...

" are used for greater than, less than and bitwise shifts"

But are not brackets; the rest ((), [], {}) must be always paired. It makes a lot more sense to use ,

"Square brackets would make more sense"

To you, maybe.

"and not require special handling when you nest them."

How come? the grammar would still be ambiguous.

"What does that parameter do in the operator overload? Which one is a preincrement overload and which is the postincrement? "

Nothing, the parameter is there to tell the postfix operation from the prefix operation. It's not so bad that requires a slashdot comment. Would you prefer a keyword?

"Not all of us are lucky enough to only use our own code."

No major toolkit uses multiple inheritance. I don't know why you are bitching about it.

"base class contains virtual mymethod(int param=0). Subclass contains virtual mymethod(). Calling mymethod() gives different results if you call it on the subclass or the baseclass."

And that's how it's supposed to work. The opposite is not just possible.

"Extra level of nesting"

It's necessary because the statements inside the try block need to be a different block from the rest of the code.

"and not immediately obvious where the code will jump to"

That's the point of exceptions.

"Like I say, it's useful, but there has to be a better way to do this."

Oh yeah? you are the smart one to discredit all language designers that came before you? please show us the better way to do this.

Re:Almost a great language.

[91degrees]

To you, maybe. Yes. This is my opinion. I also think that ! would make at least as much sense for destructors as ~ but look nicer:)

No major toolkit uses multiple inheritance. I don't know why you are bitching about it.

Because we don't all use major toolkits.

And that's how it's supposed to work. The opposite is not just possible.

If I call baseclass->mymethod() and mymethod is virtual, typically I expect it to call the subclass if baseclass is actually an instance of subclass. C# solved this problem by forcing you to be explicit about overrides.

It's necessary

I know it is. It's still an annoyance that I'd rather avoid.

That's the point of exceptions.

I thought the point was that it was obvious.

Oh yeah? you are the smart one to discredit all language designers that came before you? please show us the better way to do this.

Just because I can't come up with a better way doesn't mean there isn't one and it doesn't mean I can't consider it unwieldy.

Re:Almost a great language.

[noidentity]

No different than when a team-member on a C-only project puts in lots of preprocessor crazyness. The problem is the team-member, not the language.

Re:Almost a great language.

[master_p]

"This is my opinion"

Well, it's a wrong opinion. Think about it again and you will see why angle brackets are chosen.

"I also think that ! would make at least as much sense for destructors as ~ but look nicer"

~ is much easier to spot than !.

"Because we don't all use major toolkits. "

Why don't you blame the designer of the code you are using then, instead of blaming the language?

"If I call baseclass->mymethod() and mymethod is virtual, typically I expect it to call the subclass if baseclass is actually an instance of subclass. "

You are not calling "baseclass->method()", you are calling "baseclass->method(data)".

"C# solved this problem by forcing you to be explicit about overrides."

It's a non-problem.

"I know it is. It's still an annoyance that I'd rather avoid."

Perhaps you also want the computer to understand English to write the code for you?

"I thought the point was that it was obvious."

The point of code that the will be executed after the exception is not obvious in any language.

"Just because I can't come up with a better way doesn't mean there isn't one and it doesn't mean I can't consider it unwieldy."

Yes, there isn't one. Believe me. Try to make a programming language and you will see.

Re:Almost a great language.

[91degrees]

You'll use the template parameters on declaration and instantiation. Square brackets don't get used for declaration so no conflict there. For instantiation you're always going to follow with a template paramter anyway, so there's no conflict.

~ is much easier to spot than !.

That's not why it was chosen.

Why don't you blame the designer of the code you are using then, instead of blaming the language?

Any language that has a feature that causes more headaches than solutions, is not needed, and where most coding standards say "don't use this feature" strikes me as flawed.

You are not calling "baseclass->method()", you are calling "baseclass->method(data)".

I know. I was expecting to be calling the method I'd specified. It's not obvious which wil be called.

Perhaps you also want the computer to understand English to write the code for you?

Yes, but that's not possible. I'll settle for languages that make things less cryptic.

Coders fault - Not the language

[AnonymousClown]

I can't stand C++, it's all but unreadable to me.

That's because just about every C++ coder wants to be the guru (and maybe find the error that gets the $2 check from Bjarne - I actually saw one and the guy who got it framed it!) so, what do they do? Ever frick'in chance they get, they have to use some esoteric feature of the language in their development regardless if it's appropriate - I've done it too. For example, how many of you fellow C++ guys made a template class even though the class would only deal with one data type for ever and ever and ever? Or overloaded an operator just for the sake of overloading it - operator overloading back in my day was the most over used and abused feature in C++.

When I got over the guru thing, I always tried to keep my code well documented and used features sparingly.

For the record, templates can be awesome such as when using the STL - that saved so much grunt work!

Re:Coders fault - Not the language

[Anonymous Coward]

For example, how many of you fellow C++ guys made a template class even though the class would only deal with one data type for ever and ever and ever?

When I was a much less experienced developer, I used to think I knew how something would be "for ever and ever and ever". Sometimes, I was even right, but of course not because I actually "knew" it - that's just how it happened to work out in some cases. For more often, my crystal ball and Miss Cleo failed me.

As with any other tool, I use generic programming when I deem it worthwhile. Sometimes I'm doing a little extra thinking for a future that never happens. Sometimes I come back to a piece of code after a few years and realize a little extra flexibility saved my later self some serious maintenance headaches.

- T

Re:Coders fault - Not the language

[IICV]

Or overloaded an operator just for the sake of overloading it - operator overloading back in my day was the most over used and abused feature in C++.

Indeed! The fact that it was so hideously abused is the reason why it's simply not possible in Java (except for the String class, but that's another discussion). Back then, though, it made sense to not have it. Without modern IDEs, it's almost impossible to just look at a line like c = a + b and actually know what's going on unless you have a thorough understanding of classes a, b and c. I mean, does it somehow append data from a and b and then replace some part of c? Or does it actually do a set sum from a and b and then append that to c? Or does it make monkeys fly out your nostril? Who knows?

It's slightly better with a modern IDE where you can just say "show me the code and/or docs for a's + overload and c's = overload", but even then while reading the code you have to keep in mind that + actually means "sum of sets" and = actually means "make monkeys fly".

And the only thing you gain from it is more concise code. I mean seriously, does it really save you that much over, say, c.appendData(a.setSum(b))? Sure, the first thing is shorter, but I would argue that you spend more time thinking about the former than you do the latter.

Re:Coders fault - Not the language

[David Greene]

And the only thing you gain from it is more concise code.

No. You've completely missed the point. Operator overloading as simple syntactic sugar is useful and easy to read but its real power is in the context of generic programming. What the operators give you is a standard textual API for calling methods. In other words, I can write some generic code to do a = b + c and it's work for int, float, some matrix class or strings, provided they've overloaded the standard operators.

Yes, this could be done with named methods, something like "a.assign(b.plus(c))" but some class could call "plus" "add" or "addition." The operators give us a standard naming convention.

Re:Coders fault - Not the language

[Rakshasa Taisab]

A kid that does not play is a grown up who does not know how to do anything.

All those C++ coders that were using 'esoteric' (wait, template class is esoteric?... you do _NOT_ want to see my code then) were getting experience in writing more complicated code than what the task at hand would have given them normally. This is not necessarily a bad thing, as one day they'll actually _NEED_ that experience.

Re:Coders fault - Not the language

[JamesP]

AMEN TO THAT

C++ is like barbecue sauce. Too much and it will ruin everything.

One of the most important things in a C++ project is setting coding style and clear rules of what's ok/not ok.

So you don't have 10 levels of inheritance, 'creative use' of STL, etc, etc

Re:Coders fault - Not the language

[140Mandak262Jamuna]

10 levels of inheritance is not a problem, if it makes sense. But multiple inheritance that has the same base class twice in the tree! Oh yeah, it can be done and C++ test has questions about it too. But if you ever use it in my project, I will fire you.

Re:Coders fault - Not the language

[David Greene]

This can be used effectively when you have mixins with a need to "cross cast." Never say never. It's certainly a niche thing but it's there for a reason.

Re:Coders fault - Not the language

[MadKeithV]

The operators give us a standard naming convention.

And by "standard" you mean:

• It might be bit-shift, or it might be stream insertion. (<<)
• It might be addition, or it might be concatenation. (+)
• Someone thought it might be nice to add "chaining" (,)
• You might be dereferencing a pointer, or there may be some smart pointer shenanigans (->)

Re:Coders fault - Not the language

[Burnhard]

So you don't have 10 levels of inheritance, 'creative use' of STL, etc, etc

C++ is an obfuscationists dream, especially when people start to do clever "tricks" with templates. If you've ever peeked into the boost:: libraries, you'll see what I mean. But I don't want to do away with it because let's face it, you can do that with any language (to me Perl looks like an utter mess). If you use a good coding style (lots of whitespace) and patterns like dependency injection, smart pointers, RAII etc. it generally works well.

Re:Coders fault - Not the language

[Burnhard]

There's almost always a different way to design your hierarchy that will avoid the problem. Over the years I've come to despise the whole concept of "hierarchy" in any case, because few problems map naturally to a single solution (there's too much ambiguity). I much prefer to use encapsulation wherever possible instead. I do use inheritance of course, but mostly I inherit abstract interfaces that gradually build to a single concrete interface. Where implementation details are similar between concrete classes, instead of making one a base and deriving for the other, I will prefer a third class that contains the behaviour both will use that can be encapsulated, rather than inherited.

Re:Coders fault - Not the language

[David Greene]

Well, "add" might be addition or concatenation. Any function might do something unexpected. "foo" might have all sorts of strange side-effects. The name hardly matters.

Re:Coders fault - Not the language

[David Greene]

Sure, encapsulation is usually the better choice, but many things map naturally to inheritance and multiple inheritance. In my case it was a compiler IR, which is naturally tree-like.

Re:Coders fault - Not the language

[marcosdumay]

All of you complainind about C++ templates never played with the preprocessor, did you?

Re:Coders fault - Not the language

[Burnhard]

Sure we did. They're better than the preprocessor of course, but that isn't to say they aren't over-used in many cases. The example I gave was a good one in that templates there are used solely to generate tighter code, rather than because there is some problem that needs solving with generics. In return for the tighter code, you get an almost incomprehensible source file.

Re:Coders fault - Not the language

[hazah]

There go your mixins. Seriously. Panic much?

What I want to know is...

[Black Art]

Does Bjarne Stroustrop think of women as objects?

Re:What I want to know is...

[gparent]

No. Functions.

Re:What I want to know is...

[AragornSonOfArathorn]

Does Bjarne Stroustrop think of women as objects?

Mr. Stroustrop treats objects like women, man....

Re:What I want to know is...

[Anonymous Coward]

Only in a generic sense...

- T

Re:What I want to know is...

[Anonymous Coward]

No no - women are the class. I'm sure he prefers to focus on a particular instance.

Re:What I want to know is...

[noidentity]

Perhaps uninitialized objects that thus have indeterminate values at any time, and might even crash if you try to read them to determine their value.

Re:What I want to know is...

[physburn]

Why think of women as object? Because they keep on objecting!

Re:What I want to know is...

[physburn]

Woman don't fit into a class hierarchy,

function quim(), changing from public to private depending on weather she subclasses pornstar.

Re:What I want to know is...

[physburn]

but men fit even less, because function dick(), changes from private to public to not function, depending on the value of the blood alcohol variable.

Re:What I want to know is...

[Bazouel]

Only if they don't have class ;)

Re:What I want to know is...

[master_p]

It depends...if they have a public interface.

Re:What I want to know is...

[Anonymous Coward]

No, merely instances of objects.

Re:What I want to know is...

[teh kurisu]

No, because that would imply that women are first class citizens.

"Portable computer"

[bonch]

When was this written, 1978? "Portable computers" are called laptops or netbooks.

Re:"Portable computer"

[puto]

Actually in spanish they are called Portatiles. Which means portable.

Re:"Portable computer"

[Vectormatic]

i'll probably get flamed to hell for this, but that sounds like some sort of excellent mexican food...

Programming Machismo

[gmurray]

I do believe that anyone that claims to actually like working with C or C++ is either

1) Unfamiliar with any languages that don't let you shoot yourself in the face so easily.
2) More like a machine than a man.
3) Trying to show off his "hacking skillz".
4) Being overly nostalgic.
5) Hasn't actually used C or C++ in about a decade.


IMHO using C or C++ when not necessary displays a depressing amount of machismo and masochism. Why do it to yourself?

Re:Programming Machismo

[rbarreira]

I like to work with C and I don't think any of that applies to me.

Re:Programming Machismo

[gmurray]

Could you explain concretely what you like about working with C?

I used to claim the same thing, but after years not being required to use C, in hindsight, I can chalk up every reason I enjoyed it to senseless machismo, and my most concrete memories are of all the time of mine C wasted by not warning of or preventing egregious errors from simple typographical mistakes.

I would never choose C if starting a new project, and it still baffles me that some do. But to each his own I guess :) Just glad I don't need to read their code!

Re:Programming Machismo

[igomaniac]

You forgot:

6) Paid a lot of money to do it.

Re:Programming Machismo

[gmurray]

I'm not sure, though, that would actually make you like it ;-)

You'd keep doing it if the money was good enough, but like it?

Re:Programming Machismo

[rbarreira]

Could you explain concretely what you like about working with C?

I like working with C because it gives me almost all the performance of Assembly language and almost all (or for many applications, all) the ease-of-use of higher-level languages. It's also good to know that whatever new machines or architectures pop up tomorrow, there is bound to be a good C compiler for it, which is more than you can say about most other languages.

Just glad I don't need to read their code!

I don't see how well-written C code is so much harder to read than well-written code in Python, Java, or whatever...

Re:Programming Machismo

[eddy]

7) lower uid than you on slashdot.

I have one rule about C++ complaints; I don't listen to them unless the person behind them indicate that they've actually read "The Design & Evolution".

Too much like listening to high-schoolers discussing "2.999... is 3" or doors with goats behind them otherwise.

Re:Programming Machismo

[melted]

6. Has to run his stuff in a very large datacenter using one third of the RAM and half as many machines higher level languages would require, faster.

Re:Programming Machismo

[tjb]

C (and increasingly C++) is the lingua franca of systems programming - you cannot live without it in the embedded or kernel-level world. Its entrenched, it works, and it functions quite nicely as a portable assembly language. Using anything else is as silly as speaking in esperanto.

Re:Programming Machismo

[serviscope_minor]

I do believe that anyone that claims to actually like working with C or C++ is either

Blah blah blah. That's great. Now suggest another language. One that isn't:

1) Slower
2) Lacks static typing
3) Less expressive
4) Less portable (you know C++ runs on an Atmel AVR, right?)

I also strongly suspect that whatever language you suggest isn't:

5) Standardised
6) As well tested, thereby revealing so thoroughly any flaws.

I also very strongly suspect that the language you suggest has:

7) A worse standard library. I happen to like having heap and nth_element. It's much more useful to me than a GUI or sockets library.

Finally, I suggest that anyone who blindly dismisses C++ while assuming that everyone who uses it must be wrong headed is:

8) an idiot.

Re:Programming Machismo

[gmurray]

Using C because its "more efficient" is like making tons of micro-optimizations before you even know where your performance problems are. It just wastes time and means you eschew the use of more appropriate tools for the task at hand.

I've never once been so dissatisfied with the performance of a higher-level language (that compiles to native code) that I've had to bust out the C compiler. Even then it would make sense to only code the performance critical section in C and leave the rest to a more productive language.

Starting with C is just asking to spend time making optimizations you may never ever need. YAGNI. Wait till you need to optimize before you even consider C, is what I say, and if you are forced to use it, you don't have to like it! :)

You can argue that well written C code is easier to understand, but the reality is that certain languages (C, C++, JavaScript, vb6) feel like they are designed to encourage developers to be incredibly sloppy. So in practice when you try to read them you are presented with monolithic code written in alien dialects.

Yes, you can write indecipherable code in any language. But I think a sensible language should at least try to discourage it.

Re:Programming Machismo

[gmurray]

There's that machismo again. Zip your pants back up, I don't have a ruler on me.

Re:Programming Machismo

[gmurray]

Perhaps read my statement a bit more carefully. I'm not calling anyone that uses C++ wrong-headed. Now if you use it and enjoy it, thats a different story.

I am being the devil's advocate to a degree here. I'm genuinely interested in the reasons people have to LIKE C++. Not just the reasons why they NEED to use it.

Re:Programming Machismo

[gmurray]

but is that a reason to LIKE it, or a reason you NEED it. Even then, I would argue only the most performance critical pieces might need conversion to C. Why start with C?

Re:Programming Machismo

[rbarreira]

Using C because its "more efficient" is like making tons of micro-optimizations before you even know where your performance problems are.

No, it is not like that at all. Especially since C already gives you most of the features that make higher-level languages easy to use (variable names, records, control structures etc.). So you're getting more efficiency without making extreme efforts (unlike what your analogy would imply).

Just as early optimization is bad, I also consider early "pessimization" to be bad, and in many cases you already know from the start that your application will have to be efficient.

It just wastes time and means you eschew the use of more appropriate tools for the task at hand.

What makes you think that there are more appropriate tools for the task at hand? Sure, for some tasks there may be. But not for all tasks, and I think we're straying a bit from the original point which is that C can be nice to work with. No one's saying that it's always the best choice.

But I think a sensible language should at least try to discourage it.

I'm not so sure. Bad programmers always find ways to shoot themselves in the foot, no matter how much the language tries to cripple their efforts.

Re:Programming Machismo

[serviscope_minor]

I guess I like using it because every other language is worse for what I do. I tend to do a lot of data processing which makes use of a lot of for-loops and generally I use a lot of templated container like classes.

I haven't found any other language which gives me the expressivity I need for these kinds of problems along with the speed.

Re:Programming Machismo

[Anonymous Coward]

It's also good to know that whatever new machines or architectures pop up tomorrow, there is bound to be a good C compiler for it, which is more than you can say about most other languages.

Reminds me of a thing that happened to me when I tried out C on ARM for the first time.
For some reason I ended up with a lot of variables in a subroutine. This resulted in some of the variables to be stored on the stack, not really a problem.
The compiler however had a slightly different opinion than me on how to handle postincrement on pointers when they were stored on the stack.
First it loaded the pointer to a register, then it used the pointer for the access. After the operation it stored the pointer back on the stack and then incremented the register.
Took me a while before I figured out that it was the C-compiler that was broken and not my code. Had to dig through a lot of assembler output before I found the problem too.

Re:Programming Machismo

[Anonymous Coward]

Common Lisp can meet or come close to meeting C++ in all but 4 and 7. Lisp is a more expressive language (macros beat templates), and CL gives you the option of interpreted & dynamic in addition to compiled and statically typed. Having a REPL makes prototyping much faster. OCaml might also be up the challenge.

Re:Programming Machismo

[Stevecrox]

It's not harder to read well written C++ code than Java, however it is easier to read badly written Java than medicore C++.

It's my one issue with C++ code, with Java our workplace has a development environment with Checkstyles, Code Formatters and analysis tools like PMD and find bugs. It makes even the new graduates code readable and fairly standard. I've never found anything like that for C\C++.

Re:Programming Machismo

[jjohnson]

No, you're calling anyone who enjoys it wrongheaded. You state categorically that anyone who likes it is a member of the sets described by points 1 to 5, none of which are complimentary or admit of any sincere and technically knowledgeable appreciation for the language. You basically say that a good programmer couldn't possibly like C++.

I haven't done much C++, but what I've done I've enjoyed a lot. It's a language that both demands and rewards precision in thought in a way that no scripting language or garbage collected language ever can. It's an expert tool with no beginner's mode, and is that much more rewarding when you do something right.

To deal with your points:

1. I've programmed non-trivially in Perl, C, Java, C#, and Python.
2. Not sure what this means.
3. All of my C++ was for personal projects that never saw the light of day. They were pursued entirely for my own experience.
4. I enjoyed C++ while I was working with it, not afterwards.
5. See point 4.

Re:Programming Machismo

[jjohnson]

That's awesome how I wrote an indignant post defending both C++ as an expert language, and myself as at least a competent and serious programmer, and then blew closing the em tag.

I guess that's my refutation of point 2.

Re:Programming Machismo

[gmurray]

I was calling programmers that enjoyed c++ masochistic and in excess of machismo, not unskilled, and as I've alluded to in other replies, mostly to illicit some kind of interesting defense of their like of this language. Because, honestly, I'm curious. C/C++ eroded my goodwill long ago.

You can wax lyrical about the warm feeling you get when you are careful and your C code works, against the odds, but usually getting C code to behave without error just seems to waste large amounts of time, which, IMO, makes it very hard to like.

Re:Programming Machismo

[russotto]

It's not harder to read well written C++ code than Java, however it is easier to read badly written Java than medicore C++.

Unless it's written using J2EE, Struts, Hibernate or any of a number of Java-world things which hide half the logic in a series of configuration files, each more diabolical than the last.

Re:Programming Machismo

[jjohnson]

C++, perhaps more than most other languages, but like C, requires that much of the discipline reside in the programmer. I think if you read the responses here from C++ defenders, you'll note a common theme, which is that they are productive and not masochistic largely because they internalize the discipline to use it well. This includes learning idioms and best practices like RAII, but generally it involves acting like a highly professional programmer.

One of my hobbies is watercolor painting. More than oil or acrylics, watercolor is a delicate medium that's unforgiving of mistakes, but mastering the material is very rewarding, allowing one to achieve certain visual effects that are unavailable in other mediums. This is how I feel about C++. Like golf, it takes a long time to learn to do well, and there's always some way to improve; but doing it well is tremendously fulfilling, both in terms of results and the feeling that discipline and commitment paid off.

That's not machismo.

Re:Programming Machismo

[aiht]

Hear, hear.
You put that beautifully, and I wholeheartedly agree with you.

Re:Programming Machismo

[m50d]

Most modern applications want higher level data structures and algorithms. Which, sure, you can implement in C, but when you do that your code becomes a lot harder to read. In a modern high level language a hash set literal looks something like { 123: 'foo', 456: bar}. In C I dread to think how many lines that would be; all the nice syntax has been used for lower-level things like arrays. Heck, even an object method call in C looks syntactically nasty.

Re:Programming Machismo

[rbarreira]

Ummm... just a simple array of structs { {123, "foo"}, {456, "bar"}, and then just make a function that adds each element to the hash.

It's really not complicated, and btw most reasonably big programs wouldn't have magic literals like that scattered through the code, instead they would be in a configuration or data file that the program loads to memory.

Re:Programming Machismo

[LizardKing]

I have one rule about C++ complaints; I don't listen to them unless the person behind them indicate that they've actually read "The Design & Evolution".

Well I've read Bjarne's apology / justification, and take it from me, C++ is still awful.

Re:Programming Machismo

[melted]

>> Why start with C

Well, it's C++ in my case. The answer is, because I write software that will run in a very large datacenter. In addition, the set of C++ libraries and coding rules we're using here at work makes C++ not nearly as horrible as it is otherwise.

It's still hard to do multithreading, but other than that, it's actually pretty good.

Re:Programming Machismo

[m50d]

Ummm... just a simple array of structs { {123, "foo"}, {456, "bar"}, and then just make a function that adds each element to the hash.

Yeah, so something like

struct hash *h = hash_create();
for(int i=0, i < 2; i++) { hash_put(l[i][0], l[i][1]);}

Shudder. Of course you'd put the loop in a function, but you still have to write it.

It's really not complicated

No, it's not. None of the individual things that C makes harder is, in itself, much harder than the higher level equivalent. But they all add up.

and btw most reasonably big programs wouldn't have magic literals like that scattered through the code, instead they would be in a configuration or data file that the program loads to memory.

Only if they came from somewhere fond of overengineering. Often such literals do belong in the code. Sure, I could have gone for a real-world problem, but they tend to be too long; at the other end of a scale, artificial examples like Knuth's "man or boy test" or Graham's "accumulator generator" make the difference clearer. But the hashmap literal is the most succinct example I have that comes directly from my own, real-world experience, and it tends to be the first thing I look at when learning a new language.

Re:Programming Machismo

[rbarreira]

Shudder. Of course you'd put the loop in a function, but you still have to write it.

Yeah, once (or maybe zero times if you use an existing hash library). Of course you would make a function that could insert any number of elements. A handful lines of code, no big deal at all (certainly not big enough to dismiss a language)...

Re:Programming Machismo

[m50d]

But everything in C is like that - you have to implement all the higher level functionality yourself. Sure, it's a full programing language, so you can implement functions to give you a decent language on top of it (though since you don't even have object methods the syntax is never going to be nice), cf Greenspun, but you'd be better off just using a better language to start with.

Re:Programming Machismo

[rbarreira]

What part of "use standard libraries" don't you understand? Every language is going to have things missing, with C you have the minimal stuff which always performs well in the language, and everything else is up to you.

I'm not saying you always need this flexibility, that's what other languages are for... Choose them for the projects that they make sense on, and admit that C is the best choice for certain kinds of programs. There's nothing that comes close to C in its combination of efficiency, simplicity and portability.

Re:Programming Machismo

[m50d]

Libraries can't give you everything - they can't modify the language syntax, for example, so you'll be forced to nest function calls to accomplish anything. And depending on libraries external to the language brings its own problems. Yes every language will be missing some things - but languages which include more useful things are better than those that include less.

This makes C "flexible" and "simple" in the same way that an empty lot is simpler and more flexible than a house. C-the-language may be simple, but actually solving a given problem in C is more complex than doing the same in anything else, because C forces you to absorb all the complexity of the problem yourself.

There may still be a few projects for which C is the best choice, but they're very, very niche. Claiming "portability" is a joke unless you're comparing to assembly language (which, to be fair, C is in much the same position as these days). As for efficiency, the performance advantage is slim-to-none compared to, say, java (a language I hate, but that's for another time), and would be dwarfed by the impact of any of the mistakes it's all too easy to make in C. For C to be the most efficient choice, the programmers would have to be good enough to write C and find the bugs (and such programmers don't come cheap), and yet a small gain in performance would have to be worth a huge cost in programmer productivity, meaning the cost of performance differences would have to be absolutely huge.

Re:Programming Machismo

[rbarreira]

Did you really just say that C is as portable as Assembly language? Are you really unaware of the myriad of C libraries and other software which is multi-platform?

Not that that's the only great exaggeration you made during this argument.

Re:Programming Machismo

[m50d]

No, I said that portability is not an advantage of C unless you're comparing to assembly language. Assembly aside, C is not substantially more portable than any other vaguely mainstream language language, and compared to many languages, it is substantially less portable.

Re:Programming Machismo

[rbarreira]

Mainstream programming languages (ignoring web server stuff): C++, Java, Perl, Python, C#, Visual Basic.

C is definitely available for more architectures and operating systems than any of these.

Re:Programming Machismo

[m50d]

Are you sure? Java runs on a number of microcontrollers that haven't bothered with a C implementation. It's a very rare system that would have C and not have at least C++/Java these days (since the cheapest way to get a C compiler for your new system is to write a gcc backend, and that gets you C++ and java for free). And since perl/python/C# have interpreters written in C, if you have C it's pretty straightforward to get them.

More to the point, while another system will have a C compiler there is no guarantee at all that your program will work correctly on it. Wheras with java/perl/python/c#, the same program works on any system.

C++ is the Beatles of Programming Languages

[wandazulu]

First there was the "red" album: straightforward rock-n-roll with some interesting wordplay, but with only a few general themes. C++ was the same way: create some objects, work with 'em, pass 'em around. All good.

Then C++ discovered acid and got into its "blue album" phase: multiple inheritance, templates, operator overloading, namespaces. To read C++ now is like listening to the later Beatles: obtuse, baffling, with a fair amount of brilliance that makes you wonder "how did they do that?????" It confirms that there are always smarter people than me if only to be able to make sense of it all...

 

Re:C++ is the Beatles of Programming Languages

[multipartmixed]

So, you're saying that C programmers have a rubber soul, and C++ programmers have revolvers?

No, you've got it all wrong!

[Scarred Intellect]

Bjarne Stroustrup hated C++! Any day now, C will rise again and be the dominating force!

"Some surprising revelations"

[Dystopian Rebel]

TFS: "There's some surprising revelations in here, too, as his portable computer runs Windows"

Very well, I am a long-time supporter of FOSS too, but I'll feed your troll: How is BS's use of M-Windows a surprise?

Is it because M-Windows has bad C++ development tools?

Is it because M-Windows is not the dominate OS?

Is it because C++ should only be used in FOSS?

Is it because BS should share your opinions or be damned?

Revelation???

[Anonymous Coward]

"There's some surprising revelations in here, too, as his portable computer runs Windows."

This is some kind of revelation? The revelation would be if he didn't run any instance of a Windows setup. The submitters bias is being overlayed onto Stroustrup for some reason, but for the sake of the rest of us he should only pose it as his (the submitters) revelation rathar than giving what seems to be a false impression that Stroustrup is anti-windows in some way.

C++ Is Usually Taught Incorrectly

[MichaelCrawford]

Another poster lamented C++ as being a terribly, messy language, and said it was nothing better than C with Classes.

If all you write is C with Classes, you'll get a leaky mess full of crash bugs that you'll never be able to do away with.

But if you write C++ the way C++ wants to be written, it's actually a very easy language to write leak-free, bug free code with. Memory management in particular is very easy with RAII - Resource Allocation Is Initialization. Smart Pointers are RAII applied to heap blocks, but it should be applied to every allocated resource, such as database locks or file handles.

A while back I wrote a style guide that summarizes much of what I know about C++: Pointers, References and Values.

The problem with C++

[RzUpAnmsCwrds]

C++ is successful for one big reason: it provides most of the advantages of C with the conveniences of an object-oriented language. Performance is excellent (close to C, which with a good compiler is close to hand-written assembly in most cases) and there's enough capability that you can write just about anything in it, including things that you would never consider writing in manged languages (like device drivers or the VM for those managed languages).

The problem is that the developers of C++ have trouble saying "no". There are a bunch of C++ features that aren't really necessary, but that exist either out of legacy or because someone thought it would be a good idea.

Look at Google's C++ style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Inheritance

Like most users of C++, Google uses a severely restricted subset of the language. The thing is, most of what Google has left out is quite frankly unnecessary for 99.9% of C++ users. But we're all stuck with it anyway.

Once you get past some of the C-legacy anachronisms and restrict C++ to a small subset of its functionality, it's actually a nice language. The problem is that we can't take things out at this point.

Re:The problem with C++

[serviscope_minor]

Performance is excellent (close to C,

And often faster. Compare e.g. std::sort to qsort.

The problem is that the developers of C++ have trouble saying "no". There are a bunch of C++ features that aren't really necessary, but that exist either out of legacy or because someone thought it would be a good idea. Look at Google's C++ style guide:

Did you actually read the style guide? It mostly says, don't overuse features like operator overlaoding, etc, not never use them. The only feature not used is exceptions which they note would generally be a good idea to use if only they didn't have so much bad code lying around.

restrict C++ to a small subset of its functionality

Like what? The usual candidate are:

Operator overloading? There goes streams, those nice maths libraries of various sorts, std::vector and a whole bunch of other handy stuff.

Tempates? There goes the STL. And a whole bunch of other really useful libraries.

Exceptions? You may enjoy checking the return value of every function and writing classes with .is_valid() methods. I don't. You did make sure you checked *every* return value, right?

Re:The problem with C++

[degeneratemonkey]

Some of Google's style guidelines are surprisingly nonsensical. It seems ludicrous that anyone would recommend against using exceptions and RAII judiciously to avert a number of expensive maintenance caveats. To even suggest that "Init" methods or uninitialized states are suitable alternatives to exception throwing... really? While some of their guidelines are trivially obvious to any seasoned C++ veteran, I still question the competence of whoever authored that document. To suggest that a need for RTTI is necessarily indicative of a design flaw is severely narrow-minded. It is true that many practical uses of RTTI are awful abuses by bad developers writing sub-par code. There are legitimate uses for which there are no better alternatives, and to reject their use as a matter of policy is a mistake.

The restrictions on Boost usage are also difficult to understand (C++0x is understandable, but only due to insufficient implementation). I think my favorite terrible exerts from the whole guide are these gems of irrationality:

As with Boost, some C++0x extensions encourage coding practices that hamper readability—for example by removing checked redundancy (such as type names) that may be helpful to readers, or by encouraging template metaprogramming. Other extensions duplicate functionality available through existing mechanisms, which may lead to confusion and conversion costs.

and

Some Boost libraries encourage coding practices which can hamper readability, such as metaprogramming and other advanced template techniques, and an excessively "functional" style of programming.

Really? "Excessively functional style of programming?" Template metaprogramming is inherently evil? Policies like these are products of fear and ignorance.

Re:The problem with C++

[David Greene]

Like most users of C++, Google uses a severely restricted subset of the language.

Actually, I don't see much restriction there at all. Mostly style guidelines. Google, a most projects, too easily dismisses multiple inheritance, but that's there problem, not mine.

Projects that severely restrict how C++ can be used are shooting themselves in the foot. I've seen it multiple times. Once you grok the "C++ way" it becomes pretty easy to write portable, safe, fast code

Re:The problem with C++

[cheesybagel]

C++ streams suck. Operator overload is mostly useful for things that arguable should come built-in with the language such as complex numbers and matrix math.

Re:The problem with C++

[martin-boundary]

Exceptions? You may enjoy checking the return value of every function and writing classes with .is_valid() methods. I don't. You did make sure you checked *every* return value, right?

Which code is easier to review for correctness?

1) A function call immediately followed by an exhaustive list of local checks for all the possible return values.

2) A function call that throws exceptions, which may or may not be handled at several levels throughout the code base, ie nonlocally.

It may not be as much fun, but 1) is the better engineering practice.

Re:The problem with C++

[Anonymous Coward]

Look at Google's C++ style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Inheritance

Like most users of C++, Google uses a severely restricted subset of the language. The thing is, most of what Google has left out is quite frankly unnecessary for 99.9% of C++ users. But we're all stuck with it anyway.

Once you get past some of the C-legacy anachronisms and restrict C++ to a small subset of its functionality, it's actually a nice language. The problem is that we can't take things out at this point.

C++-- ??

Re:The problem with C++

[Anonymous Coward]

#2 by overwhelming amount. #1 quickly becomes unmaintainable unless you add more programmers for any substantial size codebase.

Re:The problem with C++

[Espressor]

1) is more labor-intensive (programmers are lazy) than 2) (it's risky to catch an exception and not let it fly unless you know exactly what you must do to recover correctly). So, in practice, 1) will generate more bugs. Not because it a worse engineering practice, but simply because it's more error-prone.

Re:The problem with C++

[Anonymous Coward]

For the the most damning guideline they have is:

Minimize use of vertical space

That was no doubt written by someone who has never had to maintain code that wasn't their own.

I always use vertical space to delineate logical blocks of code. It helps separate each step of the code. If it's all mashed together with very little vertical space then it's very hard to read and understand what the code is doing because it's not broken into steps. I will say mashing it all together seems to be a popular way of coding even though it's totally, completely wrong. When people see my code the comment I hear most often is "wow, that's good code" mostly because of the way I format it, making it extremely easy to follow.

Re:The problem with C++

[weicco]

Exceptions? You may enjoy checking the return value of every function and writing classes with .is_valid() methods. I don't. You did make sure you checked *every* return value, right?

I'm sorry if this isn't what you meant but I just had to point out that, at least IMHO, exceptions shouldn't be used as return values. Return value is a, well, return value but exception is for something exceptional. For instance AllocateMemory(int len) method would return void pointer pointing to the newly allocated block or throw OutOfMemory exception if system is out of memory.

Re:The problem with C++

[Anonymous Coward]

Features that at one time I thought weren't useful and just complicate things have proven to be very useful. It is just that there are some that people don't know how to use effectively. e.g. multiple inheritance isn't very useful for most OOP designs but it is awesome when you use it with templates to do mix-ins.

Google's guide is one of the worst I have seen. It bans the use of exceptions in the only language I have seen that does it right. Maybe most programmers don't use some of the features of the language. But the solution is more education, not dumb everyone down to the least common denominator.

It is better to have to deal with learning a complex language and the resultant simple code than to learn a simple language and have to deal with complex code.

Re:The problem with C++

[aiht]

Thank you! If I hadn't done a quick bit of digging to refute your claims, I wouldn't have found out about std::complex.
Oh, and I disagree with your claims.

Re:The problem with C++

[21mhz]

It bans the use of exceptions in the only language I have seen that does it right.

You don't say. But to their defence, they also ban the use of exceptions in C++, and for very good reasons.

Re:The problem with C++

[Rogerborg]

Policies like these are products of fear and ignorance.

Fear, yes, but fear based on knowledge. The hardest task for software engineers in the real world is maintaining "clever" code lashed out and abandoned five years ago by some Goddamn wunderkind who then moved on to spamming the latest buzzkeywords over his next abandoned project.

Now shush, grown ups are talking.

Re:The problem with C++

[master_p]

"Performance is excellent (close to C, which with a good compiler is close to hand-written assembly in most cases) "

Performance is actually equal to C for the same type constructs. If you use no virtual functions, for example, member function calls are C calls, in reality.

Re:The problem with C++

[Anonymous Coward]

You're roughly right. Most of what Google left out is unnecessary for 99% of the users. But there's about 1% for which that's vital. Here's the sticking point: Amongst those 1%, you will find a lot of library writers. And the other 99% of the users shouldn't be writin libraries, but using them. Giving library writers better tools (such as move constructors in C++0x) benefits them all.

Re:The problem with C++

[theCoder]

Clever code? The Google guidelines forbid things like exceptions and dynamic_cast (and other RTTI). Are exceptions really that uncommon as to be labeled "clever"? They also discourage the use of inheritance (guess that's why you don't need RTTI) and even simple operator overloading, like operator==(). Really, operator==() is just the C++ name for equals(). They also discourage the use of operator=(), operator(), and streams in general.

I suppose their restrictions are internally consistent (no need for operator if you're not using streams, no need for RTTI if you have minimal inheritance, etc), but they turn C++ into "C with classes". It makes the code more understandable if you're a C programmer, but for a good C++ programmer, who understands things like templates, exceptions, and inheritance, a lot of those restrictions are very limiting. A good C++ programmer means that banning the use of exceptions just means that your code is probably not going to be exception safe, and will likely have problems when an exception is thrown through it (like a bad_alloc exception if you run out of memory). Unlike the GP, I think the things Google leaves out are incredibly important to writing good C++ code instead of just "C with classes."

Re:The problem with C++

[Anonymous Coward]

Actually that's not quite true.
1) Fork C++ to another language name.
2) Remove from that clone the offending and non-core features.
3) --hopefully-- add in some useful networking/generalized information presentation system libraries.
4) Release for all to enjoy

Re:The problem with C++

[Anonymous Coward]

Of course it isn't what he meant. Please try harder.

Re:The problem with C++

[Anonymous Coward]

Just use macros!
#define CHECK_OUTPUT(val) switch(val){case GOOD:do_something();break;case NOT_SO_GOOD:do_something_else();break;default:really_bad_error(val)}
See how easy it is? You can even make another macro that calls the function and checks it's return value for you!
#define CALL(func,retval) retval=func;CHECK_OUTPUT(retval)
Better than exceptions!

It's not the only tool, but it's a good one.

[degeneratemonkey]

Anyone who outright dismisses C++ as a generally bad language to use in any situation is matched in their ignorance only by someone who swears by C++ as the best solution in every situation. I can't imagine keeping a straight face while using the term "engineer" in any capacity to describe a person made uncomfortable by such a powerful language. Ugly? Yep. Stopgap solution that got out of control? Pretty much. The [i]only[/i] language in its class? Yep. Bad C++ code can be very, very bad. Good C++ code is surprisingly elegant and extremely powerful. Its unique mix of expressive features, performance capacity, programmer flexibility and sheer volume of libraries far outweigh any argument about its semantical shortcomings.

It was all a joke

[oracleguy01]

It seems appropriate to bring up that C++ was all one big joke: http://www.ariel.com.au/jokes/An_Interview_with_Bjarne_Stroustrup.html

Uncle C++

[sharkey]

He runs fast.

I hope this doesn't turn into a hater thread

[GodfatherofSoul]

I started up with C++ later in my career, and despite the difficulty you face working it, I appreciate the ingenuity it took to create the language in the context it was written. It's not like creating Java or C# with a clean slate and years of experience with the pros and cons of their progenitor on the books. I came to C++ from the Java world and the ubiquity, power, and performance you get with it are well appreciated in my book, though that beautiful bride comes with a dowry of deficiencies.

Great books, though

[Anonymous Coward]

What I thoroughly enjoyed as a programmer learning C/C++ in the early 90's was the chance to read Kernighan and Ritchie's The C Programming Language and Stroustrup's The C++ Programming Language cover to cover. Both were literate, well-edited and thankfully free of screen shots (I hate screen shots in "how to" books). Compared to the hundreds of cookbooks and step-by-step guides I've consumed since, these two books educated me in PROGRAMMING in a deep way.

Say what you like about C++ itself, there was an exceptionally lucid mind behind it.

Boggle. Is That Really Linus???

[Anonymous Coward]

I've never actually read anything written by him. He sounds like some dumb 15 year old high school programmer.

Boggle.

Re:Boggle. Is That Really Linus???

[Anonymous Coward]

Unlike a dumb 15-year old high school programmer, Linux has credibility, so IMO he's free to trash C++.

Re:Boggle. Is That Really Linus???

[Anonymous Coward]

Yeech, a Linus fanboy...

Re:Boggle. Is That Really Linus???

[Anonymous Coward]

That's why you need to read his code to know him, or any programmer.

Relative

[MrTripps]

C++ seems kinda kludgy. Until you start writing programs in assembly. After that C++ looks elegant.

Re:Relative

[cheesybagel]

Depends on which assembly you are using. If it is X86 assembly, sure, it is baroque.

Re:Relative

[russotto]

C++ seems kinda kludgy. Until you start writing programs in assembly. After that C++ looks elegant.

Having written both, I disagree. I will grant you most of my assembler has NOT been x86.

C++ is a disaster on many levels. Syntactically, it's obviously so; when a simple loop through an STL vector of int is
for (std::vector::const_iterator citer = myvector.begin(); citer != myvector.end(); ++citer)
{
      switch (*citer) { // blah
      }
}

Semantically it's full of land mines. Copy and conversion constructors called when you least expect it. Temporaries galore. Idioms that work, but would be inefficient if compiler-writers hadn't developed specific work-arounds (RVO, NRVO). Byzantine rules about declaration and definition and scoping. The list goes on.

Re:Relative

[Anonymous Coward]

Two words: linked lists.

Objective C

[goombah99]

ObjectiveC is what C++ and Java were trying to achieve but failed. The C++ books keep getting thicker and thicker to the point that they are increasing in width faster than the speed of light. (this is allowed because they contain no information and consume rather than create energy.) C++ reminds me of the woman in Terry Gilliam's Brazil that kept getting more plastic surgery to correct the mistakes of the last one till she was reduced to goo.

Meanwhile ObjectiveC has stayed lean and effective, while having the major advantages of java available.

try it before you lash out at me.

Re:Objective C

[Anonymous Coward]

I think the thing that puts a lot of people off ObjectiveC when they come across it the first time is unfamiliar syntax for calling a method. Ironically this is one of it's greatest strengths! In objectiveC function polymophism is not determined a 'signature' created by the argument "types" (which is an idiotic way to do it since it's ambiguous), but rather by the argument labels. That is, the objectiveC method labels every argument with a variable name, not it's type. For example consider the cosine() function. ObjectiveC lets you effectively says Cosine(Radians=3.14159) and Cosine(Degrees=180.0) and have those be polymorphic even though both arguments are floats. In C++ if you want to do that you'd have to create a different typedef for every argument. yuck.

    Moreover, ObjectiveC does not actually determine which method gets called at compile time. it can do it at load time with late binding (like Java) or it can do it at runtime! this is because the object that get's the message can introspect the calling args and decide how to respond to it. You get all these Java-like advantages but run a C-like speed. Nifty.

This is not to say that ObjectiveC is untyped like python keyword args, but rather that you have the benefit of typing and labeling due to it's more versatile syntax. It's just looks funny the first time you see it.

At this point someone always says you can do that in C++ to and then produces some archane C++ way of doing that. Yes, well you can do that in BrainFuck too since it's turing complete as well. What matters is how simple you can make that. The beauty of ObjectiveC is that it is a very very thin layer on C that gets you all the things you really wanted in an object oriented language without the crap that makes it hard to use and debug.

Re:Objective C

[loufoque]

Cosine(Radians=3.14159) and Cosine(Degrees=180.0)

Nothing prevents from having that exact same syntax in C++, along with many different possible others (whatever is a valid C++ expression).
C++0x also allows the nicer Cosine(3.14159_Radians) through user-defined literals.

Re:Objective C

[grub]

I've been working with Objective-C for some iOS and Mac stuff. Gotta say, the learning curve is much nicer compared to when I was first looking at C++. It just seems much more thought out as to why things are how they are. I can't quantify it but an analog for me would be like looking at a Linux distro vs. a BSD install: a more complete, refined system.

Re:Objective C

[Anonymous Coward]

Cosine(Radians=3.14159) and Cosine(Degrees=180.0)

Nothing prevents from having that exact same syntax in C++, along with many different possible others (whatever is a valid C++ expression).
C++0x also allows the nicer Cosine(3.14159_Radians) through user-defined literals.

You are making the grand parents point for him. As he said, You are forcing the polymorphism via typedefs. Your Radians and Degrees are no longer simply floats. What you really meant to do is use a label not a type-- but since there is no syntax for that in C++ you have to use a crescent wrench as a hammer. As the parent pointed out you can do that but it's not simple and does not enforce self documenting code.

Re:Objective C

[Vegemeister]

How is that superior to cosine_radians(3.14159)?

Re:Objective C

[Haeleth]

ObjectiveC is what C++ and Java were trying to achieve but failed.

They were trying to be a niche language, confined to a single platform, which is so unpopular with developers that every time the owner of said platform has tried to make something Objective-C-exclusive they have faced such overwhelming resistance that they've been forced to back down?

I guess Objective-C is like the platform that uses it: its handful of users feel obliged to get up on a soap box and preach to the world about how it's totally awesome and perfect in every way, and everyone else looks at them in a funny way, shrugs, and carries right on using a mainstream product.

Re:Objective C

[Haeleth]

You get all these Java-like advantages but run a C-like speed.

Right. Because, by the divine power of Saint Jobs, Objective-C is magically able to do late binding and introspection for free.

Back in the real world, the speed difference between Objective-C and Java is pretty negligible.

Re:Objective C

[Haeleth]

Your Radians and Degrees are no longer simply floats.

Why on earth would you want them to be? They aren't the same type of data. If you add 45 degrees to pi radians, the answer should not be approximately 48.142.

Re:Objective C

[pizzach]

You get all these Java-like advantages but run a C-like speed. Right. Because, by the divine power of Saint Jobs, Objective-C is magically able to do late binding and introspection for free. Back in the real world, the speed difference between Objective-C and Java is pretty negligible.

The reason people say this is because you can use straight C when the extra speed is paramount. Can you run inline C code in java without needing the interpreter? Using straight C code inline in Obj-C is a bit like using Assembly inline in C. It's there when you need it.

Re:Objective C

[Anonymous Coward]

I don't actually program in Objective C, but I think it's useful for stuff like [drawSquare x=100, y=120, width=30, height=40]. A little bit clearer, at least for some of us.

Re:Objective C

[Creepy]

The real problem with Objective-C IMO is Apple is dictating its direction library-wise (or "extensions" as GNUstep calls them), and thus other platforms are always a step behind macs.

That said, most of these "extensions" really only apply to new GUI and system features and not general coding, so if you don't care about GUI stuff, you probably are fine. On the other hand, we already had a perfectly good cross platform gui-based object oriented language - Smalltalk - and it failed for the most part. The slowness of message passing always seems to be the killer of true OOPs, which is why kernels (like... any written in an OOP language) bolt on ways to bypass it, even if they are otherwise truly OOP.

Re:Objective C

[Anonymous Coward]

> ObjectiveC lets you effectively says Cosine(Radians=3.14159) and Cosine(Degrees=180.0) and have those be polymorphic

That's not polymorphic in the least. You simply have a method composed of multiple parts. When you can omit the label and have the proper implementation picked by the criteria of the argument alone, that's polymorphism..

Objective C has polymorphism through other means, such as protocols. Selectors alone don't cut it.

Re:Objective C

[larry bagina]

that would be [someObject drawSquareX: 100 y: 120 width: 30 height: 40] (not actually much of a square) or [someObject drawRectangle: myRect]

Re:Objective C

[SETIGuy]

Or, better yet lets use some polymorphism.

Degrees d(180.0);
Radians r(M_PI);
cos_d=d->Cosine();
cos_r=r->Cosine();

assert(cos_d == cos_r);
assert(sizeof(d) == sizeof(float));

Your typical Objective C programmer will probably say that the final assert will fail. That's because they don't understand C++.

A good compiler, on the other hand, will only compute cos(M_PI) once.

Re:Objective C

[Anonymous Coward]

You don't make a proper language without including the possibility of creating inheritance lattices. You just don't.
On the other hand, I just read about the protocols which were not around when I first heard about the language. So it turns out you can make a simulation of an inheritance lattice simulating the complexity of the this reality without a spoon when you need one.

Re:Objective C

[HeronBlademaster]

ObjectiveC has stayed lean and effective

Lean and effective? How can ObjectiveC be leaner than C++ when C++ is arguably a subset of ObjectiveC? (Remember, ObjectiveC allows C++ code to be mixed in with your ObjectiveC code.) And ObjectiveC's memory management is a lot more manual than Java's...

And on top of that, the one major IDE made to be good at ObjectiveC, Xcode, is an utter failure of an IDE...

Re:Objective C

[aiht]

The reason people say this is because you can use straight C when the extra speed is paramount. Can you run inline C code in java without needing the interpreter? Using straight C code inline in Obj-C is a bit like using Assembly inline in C. It's there when you need it.

You can do that in C++, however.
It's a bit blurry, though, where the boundary is between "inline C code" vs "C++ or ObjC written to be efficient" i.e. not using things like late binding and runtime introspection.

Re:Objective C

[Anonymous Coward]

Avoids code duplication.

Re:Objective C

[eric-x]

How is that superior to -1?

Re:Objective C

[pizzach]

When you are talking about Objective-C++, please say Objective-C++.

http://en.wikipedia.org/wiki/Objective-C#Objective-C.2B.2B

Objective-C uses C.

Re:Objective C

[tehcyder]

Isn't Objective C only available on the closed-source, proprietary Apple operating system?

Re:Objective C

[loufoque]

That's a horrible design if there ever was one.

Re:Objective C

[ByOhTek]

His uses one more character, so his files look bigger and more impressive?

Re:Objective C

[ByOhTek]

d'oh, epic fail.

Both are the same number of characters

I lose.

Re:Objective C

[Anonymous Coward]

Python keyword arguments are strongly typed. Python parameters are dynamically typed. Nothing in Python is untyped; maybe you're thinking of Forth?

Re:Objective C

[LizardKing]

Isn't Objective C only available on the closed-source, proprietary Apple operating system?

No. Although they are transitioning to LLVM, Apple use GCC just as NeXT did before them. Although most Linux distros probably don't install the Objective C frontend and runtime support library by default, I've yet to encounter a popular one that doesn't have the necessary packages in their repositories.

Re:Objective C

[marcosdumay]

But the right thing is to use type polymorphism here. You should declare different classes, so you can make "radians = degree + radians" and have the compiler do the right thing.

Re:Objective C

[marcosdumay]

"Can you run inline C code in java without needing the interpreter?"

Yes.

Re:Objective C

[Teckla]

ObjectiveC lets you effectively says Cosine(Radians=3.14159) and Cosine(Degrees=180.0) and have those be polymorphic even though both arguments are floats.

How is that better than having two functions, one named CosineRadians() and one named CosineDegrees()?

By the way, I'm not saying that feature of Objective C is useless, but perhaps your example is not a good one.

Re:Objective C

[HeronBlademaster]

Considering that ObjectiveC started life as a set of C preprocessor macros layered on top of C, I would have to say that ObjectiveC is hardly "lean and effective". "Obtuse and difficult to comprehend" is more accurate.

Seriously, what nincompoop thinks the "+" and "-" method modifiers in any way make ObjectiveC easier to use or understand or develop than the alternatives?

I guess using modifiers that are intuitively obvious in meaning - like, I don't know, defaulting to instance methods and providing "static" for the other - was too non-lean and un-effective?

ObjectiveC is full of WTFs even without people claiming it's lean and effective. Trying to write software in ObjectiveC drives me insane every time.

Re:Objective C

[jolson74]

ObjectiveC lets you effectively says Cosine(Radians=3.14159) and Cosine(Degrees=180.0) and have those be polymorphic even though both arguments are floats

Actually, this example isn't a good one. What you are talking about still has 2 distinct method signatures. In obj-c, those 2 functions would be:
-(float)CosineWithRadians: (float)radians;
-(float)ConsideWithDegrees: (float)degrees;
Which in C++ would be something like:
float CosineWithRadians(float);
float CosineWithDegrees(float);
If you try to define the following in Obj-C, you will get a compile error because the CALLER doesn't pass the variable name, only the value (e.g. [target cosine:3.14]):
-(float)cosine: (float)radians;
-(float)cosine: (float)degrees;
So in this respect, the languages are the same (although you are correct that Obj-C does not resolve method invocations until runtime since it is message based)

From an outsider's perspective

[elashish14]

I'm not a programmer in any sense of the term - not even that of a hobbyist, outside of simple bash/python scripts I use to aid my research. I've learned quite a few languages though, and I think learning C++ (university class) was the most painful. The syntax was a nightmare to learn (and this is from when I already knew C and Java) and all the complicated rules made it seem more like a cultural festivity than some tool used to accomplish a task. Not only that, but the C course was just 3 weeks whereas the C++ course was a full semester (and I still feel like I learned nothing).

I'm sure it's useful once you learn all of it, but it's quite arcane and difficult to get used to on first pass. Then again, maybe my course wasn't taught as well as it should have been, or I didn't approach it the right way. Of course, I certainly understand that it's a very powerful language if you use it more often than I did. But probably my least favorite language of those that I've learned.

Re:From an outsider's perspective

[David Greene]

The syntax was a nightmare to learn

I hear that all the time, but I can't quite figure it out. What's so hard about the syntax? The semantics (overload resolution, ADL, etc.) is tricky, but the syntax is pretty straightforward, I think.

Worst of both worlds

[youshotwhointhewhat]

I don't loathe C++ as much as some people, but I am not much of a fan either. To me C++ (and Java) is too much of a middle road between lower level languages (like C) and higher level languages (Python, Perl, etc). I prefer to write the bulk of my code in a high level language like Python, profile the code, and then rewrite performance critical sections in C (which is relatively easy to integrate with Python). This gives a good balance between performance, development speed, and maintainability.

Ada Programming

[Ada_Rules]

There certainly is no perfect language but I find any programmer that really spends time learning Ada, or Python or other language really well ends up being a better C++ programmer in the end too. Brief interludes don't really cut it either.

Re:Ada Programming

[Anonymous Coward]

Prolog is the best thing to happen to any programmer, no matter what they end up coding in.

Re:Ada Programming

[Anonymous Coward]

There certainly is no perfect language but I find any programmer that really spends time learning Ada, or Python or other language really well ends up being a better C++ programmer in the end too. Brief interludes don't really cut it either.

Contrary, i have found that many programmers can write good old fortran 77 in any language they come near. C++? No problems. ADA? Oh, yes. Java? No doubt.

No surprize

[taradfong]

...that the creator of C++ runs Windows. C++ is a barely-stomach-able OO implementation, and Windows is a barely-usable GUI & OS. I look forward to using neither, but often must do so.

the c++ mentality

[larry bagina]

Brad Cox liked C, but it was missing OOP. So he created Objective C, a pure superset of C that embraced the C-ness but added a smalltalk inspired runtime and OO.

Bjarne Stroustrup wanted to create a new OO (or whatever) language, but he knew that creating an entirely new language was a dead end. He hated C, but it was popular, so he embraced and extended.

Re:the c++ mentality

[aiht]

Brad Cox ... embraced the C-ness but added ...
Bjarne Stroustrup ... embraced and extended.

Sorry, what differences are you trying to point out here? You make it sound like they did exactly the same thing (which they did, as far as I'm concerned).

You're Making A Fool Of Yourself. Just Stop.

[Anonymous Coward]

Millions and millions of lines of commercial grade C++ code running from gigantic enterprise systems to can't fail for years systems to real time system down to tiny embedded systems over the past 25 years.

But some random idiot on Slashdot running his mouth off 'sez it sucks'.

 

Running with scissors and suckers on ice

[blunte]

I won't bother speculating why C++ became dominant (any more than I feel like rehashing VHS vs BetaMax), but I will say this: any language that needs a series of books explaining how NOT to use the language (lest you create obscure bugs) is an inherently flawed language.

With assembly there's an excuse - you have no boundaries (no pun intended). You realize you're operating on bare metal, or at least one step above it. But with C++ you have this belief that you have the illusion of power and safety, but the reality is you have a jumble of constructs and tools that can easily be used wrong (and often are by novices and intermediate developers).

I daresay you could teach an intermediate coder how to do OO in straight C and get better results than if they were trying to use C++.

And yeah, I'm in the camp of "Obj-C is better than C++". But then, I like Ruby, Lisp, Clojure, and Scala too. C++ really needs to die. Any further energy spent on C++ needs instead to be put into JVM and other abstraction technologies.

Re:Running with scissors and suckers on ice

[master_p]

Your post is extremely provocative, to the point that one can suspect you are totally ignorant of C++.

"but the reality is you have a jumble of constructs and tools that can easily be used wrong (and often are by novices and intermediate developers)."

My 4 co-workers, that work on iPhone applications, are still struggling with Obj-C memory management bugs, while I've successfully manage 250,000 lines of c++ code alone without any memory management problem in sight.

If there is a language with a jumble of constructs and tools, that is Obj-C (the language that you must alloc and init your objects separately, and then you have to manually count references by using acquire and release).

"I daresay you could teach an intermediate coder how to do OO in straight C and get better results than if they were trying to use C++."

Yeah, and write all those vtables by hand. And then maintain them.

"And yeah, I'm in the camp of "Obj-C is better than C++"."

You are totally ignorant of modern C++. And with the new C++ that supports move semantics, C++ kicks Obj-C's ass big time in performance and safety.

"C++ really needs to die. Any further energy spent on C++ needs instead to be put into JVM and other abstraction technologies."

You are totally ignorant then of how much C++ is still needed.

Re:Running with scissors and suckers on ice

[russotto]

And yeah, I'm in the camp of "Obj-C is better than C++". But then, I like Ruby, Lisp, Clojure, and Scala too. C++ really needs to die. Any further energy spent on C++ needs instead to be put into JVM and other abstraction technologies.

Why there? We need languages meant to run on the bare metal; if nothing else, the virtual machines need to be written. It would be really good to have a language which filled C++'s niche without being C++. The problem is that C++ is too entrenched, and worse, some of C++'s flaws are too entrenched. For instance, IMO, you'd have to discard templates in favor of some more limited generics mechanism to make a reasonable language.

Re:Running with scissors and suckers on ice

[Anonymous Coward]

C++ is a bag of powerful tools that let you write high performance code efficiently, if you know what you're doing. Every tool in that bag was put there by someone who was trying to solve a problem. Not all of them work for all situations, but the nice thing is, the language doesn't make you pay in overhead for features you don't use; that was one of BS's design principles. When I need to write high throughput real-time code, I can bypass STL/boost, code in a "C with classes and simple templates" subset, and get my code to meet spec. When I don't need the performance, STL lets me get code working about as fast as I could do it in python, and it's still 100X faster. I could code in half a dozen different languages, but by coding mostly in C++, I can leverage utilities and libraries that I've written for my application space over and over, saving time. I can mix high performance low-level coding styles for performance-critical areas with high-productivity coding styles for the other half of the code, seamlessly. And by constantly practicing in one language, which can solve the full range of problems I am faced with, I stay good enough at it to get stuff working fast, without having to struggle with syntax and idiom.

It takes some time and dedication to learn. But the thing is, if you want a career writing complex software, learning a programming language, even a big one like C++, is the easiest thing you will ever do. There are dozens of well written books and thousands of web sites and classes, and all the work has been done for you. After you learn the language, you will have to design an entire program yourself, or, worse yet (and more likely), understand existing code well enough to improve it without causing damage. There will be no well written books about that program, and no web sites. If you're lucky, there will be some kind of documents the developers wrote, which won't exactly match the code, and they will suck compared to an O'Reilly book, even if you wrote them yourself, years ago. The language is the easy part.

People have been complaining for years that English is a terrible language, with inconsistent spelling rules and difficult grammar - but it has a million words, and is spreading all over the world. Other languages may be easier to learn, but that's not what matters. Power and ease of use, once you have climbed the learning curve, matter much more than ease of learning. You will spend much more time using English than learning it. The same is true with C++.

Re:intel inside

[moderatorrater]

I know they say it for marketing, but the devices wouldn't have had intel in them at all. Only chips, generated by 3rd party plants, which took specs from Intel. :) A couple layers of abstraction away is all...

C++ is still misunderstood

[Anonymous Coward]

After 25 years, the core concepts of C++ are still misunderstood. This is not surprising since people jumped into C++ from C and saw C++ only as a syntactic sugar over C.
The key concept of C++ is stack unwinding with orderly destruction of scoped objects. In C++, the data best reside on the stack - the heap is for shared data or really large data, and should always be tracked by some object on the stack. No other commercial language has this concept of predictable and orderly resource management.
Once this concept is fully grasped, one can produce very robust and clean C++ code.

Re:C++ is still misunderstood

[David Greene]

This is one of the more insightful statements about C++ I've read recently. Thank you!

Re:C++ is still misunderstood

[Kensai7]

Great post, parent.

And the thing is: Stroustrup himself said that (1) if you write C-styled code in C++ you shall probably lose most of C++'s unique facilities and (2) no language is perfect, just use the right tool for the right job. He didn't try to force you to use C++, he just wanted to write a better C, with more features and type safety.

He managed it, and even the C ISO committee admits in its future C1X Charter that:

Regarding our relationship with C++, the committee is content to let C++ be the "big''
and ambitious language. While some features of C++ may well be embraced, it is not the
committee's intention that C become C++.

People like C because it's small and simple. It's totally another philosophy from C++ which deals with many programming concepts under the same hood.

Readability of K&R C

[sbjornda]

Just glad I don't need to read their code!

I don't see how well-written C code is so much harder to read than well-written code in Python, Java, or whatever..

27 years ago I watched my wife code C and I laughed, because she was trained in COBOL and her C looked so much like COBOL it was funny.

Now, the joke's on me. 27 years later her stuff is still easy to read & modify. There's not much other C code you can say that about, in the otherwise known as "write-only language".

(Yeah, she forgave me for laughing. She knew how the story would end.)

--
.nosig

C++... invented by an Aggie.

[Anonymous Coward]

NOW IT MAKES SENSE!!!

Never wanted to master C.

[Anonymous Coward]

I pushed and poked registers in assembler and compiled IBM punch cards. Fortran was fabulous, then, Pascal was global, and Basic was child's play. C was just too much for me!

Summary is wrong

[tomhudson]

in the now pervasive replacement language for C

Only someone who didn't know both languages would make such a stupid mistake. c and c++ are complementary languages.

The pre-processor is one of c and c++ strengths. It enables a type of workflow that languages w/o it could benefit from.

-- Barbie

Re:Summary is wrong

[ByOhTek]

Actually, it can be done without the preprocessor, and some languages manage to do some things that are harder to do /with/ the preprocessor. D has a lot of interesting things that it does, for example.

Then again, I'd just like to see counter in the preprocessor... When accessed it's treated like the 'current' integer...

#COUNTER( C_ , 1 )
#define A C_
#define B C_
#COUNTER_NEXT( C_ )
#define C C_

A->1
B->1
C->2

But I digress...

Brings back memories...

[krisamico]

Bjarne and the Community's creation was the bona fide beginning of my career. When I started, I thought I was a 7 in C++. Several years later, I was a 5. I wrote my best and worst code in the language, over 15 years, and I am still running into issues in the language that challenge me today. C++ helped me learn a lot about myself along the way, and I am grateful to Bjarne and the Community at large for that. A good article and interview, if not a tad brief.

Re:Brings back memories...

[Rudisaurus]

Amen to that -- and kudos to you for a good comment. I feel the same way.

C++ still great for a large class of problems

[pslam]

Sadly, every time C++ is mentioned on Slashdot, we get a flood of unoriginal, boring comments about how bad it is. These usually come from people who either don't understand why the language exists, or have just plain never used it. But they heard it sucks somewhere and all the cool kids in the gang are saying it sucks, so they should join in the bullying.

So far, no language can replace it. If you don't understand this, you don't understand the class of programming problems it solves. C++ is a language designed for static compilation. It doesn't run in a VM. It isn't managed. This makes it great for system code (drivers, kernels), high performance, and "raw" environments. It is designed to be "wysiwyg": a line of code will translate to a sequence of unsurprising assembly if the programmer is experienced enough. It is designed to allow all that and still have high level features to reduce lines of code, improve type safety, and increase modularity.

There are good reasons it's still one of the most commonly used languages for games, kernels, embedded devices and high performance apps: it really is good at them. It's not just momentum and "lock-in". There have been plenty of languages with bigger backers that died because they were bad or just merely obsolete: Pascal, COBOL, Fortran as quick examples. Ada is still out there simply because the military backs it, and I wouldn't be surprised if that changes.

There are plenty of languages which are better in some domains: Java has the advantage of a managed VM, and Python has a neat syntax and can achieve a lot in few lines of code, as just two examples. However, you'd never write system code in Java or Python. You'd never write something high performance in Python. You'd never settle for the critical path of a high performance application being written in Java. Well, some people do, but they're either kidding themselves, or they don't really have a high performance application.

I really, really would love someone to design a language which fulfills everything C++ does, but at the same time fix up its sometimes arcane syntax and removing the shotguns constantly pointing at your feet. But until then, I'm happy with the language that makes my every day job that little bit easier. If you find that funny, then you're the target of Stroustrup's interview: you need to stop being foolish and give it a chance. I pity all the people I've met over the years who are convinced they know the "best" language and will stick with it forever. Or those who consider C better for every problem which C++ would be suited. Happy job hunting to them - that attitude will catch up with you some day.

Re:C++ still great for a large class of problems

[David Greene]

Fortran is alive and well. The 2008 standard just came out. Lots of people use it. Like C++, it is not the best language for every problem.

Re:C++ still great for a large class of problems

[pslam]

Fortran is alive and well. The 2008 standard just came out. Lots of people use it. Like C++, it is not the best language for every problem.

Hah, I'm not sure why I even wrote that now. You're right: it's still in active use for number-crunching by a large number of people.

It's because I've never used it in employment, ever. I get the same from folks who grew up with nothing but plain C or Java: they think C++ is dead because they never see it being used. They're surprised when they learn that practically everything they use on an hourly basis has C++ running at the heart of it.

Re:C++ still great for a large class of problems

[master_p]

Amen brother. How very true. Unfortunately, while you should have been modded "5, insightful", that accolade went to other posters that blame the language with very weak arguments.

Re:C++ still great for a large class of problems

[Anonymous Coward]

The problem is that the domains that C++ is now still reasonable to use for are covered perfectly well by C, and the other domains are covered better by Python, .NET, ruby, and Java.

C++ is a solution for a problem that no longer exists.. namely "How do I write software that runs decently on a 386, works with C code, and can do whatever I need without having to mix in a much slower interpreted language that makes debugging and maintenance a chore."

The problems that exist now are.. how do I write secure, stable, reliable code that I can maintain and extend without very expensive and time consuming development that will run unnoticeably slower than something written in C or C++.

Re:C++ still great for a large class of problems

[walshy007]

This makes it great for system code (drivers, kernels)

Most of the rest of your post I could agree with, but not this, there is a reason we code in c not c++ in embedded systems.

Re:C++ still great for a large class of problems

[pslam]

Most of the rest of your post I could agree with, but not this, there is a reason we code in c not c++ in embedded systems.

Who's "we"? I've been very successfully coding in C++ in embedded systems for over a decade, and I'm talking devices with anything from just a few KB of memory. If you don't understand what language structures do to code generation, you shouldn't be coding for embedded systems in either language. If you think C++ cannot be used for embedded systems, you don't understand the language at all.

Re:C++ still great for a large class of problems

[Anonymous Coward]

A lot of us hate C++ because we use it professionally. Yes, it is the most practical solution to a difficult problem. That doesn't mean that it isn't a horrible language. I can write functionally identical software in half the time in saner languages... except when I can't because the libraries aren't available or low-level optimisation is required.

Re:C++ still great for a large class of problems

[walshy007]

Of course you can use c++ for embedded design, but you have to admit a lot of what makes c++ differ from c can be very ill suited for memory constrained devices, sure you can not use those language constructs that are ill suited, but when you limit yourself to a mostly c subset anyway (compared to the entirety of c++) why not just use c?

Would I try and use exceptions and the like on a device with a harvard architecture with 4kb of code storage and 512bytes of ram? I think not, same with RAII etc, that's a lot over overhead for such a small device.

Re:C++ still great for a large class of problems

[pslam]

Would I try and use exceptions and the like on a device with a harvard architecture with 4kb of code storage and 512bytes of ram? I think not, same with RAII etc, that's a lot over overhead for such a small device.

But this is something C++ is fundamentally designed to achieve: you can simply take your C program, sometimes tweak it a little, compile it in C++ mode and get almost the same code generated (because they're not identical compilers).

You can restrict which C++ constructs you use. There's no reason not to use classes if you were otherwise going to make a struct called "foo" and then a bunch of functions called "foo_init()" "foo_get_c()" etc. I see this all the time and it makes me do a facepalm for real.

Why, why, why would you restrict yourself to just plain C if you know exactly what these C++ constructs are going to do? Why would you use just plain C if that would mean less type safety, and more code? Why would you use just plain C if it got in the way of rapid development? Isn't that just language zealotry? These kind of development tools decisions are bad for you and others who use your code.

Re:C++ still great for a large class of problems

[walshy007]

Why, why, why would you restrict yourself to just plain C if you know exactly what these C++ constructs are going to do?

Code readability for one, yes it may be a little more verbose but c is a very simple beast and what you see is usually what you get. The use of c++ gives you enough tools to make things more difficult to understand unless either you were the one that wrote the code, or it's mostly just c anyway.

Even if you're an awesome guy that doesn't use the c++ constructs unless they are extremely appropriate, that does not mean a co-worker or someone else using your code won't go 'ooh, I'll just do *insert resource intensive thing here*' because it's running c++. In essence using c enforces a very consistent readable codebase in small projects.

Objective C++

[pslam]

I don't understand why Objective C is considered a good alternative to C++. Why not use both? You get the advantages of C++ type checking and encapsulation, while also having the runtime dynamic binding of Objective C.

Re:Objective C++

[Kensai7]

My thoughts exactly. Objective-C++ is what I'm looking at right now.

Using the powerful C++ and those flexible notions of Objective-C for Apple development.

C++ Report

[Anonymous Coward]

Where can I get an archive of back issues of the C++ Report? It had a nice run during the 90's as one of the hippest magazines in software development. Then, Java and web scripting came along, followed by XML and .NET, and it withered and died.

Soustroup and flame wars

[140Mandak262Jamuna]

He used to actually participate in holy flame wars in the usenet about C++. I am sure he is a slashdotter. Should he be allowed to use his mod points on this thread?

Good programmers write good code.

[Anonymous Coward]

Not to say there are no bad languages out there, but the quality of code (from elegance, maintenance, and performance standpoints) has MUCH more to do with the person who wrote it than the language it is written in. At the expense of being momentarily arrogant, the code I write in C++ kicks ass, not because it was written in C++ but because it was written by me. Similar to how my Python kicks ass or my C# kicks ass. It's because I kick ass, not the language I'm using.

My transition from Java-C-C++ and why C++ sucks

[pizzach]

I am only a few weeks in on C++. I like the idea of classes and a true object oriented language over C, but the syntax is so damn bad for everything.

I believe it has mostly to do with C++'s legacy with C and trying to be backwards compatible. It feels like it breaks so many general convensions in how things are written in C, you don't know what the hell it is going to do. "std::string mystring()" took a while for me to comprehend. My first thought was that it was something like "char mystring()" until I realized it was an object initalization and declaration all in one.

Templates? I really don't know what to think of them yet. Should they really be built into the language? I can't shake this feeling they are serving a purpose better met by perhaps a Makefile which copies and replaces the variables in a file.

I will probably have C++ grow on me more over time once the syntax stops pissing me off. Haven't tried Obj-C yet. But I have a feeling that or D would piss me off less. Only one way to find out...

Re:My transition from Java-C-C++ and why C++ sucks

[jjohnson]

I am only a few weeks in on C++.

Then you're overqualified for public pronouncements about C++ on /. Perhaps you have some trenchant thoughts on f#.

Re:My transition from Java-C-C++ and why C++ sucks

[aiht]

I'm sorry to see that you aren't liking it so far - my personal opinion is that using C++ is very rewarding, at least over similar languages such as Java and C#.
Regarding

"std::string mystring()" took a while for me to comprehend. My first thought was that it was something like "char mystring()" until I realized it was an object initalization and declaration all in one.

your first thought was correct, if by 'something like "char mystring()"' you mean declaring a function - not defining a variable.
Where it can get confusing is when there are parameters:
"std::string mystring("hi");" is a variable initialization;
"std::string mystring(char c);" is a function declaration.

Good luck, and which ever language you work with, enjoy it!

Re:My transition from Java-C-C++ and why C++ sucks

[master_p]

You don't know c++ yet to criticize it. Go back to making useful applications and then come back to talk.

Re:My transition from Java-C-C++ and why C++ sucks

[sempir]

When they gonna come out with English++ (MOI terribly confused by ALL the above).

Link the right words

[Anonymous Coward]

You linked "C++'s first release 25 years ago". I didn't want to read about the first release of C++, so I didn't click it. Similarly, you linked "creator regularly receives accolades", which I'm also uninterested in. However, you mention a new interview by Wired, which I'm very interested in, but there was no apparent link to the information.

Linking really isn't hard -- you link the bit of text that represents what you're linking to. It seems like 75% of the articles these days just link random substrings in the text instead of something contextually relevant.

C++ actually faster than C

[pslam]

Except C++ is not slower than C... It's actually equally fast, and can give a lot of performance optimizations with a fraction of the code needed to do the same on C.

It's even better than that. There's extra type checking and tighter rules on aliasing in C++ (unless you turn them off), so it can actually generate faster code. If you trivially convert a C program to the slightly less relaxed rules of C++, you should expect at least the same performance (if not, file a bug with your compiler provider), and often better.

I agree with the sentiment that anyone who thinks C++ is slower then C understands neither. It perfectly demonstrates their lack of understanding.

Re:C++ actually faster than C

[Anonymous Coward]

Technically c99 has `restrict` pointers which allow the compiler to perform fortran-like optimizations. c++ does not have `restrict` pointers. However, msvc and gcc have the compielr-specific `__restrict` pointers which do the same thing.

Re:You Just Flunked The Interview

[Anonymous Coward]

Totally agree. I do the same thing when giving interviews.

It's None of Those Things

[Senjutsu]

It's because Bjarne Stroustrup spent 23 years at Bell Labs, and ran the Large-Scale Programming Research Department there.

Bell Labs was the birth-place of Unix, and was always Unix central. Anyone even cursorily familiar with these facts would be a bit surprised to see someone who was so close to such a Unix stronghold for so long running a non-POSIX compatible system for day-to-day use.

Re:It's None of Those Things

[Espressor]

Are you TFS? No? Then maybe it'd best to let him/her answer in your stead so he can explain his opinion, don't you think? :-)

Anyway, thanks for the informative tidbit.

But working so close to Unix is no reason to favor it on one's "portable computer" like TFS calls it. There are plenty of reasons to prefer Windows on a laptop (driver support, applications available, etc.). It's unfortunate of course, but what can you do...

Re:It's None of Those Things

[Reservoir Penguin]

TFA says he uses Linux on his main computer. And it's hardly his fault that Linux sucks on laptops.

Re:It's None of Those Things

[multipartmixed]

> And it's hardly his fault that Linux sucks on laptops.

And really, why do laptops even have to be workstations?

What I need in a laptop is a portable terminal, and these days a portable web browser. When I go laptop shopping, I type on them to see if they keyboard's any good, make sure it has USB ports, at least a couple gigs of RAM, built-in WiFi and away I go. I don't have enough spare time to install and configure an alternate operating system just to satisfy some stupid fanboi ego trip, I use whatever it comes with. Which of course is Windows.

Hm, I just realized the above isn't strictly true with my current laptop any more. I'm accidentally getting Windows-ownership benefits in the form of one those cellular modem doohickeys I picked up in a hurry one day when I was on the road and needed net access while moving. I don't know if it will work on Linux or not, but it sure as hell didn't come with Linux drivers.

Re:It's None of Those Things

[ebuck]

It's because Bjarne Stroustrup spent 23 years at Bell Labs, and ran the Large-Scale Programming Research Department there. Bell Labs was the birth-place of Unix, and was always Unix central. Anyone even cursorily familiar with these facts would be a bit surprised to see someone who was so close to such a Unix stronghold for so long running a non-POSIX compatible system for day-to-day use.

Windows is Posixly comfatable. No, that's not a typo.

The Real Headline

[brsmith4]

Bjarne Stroustrup Reflects On 25 Years of C++: My bad

Templates good, defaults?

[nten]

I like templates, besides the generalization of types, I find it ends up replacing a lot of #define macros which are infinitely more evil because of the lack of namespacing and typesafeness. Default parameters (template or otherwise) have bitten me so many times that I can't help but hate them, and I tell others not to use them, but every once in a long while....

Also template specialization (and partial template specialization) can be very useful for optimizing specific versions of routines for a given type or size.

Re:Templates good, defaults?

[David Greene]

Completely agree about default arguments. I've been bitten many times as well. Boost.Parameter is closer to what it should be but without language support, we're left to use these kinds of libraries that involve a lot of boilerplate.

Enough with the[insert favorite language] fanatism

[Espressor]

Real men code in Assembler.

Not trolling, just suprising

[Anonymous Coward]

Probably because, as a Bell Labs alum, Stroustrup undoubtedly had a heavy immersion in the Unix tradition.

That he would choose the only major non-Unix-y OS for his portable would strike me as surprising as learning that Bill Gates had just bought an iPad.

Good leaders are not *always* good leaders.

[Futurepower(R)]

Unfortunately, although Linus Torvalds is an excellent leader of technology development, he sometimes exhibits unsophisticated social behavior.

In the linked message from Linus, *YOU* are full of bullshit, he gives good reasons why he doesn't like C++, but he does not fully analyze the entire situation.

For example, he says "C++ leads to really really bad design choices". That's true in many cases, but C++ programming could be limited to the features that work well. Many of the problems with C++ are caused by programmers using features that they don't fully understand, only so they can get some experience using them. Often, it seems, programmers just want to experiment, and don't care about the long-term end result of what they are coding.

Another problem with C++ is that, while Bjarne Stroustrop was a good leader when C++ was introduced, he has basically exercised too little power in the last 20 years in making sure the C++ language and libraries developed rapidly enough, and in the correct direction.

Still, as bad as the situation is with C++, what is better? Java and C# are easily decompiled; both suffer from ugly politics. C++ is better than C in that it helps programmers control the scope of variables, for example.

When Linus Torvalds says "*YOU* are full of bullshit", he is acting out his anger, he is not acting like a leader. He is not helping make the situation better.

Unfortunately, the people on whom we rely to be our leaders are not always good leaders. We can, however, be thankful for everything positive they have done for us.

Re:Good leaders are not *always* good leaders.

[21mhz]

Note that he was shutting down an annoying newbie who suggested something like reworking the git codebase to use "nice abstractions" to solve no real problem. C++ advocacy on the net seems to be dominated by such newbies, or then they are the gurus who know obscure C++ quirks inside out and have written a book on that.

Re:Good leaders are not *always* good leaders.

[m50d]

Java and C# are easily decompiled;

You say that like it's a bad thing. It makes them easy to e.g. debug. If you want obfuscation you should do that with a specialised tool for the purpose, not rely on your compiler to do it.

both suffer from ugly politics.

Perhaps, but the end result has been better; both have decent standard libraries and if not quite "write once, run anywhere" then pretty close, putting them miles ahead of C++.

Re:Good leaders are not *always* good leaders.

[Kaz Kylheku]

C++ is better than C in that it helps programmers control the scope of variables, for example.

C has similar scope rules to C++. ISO standard since 1999. That is, declarations can be mixed with statements, and the for (;;) loop header contain a declaration.

Furthermore, C does not have the "class scope" disease:

    int x;

    void foo::bar(int y)
    {
          x = y;
    }

You better get into the habit of writing ::x when referring to that file scope variable. Otherwise if someone introduces member "x" to the foo class, or any of its inheritance ancestors, the meaning of the assignment changes. It now silently resolves to the member.

C++ class scope is the Pascal WITH statement different clothing. When you write

    int foo::bar() {

    }

you are saying, "open a scope between these braces which contains an unknown quantity of declarations which are potentially scattered in numerous remote locations, nowhere visible in the present lexical scope".

Every time you need to add a member variable, you have to inspect every single region of class scope to look for this type of silent clash, unless you strictly adhere to naming conventions like m_ on every member.

The people who come up with protective C++ coding conventions are the true thinkers and designers.

Re:Good leaders are not *always* good leaders.

[Anonymous Coward]

You better get into the habit of writing ::x when referring to that file scope variable. Otherwise if someone introduces member "x" to the foo class, or any of its inheritance ancestors, the meaning of the assignment changes. It now silently resolves to the member.

The problems here are a bad class partitioning and the potential violation of the substitution principle, in my humble opinion..

pick your poison

[yyxx]

Objective-C is a caricature of Smalltalk, combining all the disadvantages of C with only few of the advantages of Smalltalk. It also lacks pretty much all the advantages of Java: Objective-C is not type-safe, it does not provide runtime safety, it does not provide sandboxing, and it does not allow you to safely load extension modules.

C++ started out as a simple set of fixes to problems in C, and for the first few years, it was a pretty good tool. That's why it won over Objective-C, which came out around the same time. Eventually, C++ bloated beyond recognition, while Objective-C stagnated from disuse, and that's the state we're still in. There are still a few valid use cases for C++, but I see none for Objective-C.

What should you use then? As far as languages that you can realistically use, I think the best ones around are C#, Go, Python, and Ruby. There is nothing (zero) new ideas in those languages compared to what's been available for decades and their implementations are mediocre and bloated at best. The evolution of programming languages has been a big, fat disappointment.

Re:pick your poison

[Anonymous Coward]

The evolution of programming languages has been a big, fat disappointment.

If you check out sites like Lambda The Ultimate you'll find that there is a lot of research still happening in language design.
Too bad all the research languages are based on ML or Lisp and you need a PhD to understand them.

Re:pick your poison

[Anonymous Coward]

I think the best ones around are C#, Go, Python, and Ruby

Go is just Algol68 with continuations and much worse syntax. why anybody thinks it's a good language I have no idea. I presume because of who created it, and that it has that "google coolness" attached to it. C# would be more tolerable (as far as corporate languages go) if the base library wasn't complete crap.

Re:pick your poison

[Rockoon]

There has still been a bit of refinement in the standard Structured+OO paradigm, with for example Generics (first seen in Ada in 1983, but not to hit mainstream languages until C#/Java, and as templates in C++)

Many programmers wouldnt want to go without some form of Generics today for any project of a significant size. All that research, when its proven useful, eventually makes its way into something more popular than the languages that pioneered them. The alternatives to generics are either re-inventing-the-wheel, inefficient-runtime-dynamics, or the complete-loss-of-type-safety. Thank you Jean Ichbiah (inventor of Ada!)

Re:pick your poison

[Anonymous Coward]

Just to nitpick a bit, Java's generics fall under "inefficient runtime dynamics" plus partial loss of type safety. I think type-erased generics were the worst mistake of Java's design.

Re:pick your poison

[Rockoon]

Just to nitpick a bit, Java's generics fall under "inefficient runtime dynamics" plus partial loss of type safety.

Didn't know that about Java's Generics, thanks!

Does C give you...

[Anonymous Coward]

Does C give you

• ... type-safe collections?
• ... closures? (No, function pointers are NOT the same thing)
• ... object polymorphism?
• ... RAII?
• ... any semi-sane way to write generic code? (No, macros and void * don't count -- they're extremely error-prone and cumbersome.)
• ... etc. etc.

In short: You just don't know what your missing.

Re:Does C give you...

[rbarreira]

I have used those things when programming C++ and other languages, and I don't really miss them when I'm using C.

Those things aren't useful for every project.

Smart pointers aren't quite

[21mhz]

Problems with "smart" pointers:

• They are not yet standardized, meaning that you can't use the same family of pointers between code using Boost and, say, Qt-based code. Not to mention that many smartasses who think they are experts in C++ invent their very own smart pointer classes.
• There is a multitude of smart pointer classes in any chosen family, breeding confusion and mistakes.
• Nevertheless, there are too few smart pointer classes to provide good granularity on performance. Shared pointers in both TR1 and Qt are thread-safe, meaning that they waste CPU time on things like memory barriers in single-threaded programs.
• Smart pointers are problematic to use in function parameter signatures, because they feature templated implicit type conversions which screw up overload resolution (playing C++ features against each other is an exciting game in general). This means that most interface designers prefer to either pass objects by plain old pointer/reference, resulting in unnecessary copying, or resort to "lightweight" handle classes wrapping opportunistically shared data structures. Not smart, huh?

But this is all corollary to the main thing: RAII is a solution to a language design problem.

Re:Smart pointers aren't quite

[HonIsCool]

What is the language design problem, and is there a better solution than RAII?

Interesting.

[Futurepower(R)]

"C++ advocacy on the net seems to be dominated by such newbies, or then they are the gurus who know obscure C++ quirks inside out and have written a book on that."

Interesting point.

Fortran

[Anonymous Coward]

Could you please explain to me why Fortran is not a good language to do lots of math for complex, multi-dimensional problems?

It does have:
-default pass-by-reference
-intrinsic complex types
-intrinsic multidimensional arrays, including simple global operations on arrays (scalar*array, array+array, etc.)
-with modules very thorough type checking (and whoever does not use them needs to be shot. Twice)
-almost intrinsic parallelism [e.g. forall statements, pure procedures, etc.]
-all features of C++ [operator overloading, classes, types, pointers, procedure pointers, etc.]

Of course, if you use it for anything else you will run into its limitations and quirks, but then you are using the wrong tool.

Re:You Just Flunked The Interview

[dbIII]

actual real world C++ engineers

What if they want real programmers instead of engineers that do a little bit of programming?
I'm an "actual real world C++ engineer" but I'm shit at coding because I know more about hardware and thermodynamics than I do about C++.

25 Years?

[ndixon]

Feels like fifty.

Re:intel inside

[Vectormatic]

intel actually owns its own plants...

struct vs. class

[nhaehnle]

Things like give me an example where a struct would be a better choice and where a class would be better.

Few people get that one right. The only difference between struct in class in C++ is that struct defaults to public, whereas class defaults to private. In other words, the choice between struct and class is purely cosmetic and can only depend on your coding guidelines.

The only case where it does matter is if you want to mix C and C++. Then any data structure that should be shared between the two obviously has to be a struct, because a C compiler does not recognize the keyword class.

Re:struct vs. class

[Bengie]

if was my understanding that a struct is a contiguous piece of memory.

eg. struct blah { i int} //An array of these would be stored in memory side by side
blah [] = new blah[8]; //8 ints created in memory

but

eg class blah {int i;} //An array of these would be an array of pointers. The issue with this is the pointers would effectively point to random locations in memory to where ever the object is stored. This will cause higher random access and less CPU pre-fetching
blah[] = new blah[8] //8 pointers to 8 ints created in memory assuming you assign each element to a new blah()

So, the benefit of an array of structs would be cache line efficiency and also the CPU can pick up the memory read pattern since the pattern in a for loop would just be the next memory address.

Also, you can add padding to structs. This would make sense, since each struct in an array is stored in memory exactly after the other. Padding can be important for cache lines. Classes don't support this since an array of classes is just an array of pointers and no point padding an array of pointers.

I mainly use C#, so sorry if I miss-understood the difference between classes and structs.

Re:struct vs. class

[bstamour]

Nope, the parent is correct. The only difference between a struct and a class is the default access level of its members. Structs are public, classes are private.

It also has an effect on inheritance as well. A struct will inherit publicly by default,

struct A : B { };

is the same as

struct A : public B { };

Similarly for classes, but replace "public" with "private".

Both structs and classes are contiguous blocks of memory. The only cases where pointers come into play are when your member functions (methods) are declared as virtual.

Undecidable problems

[nhaehnle]

What really killed C++ for me was when a student created a situation like this:

std::string somefunction(){}

As others have pointed out, most compilers give at least a warning about this or even fail to compile, which is well within what the standard allows. And it is quite reasonable for the C++ standard to make this an undefined behaviour, because it is impossible in general for the compiler decide whether the flow of control can leave a function via the closing brace. If a compiler could decide that, then it could decide problems like the halting problem that are known to be undecidable (in a computability sense).

Now of course, the standard could instead have defined the correct behaviour of the compiler to be that if it cannot decide this, it should introduce code that throws an exception. But that would be introducing code that the programmer has not asked for, e.g. if the programmer has proven that control flow cannot fall off the end of the function, but the compiler is unable to follow that proof. That goes against the philosophy of C++ as a systems programming language.

Whether anybody should write code where the compiler is unable to figure out stuff like this is another question, of course, and obviously compilers should do a best effort to catch the obvious cases - but they already do that. So this is a pretty lame argument against C++ as a language.

Re:Undecidable problems

[betterunixthanunix]

Thus explaining why other languages do not have this problem? What, do their compilers decide the halting problem? In the general case, the semantic analyzer should detect that (1) control flow reaches the end of a function that is supposed to return a value or object and (2) stop with an error, because that is not something that should happen.

OO C

[js_sebastian]

I daresay you could teach an intermediate coder how to do OO in straight C and get better results than if they were trying to use C++.

I have done OO in C, and it's not pretty... with my own hacked up implementation of a virtual function table that you have to explicitly fill with the right pointers. This was some kind of expression evaluation code where the only alternative really was a huge switch statement, so it might have been better than the alternative, but I wouldn't advise, let alone teach, anyone to do this.

Favorite Part of TFA: Non-fanatical and Wise

[Hobbes_2100]

From Stroustrup, in the article:

"Know your fundamentals (algorithms, data structures, machine architecture, systems) and know several programming languages to the point where you can use them idiomatically.

Know some non-computer field of study well — math, biology, history, optics, whatever. Learn to communicate effectively in speech and in writing. Spend an unreasonable amount of time on some difficult topic to really master it. Try to do something that might make a difference in the world."

I guess he wouldn't do to well on Slashdot.

Stroustrup reflects. C++? Not so much.

[Kaz Kylheku]

:)

Lables versus typedefs

[Anonymous Coward]

That was a simple example for economy of words. Let's take a more complex example. Suppose I have an area function that takes inputs like height (H=5) and width (W=6) and length (L=7). In objectC you might write the following where W,L, and H are just floats to get the area of the side of the object:
[object area width:W height:H]
simple and you could do that in C++ by typedef W is type width, and H is try Length.
but now you want the area of the top and bottom:
[object area width:L height:W ]
But you can't do that in C++ without casting because L and W are not floats but rather are type defs that don't match their positions.
But that's not an example of polymophism just using labels instead of type defs which is what you really wanted in the first place, since the values were logically floats and you don't need to proliferate the type defs and make it a typically C++ mess. On the other hand if you really did require type safety then you could give them types.

THe other thing is that there are a proliferation of ways you might write the call in c++. IN most of these you would just have a list of arguments separated by commas:
object.area(L,W)
or
object.area(W,L)
Notice there is no enforcement of self documentation here. Can you recall which order the arguments are supposed to be in? L then W or W then L? In objectiveC the labels are enforced automatically.

People who write in C++ try to make up for the lack of labels by name mangling the method name like this:
object_area_L_then_W(L,W)
but there's no consistency in how that is done, and it does not enforce that the arguments are actually in the order required.

None of this has been about polymoprhism. I was just backing up to show you that trying to use typdefs to do the job of labels is why C++ code is so damn hard to write, debug and read, and has no consistency from person to person. Notice that ObjectiveC is doing this without any bloat: THere is only way way to write the method not a proliferation. We did not have to create some library to hand in maps to fake labels as we would in C++. it's all very natural. The fact that you then get polymorphism directly emphasizes how natural it was: methods with different labels are different methods. No typecasting required. The signatures could be identical.

Re:Lables versus typedefs

[goombah99]

Mod parent up. Nice explanation.

Coding conventions should be part of any language.

[Futurepower(R)]

"... unless you strictly adhere to naming conventions like m_ on every member."

"The people who come up with protective C++ coding conventions are the true thinkers and designers."

In my opinion, strong coding conventions should be part of any language. Presumably Bjarne Stroustrup is a careful coder. However, he has not been a strong enough leader in the social issues of coding C++. To be fair, however, getting programmers to cooperate fully is more difficult than herding cats. It's like herding a group consisting of alligators, rhinoceroses, and leopards.

What Languages Fix

[npsimons]

A lot of people are bitching about C++ here; whether it's sour grapes over its success, a lack of understanding of the language, a lack of discipline to work in such a low level language, or honest criticisms, one thing has to be remembered: C++ was created to solve problems because its creator thought he could make a better language. One of my favorite ways to compare languages is What Languages Fix. It's a good, short read, but I'll spoil you and let you know that C++ was created to fix the problem of C being too low level. This implies many things, not the least of which is that Stroustrup wanted to leverage C's popularity, and of course that limited his options when designing C++. You'll also notice in that essay that Java was created to fix the problem of C++ being a kludge. And of course, C# was created for no other reason than Microsoft doesn't control Java ;)

Too bad you are completely wrong

[goombah99]

The guys who ported Quake to Mac, say objective C, is C. It runs just as fast as C. ObjectiveC allegedly has slower method dispatch (as opposed to C-function calls) but tests show it's fast or faster than C++ (i.e. a tie as far as apples and oranges can be comapred)

Re:Too bad you are completely wrong

[Anonymous Coward]

that link did not show objective c message dispatching to be as fast or faster than c++. Now, I think the runtime features are worth the extra cost, but they're not free.

a non-virtual, non-inline c++ class method (object->function(parameters)) is essentially: function(object, parameters...).

a virtual c++ class method (object->vfunction(parameters)) is essentially (object->vtable[constant_number])(object, parameters), ie a couple extra instructions to get the function pointer.

An objective c class method [object function: parameters] requires calling the run time to get the function pointer from a hash table. No way around it, it's slower than the inline vtable lookup.

Oh, but one comment had code where you looked up the function pointer and used that. Ok, that would be faster than a virtual table but more work for the programmer.

Re:Too bad you are completely wrong

[Anonymous Coward]

you sound like a pair of bald men fighting over a comb. Are we arguing miniscule details here. Objective C is fast and has huge advantages. That's not in dispute is it?

Re:Enough with the[insert favorite language] fanat

[turgid]

Real men code in Assembler.

Real Men code themselves a FORTH environment in assembler.

C++ is...

[CondeZer0]

"... an octopus made by nailing extra legs onto a dog." -- Steve Taylor

The real reason for the creation of C++

[CondeZer0]

This is interesting, but not as interesting as the interview where Bjarne Stroustrup explains the real reason for inventing C++.

(Yes, it is satire, but very sharp and insightful satire.)