Hacker News Reader

Comment by stinos | Hacker News Reader

Good luck trying to understand C++ without C

look at it this way: suppose some alternate universe where there is no such thing as C, it just doesn't exist, nobody ever heard of it. Why would you not be able to completely master C++ that universe? The traps and pitfalls which you consider C, would then just be known as C++ (just as in reality they are C++ now, maybe not just always named as such). I think that's one thing what's being advocated here.

Anyway, what traps do you have in mind specifically?

View on HN

Much of C++ can only be understood in the context of C. For example, why are string literals not std::string, and what the heck are null-terminated strings about? In your alternate universe, C++ would be a nonsense language full of absurd design decisions. Understanding C is perhaps necessary to understand why C++ works the way it does.

> Much of C++ can only be understood in the context of C.

This. Moreover, much of the complexity of the language is caused by being designed as a super-set of C. C++, literally, makes no sense without C.

Even further, why are strings considered a linear sequence of 8-bit characters (defaulting to ASCII)? That's madness in 2014! If I give you a sequence of bytes and tell you it's a "string", that's no more meaningful than if I gave you a bunch of bytes and said "this is music" or "this is a picture". Without telling you the encoding you have to blindly guess how to interpret it.

Go does a good job of rectifying this: strings are generally opaque binary objects--indexing into them gives you abstract "runes" (representing Unicode code points) which can then be encoded into various flavors of UTF characters.

I know it's a rhetorical question, but "Unicode didn't exist when C or C++ were invented" is a really good answer.

"Go does a good job of rectifying this: strings are generally opaque binary objects--indexing into them gives you abstract "runes" (representing Unicode code points) which can then be encoded into various flavors of UTF characters."

Overselling Go a bit there. Indexing into a string gives you that byte: http://play.golang.org/p/rxeexRzW7e

There are ways of iterating along a string by "rune" but it's not the default. That said, given that strings in Go are assumed to be UTF-8, indexing into them by rune is expensive and if you actually want to iterate by Unicode char I'm not bothered by having to be a bit more explicit about it.

Strictly speaking, indexing into a string gives you an integer type (as your example also shows): https://play.golang.org/p/i7_MKja_mQ

"Rune" is an alias for int32. So we are saying the same thing, essentially.

Try that with something that isn't one byte in UTF-8. It won't work. We aren't saying the same thing.

OK. https://play.golang.org/p/Q94GFI02ru

I'm not sure what your point is in this argument? You're saying the above is worse than braindead C ASCII-only strings?

That promising that "Go strings allow you to index into them to retrieve runes" is overselling Go's string support, of course. That's why I led with that statement, since it is what I was trying to say.

It's best to be correct about how languages work, because when you interest someone in a language via a false statement, they do not end up thinking highly of either you or the language when they discover the falsity. While I'm not sure I'd call myself a Go "advocate", I do prefer that people like and/or dislike it for valid reasons rather than invalid ones.

C++ wouldn't exist in that universe.

But if we accept the hypothetical, I think that people in that universe would still identify and separately consider the C-ish subset of C++, much like template metaprogramming is considered its own subset of the language.

So no, I don't think they would understand C++ without first understanding C, even if they didn't call it "C" or consider it to be a completely separate entity.

Reply on news.ycombinator.com