Hayden Schultz x3685 (haydens@wayback.atc.ll.mit.edu) wrote:

[...]

: 2) It's really beyond the state-of-the-art to build a large complex
: system without any bugs. The best we can do is to make the bugs very
: unlikely. Fragile code is deadly in a large complex system. Especially
: when several people are working with the code.

You really need to have both.  Haveing your code be brittle (strong within
its intended domain) during testing makes life significantly easier.
Useing assert to implement pre and post conditions around important
pieces of code is one way of trying to achieve this that can be
disabled easily (although many would argue that invalidates your testing).
Useing out of band error reporting (exceptions) and adopting a system
design and codeing style where you test the validity of a certain condition
at a well defined point *once* is another method.

In addition the fact that building s/w fault tolerance into your software
tends to make your software more complex tends to aggravate the fact
that complex systems are hard to make bug free.

Building complex systems out of a bunch of small cooperating processes
communicating via blocking message passing can also help decouple
much of the complexity that you refer to and allow "brittleness" at
the process level to be useful.  Unfortunately it appears that many
people have passed blocking message by for async message passing due to
its generality.

   mph



--
* Michael Hunter bagpiper@netcom.com or QUICS: mphunter

In article <HAYDENS.95Apr19235917@wayback.atc.ll.mit.edu>
           haydens@ll.mit.edu "Hayden Schultz x3685 " writes:

>        for(int i=... ; i <= end; ...) {...}
>        assert(i == end);
>
>That should keep both you and your client happy.

Given that this will cause the program to always fail after the loop, it
is unlikely that either you or the client will be happy. Assuming there
are no premature breaks in the loop body, there is not substitute for
writing the code correctly in the first place:

 for(int i = ...; i < end; ...) { ... }

Even less amusing to the client will be the lack of portability and long
term inability to compile the code they have invested in:

 int i = ...;
 for(; i < end; ...) { ... }
 assert(i == end);

will do the job (assuming you're not using the macro 'for' trick to hack
the scope).

+---------------------------+-------------------------------------+
| Kevlin A P Henney         | Can you secure Christmas with an    |
| kevlin@wslint.demon.co.uk | approximation only eighteen million |
| Westinghouse Systems Ltd  | seconds left of the original old    |
|                           | red chimney?         - Jack Kerouac |
+---------------------------+-------------------------------------+

John> Since C++ is primarily based on the notion of static checking --
John> which includes human validation of correctness -- FRAGILE code
John> is often a superior idiom than robust code.

John> For example, I had an algorithm which had a loop like:

John>  for(int i = ..; i != end; .. )

John> in which the initial value was certainly less than "end".  The
John> code failed (it was fading lights). My client could not
John> understand when I point blank refused to make the code robust by
John> changing the loop to read:

John>  for(int i = ..; i <= end; ..)

John> I WANTED the code to be fragile and NOT robust: I'd never have
John> caught the error if the lights hadn't cycled around for ages
John> instead of fading up and stopping. The point being the code was
John> WRONG, it should have terminated and the error wasn't in the
John> loop termination condition. So there was no point changing it.
John> I had to find the real bug.

John> Summary: robust code hides bugs. Fragile code exposes them
John> early.  Which kind is better depends on the context. Fragile
John> code has the advantage of expressing intent more exactly.
John> Robust code has the advantage of continuing to work in the face
John> of change.

I am uncomfortable with this argument for a couple of reasons. 1) You
really can usually have bug detection and robust code. In this
example:

 for(int i=... ; i <= end; ...) {...}
 assert(i == end);

That should keep both you and your client happy.

2) It's really beyond the state-of-the-art to build a large complex
system without any bugs. The best we can do is to make the bugs very
unlikely. Fragile code is deadly in a large complex system. Especially
when several people are working with the code.

 Hayden

--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
Air Traffic Automation
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

In article <D6DuG7.1Ax@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) says:
>
>        Although Pete Becker doesn't agree on this one --
>I had serious problems with the C++ string class.
>Until it was decided to make it a full STL sequence.

 Yup, now you're no longer prevented from calling random_shuffle()
on a string. <g>
 -- Pete

In article <3lc3td$b30@vbohub.vbo.dec.com>,
Ian Johnston <johnston@caiman.enet.dec.com> wrote:
>
>In article <D655IH.M48@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max
>Skaller) writes:
>>In article <3l6ogl$m7e@vbohub.vbo.dec.com>,
>>Ian Johnston <johnston@caiman.enet.dec.com> wrote:
>
>>>What I don't understand is to what extent making the STL model conformant
>>>with C-style arrays has reduced the safety of a standard
>>>library architecture. (I, at least, need more experience to start
>>>approaching an answer.)
>>
>> You can't ask that question without comparing it with
>>"something else". I haven't seen anything else around that
>>supports the kind of interoperability STL does.
>>
>> Of course, one might well devise such a system.
>
>Interoperability with what? With C-style arrays?

 No. Interoperability of independently devised algorithms
and containers. Ability of programmers to rapidly comprehend
and user other peoples sources.

 REUSABILITY. Thats what I'm talking about.

[C arrays]
>Is that something that
>people want/should be encouraged to use?

 Irrelevant. C arrays are necessary exactly when you
need an array of fixed size in some context with optimal
performance. Which is quite often.

>If you mean interoperability
>between different container types, then I agree, I haven't seen anything
>else that compares with STL's flexibility.

 Yes, thats what I mean. But C style arrays fit in too,
which is good because people WILL use them anyhow. Because they
have to.

>>>It's not clear that everyone buys into the STL design providing "very
>>>clean and elegant" ways of working with containers.
>>
>> STL provides a coherent way.
>
>Is coherence enough?

 No, of course not. But it is a very good start. :-)

>If it can promote 'dangerous' programming practices,
>won't people (especially the less experienced) fall into using those
>practices?

 Yes, that is not only possible but likely.
The same could be said for inheritance and C++ itself.

>Doesn't this 'danger' outweigh a high level of coherence?

 Only if there is something which is also reasonbly
coherent and efficient which supports reusability -- but which
is safer and better engineered.

 Do you know of anything like this?

 Perhaps you might agree that even though STL is not
such a safe thing to use, it is possible to USE it to design
something safer -- if that is the tradeoff you want to make.

 And that some people do not wish to trade off
efficiency for safety? (More realistically, we all make the trade,
with varying weights depending on what and where).

>> STL is basically a more modern equivalent of
>>"memcpy"/"strcpy"/"malloc" style functions of the C library
>>that is appropriate for C++.
>>
>
>Hmm. That's what concerns me :-) I had kinda hoped we would be getting
>away from all that sort of stuff. Would you advocate that people
>shouldn't use a String class, but should use char arrays with strcpy?

 Certainly, if they want high speed operations for which
arrays were appropriate.

