C bug of the day

C bug of the day

[Hyman Rosen]

One of the trading systems we use in our company had been
crashing every night for a week while trying to run a
certain batch procedure. We finally traced the problem to
the usual C bugaboo, a buffer overflow.

In this case, the program was trying to form an SQL command
for entering a row of data into a database table. Even though
the program is written in C++, the programmers apparently
decided that the way to produce the SQL was to format it into
a fixed-size buffer. Unfortunately, they decided to use '%f'
to format some floating-point numbers, and more unfortunately,
a situation arose in our data where a number was on the order
of 10**141. Boom!

We don't have the source code, but they do ship the program as
relinkable libraries. We found the offending string and patched
the binary to use %g instead of %f. Sigh.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Ron Natalie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message news:sUUCa.41207$fT5.6121@nwrdny01.gnilink.net...

> We don't have the source code, but they do ship the program as
> relinkable libraries. We found the offending string and patched
> the binary to use %g instead of %f. Sigh.

Ahh, the power of EMACS for code maintenance.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[John H. Lindsay]

Hi Hyman & All:

Hyman Rosen wrote:
> 
> One of the trading systems we use in our company had been
> crashing every night for a week while trying to run a
> certain batch procedure. We finally traced the problem to
> the usual C bugaboo, a buffer overflow.
.....

Welcome to the old timer's club.  Sit back and enjoy a beer 
while we reminisce about old machines, old problems, bugs 
that we tell each other that no one, and scarcely even 
ourselves could find, but we did in spite of it all.  Don't 
ya just love debugging at the bit level ?

John

-- 
John H. Lindsay   jDELETEUPPERCASETOREPLYlindsay@kingston.net
48 Fairway Hill Crescent, Kingston, Ontario, Canada, K7M 2B4.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> One of the trading systems we use in our company had been
> crashing every night for a week while trying to run a
> certain batch procedure. We finally traced the problem to
> the usual C bugaboo, a buffer overflow.
> 
> In this case, the program was trying to form an SQL command
> for entering a row of data into a database table. Even though
> the program is written in C++, the programmers apparently
> decided that the way to produce the SQL was to format it into
> a fixed-size buffer. Unfortunately, they decided to use '%f'
> to format some floating-point numbers, and more unfortunately,
> a situation arose in our data where a number was on the order
> of 10**141. Boom!

We've encountered a number of C problems here, similar to that.
The only difference is that our source code in question was
primarily in C. But your experience only goes to show as I have
always maintained, that C++ is not safe because of the STL.
There will always be the temptation to go straight to
the old C habits (I know, you can go out of your way to do
bad things in Ada too, but in Ada at least, this is usually
more effort.. not less).

Your problem occurred with a large number. The best one I had
encountered was the reverse. The value was near zero as something
like 1.0E-14. It took me 3 months of hard core debugging to ferrit
this one out, because it was occuring inside of a shared library that
was about 250k SLOC (C code). Because we always found problems
in this legacy code, I never expected to find the problem where it
finally turned up.

The problem ended up in an INFORMIX-7.31 library,
where the float (or was it decimal?) value was being converted
to some other form (I think it was decimal -> string) for
a formatted print with picture info. Chance are that this bug
is still in the current version ;-)

After building many types of electric
fence routines, I eventually proved that the problem was caused
by this INFORMIX conversion routine when the value had a very
negative exponent. It seems that the INFORMIX routine did not
plan its buffer properly in this scenario. Fortunately, for this
application, I was able to just plug in a zero if
the value was sufficiently small. This fixed the memory corruption
problem.

That little buffer overflow problem cost me 3 months of my life,
and was a very expensive mistake for the company to correct.

> We don't have the source code, but they do ship the program as
> relinkable libraries. We found the offending string and patched
> the binary to use %g instead of %f. Sigh.

Creative fix!  8-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<sUUCa.41207$fT5.6121@nwrdny01.gnilink.net>...
> One of the trading systems we use in our company had been
> crashing every night for a week while trying to run a
> certain batch procedure. We finally traced the problem to
> the usual C bugaboo, a buffer overflow.
>
> ....

I believe the standard response here is "a competent programmer would
not make that mistake!"  ;-)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Hyman Rosen]

John H. Lindsay wrote:
 > Welcome to the old timer's club.

Heh. This wasn't the hardest thing I've ever had
to debug by a long shot. Others had been working
on the problem, they knew what routine it was
dying in, and someone mentioned that they had
noticed that the numbers were unusually large.
As soon as I heard that, I said "%f", and then
we immediately found and fixed it.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
 > The problem ended up in an INFORMIX-7.31 library
 >
 > That little buffer overflow problem cost me 3 months of my life,
 > and was a very expensive mistake for the company to correct.

Oddly enough, the most mysterious bug I had to deal with
recently turned out to be a problem in Sybase ODBC drivers.
I had been programming database code in Visual Basic in Excel.
The company was changing people over from WindowsNT to
Windows2000, and certain of my spreadsheets stopped working.
Stored procedure calls would fail mysteriously. You can only
imagine the number of blind alleys I wandered down trying to
figure out what was going on.

The ultimate culprit? The ODBC driver when invoked from Excel
sent Sybase its host ID in hex. One of the internal stored
procedures of the same trading system would get the host ID,
which Sybase returns as a string, and try to convert it to
decimal. When there happened to be no hex digits in the ID,
everything would be fine. When there were, the conversion
would cause an error, aborting the procedure. On and off,
that bug cost me a couple of months of hair pulling.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[LLeweLLyn]

Hyman Rosen <hyrosen@mail.com> writes:

> One of the trading systems we use in our company had been
> crashing every night for a week while trying to run a
> certain batch procedure. We finally traced the problem to
> the usual C bugaboo, a buffer overflow.
>
> In this case, the program was trying to form an SQL command
> for entering a row of data into a database table. Even though
> the program is written in C++,

I wonder if their implementation of C++ provides std::stringstream,
    whose use could have avoided this problem. I wonder if they had
    access to C99 snprintf, which at least provides a way to detect
    that the string was too long for the buffer, without out
    overriding the buffer.

Since you crossposted this to comp.lang.ada, I wonder if they had any
    programmers who knew there was a programming language named
    ada. :-) 

> the programmers apparently
> decided that the way to produce the SQL was to format it into
> a fixed-size buffer. Unfortunately, they decided to use '%f'
> to format some floating-point numbers, and more unfortunately,
> a situation arose in our data where a number was on the order
> of 10**141. Boom!
>
> We don't have the source code, but they do ship the program as
> relinkable libraries. We found the offending string and patched
> the binary to use %g instead of %f. Sigh.
[snip]

Now that is an *ugly* (but IMO necessary) solution ...

Perhaps you should raise the bug as justification for obtaining a
    source license.

I don't see that you have any point in posting this other than the
    obvious venting - I think we all have to do things like this once
    in a while.

However I would like to know of some ideas for dealing with this sort
    of thing. We all deal with reams of buggy and poorly designed
    code, but it seems most of the expert-recommended patterns and
    idioms assume good code.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Carlos Moreno]

Warren W. Gay VE3WWG wrote:

> fence routines, I eventually proved that the problem was caused
> by this INFORMIX conversion routine when the value had a very
> negative exponent. 

Very negative...???   As opposed to just a little negative?  (10%
negative or less?  No more than 5% negativeness?)

;-)

Carlos
--
PS: Sorry!  Couldn't resist the temptation!  :-)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Ken Hagan]

Warren W. Gay VE3WWG wrote:
>
> But your experience only goes to show as I have
> always maintained, that C++ is not safe because of the STL.
> There will always be the temptation to go straight to
> the old C habits (I know, you can go out of your way to do
> bad things in Ada too, but in Ada at least, this is usually
> more effort.. not less).

Whether that is tempting depends on your library and your
personal outlook. printf ought to be slower than IO streams,
particularly if the latter aren't sync-ed with stdio, so I
don't see much temptation there.

I think the real issue here is that C++ programmers tend to
be fairly tolerant of the C legacy and consider functions
like vsprintf to be really flexible building blocks rather
than the spawn of the devil.

Ada programmers are probably using Ada precisely because they
disagree with that viewpoint. I'd guess that an Ada programmer
forced to write in C++ would always use IO streams rather than
the C library. (This thread is cross-posted, so presumably I'm
about to find out. :)



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Peter van Merkerk]

> But your experience only goes to show as I have
> always maintained, that C++ is not safe because of the STL.

Would you care to explain why "C++ is not safe because of the STL"?

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Wesley Groleau]

> I wonder if their implementation of C++ provides std::stringstream,

I'd like to have midstream::horses and then try to change it.

(What can I say, I'm in a weird mood)

Re: C bug of the day

[Raoul Gough]

Hyman Rosen <hyrosen@mail.com> writes:

 > Warren W. Gay VE3WWG wrote:
 >  > The problem ended up in an INFORMIX-7.31 library
 >  >
 >  > That little buffer overflow problem cost me 3 months of my life,
 >  > and was a very expensive mistake for the company to correct.
 >
 > Oddly enough, the most mysterious bug I had to deal with
 > recently turned out to be a problem in Sybase ODBC drivers.
 > I had been programming database code in Visual Basic in Excel.
 > The company was changing people over from WindowsNT to
 > Windows2000, and certain of my spreadsheets stopped working.
 > Stored procedure calls would fail mysteriously. You can only
 > imagine the number of blind alleys I wandered down trying to
 > figure out what was going on.
 >
 > The ultimate culprit? The ODBC driver when invoked from Excel
 > sent Sybase its host ID in hex. One of the internal stored
 > procedures of the same trading system would get the host ID,
 > which Sybase returns as a string, and try to convert it to
 > decimal. When there happened to be no hex digits in the ID,
 > everything would be fine. When there were, the conversion
 > would cause an error, aborting the procedure. On and off,
 > that bug cost me a couple of months of hair pulling.

I remember a buffer overflow that started crashing some DB access code
of ours when we moved the DB from one machine to another (our code was
written in C++ and C, so this is mildly on topic). The only thing was,
the buffer actually was big enough for the data we were retrieving,
and putting magic markers at either end of the buffer showed no
past-the-end writing taking place. Nevertheless, certain data sets
crashed the program consistently, and only when the database being
accessed was on the local machine.

I was going bananas trying to figure this out, until I realised that
part of our code was dealing with the exact size of the current BLOB,
whereas other parts were using the BLOB *segment* size for the DB in
general. If the given BLOB was actually smaller than a single segment,
we were misreporting the size of our buffer to the DB library. Now,
with the DB on the local machine, the smart old Rdb library was
mapping the file data into memory, rather than reading and copying
it. The buffer was big enough for the BLOB's data, but actually not as
big as we claimed, so the memory map system call was failing
sometimes. I suspect it happened only when the buffer happened to be
near the top of the process's virtual memory.

I fixed our code and reported a bug to the Rdb support anyway, because
it should have been reporting an error instead of crash dumping.

-- 
Raoul Gough
"Let there be one measure for wine throughout our kingdom, and one
measure for ale, and one measure for corn" - Magna Carta

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Hyman Rosen]

Peter van Merkerk wrote:
 > Would you care to explain why "C++ is not safe because of the STL"?

He misphrased his English somewhat. He means that "just because C++
has the STL, that does not make it safe", alluding to the leagcy C
stuff that is present.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Terje Slettebø]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1054751321.434656@master.nyc.kbcfp.com...
> Peter van Merkerk wrote:
>  > Would you care to explain why "C++ is not safe because of the STL"?
>
> He misphrased his English somewhat. He means that "just because C++
> has the STL, that does not make it safe", alluding to the leagcy C
> stuff that is present.

Ah. Well, that depends of course on how you program. If you use safer
things in C++, then you can avoid the problems of the C library
functions.

There's also a "Proposal for Technical Report on C++ Standard Library
Security"
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1425.pdf),
which mainly has to do with giving safer alternative functions to the
more dangerous C functions in the C++ standard library. Yet, there are
typically better ways of doing this in C++, than to use these functions.


Regards,

Terje

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Dave Harris]

hyrosen@mail.com (Hyman Rosen) wrote (abridged):
> > Would you care to explain why "C++ is not safe because of
> > the STL"?
> 
> He misphrased his English somewhat. He means that "just
> because C++ has the STL, that does not make it safe",
> alluding to the leagcy C stuff that is present.

Although the other meaning is true too. C++ is unsafe largely
due to undefined behaviour, and the STL has plenty of that.
For example, vec[-1].

-- Dave Harris, Nottingham, UK

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Balog Pal]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:sUUCa.41207$fT5.6121@nwrdny01.gnilink.net...

> In this case, the program was trying to form an SQL command
> for entering a row of data into a database table. Even though
> the program is written in C++, the programmers apparently
> decided that the way to produce the SQL was to format it into
> a fixed-size buffer. Unfortunately, they decided to use '%f'
> to format some floating-point numbers, and more unfortunately,
> a situation arose in our data where a number was on the order
> of 10**141. Boom!


Microsoft's managed to have a similar bug in MFC 's CString::Format().
That
supposed to return a corect string for the arguments.  Internally they
calculate the needed length for the format line, and some 128 bytes got
assumed fot %f. Which spans to around 300.

That waw in MSVC 5.0, corrected in 6.0. Look out for old mfc42.dll-s
possibly still lingering.

Paul



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

brangdon@cix.co.uk (Dave Harris) wrote in message
news:<memo.20030605193115.9141A@brangdon.madasafish.com>...
> hyrosen@mail.com (Hyman Rosen) wrote (abridged):
> > > Would you care to explain why "C++ is not safe because of
> > > the STL"?

> > He misphrased his English somewhat. He means that "just because C++
> > has the STL, that does not make it safe", alluding to the leagcy C
> > stuff that is present.

> Although the other meaning is true too. C++ is unsafe largely due to
> undefined behaviour, and the STL has plenty of that.  For example,
> vec[-1].

Or resizing a container and invalidating an iterator:-).

C++ is unsafe for any number of reasons.  The STL just follows in the
same old grand tradition.

On the other hand, C++ gives the programmer an enormous freedom.
Including the freedom to write very safe programs.  I know of some other
languages which make a lot of claims because one or two elements have a
safer default (array accesses always bounds checked, for example), but
which don't allow you any way of added to the safety built into the
language.

That doesn't mean C++ is perfect, of course.  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.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Vinzent Hoefler]

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? ;-)


Vinzent.

Re: C bug of the day

[Preben Randhol]

Vinzent Hoefler wrote:
> 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? ;-)

Yes. Only goes to show that there are a lot of people who doesn't know
that there are better alternatives to C/C++. *sigh*

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: C bug of the day

[Matthew Heaney]

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message
news:<bbkea6$mo$1$8300dec7@news.demon.co.uk>...
> 
> Ada programmers are probably using Ada precisely because they
> disagree with that viewpoint. I'd guess that an Ada programmer
> forced to write in C++ would always use IO streams rather than
> the C library. (This thread is cross-posted, so presumably I'm
> about to find out. :)

You are correct.  I use string, iostream, stringstream classes for
just about everything.  I don't think I've ever used printf or scanf
in any C++ program I've written, and rolled my own replacements for
the deprecated strstream classes (which were horribly designed).

My latest project was to write a streambuf that directs its output to
::OutputDebugString during sync().

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Preben Randhol]

kanze@gabi-soft.fr wrote:
> On the other hand, C++ gives the programmer an enormous freedom.
> Including the freedom to write very safe programs.  I know of some
other
> languages which make a lot of claims because one or two elements have
a
> safer default (array accesses always bounds checked, for example), but
> which don't allow you any way of added to the safety built into the
> language.

?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Jim Rogers]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbeboi5.1qc.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Vinzent Hoefler wrote:
> > 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? ;-)
> 
> Yes. Only goes to show that there are a lot of people who doesn't know
> that there are better alternatives to C/C++. *sigh*

This is even more disappointing coming from the author (James Kanze).
I have had email conversations with him about Ada. He has heard of Ada.
He has never used Ada. He does not understand what he has been told.

I suppose, if your whole experience is using C and / or C++
you would have a difficult time understanding Ada from a purely
intellectual viewpoint. Some of these understandings must derive from
more visceral experience.

Jim Rogers

Re: C bug of the day

[Wesley Groleau]

>>>> 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.

> This is even more disappointing coming from the author (James Kanze).
> I have had email conversations with him about Ada. He has heard of Ada.
> He has never used Ada. He does not understand what he has been told.

Sounds to me like he knows he's describing Ada
and pretending he doesn't.
Could it be a subtle form of trolling ?

Re: C bug of the day

[Hyman Rosen]

Wesley Groleau wrote:
> Could it be a subtle form of trolling ?

I don't think so. He's a regular poster on the C++ groups,
and he's always intelligent and sensible. From everything
I can tell, though, I think he's that C++ programmer that
we're always talking about, the one that really doesn't
ever make a mistake. That could explain his perspective.

Re: C bug of the day

[kanze]

Preben Randhol <randhol+abuse@pvv.org> wrote in message
news:<slrnbeboi5.1qc.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Vinzent Hoefler wrote:
> > 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? ;-)

> Yes. Only goes to show that there are a lot of people who doesn't know
> that there are better alternatives to C/C++. *sigh*

I didn't say that there weren't better languages.  I only said that
there wasn't a perfect language.

I've never actually used Ada, so I cannot say for sure, but from what
I've heard and read, it does have better defaults than C++, at least in
most cases.  I suspect that for many applications, it would be a better
choice, at least on purely technical grounds, than C++.  I suspect that
the same thing is true for a number of other languages, such as Eiffel
or Modula-3.  

But I'm not sure. My original contact with Modula-3 was 10 years ago,
and I found it beautiful. A couple of months ago, I took another look.
While much of the original elegance is still there, it did seem a bit
archa�c for some things: no multiple inheritance, no destructors, etc.
While C++ has a lot of bad points, it also has some very good points
(like destructors).  In the last ten years, I've grown very used to
these good points, and very adept at avoiding the bad points.  To the
point that if a language is missing one of the good points, it seems
somehow lacking something, even if it has corrected all of the bad
points.

One could also argue that Ada isn't very popular or wide spread.  At
least, I've never been able to get a contract where I could use it.  And
I'd really like to try it, if only to be able to speak with authority
one way or the other.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[kanze]

jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message
news:<82347202.0306101232.16776a81@posting.google.com>...

> I suppose, if your whole experience is using C and / or C++ you would
> have a difficult time understanding Ada from a purely intellectual
> viewpoint. Some of these understandings must derive from more visceral
> experience.

Bingo.  I've read about Ada.  I've even read the Ada standard.  I admire
Ada.  I suspect that it is a really effective language.  But until I've
actually used it, in a real application of some size, I can't really
know.  (I also suspect that it has some hidden catches too.  Probably
less than C++, but it WAS developed by human beings.)

And don't read too much into my original comment.  I was unaware of the
cross-posting to the Ada group, and the point I was trying to make was
only that C++ isn't perfect, but that with care, it can be used
effectively.  To a certain degree, of course, the same can be said of
any language -- I'll stand by my statement that a perfect language
doesn't exist.  But obviously, the amount of care varies according to
the language.  Perhaps more importantly, where the care is needed
varies: one of the most common errors in Java programs is forgetting a
finally; in C++, the proper use of destructors make this particular
problem almost inexistant.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[kanze]

Wesley Groleau <wesgroleau@despammed.com> wrote in message
news:<fOOdnX15fpHvN3ujXTWcqg@gbronline.com>...
> >>>> 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.

> > This is even more disappointing coming from the author (James
> > Kanze).  I have had email conversations with him about Ada. He has
> > heard of Ada.  He has never used Ada. He does not understand what he
> > has been told.

> Sounds to me like he knows he's describing Ada and pretending he
> doesn't.

Just to set the record straight, I hadn't seen the cross posting, and
wasn't thinking of Ada at all.

There are a number of languages whose developers have placed safe use as
a very high criteria.  Some of them also allow unsafe practices when
possible.  From what I've read, Modula-3 is my favorite of these, but
Ada is certainly among them (and even Modula-3 has one or two things I
don't like).  While I very much like these languages in theory, I've
never had the occasion to actually use them in a real application.  So I
tend to forget about them.

There are also languages which correct one or two weaknesses of C++, but
also throw out all of its good points, and make work-arounds impossible
in the cases which they got wrong (which are still a lot).  The results
are that even though such languages claim great safety, and do tend to
core dump less often in the hands of a na�ve programmer (but is a wrong
result better than a core dump?), it is very difficult, if not
impossible, for a careful and conscientious programmer to write code to
the level of quality that I usually insist on.  Never the less, some of
these languages have received a great deal of publicity because of their
supposed safety.

I was mainly thinking of this latter group when I wrote my statement.
While I'll stand by my statement that no language is perfect, with
regards to Ada, I'll admit my ignorance, and say that from what I've
read of the language, I'm very favorably impressed.

> Could it be a subtle form of trolling ?

Not intentionally, at any rate.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[Erlo Haugen]

On 11 Jun 2003 02:22:09 -0700
kanze@gabi-soft.fr wrote:
---Cut---
> 
> I didn't say that there weren't better languages.  I only said that
> there wasn't a perfect language.
---Cut---

No language can be perfect, I guess. What is good for some kind of tasks might
be bad in other cases. Ada has its strengths and weaknesses (think about string
handling). I don't think anyone would even think about Ada for embedded
applications in 8 bit MCU's as an example.

Erlo

-- 
Remove the underscores

Re: C bug of the day

[James Rogers]

kanze@gabi-soft.fr wrote in
news:d6652001.0306100323.338a2a1c@posting.google.com:

 > That doesn't mean C++ is perfect, of course.  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.
 >

Since this was cross-posted to comp.lang.ada I think it is fair to
mention that there is a language that meets your description above.
That language is Ada.

Its defaults are fundamentally safe. It provides the ability to
override the safety constraints whenever you choose to. Note how
Ada differs from Java. You cannot turn off array bounds checking
for Java. In Ada you can. In fact, many Ada compilers will optimize
out bounds checking when they can determine the checks are
unnecessary.

In other words, you can arrive at the same level of safety which
is the default for C++. With Ada, however, you need to remove
safety checks to get there. Manually removing safety checks is not
usually needed for performance reasons.

Most programmers will use a language in the manner which requires
minimum effort. This is why safety checks are not terribly common
in C++. It is also why manually turning off safety checks is not
terribly common in Ada.

Jim Rogers

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Vinzent Hoefler]

Erlo Haugen wrote:

>No language can be perfect, I guess. What is good for some kind of tasks might
>be bad in other cases. Ada has its strengths and weaknesses (think about string
>handling). I don't think anyone would even think about Ada for embedded
>applications in 8 bit MCU's as an example.

Well, why not? If there's a compiler available? :-)


Vinzent.

Re: C bug of the day

[Peter Hermann]

Erlo Haugen <_elh_@_terma_._com_> wrote:
> handling). I don't think anyone would even think about Ada for embedded
> applications in 8 bit MCU's as an example.

You are "thinking" wrong**2

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: C bug of the day

[Erlo Haugen]

On Wed, 11 Jun 2003 10:36:19 +0000 (UTC)
Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote:

> Erlo Haugen <_elh_@_terma_._com_> wrote:
> > handling). I don't think anyone would even think about Ada for embedded
> > applications in 8 bit MCU's as an example.
> 
> You are "thinking" wrong**2
> 
Interesting! Any examples/links??

Erlo

-- 
Remove the underscores

Re: C bug of the day

[Erlo Haugen]

On Wed, 11 Jun 2003 12:11:00 +0200
Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:

> Erlo Haugen wrote:
> 
> >No language can be perfect, I guess. What is good for some kind of tasks
> >might be bad in other cases. Ada has its strengths and weaknesses (think
> >about string handling). I don't think anyone would even think about Ada for
> >embedded applications in 8 bit MCU's as an example.
> 
> Well, why not? If there's a compiler available? :-)
> 
> 
> Vinzent.

Architectural limitations. 
Some of the single chip MCU's are quite limited with respect to stack
manipulation and registers. I had MC6809 in mind when I wrote the previous 
message.I have done a lot of programing on this MCU, and it has no provision
for stack manipulation etc. 

As for other 8 bits, Z80 and the like would be good candidates.

Erlo

-- 
Remove the underscores

Re: C bug of the day

[Vinzent Hoefler]

Erlo Haugen wrote:

>On Wed, 11 Jun 2003 12:11:00 +0200
>Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
>
>> Erlo Haugen wrote:
>> 
>> >No language can be perfect, I guess. What is good for some kind of tasks
>> >might be bad in other cases. Ada has its strengths and weaknesses (think
>> >about string handling). I don't think anyone would even think about Ada for
>> >embedded applications in 8 bit MCU's as an example.
>> 
>> Well, why not? If there's a compiler available? :-)
>
>Architectural limitations.

Those would apply to any higher level programming language.

>As for other 8 bits, Z80 and the like would be good candidates.

At least for 6502 and Z80 exist C-compilers, so I don't see why there
shouldn't be any Ada-Compiler. I even remember playing around with
Pascal and FORTH on a Z80 machine (around 1986).


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[Erlo Haugen]

On Wed, 11 Jun 2003 13:08:02 +0200
Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
ates.
> 
> At least for 6502 and Z80 exist C-compilers, so I don't see why there
> shouldn't be any Ada-Compiler. I even remember playing around with

Efficiency ?? 


> Pascal and FORTH on a Z80 machine (around 1986).
> 

Jupiter Ace. I have one of those...Fast little thing (Compared to ZX??)

Erlo

-- 
Remove the underscores

Re: C bug of the day

[Vinzent Hoefler]

Erlo Haugen wrote:

>On Wed, 11 Jun 2003 13:08:02 +0200
>Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
>> 
>> At least for 6502 and Z80 exist C-compilers, so I don't see why there
>> shouldn't be any Ada-Compiler. I even remember playing around with
>
>Efficiency ?? 

Well, I don't see what would make Ada-compiled code less efficient
that C-compiled code. :)

Or do you mean, that programming HLL on those machines is quite
inefficient in general?

>> Pascal and FORTH on a Z80 machine (around 1986).
>
>Jupiter Ace.

No no, this one: <http://www.zock.com/8-Bit/D_KC85-3.HTML>. I don't
know where the FORTH thingie came from.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[Erlo Haugen]

On Wed, 11 Jun 2003 13:58:05 +0200
Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:

> Erlo Haugen wrote:
> 
> >On Wed, 11 Jun 2003 13:08:02 +0200
> >Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
> >> 
> >> At least for 6502 and Z80 exist C-compilers, so I don't see why there
> >> shouldn't be any Ada-Compiler. I even remember playing around with
> 
> >Efficiency ?? 
> 
> Well, I don't see what would make Ada-compiled code less efficient
> that C-compiled code. :)
>

Perhaps not, but C need to implement pointers, which Ada don't.
Could one imagine an MCU without indexed access to ram??
 
> Or do you mean, that programming HLL on those machines is quite
> inefficient in general?
>
If the ram area is small and the registers awkward, yes. (MC68705 in variuos
versions comes to mind.)

