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

91–100 of 144 posts

Re: Popular Myths about C++, Part 1

#91

Post by npalli »

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

>>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};

The auto example creates an std::initializer_list which then can be converted into a vector or a set

    std::vector newvectorfromauto(v);

    std::set newsetfromauto(v);
Which seems the best you can expect with auto deduction. What else do you have in mind?

Re: Popular Myths about C++, Part 1

#92

Post by mikeash »

antimagic wrote: post #88
mikeash wrote: 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.

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

Swap has nothing to do with it. Getting malloc to fail is easy:

    malloc(-1);
With address space fragmentation, the requested size can be a lot smaller and still fail. With overcommit, you can allocate a ton of memory without using up any RAM.

Re: Popular Myths about C++, Part 1

#93

Post by maxlybbert »

throwawayaway wrote: post #90
maxlybbert wrote: post #87

Earlier quoted context omitted.

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

I will admit that the textbook I learned C++ from didn't cover C-style string manipulation (other than to say it was error prone). It took a very long time for me to be comfortable doing any kind of string operation without first converting to a std::string. Nowadays I realize that there are often different answers to different questions, and it doesn't bother me.

Re: Popular Myths about C++, Part 1

#94

Post by TheCoelacanth »

jerf wrote: post #84
jlarocco wrote: post #65

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?

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…

Yes, C++ has no shortage of ways to initialize variables. Any of these should work

    TYPENAME v {1, 2, 3};
    TYPENAME v = {1, 2, 3};
    auto v = TYPENAME {1, 2, 3};

Re: Popular Myths about C++, Part 1

#95

Post by bkeroack »

jerf wrote: post #86
bkeroack wrote: post #45

Earlier quoted context omitted.

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

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.

Re: Popular Myths about C++, Part 1

#96

Post by jerf »

bkeroack wrote: post #95
jerf wrote: post #86

Earlier quoted context omitted.

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

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.

Re: Popular Myths about C++, Part 1

#97

Post by jj00 »

WhitneyLand wrote: post #43

Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints? Back in the day I read Bjarne's book cover to cover, used C++ for very large scale projects, and was one of those guys who could make sense of arbitrarily complex pointer expressions. Now I mostly regret it. Led down the rabbit hold of multiple inheritance, STL being much more complicated than templating in other langu…

Couldn't you say this for any language? As soon as you start applying it to larger projects things start to get more complicated. It's not the same problem per language, but each has their own issues.

Re: Popular Myths about C++, Part 1

#98

Post by Retra »

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…

Standard libraries are part of the language. I would go so far as to say anybody who designs a language that isn't meant to make their standard libraries powerful, consistent, and elegant isn't doing any favors for the discipline.

Re: Popular Myths about C++, Part 1

#99

Post by bkeroack »

jerf wrote: post #96
bkeroack wrote: post #95

Earlier quoted context omitted.

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?

Re: Popular Myths about C++, Part 1

#100

Post by jerf »

bkeroack wrote: post #99
jerf wrote: post #96

Earlier quoted context omitted.

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.

Post reply on HN