>> The answer is: if you _extend_ STL so that the requirements
>>on a specific subset of iterators are required to provide
>>properly partially ordered comparison operators -- then you can
>>always perform those checks provided the alghorithm is provided
>>iterators from that subset.
>
>So if I need to extend STL to get the safety I'm looking for, what
>has STL bought me? Yes, I would be layering over a standard library
>(but I could just layer over the language directly). Yes, that might
>be parts of STL I could use directly, not implement myself: but it's
>not clear to me how extensive those parts would be (50%? 25%? 5%?).

 It is not clear to me either: I don't yet have enough
experience wusing STL or writing STL compliant entities.

 However my first STL container has ROBUST iterators.

>> STL has had more field testing than some of the extensions
>>to the C++ language itself. How many people have used namespaces
>>or partial specialisations?
>
>Nice observation, but I don't think this counters my argument that STL
>could have used more field testing.

 I wasn't trying to counter your argument.  You aren't
addressing the question of importance -- given STL should we
Standardise it or live without a decent Standard Library?

 My answer is: we should Standardise it and an overwhelming
majority of the C++ committee agree.

 Yes, we could always use more testing. I tend to think
Standardisation of C++ is premature. But if we're going to have
a Standard soon, lets get STL into it because it will do MORE
for C++ than any other feature of the language.

 Bjarne Stroustrup has said if he had to name the
biggest mistake he made in C++ it was not providing a
decent library earlier.

 Better late than never.

>> What would you advocate?
>
>Well, a good start would be to poll what the users want: how much
>safety, how much coherence. I think Bjarne did talk more to his users
>in the early days. I guess that's not feasible now, and of course
>could not happen in time.

 It is not only feasible it is about to happen.
The ANSI public review is about to commence.

>I suppose STL is the best political
>decision, even if not (necessarily) the best technical decision.

 Yes. But I think it was the best technical decision too. :-)

--
        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 <3lc3td$b30@vbohub.vbo.dec.com>,
Ian Johnston <johnston@caiman.enet.dec.com> wrote:
>
>> What would you advocate?
>
>Well, a good start would be to poll what the users want: how much
>safety, how much coherence. I think Bjarne did talk more to his users
>in the early days. I guess that's not feasible now, and of course
>could not happen in time. I suppose STL is the best political
>decision, even if not (necessarily) the best technical decision.

 Let me add a bit more here. My major concern with the
pre-STL library (as delegate of a National Body) was that
it was not really coherent and failed to include basic things
like standard containers -- lists, sets, maps, vectors --
that users WANTED in a Standard Library.

 STL, however, provides much MORE than I would have been
happy with: it provides a full scale architecture, and is a
"standard" in its own right.

 On the other hand it does not go in for the heavily
coupled idiosynchratic design architectures of almost
every other library I have seen: it is an open architecture
with such compelling power that the language has been
extended and designed around _it_.

 Although Pete Becker doesn't agree on this one --
I had serious problems with the C++ string class.
Until it was decided to make it a full STL sequence.
Now I _know_ it will not stand in my way, but is sure to
be a useful tool I can extend as I need -- or ignore if
I need something else.

>>>I can't speak for other people, but I'm starting to get nervous about
>>C++.
>>
>> Only starting?
>
>Ok, starting to get *real* nervous. So nervous that I'm looking at
>alternatives more than half-seriously.

 So am I. Have been for 20 years. C++ is the best thing
I have seen which meets two criteria:

 (1) It is a half way decent language

 (2) I can make money being good at it without getting
  completely bored rewriting the same old drivel
  over and over

>>>about what the compiler's up to as well. So just how much longer will
>>>it be before we have solid, stable, compatible compilers?
>>
>> Two years after we have an International Standard. IMHO.
>>
>> Also IMHO: the wait will be worth it.
>>
>> In fact, my biggest fear is _premature_ Standardisation.
>
>I hope your time estimate is right.

 Well, it is really only a guess. But most vendors
will have reasonable approximations at the _same_ time
as the Standard comes out. After all, most of them
are on the committee and contribute to decision making.

>The wait will be worth it. But
>will we still be using C++ three years from now?

 Yes, more so than ever when major reusable
container class libraries become available for the first time in
the history of computing.

 (We have major reusable function libraries, written
in FORTRAN, and have had them for 20 years.)

>I'm looking at these
>other languages, and they have/promise lots of nice features in their
>*environments*, like incremental compilation, edit-and-continue,
>no recompilation for implementation changes in base/supplier classes,
>interpreted and compiled versions, and so on.
>
>I know, I want it all :-(

 Yes. Me too. But to _write_ such a system, you need
a bootrap. And C is just not enough. C++ is -- just.

--
        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 <3l8f52$hep@vbohub.vbo.dec.com>,
Ian Johnston <johnston@caiman.enet.dec.com> wrote:
>
>In article <D5zIvF.Ko5@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max
>Skaller) writes:
>
>> STL is like a magnifying glass. It increases expressive power
>
>This is good.
>
>>      without loss of effiency
>
>This is good.
>
>>                                or gain of robustness.
>
>This is bad.

 Unfair. It isn't "bad", it merely fails to be "good". :-)
>
>It's a value judgement whether (good + good) > bad.

 good + good > no change.

>One of the prime
>benefits of C++ is surely to enhance robustness?

 To _permit_ such enhancement, certainly.
But that does not mean _all_ C++ and _all_ class libraries have to do that.

>> Static enforcement of, for example, pre-conditions
>>of functions is a kind of difficult research problem.
>
>I don't understand how this relates to the prior discussion. Could
>you elaborate?

 Sure. A function has pre- and post-conditions.
If the pre-conditions are met -- and the function is correct --
then the post conditions obtain.

 There are two difficulties using correct functions:

 1) calling the right function for the job
 2) ensuring the pre conditions are in fact met

"Robust" software will tolerate pre-condition failure --
thats what "robust" means. It will report a programming
error by throwing an exception, aborting the program
with a message, or rerunning part of the code in the hope
the failure was due to weird quirk that won't be
repeated (done sometimes in embedded systems).

If you call the "right" algorithms (eg you sort ascending
not descending when you need to) then your main
problem is ensuring you've met the pre-conditions.

While a program that kindly reports an error is nice,
if the program has to be correct, checking is a waste
because reporting the error or not, the program has
failed if the error occurs.

Since C++ is primarily based on the notion of static checking
-- which includes human validation of correctness --
FRAGILE code is often a superior idiom than robust code.

For example, I had an algorithm which had a loop like:

 for(int i = ..; i != end; .. )

in which the initial value was certainly less than "end".
The code failed (it was fading lights). My client could
not understand when I point blank refused to make the code
robust by changing the loop to read:

 for(int i = ..; i <= end; ..)

I WANTED the code to be fragile and NOT robust: I'd never have caught
the error if the lights hadn't cycled around for ages instead
of fading up and stopping. The point being the code was WRONG,
it should have terminated and the error wasn't in the loop
termination condition. So there was no point changing it.
I had to find the real bug.

Summary: robust code hides bugs. Fragile code exposes them early.
Which kind is better depends on the context. Fragile code
has the advantage of expressing intent more exactly.
Robust code has the advantage of continuing to work in the face
of change.

