Re: C bug of the day

[Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de>]

Kevin Cline <kcline17@hotmail.com> wrote:
: Vinzent Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bc4n70$fei5u$1@ID-175126.news.dfncis.de>...
:> kanze@gabi-soft.fr wrote:
:> 
:> >  I'd rather have a language
:> >in which all of the defaults were fundamentally safe, but with the
:> >freedom to override them if you had special constraints, or even in
:> >cases where you came across a case which the language authors hadn't
:> >considered.  I don't know such a language, however; it may exist
:> >somewhere, but if it does, it certainly isn't very popular or wide
:> >spread.
:> 
:> And that's been posted to comp.lang.ada? ;-)
: 
: Sorry, Ada doesn't solve this problem.  Ada has no equivalent to the
: C++ STL.

And the STL is there to allow you to override the safety defaults,
whilst in Ada you cannot override safety defaults? At least the
latter seems completely wrong to me, actually.

And what about the STL being possible with C++ only?  Except
for tricky and useful compile time Lisp in C++ templates, and
()-operator magic sugar, I don't think this is so, ask Matthew
Heaney about Charles.

: Ada is fine as long as you are happy to program using only arrays. 
: Beyond that, you are stuck searching the web for some public domain
: components and hoping they have been debugged enough to be reliable,

Most of the components are licensed, not in the public domain,
at least not in the US public domain, afaict.  And the old Booch
components were accompanied by a huge book (1987) full of careful
analysis and presentation. Doesn't make sense to me to assume they
might not have been debugged enough, or be unreliable. Likewise,
what makes you assume that the new Booch components ("based on
Mr. Booch's more recent C++ design"), which also seem to have
been actively developed for some years now, cannot at least be
compared to the non-theoretical STL implementations out there?
Despite the different approach taken, there is at least no
#ifdef hell in these components.

(Have you ever tried to write standard conforming STL code using
a compiler like Comeau's and then port that standard conforming
code to some other "C++ compiler" ;-)

BTW, I don't feel forced to use arrays a lot, despite their
outstanding features, when compared to non-STL C++ "arrays".

: or writing your own and hoping that you don't somehow screw up
: new/unchecked deallocation.

Why is there Boost, if the STL solves all problems?
Why are there patterns if the STL solves all problems?
Which patterns implementation is standardised with C++?

Last but no least, what kind of safety and reliability do you
get from C++ with or without STL when it comes to organizing
your software around processes, resources, and data exchange
between them? How does the C++ standard guarantee portability
of this kind of software? Does it?


// Georg