The only bad thing about C++ is C

[vivmen]

Hi all

i think what makes c++ more problematic is c.

if we avoid c features & use more c++ code. c++ seems better & more safe language.

[hamsterman]

Are you sure it's not the other way around?

[1vRz3TCk]

I would have thought that if you 'avoid c features' you would not have much of anything useful left.

[Gaminic]

We'd have to redefine everything in terms of bool-only variables!

[rapidcoder]

c++ seems better & more safe language.

If by safety you mean illusion of safety, then - yes.

class SomeClass {
private:
  Something1* obj1;
  Something2* obj2;
public:
  SomeClass() {
    obj1 = new Something1;
    obj2 = new Something2;
  }

  ~SomeClass() {
    delete obj1;
    delete obj2;   
  }
};

Is it C? No. Is it idiomatic C++? Yes.
The key question is: Is it safe?

[1vRz3TCk]

Bjarne Stroustrup wrote:

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.

[Catfish]

Bjarne Stroustrup wrote:

Interviewer: Is C obsolete?

BS: I think it is obsolete. I think the languages should have been merged into one, so that C would have been a subset of C++ instead of nearly a subset of C++.

Of course...
Because he realized, 30 years too late, that one can't build a high-level OOP language on top of C.
So he'd very much like to deprecate C to avenge his pains. Too sad he can't.

@ vivmen: I agree with your post... especially "c++ seems a better and more safe language".

You can argue it's better because you work less than you would in C, to achieve a similar degree of safety.
You can argue it's better because of the STL, which is nice indeed.

But at its core, C++ is still C. And the core is where the pain comes from.
iterators are still pointers. You can cast your way out of const and encapsulation.
Why do you think you can defeat everything in C++ by using C-style hackery?

[Duthomhas]

You are putting words in Stroustrup's mouth. (And you are misquoting him.)

If you all hate C++ so much, why are you here?

[rapidcoder]

I think this blog post well describes what the main problem of C++ is:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

This one is nice:

Joel Spolsky wrote:

C++ string classes are supposed to let you pretend that strings are first-class data. They try to abstract away the fact that strings are hard and let you act as if they were as easy as integers. Almost all C++ string classes overload the + operator so you can write s + "bar" to concatenate. But you know what? No matter how hard they try, there is no C++ string class on Earth that will let you type "foo" + "bar", because string literals in C++ are always char*'s, never strings. The abstraction has sprung a leak that the language doesn't let you plug. (Amusingly, the history of the evolution of C++ over time can be described as a history of trying to plug the leaks in the string abstraction. Why they couldn't just add a native string class to the language itself eludes me at the moment.)

[Gaminic]

When exactly would that be useful? As far as I know, string literals are "I typed them myself"-hardcoded anyway. If you can hardcode "foo" + "bar", you can hardcode "foobar". In any other case, you'll be concatenating variables, which is always possible regardless of whether they're C-strings or C++strings. The only case I can see where this "lack of type compatibility" would occur is if you're using macros that contain string literals, but that's like saying it's impossible to ride a horse with your foot up its anus.

Then again, I'm inexperienced and am probably missing some vital aspects of this complaint.

[Catfish]

You are putting words in Stroustrup's mouth. (And you are misquoting him.)

That's what he said in the interview.
And I'm free to interpret what he said, to reveal what he didn't say.

If you all hate C++ so much, why are you here?

Lest that otherwise, learning it was a waste of time. [/sarcasm]
It's rude saying "GTFO", even if it's hidden beneath a rhetorical strawman question. Step off.

[1vRz3TCk]

Question: What is the difference between C and C++?
Bjarne Stroustrup: C has the basic mechanisms for expressing computations. It has iterations, it has data types, it has functions and that’s it. It doesn’t get into the game of expressing abstractions. So if I want a matrix in C, I would have to say, I want an array and then I want a whole bunch of arrays and when I want to get the third element I have to program my way down to the third element of the fourth row or something like that.

In C++ you can define something, call it a matrix, you define a subscript operator. If you don’t want rectangular matrixes you can get pentadiagonal matrices, triangular matrices that’s the kind of stuff that people... the expert in that field are interested in. And you build that set of concepts and then you program it directly. It’s easier to program, it’s easier to debug and sometimes it’s even easier to optimize for performance when you are expressing the notions at the higher level, at the level where an expert in the field operates, rather than trying to have the expert in the field, say the physicist, also be an expert in dealing with the hardware, with the computer. There are fields still where you have to have a physicist and a computer scientist to get the work done, but we would like to minimize those because the skill sets are not the same. So you want to lift from the hardware towards the human level.


Question: Is C obsolete?
Bjarne Stroustrup: This is somewhat controversial. I think it is obsolete. I think the languages should have been merged into one, so that C would have been a subset of C++ instead of nearly a subset of C++. And then people could have used whatever parts of the C++ tool set they needed. As it is now, there are still enough incompatibilities that you have to remember which language you’re writing in, and I don’t think that is necessary. It appears to be a historical necessity, but it is not a technical necessity.

I’ve argued for compatibility, very strong compatibility, all the time. I mean, I started working on C++ three doors down from Dennis Ritchie and we were talking every day. The competition and tension that has been between C and C++ over the decades certainly didn’t come from home.

Dennis Ritchie wrote that first book that Brian Carnahan, now I’ll have dinner with Brian next week. We’re still very good friends as we’ve always been, but sometimes the programmers of the languages don’t quite see it that way. It should have been one language.

[bbgst]

Gaminic wrote:

If you can hardcode "foo" + "bar", you can hardcode "foobar".

And even "foo" "bar".

[hamsterman]

@Gaminic, bbgst, abstraction that requires you to know it's inner mechanism is nearly useless. Do read what rapidcoder posted.
_{before I get criticized, the overstatement was intentional..}

[bbgst]

I agree with almost everything written on that article. But I don't agree on this C/C++ relation being considered a "leaky abstraction". The whole point of these two languages is giving the programmer the power to choose whatever tools he needs, not trying to abstract away the complexities of software development.

In other words, if you think C++ doesn't suit your needs, find a language that does.

[Gaminic]

Yeah I do realize that, but I'm looking at it from the other way.

Say some newbie types "foo" + "bar" and gets an error, then posts it up here. Apparently, you, rapidcoder and "Joel on software"'s first reactions are "Oh god, abstraction is leaking, abandon ship!". My first thought is "Why on earth is newbie X typing "foo" + "bar"?". There is no logical reason to ever do so [as far as I know, but as said before, I'm still quite new to C/C++!]. Rather than use it as an opportunity to bash C++/programming paradigms, I'd use it as an opportunity to point out odd/bad programming practices.