> >> Pascal and FORTH on a Z80 machine (around 1986).
> 
> >Jupiter Ace.
> 
> No no, this one: <http://www.zock.com/8-Bit/D_KC85-3.HTML>. I don't
> know where the FORTH thingie came from.
> 
The Ace runs Forth.

Erlo
-- 
Remove the underscores

Re: C bug of the day

[James Rogers]

kanze@gabi-soft.fr wrote in
news:d6652001.0306110131.6ac9e693@posting.google.com: 

> jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message
> news:<82347202.0306101232.16776a81@posting.google.com>...
> 
>> I suppose, if your whole experience is using C and / or C++ you would
>> have a difficult time understanding Ada from a purely intellectual
>> viewpoint. Some of these understandings must derive from more
>> visceral experience.
> 
> Bingo.  I've read about Ada.  I've even read the Ada standard.  I
> admire Ada.  I suspect that it is a really effective language.  But
> until I've actually used it, in a real application of some size, I
> can't really know.  (I also suspect that it has some hidden catches
> too.  Probably less than C++, but it WAS developed by human beings.)
> 
> And don't read too much into my original comment.  I was unaware of
> the cross-posting to the Ada group, and the point I was trying to make
> was only that C++ isn't perfect, but that with care, it can be used
> effectively.  To a certain degree, of course, the same can be said of
> any language -- I'll stand by my statement that a perfect language
> doesn't exist.  But obviously, the amount of care varies according to
> the language.  Perhaps more importantly, where the care is needed
> varies: one of the most common errors in Java programs is forgetting a
> finally; in C++, the proper use of destructors make this particular
> problem almost inexistant.
> 

I do not think you will get any significant resistance to the idea that
Ada is imperfect. If you look through the current list of threads in 
comp.lang.ada you will find a number of suggestions for improving the
language.

You will also probably see that few of these suggestions are focused on
improving fundamental Ada safety. Most are focused on ways to make Ada
more popular.

I assert that it is impossible to develop a universally perfect language.
Different problem domains require different language strengths. I do not,
for instance, believe a single language can satisfy all the requirements
of a scripting language while simultaneously satisfying all the needs of
an embedded language used in SIL-4 level applications.

Jim Rogers

Re: C bug of the day

[Vinzent Hoefler]

Erlo Haugen wrote:

>On Wed, 11 Jun 2003 13:58:05 +0200
>Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
>
>> Erlo Haugen wrote:
>> 
>> >On Wed, 11 Jun 2003 13:08:02 +0200
>> >Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
>> >> 
>> >> At least for 6502 and Z80 exist C-compilers, so I don't see why there
>> >> shouldn't be any Ada-Compiler. I even remember playing around with
>> 
>> >Efficiency ?? 
>> 
>> Well, I don't see what would make Ada-compiled code less efficient
>> that C-compiled code. :)
>
>Perhaps not, but C need to implement pointers, which Ada don't.

Well, just because Ada hides pointers from the programmer to a large
amount that doesn't mean, it does not have them at all.

This is more an compiler implementation issue. IMO, as an example, a
good thing is that an Ada compiler would be free to choose whether a
parameter to a function is given by value or by reference, depending
on what seems more efficient either for time or space optimizations.
Assuming a rather good optimizing compiler, the compiler's choice
could actually be the better one. In C the compiler is bound to
implement the programmer's choice, whether is seems efficient or not.

Of course, it could also be the other way around. ;)

>> Or do you mean, that programming HLL on those machines is quite
>> inefficient in general?
>>
>If the ram area is small and the registers awkward, yes. (MC68705 in variuos
>versions comes to mind.)

Well, in that case, ACK.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[Bernd Trog]

Erlo Haugen <_elh_@_terma_._com_> wrote in message 
> > > handling). I don't think anyone would even think about Ada for embedded
> > > applications in 8 bit MCU's as an example.
> > 
> > You are "thinking" wrong**2
> > 
> Interesting! Any examples/links??

Atmel-AVR:
http://sourceforge.net/projects/avr-ada/

Motorola 68hc11:
http://gel.sourceforge.net/ada_example.php

Re: C bug of the day

[Erlo Haugen]

On Wed, 11 Jun 2003 14:59:57 +0200
Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:

> Erlo Ha
> 
> Well, just because Ada hides pointers from the programmer to a large
> amount that doesn't mean, it does not have them at all.
> 
> This is more an compiler implementation issue. IMO, as an example, a
> good thing is that an Ada compiler would be free to choose whether a
> parameter to a function is given by value or by reference, depending
> on what seems more efficient either for time or space optimizations.
> Assuming a rather good optimizing compiler, the compiler's choice
> could actually be the better one. In C the compiler is bound to
> implement the programmer's choice, whether is seems efficient or not.
> 
> Of course, it could also be the other way around. ;)
> 

You are quite right, most modern compilers are extremely good at optimization.
I have seen generated code that I by no means would try to do better by hand,
even on a processor that I know as well as my own backyard.

> >> Or do you mean, that programming HLL on those machines is quite
> >> inefficient in general?
> >>
> >If the ram area is small and the registers awkward, yes. (MC68705 in variuos
> >versions comes to mind.)
> 
> Well, in that case, ACK.
>
Actually, that was what I meant to say in my first posting :-) Guess I didn't
succeed very well.

Erlo


-- 
Remove the underscores

Re: C bug of the day

[Wesley Groleau]

kanze@gabi-soft.fr wrote:
> One could also argue that Ada isn't very popular or wide spread.  At
> least, I've never been able to get a contract where I could use it.  And
> I'd really like to try it, if only to be able to speak with authority
> one way or the other.

And there's the problem.

Contract uses Ada and you never have?  Don't waste time
applying because you'll never get past the HR guy whose
ony clue about Ada is that it's not on your r�sum�.

Same goes for Java, C++, APL, Fortran, C#, ....

Your r�sum� might show that you have learned and applied
ten languages and ten development environments in twenty
years, but if you aren't already experienced at _their_
current fad, you're out.

I saw one ad that _required_ "two years experience in C#
or one year each at at least two jobs."  This was when
C# was less than three years old!

Re: C bug of the day

[Warren W. Gay VE3WWG]

Erlo Haugen wrote:
> On 11 Jun 2003 02:22:09 -0700
> kanze@gabi-soft.fr wrote:
> ---Cut---
> 
>>I didn't say that there weren't better languages.  I only said that
>>there wasn't a perfect language.
> 
> ---Cut---
> 
> No language can be perfect, I guess. What is good for some kind of tasks might
> be bad in other cases. Ada has its strengths and weaknesses (think about string
> handling). I don't think anyone would even think about Ada for embedded
> applications in 8 bit MCU's as an example.
> 
> Erlo

I don't see string handling as being a "weakness". I know I sure
saw it that way when I was first starting to use the language. But
with the necessary experience, you learn the "Ada way" of working
with strings (this includes how to use native strings and when to
use Ada.Strings.Unbounded etc.)

If you want to be picky, C has "weaknesses" with strings too. For
example if you want to return a string value as a parameter, you
have to supply its maximum length as a separate argument (the
string pointer itself does not reflect how much room you have for
the result). There are other ways of returning strings through a
parameter, but none of them without their own caveats.

Ada does require the programmer to think differently to use "native
strings". But this is not necessarily a "weakness" because it is
different.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: C bug of the day

[Wesley Groleau]

> an embedded language used in SIL-4 level applications.

Is 'SIL-4' a typo for 'SEI-4' or something I never heard of?

Re: C bug of the day

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

In article <PricnaN_zorZxnqjXTWcqA@gbronline.com>, Wesley Groleau <wesgroleau@despammed.com> writes:
> kanze@gabi-soft.fr wrote:
>> One could also argue that Ada isn't very popular or wide spread.  At
>> least, I've never been able to get a contract where I could use it.  And
>> I'd really like to try it, if only to be able to speak with authority
>> one way or the other.
> 
> And there's the problem.
> 
> Contract uses Ada and you never have?  Don't waste time
> applying because you'll never get past the HR guy whose
> ony clue about Ada is that it's not on your r�sum�.

But it is possible that some hiring manager has properly trained HR
to understand that good programmers can learn additional languages.
If that happens, you have located an employer devoutly to be coveted.

Re: C bug of the day

[Robert I. Eachus]

Wesley Groleau wrote:

> I saw one ad that _required_ "two years experience in C#
> or one year each at at least two jobs."  This was when
> C# was less than three years old!

My favorite was a ad on the back cover of Communications of the ACM 
requiring 10 years of Ada experience.  I'd have to check old ARG minutes 
to set an exact date, I think 1988. (There was an ARG meeting in Munich 
along with the Ada Europe meeting.)  An dinner during the ARG meeting we 
tried to figure if there was anyone sitting at the table who qualified. 
  (Jean Ichbiah was there along with John Barnes, Robert Dewar, Mike 
Woodger and a few others active early in the Ada design effort.)

Re: C bug of the day

[Mike Silva]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<PricnaJ_zoqTwXqjXTWcqA@gbronline.com>...
> > an embedded language used in SIL-4 level applications.
> 
> Is 'SIL-4' a typo for 'SEI-4' or something I never heard of?

Safety Integrity Level 4

http://wheelie.tees.ac.uk/hazop/standards/56/lifecyc/riskest.htm
http://wheelie.tees.ac.uk/hazop/standards/56/lifecyc/table7.htm
http://wheelie.tees.ac.uk/hazop/standards/56/lifecyc/table3.htm

Re: C bug of the day

[Kevin Cline]

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.
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,
or writing your own and hoping that you don't somehow screw up
new/unchecked deallocation.

Re: C bug of the day

[Andrei Alexandrescu]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9396BDBB14558jimmaureenrogers@204.127.36.1...
> Its defaults are fundamentally safe. It provides the ability to
> override the safety constraints whenever you choose to. Note how
> Ada differs from Java. You cannot turn off array bounds checking
> for Java. In Ada you can. In fact, many Ada compilers will optimize
> out bounds checking when they can determine the checks are
> unnecessary.

In fairness, it should be said that Java optimizers have the same
prerogative.

> In other words, you can arrive at the same level of safety which
> is the default for C++. With Ada, however, you need to remove
> safety checks to get there. Manually removing safety checks is not
> usually needed for performance reasons.
>
> Most programmers will use a language in the manner which requires
> minimum effort. This is why safety checks are not terribly common
> in C++. It is also why manually turning off safety checks is not
> terribly common in Ada.

That's deep. I bet a ton of problems would have not existed through the
years if C (or at least C++) would have required:

int i = uninitialized;

instead of:

int i;

to define an uninitialized variable, and would have defaulted to
zero-initialization in the latter case.


Andrei



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Wesley Groleau]

> At least for 6502 and Z80 exist C-compilers, so I don't see why there
> shouldn't be any Ada-Compiler. I even remember playing around with
> Pascal and FORTH on a Z80 machine (around 1986).

I had "Janus" on a Z80 in the late 1980s.
Janus was a subset of Ada--I don't remember
what was missing.

Re: C bug of the day

[Wesley Groleau]

Larry Kilgallen wrote:
> But it is possible that some hiring manager has properly trained HR
> to understand that good programmers can learn additional languages.
> If that happens, you have located an employer devoutly to be coveted.

I'm coveting, I'm coveting...
But I am not locating.  :-)

Re: C bug of the day

[Vinzent Hoefler]

Kevin Cline 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.

In what respect? The primary question was about safety, not some kind
of hyper-versatility. And the safety problem cannot be solved with C++
and an STL.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[Erlo Haugen]

On Wed, 11 Jun 2003 12:40:52 -0400
"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote:
 > 
> > No language can be perfect, I guess. What is good for some kind of tasks
> > might be bad in other cases. Ada has its strengths and weaknesses (think
> > about string handling). I don't think anyone would even think about Ada for
> > embedded applications in 8 bit MCU's as an example.
> > 
> > Erlo
> 
> I don't see string handling as being a "weakness". I know I sure
> saw it that way when I was first starting to use the language. But
> with the necessary experience, you learn the "Ada way" of working
> with strings (this includes how to use native strings and when to
> use Ada.Strings.Unbounded etc.)
>

I didn't mean weakness as in "unsafe". It's just that string handling in Ada is
a little tediuos. Other languages has much better provision for string handling.
This was just to show that for some jobs, other languages might be more
productive.

> If you want to be picky, C has "weaknesses" with strings too. For
> example if you want to return a string value as a parameter, you
> have to supply its maximum length as a separate argument (the
> string pointer itself does not reflect how much room you have for
> the result). There are other ways of returning strings through a
> parameter, but none of them without their own caveats.
> 
> Ada does require the programmer to think differently to use "native
> strings". But this is not necessarily a "weakness" because it is
> different.

Correct. But the point I wanted to make was that a language that is perfect (or
close to) for one task is not neccessary any good for another task.

Erlo

-- 
Remove the underscores

Compilers on old machines (was: C bug of the day)

[Vinzent Hoefler]

Dennis Lee Bieber wrote:

>Vinzent Hoefler fed this fish to the penguins on Wednesday 11 June 2003 
>04:08 am:
>
>> At least for 6502 and Z80 exist C-compilers, so I don't see why there
>> shouldn't be any Ada-Compiler. I even remember playing around with
>> Pascal and FORTH on a Z80 machine (around 1986).
>>
>        Rather late...

Hey, I was just a little twelve-year-old-boy at that time... :)

>My TRS-80 was being replaced with an Amiga in that time 
>frame.

Well, in the GDR (aka. East Germany) such stuff was quite hard to get
and if so, it was damn expensive. Some of my friends were *very* proud
of their C64's.

>        My TRS-80, in 1982/83, was running Alcor Pascal, Supersoft LISP, and 
>Misosys Pro-MC (a K&R C that may have started life as LC, and the 
>latter was a Small-C variant). 64KBytes (of which the OS sucked up 
>about 8KB), dual 180K floppies. Supersoft LISP actually ran on a 32K 
>machine with no disk drives, just an audio cassette.

Same here. Not actually LISP, I mean the cassette. Kind of fun to wait
for three minutes just to load the compiler.

>The OS had 
>features Windows still lacks (individual passwords on files, 7level 
>file access permission, automatic drive search [not really needed these 
>days] for files if no drive specified [or the default drive is 
>read-only and you open an output file], and a /job log/).

Pretty impressive for such small machines. At least compared with
today, where Pacman would need 3D-Hardware, a Gigaherz-CPU, at least
256 MB RAM to run, and would eat 500 MBytes of disk space. ;)

I like the small machines. Probably this is why I like doing things
with an 8 MHz-CPU that even a today's Pentium-IV couldn't reliably do
on Windows.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[James Rogers]

"Andrei Alexandrescu" <SeeWebsiteForEmail@moderncppdesign.com> wrote in
news:bc8423$gt53a$1@ID-14036.news.dfncis.de:

 > "James Rogers" <jimmaureenrogers@att.net> wrote in message
 > news:Xns9396BDBB14558jimmaureenrogers@204.127.36.1...
 >> Its defaults are fundamentally safe. It provides the ability to
 >> override the safety constraints whenever you choose to. Note how
 >> Ada differs from Java. You cannot turn off array bounds checking
 >> for Java. In Ada you can. In fact, many Ada compilers will optimize
 >> out bounds checking when they can determine the checks are
 >> unnecessary.
 >
 > In fairness, it should be said that Java optimizers have the same
 > prerogative.

Yes, Java optimizers can disable bounds checking. Java programmers
cannot. The point I was trying to make is that Ada allows the programmer
to explicitly turn off checks. Most of the time it is not necessary
or desirable to turn off checks. Nevertheless, the programmer is allowed
to do so.

 >
 >> In other words, you can arrive at the same level of safety which
 >> is the default for C++. With Ada, however, you need to remove
 >> safety checks to get there. Manually removing safety checks is not
 >> usually needed for performance reasons.
 >>
 >> Most programmers will use a language in the manner which requires
 >> minimum effort. This is why safety checks are not terribly common
 >> in C++. It is also why manually turning off safety checks is not
 >> terribly common in Ada.
 >
 > That's deep. I bet a ton of problems would have not existed through the
 > years if C (or at least C++) would have required:
 >
 > int i = uninitialized;
 >
 > instead of:
 >
 > int i;
 >
 > to define an uninitialized variable, and would have defaulted to
 > zero-initialization in the latter case.

Interesting. Do you think the fundamental safety problem in C code
is ininitialized integers? What about memory leaks, de-referencing
null pointers, and array bounds violations?

The lint tool was able to identify uninitialized variables nearly
thirty years ago. Of course, lint is not part of the C language,
but it is one of those tools that has been used to try to improve
the quality of C code for decades. With the common availability of
lint for so many years, why is do uninitialized variables still
occur in C?

The reason is that many programmers neglect to use tools such as
lint, which support my point. Programmers are frequently lazy.
They will do what takes the least amount of time to meet minimum
requirements. This is simple human nature.

A language that requires extra work to achieve safety will
frequently be used to create unsafe programs. This is not
because it is impossible to create safe programs with the language.
It is because doing so requires extra work.

On the other hand, a language that requires extra work to remove
built in safety features will frequently be used to create safe
programs. This is not because it is impossible to create unsafe
programs with the language. It is because doing so requires extra
work.

Jim Rogers

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Georg Bauhaus]

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

Re: C bug of the day

[Andrei Alexandrescu]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9397C17B49692jimmaureenrogers@204.127.36.1...
> "Andrei Alexandrescu" <SeeWebsiteForEmail@moderncppdesign.com> wrote
in
>  > That's deep. I bet a ton of problems would have not existed through
the
>  > years if C (or at least C++) would have required:
>  >
>  > int i = uninitialized;
>  >
>  > instead of:
>  >
>  > int i;
>  >
>  > to define an uninitialized variable, and would have defaulted to
>  > zero-initialization in the latter case.
>
> Interesting. Do you think the fundamental safety problem in C code
> is ininitialized integers? What about memory leaks, de-referencing
> null pointers, and array bounds violations?

I was mentioning that just to mention a simple language design decision
that's a no-brainer to implement, yet which imho has a great impact
because
of the psychological issue you mentioned. The others are also important,
but
not as trivial to implement and support without making performance
tradeoffs.


Andrei



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[kanze]

James Rogers <jimmaureenrogers@att.net> wrote in message
news:<Xns9397449823400jimmaureenrogers@204.127.36.1>...
> kanze@gabi-soft.fr wrote in
> news:d6652001.0306110131.6ac9e693@posting.google.com: 

> > jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message
> > news:<82347202.0306101232.16776a81@posting.google.com>...

> >> I suppose, if your whole experience is using C and / or C++ you
> >> would have a difficult time understanding Ada from a purely
> >> intellectual viewpoint. Some of these understandings must derive
> >> from more visceral experience.

> > Bingo.  I've read about Ada.  I've even read the Ada standard.  I
> > admire Ada.  I suspect that it is a really effective language.  But
> > until I've actually used it, in a real application of some size, I
> > can't really know.  (I also suspect that it has some hidden catches
> > too.  Probably less than C++, but it WAS developed by human beings.)

> > And don't read too much into my original comment.  I was unaware of
> > the cross-posting to the Ada group, and the point I was trying to
> > make was only that C++ isn't perfect, but that with care, it can be
> > used effectively.  To a certain degree, of course, the same can be
> > said of any language -- I'll stand by my statement that a perfect
> > language doesn't exist.  But obviously, the amount of care varies
> > according to the language.  Perhaps more importantly, where the care
> > is needed varies: one of the most common errors in Java programs is
> > forgetting a finally; in C++, the proper use of destructors make
> > this particular problem almost inexistant.

> I do not think you will get any significant resistance to the idea
> that Ada is imperfect. If you look through the current list of threads
> in comp.lang.ada you will find a number of suggestions for improving
> the language.

That's good news.  I know that when I was using Java, you could get
seriously flames in comp.lang.java.programming just for suggesting that
the language wasn't perfect.

> You will also probably see that few of these suggestions are focused
> on improving fundamental Ada safety. Most are focused on ways to make
> Ada more popular.

Obviously, you concentrate on the most important problems first:-).
Good luck.  (I rather doubt that a language can be both safe and
popular.  History, at any rate, is against you.)

> I assert that it is impossible to develop a universally perfect
> language.  Different problem domains require different language
> strengths. I do not, for instance, believe a single language can
> satisfy all the requirements of a scripting language while
> simultaneously satisfying all the needs of an embedded language used
> in SIL-4 level applications.

Exactly.  And in some cases, my opinion as to what the safe default is
may not agree with yours.  If your argument is that it is significantly
easier to write a robust application in Ada than in C++, all that I have
been able to find out about the language without actually using it makes
me think that you are right.  If you try to claim that it is impossible
to write an incorrect program without overriding a default behavior, on
the other hand...

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[Preben Randhol]

kanze@gabi-soft.fr wrote:
> If you try to claim that it is impossible to write an incorrect
> program without overriding a default behavior, on the other hand...

No, we do not claim that Ada catches logical errors. For some reason a
lot of people think that when one say that Ada catches a lot of errors
because the compiler can extract more information due to the language
and thus catch a lot of the errors at compile-time in stead of at
run-time, we mean that it catches *all* error both non-logical and
logical. But to quote from a previous discussion:

   "... in Ada, you can never have a buffer overflow error. Unless of
   course you go very far out of your way to specifically program one
   [...] most Ada programmers would consider going out of your way to
   construct an Ada program that had a potential buffer overflow not
   as a challenge, but as a kind of pornography." - Robert I. Eachus

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: C bug of the day

[kanze]

Wesley Groleau <wesgroleau@despammed.com> wrote in message
news:<PricnaN_zorZxnqjXTWcqA@gbronline.com>...
> kanze@gabi-soft.fr wrote:
> > One could also argue that Ada isn't very popular or wide spread.  At
> > least, I've never been able to get a contract where I could use it.
> > And I'd really like to try it, if only to be able to speak with
> > authority one way or the other.

> And there's the problem.

> Contract uses Ada and you never have?  Don't waste time applying
> because you'll never get past the HR guy whose ony clue about Ada is
> that it's not on your r�sum�.

> Same goes for Java, C++, APL, Fortran, C#, ....

I know.  A lot depends on the market.  Around five years ago, I got a
contrat using Java, although I'd never written a line of Java code.
Around five years ago, at least here in Europe, employers were happy to
get anyone they could.

On the other hand: the people who offered me the Java job weren't dumb.
There were three technical experts present at the interview.  After two
questions, it was obvious that I knew nothing about Java.  So they
grilled me for the next two hours on design patterns, thread safety
issues, etc., etc.  And after I got the job, one of the persons at the
interview explained to me that he had seen my postings in
comp.lang.c++.moderated, and that I wouldn't even have gotten to the
interview if they hadn't felt that the postings had displayed an
attitude which would make the transition to the type of Java they wanted
easy.  And of course, the main reason I took that job, instead of the
other offers I had at the time, was that they asked the right questions
at the interview, and showed that, as a company, they knew what they
were doing.

> Your r�sum� might show that you have learned and applied ten languages
> and ten development environments in twenty years, but if you aren't
> already experienced at _their_ current fad, you're out.

Well, you don't just learn good C++ like that.  On the other hand, it's
easy to have 10 years experience in C++, and still not know how to write
good code in the language.

> I saw one ad that _required_ "two years experience in C# or one year
> each at at least two jobs."  This was when C# was less than three
> years old!

I saw a demand for 10 years experience in Java in 1997.  I also had a
friend refused an interview because the client insisted on Unix, and all
he had was Sun OS.

Unless the market's really bad, I prefer to give those companies a skip
anyway.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4590 bytes --]

James Rogers <jimmaureenrogers@att.net> wrote in message
news:<Xns9396BDBB14558jimmaureenrogers@204.127.36.1>...
> kanze@gabi-soft.fr wrote in
> news:d6652001.0306100323.338a2a1c@posting.google.com:

>  > That doesn't mean C++ is perfect, of course.  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.

> Since this was cross-posted to comp.lang.ada I think it is fair to
> mention that there is a language that meets your description above.
> That language is Ada.

Permit me to be sceptical.  If your claim is that Ada has more of the
safe defaults than C++, I doubt anyone would dare argue it.  If your
claim is even that most of the defaults are the safe version, from what
little I know of the language, it would seem true.  But to say that in
1983, they got everything right, including problems that weren't even
understood until significantly later.  Well, I'm sceptical.  Perfection
just isn't of this world.

One point where I'm pretty sure Ada 83 didn't have the right default
(although they may have fixed it in Ada 95): garbage collection.  While
there are places where it is necessary to turn garbage collection off
(which seriously limits the use of a language in which you cannot have
untraced pointers, which the garbage collector cannot see), the safe
option is obviously to have it on by default, no?

> Its defaults are fundamentally safe. It provides the ability to
> override the safety constraints whenever you choose to. Note how Ada
> differs from Java. You cannot turn off array bounds checking for
> Java. In Ada you can. In fact, many Ada compilers will optimize out
> bounds checking when they can determine the checks are unnecessary.

I believe that this is standard practice in all languages which support
array bounds checking.

> In other words, you can arrive at the same level of safety which is
> the default for C++.

And you're bragging about it:-) ? 

Seriously, I am aware that 1) Ada generally adopts the safe option, and
2) you can generally "work around" the safety checks if necessary
(hopefully on a case by case basis, using source code constructs;
e.g. by writing array.unsafe_at( index ) rather than array[ index ]).
In my original statement, I'll admit that I wasn't thinking so much
about Ada, as about some other, more popular languages which claim a lot
of safety that they don't necessarily give.  Still, even thinking about
Ada, I don't think I'd change it.  As I say, I simply cannot believe
that the language is perfect.

> With Ada, however, you need to remove safety checks to get
> there. Manually removing safety checks is not usually needed for
> performance reasons.

Most of the time, when you want to remove safety checks, it is because
you are writing low level software.  On another level, I'm quite happy
that the operating systems I use don't normally allow me to write to raw
disk.  But if I'm writing a file system manager, I will need this
permission.  Similarly, address arithmetic is something to be avoided at
all costs.  Unless, of course, you are writing a garbage collector (or
in C++, an array class).

> Most programmers will use a language in the manner which requires
> minimum effort. This is why safety checks are not terribly common in
> C++. It is also why manually turning off safety checks is not terribly
> common in Ada.

I would certainly not claim that the defaults for C++ are safer than for
Java.  I've been using C++ now for close to fifteen years, and almost
exclusively for ten (except for a short excursion into Java).  Certain
avoidance manoevers have become instinctive, but I know that they are
missing in 99% of the code I see.  I suspect that I would need a lot
less avoidance manoeuvres in Ada -- perhaps none in day to day coding.
But I really doubt that there would never be a case where I couldn't do
better than the default.

--
James Kanze             GABI Software
mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter
Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45
16

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[kanze]

kcline17@hotmail.com (Kevin Cline) wrote in message
news:<ba162549.0306111431.366b59ba@posting.google.com>...
> 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.

So one less source of possible errors.

> 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,
> or writing your own and hoping that you don't somehow screw up
> new/unchecked deallocation.

