Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<fl4rs1ewox.fsf@sel.cmla.ens-cachan.fr>...
> pdimov@mmltd.net (Peter Dimov) writes:
>
> | Users will not be able to legally define anything named "fill",
> | "copy_backwards", etc. This effectively would turn all std:: names
> | into keywords, thereby preventing any future extensions to the
> | standard library.
>
> I keep seeing this overstatement of the situation in all papers you
> happen to submit to the committees :-)

Submit a paper that would dispel this glaring misconception. :-)

> Firstly, users are able to legally define anything named fill or
> copy_backwards.

... as long as they know that the namespace these symbols are in is
not reachable through argument dependent lookup. And in the general
case they cannot know that.

The other problem is that users will be allowed to define entities in
reachable namespaces that do not collide with algorithm names, but a
future standard may contain an algorithm with the same name.

> Things may go wrong only when such names are used in
> a *namespace* considered by a Koenig lookup for some expressions.

Things _will_ go wrong, from "standard" point of view, since this
would have to be specified as "undefined behavior."

> Secondly, I do effectively think that some standard functions like
> swap() should be viewed like keywords.  Note that, I'm not saying that
> all standard functions should behave like that.

And I don't disagree with you on this one. All I am saying is that, in
my opinion, the chances that 'fill' and 'copy_backwards' will be
awarded keyword status are not very high -- assuming that anything
gets keyword status at all.

> My main concern is to have the committe list down which standard
> function have a "keyword status".

I bet on 'swap' and possibly 'iter_swap'.

--
Peter Dimov
Multi Media Ltd.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
>
> pdimov@mmltd.net (Peter Dimov) writes:
>
> | Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<fl4rs8rcc8.fsf@sel.cmla.ens-cachan.fr>...
> | > jk@steel.orel.ru (Eugene Karpachov) writes:
> | >
> | > | >:-)
> | > |
> | > | ?
> | >
> | > The issue raised by Dave is a DR with respect to the Standard.  There
> | > is a proposed resolution which requires explicit qualification.
> | > There still is some debate on related issues -- Dave knows the gory
> | > details.
> |
> | I doubt that any resolution of the issues in question would render
> | this legal. std::vector::insert is not documented to call fill() or
> | copy_backwards().
>
> But there is nothing which prohibits doing so.
>

Sure there is, and Dave's program is an example of it. When insert makes
an unqualified call to fill, that valid program doesn't do what the
standard requires. The library must use a qualified call in order to
avoid that problem. (which is why I regard the proposed DR as
unnecessary, because all it does is state the obvious solution to this
perhaps non-obvious problem. But it's not the job of the standard to
point every place where implementors could go wrong)

> | Dave's program is conforming.

> Did someone question whether Dave's program was conforming?
> No.  So what?

His program doesn't do what the standard says it should do because of
the way that the library was written. In order to demonstrate that it's
an error in the library it must first be shown that the program is
conforming.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<flbsmbefot.fsf@sel.cmla.ens-cachan.fr>...
> pdimov@mmltd.net (Peter Dimov) writes:
>
> | I doubt that any resolution of the issues in question would render
> | this legal. std::vector::insert is not documented to call fill() or
> | copy_backwards().
>
> But there is nothing which prohibits doing so.

Not directly, but...

> | Dave's program is conforming.
>
> Did someone question whether Dave's program was conforming?
> No.  So what?

The compiler doesn't accept it. A conforming compiler is not allowed
to reject a well-formed program that does not invoke undefined
behavior. [ Is it? ] Therefore, either the program violates a rule in
the Standard (which one?) _or_ the compiler does not follow the
Standard.

--
Peter Dimov
Multi Media Ltd.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

pdimov@mmltd.net (Peter Dimov) writes:

| > | Dave's program is conforming.
| >
| > Did someone question whether Dave's program was conforming?
| > No.  So what?
|
| The compiler doesn't accept it. A conforming compiler is not allowed
| to reject a well-formed program that does not invoke undefined
| behavior. [ Is it? ] Therefore, either the program violates a rule in
| the Standard (which one?) _or_ the compiler does not follow the
| Standard.

