Re: Incomplete type in template parameter, complete type as argument
On Apr 9, 3:35 am, gre...@pacbell.net (Greg Herlihy) wrote:
On 4/8/07 1:17 PM, in article
1176052237.259633.230...@o5g2000hsb.googlegroups.com, "James Kanze"
<james.ka...@gmail.com> wrote:
On Apr 8, 3:27 am, gre...@pacbell.net (Greg Herlihy) wrote:
On 4/6/07 8:59 AM, in article
1175859305.420565.301...@y80g2000hsf.googlegroups.com, "James Kanze"
<james.ka...@gmail.com> wrote:
The tbl array attempts to instantiate the accept() function
template with two bounded arrays types (meaning that in
each instance the nontype argument is a complete type). The
attempt to instantiate accept() fails (and fails correctly)
because the nontype argument used to instantiate accept()
in both cases is not the same type as the type specified in
accept's function template declaration.
The instantiation doesn't fail, and if I modify the code to use
a sentinal value, rather that "begin()" and "end()", it works
perfectly. char const* [N] (with N a compile time constant) is
"compatible" with char const* [].
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):
template <int N, int (&a)[N]>
void f() {}
extern int s[];
int main()
{
f<1, s>(); // error: no matching function for call to 'f'
}
int s[] = { 1 };
That I can understand. You can't use an incomplete type where a
complete type is required. The reverse should work.
Moving the definition of "s" before main() does compile successfully (again,
on all three C++ compilers tested), because moving the definition actually
changes the type of "s". Unlike forwardly-declared types (which have a
consistent type before and after the type is completed), the type of an
array object actually changes once the array's type is completely defined.
That is the significant point that you do not seem to have realized just
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++.)
Furthermore, there is no such thing as "compatible" types when it comes 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.
Granted, a limited number of conversions is allowed for certain
non-type arguments - but none are allowed for reference non-type arguments.
Therefore there is no conversion between an incomplete array type and any
bounded array type. Besides, if complete and incomplete array types were
compatible, then the following overloads of f() should be ambiguous:
template <int (&a)[]>
void f() {}
template <int (&a)[1]>
void f() {}
But they are not ambiguous in the least.
That's an interesting point. I would argue that one is a better
match... matching the exact type is a better match than matching
a "compatible" type. But I don't know that the standard
actually considers this case.
There's not the slightest doubt that the template function
should be instantiated.
The EDG, gcc, and Comeau C++ compilers show not the slightest doubt that a
complete array type cannot be passed as a template nontype argument where an
incomplete array type has been declared.
G++ seems to agree in simple cases, but not when the code
becomes more complicated (as in my example). In my example, it
complained about not finding a match for begin() and end()
(which means that it must be instantiating the function, since
these are dependent function calls).
In other words, as long as the program tries to instantiate
accept() with a array whose type is complete, the program will
not compile successfully.
If I replace the call to std::find_if (and the begin and end's),
and use a sentinal, it does compile.
The question centers around the notion
of when the incompleteness is resolved: in the definition of the
template, or when the template is instantiated. And it is
linked to a dependant function call---if I call a dependent
function in a template in which the parameter type is
incomplete, but the instantiation type is complete, does the
dependent fonction see the complete type, or only the
incomplete. (In the case of g++, it only sees the incomplete
type, but the question seems awkward enough that I want an
answer based on the standard.)
The answer is that the type of the argument is determined at the point that
the template instantiation appears in the source file - and that is the
reason why moving the definition of the array after that point works - while
having the definition appear prior to that point - is certain to fail.
In other words, an incomplete array type is a
different type than a complete array type:
Different, but compatible.
Either the types are the same or they are different. Since they are
different in this case - the types are incompatible.
Even in C++, the notion of compatible type exists. Whether it
applies with regards to incomplete and complete array types, I'm
not sure, and whether it applies in this case, even less, but
the concept is there (if only for reasons of C compatibility, in
certain cases).
"The declared type of an array object might be an array of unknown size and
therefore be incomplete at one point in a translation unit and complete
later on;
That is exactly the phrase on which my problem hinges. The type
is incomplete when the template is defined, but it is complete
when the template is instantiated.
The accept() function template was defined with an incomplete array type and
therefore it can only be instantiated with an array whose type is
incomplete.
Which is why I was getting error messages from the
instantiations? It may be an error in g++ (the fact that g++
does refuse to instantiate in simpler cases tends to confirm
this), but the template was definitly being instantiated.
Accept() may not be instantiated with any array whose type is
complete - because that array object has the wrong type to match the
declaration.
In which case, I'd call that a defect in the standard.
[..]
Unfortunately, the program still fails to compile because accept() uses its
own nontype template argument ("keys" which is an incomplete type) as a
function parameter in calls to the function templates begin() and end() -
both of which use the function parameter's type to deduce a complete array
type - a deduction which naturally fails when the parameter's type is
certain to be incomplete.
The problem is that accept uses its non-type template argument
in a context where a complete type is required, yes. There's no
problem instantiating accept. The problem involves whether
instantiating it with a complete type results in a complete
type.
Any attempt to pass a complete array type where an incomplete non-type
parameter is declared will not compile. And if you can produce such a
program that does compile successfully, then by all means post it.
Regretfully, I didn't safe to modification using sentinals which
did compile. Maybe I did do something different (e.g. declare a
pointer to the array, and not a reference), since I can't
reproduce the case. (I've since rewritten the actual code to
use the classical solution, based on inheritance rather than
templates.)
I'd also be curious if there was a clever work-around which
worked. A priori, the compiler has all of the knowledge which
it needs, but I can't figure out a way of making it use it.
The issues are exactly as I have described them: first, passing an array
with a complete type where an array with an incomplete type is required (but
fixing that problem leads to the opposite situation) passing an array with
an incomplete array type where an array with a complete type is needed.
The compiler has the information it needs at the point of
instantiation. The problem is how to tease them out of it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
---
[ 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 ]