Re: memory management in Ada: tedious without GC?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 18 May 2008 01:50:21 -0700 (PDT), jhc0033@gmail.com wrote:

> On May 18, 12:03 am, Martin Krischik <krisc...@users.sourceforge.net>
> wrote:

>> #include <vector> is missing for it to become "perfectly legal". This is the
>> typical cheat of C++ advocates - selling there standart library as
>> languages features.
> 
> So if the C++ standard said: "<vector> is included by default", that
> would make C++ a better language in your opinion?

Right, actually less built-in types a language has, the better the language
is.

The problem with C++ and vector is not that vector is not built-in. It is
that vector cannot have a treatment fully equal to a built-in type:

1. Its body cannot be allocated on the stack.
2. It is not a proper type (requires parametrization)
3. Optimization. I have doubts that small vectors could be passed by value,
loops over them unrolled, values cached in registers, that static bounds
checking could be enforced at compile time and skipped at run-time etc.

Further, the array abstraction is incomplete:

4. It does not have a class over the element type
5. It does not have a class over the index type

(Ada does not have 4-5 either)

>> But that is unfair as vector<> can be implemented in any language including
>> assember.
> 
> Oh, panlinguistic guru, I'd like to see you try to implement "STL" in
> C! I wonder if you'll go for macros or void* type casts with type
> sizes as explicit parameters. How will you implement automatic memory
> management and deep copy semantics for arbitrary user-constructed type
> parameters?

This is a misunderstanding. Clearly, it is doable in any Turing-complete
language. The problem is how much an implementation could be disguised as a
normal array type. However, because assembler does not have much types
anyway, where is a problem? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de