I don't know.  I find using my propre collections far less error-prone
than the STL.  No iterators becoming invalid just because I happened to
insert an element, for example.

I use the STL because it is standard, not because it is a particularly
good generic library.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[Matthew Heaney]

kcline17@hotmail.com (Kevin Cline) wrote in message news:<ba162549.0306111431.366b59ba@posting.google.com>...
> 
> Sorry, Ada doesn't solve this problem.  Ada has no equivalent to the
> C++ STL.
> 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,
> or writing your own and hoping that you don't somehow screw up
> new/unchecked deallocation.

Yes, it's true that there is no standard container and algorithms
library a la the STL in Ada95.  However, the Charles library is more
or less a port of the STL to Ada95, so in practice you don't need to
resort to low-level arrays or linked lists.

I also think that Charles has "been debugged enough to be reliable,"
but ultimately it's up to the user to decide whether that's really the
case.

The Charles library is available at my webpage.

http://home.earthlink.net/~matthewjheaney/charles/

Matt

Re: C bug of the day

[Mike Silva]

Vinzent Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bc98sp$gaqa0$1@ID-175126.news.dfncis.de>...
> Kevin Cline 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.
> 
> In what respect? The primary question was about safety, not some kind
> of hyper-versatility. And the safety problem cannot be solved with C++
> and an STL.

Yes, it seems like the objection is that Ada doesn't "solve this
problem" because at some point a programmer will actually have to
write code, and that code may have bugs.  True, but nothing to do with
"all of the defaults were fundamentally safe."

Mike

Re: C bug of the day

[Robert I. Eachus]

Mike Silva wrote:

> Yes, it seems like the objection is that Ada doesn't "solve this
> problem" because at some point a programmer will actually have to
> write code, and that code may have bugs.  True, but nothing to do with
> "all of the defaults were fundamentally safe."

Sort of "agreeing violently" with Mike...

The goal in Ada is for as many bugs as possible to be caught by the 
compiler.  Is it possible for the compiler to catch all bugs?  Of course 
not.  But based on my experience at least, Ada does catch around 99% of 
all bugs by the time you have a clean compile.  That of course requires 
that when you see an "unexpected" compiler message, you think about what 
it means, rather than just papering it over.

For example, if GNAT tells me that no function Foo is directly visible, 
but there is one at Ada.Bar.Foo, there are two cases.  One is, "Of 
course I meant that one, just thought I had a use clause."  The other of 
course is that I was thinking of some other function entirely.  I would 
hate to have a compiler that "fixed" the reference.  At least 90% of the 
time it would be right, but the compiler has no way to know which 90% 
that is.

Re: C bug of the day

[Balog Pal]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9397C17B49692jimmaureenrogers@204.127.36.1...

> Interesting. Do you think the fundamental safety problem in C code
> is ininitialized integers?

Not "the" bat a very seriously fundamental problem I find in practice.

> What about memory leaks

Memleaks: I find not a problem in C++.  (it is in C)   [user shall not
handle memory in C++, containers and self-managing classes can solve
that
problem.]

> de-referencing
> null pointers, and array bounds violations?

null pointers: not really. Dangling pointers is a problem. But it is not
a
coding-level problem but more generic, object lifetime problem on the
design
level.

Array bounds: C, not C++. As normally in C++ we use containers, and
those do
bounts checks in debug build, that's enough to cath the typos/offby1
goofing. Generally.

Uninited variables are more than a nuisance, they pick up memory trash,
and
make the execution non-deterministic.   You can easily end up with all
your
tests passing, and still a broken problem that will hit you picking up
another memory pattern.

> The lint tool was able to identify uninitialized variables nearly
> thirty years ago. Of course, lint is not part of the C language,
> but it is one of those tools that has been used to try to improve
> the quality of C code for decades. With the common availability of
> lint for so many years, why is do uninitialized variables still
> occur in C?

My guess is "we're cool guys not using lint". ;-o
btw lint will pick every case of uninited variable I guess, how you tell
it
to pass those you actually want uninited?

> The reason is that many programmers neglect to use tools such as
> lint, which support my point. Programmers are frequently lazy.

Well, if it was part of the package -- I still don't know whether I used
it
or not. (More probably yes.)  with C++ it's quite a crude tool, isn't
it?

Can you tune it to pick up most real problems while not producing 10
times
more noise?

> A language that requires extra work to achieve safety will
> frequently be used to create unsafe programs. This is not
> because it is impossible to create safe programs with the language.
> It is because doing so requires extra work.

Sure, that's why the other poster claimed the uninitialised is a bad
default
behavior.

> On the other hand, a language that requires extra work to remove
> built in safety features will frequently be used to create safe
> programs. This is not because it is impossible to create unsafe
> programs with the language. It is because doing so requires extra
> work.

And that is not so symmetric unfortunately.  Most safety you must reach
at
the design level. The level of language features may be too far away
from
that to know what is safe, or what is reasonable.  [sometimes even
design
falls on face, like the syncronised stuff in the first java containers.]


Paul



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Pascal Obry]

Wesley Groleau <wesgroleau@despammed.com> writes:

> I had "Janus" on a Z80 in the late 1980s.
> Janus was a subset of Ada--I don't remember
> what was missing.

Almost everything! If my memory is right I have used a Janus Ada compiler back
in 1987. It was basically Pascal (no task, no generic, lot of bugs). It was
also impossible to build programs except very very small ones otherwise we had
a "not enough memory" error...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: C bug of the day

[Simon Wright]

kcline17@hotmail.com (Kevin Cline) writes:

> Sorry, Ada doesn't solve this problem.  Ada has no equivalent to the
> C++ STL.
> 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,
> or writing your own and hoping that you don't somehow screw up
> new/unchecked deallocation.

Well, the Ada 95 Booch Components (now GMGPL) are in use in real
projects right now. There are feature requests every so often, but not
that many bug reports. The main complaint is about the user
documentation (or lack of it, or unclarity ..).

Re: C bug of the day

[Matthew Heaney]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:<bc9k7c$b53$1@a1-hrz.uni-duisburg.de>...
> 
> 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.

The statement that "STL is only possible in C++" is false.  The
Charles library constitutes a proof-by-counterexample.

http://home.earthlink.net/~matthewjheaney/charles/


> Most of the components are licensed, not in the public domain,
> at least not in the US public domain, afaict.  

The components in the Charles library use the GMGPL.

Re: C bug of the day

[Larry Kilgallen]

In article <d6652001.0306120418.37a97d1c@posting.google.com>, kanze@gabi-soft.fr writes:
> James Rogers <jimmaureenrogers@att.net> wrote in message
> news:<Xns9396BDBB14558jimmaureenrogers@204.127.36.1>...

>> Since this was cross-posted to comp.lang.ada I think it is fair to
>> mention that there is a language that meets your description above.
>> That language is Ada.
> 
> Permit me to be sceptical.  If your claim is that Ada has more of the
> safe defaults than C++, I doubt anyone would dare argue it.  If your
> claim is even that most of the defaults are the safe version, from what
> little I know of the language, it would seem true.  But to say that in
> 1983, they got everything right, including problems that weren't even
> understood until significantly later.  Well, I'm sceptical.  Perfection
> just isn't of this world.
> 
> One point where I'm pretty sure Ada 83 didn't have the right default
> (although they may have fixed it in Ada 95): garbage collection.  While
> there are places where it is necessary to turn garbage collection off
> (which seriously limits the use of a language in which you cannot have
> untraced pointers, which the garbage collector cannot see), the safe
> option is obviously to have it on by default, no?

Perhaps it depends on what one means by the word "safe" :-),
but even with Ada 95 provision of any garbage collection is
up to the compiler vendor.  Since the language definition
does not mandate garbage collection, it cannot very well
mandate that it be defaulted on or defaulted off.

Does the C++ standard mandate garbage collection be on or off ?

> Seriously, I am aware that 1) Ada generally adopts the safe option, and
> 2) you can generally "work around" the safety checks if necessary
> (hopefully on a case by case basis, using source code constructs;
> e.g. by writing array.unsafe_at( index ) rather than array[ index ]).
> In my original statement, I'll admit that I wasn't thinking so much
> about Ada, as about some other, more popular languages which claim a lot
> of safety that they don't necessarily give.  Still, even thinking about
> Ada, I don't think I'd change it.  As I say, I simply cannot believe
> that the language is perfect.

I don't think anyone in comp.lang.ada believes Ada is perfect either.
The typical Ada expert believes in code review, formal inspection,
fault analysis, project specification and many other activities that
would be useless if there were a perfect programming language.

> I would certainly not claim that the defaults for C++ are safer than for
> Java.  I've been using C++ now for close to fifteen years, and almost
> exclusively for ten (except for a short excursion into Java).  Certain
> avoidance manoevers have become instinctive, but I know that they are
> missing in 99% of the code I see.  I suspect that I would need a lot
> less avoidance manoeuvres in Ada -- perhaps none in day to day coding.
> But I really doubt that there would never be a case where I couldn't do
> better than the default.

Sometimes "better" is subjective, but if a compiler can be told to
include or omit those checks it is easier to try it both ways to
see if omitting checks really has an effect on performance.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[James Rogers]

kanze@gabi-soft.fr wrote in
news:d6652001.0306120439.75bdfe78@posting.google.com: 

> James Rogers <jimmaureenrogers@att.net> wrote in message
> news:<Xns9397449823400jimmaureenrogers@204.127.36.1>...
>> kanze@gabi-soft.fr wrote in
>> news:d6652001.0306110131.6ac9e693@posting.google.com: 
> 
>> I do not think you will get any significant resistance to the idea
>> that Ada is imperfect. If you look through the current list of
>> threads in comp.lang.ada you will find a number of suggestions for
>> improving the language.
> 
> That's good news.  I know that when I was using Java, you could get
> seriously flames in comp.lang.java.programming just for suggesting
> that the language wasn't perfect.
> 
>> You will also probably see that few of these suggestions are focused
>> on improving fundamental Ada safety. Most are focused on ways to make
>> Ada more popular.
> 
> Obviously, you concentrate on the most important problems first:-).
> Good luck.  (I rather doubt that a language can be both safe and
> popular.  History, at any rate, is against you.)
> 

I agree about history.

>> I assert that it is impossible to develop a universally perfect
>> language.  Different problem domains require different language
>> strengths. I do not, for instance, believe a single language can
>> satisfy all the requirements of a scripting language while
>> simultaneously satisfying all the needs of an embedded language used
>> in SIL-4 level applications.
> 
> Exactly.  And in some cases, my opinion as to what the safe default is
> may not agree with yours.  If your argument is that it is
> significantly easier to write a robust application in Ada than in C++,
> all that I have been able to find out about the language without
> actually using it makes me think that you are right.  If you try to
> claim that it is impossible to write an incorrect program without
> overriding a default behavior, on the other hand...

Heavens no. Ada cannot determine if you are using the wrong
algorithm. It does, however, provide the syntax to allow you to
express your design very accurately and efficiently. This in
turn gives the compiler a better understanding of your design.
That understanding allows the compiler to flag problems only
revealed during debugging in C and C++.

The following is a simple example of extra design information in
a program:

with Ada.Text_IO;

procedure Simple_Example is
   type Days is (Monday, Tuesday, Wednesday, Thursday, Friday,
                 Saturday, Sunday);
   package Day_IO is new Ada.Text_IO.Enumeration_IO(Days);
   today : Days;
begin
   Ada.Text_IO.Put("Enter the name of the current day: ");
   Day_IO.Get(today);
   if today in Monday..Friday then
      Put_Line("Go to work.");
   else 
      Put_Line("Go Fishing.");
   end if;
end Simple_Example;

I instantiate the generic package Ada.Text_IO.Enumeration_IO
with the type Days. This creates an I/O package that allows
a user to type in any value in the Days type as input. That
value will be converted to the corresponding enumeration
value and assigned to the variable "today". I can then check
the value in the variable using a range notation.

Ada generics are similar to C++ templates.

Jim Rogers

Re: C bug of the day

[James Rogers]

kanze@gabi-soft.fr wrote in
news:d6652001.0306120623.151b7fa3@posting.google.com: 

> I don't know.  I find using my propre collections far less error-prone
> than the STL.  No iterators becoming invalid just because I happened
> to insert an element, for example.
> 
> I use the STL because it is standard, not because it is a particularly
> good generic library.
> 
>

Maybe it is a reflection of my age, but I do not find it terribly
difficult to create my own collections. This also lets me tune
performance for my current problem, instead of accepting a
somewhat average performance from a generic implementation.

Jim Rogers

Re: C bug of the day

[Mike Silva]

kanze@gabi-soft.fr wrote in message news:<d6652001.0306120418.37a97d1c@posting.google.com>...
 >
 > One point where I'm pretty sure Ada 83 didn't have the right default
 > (although they may have fixed it in Ada 95): garbage collection.  While
 > there are places where it is necessary to turn garbage collection off
 > (which seriously limits the use of a language in which you cannot have
 > untraced pointers, which the garbage collector cannot see), the safe
 > option is obviously to have it on by default, no?

I've read that Ada customers don't ask for garbage collection, because
in typical Ada applications (safety-critical, hard realtime embedded)
dynamic allocation is simply not acceptable.

Mike

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Wesley Groleau]

 >
 > One point where I'm pretty sure Ada 83 didn't have the right default
 > (although they may have fixed it in Ada 95): garbage collection.  While
 > there are places where it is necessary to turn garbage collection off
 > (which seriously limits the use of a language in which you cannot have
 > untraced pointers, which the garbage collector cannot see), the safe
 > option is obviously to have it on by default, no?

In Ada, GC is automatic for stack variables, but it
was intentionally left up to the vendor for access types
(which in Ada only exist when the programmer explicitly
declares them) because in some applications, it could
cause timing problems.  However, Ada 95 did add the ability
for the programmer to define whether GC occurs for any particular
data type, as well as to define how it occurs.

 > 2) you can generally "work around" the safety checks if necessary
 > (hopefully on a case by case basis, using source code constructs;
 > e.g. by writing array.unsafe_at( index ) rather than array[ index ]).

Actually, it's something like
pragma Suppress ( <type-of-check>, <entity> );


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[James Rogers]

"Andrei Alexandrescu" <SeeWebsiteForEmail@moderncppdesign.com> wrote in
news:bc9h7j$gm42t$1@ID-14036.news.dfncis.de:

 > I was mentioning that just to mention a simple language design decision
 > that's a no-brainer to implement, yet which imho has a great impact
 > because
 > of the psychological issue you mentioned. The others are also important,
 > but
 > not as trivial to implement and support without making performance
 > tradeoffs.

I am sorry. I misunderstood. I thought you were being sarcastic.
If your suggestion was adopted, how would it affect existing
programs? For that matter, why would you ever *want* uninitialized
variables? Another way to ask that is when is initialization a bad
thing?

Jim Rogers

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[James Rogers]

kanze@gabi-soft.fr wrote in
news:d6652001.0306120418.37a97d1c@posting.google.com:

 > James Rogers <jimmaureenrogers@att.net> wrote in message
 > news:<Xns9396BDBB14558jimmaureenrogers@204.127.36.1>...
 >> kanze@gabi-soft.fr wrote in
 >> news:d6652001.0306100323.338a2a1c@posting.google.com:
 >
 >>  > That doesn't mean C++ is perfect, of course.  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.
 >
 >> Since this was cross-posted to comp.lang.ada I think it is fair to
 >> mention that there is a language that meets your description above.
 >> That language is Ada.
 >
 > Permit me to be sceptical.  If your claim is that Ada has more of the
 > safe defaults than C++, I doubt anyone would dare argue it.  If your
 > claim is even that most of the defaults are the safe version, from what
 > little I know of the language, it would seem true.  But to say that in
 > 1983, they got everything right, including problems that weren't even
 > understood until significantly later.  Well, I'm sceptical.  Perfection
 > just isn't of this world.

I am sorry. I did not mean that Ada is perfect. I meant that Ada is a
fundamentally safe language with the ability to turn off checking if
you encounter a situation where checking presents a problem for you.

 >
 > One point where I'm pretty sure Ada 83 didn't have the right default
 > (although they may have fixed it in Ada 95): garbage collection.  While
 > there are places where it is necessary to turn garbage collection off
 > (which seriously limits the use of a language in which you cannot have
 > untraced pointers, which the garbage collector cannot see), the safe
 > option is obviously to have it on by default, no?

Is garbage collection always the right default? For web applications
this may be true. Ada was originally designed for hard real time
embedded systems. In 1983 and 1995 there was no way to implement
deterministic garbage collection for hard real time systems with
nanosecond timing requirements.

That said, like C++, Ada does not prohibit garbage collection.

 >
 >> Its defaults are fundamentally safe. It provides the ability to
 >> override the safety constraints whenever you choose to. Note how Ada
 >> differs from Java. You cannot turn off array bounds checking for
 >> Java. In Ada you can. In fact, many Ada compilers will optimize out
 >> bounds checking when they can determine the checks are unnecessary.
 >
 > I believe that this is standard practice in all languages which support
 > array bounds checking.
 >

This is standard practice in theory. For many languages the reality is
that such optimizations are rare because the compiler lacks the
information needed to prove the safety of removing the bounds checks.

 >> In other words, you can arrive at the same level of safety which is
 >> the default for C++.
 >
 > And you're bragging about it:-) ?

No, I am being practical. You can remove all safety checks in Ada and
produce a program as unsafe as anything you might write in C. On the
other hand, you can write a C++ program carefully and produce a very
safe result. Note that there is a lot of crossover in safety here.

 >
 > Seriously, I am aware that 1) Ada generally adopts the safe option, and
 > 2) you can generally "work around" the safety checks if necessary
 > (hopefully on a case by case basis, using source code constructs;
 > e.g. by writing array.unsafe_at( index ) rather than array[ index ]).
 > In my original statement, I'll admit that I wasn't thinking so much
 > about Ada, as about some other, more popular languages which claim a lot
 > of safety that they don't necessarily give.  Still, even thinking about
 > Ada, I don't think I'd change it.  As I say, I simply cannot believe
 > that the language is perfect.

And your are correct. The language is not perfect.

 >
 >> With Ada, however, you need to remove safety checks to get
 >> there. Manually removing safety checks is not usually needed for
 >> performance reasons.
 >
 > Most of the time, when you want to remove safety checks, it is because
 > you are writing low level software.  On another level, I'm quite happy
 > that the operating systems I use don't normally allow me to write to raw
 > disk.  But if I'm writing a file system manager, I will need this
 > permission.  Similarly, address arithmetic is something to be avoided at
 > all costs.  Unless, of course, you are writing a garbage collector (or
 > in C++, an array class).

If you want to get really low level in Ada you can directly call assembler
routines, just as in C or C++. This has the same problems and benefits as
in C or C++.

 >
 >> Most programmers will use a language in the manner which requires
 >> minimum effort. This is why safety checks are not terribly common in
 >> C++. It is also why manually turning off safety checks is not terribly
 >> common in Ada.
 >
 > I would certainly not claim that the defaults for C++ are safer than for
 > Java.  I've been using C++ now for close to fifteen years, and almost
 > exclusively for ten (except for a short excursion into Java).  Certain
 > avoidance manoevers have become instinctive, but I know that they are
 > missing in 99% of the code I see.  I suspect that I would need a lot
 > less avoidance manoeuvres in Ada -- perhaps none in day to day coding.
 > But I really doubt that there would never be a case where I couldn't do
 > better than the default.

You can add additional checks if you wish in your own code. Ada does
not prevent you from doing what you need to do. If, for instance,
you wanted to create a type representing all the odd numbers from
1 through 101 you would need to create the equivalent of a C++ class.
You would also need to define your own arithmetic operators for
such a type. Ada's built in safety features would be of only limited
help for such a type.

Compare this with defining a numeric type with all integers from
1 through 101:

type My_Ints is range 1..101;

In this case Ada automatically provides all the checking and
numeric operators for you.

Jim Rogers

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[James Rogers]

"Balog Pal" <pasa@lib.hu> wrote in news:3ee8901a@andromeda.datanet.hu:

 > "James Rogers" <jimmaureenrogers@att.net> wrote in message
 > news:Xns9397C17B49692jimmaureenrogers@204.127.36.1...
 >
 >> Interesting. Do you think the fundamental safety problem in C code
 >> is ininitialized integers?
 >
 > Not "the" bat a very seriously fundamental problem I find in practice.
 >
 >> What about memory leaks
 >
 > Memleaks: I find not a problem in C++.  (it is in C)   [user shall not
 > handle memory in C++, containers and self-managing classes can solve
 > that
 > problem.]

Do you ever deal with C++ code written using C style primitives such
as arrays? I understand that such code still exists.

 >
 >> de-referencing
 >> null pointers, and array bounds violations?
 >
 > null pointers: not really. Dangling pointers is a problem. But it is not
 > a
 > coding-level problem but more generic, object lifetime problem on the
 > design
 > level.

I agree that pointer lifetime issues are a design issue. One of the
sometimes more difficult rules in Ada deals with pointer lifetime
issues. (In Ada they are called access variables, but the lifetime
issue applies here.) The language has very strict rules about access
value lifetimes. The compilers enforce those rules. The result is
a very low occurrance of dangling pointers.

 >
 > Array bounds: C, not C++. As normally in C++ we use containers, and
 > those do
 > bounts checks in debug build, that's enough to cath the typos/offby1
 > goofing. Generally.

Again, what about C++ code written using C style primitives such as
strings and other forms of arrays?

What C++ allows, and provides for "free" with the STL, is the
ability to wrap the C style primitives such as arrays in a class,
with all the bounds checking built into the class.

This provides safety at the expense of some efficiency. Although
the STL is part of the language definition, it is not part of the
language syntax. A C++ compiler cannot optimize out bounds checks
from STL or other container classes.

 > My guess is "we're cool guys not using lint". ;-o
 > btw lint will pick every case of uninited variable I guess, how you tell
 > it
 > to pass those you actually want uninited?
 >
 >> The reason is that many programmers neglect to use tools such as
 >> lint, which support my point. Programmers are frequently lazy.
 >
 > Well, if it was part of the package -- I still don't know whether I used
 > it
 > or not. (More probably yes.)  with C++ it's quite a crude tool, isn't
 > it?

Do modern C++ compilers produce the level of diagnostic output available
from (or better than) lint?

 >
 > Can you tune it to pick up most real problems while not producing 10
 > times
 > more noise?

This has always been an issue with lint. Tuning the output to give
no false reports while still not missing any real problems is not
easy.
 >
 >> A language that requires extra work to achieve safety will
 >> frequently be used to create unsafe programs. This is not
 >> because it is impossible to create safe programs with the language.
 >> It is because doing so requires extra work.
 >
 > Sure, that's why the other poster claimed the uninitialised is a bad
 > default
 > behavior.

I agree it is bad. I just did not think it was the most often encountered
problem.

Ada goes a bit further in this area than most C++ programs.
Ada allows you to define your own numeric types (as primitives, not
classes). You are allowed to define several characteristics about
these types.

type My_Index is range 1..10;

The above line defines an integer type with a valid range of values
from 1 through 10 inclusive. Now, let's combine that definition with
an array type definition:

type Nums is array (My_Index) of Float;

This defines an array type indexed by the type My_Index. Each element
of the array is a Float.

The compiler can now optimize out bounds checking for accessing
an array of Nums. The only index type allowed is type My_Index.
Every possible value of that type maps to an array element.

Trying to assign an out of range value to a variable of My_Index
causes the program to raise the exception Constraint_Error at run time.

Note that it would be illegal to initialize a variable of My_Index to
0. 0 is not a valid value for My_Index. The Ada compiler detects the
use of uninitialized variables.

 >
 >> On the other hand, a language that requires extra work to remove
 >> built in safety features will frequently be used to create safe
 >> programs. This is not because it is impossible to create unsafe
 >> programs with the language. It is because doing so requires extra
 >> work.
 >
 > And that is not so symmetric unfortunately.  Most safety you must reach
 > at
 > the design level. The level of language features may be too far away
 > from
 > that to know what is safe, or what is reasonable.  [sometimes even
 > design
 > falls on face, like the syncronised stuff in the first java containers.]

In Ada, I would simply use a container type as a data member in a
protected type definition. This allows me to have all the synchronization
behavior I need without suffering performance hits for the container
itself.

One common Ada container type is an unbounded string. It behaves
something like a Java String type. If I want to share that string
between several Ada tasks (similar to Java threads) I do the following:

protected type String_Buf is
    procedure Write(Item : in String);
    function Read return String;
private
    Buf : Unbounded_String;
end String_Buf;

The above code defines the interface, and private data member, for a
String_Buf. An Ada protected type is protected from inappropriate
mutual access by tasks. In this case any task calling the Write
procedure has exclusive access to the instance of String_Buf, while
any task calling the Read function has shared access to the instance
of String_Buf. This allows simultaneous reads and exclusive writes.

Note that this access control is far more sophisticated than what is
provided by Java synchronization.

The actual implementation of the String_Buf type follows:

protected body String_Buf is
    procedure Write(Item : in String) is
    begin
       Buf := To_Unbounded_String(Item);
    end Write;
    function Read return String is
    begin
       return To_String(Buf);
    end Read;
end String_Buf;

All locking and unlocking is implicit.
Each assignment to Buf causes the contents of Buf to be adjusted to
exactly the number of characters required. Dynamic memory issues are
handled automatically, just as in C++ with proper constructors and
destructors.

Jim Rogers

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[AG]

<kanze@gabi-soft.fr> wrote in message
news:d6652001.0306120439.75bdfe78@posting.google.com...

> Obviously, you concentrate on the most important problems first:-).
> Good luck.  (I rather doubt that a language can be both safe and
> popular.  History, at any rate, is against you.)

Mind if I try to take it on a bit of a tangent?

Why do you think the things like TDD and
unit-testing are getting so much attention
lately? Could it (possibly) be that they
just try to fill-in the role that a safe
language would do as a matter of course?

Sort of trying to compensate for
deficiencies of a language with some
home-grown solutions?

Re: C bug of the day

[Peter Amey]

AG wrote:
> <kanze@gabi-soft.fr> wrote in message
> news:d6652001.0306120439.75bdfe78@posting.google.com...
> 
> 
>>Obviously, you concentrate on the most important problems first:-).
>>Good luck.  (I rather doubt that a language can be both safe and
>>popular.  History, at any rate, is against you.)
> 
> 
> Mind if I try to take it on a bit of a tangent?
> 
> Why do you think the things like TDD and
> unit-testing are getting so much attention
> lately? Could it (possibly) be that they
> just try to fill-in the role that a safe
> language would do as a matter of course?
> 
> Sort of trying to compensate for
> deficiencies of a language with some
> home-grown solutions?
> 

That certainly fits with our experience using SPARK (SPARK takes the 
principle of early error detection even further than Ada).  On SPARK 
projects we have found unit test to be of little or no value since the 
kinds of errors it typically find do not typically occur in SPARK 
programs.  Requirements-based testing of the complete system is a 
different story; that is always worthwhile.

