More safety problems than security problems, though there are points
where the two overlap. By passing (copies of) stack-allocated objects
outside the library to user code, which the user code was then able to
obtain references to. Hilarity ensues once the stack gets cleaned up
and objects that the object contains a reference to are deallocated
out from under the user.Errr… That’s a typical newbie error, right? Compilers issue warnings
for these types of errors.
Only when the compiler knows what’s going on. See above, re:
passing them outside of the library.
No, of course not. See above, “stack allocation is wonderful for
value types.” I’m suggesting that C++ should dump stack allocation
for objects altogether.So where exactly do you draw the line between “objects” and “value
types”? Is a class containing only a few ints and no
pointers/references to anything an object, or a “value type”?
That sounds like a value type to me, and a good candidate for putting
into a struct, though it depends on how many ints constitute “a few”.
Anything significantly larger than sizeof(pointer) probably should be a
reference type anyway, for performance reasons.
Still, I don’t think the dumbness of a few programmers should dumb down
the whole language.
Neither do I, but you have to draw the line somewhere. I prefer to err on
the side of caution. These aren’t issues for “a few dumb programmers”.
They’re very common C++ gotchas that everyone ends up getting tripped
up by, and has to learn and commit to memory, and even then can end up
forgetting, causing embarrassing and occasionally dangerous problems.
When it’s that easy to get it wrong, that’s a strong indication that the
underlying system is badly-designed. The correct solution isn’t “bend
every single user’s thought patterns away from what’s intuitive into what
fits the system,” it’s “fix the system to make it more intuitive!”
Let’s not discuss performance issues of C-style vs Pascal-style
stringsI don’t think it makes a huge difference one way or the
other.
Please don’t take this the wrong way, but if you truly think that
having to run a linear scan to find the length of a string in O(n) time
instead of having it immediately available in O(1) time, and needing
to perform all string operations one byte at a time, with a conditional
test between each byte, instead of in the largest chunks the CPU can
use to transfer data, with the conditional test against a length value
that’s known from the start and can be kept in a register that doesn’t
have to have values loaded into it over and over, doesn’t make a
significant difference, (especially on low-end CPUs like you’re
talking about!) then yes, I probably shouldn’t be discussing
performance issues with you.
But the memory usage might. Making the length prefix
variable-sized isn’t really feasible since then you would have to
compile all the code an app uses (including libraries) with the same
prefix-size options. So you end up using 4-byte prefixes. So each
string uses 3 bytes more memory than a C string would. This doesn’t
normally matter on desktops of course, but on microcontrollers and the
like, it does matter.
What sort of microcontrollers are you referring to? These days, even
tiny embedded systems like cellphones have access to hundreds of
megabytes of RAM. An extra 3 bytes per string might have been
significant 10 years ago, but today?
But due to pointer aliasing, changing a string with multiple
references to it would cause trouble. So how do you fix that?If you change a string, it is changed, no matter how many references to
it exist. This is just plain obvious. Everything else would be
counter-intuitive, and wrong. Nothing to fix here.
Not necessarily. Yes, you need to copy a string when you make
changes to it, to avoid stomping aliased references, but how do you
know when is the right time to copy? If you pass a C string into a
function, you don’t know if it’s got one reference to it or a hundred,
so you end up needing to make a (possibly unnecessary) copy
if you’re going to change it. This can be very expensive if it’s a
large string, especially since C has to copy the string one byte at a
time with a conditional test between each byte.
By building reference counting into the language’s string type,
you ensure that copying always takes place when it needs to, and
never when it doesn’t. No chance of user error there. I’d have to
check to make sure, but I don’t think the Delphi standard library
even has a strcopy() function, because it doesn’t need one.>----- Original Message ----
From: Johannes Kroll
Subject: Re: [SDL] rival library?
