pabrabbin@hotmail.com wrote:
....
> This is kind of where this whole thing started.  The standard says that
> X::const_iterator supports ==, but I can't find anything which says that this
> should be implemented as a global function operator==(X::const_iterator,
> X::const_iterator) or as a member function X::const_iterator::operator==
> (X::const_iterator).  (Maybe this is deliberate ?)

Yes - see section 17.3.1.2p3:
'Interface convention requirements are stated as generally as possible.
Instead of stating that "class X has to define a member function
operator++()," the interface requires "for any object x of class X, ++x
is defined." That is, whether the operator is a member is unspecified.'

It's also irrelevant. Either form would work equally well if X::iterator
is required to be implicitly convertible to X::const_iterator.
Unfortunately, it's only required to be convertible, a requirement that
can be met by defining an conversion constructor that's been declared
'explicit'. However,

 (X::const_iterator(i)==ci)

is guaranteed to work, but is apparantly not an acceptable solution for
those who've been arguing on this thread.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <372605FD.DF0BE61E@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> pabrabbin@hotmail.com wrote:
> ....
> > This is kind of where this whole thing started.  The standard says that
> > X::const_iterator supports ==, but I can't find anything which says that
this
> > should be implemented as a global function operator==(X::const_iterator,
> > X::const_iterator) or as a member function X::const_iterator::operator==
> > (X::const_iterator).  (Maybe this is deliberate ?)
>
> Yes - see section 17.3.1.2p3:
> 'Interface convention requirements are stated as generally as possible.
> Instead of stating that "class X has to define a member function
> operator++()," the interface requires "for any object x of class X, ++x
> is defined." That is, whether the operator is a member is unspecified.'
>
> It's also irrelevant. Either form would work equally well if X::iterator
> is required to be implicitly convertible to X::const_iterator.
> Unfortunately, it's only required to be convertible, a requirement that
> can be met by defining an conversion constructor that's been declared
> 'explicit'. However,
>
>  (X::const_iterator(i)==ci)
>
> is guaranteed to work, but is apparantly not an acceptable solution for
> those who've been arguing on this thread.

Thanks for the info James.  Nice point about the 'explicit' specifier - I
hadn't thought of that, and I guess it means that

  (ci==X::const_iterator(i))

is then also required to avoid any possible problems with conversion when
comparing the other way.


The problem which I'm finding with little things such as this in the STL is
that (as we all know) no implementation/compiler combination yet implements
the Standard fully and correctly - so it's easy to rely on what is actually
undefined behaviour (according to the Standard), which might break code in
the next compiler/library release.

VC5 allows comparison of the above expression in both orders, neither of
which now appear to be guaranteed by the Standard.  On this occasion,
Microsoft seem to have allowed behaviour which actually seems quite sensible.
 It's not that I necessarily find (ci==X::const_iterator(i)) "unacceptable",
but it does seem unnecessary since the comparison is always safe - I was
merely trying to establish 1) if VC5 was right due to some point I'd missed
in my reading of the Standard, and 2) if not, whether this is a small
oversight in the specification or a deliberate action.

I'm now convinced that it's not deliberate and explicit conversion of
X::iterator to X::const_iterator is always necessary to follow "the letter of
the law".

Thanks,

Phil Brabbin

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:

> It's also irrelevant. Either form would work equally well if X::iterator
> is required to be implicitly convertible to X::const_iterator.
> Unfortunately, it's only required to be convertible, a requirement that
> can be met by defining an conversion constructor that's been declared
> 'explicit'.

Please. It's clearly required to be implicitly convertible.

But it doesn't make i==ci nor ci==i valid.

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <372605FD.DF0BE61E@wizard.net>...
>It's also irrelevant. Either form would work equally well if X::iterator
>is required to be implicitly convertible to X::const_iterator.
>Unfortunately, it's only required to be convertible, a requirement that
>can be met by defining an conversion constructor that's been declared
>'explicit'. However,


The standard doesn't define convertible.

There are a number of places in the standard which say "x is convertible to
y" and it should be clear that the intention is that there be an accessible
implicit conversion.

For instance 24.1.3 says that for a forward iterator class X
  X r;
r++ must be convertible to X.  I would argue that if the conversion is
explicit or inaccessible X does not meet the forward iterator requirements.

How does one submit a defect request to get "convertible" defined?

Is string "convertible" to char*?   const_cast<char*>(s.c_str())





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

pabrabbin@hotmail.com wrote:
> =

