:  I was _very_ impressed with A++ and very disappointed
: no real implementation exists. Pointers are intrinsic to C++:
: I suspect its not just "aliasing" but the loss of array
: bounds information that causes problems. And of course
: undiscriminated unions, side effects .... A whole lot
: of things that are there for programmer optimisation
: and which defeat logic based optimisation.

:  A++ goes well beyond the assertional facilities
: provided by Eiffel. I really wish I had one :-)


Where can I read about A++ and Safe C++?

Even if they don't exist, I'm guessing that learning about them
would improve my C++ programming style.

--
----------------------
Dave Kuhlman        Reify, Redwood City, CA
Internet:   dkuhlman@netcom.com
Compuserve: 72470,116
----------------------

Kenny Pitt <Kenny.Pitt@AtlantaGA.NCR.COM> writes:

>You can't take a language like C++ that has been in
>use for a number of years and make a change that is radical enough
>to break probably at least 75% of the existing code.

Well, actually you can and the committee already has (the change
was exceptions).

But for all those people who missed this the first five times, apart
from adding a couple of new keywords the "Safe C++" proposal would NOT
break any existing code.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <9426909.12044@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>Kenny Pitt <Kenny.Pitt@AtlantaGA.NCR.COM> writes:
>
>>You can't take a language like C++ that has been in
>>use for a number of years and make a change that is radical enough
>>to break probably at least 75% of the existing code.
>
>Well, actually you can and the committee already has (the change
>was exceptions).
>

 Apart from adding a couple of new keywords, exceptions do NOT break
any existing code. Changing an existing program to use exceptions will
break it. The change to operator new to require it to throw an exception when
allocation fails probably breaks existing programs, which is why we provied
a mechanism for restoring the current behavior.

>But for all those people who missed this the first five times, apart
>from adding a couple of new keywords the "Safe C++" proposal would NOT
>break any existing code.
>
>--
>Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <Cwqz5w.MJ5@borland.com> pete@genghis.interbase.borland.com
(Pete Becker) writes:

|> In article <9426909.12044@mulga.cs.mu.oz.au>,
|> Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
|> >Kenny Pitt <Kenny.Pitt@AtlantaGA.NCR.COM> writes:

|> >>You can't take a language like C++ that has been in
|> >>use for a number of years and make a change that is radical enough
|> >>to break probably at least 75% of the existing code.

|> >Well, actually you can and the committee already has (the change
|> >was exceptions).

|>  Apart from adding a couple of new keywords, exceptions do NOT break
|> any existing code. Changing an existing program to use exceptions will
|> break it. The change to operator new to require it to throw an exception when
|> allocation fails probably breaks existing programs, which is why we provied
|> a mechanism for restoring the current behavior.

But that mechanism isn't the default, so you did break code:-).

I don't think that is the real problem, though.  The real problem is
that modifying code to add exceptions cannot be done locally.
Typically, adding an exception anywhere (say because you upgraded your
string library, and the new version throws exceptions) will require
rewriting most of the application.  And the transition rewrites are
definitly not beautiful.

Eventually, all code will use string, or dynarray, or something
similar, instead of using new and delete directly, will use Lock
objects, instead of calling the global functions lock and unlock,
etc., etc.  And in my opinion, such code will be cleaner, more
maintainable and more readable than the code it replaces.  And
exceptions won't cause it any problems.  But I fear that we have a
difficult transition period to go through.

Which doesn't mean I don't think we should have exceptions.  But
saying that they don't break any code will not simplify the
transition.  (Providing standardized exception safe alternatives to
like string and dynarray *will* simplify the transition.)
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

I wrote:

>>ark@tempel.research.att.com (Andrew Koenig) writes:
>>
>>>Knowing the background of the people working on "Safe C++", and the
>>>experience with other languages that went into its design, I don't think
>>>it is "radical".  It corrects some obnoxious defects in C++ (lack of GC,
>>>lack of array bounds checking, pointer/array confusion).

Sorry, I mucked up the attributions there.  It wasn't Andrew Koenig who
wrote that, it was David Chase (chase@centerline.com).  No doubt Andrew
Koenig has quite different views.  My apologies.
(Thanks to Ross Ridge for picking that up.)

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <NISIMURA.94Sep22105516@as32.itl.atr.co.jp>,
Hitoshi Nishimura <nisimura@itl.atr.co.jp> wrote:
>
>
>  Can we get STL library or its information from ftp?
>
>  If we can, please tell me where is STL library.
>                           (ftp address?)

 butler.hpl.hp.com