>>STL makes no progress here -- but it make huge leaps in
>>ensuring postconditions are met by algorithms -- by allowing
>>people to reuse tried and tested code.
>
>This is much goodness. But is the current STL iterator model a
>precondition of providing tried and tested code?

 No, of course not. It is just one possible architecture.
>
>If no, then it's still a value judgement:

 I agree, it is a value judgement.

 But you need to see the decision to be made by
the committee was binary:

 a) stick to the existing inadequate class library
  which we were strugling to _make_ coherent

 b) adopt as Standard the STL which was _designed_
   with solid mathematical foundations, had an
   architecture, a coherent model, and a clean
   specification -- as well as a working implementation
   which had been tested by a respected research
       laboratory

We had to decide. We did. No doubt STL is not optimal, it is not
the best possible library. But the Standard must consist of
something real, not a possibility.
>
>bool b = (expressive_power + efficiency + tried_and_tested) > robustness;
>
>Now, is b true or false?

 Its false IMHO because the LHS and RHS of the comparison
are incomparable without specifying a context.

 There are parts of STL the design of which has been expressly
conditioned by a desire to permit tools to check validity. While such
checks are beyond requiring of compilers, the possibility
of _static_ validation of STL style code -- rather than a retreat
to permitting run-time checks -- is an important feature of
the design.

 What I mean by that is that it is important STl algorithms
are NOT required to check for valid iterators and other
preconditions and throw exceptions because if they were,
then it would be legal to call the algorithms with
invalid iterators and checking tools would be unable to
report what would otherwise be a definite programming error.

 Woops, thats sounds complex. An example: my string
class checks indexes. It does not do so to catch errors,
the class is robust and indexing an string with ANY integral
value is _well defined_. It is permitted. It isn't an error.
So you can't say the code:

 MTLstring s = "Hello";
 for(int i=0; i<100; ++i) cout << s[i];

is in error, because it isn't, its a perfectly valid if silly
piece of code. The same code for an STL vector is a bug,
and a tool might well catch and report such an error.

BTW: my string class is robust because it is designed primarily
for use in reporting errors (debugging, and in exception
handling -- which is hard to test) and for generating output
(in which case seeing the bugged output helps find the error more
than getting an "index range" error).
--
        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

I see quite a bit of discussion here about the style of STL, which is
valuable in that it helps people get a handle on STL.

     I am not completely certain about this, but if one steps back a
minute to understand what has happened here, it is that STL somehow
combines component programming technology and "C++ technology."  Earlier
on, C++ data structures class libraries took a Smalltalk approach, with
inheritance hierarchies that made things difficult to understand and
use.  The trend was then to "flatten out" the hierarchy.  It is not
surprising that the style of STL is somewhat different (I would almost
expect it to be), but the real question to me is "Is it workable?"
Intuitively, I sense it is.  I still need to examine it further.

mc

In article <D655IH.M48@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max
Skaller) writes:
>In article <3l6ogl$m7e@vbohub.vbo.dec.com>,
>Ian Johnston <johnston@caiman.enet.dec.com> wrote:

[snip]

>>What I don't understand is to what extent making the STL model conformant
>>with C-style arrays has reduced the safety of a standard
>>library architecture. (I, at least, need more experience to start
>>approaching an answer.)
>
> You can't ask that question without comparing it with
>"something else". I haven't seen anything else around that
>supports the kind of interoperability STL does.
>
> Of course, one might well devise such a system.
>

Interoperability with what? With C-style arrays? Is that something that
people want/should be encouraged to use? If you mean interoperability
between different container types, then I agree, I haven't seen anything
else that compares with STL's flexibility.


>>It's not clear that everyone buys into the STL design providing "very
>>clean and elegant" ways of working with containers.
>
> STL provides a coherent way.


Is coherence enough? If it can promote 'dangerous' programming practices,
won't people (especially the less experienced) fall into using those
practices? Doesn't this 'danger' outweigh a high level of coherence?


>>Before STL appeared,
>>the C++ literature seemed to be implying that it was a good thing to
>>move away from older C-style practices, and to encapsulate much more
>>to provide safety: use array classes (maybe with checked array indexes),
>>use iterators that knew about their containers, use resource acquisition
>>is initialization. It's not clear to me whether the STL model follows
>that
>>direction, or reverses it.
>
> It steps backwards from it. Establishing a Standard
>for all C++ users means obtaining consensus. It is hard to
>do that with competing -- and incompatible -- "high" level
>architectures.
>
> STL is basically a more modern equivalent of
>"memcpy"/"strcpy"/"malloc" style functions of the C library
>that is appropriate for C++.
>

Hmm. That's what concerns me :-) I had kinda hoped we would be getting
away from all that sort of stuff. Would you advocate that people
shouldn't use a String class, but should use char arrays with strcpy?


>>For example, how can a function which takes two iterator parameters
>>check whether those two iterators do, in fact, point to elements of
>>the same collection?
>
>>The answer seems to be "no more easily than could a
>>function taking two pointer parameters".
>
> The answer is: if you _extend_ STL so that the requirements
>on a specific subset of iterators are required to provide
>properly partially ordered comparison operators -- then you can
>always perform those checks provided the alghorithm is provided
>iterators from that subset.
>

So if I need to extend STL to get the safety I'm looking for, what
has STL bought me? Yes, I would be layering over a standard library
(but I could just layer over the language directly). Yes, that might
be parts of STL I could use directly, not implement myself: but it's
not clear to me how extensive those parts would be (50%? 25%? 5%?).


> On the other hand, this is NOT the only kind of iterator
>STL will support. For example I have a kind of iterator which
>will work in places on the _wrong_ container: the difference
>between two such iterators is well defined no matter
>what containers they refer to. (The iterators sometimes work
>as an iterator and sometimes as an index :-)
>
> This is yet another -- different -- extension of STL.

Umm, sounds like a dangerous extension to me. Yes, the difference
between the iterators is well defined, but I don't see that that is
of any use.

[snip]

> STL has had more field testing than some of the extensions
>to the C++ language itself. How many people have used namespaces
>or partial specialisations?

Nice observation, but I don't think this counters my argument that STL
could have used more field testing.


>>I understand the reasons why it didn't (the need to get something in
>>place in time for the standardization process), but that doesn't
>>necessarily make it the right, or the best decision.
>
> What would you advocate?

Well, a good start would be to poll what the users want: how much
safety, how much coherence. I think Bjarne did talk more to his users
in the early days. I guess that's not feasible now, and of course
could not happen in time. I suppose STL is the best political
decision, even if not (necessarily) the best technical decision.

[snip]

>>I can't speak for other people, but I'm starting to get nervous about
>C++.
>
> Only starting?
>

Ok, starting to get *real* nervous. So nervous that I'm looking at
alternatives more than half-seriously.

>>Considering that the ARM has been around for four to five years, and we
>>still don't have compilers that implement ARM-level templates and
>>exceptions properly;
>
> BC4.0 does a pretty good job. So does HighC/C++.
>

Hich C/C++ I can't comment on. As for BC4.x, it does a lot better than
most, but there are still problems. (As an aside, and this applies to
C as well, compilers still don't even agree on how to *preprocess*
source text.)