See "Is Proof More Cost-effective than Testing" on www.sparkada.com for 
some background on this.

Peter

Re: C bug of the day

[Ed Falis]

On Fri, 13 Jun 2003 21:37:38 +1200
"AG" <ang@xtra.co.nz> wrote:
 Could it (possibly) be that they
> just try to fill-in the role that a safe
> language would do as a matter of course?
> 
> Sort of trying to compensate for
> deficiencies of a language with some
> home-grown solutions?
> 
> 

I don't think so.  I use Ada, together with assertions (approxamating
DBC) and unit tests (AUnit) together.  Each has its own strengths, and
they complement each other.

- Ed

Re: C bug of the day

[kanze]

"AG" <ang@xtra.co.nz> wrote in message
news:<NWgGa.25387$JA5.474581@news.xtra.co.nz>...
> <kanze@gabi-soft.fr> wrote in message
> news:d6652001.0306120439.75bdfe78@posting.google.com...

> > Obviously, you concentrate on the most important problems first:-).
> > Good luck.  (I rather doubt that a language can be both safe and
> > popular.  History, at any rate, is against you.)

> Mind if I try to take it on a bit of a tangent?

> Why do you think the things like TDD and unit-testing are getting so
> much attention lately?  Could it (possibly) be that they just try to
> fill-in the role that a safe language would do as a matter of course?

I'm not sure that they are getting as much attention as they need, even
now.  And even with Ada, I'm sure that I'd insist on unit tests.

> Sort of trying to compensate for deficiencies of a language with some
> home-grown solutions?

I don't think so.  Unit tests are essential, regardless of the
language.  Some errors simply cannot be caught until run-time.

Of course, if a shop is well run, the unit tests will run clean first
time.  But they remain necessary to keep the programmers honest.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[kanze]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:<3EE8CE83.8090001@attbi.com>...
> Mike Silva wrote:

> > Yes, it seems like the objection is that Ada doesn't "solve this
> > problem" because at some point a programmer will actually have to
> > write code, and that code may have bugs. True, but nothing to do
> > with "all of the defaults were fundamentally safe."

> Sort of "agreeing violently" with Mike...

> The goal in Ada is for as many bugs as possible to be caught by the
> compiler.  Is it possible for the compiler to catch all bugs?  Of
> course not.  But based on my experience at least, Ada does catch
> around 99% of all bugs by the time you have a clean compile.  That of
> course requires that when you see an "unexpected" compiler message,
> you think about what it means, rather than just papering it over.

Up until there, I could say the same thing about C++.  But that's
because I know what to avoid, and pay very careful attention.

In most languages, if you are programming carefully, most errors will be
typing errors.  In this regard, of course, C++'s use of a lot of
symbolic operators doesn't help; a one character error is likely to
result in a different legal operator.  But most of the time, it will be
an inversion of characters in a name, or something like that.  And C++
also complains if you use an undefined symbol.

I think the real argument is more along the lines of how difficult is it
to program carefully.

I think another real argument (which hasn't been mentionned) is how
transparent the working code is.

> For example, if GNAT tells me that no function Foo is directly
> visible, but there is one at Ada.Bar.Foo, there are two cases.  One
> is, "Of course I meant that one, just thought I had a use clause."
> The other of course is that I was thinking of some other function
> entirely.  I would hate to have a compiler that "fixed" the reference.
> At least 90% of the time it would be right, but the compiler has no
> way to know which 90% that is.

I don't know of any compiler which does that, in any language.  Today,
because I seem to recall having seen some 20 or 30 years ago.  When you
turn your punched cards in in the evening, to get the results back the
next morning, you might appreciate such a feature, provided the compiler
did say what it did.  In today's environments, of course, where you
never actually invoke the compiler, but some sort of advanced (or not so
advanced) build system, it would be a disaster.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[kanze]

mheaney@on2.com (Matthew Heaney) wrote in message
news:<1ec946d1.0306121358.3e97731e@posting.google.com>...
> Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote in message
> news:<bc9k7c$b53$1@a1-hrz.uni-duisburg.de>...

> > 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.

> The statement that "STL is only possible in C++" is false.  The
> Charles library constitutes a proof-by-counterexample.

> http://home.earthlink.net/~matthewjheaney/charles/

I'm not familiar enough to be sure, but from what I know, certain
aspects of the STL *are* impossible in Ada.  I rather think that this is
a feature of Ada, however, and not a problem.  Can you get undefined
behavior from an iterator because somewhere else in the code, someone
has inserted an element into the underlying container?

In this sense, I suspect that the STL is only possible in C++.

Someone else mentionned the Booch components.  I used these in C++, and
they were far superior to the STL (in C++, anyway).  If they are still
available for Ada, this would be an argument in favor of Ada, I would
think.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[Vinzent Hoefler]

kanze@gabi-soft.fr wrote:

>"Robert I. Eachus" <rieachus@attbi.com> wrote in message
>news:<3EE8CE83.8090001@attbi.com>...
>
>> For example, if GNAT tells me that no function Foo is directly
>> visible, but there is one at Ada.Bar.Foo, there are two cases.  One
>> is, "Of course I meant that one, just thought I had a use clause."
>> The other of course is that I was thinking of some other function
>> entirely.  I would hate to have a compiler that "fixed" the reference.
>> At least 90% of the time it would be right, but the compiler has no
>> way to know which 90% that is.
>
>I don't know of any compiler which does that, in any language.

Well, at least the older C-versions sort of did that (C99 now requires
proper prototypes, IIRC, so this sort of error is more unlikely now).

But writing

|printf (4711);

was perfectly legal and the linker didn't complain, because a symbol
with the appropriate name was defined. Well, running the executable
than would have had possibly quite desastrous results.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[kanze]

James Rogers <jimmaureenrogers@att.net> wrote in message
news:<Xns9398C982B7580jimmaureenrogers@204.127.36.1>...
> kanze@gabi-soft.fr wrote in
> news:d6652001.0306120623.151b7fa3@posting.google.com: 

> > I don't know.  I find using my propre collections far less
> > error-prone than the STL.  No iterators becoming invalid just
> > because I happened to insert an element, for example.

> > I use the STL because it is standard, not because it is a
> > particularly good generic library.

> Maybe it is a reflection of my age, but I do not find it terribly
> difficult to create my own collections.

I agree to a point.  Before I started using C++, I regularly used hash
tables in C.  Which I rewrote each time around -- if genericity isn't a
goal, and you only have to solve the problem at hand, a hash table is
only about ten or twenty lines of code.

Never the less, I use standard components whenever possible.  Not for my
own sake -- I think I could design and write something better for my
needs than the standard library.  But for the sake of the programmer
coming after me, who knows, or should know, the standard library, but
certainly isn't familiar with my personal components.

Note that while we have been speaking here about safety, no one has
mentionned readability.  And IMHO, this is the most important single
feature of safety: a well run code review will catch many more errors
than the best compiler, but for a code review to be effective, the
readers have to be able to understand what you have written.

Not that I'd try and present this as an argument for C++:-).

> This also lets me tune performance for my current problem, instead of
> accepting a somewhat average performance from a generic
> implementation.

Most of the time, I really don't care.  I want something that gets the
job done, is correct, and is readable.  And no ordering is implied --
all three are absolutly essential.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

Re: C bug of the day

[Vinzent Hoefler]

kanze@gabi-soft.fr wrote:

>Note that while we have been speaking here about safety, no one has
>mentionned readability.

Probably because this is what Ada is so well known for, that nobody in
c.l.a. doesn't think about it anymore... ;)

>  And IMHO, this is the most important single
>feature of safety: a well run code review will catch many more errors
>than the best compiler, but for a code review to be effective, the
>readers have to be able to understand what you have written.

I fully agree with that. And IMO Ada makes writing readable programs
very easy. 

>Not that I'd try and present this as an argument for C++:-).

Beware of the flame wars... :)

As you already mentioned, no language is perfect, so in that respect
it is surely possible to write unreadable code in Ada, but this is at
least much harder to achieve than in C++.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[Terje Slettebø]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9398BD1E07E3Ejimmaureenrogers@204.127.36.1...
> "Andrei Alexandrescu" <SeeWebsiteForEmail@moderncppdesign.com> wrote
in
> news:bc9h7j$gm42t$1@ID-14036.news.dfncis.de:
>
>  > I was mentioning that just to mention a simple language design
decision
>  > that's a no-brainer to implement, yet which imho has a great impact
>  > because
>  > of the psychological issue you mentioned. The others are also
important,
>  > but
>  > not as trivial to implement and support without making performance
>  > tradeoffs.
>
> I am sorry. I misunderstood. I thought you were being sarcastic.
> If your suggestion was adopted, how would it affect existing
> programs? For that matter, why would you ever *want* uninitialized
> variables?

Reading from streams is an obvious example:

int i;

stream >> i;

Intialising "i" beforehand would just be vasteful.


Regards,

Terje

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Wesley Groleau]

> I don't think so.  Unit tests are essential, regardless of the
> language.  Some errors simply cannot be caught until run-time.
> 
> Of course, if a shop is well run, the unit tests will run clean first
> time.  But they remain necessary to keep the programmers honest.

I was once required to use a tool that parsed the
source code and generated unit tests for you.

The only problem (which I could not persuade management
of) was that it did not truly test our code.  The tests
NEVER failed unless there was a compiler bug, because
all the tool did was determine what the code ought to do
and test for that.

Re: C bug of the day

[Terje Slettebø]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9398C378C97C4jimmaureenrogers@204.127.36.1...
> "Balog Pal" <pasa@lib.hu> wrote in news:3ee8901a@andromeda.datanet.hu:
>
>  > "James Rogers" <jimmaureenrogers@att.net> wrote in message
>  > news:Xns9397C17B49692jimmaureenrogers@204.127.36.1...
>  >
> What C++ allows, and provides for "free" with the STL, is the
> ability to wrap the C style primitives such as arrays in a class,
> with all the bounds checking built into the class.

There's no mandated bounds checking in the standard library (except
where explicitly noted such as std::string's at() function), but an
implementation might provide it, anyway, especially in debug builds.

> This provides safety at the expense of some efficiency. Although
> the STL is part of the language definition, it is not part of the
> language syntax. A C++ compiler cannot optimize out bounds checks
> from STL or other container classes.

It might, if it's able to see that the values are always within the
bounds.

> Ada goes a bit further in this area than most C++ programs.
> Ada allows you to define your own numeric types (as primitives, not
> classes). You are allowed to define several characteristics about
> these types.
>
> type My_Index is range 1..10;
>
> The above line defines an integer type with a valid range of values
> from 1 through 10 inclusive. Now, let's combine that definition with
> an array type definition:
>
> type Nums is array (My_Index) of Float;
>
> This defines an array type indexed by the type My_Index. Each element
> of the array is a Float.
>
> The compiler can now optimize out bounds checking for accessing
> an array of Nums. The only index type allowed is type My_Index.
> Every possible value of that type maps to an array element.

You could also do this in C++, by creating such range types.

In Ada, like in C++, there would likely be bounds checking at a
different place, instead, though: in the range class, itself, ensuring
that operations on it doesn't result in values outside the range. So you
haven't really removed the range checking, just moved it. The array
doesn't need to check, but the range class does.

> Trying to assign an out of range value to a variable of My_Index
> causes the program to raise the exception Constraint_Error at run
time.
>
> Note that it would be illegal to initialize a variable of My_Index to
> 0. 0 is not a valid value for My_Index.

This is what I meant.


Regards,

Terje

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Hyman Rosen]

James Rogers wrote:
 > Another way to ask that is when is initialization a bad thing?

The most common case is when you have large arrays
which are eventually going to be full of data which
requires a bunch of computation to derive. There's
no point, and possibly significant delay, in filling
them with initial values, say zeroes.

In the past, I've also posted a data structure which
requires accessing uninitialized data in order to
fulfill its time complexity requirements, and yet
works (as long as an uninitialized variable can be
assumed to hold a definite but unspecified value.
That's not true for Standard C++, but many compilers
will act that way.) It's a pair of arrays of unsigned
integers and a counter for which we want to check if
'd[s[i]] == i' for 's[i] < n'. We can leave 's' to be
uninitialized and only set those values we need (i.e.,
for "interesting" values of 'i').


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[LLeweLLyn]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <d6652001.0306120418.37a97d1c@posting.google.com>,
>kanze@gabi-soft.fr writes: 
>> James Rogers <jimmaureenrogers@att.net> wrote in message
>> news:<Xns9396BDBB14558jimmaureenrogers@204.127.36.1>...
>
>>> Since this was cross-posted to comp.lang.ada I think it is fair to
>>> mention that there is a language that meets your description above.
>>> That language is Ada.
>> 
>> Permit me to be sceptical.  If your claim is that Ada has more of the
>> safe defaults than C++, I doubt anyone would dare argue it.  If your
>> claim is even that most of the defaults are the safe version, from
what
>> little I know of the language, it would seem true.  But to say that
in
>> 1983, they got everything right, including problems that weren't even
>> understood until significantly later.  Well, I'm sceptical.
Perfection
>> just isn't of this world.
>> 
>> One point where I'm pretty sure Ada 83 didn't have the right default
>> (although they may have fixed it in Ada 95): garbage collection.
While
>> there are places where it is necessary to turn garbage collection off
>> (which seriously limits the use of a language in which you cannot
have
>> untraced pointers, which the garbage collector cannot see), the safe
>> option is obviously to have it on by default, no?

What kinds of programs are most commonly written in Ada?

For some kinds of programs, traditional gc algorithms do not work
    well, or are completely unacceptable. If Ada is frequently used in
    real-time systems (that is my impression), off might be a better
    default.

Of course for C++, on would be the best default - but plenty of
    programs would need to replace the garbage collector, 
    plenty would need to turn it off, and some would need different
    solutions for different components of the same program.

>
> Perhaps it depends on what one means by the word "safe" :-),
> but even with Ada 95 provision of any garbage collection is
> up to the compiler vendor.  Since the language definition
> does not mandate garbage collection, it cannot very well
> mandate that it be defaulted on or defaulted off.

But quick search of rm95 turns up what looks to be a way to prevent
    objects accessed by specific access types from being garbage
    collected. (http://www.adapower.com/rm95/arm95_210.html#SEC210)
    This description seems to imply that if an implementation provides
    garbage collection it is on by default. I've never written a
    non-toy Ada program, so maybe I misunderstand, but that's more
    than C++ provides. 

Another bit - it seems Ada allows creation of variable-sized objects
    on the stack. I suspect that use of dynamic memory in C++ could be
    significantly reduced in most programs, by aggressive use 
    of such a feature (which C++ doesn't have - alloca isn't part of the
    standard, and a safe constructing and destructing wrapper around it
    is harder than it first appears). (Variable-sized stack objects
    probably couldn't eliminate the need for dynamic memory in most
    programs because all too often the function that knows what type
    an object should be is called from the function that (via virtual
    functions) manipulates the object. )

In some sense one could argue that both languages chose a safe
    allocation default: by default, objects are stack allocated, and
    have scope-controlled lifetimes. It takes explicit work to create 
    dynamicly allocated objects. Trouble is C++ has an education
    problem here - too many C++ programmers are (wrongly) taught to
    allocate dynamicly every time they want an object for any
    purpose! Right defaults are important, but IMO in several cases
    poor C++ education has taught many programmers to do the wrong
    thing even where the default is right. (Fortunately this problem
    appears to be in the process of being solved; I don't see as much
    unsafe C++ code as I once did.) 

> Does the C++ standard mandate garbage collection be on or off ?

Niether. The C++ standard says nothing whatsoever about garbage
    collection. It doesn't even require an implementation to document
    whether garbage collection is availible, on, off, etc. In
    practice, few C++ implementations provide garbage collection
    - but garbage collectors that work well with many implementations
    can be found
    (e.g. http://www.hpl.hp.com/personal/Hans_Boehm/gc/). And an
    implementation providing garbage collection but not documenting it
    seems almost unimaginable.

>
>> Seriously, I am aware that 1) Ada generally adopts the safe option,
and
>> 2) you can generally "work around" the safety checks if necessary
>> (hopefully on a case by case basis, using source code constructs;
>> e.g. by writing array.unsafe_at( index ) rather than array[ index ]).
>> In my original statement, I'll admit that I wasn't thinking so much
>> about Ada, as about some other, more popular languages which claim a
lot
>> of safety that they don't necessarily give.  Still, even thinking
about
>> Ada, I don't think I'd change it.  As I say, I simply cannot believe
>> that the language is perfect.
>
> I don't think anyone in comp.lang.ada believes Ada is perfect either.
> The typical Ada expert believes in code review, formal inspection,
> fault analysis, project specification and many other activities that
> would be useless if there were a perfect programming language.

Perhaps this is more important than the safety of the language
    defaults; IMO the biggest safety problem for most C++ progammers
    is that too many shops do no code review, formal inspection, etc,
    and in many shops that do, so many progammers have so little
    experience reviewing code, have so many misunderstandings, and
    must deal with such rotten code, that code review is less helpful
    (in the short term) than it might be.
    
>
>> I would certainly not claim that the defaults for C++ are safer than
for
>> Java.

The problem with Java is that all too often, it does not provide one
    with any choice - garbage collection is not the default - it is
    the only choice, and no matter how much it interferes with (for
    example) the real-time needs of one's program, there is no
    escape. Reference types are not the default - they are the only
    choice. Java does not support user-defined value types. Most of
    the laws laid down by the Java language designers work well, most
    of the time. But if one must write an application for which they
    do not work well, one is in a surprisingly hard spot, for the
    language provides no escape (except to write native functions in C
    or assembler :-).

In this respect Java is unlike C++, which all too often has the unsafe
    default, but allows one to change about that default, and also
    unlike Ada, which usually has the safe default, but also allows
    one to change it.

>> I've been using C++ now for close to fifteen years, and almost
>> exclusively for ten (except for a short excursion into Java).
Certain
>> avoidance manoevers have become instinctive, but I know that they are
>> missing in 99% of the code I see.  I suspect that I would need a lot
>> less avoidance manoeuvres in Ada -- perhaps none in day to day
coding.
>> But I really doubt that there would never be a case where I couldn't
do
>> better than the default.
>
> Sometimes "better" is subjective, but if a compiler can be told to
> include or omit those checks it is easier to try it both ways to
> see if omitting checks really has an effect on performance.
[snip]

Certainly. And since many programs need checks, performance is not
    crucial for most programs, and performance can often be improved
    in other ways, I often wish C++ had checks enabled by default, and
    one had to do work to disable them - but no, all too often one
    must write, download, or find in the standard library some
    user-defined type that does checking, and enable checks on a case
    by case basis, or, enable the debug mode in some implementations
    of the standard library.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[AG]

<kanze@gabi-soft.fr> wrote in message
news:d6652001.0306130643.1e320398@posting.google.com...

> > Sort of trying to compensate for deficiencies of a language with some
> > home-grown solutions?
>
> I don't think so.  Unit tests are essential, regardless of the
> language.  Some errors simply cannot be caught until run-time.

That's right but what I meant was that all too often
unit tests are used to catch the things that can and
should be caught at compile time. This means two
things:

1. Weakened checking compared to what
compiler could do.
2. A huge number of trivial unit tests which
hide and obfuscate the really inresting ones
making them harder to find or even to invent.

As an example, lets consider a case of
a language which doesn't have the "out"
parameter mode in it's method/procedure
calls. Everything is passed, in effect, as
"in out". So, we have something declared
as:  X(a, b: booleanResults; x: inputData).

Turns out that internally (due to a bug)
the X depends on initial input values of
a & b. Once that's discovered, it needs
four additional unit tests per input data
to test that the bug was fixed and all
input combinations of a & b work.

Now, if the language had "out" parameter
mode it could be used in that case and
make those tests totally irrelevant - leaving
more chance for a really interesting ones.

Re: C bug of the day

[Randy Brukardt]

Vinzent Hoefler wrote in message ...
Erlo Haugen wrote:
>>As for other 8 bits, Z80 and the like would be good candidates.

>At least for 6502 and Z80 exist C-compilers, so I don't see why there
>shouldn't be any Ada-Compiler. I even remember playing around with
>Pascal and FORTH on a Z80 machine (around 1986).

The original versions of Janus/Ada were for CP/M on 8080/Z80 machines.
Certainly, in 1986 you could have purchased Janus/Ada from us. And we
had several competitors on that platform.

It would be relatively easy to create a cross-compiler to the Z80; we
still have the majority of the source for it. Of course, it would be a
significant job to bring it up to the current state of our compiler --
it's been more than 15 years since any development took place on that
compiler. But we haven't had a customer who was interested enough to
partially fund it.

          Randy.

Re: C bug of the day

[Randy Brukardt]

Pascal Obry wrote in message ...
>
>Wesley Groleau <wesgroleau@despammed.com> writes:
>
>> I had "Janus" on a Z80 in the late 1980s.
>> Janus was a subset of Ada--I don't remember
>> what was missing.
>
>Almost everything! If my memory is right I have used a Janus Ada
compiler back
>in 1987. It was basically Pascal (no task, no generic, lot of bugs). It
was
>also impossible to build programs except very very small ones otherwise
we had
>a "not enough memory" error...


Right. It's very hard to build a useful compiler that fit in 56K of RAM
(which is what was available on CP/M). But the Z-80 was a lot more
memory efficient than the 8088 was, so it could compiler bigger programs
than the early PC's could (with 128K of RAM).

Even the MS-DOS version (full Ada 83) has quite limited compilation
sizes because of 640K doesn't go that far. (Text_IO uses about 65% of
the available memory.)

Cross-compiling from Windows or a Unix never had that problem, of
course. It's unfortunate that so many people found the limitations of
the platform to somehow be a limitation of the technology/vendor.

                 Randy Brukardt

Re: C bug of the day

[Wesley Groleau]

> The problem with Java is ....
>     .. [and] Reference types are not the default - they are the only

Well, there's also primitives.  Contrary to an oft-repeated
falsehood, Java is NOT "pure O.O."  As a beginner, I find it
irritating at best to have to maintain two different paradigms
for handling entities, and to have to keep track of which group
every object fits into.  At least in Ada, it's only a reference
type if I _need_ it to be and declare it that way.

Re: C bug of the day

[Simon Wright]

kanze@gabi-soft.fr writes:

> I'm not familiar enough to be sure, but from what I know, certain
> aspects of the STL *are* impossible in Ada.  I rather think that
> this is a feature of Ada, however, and not a problem.  Can you get
> undefined behavior from an iterator because somewhere else in the
> code, someone has inserted an element into the underlying container?
> 
> In this sense, I suspect that the STL is only possible in C++.

I think it would be very easy to get undefined behaviour in these
circomstances, whatever the implementation language! (I think you
possibly mean "erratic" rather than "undefined", it would be possible
to have stable, desirable behaviour and just not define it!)

> Someone else mentionned the Booch components.  I used these in C++,
> and they were far superior to the STL (in C++, anyway).  If they are
> still available for Ada, this would be an argument in favor of Ada,
> I would think.

Even I wouldn't have gone as far as that! but see
http://www.pushface.org/components/bc/

Re: C bug of the day

[Simon Wright]

kanze@gabi-soft.fr writes:

> Note that while we have been speaking here about safety, no one has
> mentionned readability.  And IMHO, this is the most important single
> feature of safety: a well run code review will catch many more
> errors than the best compiler, but for a code review to be
> effective, the readers have to be able to understand what you have
> written.

Different kinds of errors, I'd think. I would prefer not to review code
until it compiles cleanly (I know there are other approaches).

Re: C bug of the day

[kanze]

James Rogers <jimmaureenrogers@att.net> wrote in message
news:<Xns9398BD1E07E3Ejimmaureenrogers@204.127.36.1>...
 > "Andrei Alexandrescu" <SeeWebsiteForEmail@moderncppdesign.com> wrote
 > in news:bc9h7j$gm42t$1@ID-14036.news.dfncis.de:

 >  > I was mentioning that just to mention a simple language design
 >  > decision that's a no-brainer to implement, yet which imho has a
 >  > great impact because of the psychological issue you mentioned. The
 >  > others are also important, but not as trivial to implement and
 >  > support without making performance tradeoffs.

 > I am sorry. I misunderstood. I thought you were being sarcastic.  If
 > your suggestion was adopted, how would it affect existing programs?
 > For that matter, why would you ever *want* uninitialized variables?
 > Another way to ask that is when is initialization a bad thing?

For the same reason you might want to access an array without a bounds
check, I guess: performance.  If you know that the initialization will
take place before the variable is used, and you have a performance
problem, initialization is a loss of time.

I imagine that such cases would be rare.  But then, I imagine that they
would be exceedingly rare for bounds checking, too.

FWIW: I've seen numeric benchmarks where Java (with bounds checking)
runs faster than C++ (without).  The reason is simple: the Java compiler
is able to hoist the bounds checking out of the tight loops, or even
eliminate it entirely.  And it doesn't have to deal with all of the
aliasing issues due to the language supporting pointer arithmetic.  It's
probably worth pointing out that C's pointer arithmetic is not only
dangerous, and a significant source of errors, but it also makes
programs run slower.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique oriente objet/
                            Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tl. : +33 (0)1 30 23 45 16

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Wesley Groleau]

 > programs? For that matter, why would you ever *want* uninitialized

I wouldn't, but ...

 > variables? Another way to ask that is when is initialization a bad

When the programmer graduates from deliberately taking
advantage of it to taking it for granted.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[kanze]

James Rogers <jimmaureenrogers@att.net> wrote in message
news:<Xns9398C9067948jimmaureenrogers@204.127.36.1>...
 > kanze@gabi-soft.fr wrote in
 > news:d6652001.0306120418.37a97d1c@posting.google.com:

 >  > James Rogers <jimmaureenrogers@att.net> wrote in message
 >  > news:<Xns9396BDBB14558jimmaureenrogers@204.127.36.1>...
 >  >> kanze@gabi-soft.fr wrote in
 >  >> news:d6652001.0306100323.338a2a1c@posting.google.com:

 >  >>  > That doesn't mean C++ is perfect, of course.  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.

 >  >> Since this was cross-posted to comp.lang.ada I think it is fair to
 >  >> mention that there is a language that meets your description
 >  >> above.  That language is Ada.

 >  > Permit me to be sceptical.  If your claim is that Ada has more of
 >  > the safe defaults than C++, I doubt anyone would dare argue it.  If
 >  > your claim is even that most of the defaults are the safe version,
 >  > from what little I know of the language, it would seem true.  But
 >  > to say that in 1983, they got everything right, including problems
 >  > that weren't even understood until significantly later.  Well, I'm
 >  > sceptical.  Perfection just isn't of this world.

 > I am sorry. I did not mean that Ada is perfect. I meant that Ada is a
 > fundamentally safe language with the ability to turn off checking if
 > you encounter a situation where checking presents a problem for you.

 >  > One point where I'm pretty sure Ada 83 didn't have the right
 >  > default (although they may have fixed it in Ada 95): garbage
 >  > collection.  While there are places where it is necessary to turn
 >  > garbage collection off (which seriously limits the use of a
 >  > language in which you cannot have untraced pointers, which the
 >  > garbage collector cannot see), the safe option is obviously to have
 >  > it on by default, no?

 > Is garbage collection always the right default? For web applications
 > this may be true. Ada was originally designed for hard real time
 > embedded systems. In 1983 and 1995 there was no way to implement
 > deterministic garbage collection for hard real time systems with
 > nanosecond timing requirements.

