const char* not crashing?

Started by
22 comments, last by Sneftel 14 years, 10 months ago
Quote:Original post by Atrix256
Quote:Original post by Lode
when they decided not to add useful strings to the language


#include <string.h>

there's lots of string functionality there.... get your facts right man


Having "string functionality" is not remotely the same thing as having "useful strings". First off, the functionality has to be applied manually, and the string doesn't properly exist as an object. Second, it's a real pain to use.

Holding up string.h here is sort of like setting up a dog's dinner bowl in the kitchen, having your child fill it daily, and emptying it daily when noone is looking; and then claiming to have bought the child a dog. The functionality is there but the expected agent isn't, and it's not really all that useful.
Advertisement
Quote:Original post by phresnel
Unfortunately, that's not insignificant (heh we are having fun [smile]).


Yes, it is.

What matters is the "big enough" criteria. 1, 8, 24 or 64 kB is not "big enough".

4GB today however is.

There was that old joke about "copy the internet to the floppy". While at that time the mere notion of being able to carry the internet around with you seemed silly, today it's not. Internet doesn't fit on a floppy, but it fits into a shipping container.

Quote:For example, I'd really like to have a 32 core processor.


So why not buy one?

Will you suddenly be able to solve bigger problems? Or just able to solve all of the existing ones up to 32 times faster.

The difference is that majority of hardware today is "good enough" for all the problems they encounter. Not only that, but NetBooks show that computers 5 years ago were good enough for most purposes.

But before then - they were not. Same rationale applies to some earlier design choices. It wasn't a matter of convenience, but simply of what was practical and possible. The assumption that entire working data set would fit into local storage was not a realistic consideration.

Looks like an extended stack allocation lifetime issue. As I don't own a copy of the C++ standard, doing a bit of googling reveals GotW #88: A Candidate For the "Most Important const"
Quote:Herb Sutter
Normally, a temporary object lasts only until the end of the full expression in which it appears. However, C++ deliberately specifies that binding a temporary object to a reference to const on the stack lengthens the lifetime of the temporary to the lifetime of the reference itself, and thus avoids what would otherwise be a common dangling-reference error.

Could it be this? :)
---Sudet ulvovat - karavaani kulkee
Quote:Original post by Naurava kulkuri
Could it be this? :)

No. That applies to const references being bound to non-reference return types, not pointers being bound to pointer return types.

This topic is closed to new replies.

Advertisement