In article <CLINE.94Sep14013849@sun.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes:
>In article <Cw2MFq.40G@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>> A very ambitious extension to C++ called A++ was devised
>>to give C++ the capability of doing that for preconditions,
>>class invariants, etc ...
>
>> The results of the experiment are not surprising:
>>its just not possible in C++. Its far too nasty a language.
>
>I remember a lot of interesting challenges when Doug and I designed A++,
>but I wouldn't say that it was "not possible in C++". I'd say the largest
>deterrent was the existance of pointers (and especially aliasing) rather
>than a perceived nastiness in the language.
>

 I was _very_ impressed with A++ and very disappointed
no real implementation exists. Pointers are intrinsic to C++:
I suspect its not just "aliasing" but the loss of array
bounds information that causes problems. And of course
undiscriminated unions, side effects .... A whole lot
of things that are there for programmer optimisation
and which defeat logic based optimisation.

 A++ goes well beyond the assertional facilities
provided by Eiffel. I really wish I had one :-)


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <35kh5b$17t@src-news.pa.dec.com> detlefs@src.dec.com (Dave
Detlefs) writes:

|> And, also, I can't resist; Ross Ridge writes

|> > Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
|> > >Safe C++ isn't another language.  It's a subset of C++.

|> > So is C.

I almost posted, C is the unsafe subset.  Sorry I didn't.

|> Well, C is not a subset of C++ (tried compiling a C program with a C++
|> compiler lately?), but even if it were, I don't see your point.  Safe
|> C++ and the-subset-of-C++-that-is-very-much-like-C share the good
|> property that they are subsets of a popular language, and therefore
|> don't require new compilers, but they can certainly differ in other
|> attributes, like, for example, safety.

And even the safe subset of C++ shares the declaration syntax.  Oh
well, half a cake is better than none, I guess.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

Hi there,

In article <rfgCw8to4.A8s@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>
>Just as long as the two keywords are not `true' and `false'.  (Somebody
>else already stole those, and that alone broke 90% of *my* existing code.)
>
But really Ron,

I can compile and use your code without change.  Surely you can just add

-Dbool=RONS_bool

to your compilation options (assuming true and false are defined as 1 and 0).

Regards,
 Rohan.
--
----------------------------------------------------------------------------
rjl@iassf.easams.com.au | All quotes can be attributed to my automated quote
Rohan Lenard            | writing tool.  Yours for just $19.95; and if you
+61-2-367-4555          | call now you'll get a free set of steak knives ...

Ron --

>>Close, but not quite.  I don't want to people to continue to
>>believe that the Ellis-Detlefs proposal would force them to
>>rewrite their code.  It won't (well, they steal two keywords,
>>but that's not much).
>
> Just as long as the two keywords are not `true' and `false'.  (Somebody
> else already stole those, and that alone broke 90% of *my* existing
> code.)

For the record, the keywords are "gc" and "nogc".  These (well, at
least "gc") are admittedly a little too likely to conflict with
existing identifiers, but we figured if we ever got to the point of
somebody objecting for this reason, 98% of the battle would be over.

Our GC proposal was never a proposal in the sense of one presented to
the ANSI committee.  We knew that prior practice would be required.
We feared that vendors would start to offer GC, but in ways that
either 1) didn't work, or 2) had unnecessary semantic restrictions, or
3) was gratuitously different from GC offered by other vendors.
We therefore hoped to convince vendors that they might want to
implement GC as an extension *before* the committee mandated it,
agreeing on our proposal as a standard interface.  We didn't have much
luck; it seems that we needn't have feared vendors rushing to
implement something that the committee hadn't agreed upon :-)

And, also, I can't resist; Ross Ridge writes

> Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
> >Safe C++ isn't another language.  It's a subset of C++.
>
> So is C.

Well, C is not a subset of C++ (tried compiling a C program with a C++
compiler lately?), but even if it were, I don't see your point.  Safe
C++ and the-subset-of-C++-that-is-very-much-like-C share the good
property that they are subsets of a popular language, and therefore
don't require new compilers, but they can certainly differ in other
attributes, like, for example, safety.

Dave








--
======================================================================
Dave Detlefs
DEC Systems Research Center
Palo Alto, CA

Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>Safe C++ isn't another language.  It's a subset of C++.

Ross Ridge writes:
>So is C.

Dave Detlefs <detlefs@src.dec.com> wrote:
>Well, C is not a subset of C++ (tried compiling a C program with a C++
>compiler lately?), but even if it were, I don't see your point.  Safe
>C++ and the-subset-of-C++-that-is-very-much-like-C share the good
>property that they are subsets of a popular language, and therefore
>don't require new compilers, but they can certainly differ in other
>attributes, like, for example, safety.

They also should have the property of having different standards
committees.  Don't waste that C++ committee's time trying to turn C++
into Safe C++.

       Ross Ridge