[snip]

>>about what the compiler's up to as well. So just how much longer will
>>it be before we have solid, stable, compatible compilers?
>
> Two years after we have an International Standard. IMHO.
>
> Also IMHO: the wait will be worth it.
>
> In fact, my biggest fear is _premature_ Standardisation.

I hope your time estimate is right. The wait will be worth it. But
will we still be using C++ three years from now? I'm looking at these
other languages, and they have/promise lots of nice features in their
*environments*, like incremental compilation, edit-and-continue,
no recompilation for implementation changes in base/supplier classes,
interpreted and compiled versions, and so on.

I know, I want it all :-(

[snip]

Ian

--
Consulting for Digital Equipment Corp  johnston@caiman.enet.dec.com
      (33) 92.95.51.74

In article <3l6ogl$m7e@vbohub.vbo.dec.com>,
Ian Johnston <johnston@caiman.enet.dec.com> wrote:
>
>I understand that I don't have to use C-style arrays; I understand that
>I can use the STL model on either C-style arrays or STL containers.
>
>What I don't understand is to what extent making the STL model conformant
>with C-style arrays has reduced the safety of a standard
>library architecture. (I, at least, need more experience to start
>approaching an answer.)

 You can't ask that question without comparing it with
"something else". I haven't seen anything else around that
supports the kind of interoperability STL does.

 Of course, one might well devise such a system.

>It's not clear that everyone buys into the STL design providing "very
>clean and elegant" ways of working with containers.

 STL provides a coherent way.

>Before STL appeared,
>the C++ literature seemed to be implying that it was a good thing to
>move away from older C-style practices, and to encapsulate much more
>to provide safety: use array classes (maybe with checked array indexes),
>use iterators that knew about their containers, use resource acquisition
>is initialization. It's not clear to me whether the STL model follows that
>direction, or reverses it.

 It steps backwards from it. Establishing a Standard
for all C++ users means obtaining consensus. It is hard to
do that with competing -- and incompatible -- "high" level
architectures.

 STL is basically a more modern equivalent of
"memcpy"/"strcpy"/"malloc" style functions of the C library
that is appropriate for C++.

>For example, how can a function which takes two iterator parameters
>check whether those two iterators do, in fact, point to elements of
>the same collection?

>The answer seems to be "no more easily than could a
>function taking two pointer parameters".

 The answer is: if you _extend_ STL so that the requirements
on a specific subset of iterators are required to provide
properly partially ordered comparison operators -- then you can
always perform those checks provided the alghorithm is provided
iterators from that subset.

 On the other hand, this is NOT the only kind of iterator
STL will support. For example I have a kind of iterator which
will work in places on the _wrong_ container: the difference
between two such iterators is well defined no matter
what containers they refer to. (The iterators sometimes work
as an iterator and sometimes as an index :-)

 This is yet another -- different -- extension of STL.

>STL's pros and cons will no doubt become clearer after we have had more
>experience using the architecture. In the early days of C++, Bjarne
>Stroustrup strove to get practical experience of new features by using them
>in applications; this acted as a sort of sanity check. I think the
>decision to incorporate STL could have used a little more field testing...

 STL has had more field testing than some of the extensions
to the C++ language itself. How many people have used namespaces
or partial specialisations?

>I understand the reasons why it didn't (the need to get something in
>place in time for the standardization process), but that doesn't
>necessarily make it the right, or the best decision.

 What would you advocate?

>It doesn't necessarily make it the wrong decision either, but I don't
>think the confidence level in STL is as high as it perhaps should be to
>become part of the standard.

 STL was adopted joyously when the proposed Standard Library
was a mish mash of individual classes.  It provided a coherent
system almost everyone could agree on. Indeed the _main_ reservations
were the late change of the library structure.

>I read the interview with Alex Stepanov in Dr Dobb's Journal the other day,
>and while STL seems to be a good step on the way to generically
>implementing algorithms, even he seemed to think that improvements
>could be made to finding better ways of programming generically

 That would probably be true for anything. But a Standard
has to provide a fixed point. STL is not a bad fixed point!

>I can't speak for other people, but I'm starting to get nervous about C++.

 Only starting?

>Considering that the ARM has been around for four to five years, and we
>still don't have compilers that implement ARM-level templates and
>exceptions properly;

 BC4.0 does a pretty good job. So does HighC/C++.

>considering that a some recent additions seem to
>have made the language even harder to compile (although I'm not an
>implementor, so maybe that's not the case); and considering that I'm trying
>to write future-proof applications now against a moving target; I'm
>starting to get nervous.

[]

>about what the compiler's up to as well. So just how much longer will
>it be before we have solid, stable, compatible compilers?

 Two years after we have an International Standard. IMHO.

 Also IMHO: the wait will be worth it.

 In fact, my biggest fear is _premature_ Standardisation.

>(I'm also getting tired of the old edit-compile-link-debug cycle; I'd
>*love* an incremental compilation system, but that's another story.)

 I'd like a module system. C++ is archaic in this regard.
--
        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 <3kt15u$7sh@druid.borland.com>, pete@borland.com (Pete Becker)
writes:

[snip]

>>Well said. This seems to be the point that most advocates of STL don't
>>understand: a lot of people don't *want* to use algorithms with
>>C-like arrays.
>>
>
> I don't understand what this means. If you don't want to use
>STL algorithms on C-style arrays you don't have to. The design model,
>however, makes this possible, and it provides a very clean and elegant
>way of doing so. It does not mean that STL suffers from all the problems
>that C-style arrays have, so the simplistic formula "C-style arrays are
>bad, therefore STL is bad" is not appropriate.
> What, specifically, is the objection here?
>    -- Pete
>

I understand that I don't have to use C-style arrays; I understand that
I can use the STL model on either C-style arrays or STL containers.

What I don't understand is to what extent making the STL model conformant
with C-style arrays has reduced the safety of a standard
library architecture. (I, at least, need more experience to start
approaching an answer.)

It is clear that STL has adopted a pointer-like approach. It is not clear
what ramifications that has for eg multi-threading or persistence (the
questions have been asked in this group and/or c.l.c++, but persuasive
answers have not been given, as far as I can see). I don't think anyone
yet understands the implications off the trade-offs the STL design has
made.
It's not clear that everyone buys into the STL design providing "very
clean and elegant" ways of working with containers. Before STL appeared,
the C++ literature seemed to be implying that it was a good thing to
move away from older C-style practices, and to encapsulate much more
to provide safety: use array classes (maybe with checked array indexes),
use iterators that knew about their containers, use resource acquisition
is initialization. It's not clear to me whether the STL model follows that
direction, or reverses it.

For example, how can a function which takes two iterator parameters
check whether those two iterators do, in fact, point to elements of
the same collection? The answer seems to be "no more easily than could a
function taking two pointer parameters". But that is not the point.

STL's pros and cons will no doubt become clearer after we have had more
experience using the architecture. In the early days of C++, Bjarne
Stroustrup strove to get practical experience of new features by using them
in applications; this acted as a sort of sanity check. I think the
decision to incorporate STL could have used a little more field testing...
I understand the reasons why it didn't (the need to get something in
place in time for the standardization process), but that doesn't
necessarily make it the right, or the best decision.

It doesn't necessarily make it the wrong decision either, but I don't
think the confidence level in STL is as high as it perhaps should be to
become part of the standard.

I read the interview with Alex Stepanov in Dr Dobb's Journal the other day,
and while STL seems to be a good step on the way to generically
implementing algorithms, even he seemed to think that improvements
could be made to finding better ways of programming generically (I
can't quote chapter and verse as I don't have the article in front of
me, but didn't he mention something at the end about exploring new
programming languages that encapsulated and supported generic
algorithmic programming more?).

Is that enough objections for you? :-)

