Live data from Hacker News

Popular Myths about C++, Part 1

isocpp.org

81–90 of 144 posts

Re: Popular Myths about C++, Part 1

#81
post #76
post #44

Earlier quoted context omitted.

Malloc will never fail on Linux due to running out of RAM . However, it will fail for other reasons, such as running out of address space. You can easily run out of address space in 32-bit processes, since you only have 4GB of address space, or less. It's much harder in 64-bit processes, but since you can allocate vast chunks of memory without having them be backed by RAM, you can accomplish it there as well.

"You can easily run out of address space in 32-bit processes, since you only have 4GB of address space, or less." Ah, 21st Century problems.

I know, right!? Kids these days. Sheesh. :-)

Re: Popular Myths about C++, Part 1

#82
post #66

Earlier quoted context omitted.

> 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! IMO it would be more confusing if that created a vector . Unless the compiler is reading your mind, how is it supposed to know you meant a vector , a set , deque , a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?

The way most other languages handle it is that the list literal construct just creates a list, and if you want something else then you need to explicitly convert. For example, in Python: x = [1, 2, 3, 5, 8, 13] # this is a list of integers y = set([1, 2, 3, 5, 8, 13]) # this is a set of integers There's nothing inherently wrong with C++'s initializer list approach. Nor is there anything inherently wrong with auto. Bu…

Well, to be fair, with "auto x = { 1, 2, 3, 4, 5, 6}" you will get a variable named "x", but it won't be a std::vector (it'll be a std::initializerList).

Re: Popular Myths about C++, Part 1

#83
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:…

The aim of C++ is not to be accessible to beginners. There are other languages for that. The philosophy of C++ is to give you power and it's up to you how to handle it.

Re: Popular Myths about C++, Part 1

#84
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:…

> 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! IMO it would be more confusing if that created a vector . Unless the compiler is reading your mind, how is it supposed to know you meant a vector , a set , deque , a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?

Go would do:

    v := []TYPEHERE{1, 2, 3}
where TYPEHERE is the type of array[1] that you're creating. Is there any equivalent C++ technique here? Explaining all the machinery may blow out a novice's mind, but I think explaining "You need to give C++ some clue about the type" isn't so bad.

[1]: Before you complain I just created a slice, remember the slice has to point at an array; I've created both a slice and an array so it's not "wrong" to say I've created an array with that syntax.

Re: Popular Myths about C++, Part 1

#85
post #83
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:…

The aim of C++ is not to be accessible to beginners. There are other languages for that. The philosophy of C++ is to give you power and it's up to you how to handle it.

The article explicitly states that C++ is a good language for beginners, and the entire point of my comment is to argue against that.

Re: Popular Myths about C++, Part 1

#86

Earlier quoted context omitted.

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.

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

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

Re: Popular Myths about C++, Part 1

#87

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?

Because references can't be NULL in C++, and you can't reseat a reference in C++.

> why does printf exist?

Personally, I think the more interesting question is "why isn't printf extensible?" And, with variable length template functions, it should now be extensible. If it were converted to a template.

> what is everything in the cstdlib?

I can't speak for all beginners, but I can say that when I was a beginner, the concept of language (and library) evolution was never hard for me to grasp. Even in a world where C never existed, I think I could have understood that some the library had old ways to do things, and new ways to do the same thing.

In fact, I can't think of any language that's been around for more than, say, ten years without a little cruft and duplication in the standard library.

Re: Popular Myths about C++, Part 1

#88
post #44

Earlier quoted context omitted.

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

Malloc will never fail on Linux due to running out of RAM . However, it will fail for other reasons, such as running out of address space. You can easily run out of address space in 32-bit processes, since you only have 4GB of address space, or less. It's much harder in 64-bit processes, but since you can allocate vast chunks of memory without having them be backed by RAM, you can accomplish it there as well.

It's not so much that malloc can fail, but that you're likely to get whacked by OOM before you run out of address space on linux. To get malloc to return a NULL, you would have to be allocating more than 4Gb of memory on a 32 bit system, the system has to have no swap, and you have to not have used any of the memory between the last physically available memory, and the memory allocated by the chunk that takes you over the 4Gb limit. Anything else gets you SIGKILLed.

Re: Popular Myths about C++, Part 1

#89

Earlier quoted context omitted.

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

By not using them like in C. Of course this isn't an argument, but this shows that even though C++ doesn't prevent you from falling into the same trap that are present in C, it does give you the tool to at least allow you to do better than C to avoid these traps, notably thanks to RAII. Oh and let's not forget nullptr, which is a blessing compared to NULL. Pointers are still a feature of both languages. Pointers in C…

You need to understand so much about C to even talk about pointers in C++, and everything related to them, it's not funny.

RAII -> Why? nullptr vs. NULL -> Why? Pointers -> Why? Don't use them in a certain way -> Why?

The answer in all cases is C.

Re: Popular Myths about C++, Part 1

#90

Earlier quoted context omitted.

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? Because references can't be NULL in C++, and you can't reseat a reference in C++. > why does printf exist? Personally, I think the more interesting question is "why isn't printf extensible?" And, with variable length template functions, it should now be extensible. If it were converted to a template. > what is everything in the cstdlib? I can't speak for all beginners,…

I don't disagree with you, but I am arguing against people who say you don't need to understand C.

If it were the case that the new ways were actually superior in all cases, then that point would stand, but in many they are not.

It's a confederation of languages and pretending it isn't hinders people and their understanding.

Post reply on HN