[Bug c++/26974] New: hidden declarations klobber STL

[Bug c++/26974] New: hidden declarations klobber STL

[igodard at pacbell dot net]

The program:
#include <vector>
#include "absParse.hh"


int main( int argc, char *argv[] )
{
  std::vector<int> v;
  v.resize(1);
  return 0;
}

compiles but gets a segv in the resize() call on several different g++
versions. The problem seems to have something to do with declarations of
operator,() in absParse.hh hijacking a loop in the STL where operator,() is
used to do two iterator increments: "for( ; i < last; ++i, ++j ) { ... }"

A full save-temps is attached

Ivan


-- 
           Summary: hidden declarations klobber STL
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug c++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #1 from igodard at pacbell dot net  2006-04-01 08:25 -------
Created an attachment (id=11178)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11178&action=view)
compiler output


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug c++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #2 from igodard at pacbell dot net  2006-04-01 08:26 -------
Created an attachment (id=11179)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11179&action=view)
source code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug c++/26974] hidden declarations klobber STL

[bangerth at dealii dot org]

------- Comment #3 from bangerth at dealii dot org  2006-04-19 02:57 -------
As usual, a shorter testcase would have been appreciated. However, here there
is really nothing that we can do: the executable doesn't link at all. I
have plenty of missing symbols, for example
  hide::notAssembler
  hide::inv::count
and six or eight others. Can you actually link your preprocessed sources?

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug c++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #4 from igodard at pacbell dot net  2006-04-19 06:36 -------
I can send you a linked binary with symbols, for either x86 Linux or Cygwin.
Would that help?

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug c++/26974] hidden declarations klobber STL

[bangerth at dealii dot org]

------- Comment #5 from bangerth at dealii dot org  2006-04-19 14:11 -------
No, because then I can't play around with the source. But seriously,
how is the code supposed to be linkable when for example noAssembler
only has a declaration, no definition?

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug c++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #6 from igodard at pacbell dot net  2006-04-20 02:43 -------
Don't know what to do then - the actual failing binary comprises 200k lines
over a hundred or so modules, all in our internal build environment. 

The problem pretty clearly had something to do with overloading operator,() and
a call inside the STL leaking out to an overload in our code, because it went
away when I changed the name of our operator. However, I wasn't able to reduce
the case.

So I guess close it. Maybe somebody else will get lucky :-) 

Thanks anyway

Ivan 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug c++/26974] hidden declarations klobber STL

[bangerth at dealii dot org]