I can't speak for other people, but I'm starting to get nervous about C++.
Considering that the ARM has been around for four to five years, and we
still don't have compilers that implement ARM-level templates and
exceptions properly; considering that a some recent additions seem to
have made the language even harder to compile (although I'm not an
implementor, so maybe that's not the case); and considering that I'm trying
to write future-proof applications now against a moving target; I'm
starting to get nervous. I firmly believe that C++ offers by far the most
flexibility to program in different styles, and to get close to the
hardware or external software systems where I need to. I want to use
C++. But I'm getting a bit tired of having to hack my code around every
time I move to a different compiler, or every time I upgrade a compiler,
or whenever I write code that will be fed to different compilers on
different platforms. I want to be able to pick up my code and move it
around; messing about with different OSes or different databases or
different windowing systems wastes enough time as it is without worrying
about what the compiler's up to as well. So just how much longer will
it be before we have solid, stable, compatible compilers?

(I'm also getting tired of the old edit-compile-link-debug cycle; I'd
*love* an incremental compilation system, but that's another story.)

Ian

--
Consulting for Digital Equipment Corp  johnston@caiman.enet.dec.com
      (33) 92.95.51.74

In article <D5zIvF.Ko5@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max
Skaller) writes:

[ snip ]

> STL is like a magnifying glass. It increases expressive
>power

This is good.

>      without loss of effiency

This is good.

>                                or gain of robustness.

This is bad.

It's a value judgement whether (good + good) > bad. One of the prime
benefits of C++ is surely to enhance robustness?

> Static enforcement of, for example, pre-conditions
>of functions is a kind of difficult research problem.

I don't understand how this relates to the prior discussion. Could
you elaborate?

>STL makes no progress here -- but it make huge leaps in
>ensuring postconditions are met by algorithms -- by allowing
>people to reuse tried and tested code.

This is much goodness. But is the current STL iterator model a
precondition of providing tried and tested code?

If yes, then we will just have to live with the badness of not increasing
robustness.

If no, then it's still a value judgement:

bool b = (expressive_power + efficiency + tried_and_tested) > robustness;

Now, is b true or false?

Ian

--
Consulting for Digital Equipment Corp  johnston@caiman.enet.dec.com
      (33) 92.95.51.74

In article <3krqil$ajp@vbohub.vbo.dec.com>,
Ian Johnston <johnston@caiman.enet.dec.com> wrote:
>
>In article <D5p2v4.6MHJ@hawnews.watson.ibm.com>, jjb@watson.ibm.com (John
>Barton) writes:
>
>>    Thanks for clarifying this.  Now that I understand that STL helps
>>perpetuate C-like arrays I can avoid STL completely.
>>
>Well said. This seems to be the point that most advocates of STL don't
>understand: a lot of people don't *want* to use algorithms with
>C-like arrays.

 STL is like a magnifying glass. It increases expressive
power without loss of effiency or gain of robustness.

 Static enforcement of, for example, pre-conditions
of functions is a kind of difficult research problem.
STL makes no progress here -- but it make huge leaps in
ensuring postconditions are met by algorithms -- by allowing
people to reuse tried and tested code.

>btw: enjoyed the book enormously.
>
 Agreed.

--
        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 <3kmubn$ble@jupiter.sjsu.edu>,
Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
>The STL approach of begin/end markers is useful for operating on a part
>of a container. An object-oriented approach would be to call such a pair
>a subrange or interval. That would have two advantages: It would be
>easier to design a safe interval, with begin and end in the same
>container. And it would reduce the temptation to use intervals in
>unordered containers such as sets, bags, or maps, where they are clearly
>bogus.

Speculation:
An architecture based on ranges might have been reasonable
if a range (or a pair<>, more literally) could deduce its
template parameter from its constructor arguments.  A function
template (e.g. make_pair<>) can be used instead, less pleasingly.

Fact:
Alex said they had tried an approach involving explicit
ranges, and found it made some things very messy, and so
they dropped it.

There's nothing quite like building a whole system using each
alternative, to discover what's best.  Few of us can afford to
do that sort of thing, which is what makes algorithms research
like Stepanov's & Lee's so valuable.

Nathan Myers
myersn@roguewave.com

In article <3krqil$ajp@vbohub.vbo.dec.com>, johnston@caiman.enet.dec.com (Ian Johnston) says:
>
>
>In article <D5p2v4.6MHJ@hawnews.watson.ibm.com>, jjb@watson.ibm.com (John
>Barton) writes:
>
>[snip]
>
>>
>>    Thanks for clarifying this.  Now that I understand that STL helps
>>perpetuate C-like arrays I can avoid STL completely.
>>
>
>Well said. This seems to be the point that most advocates of STL don't
>understand: a lot of people don't *want* to use algorithms with
>C-like arrays.
>

 I don't understand what this means. If you don't want to use
STL algorithms on C-style arrays you don't have to. The design model,
however, makes this possible, and it provides a very clean and elegant
way of doing so. It does not mean that STL suffers from all the problems
that C-style arrays have, so the simplistic formula "C-style arrays are
bad, therefore STL is bad" is not appropriate.
 What, specifically, is the objection here?
    -- Pete

In article <ncmD5zM3M.65v@netcom.com>, Nathan Myers <ncm@netcom.com> wrote:
>In article <3kmubn$ble@jupiter.sjsu.edu>,
>Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
>>The STL approach of begin/end markers is useful for operating on a part
>>of a container. An object-oriented approach would be to call such a pair
>>a subrange or interval. That would have two advantages: It would be
>>easier to design a safe interval, with begin and end in the same
>>container. And it would reduce the temptation to use intervals in
>>unordered containers such as sets, bags, or maps, where they are clearly
>>bogus.
>
>Speculation:
>An architecture based on ranges might have been reasonable
>if a range (or a pair<>, more literally) could deduce its
>template parameter from its constructor arguments.  A function
>template (e.g. make_pair<>) can be used instead, less pleasingly.
>
>Fact:
>Alex said they had tried an approach involving explicit
>ranges, and found it made some things very messy, and so
>they dropped it.
>
>There's nothing quite like building a whole system using each
>alternative, to discover what's best.  Few of us can afford to
>do that sort of thing, which is what makes algorithms research
>like Stepanov's & Lee's so valuable.

 Ranges don't work. All you are doing is changing the
point in time for which checking is required. Such checking
is expensive and not always possible.

 STL uses the most powerful (expressive) and least
well checked notation. Which means you remain free to
invent your own better checked mechanisms.

 Don't YOU get rather annoyed when a nice assured
safe system stops you doing something YOU know is safe
but the stupid system prevents you doing it?

 Rest assured. If C gives you gun to shoot yourself
in the foot, and C++ gives you a shotgun to blow your whole
leg off, then STL gives you a whole platoon of machine gunners
and lets you instantiate more anytime you need 'em. :-)

 Its _still_ up to you to aim the right way.

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

pstemari@erinet.com (Paul J. Ste. Marie) writes:
> Now, I can use
>
> double *begin = array;
> double *end   = array + sizeof(array)

You mean,

double *end   = array + sizeof(array) / sizeof(array[0]);

I forgot to point out that:

:In article <3kmltc$3mk@highway.LeidenUniv.nl>,
:   ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) wrote:
::
::while(some_iterator++) { dosomethingwith(*someiterator); }
::
::Isn't that cute (and pointerlike)?

