Unlike heap allocation, using data on the stack is automatically
cache-friendly. It’s perfectly possible to allocate data from the heap
though. It’s done all the time. I’m not familiar with QT, so I can’t
comment on whether using stack-allocated objects in QT causes security
problems (how?). If it is true, it boils down to bad programming skills
or bad documentation, not bad language.
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.
And yes, that’s partially a bad programming skills issue, and I’ve
heard that a lot of these bugs have been fixed lately, but it’s also
partially the fault of bad language design for making it possible in
the first place.
Stack allocation is wonderful for value types. But once you get
something that owns references to other variables, it’s more trouble
than it’s worth. Then you’re better off using another x86 feature:
the built-in instructions for dereferencing pointers.
Then use data from the heap where necessary. You’re not really
suggesting C++ should dump stack allocation altogether?
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.
Wait, no. That would break backwards compatibility with too much
existing code. What I’m really suggesting is that programmers
should dump C++ altogether. 
C++ is not a VHLL. C++ covers a different area of use than you seem to
want. You can perfectly use C++ for programming a 16MHz ATMega micro
with 16 Kilobytes RAM. Partly because C++ uses, by default, a string
representation that hardware can process efficiently: just a
zero-terminated list of bytes.
That’s probably the worst example you could have given. See
http://www.joelonsoftware.com/articles/fog0000000319.html in which
Joel Spolsky, who knows a lot more about C++ than I ever will,
explains why C strings are pretty much the worst possible way to
handle strings, from the perspective of the CPU. He specifically holds
up the Pascal string model as an improvement. It has one drawback,
that strings are very limited in size. This can be fixed, though, by
using two bytes, or four, instead of one for the length data.
Of course, since strings tend to be big, you probably don’t want to
be passing them around by value (copying all howevermany bytes
to the stack every time you make a function call) anyway, so it’s a
good idea to make them reference types. IIRC, C strings are
always reference types anyway, so that’s not much of a
problem… yet.
But due to pointer aliasing, changing a string with multiple
references to it would cause trouble. So how do you fix that?
By putting a reference count on your string, (which takes care
of memory and cleanup issues as long as you don’t do anything
stupid like casting it to a pointer), and implementing copy-on-write
semantics for strings with multiple references.
Of course, all of this has to be baked into the compiler to really
work well. But once you get it working, you have something far
more efficient for real-world use cases than C strings. No linear
scan required for obtaining the length or concatenation.
(Imagine trying to take the length of a C string representing the
text of an entire novel!) And with the length known up front, your
CPU can read from it one native word size at a time, (or more, if
you’ve got SIMD instructions and large registers available, for
example,) instead of having to go one byte at a time and then
test each individual byte to see if it’s 0, which results in huge speed
gains on modern hardware.
The additional cost for all these real-world optimizations is a few
extra bytes per string. 4-8, depending on how large you make your
size marker and your reference count, as opposed to 1 byte of
overhead for C strings. This is the Delphi string model. It’s the
sort of thing that happens when language designers actually think
about how certain language features get used in real-world use
cases, instead of applying premature optimizations. (And, of
course, if those extra bookkeeping bytes are just too much for your
scenario, the option to fall back to old-school Pascal strings is still
available.)>----- Original Message ----
From: Johannes Kroll
Subject: Re: [SDL] rival library?