------- Comment #7 from bangerth at dealii dot org  2006-04-20 03:46 -------
(In reply to comment #6)
> The problem pretty clearly had something to do with overloading operator,() and
> a call inside the STL leaking out to an overload in our code, because it went
> away when I changed the name of our operator. However, I wasn't able to reduce
> the case.

I believe you that it had to do with operator, -- there is just nothing that
I can do to figure out what is going on without a testcase that I can
compile, run, and let crash :-(

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[bangerth at dealii dot org]

------- Comment #8 from bangerth at dealii dot org  2006-04-20 04:13 -------
Thinking about it some more, I can come up with something. Take this
code here:
---------------------
class specReg{};

template<typename T>
int operator,(int i, T t) { abort(); return i; }

#include <vector>

int main()
{
  std::vector<int> v;
  v.resize(1);
  return 0;
}
----------------------
When compiled, I indeed get a reference to the operator, :

g/d> c++ -c x.cc
g/d> nm -C x.o | grep operator,
00000000 W int operator,<__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > > >(int, __gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >)

I guess it is a question to the libstdc++ people if this is what they want.
By tracing the abort() in the debugger, I can see where it comes from, namely
from std::fill_n(). 

I think this place is harmless: we're in a for-loop and the comma-separated
expressions return something that is unused. Since both expressions used 
as arguments are evaluated completely before the call, nothing bad can happen.

The only place I can possibly conceive it matters is in something like this:

  a = (b,c);

and with a definition of operator, (taken from your code) that is admittedly
pretty much asking for trouble:

  template<typename T>
  hide::inv operator,(specReg r, T t) { return t, r(); }

With such a definition, you make sure that after the assignment a==c, not
a==b. I think you're already pretty much shooting yourself in the foot with
defining an operator, that takes a template argument, and I must admit I have
very little sympathy for then even exchanging the values.

That said: Why do you think this is a bug? In the short example I posted,
why should ::operator, not be called?

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
          Component|c++                         |libstdc++
         Resolution|WORKSFORME                  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #9 from igodard at pacbell dot net  2006-04-20 08:20 -------
I believe it is a bug because my declaration should not be able to hijack the
use inside the STL, which should only be seeing the declarations that were
visible where the STL function was defined, which did not include any of my
code. That is, my operator should not have been on the resolution list for the
STL use. Your example  has the STL declaration *after* the operator
declaration, so the operator is visible. The test case I sent in had the STL
first.

Also, even if my operator was visible, why was it called when it wants a
specReg left operand and didn't get one? The other overloads also all want
particular classes as left operands, and the STL case should have been none of
them, even if they were visible. You have created a case where the left operand
is int but mine declarations all have particular classes as left operand.

The operator,() is used here as a metaprogramming device so that a
comma-separated list can be eaten and and its elements lightly processed and
then saved in a compile-time structure for later processing. The particular
situation requires that the form be syntactically a comma-separated list, and
some other operator or functional notation would not do. As I recall, the
swapping template was because I needed to work around a language restriction
whereby operator,() cannot discriminate on the second operand (being by
definition defined for left operand and anything). The swapping let me
double-dispatch so I could dispatch (in the second invocation) on what had been
the right operand but was now the left. But I no longer recall.

Is there anything in the Standard that precludes having a templated
operator,()? I'd guess that the same bug might be evidenced with operator&& and
operator|| as well, because these three have nonstandard (er - uncommon)
binding behavior.

Hope this helps

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #10 from pcarlini at suse dot de  2006-04-20 09:10 -------
Well, two comments: first, I cannot reproduce with current mainline. Second,
frankly, if the implication of the issue is that in the entire implementation
of <algorithm> we cannot use operator, only to allow the user to write
unrestricted operator, templates in the face of the ADL trickeries, then, well,
I don't think we are going to buy that. Before closing this I'm only curious to
know why mainline is fine, maybe, simply, ADL was too zelant here? Any language
lawyer kicking in?


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #11 from pcarlini at suse dot de  2006-04-20 09:25 -------
(In reply to comment #10)
                                          Before closing this I'm only curious
to
> know why mainline is fine, maybe, simply, ADL was too zelant here? Any language
> lawyer kicking in?

The reason seems trivial, actually: in mainline vector is a little different
(better ;) and avoids some pointless calls to copy/fill.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #12 from igodard at pacbell dot net  2006-04-20 09:28 -------
I don't think that the problem is in the STL. The STL can be as tricky as it
wants, including use of operator,(). It should not be possible for the actual
operator,()s I declared to hijack the STL the way that happened, because 1) my
declarations were out of scope for the STL code and 2) their signatures did not
match the STL call site. This suggests a compiler bug to me, not an STL
mis-design. 

A bug for this operator is not unlikely, because operator,() has unusual
semantics that would force non-standard handling within the compiler, and the
special code for it is probably not exercised as well as the main operator
invocation path. It certinly looks to me like a template that uses operator,()
that is defined before a second declaration of that operator but instantiated
after the second declaration is seeing the second dec when parsing the body of
the instantiation

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #13 from igodard at pacbell dot net  2006-04-20 09:31 -------
p.s. Another requirement for the failure probably is that the second
declaration has to be a templated operator,() of the form I used i.e. right
argument a free template argument.

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #14 from pcarlini at suse dot de  2006-04-20 09:37 -------
(In reply to comment #12)
> I don't think that the problem is in the STL. The STL can be as tricky as it
> wants, including use of operator,(). It should not be possible for the actual
> operator,()s I declared to hijack the STL the way that happened, because 1) my
> declarations were out of scope for the STL code and 2) their signatures did not
> match the STL call site. This suggests a compiler bug to me, not an STL
> mis-design.