_Or_ The Standard is not clear.

As I said earlier, this is an open issue (with a proposed resolution)

 http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#225

Any resolution of that issue affects other issues as well.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Peter Dimov wrote:
>
> Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<flbsmbefot.fsf@sel.cmla.ens-cachan.fr>...
> > pdimov@mmltd.net (Peter Dimov) writes:
...
> > | Dave's program is conforming.
> >
> > Did someone question whether Dave's program was conforming?
> > No.  So what?
>
> The compiler doesn't accept it. A conforming compiler is not allowed
> to reject a well-formed program that does not invoke undefined
> behavior. [ Is it? ] Therefore, either the program violates a rule in
> the Standard (which one?) _or_ the compiler does not follow the
> Standard.

I couldn't see any violation of any rule in his code. I'd guess that
either the compiler's support for namespaces is inadequate, or that
there's a defect in the standard library header file that makes it
incorrectly declare fill() in the global namespace. Does anyone know
which one is the case? It's Dave Abraham's example, and it was Paolo
Carlini's claim of complete support for namespace std that he
demolished; would either one be able to investigate the actual cause of
this defect?

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

| Gabriel Dos Reis wrote:
| >
| > pdimov@mmltd.net (Peter Dimov) writes:
| >
| > | Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<fl4rs8rcc8.fsf@sel.cmla.ens-cachan.fr>...
| > | > jk@steel.orel.ru (Eugene Karpachov) writes:
| > | >
| > | > | >:-)
| > | > |
| > | > | ?
| > | >
| > | > The issue raised by Dave is a DR with respect to the Standard.  There
| > | > is a proposed resolution which requires explicit qualification.
| > | > There still is some debate on related issues -- Dave knows the gory
| > | > details.
| > |
| > | I doubt that any resolution of the issues in question would render
| > | this legal. std::vector::insert is not documented to call fill() or
| > | copy_backwards().
| >
| > But there is nothing which prohibits doing so.
| >
|
| Sure there is, and Dave's program is an example of it. When insert makes
| an unqualified call to fill,

I didn't make it clear, but I was implying std::flll and
std::copy_backwards.  There is nothing in the Standard which prohibits
std::vector<T>::insert to call those functions.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> writes:

| Does anyone know which one is the case?

Yes, this is LWG issue #225 (and #229)

 http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#225

| It's Dave Abraham's example, and it was Paolo
| Carlini's claim of complete support for namespace std that he
| demolished; would either one be able to investigate the actual cause of
| this defect?

FYI, GCC-3.x/g++ does have complete support for std, and the library
is effectively put in std:: -- except for bits from "C-headers" <cxxx>
and <xxx.h>, but then major implementations do have problems with
those headers (they are hard to get right without collaboration from
the C-library implementors, which means that for implementations like
GCC on non GNU/Linux systems it is nearly impossible to have something
conformant and useful).

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> writes:
>
> | Does anyone know which one is the case?
>
> Yes, this is LWG issue #225 (and #229)
>

Well, sort of. #225 asks that the standard include advice to
implementors that calls to standard library functions from within the
standard library should be qualified with std::. When they aren't, users
can inadvertently change the library's behavior.

>         http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#225
>
> | It's Dave Abraham's example, and it was Paolo
> | Carlini's claim of complete support for namespace std that he
> | demolished; would either one be able to investigate the actual cause of
> | this defect?
>
> FYI, GCC-3.x/g++ does have complete support for std, and the library
> is effectively put in std:: -- except for bits from "C-headers" <cxxx>
> and <xxx.h>

Then why doesn't Dave's conforming code compile?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

| Gabriel Dos Reis wrote:
| >
| > "James Kuyper Jr." <kuyper@wizard.net> writes:
| >
| > | Does anyone know which one is the case?
| >
| > Yes, this is LWG issue #225 (and #229)
| >
|
| Well, sort of. #225 asks that the standard include advice to
| implementors that calls to standard library functions from within the
| standard library should be qualified with std::.