There still isn't, if you are talking about nanosecond timing
requirements.  In fact, at that level, there is no way to implement
dynamic memory at all.

 > That said, like C++, Ada does not prohibit garbage collection.

Perhaps a more relevant question would be: do comment implementations
have it?  Or is it used?  (But as others have mentionned, it may not be
used because typical Ada applications are in domains where it is NOT
appropriate.)

 >  >> Its defaults are fundamentally safe. It provides the ability to
 >  >> override the safety constraints whenever you choose to. Note how
 >  >> Ada differs from Java. You cannot turn off array bounds checking
 >  >> for Java. In Ada you can. In fact, many Ada compilers will
 >  >> optimize out bounds checking when they can determine the checks
 >  >> are unnecessary.

 >  > I believe that this is standard practice in all languages which
 >  > support array bounds checking.

 > This is standard practice in theory. For many languages the reality is
 > that such optimizations are rare because the compiler lacks the
 > information needed to prove the safety of removing the bounds checks.

The information isn't difficult to synthesize.  But generally speaking,
if the array bounds checking is part of the language, the compiler knows
it.  If your code is full of goto's, it is difficult for the compiler to
figure out when it can suppress the checking, but it isn't difficult to
realise that in a classical for loop, it doesn't have to check the
bounds each time through.

 >  >> In other words, you can arrive at the same level of safety which
 >  >> is the default for C++.

 > > And you're bragging about it:-) ?

 > No, I am being practical. You can remove all safety checks in Ada and
 > produce a program as unsafe as anything you might write in C. On the
 > other hand, you can write a C++ program carefully and produce a very
 > safe result. Note that there is a lot of crossover in safety here.

This sounds more like what I thought.  You can write junk in either
language, and you can write robust code in either.  It's just that one
language makes writing junk particularly easy, and the other makes
robust code easier.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique oriente objet/
                            Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tl. : +33 (0)1 30 23 45 16

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[LLeweLLyn]

James Rogers <jimmaureenrogers@att.net> writes:

 > "Balog Pal" <pasa@lib.hu> wrote in news:3ee8901a@andromeda.datanet.hu:
 >
 >  > "James Rogers" <jimmaureenrogers@att.net> wrote in message
 >  > news:Xns9397C17B49692jimmaureenrogers@204.127.36.1...
 >  >
 >  >> Interesting. Do you think the fundamental safety problem in C code
 >  >> is ininitialized integers?
 >  >
 >  > Not "the" bat a very seriously fundamental problem I find in practice.
 >  >
 >  >> What about memory leaks
 >  >
 >  > Memleaks: I find not a problem in C++.  (it is in C)   [user shall not
 >  > handle memory in C++, containers and self-managing classes can solve
 >  > that
 >  > problem.]
 >
 > Do you ever deal with C++ code written using C style primitives such
 > as arrays? I understand that such code still exists.

Yes, it does, and will continue to do so - std::vector<> handles dynamic
     memory allocation nicely, but if one must avoid dynamic memory
     allocation, one must either use an array, or download an
     apropriate array wrapper. Additionally, std::vector<> is for
     variable sized arrays, and not all arrays should be variable
     sized.

IMO the real solution to this is for more implementations to provide
     bounded pointers - unfortunately, that doesn't happen. What C++
     needs is a revolt against the old gaurd that fails to provide such
     things simply because they have always failed to provide such
     things.

 >
 >  >
 >  >> de-referencing
 >  >> null pointers, and array bounds violations?
 >  >
 >  > null pointers: not really. Dangling pointers is a problem. But it is not
 >  > a
 >  > coding-level problem but more generic, object lifetime problem on the
 >  > design
 >  > level.
 >
 > I agree that pointer lifetime issues are a design issue. One of the
 > sometimes more difficult rules in Ada deals with pointer lifetime
 > issues. (In Ada they are called access variables, but the lifetime
 > issue applies here.) The language has very strict rules about access
 > value lifetimes. The compilers enforce those rules. The result is
 > a very low occurrance of dangling pointers.

In C++ one downloads, writes, or finds in the standard library a smart
     pointer that (via the compiler) enforces such rules. No, this is
     not as good as what Ada access types provide; though the
     functionality may be as good or better, the fact that standard
     library only provides one kind (an IMO auto_ptr is not a
     particularly good kind of smart pointer), is in practice a
     significant, but not insurmountable, problem in encouraging the
     use of safer smart pointers.

 >  >
 >  > Array bounds: C, not C++. As normally in C++ we use containers, and
 >  > those do
 >  > bounts checks in debug build, that's enough to cath the typos/offby1
 >  > goofing. Generally.
 >
 > Again, what about C++ code written using C style primitives such as
 > strings and other forms of arrays?
 >
 > What C++ allows, and provides for "free" with the STL, is the
 > ability to wrap the C style primitives such as arrays in a class,
 > with all the bounds checking built into the class.
 >
 > This provides safety at the expense of some efficiency. Although
 > the STL is part of the language definition, it is not part of the
 > language syntax. A C++ compiler cannot optimize out bounds checks
 > from STL or other container classes.

I think you have some minor misunderstaings here. First, the ISO C++
     standard says nothing about bounds checking of standard library
     iterators, and if one is not careful about the bad habit of
     passing references to containers to functions, one can get some
     nasty surprises from iterator invalidation rules. If one misuses
     an iterator, either via a container operation that invalidates it,
     or via an arithmetic operation that takes it out of bounds, the
     ISO C++ standard says (essentially) 'the behavior is
     undefined'. This has obvious drawbacks.

In practice, several implementations provide a 'debug mode' behavior,
     which throws exceptions, or aborts with appropriate error
     messages, when one does inappropriate things with iterators, and a
     'release mode' behavior, where 'undefined behavior' is some
     compromise between best performance, and whatever the implementor
     found most convienient. One can usually use what amount to
     compiler flags to change modes, though since the standard library
     provider is sometimes not the same as the core language provider,
     these flags may be interesting. :-)

Second, while no compiler I know of does this, I believe it is
     possible to optimize bounds checking out of a bounds checked
     standard library implementation, though it likely requires
     extensive co-operation between standard library provider and
     compiler provider (again, sometimes not the same entity) to be
     practical.

 >
 >  > My guess is "we're cool guys not using lint". ;-o

In my experience this and related problems have everything to do with
     ignorance, and nothing to do with thinking 'we're cool ...'

I've said it before, and I'll say it again - ignorance is C++'s worst
     problem. Having Ada's safer defaults, checks, etc, would help, but
     not has much as an aggressive campaign against ignornace. (And in
     practice such a campaign would be necessary part of getting
     Ada-like safer defaults and checks in C++.)

 >  > btw lint will pick every case of uninited variable I guess, how you tell
 >  > it
 >  > to pass those you actually want uninited?
 >  >
 >  >> The reason is that many programmers neglect to use tools such as
 >  >> lint, which support my point. Programmers are frequently lazy.
 >  >
 >  > Well, if it was part of the package -- I still don't know whether I used
 >  > it
 >  > or not. (More probably yes.)  with C++ it's quite a crude tool, isn't
 >  > it?
 >
 > Do modern C++ compilers produce the level of diagnostic output available
 > from (or better than) lint?

For the cases of uinitialized variables, type checking, things that
     are not too hard to detect and almost certainly wrong, the answer
     is often yes - but for higher level tasks the answer is no.

 >
 >  >
 >  > Can you tune it to pick up most real problems while not producing 10
 >  > times
 >  > more noise?
 >
 > This has always been an issue with lint. Tuning the output to give
 > no false reports while still not missing any real problems is not
 > easy.
 >  >
 >  >> A language that requires extra work to achieve safety will
 >  >> frequently be used to create unsafe programs. This is not
 >  >> because it is impossible to create safe programs with the language.
 >  >> It is because doing so requires extra work.
 >  >
 >  > Sure, that's why the other poster claimed the uninitialised is a bad
 >  > default
 >  > behavior.
 >
 > I agree it is bad. I just did not think it was the most often encountered
 > problem.

I don't think it is the most often encountered problem either. I've
     worked in some places with awful coding habits, but everywhere
     I've been the compiler warning flags for uninitialised variables
     are used and heeded.

 >
 > Ada goes a bit further in this area than most C++ programs.
 > Ada allows you to define your own numeric types (as primitives, not
 > classes). You are allowed to define several characteristics about
 > these types.
 >
 > type My_Index is range 1..10;

That's possible in C++, but it isn't that easy - it could be, but
     neither the standard library (nor boost) provide ranged integers.

 >
 > The above line defines an integer type with a valid range of values
 > from 1 through 10 inclusive. Now, let's combine that definition with
 > an array type definition:
 >
 > type Nums is array (My_Index) of Float;
 >
 > This defines an array type indexed by the type My_Index. Each element
 > of the array is a Float.
 >
 > The compiler can now optimize out bounds checking for accessing
 > an array of Nums. The only index type allowed is type My_Index.
 > Every possible value of that type maps to an array element.
 >
 > Trying to assign an out of range value to a variable of My_Index
 > causes the program to raise the exception Constraint_Error at run
 > time.
[snip]

Hm. This sounds like the bounds checking is not being optimized out,
     but moved from the array to the index type. This seems an
     improvement - I suspect assigments to index variables are somewhat
     less common than using them in the array, but the compiler still
     can't get rid of all checks. (Yes this is still an improvement
     over the C++ situation w.r.t. to bounds checking.)

[synch stuff snipped]


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[LLeweLLyn]

Wesley Groleau <wesgroleau@despammed.com> writes:

 >  >
 >  > One point where I'm pretty sure Ada 83 didn't have the right default
 >  > (although they may have fixed it in Ada 95): garbage collection.  While
 >  > there are places where it is necessary to turn garbage collection off
 >  > (which seriously limits the use of a language in which you cannot have
 >  > untraced pointers, which the garbage collector cannot see), the safe
 >  > option is obviously to have it on by default, no?
 >
 > In Ada, GC is automatic for stack variables,
[snip]

In C++ GC is automatic for stack variables as well - and via
     constructors and destructors, one can leverage that to make it
     automatic for many kinds of dynamic variables. This isn't a
     complete solution however - one sometimes ends up with a few dynamic
     objects for which no readlily availible smart pointer is suitable.

 > but it
 > was intentionally left up to the vendor for access types
 > (which in Ada only exist when the programmer explicitly
 > declares them) because in some applications, it could
 > cause timing problems.  However, Ada 95 did add the ability
 > for the programmer to define whether GC occurs for any particular
 > data type, as well as to define how it occurs.

What do you mean by 'define how it occurs'? In C++ one 'defines how it
     occurs' by overloading new and delete, writing a smart pointer, or
     downloading an appropriate smart pointer or garbage
     collector. This is hardly the most convient way (for a programmer
     using C++), but it has oodles of flexibility.

 >
 >  > 2) you can generally "work around" the safety checks if necessary
 >  > (hopefully on a case by case basis, using source code constructs;
 >  > e.g. by writing array.unsafe_at( index ) rather than array[ index ]).
 >
 > Actually, it's something like
 > pragma Suppress ( <type-of-check>, <entity> );
[snip]

I think in another post I provided a link to what the rm95 has to say
     about this.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Ron Natalie]

"Terje Sletteb" <tslettebo@chello.no.nospam> wrote in message news:WXiGa.11515$KF1.273500@amstwist00...
 > > > I am sorry. I misunderstood. I thought you were being sarcastic.
 > > If your suggestion was adopted, how would it affect existing
 > > programs? For that matter, why would you ever *want* uninitialized
 > > variables?
 >
 > Reading from streams is an obvious example:
 >
 > int i;
 >
 > stream >> i;
 >
 > Intialising "i" beforehand would just be vasteful.

It wouldn't break anything, just make it a tiny bit slower.   If you allowed something to inidicate
uninitialized, you could get the performance back.

     int i;                // initialize to 0
     stream >> i;

     auto int i;        // recycle auto to mean uninitialized.
     stream >> i;

In the above case existing code that used the unqualified name would work in old and new compilers
(with a slight performance hit in the new complier), those in the second case would work the same way
in the old and new compiler (the same way it used to).

The failure to initialize all variables is one of the major inconsistancies of C++, along with the braindamaged
way arrays work.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Dave Harris]

jimmaureenrogers@att.net (James Rogers) wrote (abridged):
 > If your suggestion was adopted, how would it affect existing
 > programs?

Some currently non-portable ones would become well-behaved.


 > why would you ever *want* uninitialized variables?

Mainly for speed. We would want to be able to say, eg,
     std::vector<int> vec( 1000000, unitialised );

to avoid writing a million zeros. Which I suspect makes it a non-trivial
language change. What is the type of "initialised"?

-- Dave Harris, Nottingham, UK

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Andrei Alexandrescu]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9398BD1E07E3Ejimmaureenrogers@204.127.36.1...
 > "Andrei Alexandrescu" <SeeWebsiteForEmail@moderncppdesign.com> wrote in
 > news:bc9h7j$gm42t$1@ID-14036.news.dfncis.de:
 >
 >  > I was mentioning that just to mention a simple language design decision
 >  > that's a no-brainer to implement, yet which imho has a great impact
 >  > because
 >  > of the psychological issue you mentioned. The others are also
important,
 >  > but
 >  > not as trivial to implement and support without making performance
 >  > tradeoffs.
 >
 > I am sorry. I misunderstood. I thought you were being sarcastic.

Must be my fame of being cranky :o).

 > If your suggestion was adopted, how would it affect existing
 > programs? For that matter, why would you ever *want* uninitialized
 > variables? Another way to ask that is when is initialization a bad
 > thing?

Multiple/big return values are an example; you pass a value by reference to
a function, and there's an implied contract that the function will fill the
value. If the value is an array, it might become inefficient to initialize
the array for no reason.


Andrei



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Preben Randhol]

Vinzent Hoefler wrote:
> kanze@gabi-soft.fr wrote:
> 
>>Note that while we have been speaking here about safety, no one has
>>mentionned readability.
> 
> Probably because this is what Ada is so well known for, that nobody in
> c.l.a. doesn't think about it anymore... ;)

Yes. It was one of the design goals:

   http://www.adapower.com/rm95/arm95_3.html#SEC3

Might also be interesting for people no familiar with Ada95 to have a
glance at these slides to get a introduction to the difference between
C/C++, Java and Ada:

   http://libre.act-europe.fr/Software_Matters/03-C_pitfalls.pdf

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Replacement for Text_IO? (was Re: C bug of the day)

[Dale Stanbrough]

In article <veko4b5b0qgmea@corp.supernews.com>,
 "Randy Brukardt" <randy@rrsoftware.com> wrote:

> Even the MS-DOS version (full Ada 83) has quite limited compilation
> sizes because of 640K doesn't go that far. (Text_IO uses about 65% of
> the available memory.)


Everyone laments the slowness of Text_IO, and how it isn't a really
high powered I/O solution, yet it is used a lot because it is 
reliably there in every Ada compiler.

Are there any moves to provide an alternative to Text_IO in Ada0Y
that will allow for more efficient implementations? 
You could get rid of the Page, Line and Column counting, as
well as moving the generic I/O packages into child packages.

Names? How about...

   Ada.Text_IO_Lite
   Ada.Text_IO_Next_Generation

or perhaps...

   Ada.Next_IO

:-)

dale

Re: C bug of the day

[Larry Kilgallen]

In article <x7vllw52nmd.fsf@pushface.org>, Simon Wright <simon@pushface.org> writes:
> kanze@gabi-soft.fr writes:
> 
>> Note that while we have been speaking here about safety, no one has
>> mentionned readability.  And IMHO, this is the most important single
>> feature of safety: a well run code review will catch many more
>> errors than the best compiler, but for a code review to be
>> effective, the readers have to be able to understand what you have
>> written.
> 
> Different kinds of errors, I'd think. I would prefer not to review code
> until it compiles cleanly (I know there are other approaches).

For one thing, fixing the kinds of errors that the compiler catches
might introduce the kinds of errors the humans catch.  Doing many
retries of the compiler checking is much cheaper than doing many of
the human checking.

Re: C bug of the day

[Simon Wright]

James Rogers <jimmaureenrogers@att.net> writes:

>           For that matter, why would you ever *want* uninitialized
> variables? Another way to ask that is when is initialization a bad
> thing?

When there is nothing you can sensibly initialize with (yet), and to
supply an unnecessary initialization would prevent the compiler (or
the static analyser) warning you that one of your paths doesn't
initialize the variable.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Bounded integer types (was: C bug of the day)

[Ed Avis]

James Rogers <jimmaureenrogers@att.net> writes:

>Compare this with defining a numeric type with all integers from
>1 through 101:
>
>type My_Ints is range 1..101;
>
>In this case Ada automatically provides all the checking and
>numeric operators for you.

FWIW, I have been working on an equivalent for C++, as

    bounded<int, 1, 10> i;

to say that i has values in the range 1..10 (I use .. to mean an
inclusive range, I hope that it doesn't mean something different in
Ada-land).  Then operations like addition are implemented so that all
range checking can be done statically - no checks at run time, except
for an explicit range_cast<int, x, y>() function which turns an int
into a bounded<int, x, y>.

So for example the type of (i + i) would be bounded<int, 2, 20>.  If
you wanted to assign this to a variable that holds only values 1..10
you would need a range_cast and a possible exception at run time.  But
assigning it to a variable that can take a larger range (or to a plain
old int) is fine.

Apart from operator=, there are no mutating operations like ++ or +=,
because these cannot be statically checked.  And operator= takes only
another bounded<int, ...> or a compile-time constant.  The aim of the
bounded<int, ...> type is to have no overhead beyond an ordinary int
(if the compiler is reasonably good) and to have no exceptions thrown
except when the programmer asks for them with range_cast.

To emphasize one of those points: you cannot assign or initialize a
bounded<int, ...> with a value that's not known at compile time.  The
default value of an uninitialized bounded type is the minimum value of
the range.  If I wanted to declare i with range 1..10 and initialize
it to 5, I'd have to write

    bounded<int, 1, 10> i = bounded<int, 6, 6>();

This is a horrible syntax but I couldn't find any much cleaner way of
specifying that the constructor must take a compile-time constant.

I realized this was a bit limiting so I have also started work on a
throwing_bounded class which does have operator=, operator++ and
friends, and throws exceptions at run time if you go outside the
range.

Followups set to the C++ newsgroup only.

-- 
Ed Avis <ed@membled.com>

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Addding new attributes to Ada0Y

[Robert I. Eachus]

Vinzent Hoefler wrote:

 > Yes, and finding this *very* useful, it reminds me, I would like to
 > have this feature for *every* variable, not just for arrays:
 >
 > As an example, currently
 >
 > |x : My_Enum;
 > |
 > |for i in x'Range loop ...
 >
 > doesn't work, you have to write
 >
 > |for in in My_Enum'Range loop
 >
 > each time. Is there any convincing explanation why it isn't allowed to
 > use the actual type of a variable instead of the type itself?

No real reason, just no one saw the need for that particular attrbiute. 
  You might want to post a request for the feature in Ada0Y to 
Ada-Comment@ada-auth.org.

 > I can imagine situations (especially with subtypes) where it could be
 > handy to use the variables' type instead of an explicit type
 > specification.

You will need a better justification than that!

But there is one. ;-)  A discrete variable declaration can have an 
explict range in its subtype_indication:

Size: Integer range 0 .. 1000;

There is no way to identify the subtype of Size to use the 'Range 
attribute, but there are times when it would come in handy. If this is 
added to the language, then probably the attributes Object'First and 
Object'Last should also be added for scalar objects.

Of course, there is a real useful idiom which would need another 
language change.  Right now the initial value, if it exists, is part of 
the declaration of an object.  Again, no particular reason for that, but 
RM8.3(14) would need to add another exception to its list.  It sure 
would be nice though, to be able to say:

Size: Integer range
    Some_Expression..Some_Other_Complex_Expression := Size'First;

Re: C bug of the day

[Francis Glassborow]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

In message <WXiGa.11515$KF1.273500@amstwist00>, Terje Sletteb� 
<tslettebo@chello.no.nospam> writes
>int i;
>
>stream >> i;
>
>Intialising "i" beforehand would just be vasteful.
>
Well yes, but any halfway competent programmer has a way to initialise a

variable from a stream, in my case I use my own template that allows me 
to write:

int i(read<int>(stream));

and note that that allows me to initialise const qualified variables 
from an input stream.

The special case is where we want to initialise an array from input 
though I do have a contortion to do that as well but only for user 
defined types written to provide that facility.


-- 
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Terje Slettebø]

"Ron Natalie" <ron@sensor.com> wrote in message
news:Fn2dnUzrDqr3YXSjXTWQlg@giganews.com...
>
> "Terje Sletteb" <tslettebo@chello.no.nospam> wrote in message
news:WXiGa.11515$KF1.273500@amstwist00...
>  > > > I am sorry. I misunderstood. I thought you were being
sarcastic.
>  > > If your suggestion was adopted, how would it affect existing
>  > > programs? For that matter, why would you ever *want*
uninitialized
>  > > variables?
>  >
>  > Reading from streams is an obvious example:
>  >
>  > int i;
>  >
>  > stream >> i;
>  >
>  > Intialising "i" beforehand would just be vasteful.
>
> It wouldn't break anything, just make it a tiny bit slower.   If you
allowed something to inidicate
> uninitialized, you could get the performance back.
>
>      int i;                // initialize to 0
>      stream >> i;
>
>      auto int i;        // recycle auto to mean uninitialized.
>      stream >> i;
>
> In the above case existing code that used the unqualified name would
work in old and new compilers
> (with a slight performance hit in the new complier), those in the
second case would work the same way
> in the old and new compiler (the same way it used to).

"auto" has already been suggested reused for the type inference
proposal. :) ("Decltype and auto"
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1478.pdf)).
However, that may not clash in this case.

Anyway, this may be a QoI issue. A compiler could warn if an
uninitialised variable is read from, and they typically do.


Regards,

Terje

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Dave Harris]

ron@sensor.com (Ron Natalie) wrote (abridged):
>      int i;                // initialize to 0
>      stream >> i;
> 
>      auto int i;        // recycle auto to mean uninitialized.
>      stream >> i;
> 
> In the above case existing code that used the unqualified name
> would work in old and new compilers (with a slight performance
> hit in the new complier), those in the second case would work
> the same way in the old and new compiler (the same way it used
> to).

A good optimiser could emit the same code in both cases. The value
zero is never read, so never needs to be written.

The compiler could figure this out either from the source (eg if
stream is from a template) or from knowing the semantics of the
std library (if stream is from the std). Cases where zero-
initialisation cannot be optimised away are fairly rare - although 
sometimes important when they do arise.

If we actually need zeros, it may be more efficient to let the
compiler provide them. For example, with an instance of a deep
class hierarchy, the compiler can zero-initialise all of the
instance variables with a single memset(), instead of every
class needing its own set of assignments.

Indeed, it can make sense to push the nulling even further back,
and have a "nulled heap". Then the system can do the work of
writing nulls during its idle time.

-- Dave Harris, Nottingham, UK

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Robert I. Eachus]

Mike Silva wrote:
> kanze@gabi-soft.fr wrote in message news:<d6652001.0306120418.37a97d1c@posting.google.com>...
>  >
>  > One point where I'm pretty sure Ada 83 didn't have the right default
>  > (although they may have fixed it in Ada 95): garbage collection.  While
>  > there are places where it is necessary to turn garbage collection off
>  > (which seriously limits the use of a language in which you cannot have
>  > untraced pointers, which the garbage collector cannot see), the safe
>  > option is obviously to have it on by default, no?
> 
> I've read that Ada customers don't ask for garbage collection, because
> in typical Ada applications (safety-critical, hard realtime embedded)
> dynamic allocation is simply not acceptable.

Hmmm...  I'd rather say that for 99% of what garbage collection is 
needed for in other languages, in Ada it is easy enough to avoid 
creating the garbage in the first place.  Most objects are created on 
the stack instead of the heap, so no garbage collection is required. 
For strings, one of the major causes of garbage in C and C++, the 
package Ada.Strings.Unbounded provides an arbitrary length string type 
with the requirement in RM A.4.5(88): "No storage associated with an 
Unbounded_String object shall be lost upon assignment or scope exit."

If you really need true garbage collection, there is also the ability to 
define a storage pool (see RM13.11 Storage Management) which has full 
garbage collection.  I think in Ada0Y there will probably be three 
packages which provide non-default storage pools with mark-release and 
full garbage collection.  Using them will require withing the 
appropriate package (and possibly instantiating a generic or calling a 
procedure to set the pool size depending on the approach selected.

 From then on, all you need to do to get garbage collection for a type 
is add an attribute_definition_clause for the access type:

for T'Storage_Pool use Garbage_Collection;

Why three packages?  There is a major advantage to having all the 
objects in a collection the same size.  So there will probably be two 
garbage collection storage pools, one where the size of all objects 
allocated from the pool is set when the pool is created, and one where 
the size of an object is set at allocation time.

As you can see, storage pools in Ada allow the programmer to mix many 
types of storage management, and not have the actual code which creates 
(and/or destroys) objects cluttered up with storage management code. 
This is, as far as I am concerned, a wonderful feature of Ada.  You can, 
for example have full garbage collection for some complex type, while in 
time critical sections of code you can avoid triggering garbage 
collection.  Remember garbage collection is associated with an access 
type, and not with the type of the actual data object.  So you can have

function My_Device_Driver(...) return Data;

where no garbage collection or storage management can occur, and call it 
in an allocator:

Some_Pointer := new Data'(My_Device_Driver(...));

Which may trigger garbage collection, but after the object value has 
been created and outside any time critical regions of code. You can 
even, if you have the need, have multiple access types with different 
storage management policies for the same data type. ;-)

So as far as I am concerned, in Ada(95) all the garbage collection you 
may ever need is "in there."  And the defaults (no garbage collection, 
heap management for Ada.Strings.Unbounded.) are correct.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Ed Avis]

LLeweLLyn <llewelly.at@xmission.dot.com> writes:

>>In Ada, GC is automatic for stack variables,

>In C++ GC is automatic for stack variables as well

I think this is abusing the term 'garbage collection', consider:

    int* f()
    {
        int x = 5;
        return &x;
    }

If C++ really did have garbage collection for stack variables, then x
would not be destroyed on exit from the function since there is still
a live pointer to it.  What C++ has is something much cruder - any
stack variable is destroyed on exit from the scope it was declared in.

You could say 'C++ does have garbage collection for stack variables,
you're just not allowed to return pointers or references to them', but
that amounts to the same thing.

-- 
Ed Avis <ed@membled.com>

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[James Rogers]