> In article <7g40ms$hb7$1@nyheter.chalmers.se>,
>   d2bjorn@dtek.chalmers.se (Mikael G Bj|rn) wrote:
> >
> > According to section 23.1 table 65 - Containter requirements,
> > X::iterator is required to be convertible to X::const_iterator.
> >
> > Since the X::const_iterator supports =3D=3D, I think the expression
> > must be valid.
> =

> This is kind of where this whole thing started.  The standard says that=

> X::const_iterator supports =3D=3D, but I can't find anything which says=
 that this
> should be implemented as a global function operator=3D=3D(X::const_iter=
ator,
> X::const_iterator) or as a member function X::const_iterator::operator=3D=
=3D
> (X::const_iterator).  (Maybe this is deliberate ?)
> =

> If the first case were always true, we could deduce that "(i =3D=3D ci)=
" is valid
> by your reasoning.  If an implementation chooses (?) to implement =3D=3D=
 with
> member variables for X::iterator and X::const_iterator, then "i" won't =
be
> converted to a const_iterator (will it ?) and there seems to be nothing=
 to
> suggest that X::iterator should have a member variable for comparison w=
ith
> X::const_iterator.  Ah well ....

This is kind of where this whole thing started. Even if 'convertible' mea=
ns
IMPLICITLY convertible (seems reasonable, IMHO) global
operator=3D=3D(X::[const_]iterator&,X;;[const_]iterator&) wont really hel=
p. =

The point was, that std::XX::[const_]iterators generally are templates. S=
o a
global operator=3D=3D would have to be a template function. OTOH, the con=
version
would (also generally) qualify as user-defined. So it won't be used for
template argument deduction. =

This in turn invalidates your reasoning for the first case: neither (ci=3D=
=3Di)
nor (i=3D=3Dci) can be used to deduce the proper template function, unles=
s there
are four of them (one for each combination of const/non-const <-> const/n=
on-const).
OTOH, for member functions (I suppose you mean that by 'member variable')=
 of
(template) classes, any legal conversion sequence (including a user-defin=
ed
conversion) can be invoked. So in this case all const/non-const combinati=
ons
could be handled with just two operators: X::const_iterator::operator=3D=3D=
(const
const_iterator&) and (!!) X::iterator::operator=3D=3D(const const_iterato=
r&). But
the last one doesn't seem to be required by the standard.
So actually it would be easier to allow the comparison using member opera=
tors...

-- J=F6rg Barfurth
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

pabrabbin@hotmail.com wrote:

> does anybody know whether the C++
> Standard either 1) explicitly allows, 2) explicitly disallows, or 3) does not
> specify the validity of the expression:
>
>         (i == ci)

Answer 3

> where i is of type T::iterator, ci is of type T::const_iterator for some
> container class T, and both i and j have valid values in the range [begin(),
> end ()) ?
>
> If anyone does and can point me to a section in the Standard, I'd love to
> know!

Precisely because no section makes it correct or ill-formed, the
answer is 3.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 26 Apr 99 03:15:59 GMT, Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>pabrabbin@hotmail.com wrote:

>> does anybody know whether the C++
>> Standard either 1) explicitly allows, 2) explicitly disallows, or 3) does not
>> specify the validity of the expression:
>>
>>         (i == ci)
>
>Answer 3

>Precisely because no section makes it correct or ill-formed, the
>answer is 3.

The standard says that "int *" is an iterator, and "int const *" is a
const_iterator.
Now for "int *" and "int const *", the expression "i==ci" is valid, or
Answer 1.
This suggests that for all iterator and all const_iterator, Answer 1
is the answer.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 26 Apr 99 03:15:59 GMT, Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> >pabrabbin@hotmail.com wrote:
>
> >> does anybody know whether the C++
> >> Standard either 1) explicitly allows, 2) explicitly disallows, or 3) does not
> >> specify the validity of the expression:
> >>
> >>         (i == ci)
> >
> >Answer 3
>
> >Precisely because no section makes it correct or ill-formed, the
> >answer is 3.
>
> The standard says that "int *" is an iterator, and "int const *" is a
> const_iterator.

int* (resp const int*) are Iterators. iterator is a typedef
                           ^
in Containers, Iterator is a concept.

> Now for "int *" and "int const *", the expression "i==ci" is valid, or
> Answer 1.

Yes

> This suggests that for all iterator and all const_iterator, Answer 1
> is the answer.

Actually it just suggests that the answer can hardly be 2 (I mean
that if the answer is 2, we have a defect).