Well, #225 is more than just "asking to include advice to implementors".
The adoption of the proposed resolution means that the committee
needs to list which standard function names can be used without
qualification, which might result in semantics change.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> | Gabriel Dos Reis wrote:
> | >
> | > "James Kuyper Jr." <kuyper@wizard.net> writes:
> | >
> | > | Does anyone know which one is the case?
> | >
> | > Yes, this is LWG issue #225 (and #229)
> | >
> |
> | Well, sort of. #225 asks that the standard include advice to
> | implementors that calls to standard library functions from within the
> | standard library should be qualified with std::.
>
> Well, #225 is more than just "asking to include advice to implementors".
> The adoption of the proposed resolution means that the committee
> needs to list which standard function names can be used without
> qualification, which might result in semantics change.
>

That resolution almost certainly won't be adopted. As the notes say:

 [Toronto: The LWG is not sure if this is a defect in the standard.
 Most LWG members believe that an implementation of std::unique like
 the one quoted in this issue is already illegal, since, under
 certain circumstances, its semantics are not those specified in
 the standard. The standard's description of unique does not say
 that overloading adjacent_find should have any effect.]

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

| That resolution almost certainly won't be adopted. As the notes say:
|
|  [Toronto: The LWG is not sure if this is a defect in the standard.
|  Most LWG members believe that an implementation of std::unique like
|  the one quoted in this issue is already illegal, since, under
|  certain circumstances, its semantics are not those specified in
|  the standard. The standard's description of unique does not say
|  that overloading adjacent_find should have any effect.]

Yes, I know that note.  The issue is still open, i.e. doesn't get any
definitive answer.  I don't intend quibbling, but the question of knowing
which standard function names can be used qualified or unqualified is
more than just a "request for advice".  Which is one the reasons why
#229 was open.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<flelr7lzz3.fsf@sel.cmla.ens-cachan.fr>...
> pdimov@mmltd.net (Peter Dimov) writes:
> | The compiler doesn't accept it. A conforming compiler is not allowed
> | to reject a well-formed program that does not invoke undefined
> | behavior. [ Is it? ] Therefore, either the program violates a rule in
> | the Standard (which one?) _or_ the compiler does not follow the
> | Standard.
>
> _Or_ The Standard is not clear.

Some people seem to think that it is clear on this particular point:

"[Toronto: The LWG is not sure if this is a defect in the standard.
Most LWG members believe that an implementation of std::unique like
the one quoted in this issue is already illegal, since, under certain
circumstances, its semantics are not those specified in the standard.
The standard's description of unique does not say that overloading
adjacent_find should have any effect.]"

IMHO there are two possible (equivalent) resolutions to this issue,
the first is "NAD - Standard already clear" and the second is
"Unqualified calls are illegal unless stated otherwise." And I doubt
that the vector::insert case will be covered by the "stated otherwise"
clause.

But let us assume for a moment that the Standard is somehow altered to
allow the current g++ 3.0 behavior. Think about the implications.
Users will not be able to legally define anything named "fill",
"copy_backwards", etc. This effectively would turn all std:: names
into keywords, thereby preventing any future extensions to the
standard library.

> As I said earlier, this is an open issue (with a proposed resolution)
>
>  http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#225
>
> Any resolution of that issue affects other issues as well.

I'm quite familiar with the issues in question. :-)

--
Peter Dimov
Multi Media Ltd.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B5CAA78.87FC4104@wizard.net>...
> Peter Dimov wrote:
> > The compiler doesn't accept it. A conforming compiler is not allowed
> > to reject a well-formed program that does not invoke undefined
> > behavior. [ Is it? ] Therefore, either the program violates a rule in
> > the Standard (which one?) _or_ the compiler does not follow the
> > Standard.
>
> I couldn't see any violation of any rule in his code. I'd guess that
> either the compiler's support for namespaces is inadequate, or that
> there's a defect in the standard library header file that makes it
> incorrectly declare fill() in the global namespace. Does anyone know
> which one is the case? It's Dave Abraham's example, and it was Paolo
> Carlini's claim of complete support for namespace std that he
> demolished; would either one be able to investigate the actual cause of
> this defect?