--
 l/    Ross Ridge      //
[oo]   The Great HTMU, CSC President   [oo]
-()-        http://csclub.uwaterloo.ca/u/r-ridge/  /()/
 db           +1 519 883 4329                             //

r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

>ark@tempel.research.att.com (Andrew Koenig) writes:
>
>>Knowing the background of the people working on "Safe C++", and the
>>experience with other languages that went into its design, I don't think
>>it is "radical".  It corrects some obnoxious defects in C++ (lack of GC,
>>lack of array bounds checking, pointer/array confusion).
>
>I would call another language a radical departure from C++.

Safe C++ isn't another language.  It's a subset of C++.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <35agbn$de1@wcap.centerline.com> chase@centerline.com (David Chase) writes:
>kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
>
>> <Kenny.Pitt@AtlantaGA.NCR.COM> writes:
>
>> |> I disagree.  You can't take a language like C++ that has been in
>> |> use for a number of years and make a change that is radical enough
>> |> to break probably at least 75% of the existing code.
>
>> Actually, I suspect that well over 75% of the existing code is broken
>> already.  I think that all David was suggesting is that the standard
>> require the compiler to discover this, rather than the user.
>
>Close, but not quite.  I don't want to people to continue to
>believe that the Ellis-Detlefs proposal would force them to
>rewrite their code.  It won't (well, they steal two keywords,
>but that's not much).

Just as long as the two keywords are not `true' and `false'.  (Somebody
else already stole those, and that alone broke 90% of *my* existing code.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

>Knowing the background of the people working on "Safe C++", and the
>experience with other languages that went into its design, I don't think
>it is "radical".  It corrects some obnoxious defects in C++ (lack of GC,
>lack of array bounds checking, pointer/array confusion).

r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:
>I would call another language a radical departure from C++.

Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>Safe C++ isn't another language.  It's a subset of C++.

So is C.

       Ross Ridge

btw. you got the attributions wrong.

--
 l/    Ross Ridge      //
[oo]   The Great HTMU, CSC President   [oo]
-()-        http://csclub.uwaterloo.ca/u/r-ridge/  /()/
 db           +1 519 883 4329                             //

In article <Cw2MFq.40G@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:

> A very ambitious extension to C++ called A++ was devised
>to give C++ the capability of doing that for preconditions,
>class invariants, etc ...

> The results of the experiment are not surprising:
>its just not possible in C++. Its far too nasty a language.

I remember a lot of interesting challenges when Doug and I designed A++,
but I wouldn't say that it was "not possible in C++". I'd say the largest
deterrent was the existance of pointers (and especially aliasing) rather
than a perceived nastiness in the language.


Marshall
--
Marshall Cline
--
Marshall P. Cline, Ph.D. / Paradigm Shift Inc / PO Box 5108 / Potsdam NY 13676
cline@parashift.com / 315-353-6100 / FAX: 315-353-6110

>==========David Chase, 9/13/94==========
>
>r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:
>
>> I would call another language a radical departure from C++.  You're
>> talking about removing the C from C++, which is fine, but you what
>> you're getting isn't C++.
>
>Nope, since there isn't a frozen standard for C++, or its
>libraries, C++ is what we get when the standard is done.
>Proposals/suggestions cannot be rejected simply because
>they "aren't C++" -- that would be equivalent to saying
>that standardization is done, right at this instant.

I disagree.  You can't take a language like C++ that has been in
use for a number of years and make a change that is radical enough
to break probably at least 75% of the existing code.  Standardization
should not redefine the language.  Rather, it should define the
"standard" way of doing things that have been or could be
interepreted differently by different implementors of the language.
Even though there was no official "standard" at the time, the
basis of the C++ language was defined when it was first developed.
I have no problems with a standard adding new features to a
language as long as those new features don't change any behavior
that was clearly defined and without ambiguity in the existing
language specification.

--
Kenny Pitt
AT&T Global Information Solutions
Disclaimer:  My views are my own.  I refuse to be a company
puppet.

In article <Cw68u7.B01@attatl.AtlantaGA.NCR.COM> Kenny Pitt
<Kenny.Pitt@AtlantaGA.NCR.COM> writes:

|> >==========David Chase, 9/13/94==========

|> >r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

|> >> I would call another language a radical departure from C++.  You're
|> >> talking about removing the C from C++, which is fine, but you what
|> >> you're getting isn't C++.

|> >Nope, since there isn't a frozen standard for C++, or its
|> >libraries, C++ is what we get when the standard is done.
|> >Proposals/suggestions cannot be rejected simply because
|> >they "aren't C++" -- that would be equivalent to saying
|> >that standardization is done, right at this instant.

