Live data from Hacker News

Popular Myths about C++, Part 1

isocpp.org

31–40 of 144 posts

Re: Popular Myths about C++, Part 1

#31
post #14

Earlier quoted context omitted.

The articles promise is actually terribly dubious. Firstly, in the real world, name+'@'+domain is likely to exceed the capacity for any SSO anyway. Even the example composition, which is 21 chars, may resort to heap allocation under some implementations. It's a bad solution to depend on it for performance. Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for sh…

That's the good thing about C. With C++, you don't know what is being allocated, where. With C, it is explicit. You know what's happening if you call malloc. And this compose function could easily be written in C to take the "addr" as an argument to be filled, rather than provide it as a return value. Then it can be entirely stack allocated. The caller would need to make sure that the "addr" array was large enough of…

> You know what's happening if you call malloc.

You think you know what is happening. There are so many ways to implement malloc across OS and compilers.

> "you could do this more efficiently if you operated on character arrays instead of a std::string"

A bounds error waiting to happen at every string operation.

Re: Popular Myths about C++, Part 1

#33
post #14

Earlier quoted context omitted.

The articles promise is actually terribly dubious. Firstly, in the real world, name+'@'+domain is likely to exceed the capacity for any SSO anyway. Even the example composition, which is 21 chars, may resort to heap allocation under some implementations. It's a bad solution to depend on it for performance. Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for sh…

Right. Also, the C version would be cleaner using the printf family of functions. Idiomatic C would use snprintf and accept a buffer. If you insist on returning a heap-allocated object, you could use asprintf, which is not universal but is common. Either way it's a one-liner.

Yeah, but as soon as you use snprintf you're throwing performance to the wind.The idiomatic C++ solution should beat it hands down. (gulp)

Re: Popular Myths about C++, Part 1

#34

Not showing up. Here's an archived version: https://archive.today/LoOe1

Thanks. Very short post though. What I have to say is, that C++11 and onwards had indeed made C++ much more approachable. I think Herb Sutter's talk on modern C++ is also worth a look. [0] [0] https://www.youtube.com/watch?v=TJHgp1ugKGM

Yes, with C++14 many of my rants over C++ are now out-of-date.

I just would like to have modules today.

Re: Popular Myths about C++, Part 1

#35

Earlier quoted context omitted.

What exactly do you need to know about C, that is not part of C++, to understand C++? Genuine question.

why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib?

References in my opinion should actually be called "Address of" operators, then it's much easier for someone new to see why pointers and references exist together.

Printf and the cstdlib - eh yeah I'll hand you that, if someone had no concept at all that a language called C existed prior to C++ this would be confusing without explaining it to them. But a newbie should not be looking at C++ code that uses the cstdlib or printf anyway, they should be looking at streams and true C++ code to begin with.

Re: Popular Myths about C++, Part 1

#36
post #9

Earlier quoted context omitted.

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 t…

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.

Re: Popular Myths about C++, Part 1

#37

Earlier quoted context omitted.

What sort of C programmer wouldn't test for malloc() failing. Drives me batty to see articles where malloc() is happily assumed to always succeed.

> Drives me batty to see articles where malloc() is happily assumed to always succeed. ... as in Linux.

Use `ulimit` from the shell, or invoke `setrlimit`, and you will see malloc fail.

Re: Popular Myths about C++, Part 1

#38

Earlier quoted context omitted.

What exactly do you need to know about C, that is not part of C++, to understand C++? Genuine question.

why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib?

> why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib?

Support for a legacy language full of security holes.

Re: Popular Myths about C++, Part 1

#39
post #32

Has Linus read this yet? I can hear him screaming in fury. :D

Linus has ported his Subsurface project to Qt, thanks to the current state of affairs in Gtk, so I imagine he might be a bit more welcoming to C++ nowadays.

https://github.com/torvalds/subsurface

pretty interesting! the .c's heavily outnumber the .cpp's.

there's nothing like having your prejudices confirmed to harden them, so I question whether he is more welcoming.

Re: Popular Myths about C++, Part 1

#40
A major problem with C++ is a lack of consistency, which you run into if you start trying to generalize the ideas presented in this article.

The article demonstrates string concatenation using +. That is great! Except it's inconsistent. The article's example works fine, of course:

    return name+'@'+domain;
I'll skip over the weird use of '' instead of "". Now let's say I want to prepend mailto: as well:

    return "mailto:" + return name+'@'+domain;
So far so good. But I think it might be clearer if the colon was separated out:

    return "mailto" + ":" + name+'@'+domain;
Oops, this no longer compiles. Hey beginner programmers, let's take time out from the arduous task of learning basic programming to understand what a const char * is and how it differs from const string and why you can + two strings or a string and a const char * or a const char * and a string but you can't + two const char *s.

The next example demonstrates initializing a vector:

    vector v = {1,2,3,5,8,13};
This is great, of course. The example after that introduces "auto" so you don't have to write the type of a variable. Well heck, let's combine the two!

    auto v = {1,2,3,5,8,13};
Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time! OK, beginners, let's take some more time out from learning what you came for and instead learn about the complex machinery that handles initializing a custom type with {} and why "a = b" can do arbitrarily complex things depending on the types of a and b.

I had a job in college tutoring students in my CS department's first-semester programming course, which was taught in C++. People would routinely come in with code that wouldn't compile because of some tiny mistake, but which produced literally pages of error output. There was no way for new students who were still struggling with the concept of a loop to figure out what they were doing wrong, besides finding somebody who had already been through it.

This was a long time ago, and C++ has improved, especially in the error message department. But these problems are still there, even if somewhat diminished, and other languages don't have them.

The fundamental problem with C++ is that it grew organically from humble beginnings without any apparent plan. This allowed to adopt a lot of nifty features and become extremely powerful, but it also means that there are a ton of bizarre corner cases and inconsistencies to deal with. For many projects, the tradeoff is worthwhile. But it's one of the worst choices imaginable for teaching new people to program.

Post reply on HN