Re: Potential eccp-3.9 bug
Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: This all seems to work when using the trait with a non-template type. If you want to use a template, it has to be instantiated first. I think I'm going to put the Edison compiler port on hold for now. Yeah, it doesn't seem quite stable enough. Let's see what they come back with, but unless there's something we're missing it might be best to wait for 3.10. I assume HP aCC 6 isn't any better? I got things working quite well on aCC 6.16. It doesn't support any of the built-ins, but I'm able to work around a lot of those issues. AFAICS, it's based on EDG eccp 3.8, so it's likely to have the same problems as those we discussed yesterday. A simple test case using __is_empty(int) compiles fine, but as expected the compiler spits out the same error for the __is_empty (S<0>) case as we saw eccp 3.9 do. Let me try to find out when HP plans to upgrade to the latest EDG front end. The one big issue is that I can't implement __rw_is_class<> accurately without __is_class(). Without this I get compile failures in the implementation of some traits that require an accurate implementation. This causes 20.meta.unary.prop.cpp to fail to compile. Now that we have eccp-3.10.1 I'll have another go at it. Thanks, Travis
RE: Potential eccp-3.9 bug
Martin Sebor wrote: > >Travis Vitek wrote: >> >> >> This all seems to work when using the trait with a >> non-template type. If you want to use a template, it >> has to be instantiated first. I think I'm going to >> put the Edison compiler port on hold for now. > >Yeah, it doesn't seem quite stable enough. Let's see what they >come back with, but unless there's something we're missing it >might be best to wait for 3.10. I assume HP aCC 6 isn't any >better? I got things working quite well on aCC 6.16. It doesn't support any of the built-ins, but I'm able to work around a lot of those issues. The one big issue is that I can't implement __rw_is_class<> accurately without __is_class(). Without this I get compile failures in the implementation of some traits that require an accurate implementation. This causes 20.meta.unary.prop.cpp to fail to compile. Now that we have eccp-3.10.1 I'll have another go at it. Thanks, Travis
Re: Potential eccp-3.9 bug
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Not always. If the template is instantiated the error would
not be seen.
The reason I ask is because I couldn't get even a simple SFINAE
test program to compile. I think the program is well-formed even
though gcc 4.3.0 chokes on too (albeit for a different reason --
see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797)
Hah, I was just filing a nearly identical bug with gcc when I got this
message.
I happened to be playing around with this a little bit earlier today.
You might find this interesting. If I use the pseudo-function
__is_empty() directly, the error message says there is no matching
function, but if I wrap it in a template, I get multiple matches (after
the incomplete class type message I complained about earlier).
This all seems to work when using the trait with a non-template type. If
you want to use a template, it has to be instantiated first. I think I'm
going to put the Edison compiler port on hold for now.
Yeah, it doesn't seem quite stable enough. Let's see what they
come back with, but unless there's something we're missing it
might be best to wait for 3.10. I assume HP aCC 6 isn't any
better?
$ cat t.cpp
template
struct enable_if {
typedef T type;
};
template
struct enable_if {
};
#ifdef _TEMPLATE
template
struct is_empty {
enum { val = __is_empty(T) };
};
template
int enabled_if_empty (typename enable_if< is_empty::val>::type* = 0)
{
return 1;
}
template
int enabled_if_empty (typename enable_if::val>::type* = 0)
{
return 0;
}
#else // !_TEMPLATE
template
int enabled_if_empty (typename enable_if< __is_empty(T)>::type* = 0) {
return 1;
}
template
int enabled_if_empty (typename enable_if::type* = 0) {
return 0;
}
#endif // !_TEMPLATE
template struct S { };
#include
//template struct S<1>;
int main () {
assert (0 == enabled_if_empty< S<1> >());
assert (1 == enabled_if_empty< long >());
return 0;
}
$ eccp -A t.cpp
"t.cpp", line 50: error: no instance of overloaded function
"enabled_if_empty"
matches the argument list
assert (0 == enabled_if_empty< S<1> >());
^
1 error detected in the compilation of "t.cpp".
$ eccp -A -D_TEMPLATE t.cpp
"t.cpp", line 15: error: an incomplete class type is not allowed
enum { val = __is_empty(T) };
^
detected during instantiation of class "is_empty [with
T=S<1>]"
at line 50
"t.cpp", line 50: error: more than one instance of overloaded function
"enabled_if_empty" matches the argument list:
function template "int
enabled_if_empty(enable_if::val,
void>::type *)"
function template "int
enabled_if_empty(enable_if<,
void>::type *)"
assert (0 == enabled_if_empty< S<1> >());
^
2 errors detected in the compilation of "t.cpp".
RE: Potential eccp-3.9 bug
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Not always. If the template is instantiated the error would
>> not be seen.
>
>The reason I ask is because I couldn't get even a simple SFINAE
>test program to compile. I think the program is well-formed even
>though gcc 4.3.0 chokes on too (albeit for a different reason --
>see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797)
>
Hah, I was just filing a nearly identical bug with gcc when I got this
message.
I happened to be playing around with this a little bit earlier today.
You might find this interesting. If I use the pseudo-function
__is_empty() directly, the error message says there is no matching
function, but if I wrap it in a template, I get multiple matches (after
the incomplete class type message I complained about earlier).
This all seems to work when using the trait with a non-template type. If
you want to use a template, it has to be instantiated first. I think I'm
going to put the Edison compiler port on hold for now.
$ cat t.cpp
template
struct enable_if {
typedef T type;
};
template
struct enable_if {
};
#ifdef _TEMPLATE
template
struct is_empty {
enum { val = __is_empty(T) };
};
template
int enabled_if_empty (typename enable_if< is_empty::val>::type* = 0)
{
return 1;
}
template
int enabled_if_empty (typename enable_if::val>::type* = 0)
{
return 0;
}
#else // !_TEMPLATE
template
int enabled_if_empty (typename enable_if< __is_empty(T)>::type* = 0) {
return 1;
}
template
int enabled_if_empty (typename enable_if::type* = 0) {
return 0;
}
#endif // !_TEMPLATE
template struct S { };
#include
//template struct S<1>;
int main () {
assert (0 == enabled_if_empty< S<1> >());
assert (1 == enabled_if_empty< long >());
return 0;
}
$ eccp -A t.cpp
"t.cpp", line 50: error: no instance of overloaded function
"enabled_if_empty"
matches the argument list
assert (0 == enabled_if_empty< S<1> >());
^
1 error detected in the compilation of "t.cpp".
$ eccp -A -D_TEMPLATE t.cpp
"t.cpp", line 15: error: an incomplete class type is not allowed
enum { val = __is_empty(T) };
^
detected during instantiation of class "is_empty [with
T=S<1>]"
at line 50
"t.cpp", line 50: error: more than one instance of overloaded function
"enabled_if_empty" matches the argument list:
function template "int
enabled_if_empty(enable_if::val,
void>::type *)"
function template "int
enabled_if_empty(enable_if<,
void>::type *)"
assert (0 == enabled_if_empty< S<1> >());
^
2 errors detected in the compilation of "t.cpp".
>
Re: Potential eccp-3.9 bug
Travis Vitek wrote:
[...]
The problem is that many of the trait tests do this type of
thing. I can work around this pretty easily by explicitly
instantating each template in each test, but this is tedious
(there are many).
I'm not sure I understand why you are even considering working
around it. Doesn't the bug make the built-in traits pretty much
unusable in generic code?
Not always. If the template is instantiated the error would not be seen.
The reason I ask is because I couldn't get even a simple SFINAE
test program to compile. I think the program is well-formed even
though gcc 4.3.0 chokes on too (albeit for a different reason --
see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797)
$ cat t.cpp && eccp -A t.cpp
#include
template struct S { };
template struct enable_if;
template struct enable_if { typedef T type; };
template
int foo (typename enable_if::type* = 0) { return 0; }
template
int foo (typename enable_if::type* = 0) { return 1; }
int main ()
{
assert (0 == foo >());
assert (1 == foo());
}
"t.cpp", line 16: error: no instance of overloaded function "foo"
matches the
argument list
assert (0 == foo >());
^
1 error detected in the compilation of "t.cpp".
Martin
I was thinking about doing something like this...
#define _INSTANTIATE(T) \
typedef typename\
__rw_conditional<__rw_is_class_or_union::value, \
T::type, \
void>::type _RWSTD_PASTE(dummy, __LINE__);
And then sneaking a void typedef into each of my user
defined types, and
then using this macro in the TEST () macro that I use all over the
tests. Is there a better way?
Travis
RE: Potential eccp-3.9 bug
Martin Sebor wrote:
>
>Travis Vitek wrote:
>> I'm porting the traits to the EDG compiler, and I'm running into
>> failures in the test suite. Here is a simple testcase to
>> illustrate...
>>
>> $ cat t.cpp && eccp t.cpp
>> template
>> struct S
>> {
>> };
>>
>> const bool a = __has_trivial_constructor( S<1> );
>> "t.cpp", line 6: error: an incomplete class type is not allowed
>> const bool a = __has_trivial_constructor( S<1> );
>> ^
>>
>> "t.cpp", line 6: warning: variable "a" was declared but never
>> referenced
>> const bool a = __has_trivial_constructor( S<1> );
>>^
>>
>> 1 error detected in the compilation of "t.cpp".
>>
>> The problem is that the template (S<1> in this case) has not
>> been instantiated, and the compiler chokes trying to use the
>> helper because the type is not 'complete'. It seems like that
>> is a bug and that referring to S<1> here should result in the
>> type being instantiated if the compiler requires it.
>
>I agree. I just sent EDG an email with your test case and CC'd
>you on it.
Thank you for reviewing and submitting.
>>
>> The problem is that many of the trait tests do this type of
>> thing. I can work around this pretty easily by explicitly
>> instantating each template in each test, but this is tedious
>> (there are many).
>
>I'm not sure I understand why you are even considering working
>around it. Doesn't the bug make the built-in traits pretty much
>unusable in generic code?
Not always. If the template is instantiated the error would not be seen.
>
>Martin
>
>>
>> I was thinking about doing something like this...
>>
>> #define _INSTANTIATE(T) \
>> typedef typename\
>> __rw_conditional<__rw_is_class_or_union::value, \
>>T::type, \
>>void>::type _RWSTD_PASTE(dummy, __LINE__);
>>
>> And then sneaking a void typedef into each of my user
>defined types, and
>> then using this macro in the TEST () macro that I use all over the
>> tests. Is there a better way?
>>
>> Travis
>
>
Re: Potential eccp-3.9 bug
Travis Vitek wrote:
I'm porting the traits to the EDG compiler, and I'm running into
failures in the test suite. Here is a simple testcase to illustrate...
$ cat t.cpp && eccp t.cpp
template
struct S
{
};
const bool a = __has_trivial_constructor( S<1> );
"t.cpp", line 6: error: an incomplete class type is not allowed
const bool a = __has_trivial_constructor( S<1> );
^
"t.cpp", line 6: warning: variable "a" was declared but never
referenced
const bool a = __has_trivial_constructor( S<1> );
^
1 error detected in the compilation of "t.cpp".
The problem is that the template (S<1> in this case) has not been
instantiated, and the compiler chokes trying to use the helper because
the type is not 'complete'. It seems like that is a bug and that
referring to S<1> here should result in the type being instantiated if
the compiler requires it.
I agree. I just sent EDG an email with your test case and CC'd
you on it.
The problem is that many of the trait tests do this type of thing. I can
work around this pretty easily by explicitly instantating each template
in each test, but this is tedious (there are many).
I'm not sure I understand why you are even considering working
around it. Doesn't the bug make the built-in traits pretty much
unusable in generic code?
Martin
I was thinking about doing something like this...
#define _INSTANTIATE(T) \
typedef typename\
__rw_conditional<__rw_is_class_or_union::value, \
T::type, \
void>::type _RWSTD_PASTE(dummy, __LINE__);
And then sneaking a void typedef into each of my user defined types, and
then using this macro in the TEST () macro that I use all over the
tests. Is there a better way?
Travis
RE: Potential eccp-3.9 bug
> -Original Message-
> From: Eric Lemings
> Sent: Thursday, July 10, 2008 1:01 PM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: Potential eccp-3.9 bug
>
>
>
> > -Original Message-
> > From: Travis Vitek [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, July 10, 2008 11:41 AM
> > To: dev@stdcxx.apache.org
> > Subject: Potential eccp-3.9 bug
> >
> >
> > I'm porting the traits to the EDG compiler, and I'm running into
> > failures in the test suite. Here is a simple testcase to
> illustrate...
> >
> > $ cat t.cpp && eccp t.cpp
> > template
> > struct S
> > {
> > };
>
> I don't get it: that's all there is to the test case?
>
> template struct S {};
Oh I see: there's another line in it:
const bool a = __has_trivial_constructor( S<1> );
>
> Brad.
>
RE: Potential eccp-3.9 bug
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 10, 2008 11:41 AM
> To: dev@stdcxx.apache.org
> Subject: Potential eccp-3.9 bug
>
>
> I'm porting the traits to the EDG compiler, and I'm running into
> failures in the test suite. Here is a simple testcase to illustrate...
>
> $ cat t.cpp && eccp t.cpp
> template
> struct S
> {
> };
I don't get it: that's all there is to the test case?
template struct S {};
Brad.