kanze@gabi-soft.fr wrote in
news:d6652001.0306130749.5d9cd084@posting.google.com: 

> James Rogers <jimmaureenrogers@att.net> wrote in message
> news:<Xns9398C9067948jimmaureenrogers@204.127.36.1>...
> > That said, like C++, Ada does not prohibit garbage collection.
> 
> Perhaps a more relevant question would be: do comment implementations
> have it?  Or is it used?  (But as others have mentionned, it may not
> be used because typical Ada applications are in domains where it is
> NOT appropriate.)
> 

The only implementation I am aware of was the no longer supported
version of GNAT that targeted the JVM. Garbage collection was supported
because the JVM requires it.

Typical Ada applications are in real time safety critical domains.
Garbage collection is not heavily used in those domains. As others
have noted, some domains such as avionics systems do not even use
dynamic memory allocation other than stack-based allocation.

What all Ada compilers do support is the creation and use of storage
pools. Quoting from the Ada language reference manual:

"Each access-to-object type has an associated storage pool. The storage 
allocated by an allocator comes from the pool; instances of 
Unchecked_Deallocation return storage to the pool. Several access 
types can share the same pool."

"A storage pool is a variable of a type in the class rooted at 
Root_Storage_Pool, which is an abstract limited controlled type. By 
default, the implementation chooses a standard storage pool for each access 
type. The user may define new pool types, and may override the choice of 
pool for an access type by specifying Storage_Pool for the type."

When you define a storage pool you also must define implementations
for the abstract procedures Allocate and Deallocate.

When you define an access type you can define which storage pool
instances of that type uses. All allocations and deallocations 
relating to instances of that access type use the specified storage 
pool and are subject to the allocation and deallocation rules of that 
storage pool.

This is how you would define Ada equivalents to smart pointers or
even garbage collection. I like the idea that you can create special
characteristics for some access types without requiring that special
behavior for all access types.

Jim Rogers

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Terje Slettebø]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20030613191305.38347A@brangdon.madasafish.com...
> jimmaureenrogers@att.net (James Rogers) wrote (abridged):
>  > If your suggestion was adopted, how would it affect existing
>  > programs?
>
> Some currently non-portable ones would become well-behaved.
>
>  > why would you ever *want* uninitialized variables?
>
> Mainly for speed. We would want to be able to say, eg,
>      std::vector<int> vec( 1000000, unitialised );
>
> to avoid writing a million zeros. Which I suspect makes it a
non-trivial
> language change. What is the type of "initialised"?

You could always have an overloaded constructor, with a "tag" type (as
suggested in the "using named parameters separators" thread at
comp.std.c++):

enum uninitialised_type { uninitialised };

std::vector constructor:

vector(size_t size, uninitialised_type); // Performs uninitialised
construction

Not a non-trivial language change, at all. Just a library change. An
implementation may well optimise away the tag value passing, seeing that
it's not used.


Regards,

Terje

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Wesley Groleau]

>  > In Ada, GC is automatic for stack variables,
> [snip]
> 
> In C++ GC is automatic for stack variables as well - and via

And in any other language that has a calling stack.

>  > cause timing problems.  However, Ada 95 did add the ability
>  > for the programmer to define whether GC occurs for any particular
>  > data type, as well as to define how it occurs.
> 
> What do you mean by 'define how it occurs'? In C++ one 'defines how it
>      occurs' by overloading new and delete, .....

Same thing, different names.  If you need any kind
of auto-initialization or cleaning (which means not
only GC, but closing files, reference counting, all
sorts of things) you declare the type to be an extension
of Finalization.Controlled and override/extend the
Initialize, Adjust, and Finalize operations.  Of course,
that means you can't do it with ordinary numbers,
characters, and other simple types, but, who needs to?


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Wesley Groleau]

>  > > If your suggestion was adopted, how would it affect existing
>  > > programs? For that matter, why would you ever *want*
uninitialized
>  > > variables?
>  >
>  > Reading from streams is an obvious example:
>  >
>  > int i;
>  >
>  > stream >> i;
>  >
>  > Intialising "i" beforehand would just be vasteful.

I would think even a mediocre compiler would optimize away
an obiously useless initialization.
> 
> It wouldn't break anything, just make it a tiny bit slower.   If you
allowed something to inidicate
> uninitialized, you could get the performance back.
> 
>      int i;                // initialize to 0
>      stream >> i;
> 
>      auto int i;        // recycle auto to mean uninitialized.
>      stream >> i;

Wouldn't it be better to have the old syntax do the same thing?
Also, doesn't "auto int" have a tiny hint of doing something
automatic to the int (as opposed to _not_ doing something)?


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[LLeweLLyn]

Ed Avis <ed@membled.com> writes:

 > LLeweLLyn <llewelly.at@xmission.dot.com> writes:
 >
 >>>In Ada, GC is automatic for stack variables,
 >
 >>In C++ GC is automatic for stack variables as well
 >
 > I think this is abusing the term 'garbage collection', consider:
 >
 >     int* f()
 >     {
 >         int x = 5;
 >         return &x;
 >     }

As far as I can see, I abused the term 'garbage collection' exactly as
     much as Wesley did. Ada has no more (and no less) garbage
     collection here than C++ does. In both cases, stack variables are
     deallocated at the end of the function or subprogram. What Ada
     does have is checked accesibilty rules that prevent returning a
     pointer to a local object.

 >
 > If C++ really did have garbage collection for stack variables, then x
 > would not be destroyed on exit from the function since there is still
 > a live pointer to it.  What C++ has is something much cruder - any
 > stack variable is destroyed on exit from the scope it was declared in.
 >
 > You could say 'C++ does have garbage collection for stack variables,
 > you're just not allowed to return pointers or references to them', but
 > that amounts to the same thing.

Yes. And it amounts to being equivalent to Wesley's statement.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Terje Slettebø]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:V1ggZeGK6g6+EwQn@robinton.demon.co.uk...
 > In message <WXiGa.11515$KF1.273500@amstwist00>, Terje Sletteb
 > <tslettebo@chello.no.nospam> writes
 > >int i;
 > >
 > >stream >> i;
 > >
 > >Intialising "i" beforehand would just be vasteful.
 > >
 > Well yes, but any halfway competent programmer has a way to initialise
a
 >
 > variable from a stream, in my case I use my own template that allows
me
 > to write:
 >
 > int i(read<int>(stream));

I would be interested to know how read() is implemented. Could you
posted it?


Regards,

Terje

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Terje Slettebø]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:9PWcnbLRQfCMCHajXTWcpQ@gbronline.com...
 >
 > >  > > If your suggestion was adopted, how would it affect existing
 > >  > > programs? For that matter, why would you ever *want*
 > uninitialized
 > >  > > variables?
 > >  >
 > >  > Reading from streams is an obvious example:
 > >  >
 > >  > int i;
 > >  >
 > >  > stream >> i;
 > >  >
 > >  > Intialising "i" beforehand would just be wasteful.
 >
 > I would think even a mediocre compiler would optimize away
 > an obiously useless initialization.

I wouldn't count on that.

Especially if the definition of istream.operator(int) is in another
translation unit, it usually can't look across translation units at
definitions, so it won't know what it does.


Regards,

Terje

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[John Potter]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On 14 Jun 2003 16:27:12 -0400, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:

> In message <WXiGa.11515$KF1.273500@amstwist00>, Terje Sletteb� 
> <tslettebo@chello.no.nospam> writes
> >int i;

> >stream >> i;

> >Intialising "i" beforehand would just be vasteful.

> Well yes, but any halfway competent programmer has a way to initialise
a

> variable from a stream, in my case I use my own template that allows
me 
> to write:

> int i(read<int>(stream));

Let's see your template.  My guess:

template <class T>
T read (istream& is) {
   T item; // uninitialized or default constructed
   is >> item;
   return item;
   }

I'm guessing that you are just hiding the uninitialized fundamental or
default constructing a udt.

John

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Re: C bug of the day

[Dave Harris]

tslettebo@chello.no.nospam (=?Windows-1252?Q?Terje_Sletteb=F8?=) wrote 
(abridged):
> enum uninitialised_type { uninitialised };
> 
> std::vector constructor:
> 
> vector(size_t size, uninitialised_type); // Performs uninitialised
> construction
> 
> Not a non-trivial language change, at all. Just a library change.

The original request was for something like:

   int i = uninitialized;

which your proposal doesn't address. Although we could deal with the two 
situations with two separate changes, it would be nicer to have a single, 
uniform syntax. 

-- Dave Harris, Nottingham, UK

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Francis Glassborow]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

In message <CnRGa.11791$KF1.273607@amstwist00>, Terje Sletteb�
<tslettebo@chello.no.nospam> writes
>I would be interested to know how read() is implemented. Could you
>posted it?

Well for what they are worth here is the complete set of overloaded
function templates

Comments for improving them are very welcome.

// These templates provide safe input for any type that supports
operator>>
// 1) from console with prompt

        template<typename in_type>
        in_type read(std::string const & prompt, int max_tries = 3){
                in_type temp;
                int tries(0);
                while(tries++ != max_tries ){
                        std::cout << prompt;
                        std::cin >> temp;
                        if(std::cin.good()) return temp;
                        std::cin.clear();       // if it has failed,
reset it to normal
                        while(cin.get() != '\n'); flush stream
                        std::cout << "\n That input was incorrect, try
again: \n";
                }
                throw fgw::problem("Too many attempts to read data.");
        }

// 2) version without prompt, defaults to colon space prompt
        template<typename in_type>
        in_type read(int max_tries=3){
                return read<in_type>(": ", max_tries);
        }

// 3) version for general input stream, throws an exception if fails
        template<typename in_type>
                in_type read(std::istream & in){
                        in_type temp;
                        in >> temp;
                        if(in.good()) return temp;
                        if(in.eof()) throw fgw::problem("Tried to read
past end of file"); // handle end of file as special case
                        in.clear();  // reset input stream
                        throw fgw::problem("Corrupted data stream.");
                }


-- 
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Garbage Collector [Was: C bug of the day]

[Martin Krischik]

James Rogers wrote:

> This is how you would define Ada equivalents to smart pointers or
> even garbage collection. I like the idea that you can create special
> characteristics for some access types without requiring that special
> behavior for all access types.

Question is: did anybody ever do it? How difficult would it be to write a
true garbage collector as "plug in" storrage pool into an existing Ada?

I would love to have a garbage collected storrage pool for GNAT and would
participate in a team to develop one. That is: if it is possible for a non
funded project.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Francis Glassborow]

In message <u8enev0gr0rmbq7p4l3gh4sa5f80ohu43e@4ax.com>, John Potter 
<jpotter@falcon.lhup.edu> writes
>> int i(read<int>(stream));
>
>Let's see your template.  My guess:
>
>template <class T>
>T read (istream& is) {
>   T item; // uninitialized or default constructed
>   is >> item;
>   return item;
>   }
>
>I'm guessing that you are just hiding the uninitialized fundamental or
>default constructing a udt.

Come on, I can write better code than that. The main point was that 
input should be at least validated as appropriate to the type,.

-- 
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Ed Avis]

LLeweLLyn <llewelly.at@xmission.dot.com> writes:

>>>>In Ada, GC is automatic for stack variables,
>>
>>>In C++ GC is automatic for stack variables as well

>>     int* f()
>>     {
>>         int x = 5;
>>         return &x;
>>     }

>Ada has no more (and no less) garbage collection here than C++
>does. In both cases, stack variables are deallocated at the end of
>the function or subprogram. What Ada does have is checked accesibilty
>rules that prevent returning a pointer to a local object.

I suppose this is a conservative analysis associating a scope level
with each variable (as part of its type) and forbidding assignment or
initialization (or whatever the equivalent Ada terms are) of a value
to a variable not in the same scope or in a deeper scope.

Does this check ever get in the way of expressing reasonable programs?
Could not C and C++ have the same check?

-- 
Ed Avis <ed@membled.com>

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Terje Slettebø]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:jhPtsFBx6F7+EwOv@robinton.demon.co.uk...
 > In message <CnRGa.11791$KF1.273607@amstwist00>, Terje Sletteb
 > <tslettebo@chello.no.nospam> writes
 > >I would be interested to know how read() is implemented. Could you
 > >posted it?
 >
 > Well for what they are worth here is the complete set of overloaded
 > function templates
 >
 > Comments for improving them are very welcome.
 >
 > // These templates provide safe input for any type that supports
 > operator>>
 > // 1) from console with prompt
 >
 >         template<typename in_type>
 >         in_type read(std::string const & prompt, int max_tries = 3){
 >                 in_type temp;

I thought your point was that you avoided the use of uninitialised
variables? However, that still happens, here.

So maybe your point was that you have a function for providing safe
input using streams? (As we've discussed at the ACCU begin-cpp mailing
list)

Well, that was not what my posting was about. My posting, and what it
replied to, was that there may be cases where leaving a variable
uninitialised is ok. The same happens in your function (as John Potter
also pointed out).

I became a little put off, when you wrote: "Well yes, but any halfway
competent programmer has a way to initialise a variable from a stream".
As I understand, you're talking about safe input, which wasn't what I
was discussing, at all. My example was simple on purpose, to show the
use with a stream. The same code appears inside your function.

Had it been that you wanted to _add_ something to what I said, I'd
understood it. But the way you wrote it, made me think that you somehow
contradicted what I said about using an uninitialised variable. It
appears you just wanted to add something, then.

Naturally, anything but toy programs typically use some form of input
validation, but like I said, that's not the issue that was being
discussed.


Regards,

Terje

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Wesley Groleau]

 >  >>>In Ada, GC is automatic for stack variables,
 >  >
 >  >>In C++ GC is automatic for stack variables as well
 >  >
 >  > I think this is abusing the term 'garbage collection', consider:

Hard to remember, but I think I was hinting at the
fact that garbage collection is not nearly as important
when using a language that doesn't force you to put
everything interesting on the heap.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[John Potter]

On 15 Jun 2003 17:55:12 -0400, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:

 > In message <u8enev0gr0rmbq7p4l3gh4sa5f80ohu43e@4ax.com>, John Potter
 > <jpotter@falcon.lhup.edu> writes
 > >> int i(read<int>(stream));

 > >Let's see your template.  My guess:

 > >template <class T>
 > >T read (istream& is) {
 > >   T item; // uninitialized or default constructed
 > >   is >> item;
 > >   return item;
 > >   }

 > >I'm guessing that you are just hiding the uninitialized fundamental or
 > >default constructing a udt.

 > Come on, I can write better code than that. The main point was that
 > input should be at least validated as appropriate to the type,.

Your article was in the part of the thread talking about uninitialized
variables.  You claimed that any decent programmer had a way around
that.  The first line is all that counts and it matches your posted
code.  The template does not solve the problem no matter how much
error testing you add.  You still have a desirable uninitialized
fundamental and can not avoid default construction of udt.  It is
possible to avoid the problem for udt with a constructor taking a
stream; however, that does not generalize to a universal template.

Not a question of the quality of your code.  Just a guess that it had
nothing to do with the subject.  QED.

John

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Vinzent Hoefler]

Randy Brukardt wrote:

>Vinzent Hoefler wrote in message ...
>Erlo Haugen wrote:
>>>As for other 8 bits, Z80 and the like would be good candidates.
>
>>At least for 6502 and Z80 exist C-compilers, so I don't see why there
>>shouldn't be any Ada-Compiler. I even remember playing around with
>>Pascal and FORTH on a Z80 machine (around 1986).
>
>The original versions of Janus/Ada were for CP/M on 8080/Z80 machines.
>Certainly, in 1986 you could have purchased Janus/Ada from us.

Well, not so easy, I'd say. I doubt, you would have been allowed to
export to "communist" countries. ;)

>It would be relatively easy to create a cross-compiler to the Z80; we
>still have the majority of the source for it. Of course, it would be a
>significant job to bring it up to the current state of our compiler --
>it's been more than 15 years since any development took place on that
>compiler. But we haven't had a customer who was interested enough to
>partially fund it.

Well, I guess, I don't have the money to fund that either. What about
releasing that stuff to the open source community?


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: C bug of the day

[Randy Brukardt]

Vinzent Hoefler wrote in message ...
>Randy Brukardt wrote:
>>The original versions of Janus/Ada were for CP/M on 8080/Z80 machines.
>>Certainly, in 1986 you could have purchased Janus/Ada from us.

>Well, not so easy, I'd say. I doubt, you would have been allowed to
>export to "communist" countries. ;)

We weren't covered by those restrictions; we had a number of customers
in "communist" countries. (Yes, we checked!).

>>It would be relatively easy to create a cross-compiler to the Z80; we
>>still have the majority of the source for it. Of course, it would be a
>>significant job to bring it up to the current state of our compiler --
>>it's been more than 15 years since any development took place on that
>>compiler. But we haven't had a customer who was interested enough to
>>partially fund it.

>Well, I guess, I don't have the money to fund that either. What about
>releasing that stuff to the open source community?

It wouldn't be any value without the front-end, and no one would want to
use the 1986 front-end anyway. In any case, this isn't my code, its RR
Software's, and I'd have to come up with a business case for such a
release. That's much easier to do for currently active products (the
obvious purpose is to make money on support, as ACT does. But for that
to make sense, there would have to be customers with money - which
brings us back to the start.)

                    Randy.

Re: C bug of the day

[Vinzent Hoefler]

Randy Brukardt wrote:

>Vinzent Hoefler wrote in message ...
>>Randy Brukardt wrote:
>>
[Ada compiler for Z80]
>>Well, I guess, I don't have the money to fund that either. What about
>>releasing that stuff to the open source community?
>
>It wouldn't be any value without the front-end,

Mmh. If someone would write a new one...

>and no one would want to
>use the 1986 front-end anyway.

Yes, of course.

>In any case, this isn't my code, its RR
>Software's, and I'd have to come up with a business case for such a
>release.

Oh, those damn managers, I will *never* understand them.

You don't sell that thing anymore, so what would be the point in
trying to make money from something, you currently don't get money
from it anyway...? Too bad.


Vinzent.

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Randy Brukardt]

Dale Stanbrough wrote in message ...
>In article <veko4b5b0qgmea@corp.supernews.com>,
> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>
>> Even the MS-DOS version (full Ada 83) has quite limited compilation
>> sizes because of 640K doesn't go that far. (Text_IO uses about 65% of
>> the available memory.)
>
>
>Everyone laments the slowness of Text_IO, and how it isn't a really
>high powered I/O solution, yet it is used a lot because it is
>reliably there in every Ada compiler.
>
>Are there any moves to provide an alternative to Text_IO in Ada0Y
>that will allow for more efficient implementations?
>You could get rid of the Page, Line and Column counting, as
>well as moving the generic I/O packages into child packages.


Well, we actually have a cut-down Text_IO called RRText_IO in our
compilers for this reason. It helped in three ways: 1) It took up less
symbol table space; 2) It didn't drag in floating point and tasking
support; 3) It didn't have a lot of unused subprograms.

Everyone these days has a computer big enough to compile a hundred
Text_IOs at once, so (1) isn't needed anymore. Many Ada compilers can
eliminate unused subprograms from the final executable, so (3) isn't a
real issue, either. (And, for those compilers that can't remove unused
subprograms, clearly their implementor's time would be far better spent
adding that feature than implementing a new version of Text_IO). (2) is
specific to Janus/Ada; I doubt most other compilers can even generate a
program without any floating point support. Similarly, Janus/Ada has a
tasking stub for non-tasking programs, so that generics work without
dragging in the 40K task supervisor. But in the absense of such a
feature, it doesn't matter anyway.

So I doubt that there would be much benefit to having Text_IO_Lite. The
effort probably would be better spent on components or sockets or the
like.

               Randy.

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Gautier Write-only]

Dale Stanbrough:

> Everyone laments the slowness of Text_IO,

Who ? Who ?

> and how it isn't a really
> high powered I/O solution, yet it is used a lot because it is
> reliably there in every Ada compiler.
> 
> Are there any moves to provide an alternative to Text_IO in Ada0Y
> that will allow for more efficient implementations?
> You could get rid of the Page, Line and Column counting,

Are you sure that *this* takes much time ? Did you do a profiling ?

> as well as moving the generic I/O packages into child packages.

It is an aesthetic issue (although, who cares ?), not a performance
one... Do such non-instanciated generic sub-packages even appear in
the machine-code in object files, on any compilation system ?
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: C bug of the day

[Francis Glassborow]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

In message <lB5Ha.11929$KF1.273430@amstwist00>, Terje Sletteb� 
<tslettebo@chello.no.nospam> writes
> > // These templates provide safe input for any type that supports
> > operator>>
> > // 1) from console with prompt
> >
> >         template<typename in_type>
> >         in_type read(std::string const & prompt, int max_tries = 3){
> >                 in_type temp;
>
>I thought your point was that you avoided the use of uninitialised
>variables? However, that still happens, here.
>
>So maybe your point was that you have a function for providing safe
>input using streams? (As we've discussed at the ACCU begin-cpp mailing
>list)

For some reason I elided my thoughts when I transferred them to the 
keyboard. I was thinking more in terms of an analogy with not having new 
used unwrapped in a class whose dtor  calls the corresponding delete.

I meant to write:

Any half-way competent programmer has a mechanism to ensure that:

1) variables can support an operator >> (istream, T) can always be 
initialised except

2) within a function that handles failure of the call to operator>>

I agree that what I wrote was far from this.

I think that seeing cin >> in top level code sends a similar message to 
seeing delete at the same level, neither belongs at that level though 
both can be useful when properly encapsulated.


-- 
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Francis Glassborow]

In message <ihaqev4k1284pakkphngf44tus5js1tdfb@4ax.com>, John Potter 
<jpotter@falcon.lhup.edu> writes
> > Come on, I can write better code than that. The main point was that
> > input should be at least validated as appropriate to the type,.
>
>Your article was in the part of the thread talking about uninitialized
>variables.  You claimed that any decent programmer had a way around
>that.  The first line is all that counts and it matches your posted
>code.  The template does not solve the problem no matter how much
>error testing you add.  You still have a desirable uninitialized
>fundamental and can not avoid default construction of udt.  It is
>possible to avoid the problem for udt with a constructor taking a
>stream; however, that does not generalize to a universal template.
>
>Not a question of the quality of your code.  Just a guess that it had
>nothing to do with the subject.  QED.

Yes, as you point out, I missed the point. The title to the thread is 
unhelpful and it has split into several sub-threads which makes it 
difficult to remember the context in which source code is offered. I 
suspect that I am not the only reader to loose track.

However note that I strongly advocate that operator >> for streams be 
regarded with as much suspicion as delete. Both should be suitably 
encapsulated.


-- 
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

Terje Sletteb� <tslettebo@chello.no.nospam> wrote in message
news:<iPDGa.11691$KF1.273533@amstwist00>...

> Anyway, this may be a QoI issue. A compiler could warn if an
> uninitialised variable is read from, and they typically do.

They can't always tell; C++ doesn't distinguish between out and inout
parameters, so if you write:

    extern void f( int& ) ;

    void
    g()
    {
        int i ;
        f( i ) ;            //  Will i be read from before init, or not?
        //  ...
    }

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

brangdon@cix.co.uk (Dave Harris) wrote in message
news:<memo.20030614124013.37883A@brangdon.madasafish.com>...
> ron@sensor.com (Ron Natalie) wrote (abridged):
> >      int i;                // initialize to 0
> >      stream >> i;

> >      auto int i;        // recycle auto to mean uninitialized.
> >      stream >> i;

> > In the above case existing code that used the unqualified name would
> > work in old and new compilers (with a slight performance hit in the
> > new complier), those in the second case would work the same way in
> > the old and new compiler (the same way it used to).

> A good optimiser could emit the same code in both cases.

But only because it is allowed to have special knowledge of
std::istream.  If you are dealing with a user defined stream, it can't.

> The value zero is never read, so never needs to be written.

But if operator>>( MyStream&, int& ) is in another translation unit, how
can the compiler know this?

> The compiler could figure this out either from the source (eg if
> stream is from a template) or from knowing the semantics of the std
> library (if stream is from the std). Cases where zero- initialisation
> cannot be optimised away are fairly rare - although sometimes
> important when they do arise.

> If we actually need zeros, it may be more efficient to let the
> compiler provide them. For example, with an instance of a deep class
> hierarchy, the compiler can zero-initialise all of the instance
> variables with a single memset(), instead of every class needing its
> own set of assignments.

> Indeed, it can make sense to push the nulling even further back, and
> have a "nulled heap". Then the system can do the work of writing nulls
> during its idle time.

I've long thought that a useful optimization for a compiler would be to
work out the image of the local variables after initialization, generate
a static block with the same image, and replace the initialization code
by a memcpy.  For C, I'm sure this would help; for C++, where
initialisation in normally in the form of constructors (defined in other
translation units), I'm less convinced.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

brangdon@cix.co.uk (Dave Harris) wrote in message
news:<memo.20030613191305.38347A@brangdon.madasafish.com>...
> jimmaureenrogers@att.net (James Rogers) wrote (abridged):
>  > If your suggestion was adopted, how would it affect existing
>  > programs?

> Some currently non-portable ones would become well-behaved.

>  > why would you ever *want* uninitialized variables?

> Mainly for speed. We would want to be able to say, eg,
>      std::vector<int> vec( 1000000, unitialised );

> to avoid writing a million zeros. Which I suspect makes it a
> non-trivial language change. What is the type of "initialised"?

Hmmm.  Either you write a million zeros, or you write a million words
with junk.  Either way, the actual execution time will not change on
typical machines.

On the other hand, I could imagine unitialised as a special type (an
enum), which told std::vector NOT to call the copy constructor on each
element.  In which case, what happens if I write:

    std::vector< std::string > vec( 1000000, uninitialized ) ;

?

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message
news:<zILn+0PDHXMh@eisner.encompasserve.org>...
> In article <d6652001.0306120418.37a97d1c@posting.google.com>,
> kanze@gabi-soft.fr writes:
> > James Rogers <jimmaureenrogers@att.net> wrote in message
> > news:<Xns9396BDBB14558jimmaureenrogers@204.127.36.1>...

> >> Since this was cross-posted to comp.lang.ada I think it is fair to
> >> mention that there is a language that meets your description above.
> >> That language is Ada.

> > Permit me to be sceptical. If your claim is that Ada has more of the
> > safe defaults than C++, I doubt anyone would dare argue it. If your
> > claim is even that most of the defaults are the safe version, from
> > what little I know of the language, it would seem true. But to say
> > that in 1983, they got everything right, including problems that
> > weren't even understood until significantly later. Well, I'm
> > sceptical. Perfection just isn't of this world.

> > One point where I'm pretty sure Ada 83 didn't have the right default
> > (although they may have fixed it in Ada 95): garbage collection.
> > While there are places where it is necessary to turn garbage
> > collection off (which seriously limits the use of a language in
> > which you cannot have untraced pointers, which the garbage collector
> > cannot see), the safe option is obviously to have it on by default,
> > no?

> Perhaps it depends on what one means by the word "safe" :-),