|> I disagree.  You can't take a language like C++ that has been in
|> use for a number of years and make a change that is radical enough
|> to break probably at least 75% of the existing code.

Actually, I suspect that well over 75% of the existing code is broken
already.  I think that all David was suggesting is that the standard
require the compiler to discover this, rather than the user.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:

> <Kenny.Pitt@AtlantaGA.NCR.COM> writes:

> |> I disagree.  You can't take a language like C++ that has been in
> |> use for a number of years and make a change that is radical enough
> |> to break probably at least 75% of the existing code.

> Actually, I suspect that well over 75% of the existing code is broken
> already.  I think that all David was suggesting is that the standard
> require the compiler to discover this, rather than the user.

Close, but not quite.  I don't want to people to continue to
believe that the Ellis-Detlefs proposal would force them to
rewrite their code.  It won't (well, they steal two keywords,
but that's not much).

The "Safe C++" proposal requires the existence of a pragma, which if
seen, would require the compiler to enforce some coding conventions,
plus some libraries that let you talk about arrays without "unsafe"
use of pointers.  If the pragma is not seen, your code's behavior
(broken or not) is unchanged.  There is no requirement that the
compiler discover your broken code (for that, we sell tools :-);
even if the safety-switch is on, it merely enforces a subset in
which it is possible to verify that no errors of a particular
variety exist.  Other errors are still allowed.

That's about all of it.

yours,

David Chase, speaking for myself
CenterLine Software

I think the thread here has lost track of the original subject.

And I ask - what exactly is STL? Is it in the standard now? And where
can I get it.

Please reply via posting on the newsgroup so other newbies are informed.

Thanks in advance.

Eric
--
-----------------------------------------------------------------
Eric Friedman Internet email: efried@netcom.com

Andrew Koenig <ark@tempel.research.att.com> wrote:
>  At least STL can be compiled and run on today's systems (modulo a
>few odd corners).

I don't think some of these corners can be dismissed out of hand like
this.  You're using a significantly limitted STL implementation if you
don't have member templates.

       Ross Ridge

In article <Cvxryu.7ns@tempel.research.att.com>,
Andrew Koenig <ark@tempel.research.att.com> wrote:

>In article <nagleCvvFu2.Gw7@netcom.com> nagle@netcom.com (John Nagle) writes:

> ...

>>       Incidentally, subscript checking can become almost free with some
>> new optimzation techniques described in Gupta's recent paper in ACM
>> Letters on Programming Languages.
>
>I look forward to vendors incorporating those techniques into
>iterator adaptors and making them available for experimentation.

As a point of information, most production quality Ada compilers
have been doing very effective "constraint check" removal for many
years.  The techniques described by Gupta are not particularly
new in the Ada compiler world.

On the other hand, Ada has subrange subtypes, and strong type
distinctions between integer types, which significantly increases
the amount of static information available.  Given an Ada compiler
with a good optimizer (and a decent programmer ;-), probably
50% of the constraint checks can be removed immediately using
static type and subtype information, and 60% of those left can be removed
using dynamic data flow analysis with range propagation, resulting
in about 4 of 5 constraint checks being removed.  (This is of course
a very rough estimate -- your mileage will vary...)

If the optimizer gives feedback about where it could not remove
constraint checks, then a conscientious programmer can generally
provide additional type and subtype declarations to get the
number of remaining unremovable constraint checks down into the noise,
while simultaneously coming closer to statically proving nice things
about their program.

>    --Andrew Koenig
>      ark@research.att.com

-Tucker Taft    stt@inmet.com

> nagle@netcom.com (John Nagle) writes:
> >       That's scary.  STL is a clever implementation of a radical concept.
> > It extends the "*p++" concept to arbitrary data structures and streams.
> > You'll be able to iterate through a list with "*p++".  Some people think
> > this is a good thing, and some don't.

ark@tempel.research.att.com (Andrew Koenig) writes:
> Iterators are hardly radical.  Iterators with interfaces that look
> like pointers are downright conservative.  Why the fear?

I think some people think that use of "*p++" to iterate through
an array should be considered an anachronism.  The inability to
tell whether "foo * p" references the middle of an entire
array of foo, or a subrarray of foo, or a lone foo, creates some
difficulties for (things like) automatic marshalling generators
and garbage collectors.  Some (me, for instance) might argue that
it makes code a little bit harder to understand.  Generally,
I think that use of "*p++" and its friends makes code less
readable, and it rarely makes it more efficient.

> >       STL is clever, but I have real doubts about whether it is a good
> > idea.  The Detlefs/Ellis "Safe C++" library looks better in many
> > respects, although it assumes a garbage collector.  In that approach,
> > arrays have sizes and subscripts are checked.

