Kresimir Fresl wrote:
>
> Pete Becker wrote:
>
> > But I'll tell you what: you needn't reply. I learned long ago
> > that when message threads start consisting of quoting previous
> > messages in order to argue about the meaning of what someone
> > said, it's usually time to drop the discussion.
>
> I agree. But I will reply anyway: At least be honest enough
> and quote complete *relevant* part of an answer.
>

If you're going to publicly accuse someone of dishonesty, at least have
the decency to point to what you think is a delibereate
misrepresentation. This sort of generic accusation has no place in any
civilized discussion.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)


======================================= MODERATOR'S COMMENT:

Because the dicussion has become heated, further postings in
this thread that involve personalities, motives, or terms of
discourse will be rejected.  The moderators will be paying
close attention to this thread to make sure that the
discussion doesn't get out of hand.

---
[ 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:
>
> However, when I point out a non-conforming feature, the response I want
> to hear is "thank you, we'll fix that as soon as we can fit it into our
> schedule", not "that's a silly example, ask us to fix it when you find
> some real code that doesn't work with our compiler".
>

This is a useful extension (try rewriting your example to take advantage
of it), and as far as I can see, if you run into a problem with it it's
trivial to work around it (all it takes is a cast, as I pointed out
earlier (hmm, can't find that message: did you see a response to your
example a day or so after you posted it?)). We've discussed this, and
don't plan to change it. So I won't tell you that we'll fix it as soon
as we can fit it in. <g>

If someone sent private e-mail with a question or comment about this
they would have received a response that was appropriate for such a
submission. Asking a question in a public forum is not the same thing --
I view that as an invitation to an open discussion.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker <petebecker@acm.org> writes:

|>  Matt Austern wrote:

|>  >     #define T   1
|>  >     #define Tp  2
|>  >     #define a   3
|>  >     #define tmp 4
|>  >     #include <algorithm>
|>  >     int main() {}

|>  > Silly?  Yes, of course.

|>  No, not at all. It's a simple example of a real-world problem. While
|>  the example itself is forced, its generalization is obvious: header
|>  files define macros, and those macros can interfere with names used
|>  in the standard libraries. The generalization of Biju Thomas's
|>  example is not at all obvious. In fact, nobody has suggested any use
|>  for it except in contrived examples.

A second point, of course, is that changing all internal names to begin
with an underscore cannot possibly break user code; removing an
extension because it is revealed non-conforming will break any user code
which uses the extension.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

Kresimir Fresl wrote:
>
> Obviously, some of us also `have missed a step here'. It is
> a step where you admit that your implementation is non-conforming
> without any fuzzy reference to `silly' examples which can cause
> problems.
>

Your misperception seems to be the result of failing to understand the
difference between a conforming usage and the degree of conformance of a
library. Unless, of course, you take James Kuyper's argument to its
extreme, and refuse to use any library that has a non-void return for
map::erase without regard to any other aspect of its conformance to the
C++ standard.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:

> Your misperception seems to be the result of failing to understand
> the difference between a conforming usage and the degree of
> conformance of a library.
> Unless, of course, you take James Kuyper's argument to its
> extreme, and refuse to use any library that has a non-void return for
> map::erase without regard to any other aspect of its conformance to
> the C++ standard.

Yes. As somebody already said, conformance is not a fuzzy term
and therefore there is no `degree of conformance' -- something
either conforms to the standard or not (`characteristic function'
of set `conforming implementation' can take only values
0 or 1, i. e. `no' or `yes'). There are no `other aspects of its
conformance'. After all, Biju Thomas and James Kuyper wrote
examples with, as you said, `conforming usage'.

But let's try to take your point of view. From the vigour with
which you defend your implementation and your point of view
follows that that implementation is `better/more useful'
(you can put here any similar fuzzy word) than what standard
requires. Would you be so kind to show us some real (not `silly')
example which proves your assertation. That is, something
that can be done with your library, but is considerably more
difficult to do with standard library.