isn't at all pointer-like, since no pointer will ever go to null
via ++ without having undefined behavior.  The pointer-like
behavior here would be:

while (*++some_iterator) { dosomethingwith(*someiterator); }

for null-terminated pointer lists, but this falls down with a
container of values since * gives back a value, not a pointer.

Paul J. Ste. Marie (pstemari@erinet.com) wrote:
: some_iterator looks like Type **, and you have a null-terminated
: pointer array.  This will not work now or ever for containers of
: values.  Example:

: double array[] = {1.0, 0.0, 5.0, 3.14159};

: Now, I can use

: double *begin = array;
: double *end   = array + sizeof(array)

: and have

: for (double* p =begin, p != end; ++p) something(*p);

: but

: double* p = begin;
: while (++p) something(*p);

: doesn't work.

Sigh!

I don't care that it doesn't work with pointers. That's why I
don't use pointers, but use our iterators instead, for it DOES
work with them. Who cares about pointers anyway? What's the point
in copying inconvenient pointer behaviour into a template library
if you can make iterators behave _better_ than pointers?

JP

In article <3kmubn$ble@jupiter.SJSU.EDU>,
   horstman@sjsumcs.sjsu.edu (Cay Horstmann) wrote:
:Rogue Wave iterators have a test to check if they are at the end
:of the container. Admittedly the test is a bit funky, but it
:doesn't use a sentinel.

Ever look at the code?  It does use a sentinel.  But handling the
algorithms I described would require you to add in your own
sentinels, which is what is hard to do in a general case.

:The STL approach of begin/end markers is useful for operating on a
:part of a container. An object-oriented approach would be to call
:such a pair a subrange or interval. That would have two
:advantages It would be easier to design a safe interval, with
:begin and end in the same container. And it would reduce the
:temptation to use intervals in unordered containers such as sets,
:bags, or maps, where they are clearly bogus.

Certainly this would work, and there's nothing to prevent you from
doing it when using the STL containers.

In article <D5p2v4.6MHJ@hawnews.watson.ibm.com>, jjb@watson.ibm.com (John
Barton) writes:

[snip]

>
>    Thanks for clarifying this.  Now that I understand that STL helps
>perpetuate C-like arrays I can avoid STL completely.
>
>--
>John.
>
>John J. Barton        jjb@watson.ibm.com            (914)784-6645
>H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598
>

Well said. This seems to be the point that most advocates of STL don't
understand: a lot of people don't *want* to use algorithms with
C-like arrays.

btw: enjoyed the book enormously.

--
Consulting for Digital Equipment Corp  johnston@caiman.enet.dec.com
      (33) 92.95.51.74

In article <3k4cv0$epa@jupiter.SJSU.EDU>,
Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
>John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
>
>:  If anything, the conversion
>
>:  operator bool()const
>
>: would make more sense in cases like
>
>:  while(it) { ..}
>
>Wasn't it some C++ programmer who said that those who forget their
>history are condemned to repeat it?
>
>There is a reason why one converts to void* to test for truth values.
>Of course, a conversion to bool would be the more logical approach, but it
>would make a lot of expressions compile with nonsensical meanings. Consider
> container<T>::iterator it1, it2, it3;
> if (it1 == it2 + it3) ...

 I guess you meant to write

 if( it1 = it2 + n )

here (i.e. an assignment).

 This idiom stinks. It gets used because C has lousy
control structures. In C++, using such implicit conversions
extensively makes already unreadable C style code hopelessly
obscure.

 I almost always write user defined assignments to return void.

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

John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
: In article <3k4cv0$epa@jupiter.SJSU.EDU>,
: Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
: >John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
: >
: >:  If anything, the conversion
: >
: >:  operator bool()const
: >
: >: would make more sense in cases like
: >
: >:  while(it) { ..}
: >
: >Wasn't it some C++ programmer who said that those who forget their
: >history are condemned to repeat it?
: >
: >There is a reason why one converts to void* to test for truth values.
: >Of course, a conversion to bool would be the more logical approach, but it
: >would make a lot of expressions compile with nonsensical meanings. Consider
: > container<T>::iterator it1, it2, it3;
: > if (it1 == it2 + it3) ...

:  I guess you meant to write

:  if( it1 = it2 + n )

: here (i.e. an assignment).

:  This idiom stinks. It gets used because C has lousy
: control structures. In C++, using such implicit conversions
: extensively makes already unreadable C style code hopelessly
: obscure.

:  I almost always write user defined assignments to return void.

I didn't mean to introduce yet another idiom. All I meant to say is that
converting to bool/int can make utter nonsense compile--and make people like
JMS worry if there is actually an idiom lurking under it.

Cay

In article <3k3adc$4in@jupiter.SJSU.EDU>, horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:
|> John Barton (jjb@watson.ibm.com) wrote:
|>
|> :   The STL, (Standard "Template" Library, ugh) uses an iterator
|> : model based on pointer-like classes.
|>
|> You mean it should have been called Standard Pointer Library :-) ?

   Standard Template Library is a ridiculous name.  Do we have a
Standard Virtual Function Library?  Standard For-Loop Library?
Perhaps its a Standard Iteration Library.  It happens to use templates
extensively.  But it does not approximately cover the domain "template".

[ Cay says that STL iterators are pointers to pointers in the
  same way that C arrays are pointers to pointers ]
|>
|> :    Second is operator void*() to obtain a pointer to the object referenced
|> : cast to void*.  About the only useful thing you can do with this
|> : operator is
|> :     while(it) {...}
|> : but the idiom is very successful as the iostream library shows.
|>
|> Yes, but remember that STL iterators faithfully emulate C pointers. Since
|> you can't test if a C pointer points outside an array, you must be
|> prevented from being able to test that for STL iterators. Otherwise you
|> might end up writing algorithms that cannot work for C arrays, which
|> would be intolerable.

    Thanks for clarifying this.  Now that I understand that STL helps
