M
Mathias Gaunard
DragonSt0rm said:It is also the C++ paradigm when due to some other restriction you have to
allocate on heal instead of the stack.
Consider for example an embedded (or old DOS) system with a small stacksize,
where you have to allocate a RGBA image of 500x300 pixels. You can't do
that on stack. The "invention" of smartpointers (like auto_ptr) was fueled
exactly because of the fact that this paradigm was widely used.
Yes, strangely enough for Mathias, the new/delete operators preceded the
auto_ptr in the C++ (not C) language history
How are smart pointers related to what you're saying?
What you need here is an Image type, which indeed does dynamic
allocation. It is way closer to a container. (and the easiest
implementation is to directly use a std::vector as a member, which
replaces advantageously any usage of new[]).
Smart pointers where invented because of the polymorphism problem,
mainly, and eventually to move around non-copyable types too. That's
totally unrelated.
Anyway, what I was saying is that all resources must always be freed in
destructors. That is RAII, and you should follow it ; it is the main C++
idiom.
If for some obscure reason you don't want to follow it (which is your
right, and is actually safe to do if you're only playing around things
with nothrow guarantee) then don't mark it as a standard idiom or good
practice.
The fact that is modern days, it is thought at the same moment, it is a
mater of evolution of language and of the teaching methods. But it wasn't
always that way. Borland 1.0 didn't knew about templates at all.
Borland 1.0 didn't know about C++. It didn't even follow the ARM.
C++ was defined in 1998 and includes templates.
So, from the historical perspective I was talking about (when Java was
designed) what I presented there IT WAS the standard C++ paradigm.
That's just a C paradigm where you replaced malloc with new.
Just like old C++ was just C with classes.
Java tried to eliminate the "delete problem" by introducting the GC, yet
this generated a whole set of issues related to nonmemory resource
allocation/disposal.
GC isn't just about the "delete problem" as you call it.
Maybe you should consider learning about GC and what its applications
are before trying to criticize it.