I would like the answer to be 1, but it isn't.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > >> does anybody know whether the C++
> > >> Standard either 1) explicitly allows, 2) explicitly disallows,
> > >> or 3) does not specify the validity of the expression:
> > >>
> > >>         (i == ci)
> >
> > Now for "int *" and "int const *", the expression "i==ci" is valid, or
> > Answer 1.
> >
> > This suggests that for all iterator and all const_iterator, Answer 1
> > is the answer.
>
> Actually it just suggests that the answer can hardly be 2 (I mean
> that if the answer is 2, we have a defect).

Come on now - it doesn't "suggest" either!  Just because we have one example
where it HAPPENS to be true doesn't allow us to infer anything about the
general case.  The general case (which is what I'm interested in ) could still
equally-well be 1, 2 or 3.

I think Siemel may have been using the case of pointers as a rather special
case since iterators are a generalisation of pointers. But I could equally
well say that given an "int *i", the expression "i + 6" is valid (assuming
that it points to an element in the same contiguous block as i) but this is
quite clearly not true for iterators in general!

- Phil

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) writes:
> >pabrabbin@hotmail.com wrote:
>
> >> does anybody know whether the C++
> >> Standard either 1) explicitly allows, 2) explicitly disallows, or 3) does not
> >> specify the validity of the expression:
> >>
> >>         (i == ci)
[...]
> The standard says that "int *" is an iterator, and "int const *" is a
> const_iterator.
> Now for "int *" and "int const *", the expression "i==ci" is valid, or
> Answer 1.
> This suggests that for all iterator and all const_iterator, Answer 1
> is the answer.

"Pluto is an animal.  Pluto is a dog.  Therefore, all animals are dogs."

The conclusion unfortunately isn't valid.
Regards,

 Jens.
--
mailto:jjk@acm.org                 phone:+49-7031-14-7698 (HP TELNET 778-7698)
  http://www.bawue.de/~jjk/          fax:+49-7031-14-7351
PGP:       06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7fqcc8$927$1@nnrp1.dejanews.com>,  <pabrabbin@hotmail.com> wrote:
>Ignoring implementation issues the moment, does anybody know whether the C++
>Standard either 1) explicitly allows, 2) explicitly disallows, or 3) does not
>specify the validity of the expression:
>
> (i == ci)
>
>where i is of type T::iterator, ci is of type T::const_iterator for some
>container class T, and both i and j have valid values in the range [begin(),
>end ()) ?
>
>If anyone does and can point me to a section in the Standard, I'd love to
>know!

According to section 23.1 table 65 - Containter requirements,
X::iterator is required to be convertible to X::const_iterator.

Since the X::const_iterator supports ==, I think the expression
must be valid.

Regards Mikael Bj   rn


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 27 Apr 1999 15:12:26 GMT, Mikael G Bj|rn <d2bjorn@dtek.chalmers.se> wrote:

>According to section 23.1 table 65 - Containter requirements,
>X::iterator is required to be convertible to X::const_iterator.

Is the conversion explicit or implicit?  My instincts tell me
implicit, but ...


>Since the X::const_iterator supports ==, I think the expression
>must be valid.

Fine.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7g40ms$hb7$1@nyheter.chalmers.se>,
  d2bjorn@dtek.chalmers.se (Mikael G Bj|rn) wrote:
>
> In article <7fqcc8$927$1@nnrp1.dejanews.com>,  <pabrabbin@hotmail.com> wrote:
> >Ignoring implementation issues the moment, does anybody know whether the C++
> >Standard either 1) explicitly allows, 2) explicitly disallows, or 3) does not
> >specify the validity of the expression:
> >
> > (i == ci)
> >
> >where i is of type T::iterator, ci is of type T::const_iterator for some
> >container class T, and both i and j have valid values in the range [begin(),
> >end ()) ?
> >
> >If anyone does and can point me to a section in the Standard, I'd love to
> >know!
>
> According to section 23.1 table 65 - Containter requirements,
> X::iterator is required to be convertible to X::const_iterator.
>
> Since the X::const_iterator supports ==, I think the expression
> must be valid.

This is kind of where this whole thing started.  The standard says that
X::const_iterator supports ==, but I can't find anything which says that this
should be implemented as a global function operator==(X::const_iterator,
X::const_iterator) or as a member function X::const_iterator::operator==
(X::const_iterator).  (Maybe this is deliberate ?)

If the first case were always true, we could deduce that "(i == ci)" is valid
by your reasoning.  If an implementation chooses (?) to implement == with
member variables for X::iterator and X::const_iterator, then "i" won't be
converted to a const_iterator (will it ?) and there seems to be nothing to
suggest that X::iterator should have a member variable for comparison with
X::const_iterator.  Ah well ....

- Phil

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

