RE: svn commit: r675315 - /stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp
I did debug and optimize builds on RH5, Sol10, and HP-UX 11.31 and they all built fine (unless I overlooked something). Will double-check. Brad. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, July 09, 2008 9:35 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r675315 - /stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp [EMAIL PROTECTED] wrote: Author: elemings Date: Wed Jul 9 12:16:56 2008 New Revision: 675315 URL: http://svn.apache.org/viewvc?rev=675315view=rev Log: 2008-07-09 Eric Lemings [EMAIL PROTECTED] STDCXX-550 * tests/utilities/20.operators.cpp (test_random_access_iterator): Oops. Should be `!defined' in #if directive. Modified: stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp Modified: stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/utili ties/20.operators.cpp?rev=675315r1=675314r2=675315view=diff == --- stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp (original) +++ stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp Wed Jul 9 12:16:56 2008 @@ -397,7 +397,7 @@ typedef RandomAccessIterator I; -#if defined _RWSTD_NO_DEBUG_ITER +#if !defined _RWSTD_NO_DEBUG_ITER RandomNumberGeneratortypename I::difference_type rndgen; This won't compile when RandomAccessIterator is a plain pointer, which both string::iterator and vector::iterator happen to be when _RWSTD_NO_DEBUG_ITER is #defined (i.e., with optimization). Martin
RE: svn commit: r675315 - /stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp
I double-checked on RH5 and HP-UX. Looks good to me. What error did you get? Brad. -Original Message- From: Eric Lemings [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2008 9:30 AM To: dev@stdcxx.apache.org Subject: RE: svn commit: r675315 - /stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp I did debug and optimize builds on RH5, Sol10, and HP-UX 11.31 and they all built fine (unless I overlooked something). Will double-check. Brad. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, July 09, 2008 9:35 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r675315 - /stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp [EMAIL PROTECTED] wrote: Author: elemings Date: Wed Jul 9 12:16:56 2008 New Revision: 675315 URL: http://svn.apache.org/viewvc?rev=675315view=rev Log: 2008-07-09 Eric Lemings [EMAIL PROTECTED] STDCXX-550 * tests/utilities/20.operators.cpp (test_random_access_iterator): Oops. Should be `!defined' in #if directive. Modified: stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp Modified: stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/utili ties/20.operators.cpp?rev=675315r1=675314r2=675315view=diff == --- stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp (original) +++ stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp Wed Jul 9 12:16:56 2008 @@ -397,7 +397,7 @@ typedef RandomAccessIterator I; -#if defined _RWSTD_NO_DEBUG_ITER +#if !defined _RWSTD_NO_DEBUG_ITER RandomNumberGeneratortypename I::difference_type rndgen; This won't compile when RandomAccessIterator is a plain pointer, which both string::iterator and vector::iterator happen to be when _RWSTD_NO_DEBUG_ITER is #defined (i.e., with optimization). Martin
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 int N
struct S
{
};
const bool a = __has_trivial_constructor( S1 );
t.cpp, line 6: error: an incomplete class type is not allowed
const bool a = __has_trivial_constructor( S1 );
^
t.cpp, line 6: warning: variable a was declared but never
referenced
const bool a = __has_trivial_constructor( S1 );
^
1 error detected in the compilation of t.cpp.
The problem is that the template (S1 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 S1 here should result in the type being instantiated if
the compiler requires 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 was thinking about doing something like this...
#define _INSTANTIATE(T) \
typedef typename\
__rw_conditional__rw_is_class_or_unionT::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 int N
struct S
{
};
I don't get it: that's all there is to the test case?
template int N struct S {};
Oh I see: there's another line in it:
const bool a = __has_trivial_constructor( S1 );
Brad.
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 int N
struct S
{
};
const bool a = __has_trivial_constructor( S1 );
t.cpp, line 6: error: an incomplete class type is not allowed
const bool a = __has_trivial_constructor( S1 );
^
t.cpp, line 6: warning: variable a was declared but never
referenced
const bool a = __has_trivial_constructor( S1 );
^
1 error detected in the compilation of t.cpp.
The problem is that the template (S1 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 S1 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_unionT::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
email delays?
Anyone else seeing major delays in list mail delivery? I sent a response to Travis' post Re: Potential eccp-3.9 bug at 3:36 MDT. It's now 3:53 and I still don't see it (I do see it in archives: http://markmail.org/message/35nmnhmbrlysknhv). I wonder if the problem is on our end at Rogue Wave? Martin
[Fwd: email delays?]
For the record, this just now showed up in my inbox. It's 4:23PM, a full 30 minutes after I sent it (as the timestamp indicates)... Original Message Subject: email delays? Date: Thu, 10 Jul 2008 15:53:16 -0600 From: Martin Sebor [EMAIL PROTECTED] Reply-To: dev@stdcxx.apache.org Organization: Rogue Wave Software, Inc. To: dev@stdcxx.apache.org Anyone else seeing major delays in list mail delivery? I sent a response to Travis' post Re: Potential eccp-3.9 bug at 3:36 MDT. It's now 3:53 and I still don't see it (I do see it in archives: http://markmail.org/message/35nmnhmbrlysknhv). I wonder if the problem is on our end at Rogue Wave? Martin
RE: email delays?
Martin Sebor wrote: Anyone else seeing major delays in list mail delivery? I sent a response to Travis' post Re: Potential eccp-3.9 bug at 3:36 MDT. It's now 3:53 and I still don't see it (I do see it in archives: http://markmail.org/message/35nmnhmbrlysknhv). I wonder if the problem is on our end at Rogue Wave? I dunno, but I noticed it a few days ago. I respondet to RE: svn commit: r675044... at 2:20pm on Wednesday. The message arrived in my inbox at 5:08pm and shows up in the archive at 9:19pm [http://tinyurl.com/65duhb]. Martin
Re: email delays?
Travis Vitek wrote: Martin Sebor wrote: Anyone else seeing major delays in list mail delivery? I sent a response to Travis' post Re: Potential eccp-3.9 bug at 3:36 MDT. It's now 3:53 and I still don't see it (I do see it in archives: http://markmail.org/message/35nmnhmbrlysknhv). I wonder if the problem is on our end at Rogue Wave? I dunno, but I noticed it a few days ago. I respondet to RE: svn commit: r675044... at 2:20pm on Wednesday. The message arrived in my inbox at 5:08pm and shows up in the archive at 9:19pm [http://tinyurl.com/65duhb]. Very odd. It seems to come and go, too. My forwarded post showed up pretty much right away. I also tested my @apache.org account by emailing my @roguewave.com account from people.apache.org at 3:55. The mail showed up in my @roguewave.com inbox at 3:57. I responded to it (i.e., to sebor @ apache.org) at the same time but I'm still waiting for the response to show up in my Inbox (my .forward file in my $HOME at people.apache.org has my @roguewave.com address). Martin
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 int N
struct S
{
};
const bool a = __has_trivial_constructor( S1 );
t.cpp, line 6: error: an incomplete class type is not allowed
const bool a = __has_trivial_constructor( S1 );
^
t.cpp, line 6: warning: variable a was declared but never
referenced
const bool a = __has_trivial_constructor( S1 );
^
1 error detected in the compilation of t.cpp.
The problem is that the template (S1 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 S1 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_unionT::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:
[...]
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 assert.h
template int struct S { };
template class, bool struct enable_if;
template class T struct enable_ifT, true { typedef T type; };
template class T
int foo (typename enable_ifT, __is_empty (T)::type* = 0) { return 0; }
template class T
int foo (typename enable_ifT, !__is_empty (T)::type* = 0) { return 1; }
int main ()
{
assert (0 == fooS0 ());
assert (1 == fooint());
}
t.cpp, line 16: error: no instance of overloaded function foo
matches the
argument list
assert (0 == fooS0 ());
^
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_unionT::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
using gcc -std=c++0x to enable C++ 0x ([Fwd: svn commit: r675809 - /stdcxx/branches/4.3.x/include/rw/_config-gcc.h])
This change makes it possible to enable stdcxx C++ 0x extensions
by using the -std=c++0x (or -std=gnu++0x) gcc command line option.
Specifically, it's possible to use these extensions with a library
configured w/o the option simply by setting CXXOPTS=-std=c++0x on
the make command line.
Original Message
Subject: svn commit: r675809 -
/stdcxx/branches/4.3.x/include/rw/_config-gcc.h
Date: Thu, 10 Jul 2008 23:35:45 -
From: [EMAIL PROTECTED]
Reply-To: dev@stdcxx.apache.org
To: [EMAIL PROTECTED]
Author: sebor
Date: Thu Jul 10 16:35:45 2008
New Revision: 675809
URL: http://svn.apache.org/viewvc?rev=675809view=rev
Log:
2008-07-10 Martin Sebor [EMAIL PROTECTED]
* include/rw/_config-gcc.h [gcc = 4.3 __GXX_EXPERIMENTAL_CXX0X__]
(_RWSTD_NO_VARIADIC_TEMPLATES, _RWSTD_NO_RVALUE_REFERENCES): Undefined
to make it possible to use C++ 0x library extensions even in builds
configured w/o C++ 0x extensions enabled in the compiler.
(_RWSTD_EXT_CXX_0X): #defined in response to either of the -std=c++0x
or -std=gnu++0x options.
Modified:
stdcxx/branches/4.3.x/include/rw/_config-gcc.h
Modified: stdcxx/branches/4.3.x/include/rw/_config-gcc.h
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/include/rw/_config-gcc.h?rev=675809r1=675808r2=675809view=diff
==
--- stdcxx/branches/4.3.x/include/rw/_config-gcc.h (original)
+++ stdcxx/branches/4.3.x/include/rw/_config-gcc.h Thu Jul 10 16:35:45 2008
@@ -200,5 +200,20 @@
# define _RWSTD_TT_MAX_ALIGNMENT 16
# define _RWSTD_TT_ALIGNED_POD(N) \
struct { unsigned char _C_align __attribute__ ((aligned ((N; }
+
+# ifdef __GXX_EXPERIMENTAL_CXX0X__
+ // enable C++ 0x features disabled in builds
+ // configured without -std=c++0x or -std=gnu++0x
+
+ // C++ 0x features supported since 4.3.0
+#undef _RWSTD_NO_VARIADIC_TEMPLATES
+#undef _RWSTD_NO_RVALUE_REFERENCES
+
+#ifndef _RWSTD_EXT_CXX_0X
+ // enable our C++ 0x extensions in GNU gcc C++ 0x mode
+# define _RWSTD_EXT_CXX_0X
+#endif
+# endif
+
#endif // __GNUC__ = 4.3
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 bool B, class T = void
struct enable_if {
typedef T type;
};
template class T
struct enable_iffalse, T {
};
#ifdef _TEMPLATE
template class T
struct is_empty {
enum { val = __is_empty(T) };
};
template class T
int enabled_if_empty (typename enable_if is_emptyT::val::type* = 0)
{
return 1;
}
template class T
int enabled_if_empty (typename enable_if!is_emptyT::val::type* = 0)
{
return 0;
}
#else // !_TEMPLATE
template class T
int enabled_if_empty (typename enable_if __is_empty(T)::type* = 0) {
return 1;
}
template class T
int enabled_if_empty (typename enable_if!__is_empty(T)::type* = 0) {
return 0;
}
#endif // !_TEMPLATE
template int struct S { };
#include assert.h
//template struct S1;
int main () {
assert (0 == enabled_if_empty S1 ());
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 S1 ());
^
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_emptyT [with
T=S1]
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_emptyT(enable_ifis_emptyT::val,
void::type *)
function template int
enabled_if_emptyT(enable_ifexpression,
void::type *)
assert (0 == enabled_if_empty S1 ());
^
2 errors detected in the compilation of t.cpp.
