This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/6424] [DR 339] sizeof() with overload resolution
- From: "gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Aug 2004 16:56:57 -0000
- Subject: [Bug c++/6424] [DR 339] sizeof() with overload resolution
- References: <20020423071601.6424.jens.maurer@gmx.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From gdr at integrable-solutions dot net 2004-08-09 16:56 -------
Subject: Re: [DR 339] sizeof() with overload resolution
"bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| This is getting off-topic, but maybe you have a short answer anyway:
|
| > For functions templates, the situation is radically different because
| > the expressions involved in function template declarations are part of
| > its signature. And you can get function templates with "neighboor"
| > signatures co-existing in the same translation unit, without violating
| > the ODR.
|
| I understand that the return type is important for things like SFINAE,
| in order to decide which function to actually call.
But, it is not just limited to SFINAE.
| However, once this is decided, there needs to be exactly one
| instance, with a presumably unique signature, constants being folded
| or not.
|
| For example, this code is valid:
| -----------------
| template <int> struct S {};
|
| template <typename T>
| S<sizeof(T)> foo (T);
|
| template <typename T>
| S<sizeof(T)*2/2> foo (T);
| -----------------
| However, when you want to call these functions, you get an ambiguity. Do
If you get an ambiguity then you get a compile-time error, so there
would be no worry about mangling anything because we don't have
anything to mangle.
The real issue is when you don't have ambiguity.
The fundamental point is that every specialization "belongs" to its
primary template. We know a specialization only through its
primary template and the template arguments list used to get that
specialization. Not through its mangled name. Primary templates that
are considered distinct should engender distinct specializations.
Otherwise you would introduce an ODR violation where the C++ standard
does not say there is. For example, consider the language in 14.5.5.1/5.
// h1.H
template<int, int> struct X { /* ... */ };
template<in> struct Y { /* ... */ };
// h2.H
#include "h1.H"
export template<int I, int J> X<I+J> f(Y<I>, Y<J>);
// h3.H
#include "h1.H"
export template<int I, int J> X<I-J> f(Y<I>, Y<J>);
// t2.C
#include "h2.H"
X<0> g()
{
Y<0> y0;
Y<0> y1;
return f(y0, y1); // call f from h2.H
}
// t3.C
#include "h3.H"
X<0> h()
{
Y<0> y0;
Y<0> y1;
return f(y0, y1); // call f from h3.H
}
// main.C
#include "h1.H"
extern X<0> g();
extern X<0> h();
int main()
{
g();
h();
}
Consider the program main.C + t2.C + t3.C. How do you make sure that
the different functions f() (usually referenced through their mangled
names) get correctly referenced without transmuting the program
semantics?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6424