actually neither of them will work...
there is no implicit type conversions done in either case because  implicit
type
conversions only work when dealin with primitive types...  and since neither
const_iterator or iterator are primitive types neither will work...
also, depending on which iterator/const_iterators u are using I am pretty
sure
that the == operator is not defined for any iterators, only the !=....
of course unless u made the iterator class....
and if u did, u would then be able to get both of your examples to work by
overloading...
hope I helped...



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Roger Williams wrote:
>
> actually neither of them will work...
> there is no implicit type conversions done in either case because  implicit
> type
> conversions only work when dealin with primitive types...

I think you're confusing implicit conversions with standard conversions.
An implicit conversion sequence may contain a maximimum of one
user-defined conversion, with an optional standard conversion sequence
before or after (or both). A user-defined type cast operator overload
may be used to provide an implicit conversion to or from a user-defined
type. A conversion constructor that isn't declared 'explicit' may be
used to provide a user-defined implicit conversion to a user-defined
type.

> ... and since neither
> const_iterator or iterator are primitive types neither will work...

For many containers, const_iterator and iterator will be primitive
types: 'const T*' and 'T*'.

> also, depending on which iterator/const_iterators u are using I am pretty
> sure
> that the == operator is not defined for any iterators, only the !=....

Output iterators are required to support neither == nor !=; all other
iterators must support both.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

if u were to look at templates such as vector, set, map, stack, etc...
then u would see that only the != operators are assigned...
which allows for the p!=x.end() command to work...
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7fp96l$c28$1@geraldo.cc.utexas.edu>,
  "Roger Williams" <rwilliams@wt.net> wrote:
> if u were to look at templates such as vector, set, map, stack, etc...
> then u would see that only the != operators are assigned...
> which allows for the p!=x.end() command to work...

The C++ STANDARD clearly states in section 24.1.1 that all input iterators
(and hence forward iterator, bidirectional iterators and random access
iterators) support both the == and != operator.  If your implementation
doesn't then I guess it's not implementing the Standard.


I'm getting rather confused by the variety of postings to this thread.  There
seems to be very little agreement about fairly fundamental things.  (I know
it's a tricky area - that's why I posed the original question).


Ignoring implementation issues the moment, does anybody know whether the C++
Standard either 1) explicitly allows, 2) explicitly disallows, or 3) does not
specify the validity of the expression:

 (i == ci)

where i is of type T::iterator, ci is of type T::const_iterator for some
container class T, and both i and j have valid values in the range [begin(),
end ()) ?

If anyone does and can point me to a section in the Standard, I'd love to
know!

- Phil Brabbin

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7fp96l$c28$1@geraldo.cc.utexas.edu>,
  "Roger Williams" <rwilliams@wt.net> wrote:
> if u were to look at templates such as vector, set, map, stack, etc...
> then u would see that only the != operators are assigned...
> which allows for the p!=x.end() command to work...

If you (this is the correct spelling of the word, by the way, not "u") look
at table 74 in the Standard (section 24.1.3), it outlines forward iterator
requirements.  A forward iterator is required to implement both operator ==
and operator !=.  The text under table 74 states "if iterators a and b are
both dereferenceable, then a==b if and only if *a and *b are the same
object." Random iterators and bidirectional iterators are required to
implement everything a forward iterator implements.

A container, by the way, is also required to implement both == and !=
according to table 65 (section 23.1), so if your STL implementation does not
implement == for iterators or containers it is a non-standard implementation.

--
Jim
I ignore all email from recruitment agencies.
Please do not send me email with questions - post here.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Philip Brabbin wrote:
>
> > I recently came across a problem trying to compare a const_iterator
> > and and iterator, and have been unable to resolve my problem.
> >
> >         const_iterator ci;
> >         iterator i;
> >
> >         if (ci == i)    // is this legal ?
>
> >         if (i == ci)    // is this legal ?
>
> > Ignoring the context and initialisation of the above iterators, this
> > is my situation.  Are the above iterator comparisons equivalent, and
> > if not, why not ?
>
> That's an interresting question. These are equivalent as they
> are equaly not defined. You can only compare two iterators of
> the same type.
>
> > I think I'm okay to do the following expansion of the above to
> >
> >         if (ci.operator==(i))
> > and
> >         if (i.operator==(ci))
> >
> > The first case should be okay since there is an implicit conversion
> > from iterator to const_iterator.
>
> It might be, but need not be

I think container requirement (23.1/5, table 65). So it seems that
ci == i is actualy a comparison betwen iterator of the same type
(X::const_iterator). But for (i == ci) .... ? (only work if the
operator is global ?)

Alain


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]