Re: Incomplete type in template parameter, complete type as
argument
On 4/11/07 9:01 AM, in article
1176302440.110184.69550@d57g2000hsg.googlegroups.com, "James Kanze"
<james.kanze@gmail.com> wrote:
On Apr 9, 3:35 am, gre...@pacbell.net (Greg Herlihy) wrote:
No, an unbounded array type is not at all "compatible" with a
bounded array type
You mean we've broken something that fundamental? It certainly
is in C, and IIRC, something like the following worked in
CFront:
void f( int (&array)[] ) ;
void g()
{
int a[ 3 ] ;
f( a ) ;
}
There's no reason why it shouldn't work, and it seems a bit
broken if it doesn't. (Of the two compilers I have access to,
one accepts it, the other doesn't.)
- they are distinct and completely different types - as the following
program demonstrates (confirmed with gcc, Comeau and EDG):
...
That I can understand. You can't use an incomplete type where a
complete type is required. The reverse should work.
No, switching the bounded and unbounded array types around - also fails -
and with the same error message as before:
template <int (&a)[]>
void f() {}
int s[] = { 1 };
int main()
{
f<s>(); // error: no matching function for call to 'f'
}
Moving the definition of "s" before main() does compile successfully (=
again,
on all three C++ compilers tested), because moving the definition actu=
ally
changes the type of "s". Unlike forwardly-declared types (which have a
consistent type before and after the type is completed), the type of a=
n
array object actually changes once the array's type is completely defi=
ned.
That is the significant point that you do not seem to have realized ju=
st
yet.
I realize it, that's why I spoke of "compatible" types, and not
the same type. (And I know, that actual concept of compatible
types is from the C standard, not from C++.)
C++ has not retained C's notion of "compatible types" - at least not as f=
ar
as templates are concerned.
Furthermore, there is no such thing as "compatible" types when it come=
s to
templates.
That is the crux of my question. If g++ had refused to
instantiation the template in my example, I would put it down to
that. What it did, however, was generate error messages from
the instantiation.
No, the compiler is not instantiating the function template accept() (and
the error that the gcc reports in the original program - is not an
instantiation failure.) Instead, the compiler has simply detected (during
the course of resolving the accept() function call) that the definition o=
f
the accept() template function is ill-formed.
According to =A714.6/7, the compiler may issue a diagnostic message for a=
n
ill-formed (even if never instantiated) template definition. (In fact, th=
e
point at which a compiler detects and reports this kind of error is left =
up
to the compiler as a "qualify of implementation" issue). As an example:
void Begin( int (&p)[1])
{
}
extern int s[];
template < int N>
void f()
{
Begin(s); // Error: invalid initialization of reference
}
int s[] = { 1 };
int main()
{
}
In the above program, the gcc compiler reports an error in the f() functi=
on
template - even though the function template f() in which the error is fo=
und
- is never instantiated at all. The issue in the original program is
comparable: gcc found an error in accept() - even though the accept()
function template was not instantiated.
So the conclusion here is simply that bounded and unbounded array types a=
re
not at all alike in C++. So C++ programs that deal with those two types -
must accommodate the difference.
Greg
---
[ 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.comeaucomputing.com/csc/faq.html ]