> Well, do you want radical concepts or don't you.  You can hardly object
> that STL is too radical and then go and propose something even more
> radical.  At least STL can be compiled and run on today's systems
> (modulo a few odd corners).

By this reasoning, every piece of the language was "radical" at one
time or another.  Do you propose to retroactively toss out multiple
inheritance, templates, and exception handling?

Knowing the background of the people working on "Safe C++", and the
experience with other languages that went into its design, I don't think
it is "radical".  It corrects some obnoxious defects in C++ (lack of GC,
lack of array bounds checking, pointer/array confusion).  It would
enable some useful tools.  Of course, perhaps "radical" is not the right
term for "iterate with *p++", since this gives new life to something I
wish would go away.

And please, don't start with the "you can always implement a checked
array class" again.  Of course I can.  I can implement a whole stinking
language, if I want to -- the question is, will anyone else use it? Will
I interoperate with any other C++ code?  It is pointless for me (and
other similarly minded C++ programmers) to reinvent the wheel,
inefficiently, and slightly differently.  The only reason I see for
using C++ is interoperation with other code and tools -- if I didn't
care about that, there are several "better" (from my POV) languages
out there.

yours,

David Chase

ark@tempel.research.att.com (Andrew Koenig) writes:
>Well, do you want radical concepts or don't you.  You can hardly object
>that STL is too radical and then go and propose something even more
>radical.  At least STL can be compiled and run on today's systems
>(modulo a few odd corners).

David Chase <chase@centerline.com> wrote:
>By this reasoning, every piece of the language was "radical" at one
>time or another.  Do you propose to retroactively toss out multiple
>inheritance, templates, and exception handling?

Non sequitur.

>Knowing the background of the people working on "Safe C++", and the
>experience with other languages that went into its design, I don't think
>it is "radical".  It corrects some obnoxious defects in C++ (lack of GC,
>lack of array bounds checking, pointer/array confusion).

I would call another language a radical departure from C++.  You're
talking about removing the C from C++, which is fine, but you what you're
getting isn't C++.

>And please, don't start with the "you can always implement a checked
>array class" again.  Of course I can.  I can implement a whole stinking
>language, if I want to -- the question is, will anyone else use it?

I dunno, is anyone using Safe C++?

>It is pointless for me (and other similarly minded C++ programmers) to
>reinvent the wheel, inefficiently, and slightly differently.

Considering you don't want the C part of C++, and the fact that
C++ is based on C, I would suggest that this is the best way
to get the language you want.

>The only reason I see for using C++ is interoperation with other code
>and tools -- if I didn't care about that, there are several "better"
>(from my POV) languages out there.

If C++ is a bad you say, I would suggest using the other languages.
The problems of using them with other code and your tools should be
more than offset by the advantage of using the better languages.

       Ross Ridge

In article <Cvxryu.7ns@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig) writes:
>In article <nagleCvvFu2.Gw7@netcom.com> nagle@netcom.com (John Nagle) writes:
>
>>       That's scary.  STL is a clever implementation of a radical concept.
>
>Iterators are hardly radical.  Iterators with interfaces that look
>like pointers are downright conservative.  Why the fear?

 STL is not "clever" but it is one of the best
libraries I've every seen, with a robust functional design,
with clearly stated preconditions for correct operation of
the functions.

 Dynamic checking is anathema to the notions of C++,
which is designed for as much _static_ (compile time)
checking as possible in an extension of C -- and enforces
nothing more.

 Some of us want to write fast code and are prepared
to test and _prove_ correctness and do not want to pay
for run-time checks built into libraries.

 Standardising STL means it will run even faster --
and perhaps vendors will offer compiler switches to
enable debugging versions that do checking.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <Cw0x5u.H5q@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>If the optimizer gives feedback about where it could not remove
>constraint checks, then a conscientious programmer can generally
>provide additional type and subtype declarations to get the
>number of remaining unremovable constraint checks down into the noise,
>while simultaneously coming closer to statically proving nice things
>about their program.

 This is very nice -- and a feature of the language design.
In general I believe that optimising a program by proving
it's correctness is the way to go.

 A very ambitious extension to C++ called A++ was devised
to give C++ the capability of doing that for preconditions,
class invariants, etc ...

 The results of the experiment are not surprising:
its just not possible in C++. Its far too nasty a language.
It is derived from C, a language specifically designed
for _programmer_ optimisation.

 The conclusion is really that a language must
be very carefully designed in conjunction with theorem
proving and reporting capabilities to enable this technique.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <Cw2LEs.18n@ucc.su.OZ.AU>,
John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>
> Some of us want to write fast code and are prepared
>to test and _prove_ correctness and do not want to pay
>for run-time checks built into libraries.
>
Some of us like having languages that will do the checking for us,
then allow us to turn it off for the version we field.  Instead of
having to hand-code special checks for indices and pointers, we just
turn those checks off.

