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".
>
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=675809&view=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=675809&r1=675808&r2=675809&view=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:
[...]
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: 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: 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 >
[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
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
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.
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
{
};
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.
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_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: svn commit: r675315 - /stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp
Eric Lemings wrote: I double-checked on RH5 and HP-UX. Looks good to me. What error did you get? I got a compilation error while testing the _TYPENAME -> typename changes w/o debugging. As I said, when _RWSTD_NO_DEBUG_ITER is #defined (i.e., in an optimized build), both string::iterator and vector::iterator are ordinary pointers. Since the test instantiates the function template on RandomAccessIterator being one of these two iterators (i.e., T*), the declaration RandomAccessIterator::difference_type is ill formed (T*::difference_type doesn't make sense). To confirm what I was seeing I used iterator_traits to verify a possible fix. I wasn't planning on checking it in but I missed it in the giant diff. 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=675315&view=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=675315&r1=675314&r2=675315&view=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 RandomNumberGenerator 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=675315&view=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=675315&r1=675314&r2=675315&view=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 > > > RandomNumberGenerator 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
Eric Lemings wrote: 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. I accidentally committed a fix for the problem last night: http://tinyurl.com/597fug I tested it with gcc but I haven't checked nightly results yet, so if you could do that I'd appreciate it. Martin 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=675315&view=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=675315&r1=675314&r2=675315&view=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 RandomNumberGenerator 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 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=675315&view=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=675315&r1=675314&r2=675315&view=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 > > RandomNumberGenerator 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 > >