The program, AFAICS, demonstrates an interesting interaction between
LWG issue #225 and CWG issue #218. Apparently the library uses an
unqualified call to fill() from within vector::insert(), and the
argument dependent lookup finds the name "fill" despite the fact that
it's not a function (template.)

--
Peter Dimov
Multi Media Ltd.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

pdimov@mmltd.net (Peter Dimov) writes:

| Users will not be able to legally define anything named "fill",
| "copy_backwards", etc. This effectively would turn all std:: names
| into keywords, thereby preventing any future extensions to the
| standard library.

I keep seeing this overstatement of the situation in all papers you
happen to submit to the committees :-)

Firstly, users are able to legally define anything named fill or
copy_backwards.  Things may go wrong only when such names are used in
a *namespace* considered by a Koenig lookup for some expressions.


Secondly, I do effectively think that some standard functions like
swap() should be viewed like keywords.  Note that, I'm not saying that
all standard functions should behave like that.

My main concern is to have the committe list down which standard
function have a "keyword status".

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
>
> more than just a "request for advice".  Which is one the reasons why
> #229 was open.
>

And that's the reason that #225, which is the one we were discussing,
isn't going to go anywhere.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> | That resolution almost certainly won't be adopted. As the notes say:
> |
> |       [Toronto: The LWG is not sure if this is a defect in the standard.
> |       Most LWG members believe that an implementation of std::unique like
> |       the one quoted in this issue is already illegal, since, under
> |       certain circumstances, its semantics are not those specified in
> |       the standard. The standard's description of unique does not say
> |       that overloading adjacent_find should have any effect.]
>
> Yes, I know that note.  The issue is still open, i.e. doesn't get any
> definitive answer.  I don't intend quibbling, but the question of knowing
> which standard function names can be used qualified or unqualified is
> more than just a "request for advice".  Which is one the reasons why
> #229 was open.

The implication of that note seems to be that the issue may end up being
closed as "Not A Defect", with the resolution being that the standard
headers must be written in such a way as to prevent this problem from
occurring.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <fl4rs1ewox.fsf@sel.cmla.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@cmla.ens-cachan.fr> wrote:

| Secondly, I do effectively think that some standard functions like
| swap() should be viewed like keywords.  Note that, I'm not saying that
| all standard functions should behave like that.
|
| My main concern is to have the committe list down which standard
| function have a "keyword status".

I have attempted a first draft of this in
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1289.html

--
Howard Hinnant
Metrowerks

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Yes.

"Eugene Karpachov" <jk@steel.orel.ru> wrote in message
news:slrn9la7uk.o2.jk@localhost.localdomain...
> Tue, 17 Jul 2001 01:25:22 GMT David Abrahams wrote:
> >Try this, for example:
> >
> >#include <vector>
> >struct fill {}; // comment out this line to compile successfully
> >struct y {};
> >void f()
> >{
> >   std::vector<y> x(10);
> >   x.insert(x.begin(), 10, y());
> >}
>
> Did you submit bug report?
>
> --
> jk
>
> ---
> [ 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://www.research.att.com/~austern/csc/faq.html                ]
>


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Wed, 18 Jul 2001 17:59:28 GMT Gabriel Dos Reis wrote:
>jk@steel.orel.ru (Eugene Karpachov) writes:
>
>| Did you submit bug report?
>
>Why ?

--- /usr/local/gcc3.0/include/g++-v3/bits/stl_vector.h.orig Thu Jul 19 10:27:35 2001
+++ /usr/local/gcc3.0/include/g++-v3/bits/stl_vector.h Thu Jul 19 10:29:20 2001
@@ -623,3 +623,3 @@
         copy_backward(__position, __old_finish - __n, __old_finish);
-        fill(__position, __position + __n, __x_copy);
+        std::fill(__position, __position + __n, __x_copy);
       }
@@ -630,3 +630,3 @@
         _M_finish += __elems_after;
-        fill(__position, __old_finish, __x_copy);
+        std::fill(__position, __old_finish, __x_copy);
       }

etc. (from top of my head)

>:-)

?

--
jk

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

jk@steel.orel.ru (Eugene Karpachov) writes:

| >:-)
|
| ?

