Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Popular Myths about C++, Part 1

isocpp.org

Post reply on HN
Print view View original

51–60 of 144 posts

Re: Popular Myths about C++, Part 1

#51

Post by pjmlp »

throwawayaway wrote: post #42
pjmlp wrote: post #38

Earlier quoted context omitted.

> 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.

In riposte: C++ willingly supports all previous security holes and adds a few more. why do we have structs and classes? all this stuff in the first week.

To allow Bjarne to sell C++ to C developers, specially those ex-Assembly programmers that were force-feed to C.

You don't need to learn C, just read "The Design and Evolution of C++".

Re: Popular Myths about C++, Part 1

#52

Post by throwawayaway »

pjmlp wrote: post #51
throwawayaway wrote: post #42

Earlier quoted context omitted.

In riposte: C++ willingly supports all previous security holes and adds a few more. why do we have structs and classes? all this stuff in the first week.

To allow Bjarne to sell C++ to C developers, specially those ex-Assembly programmers that were force-feed to C. You don't need to learn C, just read "The Design and Evolution of C++".

But how can you explain their existence and all the C++ behaviour derived from that without using C - you can't.

Re: Popular Myths about C++, Part 1

#53

Post by Derpdiherp »

throwawayaway wrote: post #41
Derpdiherp wrote: post #35

Earlier quoted context omitted.

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…

C++ falls to the no true scotsman fallacy yet again. If you type in hello world to the internet, you are going to be getting C and C++ versions and you are going to find out that both work. You can't hide the truth from beginners for any length of time. Imagine telling someone that they can't look stuff up on the internet in case they get exposed to "the wrong stuff"? check out google on streams: http://google-styleg…

Bit of a strawman on googling for results - sure I'm not suggesting you can hide the fact it's a relative of C, but I know when I first started out every question I would ask the almighty google oracle would be appended with "C++" - "Why is my code crap C++" - so usually you'd get an actual C++ style solution.

And so far as google and streams, well that's their opinion and fits into their particular style. There's plenty of dev houses that would tell you to avoid C style string manipulation due to the dangers of stack overflows etc.

Anyway I'm not wanting to fall into a C vs C++ argument, I'm merely pointing out that it's very possible for someone to pick up C++ without having the slightest bit of knowledge of C to begin with. I sure didn't know any C to start with.

Re: Popular Myths about C++, Part 1

#54

Post by mikeash »

stinos wrote: post #9
ExpiredLink wrote: post #5

Good luck trying to understand C++ without C. The numerous C++ traps and pitfalls will just look mad to you. BTW, 'multi-paradigm' is an oxymoron. Not even Scala uses that concept any more.

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…

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.

Re: Popular Myths about C++, Part 1

#55

Post by throwawayaway »

Derpdiherp wrote: post #53
throwawayaway wrote: post #41

Earlier quoted context omitted.

C++ falls to the no true scotsman fallacy yet again. If you type in hello world to the internet, you are going to be getting C and C++ versions and you are going to find out that both work. You can't hide the truth from beginners for any length of time. Imagine telling someone that they can't look stuff up on the internet in case they get exposed to "the wrong stuff"? check out google on streams: http://google-styleg…

Bit of a strawman on googling for results - sure I'm not suggesting you can hide the fact it's a relative of C, but I know when I first started out every question I would ask the almighty google oracle would be appended with "C++" - "Why is my code crap C++" - so usually you'd get an actual C++ style solution. And so far as google and streams, well that's their opinion and fits into their particular style. There's pl…

you didn't understand C++ until you understood all the elements of C, you can start to learn C++ w/o C, but you can't continue.

you even knew when you started that you had to append C++!

Re: Popular Myths about C++, Part 1

#56

Post by humanrebar »

mike-cardwell wrote: post #18
nly wrote: 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…

> That's the good thing about C. With C++, you don't know what is being allocated, where. With C, it is explicit.