perpetuate C-like arrays I can avoid STL completely.

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <D5p2v4.6MHJ@hawnews.watson.ibm.com>, jjb@watson.ibm.com (John Barton) says:
>|>
>|> Yes, but remember that STL iterators faithfully emulate C pointers. Since
>|> you can't test if a C pointer points outside an array, you must be
>|> prevented from being able to test that for STL iterators. Otherwise you
>|> might end up writing algorithms that cannot work for C arrays, which
>|> would be intolerable.
>
>    Thanks for clarifying this.  Now that I understand that STL helps
>perpetuate C-like arrays I can avoid STL completely.
>

 STL does not "perpetuate C-like arrays", nor does it "faithfully
emulate C pointers." If you decide to "avoid STL completely" that is, of
course, your decision to make. But do not do so based on these
misstatements and misinterpretations.
 -- Pete

John Barton (jjb@watson.ibm.com) wrote (in a couple articles):

:[ Cay says that STL iterators are pointers to pointers in the
:  same way that C arrays are pointers to pointers ]

That's not right.  STL iterators are just pointers--whether to
values or to other pointers depends on the contents of the
container.

:    Second is operator void*() to obtain a pointer to the
: object referenced cast to void*.  About the only useful thing
: you can do with thisoperator is
:     while(it) {...}
: but the idiom is very successful as the iostream library shows.

Wrong idiom here.  The iostream flavor was a hacked attempt at
getting a Boolean return value.  Incrementing pointers doesn't
result in null.  If you're looking for an argv-like idiom, then the
test would be:

      while (*it)

or

      while (*++it)

but that breaks on, for example, a container of strings.

:    Thanks for clarifying this.  Now that I understand that STL
:helps perpetuate C-like arrays I can avoid STL completely.

Whatever turns you on--but try writing a quicksort, heapsort, or
mergesort using something like a Rogue Wave implementation, which
has the sort of semantics you're looking for, and then try writing
one using these semantics.  I like Rogue Wave, but having an
endmarker to pass around instead of testing the iterator for
end-of-container is a lot more flexible, especially with recursive
algorithms.  The other alternative is sticking sentinels in the
containers, which is a real PITA.

In article <D5p2v4.6MHJ@hawnews.watson.ibm.com>,
John Barton <jjb@watson.ibm.com> wrote:
>In article <3k3adc$4in@jupiter.SJSU.EDU>, horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:
>|> John Barton (jjb@watson.ibm.com) wrote:
>|>
>|> :   The STL, (Standard "Template" Library, ugh) uses an iterator
>|> : model based on pointer-like classes.
>|>
>|> You mean it should have been called Standard Pointer Library :-) ?
>
>   Standard Template Library is a ridiculous name.  Do we have a
>Standard Virtual Function Library?  Standard For-Loop Library?
>Perhaps its a Standard Iteration Library.  It happens to use templates
>extensively.  But it does not approximately cover the domain "template".

If it's a library of templates, why not call it a template library?
If it's a standard library of templates, why not call it a standard
template library?
If it's the only standard library of templates, why not call it _the_
standard template library and introduce a convenient acronym?

Last time I was granted a look at the ISO working paper, this last point
(i.e., STL is the _only_ standard library of templates) was not true;
there was at least one more template (valarray). However, I imagine there
is a possibility that in the final standard all standard templates can
be collectively called the "standard template library".
[... snip ...]
>|>
>|> Yes, but remember that STL iterators faithfully emulate C pointers. Since

I suppose you (Cay) mean that STL iterators accept a set of operations that
is a subset of those operations that are valid for built-in pointers. As
another thread pointed out, they do not really emulate pointers (since,
e.g., there is no requirement for "nil" iterators).

>|> you can't test if a C pointer points outside an array, you must be
>|> prevented from being able to test that for STL iterators. Otherwise you
>|> might end up writing algorithms that cannot work for C arrays, which
>|> would be intolerable.
>
>    Thanks for clarifying this.  Now that I understand that STL helps
>perpetuate C-like arrays I can avoid STL completely.

I suppose you have no need for C-like arrays. Your statement does,
however, "sound" as if the mere fact that STL is compatible with the
built-in array construct makes STL "bad" (somehow). I would find that
a thin argument.
>
>--
>John.
>
>John J. Barton        jjb@watson.ibm.com            (914)784-6645
>H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

 Daveed

Paul J. Ste. Marie (pstemari@erinet.com) wrote:
: Whatever turns you on--but try writing a quicksort, heapsort, or
: mergesort using something like a Rogue Wave implementation, which
: has the sort of semantics you're looking for, and then try writing
: one using these semantics.  I like Rogue Wave, but having an
: endmarker to pass around instead of testing the iterator for
: end-of-container is a lot more flexible, especially with recursive
: algorithms.  The other alternative is sticking sentinels in the
: containers, which is a real PITA.

Another alternative (again) is letting iterators return some nullish
value whenever they have been iterated past their end (and/or
beginning). This is how we implemented our yet to be released
VanBil++ container library, and it works like a breeze. If you use the
proper conversion operators, as Barton said, you can then even use the
old C-style

while(some_iterator++) { dosomethingwith(*someiterator); }

Isn't that cute (and pointerlike)?

Additional niceties are that you don't have to pass the object
to which the iterator points around either.

JP

"Mediocracy thrives on standardisation."

In article <3kmltc$3mk@highway.LeidenUniv.nl>,
   ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) wrote:
:Another alternative (again) is letting iterators return some
:nullish value whenever they have been iterated past their end
:(and/or beginning). This is how we implemented our yet to be
:released VanBil++ container library, and it works like a breeze.
:If you use the proper conversion operators, as Barton said, you
:can then even use the old C-style
:
:while(some_iterator++) { dosomethingwith(*someiterator); }
:
:Isn't that cute (and pointerlike)?

But again you completely miss the point.  This only works if
some_iterator looks like Type **, and you have a null-terminated
pointer array.  This will not work now or ever for containers of
values.  Example:

double array[] = {1.0, 0.0, 5.0, 3.14159};

Now, I can use

double *begin = array;
double *end   = array + sizeof(array)

and have

for (double* p =begin, p != end; ++p) something(*p);

but

double* p = begin;
while (++p) something(*p);

doesn't work.

In article <3kkjcv$b7d@usenet.rpi.edu> vandevod@oooge.cs.rpi.edu (David Vandevoorde) writes:
> In article <D5p2v4.6MHJ@hawnews.watson.ibm.com>,
> John Barton <jjb@watson.ibm.com> wrote:
> > ...
> >   Standard Template Library is a ridiculous name.  Do we have a
> >Standard Virtual Function Library?  Standard For-Loop Library?
> >Perhaps its a Standard Iteration Library.  It happens to use templates
> >extensively.  But it does not approximately cover the domain "template".
>
> If it's a library of templates, why not call it a template library?
> If it's a standard library of templates, why not call it a standard
> template library?
> If it's the only standard library of templates, why not call it _the_
> standard template library and introduce a convenient acronym?