The easier it is to write robust code with the language, the safer it
is. 

> but even with Ada 95 provision of any garbage collection is up to the
> compiler vendor. Since the language definition does not mandate
> garbage collection, it cannot very well mandate that it be defaulted
> on or defaulted off.

> Does the C++ standard mandate garbage collection be on or off ?

Formally, the C++ standard says nothing about garbage collection.
Formally, there are one or two things in the C++ standard that make
garbage collection impossible.  Practically, those things aren't used,
and an implementation could (and some, like Sun Forte, do) offer garbage
collection as an option.

I know that in many cases, garbage collection isn't an option.  This is
probably particularly true in the type of applications where Ada is most
used (although it isn't the case of the uses of Ada I'm familiar with).
Still, it is the safer option; IMHO, it should be on by default, but
with options to turn it off.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]


"Terje Sletteb�" <tslettebo@chello.no.nospam> wrote in message news:iPDGa.11691$KF1.273533@amstwist00...

> Anyway, this may be a QoI issue. A compiler could warn if an
> uninitialised variable is read from, and they typically do.
>
>
It is not a QoI issue.   The above was a trivial case to counter a previous
poster.   The compiler is NOT able to tell in general (for example, POD elements
in a dynamically allocated class).   It's an egregious violation of the C++ object
model to just forget to perform default initialization.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5527 bytes --]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:<3EEB5633.70107@attbi.com>...
> Mike Silva wrote:
> > kanze@gabi-soft.fr wrote in message
> > news:<d6652001.0306120418.37a97d1c@posting.google.com>...

> >  > One point where I'm pretty sure Ada 83 didn't have the right
> >  > default (although they may have fixed it in Ada 95): garbage
> >  > collection.  While there are places where it is necessary to turn
> >  > garbage collection off (which seriously limits the use of a
> >  > language in which you cannot have untraced pointers, which the
> >  > garbage collector cannot see), the safe option is obviously to
> >  > have it on by default, no?

> > I've read that Ada customers don't ask for garbage collection,
> > because in typical Ada applications (safety-critical, hard realtime
> > embedded) dynamic allocation is simply not acceptable.

I'm sure that there are applications where garbage collection is not
acceptable.  They may even be the majority of Ada applications.  But the
fact remains that garbage collection is the "safe" option, and so
according to the premise that the defaults should always be the "safe"
options, garbage collection should be on by default.

> Hmmm...  I'd rather say that for 99% of what garbage collection is
> needed for in other languages, in Ada it is easy enough to avoid
> creating the garbage in the first place.  Most objects are created on
> the stack instead of the heap, so no garbage collection is required.
> For strings, one of the major causes of garbage in C and C++, the
> package Ada.Strings.Unbounded provides an arbitrary length string type
> with the requirement in RM A.4.5(88): "No storage associated with an
> Unbounded_String object shall be lost upon assignment or scope exit."

Which other languages?  What you've just said above describes C++
perfectly.

> If you really need true garbage collection, there is also the ability
> to define a storage pool (see RM13.11 Storage Management) which has
> full garbage collection.  I think in Ada0Y there will probably be
> three packages which provide non-default storage pools with
> mark-release and full garbage collection.  Using them will require
> withing the appropriate package (and possibly instantiating a generic
> or calling a procedure to set the pool size depending on the approach
> selected.

>  From then on, all you need to do to get garbage collection for a type
> is add an attribute_definition_clause for the access type:

> for T'Storage_Pool use Garbage_Collection;

> Why three packages?  There is a major advantage to having all the
> objects in a collection the same size.  So there will probably be two
> garbage collection storage pools, one where the size of all objects
> allocated from the pool is set when the pool is created, and one where
> the size of an object is set at allocation time.

So you have additional standard library support for special cases.  You
can do the same in C++ (I do, from time to time), but you have to do it
by hand.  Generally speaking, for the types of applications I've worked
on recently, it hasn't been appropriate, but for some of the types I've
worked on in the distant past, it would have been.

> As you can see, storage pools in Ada allow the programmer to mix many
> types of storage management, and not have the actual code which
> creates (and/or destroys) objects cluttered up with storage management
> code.  This is, as far as I am concerned, a wonderful feature of Ada.

This is all nice and fine if you need it.  The advantage of garbage
collection is that usually, it just does the right thing (or at least,
something perfectly acceptable) without any programmer intervention.
(For memory management, of course.  Lifetime of object issues still
cannot be completely ignored.)

> You can, for example have full garbage collection for some complex
> type, while in time critical sections of code you can avoid triggering
> garbage collection.  Remember garbage collection is associated with an
> access type, and not with the type of the actual data object.  So you
> can have

> function My_Device_Driver(...) return Data;

> where no garbage collection or storage management can occur, and call
> it in an allocator:

> Some_Pointer := new Data'(My_Device_Driver(...));

> Which may trigger garbage collection, but after the object value has
> been created and outside any time critical regions of code. You can
> even, if you have the need, have multiple access types with different
> storage management policies for the same data type. ;-)

The garbage collections I've heard about for C++ don't trigger at random
times either.  They will trigger when you attempt to allocate, or you
can explicity trigger them, but they won't trigger just for the fun of
it.

> So as far as I am concerned, in Ada(95) all the garbage collection you
> may ever need is "in there."  And the defaults (no garbage collection,
> heap management for Ada.Strings.Unbounded.) are correct.

According to what criteria?  The default may be the most useful for the
application domains where Ada is used, but it isn't the safest.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: Garbage Collector [Was: C bug of the day]

[Robert A Duff]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Question is: did anybody ever do it? How difficult would it be to write a
> true garbage collector as "plug in" storrage pool into an existing Ada?

Ada's storage pools are very useful for writing custom allocation
algorithms, for use with by-hand allocation and deallocation.
However, I don't think they're much in help in writing a "true" garbage
collector.

By "true" GC, I presume you mean a tracing GC, with no explicit help
from the mutator.  A GC needs to know which fields of each record are
pointers.  The compiler knows that, but the storage pool type does not.

Also, in order to tell which objects in a given storage pool are
garbage, you have to know about all the pointers into that pool from
outside -- from other pools, from the stack, and from statically
allocated memory.  The storage pool doesn't help there.

Unless you're talking about so-called "conservative" garbage collection,
in which case you can use existing ones (see Boehm).

In general, a good garbage collector requires cooperation from the
compiler.  Even a so-called "conservative" GC requires that the compiler
avoid certain "tricky" optimizations.

- Bob

P.S. If you're interested in GC, you should read the excellent Jones and
Lins book on the subject.

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Randy Brukardt]

Gautier Write-only wrote in message <3EEE464A.D48A8E2D@somewhere.nil>...
>Dale Stanbrough:
>> as well as moving the generic I/O packages into child packages.
>
>It is an aesthetic issue (although, who cares ?), not a performance
>one... Do such non-instanciated generic sub-packages even appear in
>the machine-code in object files, on any compilation system ?


They do if they were compiled for generic code sharing. And those
packages are the best reason for generic code sharing (they're a lot
more likely to be instantiated multiple times in a program than some
user generic). So, they do have a code footprint in Janus/Ada, and I
suspect as well in some other compilers.

           Randy.

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Dale Stanbrough]

Gautier Write-only wrote:

> Dale Stanbrough:
> 
> > Everyone laments the slowness of Text_IO,
> 
> Who ? Who ?

Are you an owl? I'm sure one "who?" would do.

Ok, it was a bit of hyperbole. -I- don't like the slowness of Text_IO :-)

Robert Dewar at one point noted that the presence of these extra
"features" prevents certain optimisations in the coding from taking
place.

One quote from him...


"Text_IO is convenient for small scale or occasional use for small
 amounts of formatted output (compare it to ACCEPT and DISPLAY use
 in COBOL). It is not the appropriate interface for large scale I/O
 where performance is critical."


try also...

http://groups.google.com.au/groups?q=robert+dewar+text_io+efficiency+grou
p:comp.lang.ada&hl=en&lr=&ie=UTF-8&group=comp.lang.ada&selm=3id0ip%24e42%
40gnat.cs.nyu.edu&rnum=2

Why not -make- it suitable for large scale I/O? Why not ensure that
everyone who wants to do some I/O doesn't have the thought in the 
back of their head "shouldn't really use text_io because it doesn't
scale".


> Are you sure that *this* takes much time ? Did you do a profiling ?

No, but I believe what Robert Dewar said. It makes me hesitant to 
recommend people code with Text_IO, which is problematic. It should
be possible to have one I/O package which is good, and people feel
will be able to grow with their application.


> > as well as moving the generic I/O packages into child packages.
> 
> It is an aesthetic issue (although, who cares ?), not a performance
> one... Do such non-instanciated generic sub-packages even appear in
> the machine-code in object files, on any compilation system ?

See Randy's followup. I didn't realise it was a problem efficieny wise,
but i've always found it an annoyance when teaching Ada to students.
It's much easier to talk about child packages than encapsulated packages.

Dale

Re: Garbage Collector [Was: C bug of the day]

[Robert I. Eachus]

Robert A Duff wrote:

> Also, in order to tell which objects in a given storage pool are
> garbage, you have to know about all the pointers into that pool from
> outside -- from other pools, from the stack, and from statically
> allocated memory.  The storage pool doesn't help there.
> 
> Unless you're talking about so-called "conservative" garbage collection,
> in which case you can use existing ones (see Boehm).
> 
> In general, a good garbage collector requires cooperation from the
> compiler.  Even a so-called "conservative" GC requires that the compiler
> avoid certain "tricky" optimizations.

There are two issues here.   First, if you want to build a "full" 
garbage collector, it needs to be compiler specific.  Martin proposed a 
GNAT specific GC, so that is covered.  Yes, new compiler versions might 
require updating the GC package.  So it would be a good idea to 
contribute the package, and get it distributed with the GNAT compiler.

The argument about "knowing" where the pointers are is to me, 
irrelevant.  As far as I am concerned, a garbarge collection package for 
any compiler would require the compiler recognize that the storage pool 
required a special type of pointer.  (Assume for the moment that their 
is a compiler specific pragma to use these special pointers, and of 
course the pragma argument is the storage pool, and it should be in the 
package that creates the storage pool type.)

So the work required to implement a garbage collecter breaks into two 
parts (well three) parts:  Decide what kind of special pointer is 
required.  If I were doing it, I'd make the pointer, excuse me, access 
type class be a controlled type, and have the finalization operations 
keep a list of all the current pointer locations.  Second, modify GNAT 
to support the special pointer type, and third implement the garbage 
collector.

As I see it, the advantage of using a controlled access type would be 
that all the grody stuff could be "hidden" there, and the actual values 
would not need to be any larger than standard pointers.  (But every copy 
of a pointer would create a new entry in the management table, when the 
table fills up--or the storage pool--garbage collection gets triggered.)

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Georg Bauhaus]

Dale Stanbrough <dstanbro@bigpond.net.au> wrote:
: Gautier Write-only wrote:
: 
:> Dale Stanbrough:
:> 
:> > Everyone laments the slowness of Text_IO,
:> 
:> Who ? Who ?
: 
: Are you an owl? I'm sure one "who?" would do.
: 
: Ok, it was a bit of hyperbole. -I- don't like the slowness of Text_IO :-)
: 
: Robert Dewar at one point noted that the presence of these extra
: "features" prevents certain optimisations in the coding from taking
: place.
: 
: One quote from him...
: 
: 
: "Text_IO is convenient for small scale or occasional use for small
: amounts of formatted output (compare it to ACCEPT and DISPLAY use
: in COBOL). It is not the appropriate interface for large scale I/O
: where performance is critical."

What's wrong with streams?


Georg

Re: C bug of the day

[Andy Sawyer]

In article <zILn+0PDHXMh@eisner.encompasserve.org>,
  on 12 Jun 2003 20:39:38 -0400,
  Kilgallen@SpamCop.net (Larry Kilgallen) wrote:

 > The typical Ada expert believes in code review, formal inspection,
 > fault analysis, project specification and many other activities that
 > would be useless if there were a perfect programming language.

None of these activities would be useless if there were a perfect
programming language.

Regards,
  Andy
-- 
"Light thinks it travels faster than anything but it is wrong. No matter
  how fast light travels it finds the darkness has always got there first,
  and is waiting for it."                  -- Terry Pratchett, Reaper Man

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Larry Kilgallen]

In article <d6652001.0306160158.8f93aab@posting.google.com>, kanze@gabi-soft.fr writes:
 > brangdon@cix.co.uk (Dave Harris) wrote in message
 > news:<memo.20030613191305.38347A@brangdon.madasafish.com>...
 >> jimmaureenrogers@att.net (James Rogers) wrote (abridged):

 >>  > why would you ever *want* uninitialized variables?
 >
 >> Mainly for speed. We would want to be able to say, eg,
 >>      std::vector<int> vec( 1000000, unitialised );
 >
 >> to avoid writing a million zeros. Which I suspect makes it a
 >> non-trivial language change. What is the type of "initialised"?
 >
 > Hmmm.  Either you write a million zeros, or you write a million words
 > with junk.  Either way, the actual execution time will not change on
 > typical machines.

Certainly an operating system can map arbitrary existing memory pages
into a particular chunk of virtual address space.  The only reason to
expect them to be zeroed or not based on operating system interests
would be confidentiality of the data formerly on those pages of memory.

VMS has "demand zero" pages that provide zeroed pages only on the first
access to the page.  I don't know if typical compilers are smart enough
to use that feature on arrays explicitly initialized to zero.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Larry Kilgallen]

In article <dstanbro-3418E9.11564717062003@mec2.bigpond.net.au>, Dale Stanbrough <dstanbro@bigpond.net.au> writes:
> Gautier Write-only wrote:
> 
>> Dale Stanbrough:
>> 
>> > Everyone laments the slowness of Text_IO,
>> 
>> Who ? Who ?
> 
> Are you an owl? I'm sure one "who?" would do.
> 
> Ok, it was a bit of hyperbole. -I- don't like the slowness of Text_IO :-)

Could that be due to your compiler and operating system ?

The record-oriented nature of Text_IO seems to match nicely the features
of RMS on VMS.  Personally the only Ada compiler from which I have used
it is VAX/DEC/Compaq Ada.

> "Text_IO is convenient for small scale or occasional use for small
>  amounts of formatted output (compare it to ACCEPT and DISPLAY use
>  in COBOL). It is not the appropriate interface for large scale I/O
>  where performance is critical."

> Why not -make- it suitable for large scale I/O? Why not ensure that
> everyone who wants to do some I/O doesn't have the thought in the 
> back of their head "shouldn't really use text_io because it doesn't
> scale".

Really large scale IO should not use a line-oriented package.  In fact
even $QIO is inadequate and one should use $IO_PERFORM, which requires
at least ASTs for efficiency and might require Ada tasking.  So some
solution which works for one operating system would not work for others.

So your particular situation might require better performance, but how
much better and how to achieve it is going to be quite OS-specific.

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Dale Stanbrough]

Georg Bauhaus wrote:

> What's wrong with streams?

Streams seem to be at the wrong level of abstraction.
If you want to write out text files from an Ada program, how you 
do you an end of line character portably using streams?

In text_io you just do new_line. In streams -which- character,
or pair of characters do you output?
Similarly for reading a text file. If I use streams I have to
include code for the possible different end of line terminators.

Processing text files in text_io is really very simple stuff, and
easy to read (and it could be better if there were a function
get_line...). I'm not sure that Streams would make for easy reading,
unless it gets layered with a host independent Text_IO like feature
(perhaps we could call it Ada.Next_IO ? :-)


Dale

Re: Replacement for Text_IO? (was Re: C bug of the day)

[Larry Kilgallen]

In article <dstanbro-69939B.21425517062003@mec2.bigpond.net.au>, Dale Stanbrough <dstanbro@bigpond.net.au> writes:
> Georg Bauhaus wrote:
> 
>> What's wrong with streams?
> 
> Streams seem to be at the wrong level of abstraction.
> If you want to write out text files from an Ada program, how you 
> do you an end of line character portably using streams?

If you want to do _portable_ text IO, you should not make the mistake
of thinking that the end of line is represented by a character.

> Processing text files in text_io is really very simple stuff, and
> easy to read (and it could be better if there were a function
> get_line...). I'm not sure that Streams would make for easy reading,
> unless it gets layered with a host independent Text_IO like feature
> (perhaps we could call it Ada.Next_IO ? :-)

If it were host-independent, the resulting files would not be compatible
with other programming languages on some platforms.

Re: C bug of the day

[Dave Harris]

kanze@gabi-soft.fr () wrote (abridged):
> But if operator>>( MyStream&, int& ) is in another translation
> unit, how can the compiler know this?

Was this question not answered by the very next paragraph you quote:

> > The compiler could figure this out either from the source (eg if
> > stream is from a template) or from knowing the semantics of the
> > std library (if stream is from the std).

If the function definition isn't available (eg not inline or a
template) and not part of the standard, then of course the compiler
can't do the optimisation.

(Often that will mean the benefit of the optimisation would be
swamped by procedural call costs anyway.)

-- Dave Harris, Nottingham, UK

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Terje Slettebø]

<kanze@gabi-soft.fr> wrote in message
news:d6652001.0306160216.59fa74d6@posting.google.com...
>
> I know that in many cases, garbage collection isn't an option.  This
is
> probably particularly true in the type of applications where Ada is
most
> used (although it isn't the case of the uses of Ada I'm familiar
with).
> Still, it is the safer option; IMHO, it should be on by default, but
> with options to turn it off.

One thing I haven't seen mentioned in this thread is that it appears
that some think that if you have garbage collection, you won't have to
do memory management. It's true that you can't completely leak memory,
but you can still get the effect of memory leak, resulting from large
structures still having a reference to them, but which are otherwise
unused.

This has also resulted in a host of new kinds of references for dealing
with it, such as weak, soft and phantom references (in Java). Memory
leak-like conditions also have expressions like lapsed listener,
lingerers, laggards and limbo.

Garbage collection just changes the problems you meet to something else,
and not necessarily easier. Garbage collection might make it harder to
manage resources, not easier.

Besides, memory is just one kind of resource, and GC does nothing for
other kinds. For languages without stack-allocated objects, like Java,
you can't use RAII in its usual form, either (use of
constructor/destructor). Instead, you have to resort to
try-catch-finally, which can lead to spaghetti code, if you have several
objects to clean up this way.


Regards,

Terje

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Ludovic Brenta]

Andy Sawyer <andys@despammed.com> writes:

> In article <zILn+0PDHXMh@eisner.encompasserve.org>,
>   Kilgallen@SpamCop.net (Larry Kilgallen) wrote:
> 
>  > The typical Ada expert believes in code review, formal inspection,
>  > fault analysis, project specification and many other activities that
>  > would be useless if there were a perfect programming language.
> 
> None of these activities would be useless if there were a perfect
> programming language.

I agree.  A perfect programming language would not be enough, one
would also need perfect programmers :)

-- 
Ludovic Brenta.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5046 bytes --]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:<jhPtsFBx6F7+EwOv@robinton.demon.co.uk>...
> In message <CnRGa.11791$KF1.273607@amstwist00>, Terje Sletteb�
> <tslettebo@chello.no.nospam> writes

> >I would be interested to know how read() is implemented. Could you
> >posted it?

> Well for what they are worth here is the complete set of overloaded
> function templates

> Comments for improving them are very welcome.

> // These templates provide safe input for any type that supports
> // operator>>

> // 1) from console with prompt

>         template<typename in_type>
>         in_type read(std::string const & prompt, int max_tries = 3){
>                 in_type temp;
>                 int tries(0);
>                 while(tries++ != max_tries ){
>                         std::cout << prompt;
>                         std::cin >> temp;
>                         if(std::cin.good()) return temp;
>                         std::cin.clear();       // if it has failed,
> reset it to normal
>                         while(cin.get() != '\n'); flush stream

I'm sure you meant to have a //  before the last two words:-).  And an
std:: before cin.

Also, although it is only a question of style, I would never write an
empty loop with just a ';' hidden on the same line as the while.

>                         std::cout << "\n That input was incorrect, try
> again: \n";
>                 }
>                 throw fgw::problem("Too many attempts to read data.");
>         }

I get an endless loop with this one.  Using g++ 3.2.2, under Solaris
2.8, I instantiating it with:

    int in( read< int >( "value: " ) ) ;

I entered "123", then control-D.  Valid input for an int, I believe, so
I shouldn't have looped at all.  (For those unfamiliar with Unix,
control-D causes an end of file on keyboard input.)

There are actually two errors (in addition to the typos in the line with
the while):

    if ( std::cin.good() ) return temp ;

The function good() takes the eofbit into consideration.  It is thus
completely worthless and unusable.  (Almost: if good() returns false,
you know that future input will fail.  You know nothing about past
input.  And if good() returns true, you know nothing, period.)  The
correct idiom here would be:

    if ( std::cin ) return temp ;

The second problem is with:

    while ( cin.get() != '\n' ) ...

if end of file or any error occurs, you have an endless loop.  As an
unrepentant Pascal programmer, I would write:

    while ( std::cin.peek() != EOF && std::cin.peek() != '\n') ...

More typical C++ idioms might be:

    char                ch ;
    while ( cin.get( ch ) && ch != '\n' ) ...

or:

    int                 ch ;
    while ( (ch = cin.get()) != EOF && ch != '\n' ) ...

or, if you don't like uninitialized variables (as I don't):

    for ( int ch = cin.get() ; 
              ch != EOF && ch != '\n' ; 
              ch = cin.get() ) ...

> // 2) version without prompt, defaults to colon space prompt
>         template<typename in_type>
>         in_type read(int max_tries=3){
>                 return read<in_type>(": ", max_tries);
>         }

> // 3) version for general input stream, throws an exception if fails
>         template<typename in_type>
>                 in_type read(std::istream & in){
>                         in_type temp;
>                         in >> temp;
>                         if(in.good()) return temp;
>                         if(in.eof()) throw fgw::problem("Tried to read
> past end of file"); // handle end of file as special case
>                         in.clear();  // reset input stream
>                         throw fgw::problem("Corrupted data stream.");
>                 }

And this has the same problem as the preceding: it "fails" for valid
input if the type requires look-ahead (most types do) and the input is
not followed by any white space character.

While the typos and the endless loop in the first bit of code are just
oversights, and could happen to anyone, the misuse of the function is
interesting.  It's not as if you are a beginner, who just looked for a
function with a likely name.  You're quite familiar with the behavior of
iostream.  I'd consider this an embarassing point in the standard, and
something worth correcting if someone can figure out how without
breaking existing code.

(BTW: I don't have anything similar.  I've never felt it necessary --
it's very rare that I will want to initialize a variable from a stream,
except in small, parser functions.  Like what you offer here.  And I
would consider myself a little more than just halfway competent.)

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Larry Kilgallen]

In article <k7blhiy5.fsf@ender.evo6.com>, Andy Sawyer <andys@despammed.com> writes:
> In article <zILn+0PDHXMh@eisner.encompasserve.org>,
>   on 12 Jun 2003 20:39:38 -0400,
>   Kilgallen@SpamCop.net (Larry Kilgallen) wrote:
> 
>  > The typical Ada expert believes in code review, formal inspection,
>  > fault analysis, project specification and many other activities that
>  > would be useless if there were a perfect programming language.
> 
> None of these activities would be useless if there were a perfect
> programming language.

What use would they have ?  The perfect programming language, unlike
Ada or C* would find human logic errors and specification faults !

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Wesley Groleau]

> and not necessarily easier. Garbage collection might make it harder to
> manage resources, not easier.

It also makes it easier to not think about it,
and continue not thinking about it until you
find out the hard way in some case that you
should have thought about it.

> Besides, memory is just one kind of resource, and GC does nothing for
> other kinds. ....

Like: closing files, decrementing usage counts,
flushing file buffers and cached data,
commiting or cancelling database transactions, ...

That's what's nice about Ada controlled types.
You can use them for anything with mandatory finalization,
not just GC.  I suppose C++ destructors could do the same.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Hyman Rosen]

Wesley Groleau wrote:
> That's what's nice about Ada controlled types.
> You can use them for anything with mandatory finalization,
> not just GC.  I suppose C++ destructors could do the same.

Of course, and much more easily, since C++ destructors do not
require inheritance from a special class like Ada's controlled
types, and classes with destructors can be declared in any
scope, not just at library level.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Preben Randhol]

Larry Kilgallen wrote:
> In article <k7blhiy5.fsf@ender.evo6.com>, Andy Sawyer <andys@despammed.com> writes:
>> None of these activities would be useless if there were a perfect
>> programming language.
> 
> What use would they have ?  The perfect programming language, unlike
> Ada or C* would find human logic errors and specification faults !

The perfect programming language would do the programming for you ;-)

Preben
-- 
"When Roman engineers built a bridge, they had to stand under it while
 the first legion  marched across.  If programmers today  worked under
 similar  ground rules,  they might well find  themselves getting much
 more interested in Ada!"                              -- Robert Dewar

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Vinzent Hoefler]

Hyman Rosen wrote:

>Of course, and much more easily, since C++ destructors do not
>require inheritance from a special class like Ada's controlled
>types, and classes with destructors can be declared in any
>scope, not just at library level.

And the destructor is called even in case of an exception?


Vinzent.

Re: C bug of the day

[Hyman Rosen]

Vinzent Hoefler wrote:
> And the destructor is called even in case of an exception?

Yes, of course.

Re: C bug of the day

[Andy Sawyer]

In article <gWZCytwq7Zqs@eisner.encompasserve.org>,
  on 17 Jun 2003 13:52:03 -0400,
  Kilgallen@SpamCop.net (Larry Kilgallen) wrote:

 > In article <k7blhiy5.fsf@ender.evo6.com>, Andy Sawyer
 > <andys@despammed.com> writes:
 > > In article <zILn+0PDHXMh@eisner.encompasserve.org>,
 > >   on 12 Jun 2003 20:39:38 -0400,
 > >   Kilgallen@SpamCop.net (Larry Kilgallen) wrote:
 > >
 > >  > The typical Ada expert believes in code review, formal inspection,
 > >  > fault analysis, project specification and many other activities that
 > >  > would be useless if there were a perfect programming language.
 > >
 > > None of these activities would be useless if there were a perfect
 > > programming language.
 >
 > What use would they have ?  The perfect programming language, unlike
 > Ada or C* would find human logic errors and specification faults !

They'd give the programmers something to do while your perfect
programming language was fixing all those errors and faults...

-- 
"Light thinks it travels faster than anything but it is wrong. No matter
  how fast light travels it finds the darkness has always got there first,
  and is waiting for it."                  -- Terry Pratchett, Reaper Man

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[John Potter]

On 17 Jun 2003 13:51:19 -0400, kanze@gabi-soft.fr wrote:

 > The second problem is with:

 >     while ( cin.get() != '\n' ) ...

 > if end of file or any error occurs, you have an endless loop.  As an
 > unrepentant Pascal programmer, I would write:

 >     while ( std::cin.peek() != EOF && std::cin.peek() != '\n') ...