You're complaining about allocation in the C++ standard library. How many allocations does sqlite3_open_v2 make? How about git_repository_open?

C code hides allocation just as much as C++ code does. Only C++ provides simple mechanisms (destructors) to make sure everything gets cleaned up when the stack unwinds.

I'll agree that std::string does the wrong thing here. The C++ standard library gets strings wrong in a lot of ways. That's why vector usually provides better examples.

Re: Popular Myths about C++, Part 1

#57

Post by pjmlp »

throwawayaway wrote: post #49
Ragnarork wrote: post #48

Earlier quoted context omitted.

Pointers aren't even there for supporting a legacy language, they have their use and are distinct from references. Mixing the two and thinking they are equivalent (though they are close in what they do) is a mistake.

How can you have pointers without allowing all the holes that C allows?

By using them like safe system programming languages from Algol/Mesa line do.

Out function parameters are implicit pointers via references. Cannot be null.

Pointers and arrays aren't compatible.

Pointer arithmetic is frown upon and in many of those languages requires an explicit unsafe block/system module import.

Re: Popular Myths about C++, Part 1

#58

Post by throwawayaway »

pjmlp wrote: post #57
throwawayaway wrote: post #49

Earlier quoted context omitted.

How can you have pointers without allowing all the holes that C allows?

By using them like safe system programming languages from Algol/Mesa line do. Out function parameters are implicit pointers via references. Cannot be null. Pointers and arrays aren't compatible. Pointer arithmetic is frown upon and in many of those languages requires an explicit unsafe block/system module import.

would it be fair to say you have just described references, or do I have to go and lookup this algol/mesa stuff?

Re: Popular Myths about C++, Part 1

#59

Post by mikeash »

humanrebar wrote: post #50
mikeash wrote: post #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:…

To be fair everything you're upset about is a problem with the standard C++ library, not the language itself. Not to say that the language doesn't have issues. The initializer list example you provide is half of one, but only because people don't like to write algorithm-based code. This is actually fine: auto v = {1, 2, 3, 5, 8, 13}; for (auto i : v) { std::cout ...all that being said, the C++ standard library gets s…

The standard library is part of the language. But that aside, the fact that + doesn't work on string literals cannot possibly be a problem with the standard library. The fact that the language lets you extend + to work with some types but not others is not a problem with the standard library.

As for initializer lists, the problem isn't simply that {} doesn't produce a vector, it's that identical-looking constructs do completely different things in different contexts. a = b can do completely different things depending on where you see it and what declarations are visible and on and on. Again, not a problem with the standard library.

The standard library suffers from these problems, as it must since it exists within the language that causes them. But the problems are not in the standard library.

Re: Popular Myths about C++, Part 1

#60

Post by pierrebai »

mike-cardwell wrote: post #13

"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings." I just compiled the C code and the C++ code using: gcc -std=c99 -Wall -Wextra test.c -o test g++ -std=c++11 -Wall -Wextra test.cpp -o test According to valgrind: C: total heap usage: 1 allocs, 1 frees,…

This is the archetypal problem with benchmarks: not only are they hard to design, but people will incorrectly nit-pick the results.

You count the number of allocations, without looking at the big picture: this is a toy example. It provides the hard-coded input to the function. This results in the C version not having to allocate memory for the hard-coded literals and the function problably being inlined and optimized away and the strlen() calls being equally optimized away as the length of the strings are known at compile time.

In the real world, these would come from some input where they would need to be allocated on the heap, just like the C++ version does. It would use just as many allocations, except they will all be hand-rolled, hand-held, error-prone, with every bit of memory management explicit. C++ is superior in every measure here. Only in toy programs and hard-coded strings does C wins.

If the goal was to have as few allocations from hard-coded strings, then just write "foo@bar" and avoid the concatenation altogether. That is not the point of the example.

(Also, the newer C++ standard support std::string literals, FWIW.)

Post reply on HN