I agree with working hard at proving the "Correctness" of the design,
however.

> Standardising STL means it will run even faster --
>and perhaps vendors will offer compiler switches to
>enable debugging versions that do checking.

A darn good idea.


--
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
             Ada 9X -- It doesn't suck                       ||  father's Ada
For all sorts of interesting Ada 9X tidbits, run the command:||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
     **Tri-Ada '94, Nov 7-11, Baltimore, MD -- Something for Everybody.**

This is getting off the subject of the STL library --
the connection between this and that revolves around
the use of "*p++" in "iterators" (as if indexing through
an array) versus the Ellis/Detlefs "Safe C++" proposal,
which would, as I understand it, not let you use "*p++"
to index through arrays.  Apparently some people think
that the ideas behind "Safe C++" are radical and untested.
I disagree.  See below for the reasons why, including
references.

r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

> I would call another language a radical departure from C++.  You're
> talking about removing the C from C++, which is fine, but you what
> you're getting isn't C++.

Nope, since there isn't a frozen standard for C++, or its
libraries, C++ is what we get when the standard is done.
Proposals/suggestions cannot be rejected simply because
they "aren't C++" -- that would be equivalent to saying
that standardization is done, right at this instant.  It is
also difficult for me to understand exactly what "removing
the C" means, or what's so horrible about it, assuming it
is what I think it is.  The ability to refer to arrays and
subarrays with what also looks like a pointer causes
trouble for toolbuilders -- if this ambiguity were removed,
it would be much easier to build these tools.  You could
get a better garbage collector, and it would be easier to
implement.  You could get built-in support for marshalling
data structures (complicated ones, with cycles in them, and
containing objects with "virtual member functions") to disk
or over the net.  Your debugger could do a better job of
displaying data (I know I get tired of trying to remember
the incantation required when I want a "pointer" displayed
like the array that it really is).  You could have tighter
interface specifications.  You could get (gasp!) run-time
checking of array bounds.

Back in 1990, when I worked at Olivetti Research Center, we
had all these tools for a safe language, and they were
implemented at a very low cost.  It took 5 people about 2
years to implement a compiler (with interface caching, for
quick turnaround) and a pre-linker and an automatic
dependency checker and an interpreter, for a language with
exception-handling, garbage collection, run-time types, and
a thread-safe library.  We (Dan Craft, actually) studied
the problem of implementing some of these tools for C++,
and came to the conclusion that the ambiguities described
above made the problem "too hard".  It was relatively easy
to build these tools for M-3.  It ought to be easy in
whatever "new" languages are designed, but it isn't in C++,
at least not as it stands now.  You'll give up very little
to get this, and you'll get plenty back.  The tools are
worth it.  (Now, if they'd just get rid of those damn
include files and go to real live interfaces.)

> I dunno, is anyone using Safe C++?

I think it is in use at Xerox PARC.  The technology is
well-understood to the point of being fairly boring to
those who've studied it.  Cedar Mesa is a "safe" version of
Mesa.  Modula-2+ is a "safe" version of Modula-2.  People
at PARC and elsewhere (me included) have programmed in a
"safe" style in C, to the extent that it is possible.
Examples of this include using either the Boehm-Weiser
garbage collector with C or the Bartlett garbage collector
with C++.  There was a paper in the 1981 POPL proceedings
by Susan Owicki on "making the world safe for garbage
collection" that more or less tells you how to do it.

There's a Xerox blue-and-white (CSL-84-7, by Paul Rovner)
describing how GC and runtime types were added to Mesa.  I
don't know if it is still available.  A description of M-2+
can be found in DEC Systems Research Center Technical
Report #3 (1985, Rovner, Levin, and Wick).  It was also
used at Acorn Research Center (when there was such a
thing), and at Olivetti Research as the first
implementation language for their Modula-3 front-end.  M-3
was also a safe language -- I implemented the gorier bits
of the run-time system, as well as its C-generating
backend.  Once you strip off the syntax (line noise or
clunky keywords, choose your poison) these languages are
fairly similar.  Note that these "safe" languages (Cedar,
M-2+, M-3) all contain an "unsafe" variant for those
modules where it is helpful to point a loaded gun at your
toes -- there is nothing you can write in C, that cannot
also be written in these other languages, in about the same
style (the keywords are big and clunky, of course, but
that's not what's at issue here).

You can also read about the Boehm-Weiser garbage collector
in one of the 1988 issues of Software Practice and
Experience -- I believe it discusses some of the things
that C programmers can do that are "not safe".  There is a
paper by Ben Zorn -- U Colorado Boulder CS Technical report
CU-CS-573-92 that discusses the various measured costs of
garbage collection for C programs.