;-)

 > More typical C++ idioms might be:

 >     char                ch ;
 >     while ( cin.get( ch ) && ch != '\n' ) ...

 > or:

 >     int                 ch ;
 >     while ( (ch = cin.get()) != EOF && ch != '\n' ) ...

 > or, if you don't like uninitialized variables (as I don't):

 >     for ( int ch = cin.get() ;
 >               ch != EOF && ch != '\n' ;
 >               ch = cin.get() ) ...

Nice.  Or

    cin.ignore(INT_MAX, '\n');


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

Wesley Groleau <wesgroleau@despammed.com> wrote in message
news:<ZwSdnYSE3NcO13KjXTWJig@gbronline.com>...
> > and not necessarily easier. Garbage collection might make it harder
> > to manage resources, not easier.

> It also makes it easier to not think about it, and continue not
> thinking about it until you find out the hard way in some case that
> you should have thought about it.

That's true for just about any tool that makes programming easier:-).

Garbage collection is a tool.  It makes life simpler, and safer, for the
programmer.  You might say that garbage collection is to memory
management what a high level language is to coding.  Neither free you
from having to consider the issues at the design stage, but once your
design is clean, and the issues addressed, the implementation is
significantly easier to get right with the modern tool.

> > Besides, memory is just one kind of resource, and GC does nothing
> > for other kinds. ....

> Like: closing files, decrementing usage counts,
> flushing file buffers and cached data,
> commiting or cancelling database transactions, ...

There is a major difference between these "resources" and memory.  They
generally can't (or shouldn't) be deferred.  The act of "freeing" the
resource has side effects which are pertinent to the observable behavior
of the program.

> That's what's nice about Ada controlled types. You can use them for
> anything with mandatory finalization, not just GC. I suppose C++
> destructors could do the same.

I don't know about controlled types, so I can't say, but it sounds like
it.  Is the finalization called at a defined moment?

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Balog Pal]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9398BD1E07E3Ejimmaureenrogers@204.127.36.1...

> I am sorry. I misunderstood. I thought you were being sarcastic.
> If your suggestion was adopted, how would it affect existing
> programs? For that matter, why would you ever *want* uninitialized
> variables? Another way to ask that is when is initialization a bad
> thing?

In a C-like langage it's good to have option to not initialise something
(right where it's created). When you write stuff that is time-sensitive
unneeded memory access is bad.

The problem is not with existance of that feature but its being the default.
A dengerous and rarely needed feature should be an 'I explicitly ask for'
thing.

Example to noinit is a case where you need a variable only on certain path
of execution. On that path it is inited and used, the others do not touch
it.   There are cases you don't put the whole path in a single if.
Another example is when you grab a local buffer char[64k]. And wrute some
small amount of data into it. Or immediately load it with data from
somewhere. Default initing the whole is just a waste of time.

Paul



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Balog Pal]

"Ron Natalie" <ron@sensor.com> wrote in message
news:Fn2dnUzrDqr3YXSjXTWQlg@giganews.com...

>      auto int i;        // recycle auto to mean uninitialized.
>      stream >> i;
>
> In the above case existing code that used the unqualified name would work
in old and new compilers
> (with a slight performance hit in the new complier), those in the second
case would work the same way
> in the old and new compiler (the same way it used to).

That looks great, but doesn't cover important cases.   Those important to me
at least.

I'm tired of not having default-initing ctors.   Every now and again I find
misbehavior of some object due to a new member introduced, then not inited
to anything in the constructor.

I'm also tired of writing redundant ctors et al -- instead of simple
directing the compiler to do it automagically.

Paul



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[James Rogers]

kanze@gabi-soft.fr wrote in
news:d6652001.0306180239.2b9672c8@posting.google.com: 

> 
> I don't know about controlled types, so I can't say, but it sounds
> like it.  Is the finalization called at a defined moment?

Finalization is called at defined moments.

Every object is finalized before being destroyed (for example, by
leaving a 
subprogram_body containing an object_declaration, or by a call to an 
instance of Unchecked_Deallocation). 

Finalization also occurs as one step in an assignment operation:

For an assignment_statement, after the name and expression have been 
evaluated, and any conversion (including constraint checking) has been 
done, an anonymous object is created, and the value is assigned into it;

that is, the assignment operation is applied. (Assignment includes value

adjustment.) The target of the assignment_statement is then finalized.
The 
value of the anonymous object is then assigned into the target of the 
assignment_statement. Finally, the anonymous object is finalized. 

Jim Rogers

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Wesley Groleau]

> I don't know about controlled types, so I can't say, but it sounds
like
> it.  Is the finalization called at a defined moment?

Yes. At the point or moment that it leaves scope,
i.e., can no longer be referred to.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Dmitry A. Kazakov]

Hyman Rosen wrote:

 > Wesley Groleau wrote:
 >> That's what's nice about Ada controlled types.
 >> You can use them for anything with mandatory finalization,
 >> not just GC.  I suppose C++ destructors could do the same.
 >
 > Of course, and much more easily, since C++ destructors do not
 > require inheritance from a special class like Ada's controlled
 > types,

They do require "inheritance". That special controlled type is called
"class" in C++. You cannot have a destructor for, say, "char *" (you cannot
even derive from it).

So there is practically no difference between Ada and C++ with this respect.

 > and classes with destructors can be declared in any
 > scope, not just at library level.

Yes, this is an important difference. Sometimes (not often) it becomes
painful. However, for years, C++ lives with only "library-level"
subroutines.

There is another difference. The parent destructors are called
automatically. This is the single case, I know, where C++ is safer than
Ada, and Ada is more "flexible" than C++. (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

James Rogers <jimmaureenrogers@att.net> wrote in message
news:<Xns939EC67E738EEjimmaureenrogers@204.127.36.1>...
> kanze@gabi-soft.fr wrote in
> news:d6652001.0306180239.2b9672c8@posting.google.com: 

> > I don't know about controlled types, so I can't say, but it sounds
> > like it. Is the finalization called at a defined moment?

> Finalization is called at defined moments.

> Every object is finalized before being destroyed (for example, by
> leaving a subprogram_body containing an object_declaration, or by a
> call to an instance of Unchecked_Deallocation).

> Finalization also occurs as one step in an assignment operation:

> For an assignment_statement, after the name and expression have been
> evaluated, and any conversion (including constraint checking) has been
> done, an anonymous object is created, and the value is assigned into
> it;

> that is, the assignment operation is applied. (Assignment includes
> value adjustment.) The target of the assignment_statement is then
> finalized. The value of the anonymous object is then assigned into the
> target of the assignment_statement. Finally, the anonymous object is
> finalized.

Interesting.  It sounds like the compiler generated "assignment
operator" does exactly what good assignment operators do in C++.  The
classical idiom in C++ is to copy construct a temporary from the right
hand side (the anonymous object which is created), then swap all of the
fields with the target object, so that the anonymous object has the bit
pattern of the original object, and vice versa.  On leaving the
assignment operator, the anonymous object goes out of scope, which
causes its destructor to be called -- if everything is coded correctly,
this has the effect of "finalizing" whatever the left hand side of the
assignment held before.

Because of the swap, C++ gets by with one finalization less:-).  On the
other hand, because this is a programmer implemented idiom, and the
assignment operator is normally written by the programmer (with the
default being nothing other than a member by member assignment), C++
requires programmers to distinguish between initialization and
assignment -- in initialization, you are given raw memory as a target,
and in assignment, a completely constructed object.  If I understand you
correctly, in Ada, the programmer is never concerned with assignment, as
defined in C++: the compiler generated assignment operator generates
code to use initialization and finalization.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[tmoran]

> classical idiom in C++ is to copy construct a temporary from the right
> hand side (the anonymous object which is created), then swap all of the
> fields with the target object, so that the anonymous object has the bit
> pattern of the original object, and vice versa.  On leaving the
>...
>Because of the swap, C++ gets by with one finalization less:-).  On the
  What if the object is on a linked list with back pointers so that
after the swap the pointers are wrong?  Or if it just contains pointers
to internal parts of itself?

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> They do require "inheritance". That special controlled type is called
> "class" in C++. You cannot have a destructor for, say, "char *" (you cannot
> even derive from it).

No. You cannot write a destructor for 'char *' because that is a system type,
and it already has one. Every built-in type has one. If you want to write a
destructor, it has to be for a type you define. Having to inherit from a
special type to get finalization is especially cumbersome in a language
which does not have multiple inheritance.

Re: C bug of the day

[Jim Rogers]

kanze@gabi-soft.fr wrote in message
news:<d6652001.0306190145.18d4a8c9@posting.google.com>...
> James Rogers <jimmaureenrogers@att.net> wrote in message
> news:<Xns939EC67E738EEjimmaureenrogers@204.127.36.1>...
> If I understand you
> correctly, in Ada, the programmer is never concerned with assignment,
as
> defined in C++: the compiler generated assignment operator generates
> code to use initialization and finalization.

This is true. In Ada assignment is designated to be an operation,
not an operator. There is no way to simply overrride the assignment
operator.

Ada controlled types provide the ability to override finalization,
as has been stated before. They also allow the programmer to
overrride initialization and "adjustment". Overriding adjustment
and initialization provides some of the capabilities of 
overriding assignment in C++.

The "adjustment" procedure is used for such things as incrementing
reference counts. The "finalize" procedure could be used to
decrement reference counts and deallocate an object when its
reference count is 0. 

The basic logic of assignment is unchanged by overriding
initialization, adjustment, and finalization. The specific order
of operations is unchanged. Ada controlled types simply provide
fine grained control over well defined steps in assignment.
Of course, initialization is also called whenever a controlled
object is created. Finalization is called whenever a controlled
object goes out of scope.

Jim Rogers

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Wesley Groleau]

Hyman Rosen wrote:
> Dmitry A. Kazakov wrote:
> 
>> They do require "inheritance". That special controlled type is called
>> "class" in C++. You cannot have a destructor for, say, "char *" (you 
>> cannot
>> even derive from it).
> 
> 
> No. You cannot write a destructor for 'char *' because that is a system 
> type,
> and it already has one. Every built-in type has one. If you want to write a
> destructor, it has to be for a type you define. Having to inherit from a
> special type to get finalization is especially cumbersome in a language
> which does not have multiple inheritance.
> 

Re: C bug of the day

[Robert I. Eachus]

Hyman Rosen wrote:
 > Having to inherit from a special type to get finalization is
 > especially cumbersome in a language which does not have multiple
 > inheritance.

That's probably true, which is why the ability to combine access
discriminants with controlled type mix-ins in Ada is so useful. ;-)
Unfortunately, that only works for limited objects.  You can still add
an access component to the mix-in part of an object to provide
finalization behavoir for the parent, but it is a bit trickier:

with Ada.Finalization.Controlled;
with System.Address_to_Access_Conversion;
generic
   type Parent is tagged private;
    with procedure Initialize (Object : in out Parent);
    with procedure Adjust   (Object : in out Parent);
    with procedure Finalize (Object : in out Parent);
package Controlled_Mixins is

   type Controlled_Part is new Ada.Finalization.Controlled
       with record
     Parent_Access: Addresses.Object_Pointer;
   end record;

   package Addresses is new
              System.Address_to_Access_Conversion(Parent);

   type Child is new Parent with record
     CP: Controlled_Part;
   end record;

private
   procedure Initialize (Object : in out Controlled_Part);
   procedure Adjust   (Object : in out Controlled_Part);
   procedure Finalize (Object : in out Controlled_Part);
end Controlled_Mixins;

The body for this package should be considered as impementation
specific, and is not provided here.  Also it should be obvious that
instantiating this package when type Parent is derived from
Ada.Finialization.Controlled is asking for trouble.  I'd ask for a
generic formal: type Foo is not new Bar; if I didn't think this was a
very special case, and one that normally should be avoided.

Incidently this definitely comes in the "Part 2" class of things you can
do in Ada, but shouldn't.  Instead it is much better to have the parts 
of the object that need finalization wrapped in one or more controlled 
mixins.  That way the mixins are self consistant, and no component is 
reaching up to modify the containing object.  But you can do it.

Re: C bug of the day

[Hyman Rosen]

Robert I. Eachus wrote:
> That's probably true, which is why the ability to combine access
> discriminants with controlled type mix-ins in Ada is so useful. ;-)

Sure, but it means that you're doing the work that MI would be
doing for you.

Re: C bug of the day

[Robert I. Eachus]

Hyman Rosen wrote:

> Sure, but it means that you're doing the work that MI would be
> doing for you.

And I guess our disagreement on that should be considered as personal 
preference.

There are lots of programming "tricks" in Ada that can be encapsulated 
in a page or so of, often, a generic unit.  I regard these programming 
exercises sort of like a pianist who uses tricky sections from various 
works as warm up exercises.

I know that some days my brain is up to doing some quite complex coding 
work, and at other times any line of code I touch will result in a lot 
more work to unwind the changes I made--and the bugs I introduced.

So there are some of these "exercises" that I have rewritten a dozen 
times or more.  On a good day I can dash off these units about as fast 
as I can type, which is in the 35-40 WPM range.  On a bad day, well ANY 
programming I did should be thrown away.  It is the in between days that 
are judgement calls.  Right now I have one nasty piece of 
coding/debugging that is waiting on a very good day.  And it will 
continue to wait for the next day like that, because any effort I put in 
on an average day would be wasted.

Re: C bug of the day

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> They do require "inheritance". That special controlled type is called
>> "class" in C++. You cannot have a destructor for, say, "char *" (you
>> cannot even derive from it).
> 
> No. You cannot write a destructor for 'char *' because that is a system
> type, and it already has one. Every built-in type has one. If you want to
> write a destructor, it has to be for a type you define.

Surely. Destructor is defined for new types. The point is that you cannot 
make a new type from "char *" [in Ada you can but in a limited form]. Thus 
you cannot produce an equivalent of "char *" plus your destructor. You have 
to aggregate it in a class. Which is same as in Ada, where you have to put 
it in a controlled type. So I see no difference here.

> Having to inherit
> from a special type to get finalization is especially cumbersome in a
> language which does not have multiple inheritance.

Oh yes. My point is that a language have to allow:

1. full inheritance from any types. [except, probably, class-wide types]
2. multiple inheritance

Missing 2. in Ada is clearly a design fault. No matter which work-arounds 
(like access discriminants) it provides. Similar problem exists in Ada 
child packages. A package may have only one parent. This also have 
work-arounds and they also as nasty as all work-arounds are.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: C bug of the day

[Wesley Groleau]

 > The "adjustment" procedure is used for such things as incrementing
 > reference counts. The "finalize" procedure could be used to

There are probably a lot of good ways to use Ada "adjust."
One important one is replacing a copy of a pointer with
a pointer to a new copy of the heap object.

This can be recursive, so that in a tree or list or such,
each allocation also "adjusts" any pointers within.

But then what if it's something like a map or graph, where
there may be more than five pointers to the same node?
You'd want one new node with five pointers to it.
Can be done, but it's awkward.  Hoever, not as awkward
as doing the whole deep copy _without_ language assistance.

I presume C++ is substantially equivalent on this issue?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Hyman Rosen]

tmoran@acm.org wrote:
 >   What if the object is on a linked list with back pointers so that
 > after the swap the pointers are wrong?  Or if it just contains pointers
 > to internal parts of itself?

It is the job of the creator of the class to decide whether swap is
appropriate for that class, and if so, what that means, and how to
do it correctly.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Hyman Rosen]

Jim Rogers wrote:
 > Ada controlled types provide the ability to override finalization,
 > as has been stated before. They also allow the programmer to
 > overrride initialization and "adjustment".

One "gotcha" for Ada newbies is that there is no overriding
initialization when assigning an aggregate, presumably on the
grounds that you can build the aggregate to what it would be
after the initialization was through with it. But I think
that this does not cover all the things that one might want
to do in a constructor, and in those cases, you must take
steps to disallow such aggregates.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[kanze]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

tmoran@acm.org wrote in message
news:<N3mIa.721016$Si4.853728@rwcrnsc51.ops.asp.att.net>...
> > classical idiom in C++ is to copy construct a temporary from the
> > right hand side (the anonymous object which is created), then swap
> > all of the fields with the target object, so that the anonymous
> > object has the bit pattern of the original object, and vice versa.
> > On leaving the > >...

> >Because of the swap, C++ gets by with one finalization less:-).  On the

>   What if the object is on a linked list with back pointers so that
> after the swap the pointers are wrong? Or if it just contains pointers
> to internal parts of itself?

It's up to the programmer to make the swap work correctly.  Most of the
time, it isn't a problem -- nobody should have any pointers to the
temporary object in function, for example.  As for the linked list
example, I would imagine that the swap function shouldn't touch the
pointers involved.  The target object remains linked where it was,
regardless of the assignment.

Obviously, this idiom doesn't work well with objects that, for example,
register themselves somewhere (i.e. the constructor "publishes" the
objects addess).  But if my experience is typical, such objects have
identity, and shouldn't be assigned or copied anyway.  About a third of
my C++ classes don't allow assignment at all, for such reasons.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Mark A. Biggar]

Dmitry A. Kazakov wrote:

> 2. multiple inheritance
> 
> Missing 2. in Ada is clearly a design fault.  

Not really, just a realization at the time (92-93) that they couldn't
make too big a change in the language, if they wanted the implementors
to go with the changes to the standard.  MI was considered along with
the current SI model and it was determined that given all the extra
mechanisms needed to solve such problems as the method/field ambiguities
in the diamond inheritance example it was too big a change to the
language.  Note that the language already had most of what what was
needed for SI in derived types so all they had to add was support for
field extension when deriving and a protocol for run-time dispatch.
SI also has a very simple implementation model (the tag field is a
simple pointer to a vtable with constant offsets for method lookup).
But as MI needs to deal with multiple inherited vtables with much more
complicated implementation.

Re: C bug of the day

[Stephen Leake]

kanze@gabi-soft.fr writes:

> Wesley Groleau <wesgroleau@despammed.com> wrote in message
> news:<ZwSdnYSE3NcO13KjXTWJig@gbronline.com>...
> > > and not necessarily easier. Garbage collection might make it
harder
> > > to manage resources, not easier.
> 
> > It also makes it easier to not think about it, and continue not
> > thinking about it until you find out the hard way in some case that
> > you should have thought about it.
> 
> That's true for just about any tool that makes programming easier:-).

I strongly disagree with this generalization. Ada makes programming
easier, but forces me to think about what's important.

> Garbage collection is a tool. It makes life simpler, and safer, for
> the programmer. You might say that garbage collection is to memory
> management what a high level language is to coding. 

Hmm. I would rather say that garbage collection is to memory
management as soft typing is to data structure design; it lets you
easily implement bad designs.

> Neither free you from having to consider the issues at the design
> stage, but once your design is clean, and the issues addressed, the
> implementation is significantly easier to get right with the modern
> tool.

Again, I disagree. It is easier to address memory management with a
properly designed container library than with garbage collection.
Especially in a real-time system, when it is critical to bound every
operation's execution time.

> > > Besides, memory is just one kind of resource, and GC does
> > > nothing for other kinds. ....
> 
> > Like: closing files, decrementing usage counts,
> > flushing file buffers and cached data,
> > commiting or cancelling database transactions, ...
> 
> There is a major difference between these "resources" and memory.
They
> generally can't (or shouldn't) be deferred.  The act of "freeing" the
> resource has side effects which are pertinent to the observable
behavior
> of the program.

True. And for real-time systems, freeing memory should not be deferred
either.

> > That's what's nice about Ada controlled types. You can use them
> > for anything with mandatory finalization, not just GC. I suppose
> > C++ destructors could do the same.
> 
> I don't know about controlled types, so I can't say, but it sounds
like
> it.  Is the finalization called at a defined moment?

Yes, when the object goes out of scope or is deallocated, same as in
C++.

-- 
-- Stephe

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Dmitry A. Kazakov]

Mark A. Biggar wrote:

> Dmitry A. Kazakov wrote:
> 
>> 2. multiple inheritance
>> 
>> Missing 2. in Ada is clearly a design fault.
> 
> Not really, just a realization at the time (92-93) that they couldn't
> make too big a change in the language, if they wanted the implementors
> to go with the changes to the standard.  MI was considered along with
> the current SI model and it was determined that given all the extra
> mechanisms needed to solve such problems as the method/field ambiguities
> in the diamond inheritance example it was too big a change to the
> language.  Note that the language already had most of what what was
> needed for SI in derived types so all they had to add was support for
> field extension when deriving and a protocol for run-time dispatch.
> SI also has a very simple implementation model (the tag field is a
> simple pointer to a vtable with constant offsets for method lookup).
> But as MI needs to deal with multiple inherited vtables with much more
> complicated implementation.

I meant design not as a process, which is IMO very successful in case of 
Ada. But at some point, one should stop and reconsider the basics 
disregarding the history of particular language features. What is good 
about Ada design *process* is that AFAIK no irreparable faults were made. 
It is still possible to add MI and MD to Ada when dust will settle down. 
(:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: C bug of the day

[Florian Weimer]

Hyman Rosen <hyrosen@mail.com> writes:

> One of the trading systems we use in our company had been
> crashing every night for a week while trying to run a
> certain batch procedure. We finally traced the problem to
> the usual C bugaboo, a buffer overflow.

I think the part of the GNAT run-time library that is written in C
still contains several buffer overflow errors.

Furthermore, there are some cases in which GNAT generates code which
allocates too little space for objects. 8-(

Re: C bug of the day

[Dave Harris]

tslettebo@chello.no.nospam (=?Windows-1252?Q?Terje_Sletteb=F8?=) wrote 
(abridged):
> It's true that you can't completely leak memory, but you can
> still get the effect of memory leak, resulting from large
> structures still having a reference to them, but which are
> otherwise unused.

Right. You may still need to null out pointers.


> This has also resulted in a host of new kinds of references for
> dealing with it, such as weak, soft and phantom references (in
> Java). Memory leak-like conditions also have expressions like
> lapsed listener, lingerers, laggards and limbo.

These issues also arise even without GC.

Also, GC allows programmers to tackle more ambitious memory
management projects. As the cookie says, "4-wheel drive means
getting stuck in more inaccessible places."


> Garbage collection might make it harder to manage resources, not
> easier.

How? By "resource" you clearly mean "memory" (because you address
non-memory resources below). Without GC we have to decide when to
delete objects. With GC we have to decide when to null pointers.
How can the second question be harder to answer?

(I know there may be issues to do with controlling the collector
itself, but that doesn't seem to be what you are talking about.)

(GC is a big win when objects can be shared by pointers which are
encapsulated. Then the question, "Has everyone finished with this
object?" gets replaced by "Have I finished with this pointer?",
which is a more local, encapsulated issue - fundamentally easier.) 


> Besides, memory is just one kind of resource, and GC does nothing
> for other kinds.

Agreed. You still need to do lifetime management.


> For languages without stack-allocated objects, like Java, you
> can't use RAII in its usual form, either (use of
> constructor/destructor). Instead, you have to resort to
> try-catch-finally, which can lead to spaghetti code, if you
> have several objects to clean up this way.

This would be a criticism of Java, not GC. Most GC languages have
idioms to encapsulate stack-based cleanup. (These are often based
on closures.) RAII is only "usual" in C++.

-- Dave Harris, Nottingham, UK

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Terje Slettebø]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20030621140227.60519A@brangdon.madasafish.com...
> tslettebo@chello.no.nospam (=?Windows-1252?Q?Terje_Sletteb=F8?=) wrote
>
> > Garbage collection might make it harder to manage resources, not
> > easier.
>
> How?

I meant that people not used to GC may meet problems they aren't
prepared for, such as these memory-leak like situations. Naturally, this
depends on what you're used to. Someone used to GC may have just as much
difficulty with a non-GC language.

So I guess this is not an argument against GC, per se, but more to
acknowledge that the problems you meet are typically different.

> (GC is a big win when objects can be shared by pointers which are
> encapsulated. Then the question, "Has everyone finished with this
> object?" gets replaced by "Have I finished with this pointer?",
> which is a more local, encapsulated issue - fundamentally easier.)

You get something similar with reference-counted smart pointers.

> > For languages without stack-allocated objects, like Java, you
> > can't use RAII in its usual form, either (use of
> > constructor/destructor). Instead, you have to resort to
> > try-catch-finally, which can lead to spaghetti code, if you
> > have several objects to clean up this way.
>
> This would be a criticism of Java, not GC. Most GC languages have
> idioms to encapsulate stack-based cleanup. (These are often based
> on closures.) RAII is only "usual" in C++.

In what way does this differ from RAII in C++. Could you give an example
from one of those languages?


Regards,

Terje

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Dave Harris]

tslettebo@chello.no.nospam (=?Windows-1252?Q?Terje_Sletteb=F8?=) wrote 
(abridged):
> > (GC is a big win when objects can be shared by pointers which are
> > encapsulated. Then the question, "Has everyone finished with this
> > object?" gets replaced by "Have I finished with this pointer?",
> > which is a more local, encapsulated issue - fundamentally easier.)
> 
> You get something similar with reference-counted smart pointers.

Yes. Which have well-known problems with loops.

Also, these introduce some of the issues you complain about for GC. For 
example, you may need weak pointers (eg boost has a weak pointer class).


> > This would be a criticism of Java, not GC. Most GC languages have
> > idioms to encapsulate stack-based cleanup. (These are often based
> > on closures.) RAII is only "usual" in C++.
> 
> In what way does this differ from RAII in C++. Could you give an
example
> from one of those languages?

In Smalltalk:

    File open: 'filename' do: [:file| "use file" ]

The stuff in square brackets is a block closure. #open:do: is a message 
sent to File, which opens the file, evaluates the closure, then closes
it 
again. So this is roughly equivalent to:

     {
         File file( "filename" );
         // use file
     }

#open:do: could be defined (on class File) like:

     open: aString do: aBlock
         |file|
         file := self open: aString.
         ^[aBlock value: file] ensure: [file close]

where #ensure: is like try/finally in Java.

-- Dave Harris, Nottingham, UK

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Re: C bug of the day

[Matthew Heaney]

tmoran@acm.org wrote in message
news:<N3mIa.721016$Si4.853728@rwcrnsc51.ops.asp.att.net>...
> >Because of the swap, C++ gets by with one finalization less:-).  On the
>   What if the object is on a linked list with back pointers so that
> after the swap the pointers are wrong?  

In that case, swap wouldn't make any sense.  In the C++ STL and Ada95
Charles libraries, the internal nodes of storage only point to other
nodes of internal storage -- never to the container object itself.

(This also explains why the C++ std::remove algorithm doesn't actually
erase the elements in the container.  There's no way to erase without
modifying the container, but an iterator doesn't know anything about
containers, so std::remove can't erase.  That's way std::remove is
typically immediately followed by <container>::erase.)


>Or if it just contains pointers
> to internal parts of itself?

Yes, that is how both the STL and Charles libraries are implemented.

http://home.earthlink.net/~matthewjheaney/charles/

(I'll have a new release of Charles in the next few days.)

Matt

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]