Markus Schaaf wrote:

> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote:
>
> > Frankly the mix of, overloaded functions, overloaded function templat=
es
> > and completely specialisation of function templates is, IMHO, a
> > quicksand that we should never have got into.
>
> So it seems best to avoid specializations of function templates at
> all, at least for now. Actually this is no restriction, because one
> may utilize class template specializations and a function template
> for parameter deduction. Right?
>

IMHO, the "mix of, overloaded functions, overloaded function templates
and completely specialisation" is very much in the spirit of C++.
I can understand that it is difficult to find a wording for the priority =
rules

that is precise enough for the purpose of a standard,
but in most cases it should be intuitively clear which version is meant.

As long as we are forced to use function templates instead of member func=
tions

(cf. my still unanswered message with the subject
=B4Operator "." for built-in types=B4),
it will not be easily possible to avoid specializations of function templ=
ates.

Using function templates for parameter deductions might work
when you design your own libraries,
it will not work, however, when you have to use
third party libraries where you cannot change the code.

Helmut



---
[ 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 <3B80B12C.87871906@vai.at>, Helmut Zeisel
<helmut.zeisel@vai.at> writes
>but in most cases it should be intuitively clear which version is meant.

Unfortunately, compilers are notably deficient in the in tuition
department :(



Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

Helmut Zeisel <helmut.zeisel@aon.at> wrote in message news:<3B72FA02.FAFD0CA0@aon.at>...

> Andrei Iltchenko wrote:
> >
> > "Helmut Zeisel" <helmut.zeisel@vai.at> wrote in message
> > news:3B722D38.F81521E6@vai.at...
> >
> > > Must the following code compile?
> > >
> > > template<typename U> void f(U&) {}
> > > template<typename U> void f(const U&) {}
> > > template<typename T, typename U> T g(U&) {return 0;}
> > > template<typename T, typename U> T g(const U&) {return 0;}
> > >
> > > int main()
> > > {
> > >   const int j=5;
> > >   f(j);
> > >   g<double>(j);
> > >   return 0;
> > > }
> > >
> > > GCC 3.0 rejects g(j) with
> > >
> > > c++ main.cxx
> > > main.cxx: In function `int main()':
> > > main.cxx:10: call of overloaded `g(const int&)' is ambiguous
> > > main.cxx:3: candidates are: T g(U&) [with T = double, U = const int]
> > > main.cxx:4:                 T g(const U&) [with T = double, U = int]
> > >
> > > Is GCC right?
> > > Why should g(j) be ambiguous,
> > > while f(j) is unique?
> >
> > Precisely this problem has already been discussed here. Please refer to the
> > thread called "T & vs T const & overloading".
> >
>
> If you are referring to the thread started by Peter Dimov on 16 May
> 2001,
> it explains why f(j) is unique.
> It is, however, still not clear to me why g(j) should be ambiguous.

That thread doesn't explain anything of that sort! It refers you to a
DR that shows that the rules in 14.5.5.2 are inconsistent and
incomplete and then discusses that fact at some length. The Standard
doesn't make it clear which function shall be called for both the
function calls in your 'main' function.

One thing is certain, if the compiler finds the specialization
'void f<int>(const int&)' to be more specialized than
'void f<const int>(const int&)' for the function-call expression
'f(j)', then it shall also find 'double g<int>(const int&)' to be more
specialized than 'double g<const int>(const int&)' for the call
'g<double>(j)'. There should be no difference in the way that the
compiler treats the two calls. Given the state that 14.5.5.2 is in, it
could even find both the calls ambiguous.

I suggest that you report a bug through the GCC GNATS bug reporting
system.


Regards,

Andrei Iltchenko.

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

Helmut Zeisel wrote:

> Must the following code compile?
>
> template<typename U> void f(U&) {}
> template<typename U> void f(const U&) {}
> template<typename T, typename U> T g(U&) {return 0;}
> template<typename T, typename U> T g(const U&) {return 0;}
>
> int main()
> {
>   const int j=5;
>   f(j);
>   g<double>(j);
>   return 0;
> }
>
> GCC 3.0 rejects g(j) with

In the meanwhile I heard that Compaq C++ V6.3-002
actually compiles a similar example.

So I can reformulate my question to "Who is right - GCC or Compaq C++?"

Helmut

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

"Helmut Zeisel" <helmut.zeisel@vai.at> wrote:

> template<typename U> void f(U&) {}
> template<typename U> void f(const U&) {}
> template<typename T, typename U> T g(U&) {return 0;}
> template<typename T, typename U> T g(const U&) {return 0;}
>
> int main()
> {
>   const int j=5;
>   f(j);
>   g<double>(j);
>   return 0;
> }
>
> GCC 3.0 rejects g(j) with
>
> c++ main.cxx
> main.cxx: In function `int main()':
> main.cxx:10: call of overloaded `g(const int&)' is ambiguous
> main.cxx:3: candidates are: T g(U&) [with T = double, U = const int]
> main.cxx:4:                 T g(const U&) [with T = double, U = int]

This is exactly what language core issue #200 is about, which is
now covered by issue #214, that is still open. So there's nothing
you can do but wait until the working group comes up with a
resolution. It's not obvious to me why issue #200 has been closed.
IMO a resolution could have been made very similar to #250. #214
is rather old, and partial ordering of function templates is kind
of unusable without clarification.

---
[ 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 <9l0ekq$6ndsn$1@ID-3706.news.dfncis.de>, Markus Schaaf
<m.schaaf.exp-aug2001@gmx.de> writes
>This is exactly what language core issue #200 is about, which is
>now covered by issue #214, that is still open. So there's nothing
>you can do but wait until the working group comes up with a
>resolution. It's not obvious to me why issue #200 has been closed.
>IMO a resolution could have been made very similar to #250. #214
>is rather old, and partial ordering of function templates is kind
>of unusable without clarification.

When we looked at it, we realised that there further ramifications and
we want time to explore those before doing something that might prove to
be even more mistaken and even harder to correct. Bizarrely, deep inside
this mess there are some nasty interactions with friend, which become
important when we deal with complete specialisations.

Frankly the mix of, overloaded functions, overloaded function templates
and completely specialisation of function templates is, IMHO, a
quicksand that we should never have got into. Getting out of it is going
to take careful thought if we are to avoid sinking deeper.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote:

> When we looked at it, we realised that there further ramifications and
> we want time to explore those before doing something that might prove to
> be even more mistaken and even harder to correct.

I understand this (and nothing in my posting was meant to be an
offense).

> Frankly the mix of, overloaded functions, overloaded function templates
> and completely specialisation of function templates is, IMHO, a
> quicksand that we should never have got into.

So it seems best to avoid specializations of function templates at
all, at least for now. Actually this is no restriction, because one
may utilize class template specializations and a function template
for parameter deduction. Right?

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

Andrei Iltchenko wrote:

> I suggest that you report a bug through the GCC GNATS bug reporting
> system.

This is more or less the background of my question.
If it is clearly a bug, I will sent a bug report.

If it is, however, a problem of 14.5.5.2,
it makes no sense to send a bug report
unless I can bring some evidence
that the intention (not the words) of 14.5.5.2 is
that g<double>(j) should be accepted by a conforming compiler.

Helmut

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

Francis Glassborow wrote:

> In article <3B80B12C.87871906@vai.at>, Helmut Zeisel
> <helmut.zeisel@vai.at> writes
> >but in most cases it should be intuitively clear which version is meant.
>
> Unfortunately, compilers are notably deficient in the in tuition
> department :(

No AI compiler yet? ;-)

To make my point clear: I didn' t say that it is easy to implement lookup
rules,
I just say that IMHO it is possible (but maybe tedious)
to properly define lookup rules that match the
programmers expectations in the usual cases.

Helmut

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

"Helmut Zeisel" <helmut.zeisel@vai.at> wrote:

> I just say that IMHO it is possible (but maybe tedious)
> to properly define lookup rules that match the
> programmers expectations in the usual cases.

You are free to post your proposal to this newsgroup. ;-)

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

Helmut Zeisel wrote:
>
> Francis Glassborow wrote:
>
> > In article <3B80B12C.87871906@vai.at>, Helmut Zeisel
> > <helmut.zeisel@vai.at> writes
> > >but in most cases it should be intuitively clear which version is meant.
> >
> > Unfortunately, compilers are notably deficient in the in tuition
> > department :(
>
> No AI compiler yet? ;-)
>
> To make my point clear: I didn' t say that it is easy to implement lookup
> rules,
> I just say that IMHO it is possible (but maybe tedious)
> to properly define lookup rules that match the
> programmers expectations in the usual cases.

However, it's very nearly impossible to match most programmer's
expectations in all of the unusual cases. The best that can be done is
define something implementatable, and then to re-educate the programmers
so their expectations match what actually happens.

---
[ 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 Russell Kuyper Jr." wrote:

>
> However, it's very nearly impossible to match most programmer's
> expectations in all of the unusual cases.

Can you give a specific example where you think
programmer's expectations differ?

Helmut

---
[ 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 <3B81FCA5.80A53265@vai.at>, Helmut Zeisel
<helmut.zeisel@vai.at> writes
>To make my point clear: I didn' t say that it is easy to implement lookup
>rules,
>I just say that IMHO it is possible (but maybe tedious)
>to properly define lookup rules that match the
>programmers expectations in the usual cases.

You obviously have no idea how many person years have already been
consumed getting where we are now. Name lookup is probably the hardest
problem in the whole of C++.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

Helmut Zeisel wrote:
>
> "James Russell Kuyper Jr." wrote:
>
> >
> > However, it's very nearly impossible to match most programmer's
> > expectations in all of the unusual cases.
>
> Can you give a specific example where you think
> programmer's expectations differ?
>
> Helmut

See <http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_index.html>.
Virtually every defect report that involves name lookup can be described
as a discrepancy between the way two different people expected the code
to work.

That list is not an ideal example of "differing expectations"; however,
it speaks directly to what I was actually trying to say: that writing
consistent, implementible, useful, and intuitively obvious lookup rules
is very difficult. It's sometimes necessary to jetison one of those
characteristics, and 'obvious' is the only one of the four I'd even
consider dropping.

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

Markus Schaaf wrote:
>
> "Helmut Zeisel" <helmut.zeisel@vai.at> wrote:
>
> > I just say that IMHO it is possible (but maybe tedious)
> > to properly define lookup rules that match the
> > programmers expectations in the usual cases.
>
> You are free to post your proposal to this newsgroup. ;-)
>

I wrote already a proposal how to define operator "."
for built-in types to avoid many template functions
that have to be overloaded.
As you know, this proposal is still unanswered.

Helmut

---
[ 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 Russell Kuyper Jr." wrote:

> See <http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_index.html>.
> Virtually every defect report that involves name lookup can be described
> as a discrepancy between the way two different people expected the code
> to work.

Maybe.
I do not see, however, how this applies to the partial ordering of function
templates.

Compaq C++ V6.3-002 does it for my example
in the way which is "obvious" for me,
GCC 3.0 does not have a different expectation how it should work,
it just does not accept the code.

I would like to see that the standard clarifies that the interpretation of
Compaq C++ V6.3-002 is right in that point.
It is an existing implementation, so this should be possible.

I do not see why partial ordering of function templates
should be a contradiction in terms,
but if you could give me a concrete example where I can see the
contradiction,
I might change my mind.


>  writing
> consistent, implementible, useful, and intuitively obvious lookup rules
> is very difficult.

I have never doubted this.
Let me point out that I never said that the committee did bad work.
On the contrary, I think they did (and still do) very good work.
This does not mean that their work is perfect,
but we all know that there is nothing perfect in the real world...


> It's sometimes necessary to jetison one of those
> characteristics, and 'obvious' is the only one of the four I'd even
> consider dropping.

If you drop 'obvious', you might better throw away C++ and
design a new language with a formal grammer from scratch.
The result will not be obvious either, but at least consistent.
Whether it will be useful is questionable, too.

Helmut


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

Francis Glassborow wrote:
>
> In article <3B81FCA5.80A53265@vai.at>, Helmut Zeisel
> <helmut.zeisel@vai.at> writes
> >To make my point clear: I didn' t say that it is easy to implement lookup
> >rules,
> >I just say that IMHO it is possible (but maybe tedious)
> >to properly define lookup rules that match the
> >programmers expectations in the usual cases.
>
> You obviously have no idea how many person years have already been
> consumed getting where we are now.

Maybe

> Name lookup is probably the hardest
> problem in the whole of C++.
>

Did I say something different? (possible != easy)

Helmut

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

Must the following code compile?

template<typename U> void f(U&) {}
template<typename U> void f(const U&) {}
template<typename T, typename U> T g(U&) {return 0;}
template<typename T, typename U> T g(const U&) {return 0;}

int main()
{
  const int j=5;
  f(j);
  g<double>(j);
  return 0;
}

GCC 3.0 rejects g(j) with

c++ main.cxx
main.cxx: In function `int main()':
main.cxx:10: call of overloaded `g(const int&)' is ambiguous
main.cxx:3: candidates are: T g(U&) [with T = double, U = const int]
main.cxx:4:                 T g(const U&) [with T = double, U = int]

Is GCC right?
Why should g(j) be ambiguous,
while f(j) is unique?

Helmut

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

"Helmut Zeisel" <helmut.zeisel@vai.at> wrote in message
news:3B722D38.F81521E6@vai.at...

> Must the following code compile?
>
> template<typename U> void f(U&) {}
> template<typename U> void f(const U&) {}
> template<typename T, typename U> T g(U&) {return 0;}
> template<typename T, typename U> T g(const U&) {return 0;}
>
> int main()
> {
>   const int j=5;
>   f(j);
>   g<double>(j);
>   return 0;
> }
>
> GCC 3.0 rejects g(j) with
>
> c++ main.cxx
> main.cxx: In function `int main()':
> main.cxx:10: call of overloaded `g(const int&)' is ambiguous
> main.cxx:3: candidates are: T g(U&) [with T = double, U = const int]
> main.cxx:4:                 T g(const U&) [with T = double, U = int]
>
> Is GCC right?
> Why should g(j) be ambiguous,
> while f(j) is unique?

Precisely this problem has already been discussed here. Please refer to the
thread called "T & vs T const & overloading".


Regards,

Andrei Iltchenko.




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

Andrei Iltchenko wrote:
>
> "Helmut Zeisel" <helmut.zeisel@vai.at> wrote in message
> news:3B722D38.F81521E6@vai.at...
>
> > Must the following code compile?
> >
> > template<typename U> void f(U&) {}
> > template<typename U> void f(const U&) {}
> > template<typename T, typename U> T g(U&) {return 0;}
> > template<typename T, typename U> T g(const U&) {return 0;}
> >
> > int main()
> > {
> >   const int j=5;
> >   f(j);
> >   g<double>(j);
> >   return 0;
> > }
> >
> > GCC 3.0 rejects g(j) with
> >
> > c++ main.cxx
> > main.cxx: In function `int main()':
> > main.cxx:10: call of overloaded `g(const int&)' is ambiguous
> > main.cxx:3: candidates are: T g(U&) [with T = double, U = const int]
> > main.cxx:4:                 T g(const U&) [with T = double, U = int]
> >
> > Is GCC right?
> > Why should g(j) be ambiguous,
> > while f(j) is unique?
>
> Precisely this problem has already been discussed here. Please refer to the
> thread called "T & vs T const & overloading".
>

If you are referring to the thread started by Peter Dimov on 16 May
2001,
it explains why f(j) is unique.
It is, however, still not clear to me why g(j) should be ambiguous.

Helmut

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