The issue raised by Dave is a DR with respect to the Standard.  There
is a proposed resolution which requires explicit qualification.
There still is some debate on related issues -- Dave knows the gory
details.

Personnally, I'm not positive about the proposed resolution because of
its implications.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<fl4rs8rcc8.fsf@sel.cmla.ens-cachan.fr>...
> jk@steel.orel.ru (Eugene Karpachov) writes:
>
> | >:-)
> |
> | ?
>
> The issue raised by Dave is a DR with respect to the Standard.  There
> is a proposed resolution which requires explicit qualification.
> There still is some debate on related issues -- Dave knows the gory
> details.

I doubt that any resolution of the issues in question would render
this legal. std::vector::insert is not documented to call fill() or
copy_backwards(). Dave's program is conforming.

The only resolution that could legalize this behavior is to
unconditionally reserve all std:: names in all namespaces. Even so,
the program is conforming now, regardless of whether it may become
non-conforming in the future.

Whether std::sort should use an unqualified call to iter_swap() is
another story.

--
Peter Dimov
Multi Media Ltd.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

pdimov@mmltd.net (Peter Dimov) writes:

| Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<fl4rs8rcc8.fsf@sel.cmla.ens-cachan.fr>...
| > jk@steel.orel.ru (Eugene Karpachov) writes:
| >
| > | >:-)
| > |
| > | ?
| >
| > The issue raised by Dave is a DR with respect to the Standard.  There
| > is a proposed resolution which requires explicit qualification.
| > There still is some debate on related issues -- Dave knows the gory
| > details.
|
| I doubt that any resolution of the issues in question would render
| this legal. std::vector::insert is not documented to call fill() or
| copy_backwards().

But there is nothing which prohibits doing so.

| Dave's program is conforming.

Did someone question whether Dave's program was conforming?
No.  So what?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"Paolo Carlini" <pcarlini@unitus.it> wrote in message
news:3B4EBCDF.89DB6A0A@unitus.it...
> Hi,
>
> pilot wrote:
>
> > Hello,
> >
> > I'd like to know if GCC 3.0 handles correctly the std namespace in
> > particular for the STL.
>
> The answer is a glorious YES.

Well, it sort of depends on what you mean.

> Anyway, you can test that yourself at
> http://www.codesourcery.com/gcc-compile.shtml

Try this, for example:

#include <vector>
struct fill {}; // comment out this line to compile successfully
struct y {};
void f()
{
   std::vector<y> x(10);
   x.insert(x.begin(), 10, y());
}




---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Hi,

David Abrahams wrote:

> Well, it sort of depends on what you mean.
>
> > Anyway, you can test that yourself at
> > http://www.codesourcery.com/gcc-compile.shtml
>
> Try this, for example:
>
> #include <vector>
> struct fill {}; // comment out this line to compile successfully
> struct y {};
> void f()
> {
>    std::vector<y> x(10);
>    x.insert(x.begin(), 10, y());
> }

This is interesting. Where that name ("fill") is coming from? Is this a known
problem? Otherwise, you should file a PR probably.

P.


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Tue, 17 Jul 2001 01:25:22 GMT David Abrahams wrote:
>Try this, for example:
>
>#include <vector>
>struct fill {}; // comment out this line to compile successfully
>struct y {};
>void f()
>{
>   std::vector<y> x(10);
>   x.insert(x.begin(), 10, y());
>}

Did you submit bug report?

--
jk

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Paolo Carlini <pcarlini@unitus.it> writes:

| Is this a known problem?

This is a known DR (with respect to the Standard).

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

jk@steel.orel.ru (Eugene Karpachov) writes:

| Did you submit bug report?

Why ?

:-)

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Hi,

pilot wrote:

> Hello,
>
> I'd like to know if GCC 3.0 handles correctly the std namespace in
> particular for the STL.

The answer is a glorious YES.
Anyway, you can test that yourself at
http://www.codesourcery.com/gcc-compile.shtml

Cheers,
Paolo.


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Hello,

I'd like to know if GCC 3.0 handles correctly the std namespace in
particular for the STL.

thanks,
    joseph.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]