I do completely understand the problem of leaky abstraction. I never realized it had a fancy name, but it's one of the things I complained about in an earlier Lounge topic: for every lesson I learn in the C++ world, I'm apparently required to learn ten in the C world before I can properly use slightly non-basic C++ functionality.

All I'm saying is that the example "Joel on software" gave is rather silly [as far as I know]. I don't think it's fair to blame a language for throwing compilation errors when the programmer writes something utterly stupid.

[1vRz3TCk]

bbgst wrote:

But I don't agree on this C/C++ relation being considered a "leaky abstraction".

Did I miss something? Who said the C/C++ relation is a "leaky abstraction"?

[Cubbi]

@rapidcoder

class SomeClass {
private:
  Something1* obj1;
  Something2* obj2;
public:
  SomeClass() {
    obj1 = new Something1;
    obj2 = new Something2;
....

Is it idiomatic C++? Yes.

No, it is not. It violates basic exception safety and multiple style guidelines.

[bbgst]

CodeMonkey wrote:

Did I miss something? Who said the C/C++ relation is a "leaky abstraction"?

The main topic is about how C++ features should be favored over C features. The article posted by rapidcoder uses the example of the string class in C++, which abstracts the whole char * thing, but leaves holes, like "foo" + "bar", calling that a leaky abstraction.

I was saying I don't agree with that thought, since the main design of C++ is letting the programmer make the decisions, instead of the language.

[rapidcoder]

No, it is not. It violates basic exception safety and multiple style guidelines.

You mean style guidelines forbidding doing anything real in constructors (like Google or Mozilla styleguide) or forbidding using exceptions at all? Well, style guides should be about style, not correctness. Therefore C++ is *not* any safer than C. Besides all the crazy bug possibilities inherited from C, C++ adds a bunch of its own, not related to C, like the one in my example. IMHO the ones added by C++ are much harder to spot.

BTW: The compiler would not give a damn warning about this code, even in the -pedantic -Wall mode. I also doubt any code style checking tool would catch this.


As for the "foo" + "bar" example - it is just an example. What about:

std:string x = 1;

It compiles, but it does something much different than a typical newbie would think it does.