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.
Popular Myths about C++, Part 1
81–90 of 144 posts
Re: Popular Myths about C++, Part 1
#82Earlier 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…
Re: Popular Myths about C++, Part 1
#83A 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:…
Re: Popular Myths about C++, Part 1
#84A 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?
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
#85A 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
#86Earlier 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:…
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
#87Earlier 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?
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
#88Earlier 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.
Re: Popular Myths about C++, Part 1
#89Earlier 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…
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
#90Earlier 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,…
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.