I think the issue of safety in programming languages has
been studied rather more thoroughly that most of the other
additions that have made it into C++.  I realize that I
must sound rather impatient and annoyed in this posting,
but it was clear how to "do safety" over 10 years ago,
and it was clear what the problems were for C++ over 5
years ago.  The (ab)use of template syntax for arrays
gives you a different a way to say all those things that
could previously only be expressed with pointers -- to me,
this looks like the last piece required for a safe version
of C++.

yours,

David Chase

In article <39436@ursa.bear.com> tmurphy@rachel.bear.com (Tim Murphy) writes:
>
>I picked up a copy of the paper on the Standard Template Library...
>
>1. In what sense is it "standard"?  Will it become as widely adopted as
>iostreams?

Don't know.

>2. The (partial) implementation I picked up (stl.h) seems targeted to
>GNU g++ and uses (at least conditionally) many new template features that
>are in the latest language spec but are far from present in any compilers
>that I use (HP, ObjectCenter; also GNU seems quite buggy where templates are
>concerned).  Are there any other implementations out there?  Any work done
>using a cfront-based compiler?

Try anonymous ftp from butler.hpl.hp.com (192.6.19.31) in
/stl/sharfile.Z.  It is (or was a few weeks ago) Stepanov's version.

>3. The design (and certainly the extant implementation) is completely
>based on templates and "compile-time" dispatch; there isn't a virtual
>function in sight.

Nice, isn't it (see two points below)?  STL is far and away the
cleanest, most comprehensive C++ design (or beginning of one) I have
ever seen.

>Most of their functions take iterators as arguments.
>Regular pointers will always suffice,

No so.  Many (actually, most) iterator types are classes.

>but has anyone (say the designers or
>proponents of the library) thought about the opposite, namely run-time
>polymorphic iterators?

Go ahead and create classes that meet the STL interface spec.  Make
the iterators polymorphic.  The full range of STL template functions
will gladly execute on your new classes.  They will also execute at
inline machine speed on others.  Excellent.

>I have the beginnings of a design that I think
>will work in their framework but it's far from trivial; it would be comforting
>to know that someone else had thought about this.

Any design that meets their interface specs should run in their
framework.  No need to be trivial.

>
>Thanks for any info you may have.
>
>-- Timothy S. Murphy,  Bear,Stearns,&Co.,  speaking for myself. --

  I picked up a copy of the paper on the Standard Template Library
(Stepanov and Lee, HP Labs, ftp to ftp.cygnus.com, pub/stl.ps.gz,
pub/stl.h) as well as the beginnings of an implementation.  It seems
like a good thing, but I have some concerns that I'd like to put to rest
before using it/adopting their style.

   1. In what sense is it "standard"?  Will it become as widely adopted as
iostreams?

   2. The (partial) implementation I picked up (stl.h) seems targeted to
GNU g++ and uses (at least conditionally) many new template features that
are in the latest language spec but are far from present in any compilers
that I use (HP, ObjectCenter; also GNU seems quite buggy where templates are
concerned).  Are there any other implementations out there?  Any work done
using a cfront-based compiler?

   3. The design (and certainly the extant implementation) is completely
based on templates and "compile-time" dispatch; there isn't a virtual
function in sight.  Most of their functions take iterators as arguments.
Regular pointers will always suffice, but has anyone (say the designers or
proponents of the library) thought about the opposite, namely run-time
polymorphic iterators?  I have the beginnings of a design that I think
will work in their framework but it's far from trivial; it would be comforting
to know that someone else had thought about this.

  Thanks for any info you may have.

 -- Timothy S. Murphy,  Bear,Stearns,&Co.,  speaking for myself. --

Tim Murphy <tmurphy@rachel.bear.com> wrote:
>  I picked up a copy of the paper on the Standard Template Library
>(Stepanov and Lee, HP Labs, ftp to ftp.cygnus.com, pub/stl.ps.gz,
>pub/stl.h) as well as the beginnings of an implementation.
...
>   1. In what sense is it "standard"?  Will it become as widely adopted as
>iostreams?

As I understand it the committee has approved it for incorporation
in the standard.  It will probably under go through some changes
before the final draft.

       Ross Ridge

r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:
>As I understand it the committee has approved it for incorporation
>in the standard.  It will probably under go through some changes
>before the final draft.
>      Ross Ridge

      That's scary.  STL is a clever implementation of a radical concept.
It extends the "*p++" concept to arbitrary data structures and streams.
You'll be able to iterate through a list with "*p++".  Some people think
this is a good thing, and some don't.

      It's worth noting that there's no mention of error checking in the