Otherwise, your claims are as `silly' as Biju Thomas' example.

fres

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

Kresimir Fresl wrote:
>
> Pete Becker wrote:
>
> > Kresimir Fresl wrote:
>
> > > Pete Becker wrote:
>
> > > > I'm getting tired of saying this. I agree that the implementation
> > > > does not conform.
>
> > > Since when? In your first reply you wrote:
>
> > > ``[...] the correct answer is that it's a conforming extension.''
>
> > Since some time after that, obviously. Read my reply to Biju Thomas's
> > example.
>
> Well, here it is:
>
> > > > > Are you saying that the following program is non-conforming?
>
> > > > No, just silly. <g>
>
> How else can one understand your words save that you stubbornly
> claim that your implementation *do conform* because only in silly
> programs non-conformance can appear, and silly programs don't count.
>

How else can anyone possibly understand "are you saying that the
following program is non-conforming?" "No" as saying anythign other than
that the program conforms? But I'll tell you what: you needn't reply. I
learned long ago that when message threads start consisting of quoting
previous messages in order to argue about the meaning of what someone
said, it's usually time to drop the discussion.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Kresimir Fresl wrote:
>
> But let's try to take your point of view. From the vigour with
> which you defend your implementation and your point of view
> follows that that implementation is `better/more useful'
> (you can put here any similar fuzzy word) than what standard
> requires. Would you be so kind to show us some real (not `silly')
> example which proves your assertation.

I've made no such assertion in this thread. But IBM, Intel, and
Microsoft think it's good enough to include with their compilers.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Kresimir Fresl wrote:
>
> Pete Becker wrote:
>
> > Your misperception seems to be the result of failing to understand
> > the difference between a conforming usage and the degree of
> > conformance of a library.
> > Unless, of course, you take James Kuyper's argument to its
> > extreme, and refuse to use any library that has a non-void return for
> > map::erase without regard to any other aspect of its conformance to
> > the C++ standard.
>
> Yes. As somebody already said, conformance is not a fuzzy term
> and therefore there is no `degree of conformance' -- something
> either conforms to the standard or not (`characteristic function'
> of set `conforming implementation' can take only values
> 0 or 1, i. e. `no' or `yes'). There are no `other aspects of its
> conformance'.

You ought to take a look at comp.lang.c++, where several times a week
people ask "what's the most conforming compiler," and other people try
to give them answers that actually try to compare compilers. I have yet
to see anyone say "there is no degree of conformance" in such a reply.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker <petebecker@acm.org> writes:

> Kresimir Fresl wrote:
> >
> > But let's try to take your point of view. From the vigour with
> > which you defend your implementation and your point of view
> > follows that that implementation is `better/more useful'
> > (you can put here any similar fuzzy word) than what standard
> > requires. Would you be so kind to show us some real (not `silly')
> > example which proves your assertation.
>
> I've made no such assertion in this thread. But IBM, Intel, and
> Microsoft think it's good enough to include with their compilers.

I think we're talking at cross purposes here.  Pete is answering the
question: How should you decide what library to buy?, or maybe the
question: Is the Dinkumware library any good?  Those questions are
interesting, but I don't think anyone else is asking them.

Most of the other people in this thread are asking the much narrower
question: By a strict reading of the standard, is an alternate return
type for map<>::erase a conforming or a nonconforming extension?  That
question may or may not be important, but this is a standards
newsgroup; playing language lawyer is what we're here for.

I agree that the alternate return type is nonconforming only for
minute, technical reasons.  Library implementors worry about minute
technical things, though.  For example, here's a snippet from my
library:
    template <class _Tp>
    inline void swap(_Tp& __a, _Tp& __b) {
      __STL_REQUIRES(_Tp, _Assignable);
      _Tp __tmp = __a;
      __a = __b;
      __b = __tmp;
    }

I know that Pete's library does something similar.  Why do both of us
do something so ugly?  Why not use more straightforward, more readable
names, instead of littering this function with underscores?  Solely
because of strict standard conformance.  It's because, according to a
strict reading of the standard, users are permitted to write this
program:
    #define T   1
    #define Tp  2
    #define a   3
    #define tmp 4
    #include <algorithm>
    int main() {}

Silly?  Yes, of course.  It's a legal program, though, and an
implementation that failed to compile it wouldn't be conforming.
Would this failure to conform matter?  Hard to say.  Before I
"uglified" my headers, I didn't get any complaints from customers who
were desperate to define macros like 'tmp' and 'ForwardIterator'
before including standard headers.  I know that some library vendors
still haven't uglified their headers; they say that they don't receive
customer complaints about this either.  We decided to make this
change, though, even though we weren't sure it mattered, because we
wanted to come closer to strict standard conformance.

Note that a library with nonconforming extensions may still be a good
library.  I hope so; I've got nonconforming extensions in my C++
library implementation too.  Some of those nonconforming extensions
are very much like this map<>::erase() business: I mistakenly believed
that they were conforming extensions.

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

Pete Becker <petebecker@acm.org> said:
> > > > ...the correct answer is that ... [returning an iterator
> > > > instead of void is] a conforming extension.

> > Christopher Eltschka asked:
> > > Really?
> > > Then, in what way is the following code non-conforming?
> > >
> > > #include <map>
> > >
> > > int main()
> > > {
> > >    typedef std::map<int, int> iimap;
> > >    typedef iimap::iterator iter;
> > >
  //This vvvvvvvvvvvvvvvvvvvvvvvvvvvv is non-conforming
> > >    void (iimap::*f)(iter, iter);
> > >    f = &iimap::erase;
  //This ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ is non-conforming
> > >
> > >    iimap m;
> > >    m[1]=1;
> > >    m[2]=2;
> > >    m[3]=3;
> > >    (m.*f)(m.begin(), m.end());
> > > }
> > >
> > > After all, it would fail with the changed signature.

> Pete Becker <petebecker@acm.org> answered:
> > Yup, sure would. See clause 17.4.4.4/2: an implementation
> > is permitted to add arguments with default values to a
> > non-virtual member function.
> > As note 172 somewhat ungrammatically says, this implies
> > that "taking the
> > address of a member function has an unspecified type." Since
> > you cannot count on the signature of a non-virtual member
> > function, adding a return value to such a function that is
> > specified to return void is conforming.

Then questionguy@my-deja.com added:
> 17.4.4.4
>
> 2 An implimentation can declare additional non-virtual
> member function signatures within a class:
...
> I would say
>
> "an implimentation is permited to add additional function signatures
> in one of three ways. One of these ways is to overload
> the member function and add additional arguments with default
> values..."
>
> which interpretation is correct ?

But you're missing the point. The code that I marked is already
invalid. The specific rule broken is that you can't rely on the
argument types of the member function, but the stated implication
is that you can NEVER declare a data type for the pointer. Ever!
Anything that you can do to rely on the return type being void
will also rely on the argument types being cast in stone, and
that part is simply wrong.

When you compile this on a brand-M compiler, an error message
will tell you that the return type is incorrect. But the
wording of the error message isn't part of the standard. The
fact is, you broke the rules and you got an error.

The rules say that you can't portably declare a data type to
hold a pointer to the erase() member function. So long as you
play by the rules, everything works. If that doesn't make the
extension conforming, what does?

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

> Bob Withers <bwit@pobox.com> wrote:
> > Granted it wasn't a big problem, I simply changed
> >
> > i = m.erase(i);
> >
> > to
> >
> > m.erase(i++);

sirwillard@my-deja.com wrote:
> It seems to me that your alternative won't work. map::erase gets
> called, so the iterator becomes invalid, and _then_ you increment it.
> I can fully understand why it appears to work under most
> implementations, but I bet this will bite you hard some time. I'm sure
> this is why the extension was added.

No. There is a sequence point after all arguments have been
evaluated (i++) and before the function is called. So i has been
incremented before the old element is erased.

> To really do this portably would
> require two lines and a temporary.
>
> iterator temp = i++; // assuming iterator is a typedef
> m.erase(temp);

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Pete Becker <petebecker@acm.org> wrote:

> Sigh. Once again: silly examples do not contribute to decisions about
> which of two libraries are "more" conforming. Ignore silly examples and
> focus on real differences.

AFAICS this is your misunderstanding (at least most other people on this
thread don't seem to share this view).

Your point (which may or may not be valid) is: Silly examples do not
contribute to decisions about which of two libraries are more _useful_
or fit for a particular purpose, but 'real' differences do.

The point of most people on this thread is: It is a simple
yes/no-question (no 'decision' involved) whether an implementation or
library is conforming in a certain respect (unless the standard is
unclear or ambiguous, in which case a DR is in order).

Any counterexample (however silly) can show that a certain extension is
not conforming.
This is only a question of technicalities and picking nits.
Even if a non-conforming extension proves useful, it will stay
non-conforming for at least another (8,9, 10 ?) years.

Whether one library is 'more' conforming than another, is a meaningful
question only in rare cases - if their non-conformant features have a
super-/subset relation. This is only a partial ordering.

Whether the set of deviations from the standard of one library impacts
its usefulness more or less than another's, is a different question -
which may also have a different answer for different customers

It is reasonable that the question of usefulness is more important to
you. But in this group the focus often is on the technicalities.

--
J   rg Barfurth                         jbarfurth@vossnet.de
----------------   using std::disclaimer;------------------------------
Software Engineer                     joerg.barfurth@germany.sun.com
Star Office GmbH                       http://www.sun.com/staroffice

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

Pete Becker <petebecker@acm.org> wrote:
> Yes, we probably need to make it clearer in our documentation
> that [non-standard return types] is an extension.

AFAIK, every single implementation of C++ library templates
documents extensions along with standard features, without
drawing sufficient (or sometimes ANY) attention to the fact
that they are not standard.

I suppose that writing documentation that is both thorough and
comprehensible is a rather daunting task, but this particular
detail does seem important. As on-line programming tools become
more and more helpful, we're starting to take on-line help for
granted. But if the on-line help doesn't point out details like
this, we may still have to have a copy of the C++ standard by
our side at all times. This is not the way that things should
work.

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Matt Austern wrote:
>
>     #define T   1
>     #define Tp  2
>     #define a   3
>     #define tmp 4
>     #include <algorithm>
>     int main() {}
>
> Silly?  Yes, of course.

No, not at all. It's a simple example of a real-world problem. While the
example itself is forced, its generalization is obvious: header files
define macros, and those macros can interfere with names used in the
standard libraries. The generalization of Biju Thomas's example is not
at all obvious. In fact, nobody has suggested any use for it except in
contrived examples.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker <petebecker@acm.org> wrote:

> The assertion was that you can take the address of a member function in
> order to assign it to a pointer to member function, and if the
> assignment fails, then you know that the declaration does not conform to
> the standard. A compilation failure, however, does not distinguish
> between a different return type and a different argument list. Since the
> argument list is allowed to be different, this test does not detect
> non-conformance. If you disagree, please show how you would do it. You
> must be able to distinguish these two cases:

Just a remark: The assertion stated above was not (at least not in this
subthread). I just reread the full sequence of posts in this subthread -
nowhere was there any real argument referring to pointers to members.

That discussion happened only in other subthreads (which are much
shorter than this one).

> requirement: void C::f(int)
> implementation 1: void C::f(int, int = 0)
> implementation 2: int C::f(int)

BTW: the answer by Hyman Rose fully answers the challenge (you didn't
give us an unbounded set of overloads <g>).


--
J   rg Barfurth                         jbarfurth@vossnet.de
-----------------         using std::disclaimer;     ------------------
Software Engineer                     joerg.barfurth@germany.sun.com
Star Office GmbH                       http://www.sun.com/staroffice

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

Matt Austern wrote:

> Pete Becker <petebecker@acm.org> writes:

> > Kresimir Fresl wrote:

> > > But let's try to take your point of view. From the vigour with
> > > which you defend your implementation and your point of view
> > > follows that that implementation is `better/more useful'
> > > (you can put here any similar fuzzy word) than what standard
> > > requires. Would you be so kind to show us some real (not `silly')
> > > example which proves your assertation.

> > I've made no such assertion in this thread. But IBM, Intel, and
> > Microsoft think it's good enough to include with their compilers.

(A question to Mr. Becker: did IBM, Intel, and Microsoft
choose Dinkumware because of (nonconforming) extensions?
Does anyone in IBM, Intel, or Microsoft know about changed
return value of `map::erase()'?)

> I think we're talking at cross purposes here.  Pete is answering the
> question: How should you decide what library to buy?, or maybe the
> question: Is the Dinkumware library any good?  Those questions are
> interesting, but I don't think anyone else is asking them.

Well, that was my question: I asked Mr. Becker to give an example
why will someone decide to buy Dinkumware and not some other
(standard conforming) library.

> Note that a library with nonconforming extensions may still be
> a good library. I hope so; I've got nonconforming extensions
> in my C++ library implementation too.

Is it possible to have both worlds? With, for example, `#ifdef':

#ifdef _CONFORMING_

// conforming inplementation

#else

// nonconforming extension

#endif

> Some of those nonconforming
> extensions are very much like this map<>::erase() business:
> I mistakenly believed that they were conforming extensions.

Will these extensions (or some of them) be in the next version
of your library (maybe with some `#ifdef' guard)? And in current
version, are they documented as extensions?


fres

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

Joerg Barfurth wrote:
>
> Pete Becker <petebecker@acm.org> wrote:
>
> > Sigh. Once again: silly examples do not contribute to decisions about
> > which of two libraries are "more" conforming. Ignore silly examples and
> > focus on real differences.
>
> AFAICS this is your misunderstanding (at least most other people on this
> thread don't seem to share this view).
>
> Your point (which may or may not be valid) is: Silly examples do not
> contribute to decisions about which of two libraries are more _useful_
> or fit for a particular purpose, but 'real' differences do.

Yes, that's what I've said.

>
> The point of most people on this thread is: It is a simple
> yes/no-question (no 'decision' involved) whether an implementation or
> library is conforming in a certain respect (unless the standard is
> unclear or ambiguous, in which case a DR is in order).

That's fine, too. I haven't disagreed with that.

>
> Any counterexample (however silly) can show that a certain extension is
> not conforming.
> This is only a question of technicalities and picking nits.
> Even if a non-conforming extension proves useful, it will stay
> non-conforming for at least another (8,9, 10 ?) years.
>
> Whether one library is 'more' conforming than another, is a meaningful
> question only in rare cases - if their non-conformant features have a
> super-/subset relation. This is only a partial ordering.

No, it's a common question, and usually means does the set of deviations
from the standard of one library impact its usefulness more or less than
another's.

>
> Whether the set of deviations from the standard of one library impacts
> its usefulness more or less than another's,
> is a different question -

Different from what? Not from the statement I've made, that some people
keep telling me is wrong, namely that choosing between libraries should
be based on assessment of the impact of differences from the standard,
not from counting the differences.

> which may also have a different answer for different customers
>
> It is reasonable that the question of usefulness is more important to
> you. But in this group the focus often is on the technicalities.

Fine. If you don't want to talk about the significance of differences
from the standard, don't respond to my messages. But don't tell me that
I'm wrong if you prefer counting them to understanding their impact.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:

> But I'll tell you what: you needn't reply. I learned long ago
> that when message threads start consisting of quoting previous
> messages in order to argue about the meaning of what someone
> said, it's usually time to drop the discussion.

I agree. But I will reply anyway: At least be honest enough
and quote complete *relevant* part of an answer.

f.

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

Pete Becker wrote:

> You ought to take a look at comp.lang.c++, where several times
> a week people ask "what's the most conforming compiler," and other
> people try to give them answers that actually try to compare
> compilers. I have yet to see anyone say "there is no degree of
> conformance" in such a reply.

Maybe I am wrong, but i think that this is completely different
thing.

Standard introduced many new issues in the language. Therefore
they can't be implemented in one day. When someone asks "what's
the most conforming compiler", he asks "what's the most conforming
compiler *now*". In particular compiler some parts of the standard
are implemented and some are not. If compiler covers larger part
of the standard, it can be said that it is `more conforming'.

But return type of `map::erase()' can be either `void'
(as standard says) or `map::iterator'. It can't be half
`void' half `iterator'.

fres

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

Pete Becker wrote:
>
> Matt Austern wrote:
> >
> >     #define T   1
> >     #define Tp  2
> >     #define a   3
> >     #define tmp 4
> >     #include <algorithm>
> >     int main() {}
> >
> > Silly?  Yes, of course.
>
> No, not at all. It's a simple example of a real-world problem. While the
> example itself is forced, its generalization is obvious: header files
> define macros, and those macros can interfere with names used in the
> standard libraries. The generalization of Biju Thomas's example is not
> at all obvious. In fact, nobody has suggested any use for it except in
> contrived examples.

I don't see how my example was any more contrived than the above. As
long as the standard defines erase() to return different types for
different container types, yet with similar semantics, there will be a
motivation for templated functions like the one I constructed.

---
[ 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:
>
> Pete Becker wrote:
> >
> > Matt Austern wrote:
> > >
> > >     #define T   1
> > >     #define Tp  2
> > >     #define a   3
> > >     #define tmp 4
> > >     #include <algorithm>
> > >     int main() {}
> > >
> > > Silly?  Yes, of course.
> >
> > No, not at all. It's a simple example of a real-world problem. While the
> > example itself is forced, its generalization is obvious: header files
> > define macros, and those macros can interfere with names used in the
> > standard libraries. The generalization of Biju Thomas's example is not
> > at all obvious. In fact, nobody has suggested any use for it except in
> > contrived examples.
>
> I don't see how my example was any more contrived than the above. As
> long as the standard defines erase() to return different types for
> different container types, yet with similar semantics, there will be a
> motivation for templated functions like the one I constructed.
>

If I were writing some sort of utility type that could be implemented
with an arbitrary container and that provided an erase function I'd
decide, as part of the design, whether erase should return an iterator.
If not, the implementation is obvious: just ignore the return value of
the container's erase function. If I decided that erase should return an
iterator I'd write erase to synthesize one when the container's erase
doesn't provide it (implementation details are left as an exercise for
the reader <g>). That localizes the difference in the return types, and
provides a uniform interface to users of the template. In turn, that
simplifies code that uses the template and simplifies the implementation
of the template itself.

In short, I think it's a design mistake to propogate the difference in
return types outside of a template that uses a container.

Matt's example, on the other hand, shows something that cannot be
attributed to a design mistake (unless you regard any use of macros as a
design mistake, and I don't think anyone has gone that far yet).
User-written headers can and often do define macros. So code like this:

#include "user.h"
#include <algorithm>

can mysteriously fail if the implementor of <algorithm> hasn't taken
appropriate precautions. (It's happened to me, and it's maddening: the
error messages don't make sense, and they point to the "wrong" file).

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Kresimir Fresl wrote:
....
> Maybe I am wrong, but i think that this is completely different
> thing.
>
> Standard introduced many new issues in the language. Therefore
> they can't be implemented in one day. When someone asks "what's
> the most conforming compiler", he asks "what's the most conforming
> compiler *now*". In particular compiler some parts of the standard
> are implemented and some are not. If compiler covers larger part
> of the standard, it can be said that it is `more conforming'.
>
> But return type of `map::erase()' can be either `void'
> (as standard says) or `map::iterator'. It can't be half
> `void' half `iterator'.

However, half the 'void' member functions defined by the standard could
be actually void, and the other half could have return types. I'm not
just being facetious; the comment is actually relevant. If there's one
such extension, there are probably others. The conformance problems of
one of the other extensions might allow a more clearly reasonable
counter-example than the one I came up with.

I said that conformance is a "yes" or "no" issue, but for real compilers
it's usually "no". The question then becomes, "How close does it come to
conforming?". That is a "more or less" issue. I perfectly agree with
Pete that some forms of non-conformance are more important than others,
and conformance isn't the only important feature of an implementation.
However, when I point out a non-conforming feature, the response I want
to hear is "thank you, we'll fix that as soon as we can fit it into our
schedule", not "that's a silly example, ask us to fix it when you find
some real code that doesn't work with our compiler". I want to believe
it stands a chance of being fixed before it breaks "real code". Now,
what actually gets done about the problem, and when, might be the same
in both cases, but I prefer the attitude expressed by the first
response.

---
[ 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:
>
> Pete Becker wrote:
> ....
> > Nope, we're talking practicalities. Conformance is not a matter of
> > counting, but of evaluating. Making silly examples work is low on my
> > list of priorities, and I'm quite sure this would not be a deal-breaker
> > for any library purchaser.
>
> The silliness of an example doesn't matter. The following is a very
> silly program:
>
>         int main()
>         {       return 0;       }
>
> I hope that if I were to lodge a valid complaint about this program not
> compiling correctly, you wouldn't dismiss the complaint just because the
> program is so silly (Note: I said "a valid complaint").
>

I don't equate simple with silly, and I don't regard this program as
silly. Here's an example of silly:

int i = 3 //* silly syntax */
 +4;

If someone objected to // comments on the grounds that they change the
meaning of this code nobody would take the objection seriously, because
this is such a narrowly limited case and would never occur in practice.
So far I haven't seen any serious attempt to get return map::erase(xxx)
out of that category.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Biju Thomas wrote:
>
> Pete Becker wrote:
> >
> > Like it or not, the standard does not
> > require that non-virtual members have the exact signature set out in the
> > standard.
>
> Pete, I am sure that you know this: The return type of functions don't
> form the part of a function signature;

That's one definition of "signature." I was using it more broadly, and I
thought its meaning was clear from the context.

> only the parameters' types and
> the cv qualifier participate in the definition of function signature.
> Repeating the above to justify the behaviour of your library doesn't
> make it conforming :-)
>
> The part of the standard that refers to this, 17.4.4.4, talks only about
> conforming extensions to signatures, and not to the return type
> specification of functions.
>

The context of this particular sub-thread was creating a pointer to a
member function. Since you cannot know the actual argument list for a
non-virtual member function, you cannot create a pointer of the correct
type. Since you cannot create a pointer of the correct type, you cannot
use a pointer to determine whether the return type is the same as what
the standard says.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
>
> Darin Adler wrote:
....
> > presumably your reasoning was that no correct program could detect that
> > the signature was different. This surprised many of us. Even though the
> > standard was specific about the return value type, you pointed out that
> > your implementation could get away with a different type because of what
> > seemed to many of us to be an obscure technicality.
>
> Well, it's obscure if you haven't read it. And every discussion of
> details turns on "techicalities." Like it or not, the standard does not
> require that non-virtual members have the exact signature set out in the
> standard. Calling this a "technicality" doesn't change that.

However, the only freedom that it explicitly gives is to change
signatures is in the argument list; permission to change the return type
is something you derived by what seems to be an appeal to the 'as-if'
rule.

....
> said no. I also said, in effect, that his example was a tiny corner
> case, and that it didn't seem particularly important. I stand by that

A small but important fraction of the features of the C++ standard are
used by almost everyone; most of the other features are each used by
only a tiny fraction of the users. You can dismiss almost any of them as
a 'tiny corner case'. Few users know how to correctly define global
operator new() and operator delete() functions; fewer still actually
need to. A lot of people never need to explicitly worry about locales.
I've met experienced C++ programmers who had no idea what a container or
an iterator was. Even the ones who do usually consider std::bind2nd() to
be quite esoteric. How many developers can correctly explain what
std::tanh() calculates? Except for locales, each of these examples seem
pretty simple to me, but they're all 'tiny corner cases' for many
developers.
That doesn't justify mis-implementing them.

> claim. If you disagree with it, provide a non-trivial example where
> being able to do what he did matters.

Being able to do what he did breaks the 'as-if' argument. Most failed
'as-if' arguments are shown to fail by the use of fairly silly example
code. Just because it's silly doesn't mean that the argument didn't
fail.

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

Pete Becker wrote:
>
> James Kuyper wrote:
> >
> > Pete Becker wrote:
> > >
> > > Biju Thomas wrote:
> > > >
> > > >
> > > > Are you saying that the following program is non-conforming?
> > >
> > > No, just silly. <g>
> >
> > Well, silliness isn't relevant to standard conformance.
>
> Sure it is. If you had a choice of a library whose map::erase function
> did nothing, but had the right signature, and a library whose map::erase
> function actually erased the specified element but had the "wrong"
> signature, would you say that there is no difference in their
> conformance to the standard? Conformance is not a matter of counting
> differences, but of assessing their importance.

A more relevant comparison is a library that does the right thing with
the right function signature, and a library that does the right thing
but with the wrong function signature. I'd unambiguously choose the
former.

Conformance is a yes/no issue (which decays, in ambiguous contexts, to
an unknown truth value). Some kinds of non-conformance are more
important than others, but that's a different question.

Consider a guy who steals a kid's lunch money. The kid says "You stole
my money!" The guy says "That's not theft; it's not enough money to
matter." It is still theft. And this case is still non-conformance.

> > Most examples
> > that show a basic principle are fairly silly, in themselves. However,
> > since they represent something that's legal, sooner or later they will
> > come up in well-motivated design.
> >
> > Code such as he gave could reasonably occur inside the expansion of
> > template, where the return type of the member function (and therefore of
> > the template function as well) is a template parameter.
>
> Example, please. I simply don't believe that any sensible design would
> call map::erase in a return statement.

You're asking me to take a feature of the library chosen essentially at
random, and come up with a context where the fact that it's been
mis-implemented will cause a well-justified design to fail. That's
intrinsically hard, and shouldn't be necessary. Showing any sample which
breaks should have been sufficient. I'll do my best, but I lack the
experience needed to come up with a good example.

=====================================================================
#include <deque>
#include <map>

template <class T> struct Recycler
{
    static std::deque<T> dq;
}

template <class ReturnType, class Container>
// For sequences, ReturnType must be Container::iterator
// For associative containers, ReturnType must be void
ReturnType recycle_in(Container &c, typename Container::iterator i)
{
    Recycler<typename Container::value_type>::dq.push_back(*i);
    return c.erase(i);
}

template <class Container> typename Container::iterator
recycle_out(Container &c, typename Container::iterator i)
{
    typename Container::value_type t =
        Recycler<typename Container::value_type>::dq[0]);

    Recycler<typename Container::value_type>::dq.pop_front();
    return c.insert(i, t);
}


// somewhere deep inside other code:

    std::map<int> intmap;
    intmap.insert(3);
    // The non-conformance of your implementation of
    // std::map<>::erase() makes the following line fail
    recycle_in<void> (intmap, intmap.begin());

=====================================================================

I've left out lots of details, such as exception and error handling
(like what happens if you call recycle_out<> when the Recycler is
empty). This is untested code, so I wouldn't be surprised if it has
coding defects. All that matters is the basic intent, which I hope is
clear. I'm not saying this a great design, or a common need. Certainly
there are other ways to design it that would avoid the defects in your
implementation. However I don't think it's a completely unreasonable
design, and I don't think it's acceptable to require people to design
around those defects.

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

questionguy@my-deja.com wrote:
>
> In article <38DA6066.D4EB2717@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
> > Christopher Eltschka wrote:
> > >
> > > Pete Becker wrote:
> > > >
> > > >
> > > > I can't speak to the answer you got in 1998, but the correct
> answer is
> > > > that it's a conforming extension.
> > >
> > > Really?
> > > Then, in what way is the following code non-conforming?
> > >
> > > #include <map>
> > >
> > > int main()
> > > {
> > > typedef std::map<int, int> iimap;
> > > typedef iimap::iterator iter;
> > >
> > > void (iimap::*f)(iter, iter);
> > >
> > > f = &iimap::erase;
> > >
> > > iimap m;
> > > m[1]=1;
> > > m[2]=2;
> > > m[3]=3;
> > > (m.*f)(m.begin(), m.end());
> > > }
> > >
> > > After all, it would fail with the changed signature.
> > >
> >
> > Yup, sure would. See clause 17.4.4.4/2: an implementation is permitted
> > to add arguments with default values to a non-virtual member function.
> > As note 172 somewhat ungrammatically says, this implies that "taking
> the
> > address of a member function has an unspecified type." Since you
> cannot
> > count on the signature of a non-virtual member function, adding a
> return
> > value to such a function that is specified to return void is
> conforming.
>
> I looked into it.
>
> 17.4.4.4
>
>   2  An implimentation can declare additional non-virtual
>      member function signatures within a class:
>
>     -- by adding arguments with defualt values to a member
>        function signature; (172) The same latitude does  not
>        extend to the implimentation of virtual or global functions,
>        however.
>
>     -- by replacing a member function signature with defualt
>        values by two or more member function signatures with
>        equivalnet behavior.
>
>     -- by adding a member function signature for a member function name.
>
> Well, I am no expert at reading the standard but it seems to me that
> the first line, grants you permission only to _add additional_ member
> function definitions (note the word "additional"). My
> interpretation stops right there.  You read it as:
>
> an implementation is permitted to add arguments with default values...
>                                   ^^^ ^^^^^^^^^
>                                   ??? ?????????
>
> I would say
>
> "an implimentation is permited to add additional function signatures
>  in one of three ways.  One of these ways is to overload
>  the member function and add additional arguments with default
>  values..."
>
> which interpretation is correct ?
>

Here's what that last version produces:

class C
{
public:
void f(int); // "standard" version
void f(int, int = 0); // "overloaded" version
};

C c;
c.f(3); // ambiguous

So that can't be the right one. This clause was intended to allow
implementors a bit more flexibility by permitting additional arguments,
so long as they have default values. That way, user code that calls the
function doesn't need to be aware of the extra arguments, but internal
code that calls it can use those extra arguments:

class C
{
public:
void f(int, int = 0);
};

C c;
c.f(3); // works, whether or not f has addiitonal default arguments

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ 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 Thu, 30 Mar 2000 20:32:22 CST, hinnant@anti-spam_metrowerks.com
(Howard Hinnant) wrote:

: Is it a useful extension?  Perhaps.  It would be nice if code like the
: following could be instantiated for all std::containers:
:
: template <class Container>
: void
: erase_all(Container& c)
: {
:    Container::iterator i = c.begin();
:    while (i != c.end())
:       i = c.erase(i);
: }
:
: Admittedly, clear obviates the need for this particlular example, but
: hopefully my point is made anyway.

Unfortunately, this example does work for vector<> where it is an
order N^2 algorithm.  It works for list<> and is order N.  It does
not work for associatives where it would be order N.  It also works
for deque<> and is order N but erasing every other item would be
order N^2.  Maybe it would be best if it didn't work at all.  There
are order N algorithms for all containers, they just are not the
same and none of them are this one.

John

---
[ 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:
>
>
> > claim. If you disagree with it, provide a non-trivial example where
> > being able to do what he did matters.
>
> Being able to do what he did breaks the 'as-if' argument. Most failed
> 'as-if' arguments are shown to fail by the use of fairly silly example
> code. Just because it's silly doesn't mean that the argument didn't
> fail.
>

I'm getting tired of saying this. I agree that the implementation does
not conform. My point about the example being silly is that it does not
represent a significant class of program techniques. If you disagree,
please explain how you would use this in real code and why it would be
important to you to do so.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ 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:
>
> Pete Becker wrote:
> >
> > Darin Adler wrote:
> ....
> > > presumably your reasoning was that no correct program could detect that
> > > the signature was different. This surprised many of us. Even though the
> > > standard was specific about the return value type, you pointed out that
> > > your implementation could get away with a different type because of what
> > > seemed to many of us to be an obscure technicality.
> >
> > Well, it's obscure if you haven't read it. And every discussion of
> > details turns on "techicalities." Like it or not, the standard does not
> > require that non-virtual members have the exact signature set out in the
> > standard. Calling this a "technicality" doesn't change that.
>
> However, the only freedom that it explicitly gives is to change
> signatures is in the argument list; permission to change the return type
> is something you derived by what seems to be an appeal to the 'as-if'
> rule.

The assertion was that you can take the address of a member function in
order to assign it to a pointer to member function, and if the
assignment fails, then you know that the declaration does not conform to
the standard. A compilation failure, however, does not distinguish
between a different return type and a different argument list. Since the
argument list is allowed to be different, this test does not detect
non-conformance. If you disagree, please show how you would do it. You
must be able to distinguish these two cases:

requirement: void C::f(int)
implementation 1: void C::f(int, int = 0)
implementation 2: int C::f(int)

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
....
> That's one definition of "signature." I was using it more broadly, and I
> thought its meaning was clear from the context.

When discussing the standard, you can minimize confusion by sticking to
the standard's definitions, when if provides them. 1.3.10 doesn't match
your use.

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

Pete Becker wrote:
....
> I'm getting tired of saying this. I agree that the implementation does
> not conform. My point about the example being silly is that it does not
> represent a significant class of program techniques. If you disagree,
> please explain how you would use this in real code and why it would be
> important to you to do so.

Sorry, I don't write enough real C++ code to excersize every capability
of C++. Non-military scientific programming jobs that involve C++ seem
to be pretty scarce in my area; I've had to settle for a one which uses
my C, IDL, and Fortran skills instead.

However, last night I posted a reply to a different message, that
contains an extremely simplified example of what seems to me to be
plausible code that will break with your implementation. It just showed
up on my news server a few minutes ago. Take a look and tell me why you
think it's silly.
Of course it's silly; it's not real code. The time to fix this is before
it breaks real code.

---
[ 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:
>
> Pete Becker wrote:
> >
> > James Kuyper wrote:
> > >
> > > Pete Becker wrote:
> > > >
> > > > Biju Thomas wrote:
> > > > >
> > > > >
> > > > > Are you saying that the following program is non-conforming?
> > > >
> > > > No, just silly. <g>
> > >
> > > Well, silliness isn't relevant to standard conformance.
> >
> > Sure it is. If you had a choice of a library whose map::erase function
> > did nothing, but had the right signature, and a library whose map::erase
> > function actually erased the specified element but had the "wrong"
> > signature, would you say that there is no difference in their
> > conformance to the standard? Conformance is not a matter of counting
> > differences, but of assessing their importance.
>
> A more relevant comparison is a library that does the right thing with
> the right function signature, and a library that does the right thing
> but with the wrong function signature. I'd unambiguously choose the
> former.

Well, maybe, if that's the only difference between the libraries. But I
suspect that libraries will have much more significant differences for a
long time yet.

>
> Conformance is a yes/no issue (which decays, in ambiguous contexts, to
> an unknown truth value). Some kinds of non-conformance are more
> important than others, but that's a different question.

I must have missed a step here. What I've been saying for the past
couple of days is that some kinds of non-conformane are more important
than others, and that this particular one seems to me to be one of the
least important ones. I don't see how you can dismiss that as "a
different question."

>
> Consider a guy who steals a kid's lunch money. The kid says "You stole
> my money!" The guy says "That's not theft; it's not enough money to
> matter." It is still theft. And this case is still non-conformance.

Yes, and I agreed several days ago that this doesn't conform.

>
> > > Most examples
> > > that show a basic principle are fairly silly, in themselves. However,
> > > since they represent something that's legal, sooner or later they will
> > > come up in well-motivated design.
> > >
> > > Code such as he gave could reasonably occur inside the expansion of
> > > template, where the return type of the member function (and therefore of
> > > the template function as well) is a template parameter.
> >
> > Example, please. I simply don't believe that any sensible design would
> > call map::erase in a return statement.
>
> You're asking me to take a feature of the library chosen essentially at
> random, and come up with a context where the fact that it's been
> mis-implemented will cause a well-justified design to fail. That's
> intrinsically hard, and shouldn't be necessary. Showing any sample which
> breaks should have been sufficient.

Sufficient for what? It certainly isn't sufficient to demonstrate that
this return type affects actual non-trivial code.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
>
> James Kuyper wrote:
....
> > The silliness of an example doesn't matter. The following is a very
> > silly program:
> >
> >         int main()
> >         {       return 0;       }
> >
> > I hope that if I were to lodge a valid complaint about this program not
> > compiling correctly, you wouldn't dismiss the complaint just because the
> > program is so silly (Note: I said "a valid complaint").
>
> Sigh. Once again: silly examples do not contribute to decisions about
> which of two libraries are "more" conforming. Ignore silly examples and
> focus on real differences.

So if I'm testing two compilers, and one of them compiles and executes
this code correctly, and the other doesn't, I shouldn't use that
information in decide which one to use? Just because the test is too
"silly"?

....
> Then by all means use a library that better fits your particular needs.
> I suspect that whether map::erase has a return type is not the biggest
> factor in your decision, though. If it is, let me know: we'll be glad to
> give you a version that doesn't have it.

That's not my decision to make, but even if it were I would consider it
a bad sign that this needs to be fixed.

---
[ 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:
>
>
> template <class ReturnType, class Container>
> // For sequences, ReturnType must be Container::iterator
> // For associative containers, ReturnType must be void
> ReturnType recycle_in(Container &c, typename Container::iterator i)
> {
>     Recycler<typename Container::value_type>::dq.push_back(*i);
>     return c.erase(i);

Trivial workaround:

 return (ReturnType)c.erase(i);

> }
>
> // somewhere deep inside other code:
>
>     std::map<int> intmap;
>     intmap.insert(3);
>     // The non-conformance of your implementation of
>     // std::map<>::erase() makes the following line fail
>     recycle_in<void> (intmap, intmap.begin());
>
> =====================================================================
>
> I've left out lots of details, such as exception and error handling
> (like what happens if you call recycle_out<> when the Recycler is
> empty). This is untested code, so I wouldn't be surprised if it has
> coding defects. All that matters is the basic intent, which I hope is
> clear. I'm not saying this a great design

Of course. Simple code makes readable examples.

> or a common need.

I don't see what the need is here, since the return value from
recycle_in isn't used. The code adds a level of indirection to the erase
call, but what can you do with it? There still has to be code that knows
whether to expect a return value, and will be written differently
depending on whether you have it.

My inclination, if I were faced with writing a generic recycler, would
be to ignore the return value of erase for sequence containers. That way
the differences between the two container categories don't propogate
through the code. That makes it simpler and probably more robust.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ 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 Thu, 30 Mar 2000 20:34:43 CST, Biju Thomas <b.thomas@attglobal.net>
wrote:
>Pete, I am sure that you know this: The return type of functions don't
>form the part of a function signature; only the parameters' types and
>the cv qualifier participate in the definition of function signature.
>Repeating the above to justify the behaviour of your library doesn't
>make it conforming :-)

I believe I understand both your point of view and Pete's.

I think that Pete's comment, although it gets away somewhat from the
original question about changing the mandated return type of a standard
library function, is still relevant. Pete correctly points out that,
since the return type is part of the type of the function, therefore
changing the return type makes it impossible to portably take the
address of the function -- yet as he equally correctly points out it is
entirely nonportable anyway to attempt to take the address of any
nonvirtual member function in the standard library, because it's allowed
to have implementation-specific additional defaulted parameters. So
changing the return type doesn't take anything more away in terms of
portably forming a pointer to member function, since we can't do that
anyway.

(Note: The "signature" and the "type" of a function are not the same
thing. The word "signature" is (somewhat arbitrarily) defined to exclude
the return type. The "type" definitely includes the return type, since
you must mention the return type when stating the function's type, say
to declare a pointer to it.)

Having said all that, your other example about "return m.erase(...);"
does independently detect a nonconforming extension that changes the
return type. I have some sympathy for Pete's view that this is an
off-in-the-bushes corner case, but I do agree that changing the return
type does break some otherwise conforming code, even if no one would
ever write such code.

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

CTO, PeerDirect Inc. (http://www.peerdirect.com)
Chair, ANSI H2 Ad-Hoc for SQL Part 12: SQL/Replication
  (Replication working group, ANSI SQL committee)
Editor-in-Chief, C++ Report (http://www.creport.com)

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

Pete Becker <petebecker@acm.org> writes:
> The assertion was that you can take the address of a member function in
> order to assign it to a pointer to member function, and if the
> assignment fails, then you know that the declaration does not conform to
> the standard. A compilation failure, however, does not distinguish
> between a different return type and a different argument list. Since the
> argument list is allowed to be different, this test does not detect
> non-conformance. If you disagree, please show how you would do it. You
> must be able to distinguish these two cases:
>
> requirement: void C::f(int)
> implementation 1: void C::f(int, int = 0)
> implementation 2: int C::f(int)

It's easy :-)

template <typename C, typename P1>
void (C::*&ref(void (C::*)(P1)))(P1)
{
 static void (C::*f)(P1);
 return f;
}

template <typename C, typename P1, typename P2>
void (C::*&ref(void (C::*)(P1, P2)))(P1, P2)
{
 static void (C::*f)(P1, P2);
 return f;
}

struct C0 { void f(int) { } };
struct C1 { void f(int, int = 0) { } };
struct C2 { int f(int) { return 0; } };

int main()
{
 ref(&C0::f) = &C0:f; // OK
 ref(&C1::f) = &C1:f; // OK
 ref(&C2::f) = &C2:f; // Doesn't compile
}

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

"Pete Becker" <petebecker@acm.org> wrote in message
news:38E3EC9A.E8A67D26@acm.org...
>
> The assertion was that you can take the address of a member function
in
> order to assign it to a pointer to member function, and if the
> assignment fails, then you know that the declaration does not conform
to
> the standard. A compilation failure, however, does not distinguish
> between a different return type and a different argument list. Since
the
> argument list is allowed to be different, this test does not detect
> non-conformance. If you disagree, please show how you would do it. You
> must be able to distinguish these two cases:
>
> requirement: void C::f(int)
> implementation 1: void C::f(int, int = 0)
> implementation 2: int C::f(int)

struct Req {
  void f(int) {}
};

struct Imp1 {
  void f(int, int = 0) {}
};

struct Imp2 {
  int f(int) { return 0; }
};

template <typename T, typename RT> struct Test {
  RT f() { return T().f(1); }
};

int main() {
  Test<Req, void>().f(); // OK
  Test<Imp1, void>().f(); // OK
  Test<Imp2, void>().f(); // Error
  return 0;
}

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
   "So that's 2 T-1s and a newsfeed ... would you like clues with that?"
                                                       -- Peter Da Silva


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

Said petebecker@acm.org (Pete Becker) in comp.std.c++:
>James Kuyper wrote:
>> Being able to do what he did breaks the 'as-if' argument. Most failed
>> 'as-if' arguments are shown to fail by the use of fairly silly example
>> code. Just because it's silly doesn't mean that the argument didn't
>> fail.
>
>I'm getting tired of saying this. I agree that the implementation does
>not conform.

Well, that's a change. Only a couple of days ago you were very
definite that it *did* conform, so much so that you convinced me
until Kuyper made his case and convinced both of us to the
contrary. :-)

If you truly feel that this non-conformance is valuable, perhaps
you should document it as a non-conforming extension. If it's not
valuable, wouldn't it be better to fix it than to let people
unknowingly use a non-conforming extension and have their code
break on another compiler?

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                http://www.mindspring.com/~brahms/
C++ FAQ Lite: http://www.cerfnet.com/~mpcline/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
more FAQs: http://www.mindspring.com/~brahms/faqget.htm

---
[ 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:
>
> Pete Becker wrote:
> >
> > James Kuyper wrote:
> ....
> > > The silliness of an example doesn't matter. The following is a very
> > > silly program:
> > >
> > >         int main()
> > >         {       return 0;       }
> > >
> > > I hope that if I were to lodge a valid complaint about this program not
> > > compiling correctly, you wouldn't dismiss the complaint just because the
> > > program is so silly (Note: I said "a valid complaint").
> >
> > Sigh. Once again: silly examples do not contribute to decisions about
> > which of two libraries are "more" conforming. Ignore silly examples and
> > focus on real differences.
>
> So if I'm testing two compilers, and one of them compiles and executes
> this code correctly, and the other doesn't, I shouldn't use that
> information in decide which one to use? Just because the test is too
> "silly"?

Only if the two are otherwise exactly equal. This particular question
would be one of the last things I looked at.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Ross Smith wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:38E3EC9A.E8A67D26@acm.org...
> >
> > The assertion was that you can take the address of a member function
> in
> > order to assign it to a pointer to member function, and if the
> > assignment fails, then you know that the declaration does not conform
> to
> > the standard. A compilation failure, however, does not distinguish
> > between a different return type and a different argument list. Since
> the
> > argument list is allowed to be different, this test does not detect
> > non-conformance. If you disagree, please show how you would do it. You
> > must be able to distinguish these two cases:
> >
> > requirement: void C::f(int)
> > implementation 1: void C::f(int, int = 0)
> > implementation 2: int C::f(int)
>
> int main() {
>   Test<Req, void>().f(); // OK
>   Test<Imp1, void>().f(); // OK
>   Test<Imp2, void>().f(); // Error
>   return 0;
> }
>

This misses the point. The discussion in this subthreadwas not whether
there is any code that can distinguish these two, but whether it can be
done with pointers to members.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

I made a slight error (one colon instead of two). Here's the correction -

template <typename C>
void (C::*&ref(void (C::*)(int)))(int)
{
 static void (C::*f)(int);
 return f;
}

template <typename C>
void (C::*&ref(void (C::*)(int, int)))(int, int)
{
 static void (C::*f)(int, int);
 return f;
}

struct C0 { void f(int) { } };
struct C1 { void f(int, int = 0) { } };
struct C2 { int f(int) { return 0; } };

int main()
{
 ref(&C0::f) = &C0::f; // OK
 ref(&C1::f) = &C1::f; // OK
 ref(&C2::f) = &C2::f; // Doesn't compile
}

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

Stan Brown wrote:
>
> If you truly feel that this non-conformance is valuable, perhaps
> you should document it as a non-conforming extension. If it's not
> valuable, wouldn't it be better to fix it than to let people
> unknowingly use a non-conforming extension and have their code
> break on another compiler?
>

Way back at the beginning I said that we need to document this better.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > The assertion was that you can take the address of a member function in
> > order to assign it to a pointer to member function, and if the
> > assignment fails, then you know that the declaration does not conform to
> > the standard. A compilation failure, however, does not distinguish
> > between a different return type and a different argument list. Since the
> > argument list is allowed to be different, this test does not detect
> > non-conformance. If you disagree, please show how you would do it. You
> > must be able to distinguish these two cases:
> >
> > requirement: void C::f(int)
> > implementation 1: void C::f(int, int = 0)
> > implementation 2: int C::f(int)
>
> It's easy :-)

<g> For those who missed the humor in Hyman's response, the actual need
is to distinguish the unbounded set of possible overloads, not just that
pair.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:

> Kresimir Fresl wrote:

> > Pete Becker wrote:

> > > I'm getting tired of saying this. I agree that the implementation
> > > does not conform.

> > Since when? In your first reply you wrote:

> > ``[...] the correct answer is that it's a conforming extension.''

> Since some time after that, obviously. Read my reply to Biju Thomas's
> example.

Well, here it is:

> > > > Are you saying that the following program is non-conforming?

> > > No, just silly. <g>

> > Well, silliness isn't relevant to standard conformance.

> Sure it is.

How else can one understand your words save that you stubbornly
claim that your implementation *do conform* because only in silly
programs non-conformance can appear, and silly programs don't count.

In your reply to James Kuyper you wrote:

> I must have missed a step here. What I've been saying for the
> past couple of days is that some kinds of non-conformane are more
> important than others[...]

Obviously, some of us also `have missed a step here'. It is
a step where you admit that your implementation is non-conforming
without any fuzzy reference to `silly' examples which can cause
problems.


fres

---
[ 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 <MPG.1345a8bee9605cad98ae66@news.mindspring.com>,
brahms@mindspring.com (Stan Brown) wrote:

> Said petebecker@acm.org (Pete Becker) in comp.std.c++:
> > For this newsgroup, the legitimate
> >aspect of this discussion is whether this return type conforms to the
> >standard. It does.
>
> Pardon a question, but how does it conform? The standard gives
> particular signatures for the function in question, and the
> implementation doesn't implement them as specified.
>
> I'm only a humble programmer, but I don't understand how you can
> say that it conforms to the standard when the standard specifies
> a particular return and the implementation has a different
> return.

It conforms because a standard conforming program can not detect that the
library doesn't conform.  Thus, the library conforms.

-Howard

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

Matt Austern wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> > Stan Brown wrote:
> > >
> > > Said petebecker@acm.org (Pete Becker) in comp.std.c++:
> > > > For this newsgroup, the legitimate
> > > >aspect of this discussion is whether this return type conforms to the
> > > >standard. It does.
> > >
> > > Pardon a question, but how does it conform? The standard gives
> > > particular signatures for the function in question, and the
> > > implementation doesn't implement them as specified.
> >
> > Right. But conformance is determined by whether a valid program compiles
> > and runs correctly. So, how will a valid program use map::erase? Like
> > this:
> >
> > erase(xxx);
> >
> > That's valid even if erase actually returns something. The program isn't
> > affected by the presence of a return value, so the extension conforms to
> > the language definition.
>
> Pete is right, of course, but there's a subtlety he didn't mention.

Didn't mention in this particular message, that is. <g> We went through
this three or four messages ago. I didn't repeat it because I wanted to
keep things simple.

>
> If you take the address of the member function map<>::erase(), the
> return type will be different if its return type is void than if its
> return type is map<>::iterator.  So this does affect what kinds of
> programs will compile and run; it affects whether you can assign the
> address value to a variable of a particular pointer-to-member type.
>
> You might think this means that changing the return value is a non-
> conforming extension.  It doesn't mean that, though, because the
> standard already says that programmers should not count on the
> addresses of member functions to have the pointer-to-member types that
> you might think they have from the signatures in the standard.
> Implementors explicitly have license to add extra arguments, provided
> that they're defaulted.
>

And provided the function is not virtual.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
>
> But conformance is determined by whether a valid program compiles
> and runs correctly. So, how will a valid program use map::erase? Like
> this:
>
> erase(xxx);
>
> That's valid even if erase actually returns something. The program isn't
> affected by the presence of a return value, so the extension conforms to
> the language definition.
>

Are you saying that the following program is non-conforming?

#include <map>

void f ()
{
  typedef std::map<int,int> MyMap;
  MyMap aMap;
  ...
  MyMap::iterator position = ....

  return aMap.erase(position);
}

--
Biju Thomas

---
[ 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 <38DCBA55.2C343CCE@acm.org>, petebecker@acm.org says...
> Matt Austern wrote:
> >
> > Pete Becker <petebecker@acm.org> writes:
> >
> > > Stan Brown wrote:
> > > >
> > > > Said petebecker@acm.org (Pete Becker) in comp.std.c++:
> > > > > For this newsgroup, the legitimate
> > > > >aspect of this discussion is whether this return type conforms to the
> > > > >standard. It does.
> > > >
> > > > Pardon a question, but how does it conform? The standard gives
> > > > particular signatures for the function in question, and the
> > > > implementation doesn't implement them as specified.
> > >
> > > Right. But conformance is determined by whether a valid program compiles
> > > and runs correctly. So, how will a valid program use map::erase? Like
> > > this:
> > >
> > > erase(xxx);
> > >
> > > That's valid even if erase actually returns something. The program isn't
> > > affected by the presence of a return value, so the extension conforms to
> > > the language definition.
[snip]

Hi Pete,

Enjoy your column in CUJ.  I'm not a language lawyer so I believe you
that this extension is conforming.  It is, however, obvious that a
program which takes advantage of this extension is not portable to an
implementation which does not porvide it.  Given that the spirit, if not
the absolute letter, of the standard is portability why would Dinkumware
implement this extension?

In point of fact this very thing caused me a problem about a year ago.  I
had developed a large program using map's under Visual C++ which was then
to be ported to several Unix platforms.  The Dinkumware implementation of
map::erase returning an iterator was the only portability problem I had.
Granted it wasn't a big problem, I simply changed

 i = m.erase(i);

to

 m.erase(i++);

but it concerned me enough that I wrote Bjarne Stroustrup about it.
Bjarne was kind enough to reply advising me that I should never take
advantage of this extension if I cared about portability.

So, the question remains, why have an extension that only people who are
unaware of the problems it presents will use?

Thanks and regards,
Bob

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

Bob Withers wrote:
>
> In point of fact this very thing caused me a problem about a year ago.

Yes, we probably need to make it clearer in our documentation that this
is an extension.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Biju Thomas wrote:
>
>
> Are you saying that the following program is non-conforming?

No, just silly. <g>

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
>
> Biju Thomas wrote:
> >
> >
> > Are you saying that the following program is non-conforming?
>
> No, just silly. <g>

Well, silliness isn't relevant to standard conformance. Most examples
that show a basic principle are fairly silly, in themselves. However,
since they represent something that's legal, sooner or later they will
come up in well-motivated design.

Code such as he gave could reasonably occur inside the expansion of
template, where the return type of the member function (and therefore of
the template function as well) is a template parameter. A great deal of
effort went into making it legal to use such a template, with the
parameter set to 'void'. That template could plausibly be instantiated
for 'void'. This would be legal, since the standard specifies the return
type to be 'void'.

The function signature argument that you used before doesn't work in
this case. The section of the standard you cited gives explicit
permission only to change the argument list, not the return type. In
effect, you used the as-if rule to extend it to the return type. Since
the pointer-to-member code would break if the argument list was
extended, it could therefore also break for other reasons, such as a
different return type. That logic doesn't apply in this case.

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

Pete Becker wrote:
>
> Biju Thomas wrote:
> >
> >
> > Are you saying that the following program is non-conforming?
>
> No, just silly. <g>

But then, is the following program conforming?

void foo()
{
  return 1;
}

int main()
{
  foo();
}

If not, Biju Thomas' program is a conforming program that
would fail with the erase extension, which would make it
non-conforming.
OTOH, I can imagine that it's allowed, given that conversion
to void is possible for all types.
Unfortunately returning expressions for void functions seems
to be a post-CD2 feature (at least CD2, 6.6.3 [stmt.return]/2
doesn't seem to allow it), therefore I can't check myself.

---
[ 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 <MPG.1347dc204b33dccf989680@news.mciworld.com>,
Bob Withers <bwit@pobox.com> wrote:
> Hi Pete,
>
> Enjoy your column in CUJ. I'm not a language lawyer so I believe you
> that this extension is conforming. It is, however, obvious that a
> program which takes advantage of this extension is not portable to an
> implementation which does not porvide it. Given that the spirit, if
not
> the absolute letter, of the standard is portability why would
Dinkumware
> implement this extension?
>
> In point of fact this very thing caused me a problem about a year
ago. I
> had developed a large program using map's under Visual C++ which was
then
> to be ported to several Unix platforms. The Dinkumware implementation
of
> map::erase returning an iterator was the only portability problem I
had.
> Granted it wasn't a big problem, I simply changed
>
> i = m.erase(i);
>
> to
>
> m.erase(i++);
>
> but it concerned me enough that I wrote Bjarne Stroustrup about it.
> Bjarne was kind enough to reply advising me that I should never take
> advantage of this extension if I cared about portability.

It seems to me that your alternative won't work.  map::erase gets
called, so the iterator becomes invalid, and _then_ you increment it.
I can fully understand why it appears to work under most
implementations, but I bet this will bite you hard some time.  I'm sure
this is why the extension was added.  To really do this portably would
require two lines and a temporary.

iterator temp = i++;   // assuming iterator is a typedef
m.erase(temp);

> So, the question remains, why have an extension that only people who
are
> unaware of the problems it presents will use?

Because the standard should have had the extension to begin with? ;)

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Bob Withers wrote:
>
> So, the question remains, why have an extension that only people who are
> unaware of the problems it presents will use?
>

That's not a fair statement of the issue. The true question is, why have
an extension when its use makes code less portable? (of course, that's
true of any extension). The answer is that portability is one factor
that enters into coding decisions, but not the only one. The way to
determine whether extensions are useful is to make them available and
see how widely they get used. If they are truly useful they can then
form a basis for future language changes.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
>
> Biju Thomas wrote:
> >
> >
> > Are you saying that the following program is non-conforming?
>
> No, just silly. <g>
>

Might be. But, we are talking about technicalities here.

The point is, the Dinkumware extension that changes the return type of
std::map::erase functions is non-conforming. Implementations can't
change the return types of any functions specified in the standard,
whatever be their return type.

--
Biju Thomas

---
[ 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 <MPG.1347dc204b33dccf989680@news.mciworld.com>,
bwit@pobox.com says...

[ ... ]

> Enjoy your column in CUJ.  I'm not a language lawyer so I believe you
> that this extension is conforming.  It is, however, obvious that a
> program which takes advantage of this extension is not portable to an
> implementation which does not porvide it.  Given that the spirit, if not
> the absolute letter, of the standard is portability why would Dinkumware
> implement this extension?

In Java (for one example) the claim is that _all_ properly written
programs are and should be portable.

The same is _not_ true of C or C++ -- both have made it quite clear
from the very beginning that there are some things that are portable
and others that aren't.  Conforming extensions don't violate the
letter of the standard, and a great deal of that is because the
standard includes rules _specifically_ to make certain types of
extensions conforming.  While I don't claim any particular capability
for divining the "spirit of the standard", I consider it unreasonable
to believe that the spirit of the standard runs directly contrary to
the very clear and specific intent of the standard's actual contents.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

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

sirwillard@my-deja.com wrote:
>
> In article <MPG.1347dc204b33dccf989680@news.mciworld.com>,
> Bob Withers <bwit@pobox.com> wrote:
> > Hi Pete,
> >
> > Enjoy your column in CUJ. I'm not a language lawyer so I believe you
> > that this extension is conforming. It is, however, obvious that a
> > program which takes advantage of this extension is not portable to an
> > implementation which does not porvide it. Given that the spirit, if
> not
> > the absolute letter, of the standard is portability why would
> Dinkumware
> > implement this extension?
> >
> > In point of fact this very thing caused me a problem about a year
> ago. I
> > had developed a large program using map's under Visual C++ which was
> then
> > to be ported to several Unix platforms. The Dinkumware implementation
> of
> > map::erase returning an iterator was the only portability problem I
> had.
> > Granted it wasn't a big problem, I simply changed
> >
> > i = m.erase(i);
> >
> > to
> >
> > m.erase(i++);
> >
> > but it concerned me enough that I wrote Bjarne Stroustrup about it.
> > Bjarne was kind enough to reply advising me that I should never take
> > advantage of this extension if I cared about portability.
>
> It seems to me that your alternative won't work.  map::erase gets
> called, so the iterator becomes invalid, and _then_ you increment it.

No. Incrementing the iterator must be finished when m.erase
is called. m.erase of course gets a temporary copy of the old
value of i.
This is because m.erase(i++) is either m.erase(i.operator++(int()))
or m.erase(operator++(i, int())), and the inner function call must
have finished before the outer function is called.

Note that even if i were a built-in type, the code had to work:
Incrementation of the iterator is a side effect of the increment
operator, and the function call is a sequence point. Since
all side effects must have occured at a sequence point, the
iterator must already be incremented.

> I can fully understand why it appears to work under most
> implementations, but I bet this will bite you hard some time.

Only on buggy implementations.

>  I'm sure
> this is why the extension was added.  To really do this portably would
> require two lines and a temporary.
>
> iterator temp = i++;   // assuming iterator is a typedef
> m.erase(temp);

This code is _exactly_ equivalent to m.erase(i++); except
that the temporary is unnamed (i.e. really a temporary),
and therefore one copy may be optimized away.

I guess the extension is more for orthogonality,
since IIRC for sequences, the iterator is returned
(esp. for vector, v.erase(i++) wouldn't work, since
erasing an element will invalidate all following
iterators, esp. i+1).

>
> > So, the question remains, why have an extension that only people who
> are
> > unaware of the problems it presents will use?
>
> Because the standard should have had the extension to begin with? ;)

Could that be a defect report (due to the difference in erase
signature between sequences and associative containers)?

---
[ 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 <kuyper@wizard.net> writes:

 >Pete Becker wrote:
 >>
 >> Biju Thomas wrote:
 >> >
 >> > Are you saying that the following program is non-conforming?
 >>
 >> No, just silly. <g>
 >
 >Well, silliness isn't relevant to standard conformance. Most examples
 >that show a basic principle are fairly silly, in themselves. However,
 >since they represent something that's legal, sooner or later they will
 >come up in well-motivated design.
 >
 >Code such as he gave could reasonably occur inside the expansion of
 >template, where the return type of the member function (and therefore of
 >the template function as well) is a template parameter. A great deal of
 >effort went into making it legal to use such a template, with the
 >parameter set to 'void'. That template could plausibly be instantiated
 >for 'void'. This would be legal, since the standard specifies the return
 >type to be 'void'.
 >
 >The function signature argument that you used before doesn't work in
 >this case.

... unless the implementation *also* has an extension to allow
`return <expression-with-non-void-type>' in functions with return
type `void'.

Does the implementation under discussion actually accept the program
that Biju Thomas posted?

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

---
[ 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 <MPG.13481e04a7a7147098975e@news.mindspring.com>,
jcoffin@taeus.com says...
> In article <MPG.1347dc204b33dccf989680@news.mciworld.com>,
> bwit@pobox.com says...
>
> [ ... ]
>
> > Enjoy your column in CUJ.  I'm not a language lawyer so I believe you
> > that this extension is conforming.  It is, however, obvious that a
> > program which takes advantage of this extension is not portable to an
> > implementation which does not porvide it.  Given that the spirit, if not
> > the absolute letter, of the standard is portability why would Dinkumware
> > implement this extension?
>
> In Java (for one example) the claim is that _all_ properly written
> programs are and should be portable.
>
> The same is _not_ true of C or C++ -- both have made it quite clear
> from the very beginning that there are some things that are portable
> and others that aren't.  Conforming extensions don't violate the
> letter of the standard, and a great deal of that is because the
> standard includes rules _specifically_ to make certain types of
> extensions conforming.  While I don't claim any particular capability
> for divining the "spirit of the standard", I consider it unreasonable
> to believe that the spirit of the standard runs directly contrary to
> the very clear and specific intent of the standard's actual contents.
>
>

I guess I'm misunderstanding the purpose of having a de jure standard.

Bob

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

Biju Thomas wrote:
>
> Pete Becker wrote:
> >
> > Biju Thomas wrote:
> > >
> > >
> > > Are you saying that the following program is non-conforming?
> >
> > No, just silly. <g>
> >
>
> Might be. But, we are talking about technicalities here.

Nope, we're talking practicalities. Conformance is not a matter of
counting, but of evaluating. Making silly examples work is low on my
list of priorities, and I'm quite sure this would not be a deal-breaker
for any library purchaser.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
>
> > > > Are you saying that the following program is non-conforming?
> > >
> > > No, just silly. <g>
> > >
> >
> > Might be. But, we are talking about technicalities here.
>
> Nope, we're talking practicalities. Conformance is not a matter of
> counting, but of evaluating. Making silly examples work is low on my
> list of priorities, and I'm quite sure this would not be a deal-breaker
> for any library purchaser.
>

I posted that example after seeing the claims made here that the
Dinkumware library with that extension for std::map::erase is
standard-conforming since there is no way to write a program to detect
the difference. Currently, I don't know whether such code is useful. (I
don't claim to be omniscient :-)) May be there can be situations where
such code can be useful deep within some template code.

Anyway, if I was evaluating a standard library, I would expect the
vendor to document any extensions (whether conforming or
non-conforming). I don't see that in the documentation of Dinkumware
library I have. This is a case of practicality. Otherwise, I would
gladly use the return value of std::map::erase in my code on the belief
that it is the proper standard, and later if I port the code to a
different compiler/library, I would be bitten by that. (In fact, such a
case was reported in this thread.) Please do at least that favour to us
users :-)

--
Biju Thomas

---
[ 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 <hinnant-2403001952280001@ith3-4de.twcny.rr.com>,
hinnant@anti-spam_metrowerks.com (Howard Hinnant) wrote:

> It conforms because a standard conforming program can not detect that the
> library doesn't conform.  Thus, the library conforms.

But I believe Biju Thomas disproved this with his example:

   #include <map>

   void f ()
   {
      typedef std::map<int,int> MyMap;
      MyMap aMap;
      ...
      MyMap::iterator position = ....

      return aMap.erase(position);
   }

Pete Becker called this silly, but didn't make a case for it being
non-conforming. So I now believe that the Dinkumware extension is
non-conforming, but in a way that perhaps only affects "silly" programs.

    -- Darin

---
[ 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 <8bnu61$4nj$1@nnrp1.deja.com>, sirwillard@my-deja.com wrote:

> > Granted it wasn't a big problem, I simply changed
> >
> > i = m.erase(i);
> >
> > to
> >
> > m.erase(i++);
> >
> It seems to me that your alternative won't work.  map::erase gets
> called, so the iterator becomes invalid, and _then_ you increment it.
> I can fully understand why it appears to work under most
> implementations, but I bet this will bite you hard some time.  I'm sure
> this is why the extension was added.  To really do this portably would
> require two lines and a temporary.
>
> iterator temp = i++;   // assuming iterator is a typedef
> m.erase(temp);

Actually m.erase(i++); will work.  When ever any method is called, the
arguments of the method must first be evaluated.  For example:

m.erase(i.f());

i.f() must be evaulated first, then the return value of that call is sent
to m.erase().  In Bob's workaround, the method iterator::operator++(int)
is executed before map::erase() is called.  Then the result of
iterator::operator++(int) is used in the argument to m.erase().  This has
(approximately) the same effect as your proposed workaround.

-Howard

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

sirwillard@my-deja.com writes:
> > m.erase(i++);
>
> It seems to me that your alternative won't work.  map::erase gets
> called, so the iterator becomes invalid, and _then_ you increment it.

No. The iterator is incremented before erase is called.

---
[ 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 <38DE4CC4.85D5364E@acm.org>, petebecker@acm.org says...
> Bob Withers wrote:
> >
> > So, the question remains, why have an extension that only people who are
> > unaware of the problems it presents will use?
> >
>
> That's not a fair statement of the issue. The true question is, why have
> an extension when its use makes code less portable? (of course, that's
> true of any extension). The answer is that portability is one factor
> that enters into coding decisions, but not the only one. The way to
> determine whether extensions are useful is to make them available and
> see how widely they get used. If they are truly useful they can then
> form a basis for future language changes.
>
>

You're right, of course.  Portability is very high on my list and I feel
I've been very successful over the years using C++ to support a large
number of platforms.  This would not be everyone's priority and your
extension is useful, just not to me.

Regards,
Bob

---
[ 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:
>
> Pete Becker wrote:
> >
> > Biju Thomas wrote:
> > >
> > >
> > > Are you saying that the following program is non-conforming?
> >
> > No, just silly. <g>
>
> Well, silliness isn't relevant to standard conformance.

Sure it is. If you had a choice of a library whose map::erase function
did nothing, but had the right signature, and a library whose map::erase
function actually erased the specified element but had the "wrong"
signature, would you say that there is no difference in their
conformance to the standard? Conformance is not a matter of counting
differences, but of assessing their importance.

> Most examples
> that show a basic principle are fairly silly, in themselves. However,
> since they represent something that's legal, sooner or later they will
> come up in well-motivated design.
>
> Code such as he gave could reasonably occur inside the expansion of
> template, where the return type of the member function (and therefore of
> the template function as well) is a template parameter.

Example, please. I simply don't believe that any sensible design would
call map::erase in a return statement.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ 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 <38E00BB4.E50D384D@acm.org>, Pete Becker
<petebecker@acm.org> wrote:

> Nope, we're talking practicalities. Conformance is not a matter of
> counting, but of evaluating. Making silly examples work is low on my
> list of priorities, and I'm quite sure this would not be a deal-breaker
> for any library purchaser.

Pete, I think you're being a bit stubborn here.

You started by claiming that your alternate return value for
std::map::erase was a conforming extension. You didn't say why, but
presumably your reasoning was that no correct program could detect that
the signature was different. This surprised many of us. Even though the
standard was specific about the return value type, you pointed out that
your implementation could get away with a different type because of what
seemed to many of us to be an obscure technicality.

Then Biju provided an example that demonstrated that a correct program
can detect the difference. That wasn't surprising to me, but perhaps it
was surprising to you. At that point, the response I'd expect would be,
"I was mistaken. I'll consider fixing that in a future release so our
implementation conforms to the standard."

Instead you seem to have gone on the defensive. I think you are now
saying that although you agree that the Dinkumware library is not
conforming in this respect, you do not consider it a significant defect
in the library and you don't plan to change it. Your position is that
it's OK because your customers won't mind this kind of defect, since it
can only be detected by silly examples.

All I have to add is this:

   1) We have not proven that only silly examples can detect the
difference. There may be useful examples that also behave differently
with the non-conforming extension present.
   2) Having a different return type does damage people's understanding
and respect for the standard. It's confusing. Even if it *was*
conforming I would think that it's worthwhile only if it confers a
significant advantage.

    -- Darin

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

Christopher Eltschka wrote:
>
> But then, is the following program conforming?
>
> void foo()
> {
>   return 1;
> }
>
> int main()
> {
>   foo();
> }
>
> If not, Biju Thomas' program is a conforming program that
> would fail with the erase extension, which would make it
> non-conforming.
> OTOH, I can imagine that it's allowed, given that conversion
> to void is possible for all types.

Well, no. 6.6.3/3 in the standard explicitly says that "return with an
expression of type cv void can be used only in functions with return
type cv void".

--
Biju Thomas

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

Biju Thomas wrote:
>
> Currently, I don't know whether such code is useful. (I
> don't claim to be omniscient :-)) May be there can be situations where
> such code can be useful deep within some template code.

Maybe, but I don't think so. The change in the semantics of return was
intended to solve a different problem, and I don't see how it's useful
here. In any event, the workaround in your example, and, presumably, in
more complex situations, is trivial.

> Anyway, if I was evaluating a standard library, I would expect the
> vendor to document any extensions (whether conforming or
> non-conforming). I don't see that in the documentation of Dinkumware
> library I have.

I replied in an earlier message that we need to document that.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
....
> Nope, we're talking practicalities. Conformance is not a matter of
> counting, but of evaluating. Making silly examples work is low on my
> list of priorities, and I'm quite sure this would not be a deal-breaker
> for any library purchaser.

The silliness of an example doesn't matter. The following is a very
silly program:

        int main()
        {       return 0;       }

I hope that if I were to lodge a valid complaint about this program not
compiling correctly, you wouldn't dismiss the complaint just because the
program is so silly (Note: I said "a valid complaint").

Conformance IS about technicalities. Some companies (such as the one I
work for) have contractual requirements imposed by the government to use
only conforming implementations of the languages we use. We have waivers
on only four specific requirements of the C89 standard, and eight of the
requirements of Fortran 90. That's one reason we're not allowed to use
C99 or C++ (my C++ knowledge is entirely personal, not work-related).
Code that makes use of a compiler-specific extension is supposed to be
rejected. We don't have sufficient resources to enforce that
requirement, but I'd be in big trouble if code I wrote failed due to
relying on such an extension.

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

Darin Adler wrote:
>
> In article <38E00BB4.E50D384D@acm.org>, Pete Becker
> <petebecker@acm.org> wrote:
>
> > Nope, we're talking practicalities. Conformance is not a matter of
> > counting, but of evaluating. Making silly examples work is low on my
> > list of priorities, and I'm quite sure this would not be a deal-breaker
> > for any library purchaser.
>
> Pete, I think you're being a bit stubborn here.
>
> You started by claiming that your alternate return value for
> std::map::erase was a conforming extension. You didn't say why,

I explained the reasoning at least twice.

> but
> presumably your reasoning was that no correct program could detect that
> the signature was different. This surprised many of us. Even though the
> standard was specific about the return value type, you pointed out that
> your implementation could get away with a different type because of what
> seemed to many of us to be an obscure technicality.

Well, it's obscure if you haven't read it. And every discussion of
details turns on "techicalities." Like it or not, the standard does not
require that non-virtual members have the exact signature set out in the
standard. Calling this a "technicality" doesn't change that.

>
> Then Biju provided an example that demonstrated that a correct program
> can detect the difference. That wasn't surprising to me, but perhaps it
> was surprising to you. At that point, the response I'd expect would be,
> "I was mistaken. I'll consider fixing that in a future release so our
> implementation conforms to the standard."
>
> Instead you seem to have gone on the defensive.

Nonsense. He asked if I thought his example was non-conforming, and I
said no. I also said, in effect, that his example was a tiny corner
case, and that it didn't seem particularly important. I stand by that
claim. If you disagree with it, provide a non-trivial example where
being able to do what he did matters.

>    1) We have not proven that only silly examples can detect the
> difference. There may be useful examples that also behave differently
> with the non-conforming extension present.

I considered that before I replied, and I don't think there are such
examples. I am willing to be persuaded if someone will produce a
non-trivial example. Saying that there "may be useful examples"
contributes nothing to anyone's understanding of this question.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Darin Adler wrote:
>
> In article <hinnant-2403001952280001@ith3-4de.twcny.rr.com>,
> hinnant@anti-spam_metrowerks.com (Howard Hinnant) wrote:
>
> > It conforms because a standard conforming program can not detect that the
> > library doesn't conform.  Thus, the library conforms.
>
> But I believe Biju Thomas disproved this with his example:
>
>    #include <map>
>
>    void f ()
>    {
>       typedef std::map<int,int> MyMap;
>       MyMap aMap;
>       ...
>       MyMap::iterator position = ....
>
>       return aMap.erase(position);
>    }
>
> Pete Becker called this silly, but didn't make a case for it being
> non-conforming.

Of course not. I explicitly agreed with his unstated implication that it
is conforming.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Is this a conforming extension?  No.  Although I've personally gotten
whiplash on this issue ... first thinking no, then yes, now no again.

Is it a useful extension?  Perhaps.  It would be nice if code like the
following could be instantiated for all std::containers:

template <class Container>
void
erase_all(Container& c)
{
   Container::iterator i = c.begin();
   while (i != c.end())
      i = c.erase(i);
}

Admittedly, clear obviates the need for this particlular example, but
hopefully my point is made anyway.

FWIW, this issue has gone before the library working group and been
rejected as a defect, but it remains a possibility for a future standard:

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#130

-Howard

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

Pete Becker wrote:
>
> Like it or not, the standard does not
> require that non-virtual members have the exact signature set out in the
> standard.

Pete, I am sure that you know this: The return type of functions don't
form the part of a function signature; only the parameters' types and
the cv qualifier participate in the definition of function signature.
Repeating the above to justify the behaviour of your library doesn't
make it conforming :-)

The part of the standard that refers to this, 17.4.4.4, talks only about
conforming extensions to signatures, and not to the return type
specification of functions.

--
Biju Thomas

---
[ 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:
>
> Pete Becker wrote:
> ....
> > Nope, we're talking practicalities. Conformance is not a matter of
> > counting, but of evaluating. Making silly examples work is low on my
> > list of priorities, and I'm quite sure this would not be a deal-breaker
> > for any library purchaser.
>
> The silliness of an example doesn't matter. The following is a very
> silly program:
>
>         int main()
>         {       return 0;       }
>
> I hope that if I were to lodge a valid complaint about this program not
> compiling correctly, you wouldn't dismiss the complaint just because the
> program is so silly (Note: I said "a valid complaint").

Sigh. Once again: silly examples do not contribute to decisions about
which of two libraries are "more" conforming. Ignore silly examples and
focus on real differences.

>
> Conformance IS about technicalities. Some companies (such as the one I
> work for) have contractual requirements imposed by the government to use
> only conforming implementations of the languages we use. We have waivers
> on only four specific requirements of the C89 standard, and eight of the
> requirements of Fortran 90. That's one reason we're not allowed to use
> C99 or C++ (my C++ knowledge is entirely personal, not work-related).
> Code that makes use of a compiler-specific extension is supposed to be
> rejected. We don't have sufficient resources to enforce that
> requirement, but I'd be in big trouble if code I wrote failed due to
> relying on such an extension.
>

Then by all means use a library that better fits your particular needs.
I suspect that whether map::erase has a return type is not the biggest
factor in your decision, though. If it is, let me know: we'll be glad to
give you a version that doesn't have it.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ 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 <38DA6066.D4EB2717@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> Christopher Eltschka wrote:
> >
> > Pete Becker wrote:
> > >
> > >
> > > I can't speak to the answer you got in 1998, but the correct
answer is
> > > that it's a conforming extension.
> >
> > Really?
> > Then, in what way is the following code non-conforming?
> >
> > #include <map>
> >
> > int main()
> > {
> > typedef std::map<int, int> iimap;
> > typedef iimap::iterator iter;
> >
> > void (iimap::*f)(iter, iter);
> >
> > f = &iimap::erase;
> >
> > iimap m;
> > m[1]=1;
> > m[2]=2;
> > m[3]=3;
> > (m.*f)(m.begin(), m.end());
> > }
> >
> > After all, it would fail with the changed signature.
> >
>
> Yup, sure would. See clause 17.4.4.4/2: an implementation is permitted
> to add arguments with default values to a non-virtual member function.
> As note 172 somewhat ungrammatically says, this implies that "taking
the
> address of a member function has an unspecified type." Since you
cannot
> count on the signature of a non-virtual member function, adding a
return
> value to such a function that is specified to return void is
conforming.


I looked into it.


17.4.4.4

  2  An implimentation can declare additional non-virtual
     member function signatures within a class:

    -- by adding arguments with defualt values to a member
       function signature; (172) The same latitude does  not
       extend to the implimentation of virtual or global functions,
       however.

    -- by replacing a member function signature with defualt
       values by two or more member function signatures with
       equivalnet behavior.

    -- by adding a member function signature for a member function name.


Well, I am no expert at reading the standard but it seems to me that
the first line, grants you permission only to _add additional_ member
function definitions (note the word "additional"). My
interpretation stops right there.  You read it as:

an implementation is permitted to add arguments with default values...
                                  ^^^ ^^^^^^^^^
                                  ??? ?????????

I would say

"an implimentation is permited to add additional function signatures
 in one of three ways.  One of these ways is to overload
 the member function and add additional arguments with default
 values..."

which interpretation is correct ?


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Pete Becker wrote:
>
> Stan Brown wrote:
> >
> > Said robert.klemme@myview.de (Robert Klemme) in comp.std.c++:
> > >i'd like to confirm that this is the correct specification for
> > >map::erase
> > >
> > ><quote>
> > >map::erase
> > >
> > >iterator erase(iterator it);
> > >size_type erase(const Key& key);
> > >iterator erase(iterator first, iterator last);
> >
> > It's not correct, at least not according to the standard. (I
> > interchanged your second and third to ease comparison with the
> > standard.) At subclause 2.3.1.2 (page 491), we see
> >
> >         void      erase(iterator position);
> >         size_type erase(const key_type& x);
> >         void      erase(iterator first, iterator last);
> >
> > The version you give sounds to me like the Brand M
> > implementation. I believe I reported the erroneous return type to
> > Dinkumware some time in 1998, and the gist of the reply was "it
> > doesn't match the standard but we're not going to change it". My
> > report was against 5.0 SP3; whether they did decide to change it
> > in later versions I don't know.
> >
>
> I can't speak to the answer you got in 1998, but the correct answer is
> that it's a conforming extension.

Really?
Then, in what way is the following code non-conforming?

#include <map>

int main()
{
  typedef std::map<int, int> iimap;
  typedef iimap::iterator iter;

  void (iimap::*f)(iter, iter);

  f = &iimap::erase;

  iimap m;
  m[1]=1;
  m[2]=2;
  m[3]=3;
  (m.*f)(m.begin(), m.end());
}

After all, it would fail with the changed signature.

---
[ 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 <38D96A68.45C1AE96@acm.org>, Pete Becker <petebecker@acm.org> wrote:

> Stan Brown wrote:
> >
> > Said robert.klemme@myview.de (Robert Klemme) in comp.std.c++:
> > >i'd like to confirm that this is the correct specification for
> > >map::erase
> > >
> > ><quote>
> > >map::erase
> > >
> > >iterator erase(iterator it);
> > >size_type erase(const Key& key);
> > >iterator erase(iterator first, iterator last);
> >
> > It's not correct, at least not according to the standard. (I
> > interchanged your second and third to ease comparison with the
> > standard.) At subclause 2.3.1.2 (page 491), we see
> >
> >         void      erase(iterator position);
> >         size_type erase(const key_type& x);
> >         void      erase(iterator first, iterator last);
> >
> > The version you give sounds to me like the Brand M
> > implementation. I believe I reported the erroneous return type to
> > Dinkumware some time in 1998, and the gist of the reply was "it
> > doesn't match the standard but we're not going to change it". My
> > report was against 5.0 SP3; whether they did decide to change it
> > in later versions I don't know.
> >
>
>
> I can't speak to the answer you got in 1998, but the correct answer is
> that it's a conforming extension.

I asked that question in Dublin and I believe it was Andy Koenig that
answered that it wasn't conforming because it would mess up a member
function pointer.  I must admit that I just took that answer on faith.
Sounded right to me.  But I haven't gone digging in the standard (too many
higher priority things to do...).

-Howard

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

Pete Becker wrote:
>
> Stan Brown wrote:
> >
> > Said robert.klemme@myview.de (Robert Klemme) in comp.std.c++:
> > >i'd like to confirm that this is the correct specification for
> > >map::erase
> > >
> > ><quote>
> > >map::erase
> > >
> > >iterator erase(iterator it);
> > >size_type erase(const Key& key);
> > >iterator erase(iterator first, iterator last);
> >
> > It's not correct, at least not according to the standard. (I
> > interchanged your second and third to ease comparison with the
> > standard.) At subclause 2.3.1.2 (page 491), we see
> >
> >         void      erase(iterator position);
> >         size_type erase(const key_type& x);
> >         void      erase(iterator first, iterator last);
> >
> > The version you give sounds to me like the Brand M
> > implementation. I believe I reported the erroneous return type to
> > Dinkumware some time in 1998, and the gist of the reply was "it
> > doesn't match the standard but we're not going to change it". My
> > report was against 5.0 SP3; whether they did decide to change it
> > in later versions I don't know.
> >
>
> I can't speak to the answer you got in 1998, but the correct answer is
> that it's a conforming extension.

If a user specializes std::map<> for a user-defined type, and their
specialization matches the standard rather than your extension, could
any other compenent of Dinkumware break?

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

Christopher Eltschka wrote:
>
> Pete Becker wrote:
> >
> >
> > I can't speak to the answer you got in 1998, but the correct answer is
> > that it's a conforming extension.
>
> Really?
> Then, in what way is the following code non-conforming?
>
> #include <map>
>
> int main()
> {
>   typedef std::map<int, int> iimap;
>   typedef iimap::iterator iter;
>
>   void (iimap::*f)(iter, iter);
>
>   f = &iimap::erase;
>
>   iimap m;
>   m[1]=1;
>   m[2]=2;
>   m[3]=3;
>   (m.*f)(m.begin(), m.end());
> }
>
> After all, it would fail with the changed signature.
>

Yup, sure would. See clause 17.4.4.4/2: an implementation is permitted
to add arguments with default values to a non-virtual member function.
As note 172 somewhat ungrammatically says, this implies that "taking the
address of a member function has an unspecified type." Since you cannot
count on the signature of a non-virtual member function, adding a return
value to such a function that is specified to return void is conforming.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Howard Hinnant wrote:
>
> I asked that question in Dublin and I believe it was Andy Koenig that
> answered that it wasn't conforming because it would mess up a member
> function pointer.

The standard allows implementors to mess up the signatures of
non-virtual member functions.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ 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:
>
> Pete Becker wrote:
> >
> > I can't speak to the answer you got in 1998, but the correct answer is
> > that it's a conforming extension.
>
> If a user specializes std::map<> for a user-defined type, and their
> specialization matches the standard rather than your extension, could
> any other compenent of Dinkumware break?
>

Not that I know of. Do you have anything specific in mind?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker wrote:
>
> James Kuyper wrote:
> >
> > Pete Becker wrote:
> > >
> > > I can't speak to the answer you got in 1998, but the correct answer is
> > > that it's a conforming extension.
> >
> > If a user specializes std::map<> for a user-defined type, and their
> > specialization matches the standard rather than your extension, could
> > any other compenent of Dinkumware break?
> >
>
> Not that I know of. Do you have anything specific in mind?

No, nothing specific. I don't have a copy of Dinkumware, and therefore
haven't examined it. This is just one of the first comments I would make
if called into a walk-through to review such an extension. This
extension allows the creation of code that uses the return values. That
won't happen in user code which conforms to the standard, so there's no
conformance problem there. However, if such code exists elsewhere in the
standard library, that code is safe only if it's applied to
instantiations of std::map<> that are guaranteed not to be dependent on
user-defined types. Given the way that types propagate through the
standard library, it could be difficult to make such a guarantee. Does
such code exist? If so, can you make that guarantee?

---
[ 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:
>
> Pete Becker wrote:
> >
> > James Kuyper wrote:
> > >
> > > Pete Becker wrote:
> > > >
> > > > I can't speak to the answer you got in 1998, but the correct answer is
> > > > that it's a conforming extension.
> > >
> > > If a user specializes std::map<> for a user-defined type, and their
> > > specialization matches the standard rather than your extension, could
> > > any other compenent of Dinkumware break?
> > >
> >
> > Not that I know of. Do you have anything specific in mind?
>
> No, nothing specific. I don't have a copy of Dinkumware, and therefore
> haven't examined it. This is just one of the first comments I would make
> if called into a walk-through to review such an extension. This
> extension allows the creation of code that uses the return values. That
> won't happen in user code which conforms to the standard, so there's no
> conformance problem there. However, if such code exists elsewhere in the
> standard library, that code is safe only if it's applied to
> instantiations of std::map<> that are guaranteed not to be dependent on
> user-defined types. Given the way that types propagate through the
> standard library, it could be difficult to make such a guarantee. Does
> such code exist? If so, can you make that guarantee?
>

This is not an appropriate place to discuss hypothetical implementation
errors in a particular library. For this newsgroup, the legitimate
aspect of this discussion is whether this return type conforms to the
standard. It does.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Said petebecker@acm.org (Pete Becker) in comp.std.c++:
> For this newsgroup, the legitimate
>aspect of this discussion is whether this return type conforms to the
>standard. It does.

Pardon a question, but how does it conform? The standard gives
particular signatures for the function in question, and the
implementation doesn't implement them as specified.

I'm only a humble programmer, but I don't understand how you can
say that it conforms to the standard when the standard specifies
a particular return and the implementation has a different
return.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                http://www.mindspring.com/~brahms/
C++ FAQ Lite: http://www.cerfnet.com/~mpcline/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
more FAQs: http://www.mindspring.com/~brahms/faqget.htm

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

Stan Brown wrote:
>
> Said petebecker@acm.org (Pete Becker) in comp.std.c++:
> > For this newsgroup, the legitimate
> >aspect of this discussion is whether this return type conforms to the
> >standard. It does.
>
> Pardon a question, but how does it conform? The standard gives
> particular signatures for the function in question, and the
> implementation doesn't implement them as specified.

Right. But conformance is determined by whether a valid program compiles
and runs correctly. So, how will a valid program use map::erase? Like
this:

erase(xxx);

That's valid even if erase actually returns something. The program isn't
affected by the presence of a return value, so the extension conforms to
the language definition.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

Pete Becker <petebecker@acm.org> writes:

> Stan Brown wrote:
> >
> > Said petebecker@acm.org (Pete Becker) in comp.std.c++:
> > > For this newsgroup, the legitimate
> > >aspect of this discussion is whether this return type conforms to the
> > >standard. It does.
> >
> > Pardon a question, but how does it conform? The standard gives
> > particular signatures for the function in question, and the
> > implementation doesn't implement them as specified.
>
> Right. But conformance is determined by whether a valid program compiles
> and runs correctly. So, how will a valid program use map::erase? Like
> this:
>
> erase(xxx);
>
> That's valid even if erase actually returns something. The program isn't
> affected by the presence of a return value, so the extension conforms to
> the language definition.

Pete is right, of course, but there's a subtlety he didn't mention.

If you take the address of the member function map<>::erase(), the
return type will be different if its return type is void than if its
return type is map<>::iterator.  So this does affect what kinds of
programs will compile and run; it affects whether you can assign the
address value to a variable of a particular pointer-to-member type.

You might think this means that changing the return value is a non-
conforming extension.  It doesn't mean that, though, because the
standard already says that programmers should not count on the
addresses of member functions to have the pointer-to-member types that
you might think they have from the signatures in the standard.
Implementors explicitly have license to add extra arguments, provided
that they're defaulted.

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

Said robert.klemme@myview.de (Robert Klemme) in comp.std.c++:
>i'd like to confirm that this is the correct specification for
>map::erase
>
><quote>
>map::erase
>
>iterator erase(iterator it);
>size_type erase(const Key& key);
>iterator erase(iterator first, iterator last);

It's not correct, at least not according to the standard. (I
interchanged your second and third to ease comparison with the
standard.) At subclause 2.3.1.2 (page 491), we see

 void      erase(iterator position);
 size_type erase(const key_type& x);
 void      erase(iterator first, iterator last);

The version you give sounds to me like the Brand M
implementation. I believe I reported the erroneous return type to
Dinkumware some time in 1998, and the gist of the reply was "it
doesn't match the standard but we're not going to change it". My
report was against 5.0 SP3; whether they did decide to change it
in later versions I don't know.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                http://www.mindspring.com/~brahms/
C++ FAQ Lite: http://www.cerfnet.com/~mpcline/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
more FAQs: http://www.mindspring.com/~brahms/faqget.htm

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

Stan Brown wrote:
>
> Said robert.klemme@myview.de (Robert Klemme) in comp.std.c++:
> >i'd like to confirm that this is the correct specification for
> >map::erase
> >
> ><quote>
> >map::erase
> >
> >iterator erase(iterator it);
> >size_type erase(const Key& key);
> >iterator erase(iterator first, iterator last);
>
> It's not correct, at least not according to the standard. (I
> interchanged your second and third to ease comparison with the
> standard.) At subclause 2.3.1.2 (page 491), we see
>
>         void      erase(iterator position);
>         size_type erase(const key_type& x);
>         void      erase(iterator first, iterator last);
>
> The version you give sounds to me like the Brand M
> implementation. I believe I reported the erroneous return type to
> Dinkumware some time in 1998, and the gist of the reply was "it
> doesn't match the standard but we're not going to change it". My
> report was against 5.0 SP3; whether they did decide to change it
> in later versions I don't know.
>


I can't speak to the answer you got in 1998, but the correct answer is
that it's a conforming extension.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

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

hi all,

i'd like to confirm that this is the correct specification for
map::erase

<quote>
map::erase

iterator erase(iterator it);
iterator erase(iterator first, iterator last);
size_type erase(const Key& key);

The first member function removes the element of the controlled sequence
pointed to by it. The second member function removes the elements in the
interval [first, last). Both return an iterator that designates the
first element remaining beyond any elements removed, or end() if no such
element exists.

The third member function removes the elements with sort keys in the
range [lower_bound(key), upper_bound(key)). It returns the number of
elements it removes.
</quote>

btw: does anybody know of a more std compliant implementation of the STL
that works with egcs 1.1.2 than the one distributed with that release?
(unfortunately this version does only implement the last one correctly
while the other two "return" 'void'.  grrrr!)

tbank you very much!

 robert

--
Robert Klemme
Software Engineer
-------------------------------------------------------------
myview technologies GmbH & Co. KG
Riemekestra   e 160 ~ D-33106 Paderborn ~ Germany
E-Mail: mailto:robert.klemme@myview.de
Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399
-------------------------------------------------------------

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

Robert Klemme wrote:
>
> hi all,
>
> i'd like to confirm that this is the correct specification for

Sorry, it isn't.

> map::erase
>
> <quote>
> map::erase
>
> iterator erase(iterator it);
> iterator erase(iterator first, iterator last);

23.3.1 p2 says that the return type is 'void', not 'iterator', for both
of those functions.

> size_type erase(const Key& key);

> The first member function removes the element of the controlled sequence
> pointed to by it. The second member function removes the elements in the
> interval [first, last). Both return an iterator that designates the
> first element remaining beyond any elements removed, or end() if no such
> element exists.

Obviously, if the correct return type is 'void', the description of the
returned values is incorrect. The rest of the specification looks
acceptable.

> The third member function removes the elements with sort keys in the
> range [lower_bound(key), upper_bound(key)). It returns the number of
> elements it removes.

The standard says that it erases all elements with a key equivalent to
the provided one. Given the definitions of lower_bound() and
upper_bound(), that amounts to the same thing, but IMHO is a better
description. You don't have to know what the "*_bound" functions do, in
order to understand it.

> </quote>
>
> btw: does anybody know of a more std compliant implementation of the STL
> that works with egcs 1.1.2 than the one distributed with that release?
> (unfortunately this version does only implement the last one correctly
> while the other two "return" 'void'.  grrrr!)

Therefore, it's doing all three correctly.

---
[ 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 schrieb:
>
> Robert Klemme wrote:
> >
> > hi all,
> >
> > i'd like to confirm that this is the correct specification for
>
> Sorry, it isn't.
> [...]
> Therefore, it's doing all three correctly.

thank you for your time!

regards

 robert

--
Robert Klemme
Software Engineer
-------------------------------------------------------------
myview technologies GmbH & Co. KG
Riemekestra   e 160 ~ D-33106 Paderborn ~ Germany
E-Mail: mailto:robert.klemme@myview.de
Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399
-------------------------------------------------------------

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