And model A Fords should have been named the Standard Assembly Line
Generated Product (SALGP).  No, the STL name gives no clue that STL
primarily defines some (quite nice, I think) ordered container
interfaces and algorithms.  From an earlier posting to c.l.c++:

As it stands STL might be better named:

Linearly Ordered Container and Algorithm Library (LOCAL)
or
Ordered Container Template and Algorithm Library (OCTAL)
or
STepanov and Lee (STL) (this may have been originally said jokingly,
but it is probably a better meaning for STL than Standard Template
Library, which may imply more generality than truly exists in STL.)

Doug
----------
Doug Morgan, doug@ads.com
Booz-Allen & Hamilton
1500 Plymouth St.
Mountain View, CA 94043-1230
     (415) 960-7444
FAX: (415) 960-7500
----------

In article <3kl59j$mob@news.erinet.com>, pstemari@erinet.com (Paul J. Ste. Marie) says:
>
>John Barton (jjb@watson.ibm.com) wrote (in a couple articles):
>
>:[ Cay says that STL iterators are pointers to pointers in the
>:  same way that C arrays are pointers to pointers ]
>
>That's not right.  STL iterators are just pointers--whether to
>values or to other pointers depends on the contents of the
>container.
>

 NO, NO, NO!!! Sorry, but people keep saying this, and it is
simply wrong. STL iterators have many of the same properties as
pointers, but they are definitely not "just pointers". You cannot use
an iterator in an arbitrary piece of code that was written to use a
pointer. The opposite is true: any code written to use an STL iterator can
also be used with a pointer. The legal operations on interators are a
subset of the legal operations on pointers.
 -- Pete

Paul J. Ste. Marie (pstemari@erinet.com) wrote:

: Whatever turns you on--but try writing a quicksort, heapsort, or
: mergesort using something like a Rogue Wave implementation, which
: has the sort of semantics you're looking for, and then try writing
: one using these semantics.  I like Rogue Wave, but having an
: endmarker to pass around instead of testing the iterator for
: end-of-container is a lot more flexible, especially with recursive
: algorithms.  The other alternative is sticking sentinels in the
: containers, which is a real PITA.
Rogue Wave iterators have a test to check if they are at the end of the
container. Admittedly the test is a bit funky, but it doesn't use a sentinel.

The STL approach of begin/end markers is useful for operating on a part
of a container. An object-oriented approach would be to call such a pair
a subrange or interval. That would have two advantages: It would be
easier to design a safe interval, with begin and end in the same
container. And it would reduce the temptation to use intervals in
unordered containers such as sets, bags, or maps, where they are clearly
bogus.

Cay

John Barton (jjb@watson.ibm.com) wrote:

:   The STL, (Standard "Template" Library, ugh) uses an iterator
: model based on pointer-like classes.

You mean it should have been called Standard Pointer Library :-) ?

: ... First is operator->() to obtain a pointer
: to the object referenced. It seems idiotic to write (*it)->foo() for
: iterators over pointer collections when it->foo() would be available
: with operator->().  For non-pointer collections, it->foo() should still
: work and seems better than (*it).foo() to me.

Compare a container<T*> with an array T*[N]. An container<T*>::iterator
and a T** behave the same way. You use (*it)->foo() or (*p)->foo() to call
T::foo().  But for non-pointer collections there is a different problem.
The ARM states (p.337) "It follows [sic] that operator->() must return
either a pointer to a class or an object of or a reference to a class for
which operator->() is defined". Never mind that it doesn't follow at all;
compilers do seem to implement that. That is, if
container<T>::iterator::operator->() returns a T*, and T is instantiated
with int, the compiler may gripe, even though you never use it-> with
that iterator. I don't know the current thinking of this issue in the
standard--the ARM may well be completely out of date in this regard.

:    Second is operator void*() to obtain a pointer to the object referenced
: cast to void*.  About the only useful thing you can do with this
: operator is
:     while(it) {...}
: but the idiom is very successful as the iostream library shows.

Yes, but remember that STL iterators faithfully emulate C pointers. Since
you can't test if a C pointer points outside an array, you must be
prevented from being able to test that for STL iterators. Otherwise you
might end up writing algorithms that cannot work for C arrays, which
would be intolerable.

:    Is there a reason not to use these operators in STL-like iterators?
: Does anyone know if they were omitted from STL on purpose?

Cay
horstman@cs.sjsu.edu

John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:

:  If anything, the conversion

:  operator bool()const

: would make more sense in cases like

:  while(it) { ..}

Wasn't it some C++ programmer who said that those who forget their
history are condemned to repeat it?

There is a reason why one converts to void* to test for truth values.
Of course, a conversion to bool would be the more logical approach, but it
would make a lot of expressions compile with nonsensical meanings. Consider
 container<T>::iterator it1, it2, it3;
 if (it1 == it2 + it3) ...
for iterators or
 cin << 10
for streams. This is because bool->int remains an implicit conversion.

Cay

In article <3k4cv0$epa@jupiter.SJSU.EDU>,
   horstman@sjsumcs.sjsu.edu (Cay Horstmann) wrote:
:... This is because bool->int remains an implicit conversion.

But one that compilers are free to issue pages of warnings about.
In fact, as near as I can see it the only advantage that the bool
stuff that's been described here buys you is the hope that
implementers will produce exactly those sort of warnings.

  The STL, (Standard "Template" Library, ugh) uses an iterator
model based on pointer-like classes.  The key operations on these
classes are operator*() to obtain the object referenced by the
iterator and operator++() to advance the iterator to the next object.

  As soon as I try to use this model, two other pointer operations
seem very important to me.  First is operator->() to obtain a pointer
to the object referenced.  It seems idiotic to write (*it)->foo() for
iterators over pointer collections when it->foo() would be available
with operator->().  For non-pointer collections, it->foo() should still
work and seems better than (*it).foo() to me.

   Second is operator void*() to obtain a pointer to the object referenced
cast to void*.  About the only useful thing you can do with this
operator is
    while(it) {...}
but the idiom is very successful as the iostream library shows.

   Is there a reason not to use these operators in STL-like iterators?
Does anyone know if they were omitted from STL on purpose?

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <D5CDxB.u4z@hawnews.watson.ibm.com>,
John Barton <jjb@watson.ibm.com> wrote:
>
 [re STL.]

>   operator void*() to obtain a pointer to the object referenced
>cast to void*.  About the only useful thing you can do with this
>operator is
>    while(it) {...}
>but the idiom is very successful as the iostream library shows.

 GAK! This horrible perversion should be killed :-)

 Consider:

 memcpy(STL_iterator, STL_iterator, 100); // no warning!!

IMHO we would be better to _remove_ the conversion to void*
from the list of implicit conversions: if you want a raw memory
address you should be _forced_ to write an explicit cast.
This conversion is rarely safe, even if it is type safe.

 If anything, the conversion

 operator bool()const

would make more sense in cases like

 while(it) { ..}

However, STL works on the principle of iteration through a
_range_ and the above idiom is not supported by STL.
Loops should be terminated by a comparison with a sentinel
iterator.

The sentinel for an array is NOT the null pointer :-)

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