STL document.  STL doesn't use exceptions, either.  As far as I can tell,
behavior if you iterate off the end of the list is "implementation-defined".

      STL is clever, but I have real doubts about whether it is a good
idea.  The Detlefs/Ellis "Safe C++" library looks better in many
respects, although it assumes a garbage collector.  In that approach,
arrays have sizes and subscripts are checked.

      Incidentally, subscript checking can become almost free with some
new optimzation techniques described in Gupta's recent paper in ACM
Letters on Programming Languages.

      John Nagle

r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:
>As I understand it the committee has approved it for incorporation
>in the standard.  It will probably under go through some changes
>before the final draft.

John Nagle <nagle@netcom.com> wrote:
>That's scary.  STL is a clever implementation of a radical concept.

Yes, I agree, it's scary.  I don't know if the committee should've
approved something that's never really been used this late in
standardization process.

>      It's worth noting that there's no mention of error checking in the
>STL document.  STL doesn't use exceptions, either.  As far as I can tell,
>behavior if you iterate off the end of the list is "implementation-defined".

Ask Alex Stepanov and he'll tell you "Yes, we are very fast."  I think
this is in the "spirit of C" that C++ inherits from C.  The expression
"*p++", where p is pointer, doesn't imply error checking or exceptions,
and going of the end of array is also implementation-defined.  As
iterators have subset of pointer functionality, I think it makes sense
to allow implementators to make the same choices between safety and
speed that they can make with pointers.  I would argue STL shouldn't
throw exceptions except as a side effect of any other library functions
it may call (eg. operator new()), but it certainly is possible to
create an implementation of STL that does do extensive error checking.
I've written a vector template that does this.

>      Incidentally, subscript checking can become almost free with some
>new optimzation techniques described in Gupta's recent paper in ACM
>Letters on Programming Languages.

Hmm?  Are you refering to his recent paper in the monster issue of
Transactions on Programming Languages and Systems?

      Ross Ridge

>      It's worth noting that there's no mention of error checking in the
>STL document.  STL doesn't use exceptions, either.  As far as I can tell,
>behavior if you iterate off the end of the list is "implementation-defined".

 I have not been programming in C++ in years, but what prevents you
from re-defining the operator ++ so that it throws an exception when you run
off the end of the list?

 I think the pre-conditions on most of these "functions" are very
simple. The list search that you are probably referring to assumes that
you will locate the element on the list. If you are not satisfying the
pre-conditions, you should protect yourself (re-define the operators) or
you deserve what you get.

Sundar Varadarajan
sundarv@cup.hp.com

>>>>> "R" == Ross Ridge <r-ridge@calum.csclub.uwaterloo.ca> writes:

R> ... it certainly is possible to create an
R> implementation of STL that does do extensive error checking.  I've
R> written a vector template that does this.

The beauty of STL is that it easily works with your own data
structures.  If we have an "array" type with known size and index
range checking, our iterator type should of course also apply range
checking.

Now, if you just plug in your array iterator with range checking,
every algorithm in STL will use range checking.  That may be radical,
but hardly scary.

      -- Dag

In article <nagleCvvFu2.Gw7@netcom.com> nagle@netcom.com (John Nagle) writes:

>       That's scary.  STL is a clever implementation of a radical concept.

Iterators are hardly radical.  Iterators with interfaces that look
like pointers are downright conservative.  Why the fear?

> It extends the "*p++" concept to arbitrary data structures and streams.
> You'll be able to iterate through a list with "*p++".  Some people think
> this is a good thing, and some don't.

In the committee discussions, there was not a single objection to
the use of pointer-like syntax.  The ability to use the same operations
for built-in and library data structures is not to be dismissed lightly.

>       It's worth noting that there's no mention of error checking in the
> STL document.  STL doesn't use exceptions, either.  As far as I can tell,
> behavior if you iterate off the end of the list is "implementation-defined".

It is a simple matter to define range-checking iterator adaptors if
that's what you want.

>       STL is clever, but I have real doubts about whether it is a good
> idea.  The Detlefs/Ellis "Safe C++" library looks better in many
> respects, although it assumes a garbage collector.  In that approach,
> arrays have sizes and subscripts are checked.

Well, do you want radical concepts or don't you.  You can hardly object
that STL is too radical and then go and propose something even more
radical.  At least STL can be compiled and run on today's systems
(modulo a few odd corners).

>       Incidentally, subscript checking can become almost free with some
> new optimzation techniques described in Gupta's recent paper in ACM
> Letters on Programming Languages.

I look forward to vendors incorporating those techniques into
iterator adaptors and making them available for experimentation.
--
    --Andrew Koenig
      ark@research.att.com