Actually, I'm not at all sure, given: 1- our vector<>::iterator not being a
built-in type; 2- ADL rules. 3- The nature of fill_n (templated on *both* _Size
and _OutputIterator). Again, I'm not a language lawyer, but I think that,
strictly speaking, the compiler may legally find and match your operator,

I can certainly patch fill_n to avoid the operator, no big deal, my question is
more general, whether, given our class-type vector<>::iterator, given the
"unrestrictedness" of many <algorithm> templates, given current ADL rules,
whether it makes sense for us to go that route trying piecewise to "improve"
now the library, in the current C++03 framework.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #15 from pcarlini at suse dot de  2006-04-20 09:56 -------
We can easily get a reference to the user defined operator, from the mainline
compiler with:

template<typename T>
int operator,(int i, T t) { return i; }

#include <vector>

int main()
{
  std::vector<int> v;

  std::fill_n(v.begin(), 0, 1);
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #16 from igodard at pacbell dot net  2006-04-20 09:57 -------
Well, I don't see how the templating of the STL code can influence whether or
not my declarations are in scope or not.

BTAIM, my declarations are certainly inappropriate for what the STL is looking
for at the call site. Assuming that user declarations are in scope, the only
thing I can think of that the STL might do to avoid unwittingly falling into
user code in cases like this is to apply boost-style concept checks, which
would have immediately eliminated my operators from consideration in this case.

However, adding concept checks to a large hunk of wooly code is not trivial. We
use them, and our experience is that they are well worth the effort because
they expose subtle bugs in our semantics, but they are not free to implement,
especially if the code was not originally written with concept-checking in
mind.

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #17 from igodard at pacbell dot net  2006-04-20 09:58 -------
Yes, you pick up my operator in Wolfgang's test case. But in the original
submission the vector code is *before* my operators, which are consequently out
of scope for the STL code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #18 from pcarlini at suse dot de  2006-04-20 10:20 -------
This is a self-contained example:

namespace mine1
{
  struct mini_iter
  {
    mini_iter(int* p)
    : _M_current(p) { }

    int&
    operator*() const
    { return *_M_current; }

    mini_iter&
    operator++()
    {
      ++_M_current;
      return *this;
    }

  private:
    int* _M_current;
  };
}

namespace mine2
{
  template<typename _OutputIterator, typename _Size, typename _Tp>
  _OutputIterator
  fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
  {
    for (; __n > 0; --__n, ++__first)
      *__first = __value;
    return __first;
  }

  void f(int* p) { fill_n(mine1::mini_iter(p), 1, 1); }
}

template<typename T>
  int operator,(int i, T t) { __builtin_trap(); return i; }

int main()
{
  int arr[1];
  mine2::f(arr);
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #19 from pcarlini at suse dot de  2006-04-20 11:32 -------
By the way, I think I mentioned incorrectly ADL, which, in this specific case,
doesn't seem involved.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #20 from pcarlini at suse dot de  2006-04-20 11:56 -------
Everything considered, I don't think there is something to fix here, either in
the compiler (and all the other compilers I tried bahaves the same of current
g++ on Comment #18, irrespective of the position of the overloaded operator, of
course) or in the library: agreed, std::fill_n could be made more robust
restricting the second template argument, but this is really matter for C++0x.
Otherwise, the problem would immediately go away if vector<>::iterator were a
plain pointer, but that is not an option for our implementation.

Agreed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #21 from pcarlini at suse dot de  2006-04-20 11:59 -------
(In reply to comment #20)
                                          std::fill_n could be made more robust
> restricting the second template argument,

Scratch this bit, sorry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[bangerth at dealii dot org]

------- Comment #22 from bangerth at dealii dot org  2006-04-20 14:10 -------
(In reply to comment #17)
> Yes, you pick up my operator in Wolfgang's test case. But in the original
> submission the vector code is *before* my operators, which are consequently out
> of scope for the STL code

That is factually incorrect, as you can easily check in your code: the
declarations involving operator, and hide::inv are in global namespace.

Both Paolo and I have come up with small test codes, but they don't seem
to to be to your liking. If you insist on there being something wrong,
I can only urge you to show us a small piece of code that we can look over,
and explain to us why you think that the compiler is wrong. Just waving
hands, talking about ADL, claiming that something is wrong, and pointing to a
60,000 line chunk of code isn't going to get us somewhere. Where's the meat?


On a different note, as a teacher, I can't help to wonder who in his right
mind thought it would be a good idea to come up with code like this:
-----------------------
hide::inv operator,(hide::inv l, hide::inv r) { return hide::inv(); }

template<typename T>
hide::inv operator,(hide::inv l, T t) { return t, hide::inv(); }

template<typename T>
hide::inv operator,(T t, hide::inv r) { return hide::notAssembler(); }
-----------------------
I mean, it's a miracle your code actually does what you expect. From a
code design viewpoint, everyone seems to agree that overloading operator, 
is already a Really Bad Idea (TM), but to do so in global namespace, using
templated arguments, and then not even returning the second argument must
be something that everyone recognizes as an accident in the making, no?

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pinskia at gcc dot gnu dot org]

------- Comment #23 from pinskia at gcc dot gnu dot org  2006-04-20 16:24 -------
Actually I don't see why the comma operator can be overridden in C++ (yes this
I am raising a question about why the standards says it can).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[bangerth at dealii dot org]

------- Comment #24 from bangerth at dealii dot org  2006-04-20 18:16 -------
(In reply to comment #23)
> Actually I don't see why the comma operator can be overridden in C++ (yes this
> I am raising a question about why the standards says it can).

It was mid-March when Stroustrup developed operator overloading. The draft
was finished March 31th, and the next day he didn't know what to do and
thought of adding something to the language appropriate for the day.

Just like this, a few years later:
  http://public.research.att.com/~bs/whitespace98.pdf

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #25 from igodard at pacbell dot net  2006-04-20 18:40 -------
Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why
operator,() was overloadable in the Rationale.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #26 from igodard at pacbell dot net  2006-04-20 19:15 -------
Sorry, fat fingered a submit before message was done, please ignore immediately
previous message. Corrected full one follows later

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #27 from pcarlini at suse dot de  2006-04-20 23:10 -------
(In reply to comment #23)
> Actually I don't see why the comma operator can be overridden in C++ (yes this
> I am raising a question about why the standards says it can).

Well, if we are talking about rationale and programming style, then authors
like Lippman/Lajoie/Moo in general advice against overloading operator,
(14.1.1).

But really, now the point seems to me rather clear: it is essentially
impossible to "protect" the library vs all the possible operator overloadings
in global namespace (consider also things like operator|| and operator&&)
together with unrestricted templates (thus "enabled" not only for user defined
types): if the user does that then has to accept the behavior he gets.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[igodard at pacbell dot net]

------- Comment #28 from igodard at pacbell dot net  2006-04-21 04:07 -------
Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why
operator,() was overloadable in the Rationale.

I still think that there is a problem here. If you try to overload other 
built-in operators in a way that intercepts the normal meaning you get: 
"foo1.cc:2: error: 'int operator+(int, int)' must have an argument of class or 
enumerated type", so maybe the compiler should have flagged my declarations.

But I think that the actual error is that *in my actual code* every one of my 
operator,() declarations had a local class as one or the other or both
argument. 
However, the intercepted usage was (int&, <some iterator class>&). Consequently 
the usage should have failed to identify my declarations and so should not have 
intercepted.

Note that #18 simplifies all the arguments to "int", but that was not the 
original case. If you change #18 to what actually happened:
#include <iostream>

namespace mine1
{
template<typename U>
struct mini_iter
{
mini_iter(U* p)
: _M_current(p) { }

U&
operator*() const
{ return *_M_current; }

mini_iter&
operator++()
{
++_M_current;
return *this;
}

private:
U* _M_current;
};
}

namespace mine2
{
template<typename _OutputIterator, typename _Size, typename _Tp>
_OutputIterator
fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
{
for (; __n > 0; --__n, ++__first)
*__first = __value;
return __first;
}

template<typename W>
void f(W* p) { fill_n(mine1::mini_iter<W>(p), 1, *p); }
}

struct bar{ int i;};

template<typename T>
T operator,(bar i, T t) { std::cerr << "interceptor\n"; return i; }


int main()
{
bar arr[1];
mine2::f(arr);
}

then the declaration does *not* intercept the STL, i.e. it does not fail. Yet i
my actual (more complicated) case it still did. 

So we have a test case (#18) that shows the problem but is correct behavior; a 
test case (this one) that doesn't fail; and my original code that looks like
the 
second but fails like the first, but which I cannot provide to you.

I think there's a bug here, but I agree that we don't have enough to
demonstrate 
its existance much less fix it. So let's close the ticket and hope somebody
else 
reports it (if bug it is) in something that is small enoughh to manage.

Thanks for your help and the useful discussion.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #29 from pcarlini at suse dot de  2006-04-21 10:08 -------
(In reply to comment #28)
> Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why
> operator,() was overloadable in the Rationale.

What about this:

  http://public.research.att.com/~bs/whitespace.html

:-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[pcarlini at suse dot de]

------- Comment #30 from pcarlini at suse dot de  2006-04-22 08:47 -------
(In reply to comment #28)

> template<typename _OutputIterator, typename _Size, typename _Tp>
> _OutputIterator
> fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
> {
> for (; __n > 0; --__n, ++__first)

[snip]

> template<typename W>
> void f(W* p) { fill_n(mine1::mini_iter<W>(p), 1, *p); }

[snip]

> template<typename T>
> T operator,(bar i, T t) { std::cerr << "interceptor\n"; return i; }

[snip]

> then the declaration does *not* intercept the STL, i.e. it does not fail.

No mistery, here, __n is an int, doesn't match bar of the overloaded operator,

Ok, let's close this one. Thanks and sorry about a bit of confusion on my part
in the first comments.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[gdr at integrable-solutions dot net]

------- Comment #31 from gdr at integrable-solutions dot net  2006-05-01 18:55 -------
Subject: Re:  hidden declarations klobber STL

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| Well, two comments: first, I cannot reproduce with current mainline. Second,
| frankly, if the implication of the issue is that in the entire implementation
| of <algorithm> we cannot use operator, only to allow the user to write
| unrestricted operator, templates in the face of the ADL trickeries, then,
well,
| I don't think we are going to buy that. Before closing this I'm only curious
to
| know why mainline is fine, maybe, simply, ADL was too zelant here? Any
language
| lawyer kicking in?

Why is operator, essential to libstdc++?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[gdr at integrable-solutions dot net]

------- Comment #32 from gdr at integrable-solutions dot net  2006-05-01 18:59 -------
Subject: Re:  hidden declarations klobber STL

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #14 from pcarlini at suse dot de  2006-04-20 09:37 -------
| (In reply to comment #12)
| > I don't think that the problem is in the STL. The STL can be as tricky as
it
| > wants, including use of operator,(). It should not be possible for the
actual
| > operator,()s I declared to hijack the STL the way that happened, because 1)
my
| > declarations were out of scope for the STL code and 2) their signatures did
not
| > match the STL call site. This suggests a compiler bug to me, not an STL
| > mis-design.
| 
| Actually, I'm not at all sure, given: 1- our vector<>::iterator not being a
| built-in type; 2- ADL rules. 3- The nature of fill_n (templated on *both*
_Size
| and _OutputIterator). Again, I'm not a language lawyer, but I think that,
| strictly speaking, the compiler may legally find and match your operator,

Yes.

| I can certainly patch fill_n to avoid the operator, no big deal, my question
is
| more general, whether, given our class-type vector<>::iterator, given the
| "unrestrictedness" of many <algorithm> templates, given current ADL rules,
| whether it makes sense for us to go that route trying piecewise to "improve"
| now the library, in the current C++03 framework.

I believe it makes sense to do so the extent we can -- we (e.g. *you*) did
patch the library so that qualified call where OK, e.g. std::copy, where
we did so only for implementation details.  The use of operator, in
this case is no different.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974

[Bug libstdc++/26974] hidden declarations klobber STL

[gdr at integrable-solutions dot net]

------- Comment #33 from gdr at integrable-solutions dot net  2006-05-01 19:02 -------
Subject: Re:  hidden declarations klobber STL

"bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I mean, it's a miracle your code actually does what you expect.

:-))

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974