RE: STDCXX-600
> -Original Message- > From: Eric Lemings > Sent: Thursday, July 24, 2008 11:10 AM > To: Eric Lemings; 'dev@stdcxx.apache.org' > Subject: RE: STDCXX-600 > > > ... > > Should I just check in this change for this particular > exception for now? I suspect all other standard exceptions > would also need to be changed. Doh. Scratch that. I was using the working test case. The original test case still fails. Brad.
RE: STDCXX-600
> -Original Message-
> From: Eric Lemings
> Sent: Thursday, July 24, 2008 10:57 AM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: STDCXX-600
>
>
...
> > >> Have you tried changing this to something like:
> > >>
> > >> _STD::out_of_range ex;
> > >> ex._C_assign (what, 0);
> > >> throw ex;
> > >
> > > I did but I got some sort of weird compile error: invalid
> > goto label or
> > > something like that.
> >
> > That's most likely because you forgot to establish a scope
> > for the block of code containing the declaration of x (it's
> > illegal to jump past a declaration).
>
> I tried that too. :)
Well I could have sworn I tried that. The following change works:
Index: src/exception.cpp
===
--- src/exception.cpp (revision 679465)
+++ src/exception.cpp (working copy)
@@ -691,7 +691,11 @@
throw (_STD::length_error&)_STD::length_error ()._C_assign
(what, 0);
case _RWSTD_ERROR_OUT_OF_RANGE:
-throw (_STD::out_of_range&)_STD::out_of_range ()._C_assign
(what, 0);
+{
+_STD::out_of_range exc;
+exc._C_assign (what, 0);
+throw exc;
+}
case _RWSTD_ERROR_RUNTIME_ERROR:
throw (_STD::runtime_error&)
Should I just check in this change for this particular exception for
now? I suspect all other standard exceptions would also need to be
changed.
Brad.
RE: STDCXX-600
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 24, 2008 9:55 AM
> To: dev@stdcxx.apache.org
> Subject: Re: STDCXX-600
>
> Eric Lemings wrote:
> >
> >
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> >> Sent: Wednesday, July 23, 2008 5:47 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: Re: STDCXX-600
> >>
> >> Eric Lemings wrote:
> >>>
> >>> FYI-type stuff.
> >>>
> >>> I've been at this issue for the past couple hours.
> Here's what I've
> >>> found so far.
> >>>
> >>> My basic test case looks like this:
> >>>
> >>> #include
> >>> #include
> >>>
> >>> int main () {
> >>> try {
> >>> // throw statement (see below)
> >>> } catch (std::exception&) {
> >>> } catch (...) {
> >>> }
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> The following "throw statements" all throw exceptions that are not
> >>> getting caught by the compiler's runtime libraries:
> >>>
> >>> a._RW::__rw_throw (_RWSTD_ERROR_OUT_OF_RANGE, _RWSTD_FUNC
> >>> ("main()"), 1, 0);
> >>> b._RW::__rw_throw_proc (_RWSTD_ERROR_OUT_OF_RANGE, "what");
> >>>
> >>> No clue yet why they are not caught.
> >>>
> >>> The following "throw statement" however is caught properly:
> >>>
> >>> c.char* what = "what"; throw
> >> (_STD::out_of_rang&)_STD::out_of_range
> >>> ()._C_assign (what, 0);
> >> Have you tried changing this to something like:
> >>
> >> _STD::out_of_range ex;
> >> ex._C_assign (what, 0);
> >> throw ex;
> >
> > I did but I got some sort of weird compile error: invalid
> goto label or
> > something like that.
>
> That's most likely because you forgot to establish a scope
> for the block of code containing the declaration of x (it's
> illegal to jump past a declaration).
I tried that too. :)
Brad.
RE: STDCXX-600
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 23, 2008 5:47 PM
> To: dev@stdcxx.apache.org
> Subject: Re: STDCXX-600
>
> Eric Lemings wrote:
> >
> > FYI-type stuff.
> >
> > I've been at this issue for the past couple hours. Here's what I've
> > found so far.
> >
> > My basic test case looks like this:
> >
> > #include
> > #include
> >
> > int main () {
> > try {
> > // throw statement (see below)
> > } catch (std::exception&) {
> > } catch (...) {
> > }
> >
> > return 0;
> > }
> >
> > The following "throw statements" all throw exceptions that are not
> > getting caught by the compiler's runtime libraries:
> >
> > a. _RW::__rw_throw (_RWSTD_ERROR_OUT_OF_RANGE, _RWSTD_FUNC
> > ("main()"), 1, 0);
> > b._RW::__rw_throw_proc (_RWSTD_ERROR_OUT_OF_RANGE, "what");
> >
> > No clue yet why they are not caught.
> >
> > The following "throw statement" however is caught properly:
> >
> > c.char* what = "what"; throw
> (_STD::out_of_rang&)_STD::out_of_range
> > ()._C_assign (what, 0);
>
> Have you tried changing this to something like:
>
> _STD::out_of_range ex;
> ex._C_assign (what, 0);
> throw ex;
I did but I got some sort of weird compile error: invalid goto label or
something like that.
Brad.
RE: STDCXX-600
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 23, 2008 4:10 PM
> To: dev@stdcxx.apache.org
> Subject: STDCXX-600
>
>
...
>
> The following "throw statements" all throw exceptions that are not
> getting caught by the compiler's runtime libraries:
>
> a._RW::__rw_throw (_RWSTD_ERROR_OUT_OF_RANGE, _RWSTD_FUNC
> ("main()"), 1, 0);
> b._RW::__rw_throw_proc (_RWSTD_ERROR_OUT_OF_RANGE, "what");
>
> No clue yet why they are not caught.
>
> The following "throw statement" however is caught properly:
>
> c.char* what = "what"; throw
> (_STD::out_of_rang&)_STD::out_of_range
> ()._C_assign (what, 0);
>
> Both of the first throw statements ultimately call the last throw
> statement so my current guess is that the problem has something to do
> with the internal what buffer.
Actually, the second/"b" case above doesn't even use the internal what
buffer. So it's not that.
So I'm thinking it may be a compiler bug: throwing an exception from
different namespaces; i.e. in this case, throwing a `std' exception from
a `__rw' function. I built and ran the test case with a more recent
version of gcc (4.3) and it works fine.
Brad.
STDCXX-600
FYI-type stuff.
I've been at this issue for the past couple hours. Here's what I've
found so far.
My basic test case looks like this:
#include
#include
int main () {
try {
// throw statement (see below)
} catch (std::exception&) {
} catch (...) {
}
return 0;
}
The following "throw statements" all throw exceptions that are not
getting caught by the compiler's runtime libraries:
a. _RW::__rw_throw (_RWSTD_ERROR_OUT_OF_RANGE, _RWSTD_FUNC
("main()"), 1, 0);
b._RW::__rw_throw_proc (_RWSTD_ERROR_OUT_OF_RANGE, "what");
No clue yet why they are not caught.
The following "throw statement" however is caught properly:
c.char* what = "what"; throw (_STD::out_of_rang&)_STD::out_of_range
()._C_assign (what, 0);
Both of the first throw statements ultimately call the last throw
statement so my current guess is that the problem has something to do
with the internal what buffer.
Brad.
RE: [jira] Commented: (STDCXX-974) [EDG eccp/Linux] errors with optimization on long long in
> -Original Message- > From: Andrew Black [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2008 9:53 AM > To: dev@stdcxx.apache.org > Subject: Re: [jira] Commented: (STDCXX-974) [EDG eccp/Linux] > errors with optimization on long long in > > Eric Lemings wrote: > [snip] > >> Brad, they're all in //rwtest/..., the same place they were > >> the last time you had to make changes to the test driver. :) > >> > >>> [EDG eccp/Linux] errors with optimization on long long in > >> > > ... > > > > Well that explains it. What are files from SourcePro's RWTest doing > > STDCXX builds? Is it supposed to pull RWTest files from 3 different > > repositories, 1 in Subversion and 2 in Perforce? If so, can't we > > simplify this somehow? Sheesh... > > The RWTest files from //rwtest/... are there because the legacy test > suite (from //stdcxx/trunk/tests/...) depend on them. Once porting of > the test suite is complete, the dependencies on perforce will go away. Right. And the legacy tests are in the //stdcxx/trunk/tests reposititory. Is there any reason why the files could not reside in the //stdcxx/trunk/tests/src directory (where one would expect to find them)? :) As it is, if I were to update those files that would affect SourcePro, wouldn't it? Brad.
RE: svn commit: r678913 - in /stdcxx/branches/4.3.x: ./ etc/config/src/ examples/include/ include/ include/loc/ include/rw/ src/ tests/containers/ tests/localization/ tests/strings/ tests/utilities/
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, July 22, 2008 4:31 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r678913 - in /stdcxx/branches/4.3.x: > ./ etc/config/src/ examples/include/ include/ include/loc/ > include/rw/ src/ tests/containers/ tests/localization/ > tests/strings/ tests/utilities/ > ... > == > > > --- stdcxx/branches/4.3.x/include/deque.cc (original) > > +++ stdcxx/branches/4.3.x/include/deque.cc Tue Jul 22 14:24:01 2008 > > @@ -518,8 +518,6 @@ > > } > > > > > > -#ifndef _RWSTD_NO_MEMBER_TEMPLATES > > - > > template > > template > > void deque<_TypeT, _Allocator>:: > > @@ -529,18 +527,6 @@ > > > > deque* const __self = this; > > And here we should be able to do away with the __self hack. This > hack, btw., is probably used in other containers (string comes > to mind, although it doesn't look to me like your patch removes > this cruft from string), so we should review and clean those up > as well. Otherwise these strange looking vestiges will leave > people wondering what the heck we're doing. Since this change is not related to STDCXX-978 and involves other containers not affected by this issue, we should create a new issue and do this cleanup as part of that issue, yes? > ... > > + > > static void swap(reference __x, reference __y); > > + > > void flip (); > > + > > void clear() > > These are good changes but in the future please resist the urge > to improve formatting in the same patch as where you're making > substantive changes. I agree in principle but for very small changes like this I probably wouldn't bother going to the trouble of doing this separately. :) I'm incorporating all other recommendations. Thanks, Brad.
RE: [jira] Commented: (STDCXX-974) [EDG eccp/Linux] errors with optimization on long long in
> -Original Message- > From: Travis Vitek (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 22, 2008 4:32 PM > To: Eric Lemings > Subject: [jira] Commented: (STDCXX-974) [EDG eccp/Linux] > errors with optimization on long long in > > > [ > https://issues.apache.org/jira/browse/STDCXX-974?page=com.atla > ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focus > edCommentId=12615814#action_12615814 ] > > Travis Vitek commented on STDCXX-974: > - > > Brad, they're all in //rwtest/..., the same place they were > the last time you had to make changes to the test driver. :) > > > [EDG eccp/Linux] errors with optimization on long long in > ... Well that explains it. What are files from SourcePro's RWTest doing STDCXX builds? Is it supposed to pull RWTest files from 3 different repositories, 1 in Subversion and 2 in Perforce? If so, can't we simplify this somehow? Sheesh... Brad.
RE: Problem building with EDG eccp 3.10
> -Original Message-
> From: Eric Lemings
> Sent: Tuesday, July 22, 2008 11:41 AM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: Problem building with EDG eccp 3.10
>
>
> Ah, I found an issue for it:
> https://issues.apache.org/jira/browse/STDCXX-800
Shouldn't the priority for this issue be raised to Major?
>
> > -Original Message-
> > From: Eric Lemings [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 22, 2008 11:33 AM
> > To: dev@stdcxx.apache.org
> > Subject: Problem building with EDG eccp 3.10
> >
> >
> > I'm trying to do a build on Linux with EDG eccp 3.10. I
> keep getting
> > the following errors during configuration.
> >
> > creating BUILDDIR=/build/stdcxx-4.2.x-12D-eccp
> > generating /build/stdcxx-4.2.x-12D-eccp/makefile.in from
> > /source/stdcxx/branches/4.2.x/etc/config/eccp.config
> > make[1]: Entering directory `/build/stdcxx-4.2.x-12D-eccp'
> > make[2]: Entering directory `/build/stdcxx-4.2.x-12D-eccp/include'
> > make config
> > make[3]: Entering directory `/build/stdcxx-4.2.x-12D-eccp/include'
> >
> > configuring stdcxx 4.2.2 for eccp-3.10.1 on
> > linux-2.6.18-8.el5xen-x86_64
> >
> > checking if the compiler is sane ok (invoked with
> > eccp)
> > checking if the linker is sane no
> >
> > int main () { return 0; }
> > eccp -D_RWSTD_SHARED_LIB -D_REENTRANT -I. -A -x
> > --template_directory=/build/stdcxx-4.2.x-12D-eccp/lib -O
> > --display_error_number --remarks --diag_suppress
> > 193,236,340,401,261,479,487,678,679,815 -c a.cpp -o a.o
> > eccp a.o
> --template_directory=/build/stdcxx-4.2.x-12D-eccp/lib -shared
> > /usr/lib/libpthread.so -lm -o a.out
> > eccp: unknown option: -shared
> >
> > What gives?
> >
> > Brad.
> >
RE: Problem building with EDG eccp 3.10
Ah, I found an issue for it:
https://issues.apache.org/jira/browse/STDCXX-800
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 22, 2008 11:33 AM
> To: dev@stdcxx.apache.org
> Subject: Problem building with EDG eccp 3.10
>
>
> I'm trying to do a build on Linux with EDG eccp 3.10. I keep getting
> the following errors during configuration.
>
> creating BUILDDIR=/build/stdcxx-4.2.x-12D-eccp
> generating /build/stdcxx-4.2.x-12D-eccp/makefile.in from
> /source/stdcxx/branches/4.2.x/etc/config/eccp.config
> make[1]: Entering directory `/build/stdcxx-4.2.x-12D-eccp'
> make[2]: Entering directory `/build/stdcxx-4.2.x-12D-eccp/include'
> make config
> make[3]: Entering directory `/build/stdcxx-4.2.x-12D-eccp/include'
>
> configuring stdcxx 4.2.2 for eccp-3.10.1 on
> linux-2.6.18-8.el5xen-x86_64
>
> checking if the compiler is sane ok (invoked with
> eccp)
> checking if the linker is sane no
>
> int main () { return 0; }
> eccp -D_RWSTD_SHARED_LIB -D_REENTRANT -I. -A -x
> --template_directory=/build/stdcxx-4.2.x-12D-eccp/lib -O
> --display_error_number --remarks --diag_suppress
> 193,236,340,401,261,479,487,678,679,815 -c a.cpp -o a.o
> eccp a.o --template_directory=/build/stdcxx-4.2.x-12D-eccp/lib -shared
> /usr/lib/libpthread.so -lm -o a.out
> eccp: unknown option: -shared
>
> What gives?
>
> Brad.
>
Problem building with EDG eccp 3.10
I'm trying to do a build on Linux with EDG eccp 3.10. I keep getting
the following errors during configuration.
creating BUILDDIR=/build/stdcxx-4.2.x-12D-eccp
generating /build/stdcxx-4.2.x-12D-eccp/makefile.in from
/source/stdcxx/branches/4.2.x/etc/config/eccp.config
make[1]: Entering directory `/build/stdcxx-4.2.x-12D-eccp'
make[2]: Entering directory `/build/stdcxx-4.2.x-12D-eccp/include'
make config
make[3]: Entering directory `/build/stdcxx-4.2.x-12D-eccp/include'
configuring stdcxx 4.2.2 for eccp-3.10.1 on linux-2.6.18-8.el5xen-x86_64
checking if the compiler is sane ok (invoked with
eccp)
checking if the linker is sane no
int main () { return 0; }
eccp -D_RWSTD_SHARED_LIB -D_REENTRANT -I. -A -x
--template_directory=/build/stdcxx-4.2.x-12D-eccp/lib -O
--display_error_number --remarks --diag_suppress
193,236,340,401,261,479,487,678,679,815 -c a.cpp -o a.o
eccp a.o --template_directory=/build/stdcxx-4.2.x-12D-eccp/lib -shared
/usr/lib/libpthread.so -lm -o a.out
eccp: unknown option: -shared
What gives?
Brad.
RE: problem in installing apache standard library on HPUX 11.23PA
Greetings, Is this still a problem for you? If so, could you provide instructions on how to reproduce it? Thanks, Eric. > -Original Message- > From: pendiala jaipal [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 11:32 PM > To: dev@stdcxx.apache.org > Subject: problem in installing apache standard library on > HPUX 11.23PA > > Hi all, > > When i install Apache standard library to > /opt/iexpress/stdcxx location it is giving problem. > > gmake install PREFIX=/opt/iexpress/stdcxx > > -- > - > mkdir -p /opt/iexpress/stdcxx > gmake -Clib install > gmake[1]: Entering directory > `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/lib' > mkdir -p /opt/iexpress/stdcxx/lib > cp libstd.sl.4.2.1 /opt/iexpress/stdcxx/lib > if [ libstd.sl != libstd.sl.4.2.1 ]; then \ > rm /opt/iexpress/stdcxx/lib/libstd.sl; \ > ln -s libstd.sl.4.2.1 > /opt/iexpress/stdcxx/lib/libstd.sl; \ > fi > mkdir -p /opt/iexpress/stdcxx/etc > cp rwstderr.cat /opt/iexpress/stdcxx/etc > gmake[1]: Leaving directory > `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/lib' > gmake -Cbin install > gmake[1]: Entering directory > `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/bin' > ./localedef -w -c -f > /home/jaipal/Stdcxx/stdcxx-4.2.1/etc/nls/charmaps/GB18030 -i > /home/jaipal/Stdcxx/stdcxx-4.2.1/etc/nls/src/zh_CN > /home/jaipal/Stdcxx/stdcxx-4.2.1/build/nls/zh_CN.GB18030 > /bin/sh: 948 Memory fault(coredump) > gmake[1]: *** [zh_CN.GB18030] Error 139 > gmake[1]: Leaving directory > `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/bin' > gmake: *** [install] Error 2 > -- > > > Can you help me regarding this issue > > Thanks in Advance, > Jaipal P. > > > > >
RE: STDCXX-978
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, July 21, 2008 2:25 PM > To: dev@stdcxx.apache.org > Subject: Re: STDCXX-978 > ... > It probably wouldn't hurt, although I suspect the raw patch might > be too big for ezmlm (AFAIK, the limit is 100K). If it is, I think > you might just as well commit it (assuming it's tested with at > least a couple of compilers). I'm building and running tests for 12D and 15D builds on Linux/gcc 4.3, Solaris, and HP-UX IPF right now. I think the changes are pretty much straightforward but someone should take a look with a close eye to make sure. There are after all lots of changes to public headers. > > Btw., I assume you're also removing the MEMBER_TEMPLATES.cpp test, > right? Uhh thanks for the reminder... :D Brad.
STDCXX-978
Heads up. Substantiative change in the works. Affects the following files in the 4.3.x branch. M 677618 include/rw/_autoptr.h M 677618 include/rw/_defs.h M 677618 include/rw/_config-sunpro.h M 677618 include/rw/_iterator.h M 677618 include/rw/_iterbase.h M 677618 include/deque M 677618 include/loc/_locale.h M 677618 include/set M 677618 include/list.cc M 677618 include/complex M 677618 include/list M 678525 include/bitset M 677618 include/string M 677618 include/string.cc M 677618 include/vector M 677618 include/vector.cc M 677618 include/deque.cc M 677618 tests/utilities/20.auto.ptr.cpp M 677618 tests/containers/23.bitset.cpp M 677618 tests/localization/22.locale.synopsis.cpp M 677618 tests/strings/21.string.exceptions.cpp M 677618 src/vecbool.cpp M 677618 etc/config/src/implicit_inclusion_imp.h M 677618 etc/config/src/IMPLICIT_INCLUSION.cpp M 677618 etc/config/src/extern_template_imp.h M 677618 etc/config/src/EXTERN_MEMBER_TEMPLATE.cpp M 677618 etc/config/src/extern_template_imp.cpp M 677618 etc/config/src/implicit_inclusion_imp.cc M 677618 README M 677618 examples/include/stocks.h Should I post the diffs for review before committing them? Brad.
RE: svn commit: r678483 - /stdcxx/branches/4.2.x/tests/regress/27.streambuf.buffer.stdcxx-808.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, July 21, 2008 12:54 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r678483 - > /stdcxx/branches/4.2.x/tests/regress/27.streambuf.buffer.stdcx > x-808.cpp > > Eric Lemings wrote: > > > > > >> -Original Message- > >> From: Travis Vitek [mailto:[EMAIL PROTECTED] > >> Sent: Monday, July 21, 2008 11:11 AM > >> To: dev@stdcxx.apache.org > >> Subject: RE: svn commit: r678483 - > >> /stdcxx/branches/4.2.x/tests/regress/27.streambuf.buffer.stdcx > >> x-808.cpp > >> > >> > >> > >> > >>> Author: elemings > >>> Date: Mon Jul 21 09:59:24 2008 > >>> New Revision: 678483 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=678483&view=rev > >>> Log: > >>> 2008-07-21 Eric Lemings <[EMAIL PROTECTED]> > >> Nit picking... :) There is supposed to be two spaces between your > >> username and e-mail address. > > > > Actually I prefer only one space to stress that the name and address > > are one component as treated by most email clients. > > The GNU Coding Standards that we follow for ChangeLog format show > two spaces: > http://www.gnu.org/prep/standards/html_node/Style-of-Change-Lo > gs.html#Style-of-Change-Logs It shows two spaces but it doesn't specify two spaces. There is a difference. Either way, it's really inconsequential so I'll update it. Brad.
RE: svn commit: r678483 - /stdcxx/branches/4.2.x/tests/regress/27.streambuf.buffer.stdcxx-808.cpp
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2008 11:11 AM > To: dev@stdcxx.apache.org > Subject: RE: svn commit: r678483 - > /stdcxx/branches/4.2.x/tests/regress/27.streambuf.buffer.stdcx > x-808.cpp > > ... > > It seems that you're missing the comment that describes what > revision(s) > you are merging. You might have a look at the following change for > reference. > > http://svn.apache.org/viewvc?view=rev&revision=676093 > I was going to add that and then, second-guessing myself, removed it. Guess my gut instinct was right the first time. :P Brad.
RE: svn commit: r678483 - /stdcxx/branches/4.2.x/tests/regress/27.streambuf.buffer.stdcxx-808.cpp
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2008 11:11 AM > To: dev@stdcxx.apache.org > Subject: RE: svn commit: r678483 - > /stdcxx/branches/4.2.x/tests/regress/27.streambuf.buffer.stdcx > x-808.cpp > > > > > >Author: elemings > >Date: Mon Jul 21 09:59:24 2008 > >New Revision: 678483 > > > >URL: http://svn.apache.org/viewvc?rev=678483&view=rev > >Log: > >2008-07-21 Eric Lemings <[EMAIL PROTECTED]> > > Nit picking... :) There is supposed to be two spaces between your > username and e-mail address. Actually I prefer only one space to stress that the name and address are one component as treated by most email clients. Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 17, 2008 9:54 AM > To: dev@stdcxx.apache.org > Subject: Re: structure of tuple tests ([Fwd: Re: svn commit: > r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h > include/tuple tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers > ... > > As I mentioned, it's just a prototype. I'm quite certain > it can (and should) be improved upon. That said, I don't > know of a generic way to concatenate strings at compile > time. If you can figure out how, more power to you! It's possible, but on second thought, it would probably require more preprocessor magic than its worth to expand the individual string literal components of a tuple name (or type list) which get concatenated by the compiler. Example: "std::tuple<" "int" ", " "UserDefined" ">" Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message-
> From: Eric Lemings
> Sent: Thursday, July 17, 2008 9:24 AM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: structure of tuple tests ([Fwd: Re: svn commit:
> r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/tuple tests/utilities/20.tuple.cnstr.cpp
> tests/utilities/20.tuple.creation.cpp
> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
>
>
>
> > -Original Message-
> > From: Eric Lemings
> > Sent: Thursday, July 17, 2008 8:47 AM
> > To: 'dev@stdcxx.apache.org'
> > Subject: RE: structure of tuple tests ([Fwd: Re: svn commit:
> > r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h
> > include/tuple tests/utilities/20.tuple.cnstr.cpp
> > tests/utilities/20.tuple.creation.cpp
> > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
> >
> >
> ...
> > > In 20.tuple.cnstr.cpp you might also be able to get rid of
> > > by using rw_strncmp(). You should also be able
> > > to use rw_equal() instead of defining a special helper (if
> > > rw_equal() doesn't do something we need to do in the tuple
> > > tests maybe we could extend it?)
> >
> > Was not aware of those. I'll try to reuse them.
>
> I believe this is a safe enhancement to rw_equal() but I just
> wanna make sure:
>
> template
> inline int rw_equal (T x, U y)
> {
> return x == y;
> }
>
> This would allow comparison of different but compatible types
> which is needed for heterogenous tuple types. Anyone see a
> problem with it?
One problem with rw_equal(), as it relates to tuple tests, is that the
arguments are copied. This poses a problem for user-defined types (esp.
UserDefined) which keeps track of and more importantly tests such
things.
I don't think it would be possible to change rw_equal() as follows:
template
inline bool rw_equal (const T& x, const U& y)
{
return x == y;
}
Or would it?
Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message-
> From: Eric Lemings
> Sent: Thursday, July 17, 2008 8:47 AM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: structure of tuple tests ([Fwd: Re: svn commit:
> r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/tuple tests/utilities/20.tuple.cnstr.cpp
> tests/utilities/20.tuple.creation.cpp
> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
>
>
...
> > In 20.tuple.cnstr.cpp you might also be able to get rid of
> > by using rw_strncmp(). You should also be able
> > to use rw_equal() instead of defining a special helper (if
> > rw_equal() doesn't do something we need to do in the tuple
> > tests maybe we could extend it?)
>
> Was not aware of those. I'll try to reuse them.
I believe this is a safe enhancement to rw_equal() but I just wanna make
sure:
template
inline int rw_equal (T x, U y)
{
return x == y;
}
This would allow comparison of different but compatible types which is
needed for heterogenous tuple types. Anyone see a problem with it?
Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 16, 2008 11:15 PM
> To: dev@stdcxx.apache.org
> Subject: Re: structure of tuple tests ([Fwd: Re: svn commit:
> r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/tuple tests/utilities/20.tuple.cnstr.cpp
> tests/utilities/20.tuple.creation.cpp
> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
>
...
> template
> struct Name {
> static void append (char *buf) {
> std::strcat (buf, type_name());
> std::strcat (buf, ", ");
>
> Name::append (buf);
Won't this result in an extra trailing ", "? If there are no more
Types..., the last append is skipped.
Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 16, 2008 11:15 PM
> To: dev@stdcxx.apache.org
> Subject: Re: structure of tuple tests ([Fwd: Re: svn commit:
> r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/tuple tests/utilities/20.tuple.cnstr.cpp
> tests/utilities/20.tuple.creation.cpp
> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
>
> Btw., here's a prototype of a utility for pretty printing of
> tuple types. It might come in handy as a generic implementation
> of type_name() for tuples, as a replacement for the handful of
> hardwired tuple types we have there.
>
>
> #include
> #include
>
> template const char* type_name () { return "???"; }
Should be left undefined so that you get a compile error and can
add the unreferenced type_name() specialization as appropriate.
Also, I'd prefer a compile-time facility for converting types to
strings. There's really no need for using a function, is there?
> template <> const char* type_name() { return "char"; }
> template <> const char* type_name() { return "short"; }
> template <> const char* type_name() { return "int"; }
> // ...
>
> template
> struct Name;
>
> template
> struct Name {
> static void append (char* buf) {
> std::strcat (buf, type_name());
> }
> };
>
> template <>
> struct Name<> {
> static void append (char*) { }
> };
>
> template
> struct Name {
> static void append (char *buf) {
> std::strcat (buf, type_name());
> std::strcat (buf, ", ");
>
> Name::append (buf);
> }
> };
>
> template
> char* name (std::tuple*)
> {
> static char buf [256];
>
> std::strcpy (buf, "tuple<");
>
> Name::append (buf);
>
> std::strcat (buf, ">");
>
> return buf;
> }
I started writing a compile-time version of this but it started to take
too long to write. Now that I have some extra time though... :)
Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, July 16, 2008 11:11 PM > To: dev@stdcxx.apache.org > Subject: Re: structure of tuple tests ([Fwd: Re: svn commit: > r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h > include/tuple tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers > > Eric Lemings wrote: > > > > > >> -Original Message- > >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of > Martin Sebor > >> Sent: Friday, July 11, 2008 1:06 PM > >> To: dev@stdcxx.apache.org > >> Subject: Re: structure of tuple tests ([Fwd: Re: svn commit: > >> r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h > >> include/tuple tests/utilities/20.tuple.cnstr.cpp > >> tests/utilities/20.tuple.creation.cpp > >> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers > >> > > ... > >> You might want to consider extending the UserClass class defined > >> in tests/include/rw_value.h, or at least borrowing code or ideas > >> from it. > > > > I generalized the overall test pattern for tuples with the latest > > revision 677458. It might not be exactly what you're after but I > > think it's much closer than the previous version. For instance, I > > lot of the tests could be wrapped in TEST() function macros. > > > > Have a look if you find time. > > Okay, I looked :) Just briefly, but I do have a few high-level > comments and suggestions for you. > > First, let's avoid using one library component to test another. > Especially avoid using ostream except in tests exercising I/O > (those should be separate from all others). We shouldn't be > #including or in 20.tuple.h. It's not currently used. I can remove it. > Also avoid > using std::rand() and, ideally, any randomization at all. It > makes it hard to reliably reproduce the same test results. Not in this case. > For , if all tuple needs is decay, it would be > nice if we could come up with a way to do without it. Yeah I could add FMT_SPEC() for each combination of cv-qualifier and reference types for all types already specified. I'd rather not though and just rely on decay since that's what its meant to do. > In 20.tuple.cnstr.cpp you might also be able to get rid of > by using rw_strncmp(). You should also be able > to use rw_equal() instead of defining a special helper (if > rw_equal() doesn't do something we need to do in the tuple > tests maybe we could extend it?) Was not aware of those. I'll try to reuse them. > Another point: most people expect headers to be #included at > the top of a file. It's surprising to see them included in > the middle, and it can have unexpected effects in template > code. Please move all #include directives to the top of the > 20.tuple.cnstr.cpp test. It's not used either. I can just remove it. > Third, I would rather strongly recommend removing the global > tuple typedefs from the common header and defining them in > each test function as necessary. AFAICS, they don't save us > anything (they're all onle-liners), and it's far from clear > from their names what each of them represents. Having their > exact types spelled out at the point of their use will make > the tests more readable, and much easier to change. The > current setup suggests that to add a single test case for > a new tuple we will have to edit the 20.tuple.h header shared > across all tests, exposing all of them to the fallout from > our edits. I can do that. It will make the code much more verbose but also more explicit, as you say. > Also, it's generally a good idea to write headers in a way > that lets them be #included in multiple translation units of > the same program. That means avoiding data definitions (except > for those with internal linkage). I realize that 20.tuple.h > isn't meant to be #included by multiple TUs, but that might > change, especially if we decide to move the header into > tests/include like all other common headers, and compile > its contents into the test driver. You probably wouldn't want to do that since it would add symbols to the RWTest library that would get linked into every test even though they are only used in a handful of tests, namely the tuple tests. Regardless, its good practice so I have no problem doing this either. Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Friday, July 11, 2008 1:06 PM > To: dev@stdcxx.apache.org > Subject: Re: structure of tuple tests ([Fwd: Re: svn commit: > r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h > include/tuple tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers > ... > > You might want to consider extending the UserClass class defined > in tests/include/rw_value.h, or at least borrowing code or ideas > from it. I generalized the overall test pattern for tuples with the latest revision 677458. It might not be exactly what you're after but I think it's much closer than the previous version. For instance, I lot of the tests could be wrapped in TEST() function macros. Have a look if you find time. Brad.
RE: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp test
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Friday, July 11, 2008 1:06 PM
> To: dev@stdcxx.apache.org
> Subject: Re: structure of tuple tests ([Fwd: Re: svn commit:
> r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/tuple tests/utilities/20.tuple.cnstr.cpp
> tests/utilities/20.tuple.creation.cpp
> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
>
...
>
> The description of the result could be just a character string
> with the values of the tuple members. For example, for the ctor
> tuple(1, 2), the description of the expected result
> could be "{1,2}" To implement the formatting in a general way
> you might want to make use of the rw_printf() callbacks. See
> test_user_defined_formatting() in the self/0.printf.cpp test.
I was looking for a test that actually uses this user-definfed
formatting but couldn't find one. Is there a use of this
formatting directive other than the test case in 0.printf.cpp?
Thanks,
Brad.
RE: Forward iteration in variadic templates
> -Original Message- > From: Eric Lemings > Sent: Monday, July 14, 2008 2:27 PM > To: 'dev@stdcxx.apache.org' > Subject: Forward iteration in variadic templates > > > Consider the following function: > > template > void print (const Types&... values); > > How would you define print() to iterate forward from 0..N, > where N is sizeof... (Types), printing each argument X ...and its corresponding index... > in the > argument list (e.g. std::cout << X)? > > Thanks, > Brad. >
Forward iteration in variadic templates
Consider the following function: template void print (const Types&... values); How would you define print() to iterate forward from 0..N, where N is sizeof... (Types), printing each argument X in the argument list (e.g. std::cout << X)? Thanks, Brad.
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.
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
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 > >
Conflicting identifiers
Getting the following compile error due to conflicting __rw_is_same identifiers: gcc -c -I/work/stdcxx/branches/4.3.x/include/ansi -D_RWSTDDEBUG -pthread -I/work/stdcxx/branches/4.3.x/include -I/build/stdcxx-4.3.x-15D/include -I/work/stdcxx/branches/4.3.x/tests/include -pedantic -nostdinc++ -std=gnu++0x -D_RWSTD_EXT_CXX_0X -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp In file included from /work/stdcxx/branches/4.3.x/include/string:42, from /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp:417: /work/stdcxx/branches/4.3.x/include/rw/_select.h:103: error: redefinition of 'struct __rw::__rw_is_same<_TypeT, _TypeU>' /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:52: error: previous definition of 'struct __rw::__rw_is_same<_TypeT, _TypeU>' /work/stdcxx/branches/4.3.x/include/rw/_select.h:110: error: redefinition of 'struct __rw::__rw_is_same<_TypeT, _TypeT>' /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:57: error: previous definition of 'struct __rw::__rw_is_same<_TypeT, _TypeT>' make: *** [20.tuple.cnstr.o] Error 1 Brad.
Latest working draft
FYI. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf
Static assertions in tests?
For compile-time tests, would it be preferable to use a static assertion or continue using good ol' rw_assert() even for compile-time checks? In the former case, the test will fail to build and, in the latter case, the compile-time check will not be easily distinguisable from other runtime assertions. Brad.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message- > From: Eric Lemings > Sent: Wednesday, July 09, 2008 3:14 PM > To: 'dev@stdcxx.apache.org' > Subject: RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: > include/rw/_tuple.h include/tuple > tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > > > > > -Original Message- > > From: Martin Sebor [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 09, 2008 11:10 AM > > To: dev@stdcxx.apache.org > > Subject: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: > > include/rw/_tuple.h include/tuple > > tests/utilities/20.tuple.cnstr.cpp > > tests/utilities/20.tuple.creation.cpp > > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > > > ... > > > This can probably be changed to use a void return type, which will > > > simplify the code further. You only really need the return > > type to chain > > > assignments or to call a function on the result, none of > > which we should > > > be doing. > > > > Good idea! Also, the inline specifier is redundant and should > > be removed. > > A void return type causes an compile error: Duh. Disregard.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 11:10 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: > include/rw/_tuple.h include/tuple > tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > ... > > This can probably be changed to use a void return type, which will > > simplify the code further. You only really need the return > type to chain > > assignments or to call a function on the result, none of > which we should > > be doing. > > Good idea! Also, the inline specifier is redundant and should > be removed. A void return type causes an compile error: gcc -c -I/work/stdcxx/branches/4.3.x/include/ansi -D_RWSTDDEBUG -pthread -I/work/stdcxx/branches/4.3.x/include -I/build/stdcxx-4.3.x-15D/include -I/work/stdcxx/branches/4.3.x/tests/include -pedantic -nostdinc++ -std=gnu++0x -D_RWSTD_EXT_CXX_0X -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.creation.cpp /work/stdcxx/branches/4.3.x/include/rw/_tuple.h: In member function 'void __rw::__rw_ignore::operator=(const _TypeT&) const [with _TypeT = double]': /work/stdcxx/branches/4.3.x/include/rw/_tuple.h:131: instantiated from '__rw::__rw_tuple<_HeadT, _TailT ...>& __rw::__rw_tuple<_HeadT, _TailT ...>::operator=(__rw::__rw_tuple<_HeadU, _TailU ...>&&) [with _HeadU = double, _TailU = const char*, _HeadT = const __rw::__rw_ignore&, _TailT = const char*&]' /work/stdcxx/branches/4.3.x/include/rw/_tuple.h:130: instantiated from '__rw::__rw_tuple<_HeadT, _TailT ...>& __rw::__rw_tuple<_HeadT, _TailT ...>::operator=(__rw::__rw_tuple<_HeadU, _TailU ...>&&) [with _HeadU = int, _TailU = double, const char*, _HeadT = int&, _TailT = const __rw::__rw_ignore&, const char*&]' /work/stdcxx/branches/4.3.x/include/tuple:123: instantiated from 'std::tuple<_TypesT>& std::tuple<_TypesT>::operator=(std::tuple<_TypesU ...>&&) [with _TypesU = int, double, const char*, _TypesT = int&, const __rw::__rw_ignore&, const char*&]' /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.creation.cpp:75: instantiated from here /work/stdcxx/branches/4.3.x/include/rw/_tuple.h:181: error: return-statement with a value, in function returning 'void' make: *** [20.tuple.creation.o] Error 1 Brad.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 2:49 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: > include/rw/_tuple.h include/tuple > tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > > Eric Lemings wrote: > > > > > >> -Original Message- > >> From: Martin Sebor [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, July 09, 2008 11:10 AM > >> To: dev@stdcxx.apache.org > >> Subject: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: > >> include/rw/_tuple.h include/tuple > >> tests/utilities/20.tuple.cnstr.cpp > >> tests/utilities/20.tuple.creation.cpp > >> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > >> > > ... > >>> I think the commented out parameter name should be removed. > >> I don't see > >>> this in existing code, and I personally find it a bit distracting. > >> I agree. Without a name, it's obvious that the parameter > >> is unused. > > > > Examples in existing code: > > As I said before, you can find examples of pretty much any > style, including two space indents. Are you purposely seeking > out these rare, obscure cases and adopting them in your code > just to make things interesting? Actually no, if you believe that. Was just providing examples since Travis could find no such usage in existing code. Brad.
Tests for vector(size_t) constructor?
I don't see any tests for the vector(size_t) constructor anywhere. Am I not looking in the right place? Thanks, Brad.
Initialize by throwing an exception?
tests/containers/23.vector.cons.cpp:
...
685 #ifndef _RWSTD_NO_EXCEPTIONS
686
687 try {
688 // throw an exception to initialize the lib (allocates
689 // memory that's never deallocated; shows up as leaks)
690 _RW::__rw_throw (_RWSTD_ERROR_LOGIC_ERROR, "", "");
691 }
692 catch (...) {
693 }
694
695 #endif // _RWSTD_NO_EXCEPTIONS
...
This seems very odd. Initializing the library by throwing an exception.
Or is this meant only to initialize the exception handling portions of
the library?
Was hoping someone could shed some light on this.
Brad.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 11:10 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: > include/rw/_tuple.h include/tuple > tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > ... > > > > I think the commented out parameter name should be removed. > I don't see > > this in existing code, and I personally find it a bit distracting. > > I agree. Without a name, it's obvious that the parameter > is unused. Examples in existing code: The run_test() function in tests/containers/23.vector.cons.cpp. Lines 56-64 in tests/containers/23.deque.modifiers.cpp. The __rw_smanip member functions in include/iomanip. Who did all that? Not me. :) I'm sure there are plenty more examples. Anyone care to search for all such cases and make it all consistent? Brad.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 09, 2008 12:40 PM
> To: dev@stdcxx.apache.org
> Subject: RE: svn commit: r675044 - in /stdcxx/branches/4.3.x:
> include/rw/_tuple.h include/tuple
> tests/utilities/20.tuple.cnstr.cpp
> tests/utilities/20.tuple.creation.cpp
> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp
>
>
...
> >
> > As I see it, the tuple implementation is required to hold a
> copy of an
> > object of the specified type (const char* in this case). If
> you don't
> > verify the value held is indeed a copy, you are not
> actually verifying
> > the requirements. This is wrong, and wrong is much worse
> than bad. :)
>
> Question:
>
> const char* s1 = "string";
> const char* s2 = "string";
> // s1 guaranteed to equal s2?
With the following change:
Index:
/work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp
===
---
/work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp
(revision 675050)
+++
/work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp
(working copy)
@@ -74,18 +73,20 @@
#define LONG_VALUE INT_VALUE
-#define STRING_VALUE"string"
+#define STRING_VALUEstr_value
+static const char* str_value = "string";
+
static void
verify_tuple (const PairTuple& pt)
{
rw_assert (std::get<0> (pt) == LONG_VALUE, __FILE__,
__LINE__,
"std::get<0> (pt), got %d, expected %d",
std::get<0> (pt), LONG_VALUE);
-rw_assert (0 == std::strcmp (std::get<1> (pt),
STRING_VALUE),
- __FILE__, __LINE__,
- "std::get<1> (pt), got %s, expected %s",
- std::get<1> (pt), STRING_VALUE);
+rw_assert (std::get<1> (pt) == STRING_VALUE, __FILE__,
__LINE__,
+ "std::get<1> (pt), got %p \"%s\", expected %p
\"%s\"",
+ std::get<1> (pt), std::get<1> (pt),
+ STRING_VALUE, STRING_VALUE);
}
I get the following assertions:
...
# ASSERTION (S7) (5 lines):
# TEXT: std::get<1> (pt), got 0f18d8c0 "string",
expected 0042796e "string"
# CLAUSE: [tuple.cnstr]
# FILE: 20.tuple.cnstr.cpp
# LINE: 86
# INFO (S1) (5 lines):
# TEXT: move constructor (heterogenous tuples)
# CLAUSE: [tuple.cnstr]
# FILE: 20.tuple.cnstr.cpp
# LINE: 458
# ASSERTION (S7) (5 lines):
# TEXT: std::get<1> (pt), got 0f18d8c0 "string",
expected 0042796e "string"
# CLAUSE: [tuple.cnstr]
# FILE: 20.tuple.cnstr.cpp
# LINE: 86
# INFO (S1) (5 lines):
# TEXT: copy assignment operator (heterogenous tuples)
# CLAUSE: [tuple.cnstr]
# FILE: 20.tuple.cnstr.cpp
# LINE: 480
# ASSERTION (S7) (5 lines):
# TEXT: std::get<1> (pt), got 0f18d8c0 "string",
expected 0042796e "string"
# CLAUSE: [tuple.cnstr]
# FILE: 20.tuple.cnstr.cpp
# LINE: 86
# INFO (S1) (5 lines):
# TEXT: move assignment operator (heterogenous tuples)
# CLAUSE: [tuple.cnstr]
# FILE: 20.tuple.cnstr.cpp
# LINE: 504
# ASSERTION (S7) (5 lines):
# TEXT: std::get<1> (pt), got 0f18d8c0 "string",
expected 0042796e "string"
# CLAUSE: [tuple.cnstr]
# FILE: 20.tuple.cnstr.cpp
# LINE: 86
...
It appears that pointer values are not guaranteed to be equal when
converting between pointer types.
Brad.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 12:28 PM > To: dev@stdcxx.apache.org > Subject: RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: > include/rw/_tuple.h include/tuple > tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > > > > Eric Lemings wrote: > > > >> Travis Vitek wrote: > >> > >> >Modified: > >stdcxx/branches/4.3.x/tests/utilities/20.tuple.creation.cpp > >... > >> >+rw_assert (0 == std::strcmp (s, "string"), __FILE__, > __LINE__, > >> >+ "s == \"string\", got false, expected true"); > >> > >> The tuple is holding the original pointer (not a copy), so I > >think you > >> can check the actual pointer here. > > > >True. But if that assumption became invalid for whatever reason, the > >code above would still work. > > > >Assumptions are bad. Robustness is good. :) > > As I see it, the tuple implementation is required to hold a copy of an > object of the specified type (const char* in this case). If you don't > verify the value held is indeed a copy, you are not actually verifying > the requirements. This is wrong, and wrong is much worse than bad. :) Question: const char* s1 = "string"; const char* s2 = "string"; // s1 guaranteed to equal s2? Brad.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 12:28 PM > To: dev@stdcxx.apache.org > Subject: RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: > include/rw/_tuple.h include/tuple > tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > > > > Eric Lemings wrote: > > > >> Travis Vitek wrote: > >> > >> >Modified: > >stdcxx/branches/4.3.x/tests/utilities/20.tuple.creation.cpp > >... > >> >+rw_assert (0 == std::strcmp (s, "string"), __FILE__, > __LINE__, > >> >+ "s == \"string\", got false, expected true"); > >> > >> The tuple is holding the original pointer (not a copy), so I > >think you > >> can check the actual pointer here. > > > >True. But if that assumption became invalid for whatever reason, the > >code above would still work. > > > >Assumptions are bad. Robustness is good. :) > > As I see it, the tuple implementation is required to hold a copy of an > object of the specified type (const char* in this case). If you don't > verify the value held is indeed a copy, you are not actually verifying > the requirements. This is wrong, and wrong is much worse than bad. :) Good point.
RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utiliti
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2008 6:04 PM > To: dev@stdcxx.apache.org > Subject: RE: svn commit: r675044 - in /stdcxx/branches/4.3.x: > include/rw/_tuple.h include/tuple > tests/utilities/20.tuple.cnstr.cpp > tests/utilities/20.tuple.creation.cpp > tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp > > ... > > The commented unused argument names again. Also, I think the > _RWSTD_SPECIALIZED_FUNCTION macro can be eliminated. If I remember > correctly Martin asked that it be removed from the traits > implementation (which I've done). I've been using _TYPENAME, _EXPLICIT, and _RWSTD_SPECIALIZED_FUNCTION just to be consistent with existing code. Is there a good reason not to do this anymore? (Actually I can think of one but I'll see if anyone else can think of it and/or another.) > ... > Is there any way that we could write a routine to generate a tuple and > then test it, so as to avoid always using the same few types > and values > hidden behind the *_VALUE macros? The usage would be something like > this... > > TEST_TUPLE (1, 3.14f, 'a', "abc"); This might work for homogenous tuples where the element types can be deduced from the values. Not sure exactly how you would fit user-defined (e.g. UserClass) values into it. Also, you'd need an expanded form for heterogenous tuples where the compatible/convertible types would have to be explicitly specified. For this latest update, I really wanted to just get a complete set of tests in there however verbose they may be. > > >-int i = 1; > >-IntTuple it1 (i); _RWSTD_UNUSED (it1); > >-const IntTuple it2 (i); _RWSTD_UNUSED (it2); > >-ConstIntTuple ct (i); _RWSTD_UNUSED (ct); > >-IntRefTuple rt (i); _RWSTD_UNUSED (rt); > > > >-NestedTuple nt (it2); _RWSTD_UNUSED (nt); > >+#define USER_VALUE user_val > > I'm being a nit-picker, but this seems like an awful simple > thing to be > wrapping a macro around. Is there a reason to do so? Like the other value macros, to hide the actual value being used and to provide a single point of definition where it can be modified. > > >Modified: stdcxx/branches/4.3.x/tests/utilities/20.tuple.creation.cpp ... > >+rw_assert (0 == std::strcmp (s, "string"), __FILE__, __LINE__, > >+ "s == \"string\", got false, expected true"); > > The tuple is holding the original pointer (not a copy), so I think you > can check the actual pointer here. True. But if that assumption became invalid for whatever reason, the code above would still work. Assumptions are bad. Robustness is good. :) Brad.
RE: Another potential hole in the tuple specs
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 08, 2008 2:36 PM
> To: dev@stdcxx.apache.org
> Subject: RE: Another potential hole in the tuple specs
>
>
...
> The following testcase works just fine (on acc-6.16, gcc-4.3.1 &
> msvc-8.0)
>
> namespace std {
>
>
> struct _Ignore
> {
> template
> void operator=(const _TypeT&) const
> {
> }
> };
This would probably work also. In any case, I've got it working now.
I'm currently enhancing the tuple test suite and doing more extensive
testing.
Brad.
RE: Another potential hole in the tuple specs
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2008 1:14 PM > To: dev@stdcxx.apache.org > Subject: Re: Another potential hole in the tuple specs > > Eric Lemings wrote: > > > > ... > > > > I tried making std::ignore const and adding const to the internal > > assignment operator. I also tried adding overloads for const and > > non-const assignment. Still got errors in all cases. > > > > The only other recourse I can think of is to use remove_const on the > > element types where appropriate. > > ignore is declared const in Boost so there must be a way > to implement tie() without declaring the object non-const. Found it. Thanks. Brad.
RE: Another potential hole in the tuple specs
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2008 10:52 AM > To: dev@stdcxx.apache.org > Subject: Re: Another potential hole in the tuple specs > > Eric Lemings wrote: > > > [...] > > A const assignment operator? Sounds unorthodox but I'll try it out. > > > > My current workaround is to declare std::ignore mutable (i.e. > > non-const). A const assignment operator (if it works) would be > > preferable; no visible workaround required. > > Remember that even the absence (or presence) of the const > qualifier on things like std::ignore can be detected by > conformance test suites so dropping it is not a viable > option. Assuming the draft standard is actually correct, that is. In this case, I don't think there is any real need for std::ignore to be a constant really. (Thinking about asking whether std::ignore really needs to be a constant on the committee reflector.) I tried making std::ignore const and adding const to the internal assignment operator. I also tried adding overloads for const and non-const assignment. Still got errors in all cases. The only other recourse I can think of is to use remove_const on the element types where appropriate. Brad.
RE: Another potential hole in the tuple specs
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Monday, July 07, 2008 5:44 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Another potential hole in the tuple specs
>
> Eric Lemings wrote:
> >
> >
> > Here's another potential problem with the tuple spec. The
> latest draft
> > declares std::ignore like so:
> >
> > namespace std {
> > const /*unspecified*/ ignore;
> > }
> >
> > The type of std::ignore is implementation-defined but for
> illustration,
> > let's say its defined like this:
> >
> > namespace std {
> >
> > struct _Ignore
> > {
> > template
> > _Ignore& operator= (const _Type& value) { return *this; }
> > };
> >
> > const _Ignore ignore = _Ignore ();
> >
> > } // namespace std
> >
> > (The need for the operator will become evident shortly.)
> >
> > Here's how the tie() function is specified, quoting from
> the standard:
> >
> > template > tuple tie(Types&... t);
> >
> > 4 Returns: tuple(t...). When an argument in t is ignore,
> > assigning any value to the corresponding
> > tuple element has no effect.
> >
> > 5 [ Example: tie functions allow one to create tuples that
> > unpack tuples into variables. ignore can be used for
> > elements that are not needed:
> >
> > int i; std::string s;
> > tie(i, ignore, s) = make_tuple(42, 3.14, "C++");
> > // i == 42, s == "C++"
> >
> > -end example ]
> >
> > In the example, the return type of the call to the tie() function is
> > std::tuple. Note that the
> > second element type in the tuple is a constant reference.
> Regardless of
> > the implementation-defined type of std::ignore, isn't it
> impossible to
> > change the value of a constant reference once initialized?
> This would
> > mean the example shown above is ill-formed I believe.
>
> You mean because tie(i, ignore, s) = make_tuple(42, 3.14, "C++")
> must assign 3.14 to std::ignore? Would declaring the assignment
> operator cost be a way to make it work?
A const assignment operator? Sounds unorthodox but I'll try it out.
My current workaround is to declare std::ignore mutable (i.e.
non-const). A const assignment operator (if it works) would be
preferable; no visible workaround required.
Brad.
RE: Makefile issues on hp-ux
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, July 07, 2008 4:36 PM > To: dev@stdcxx.apache.org > Subject: Re: Makefile issues on hp-ux > > Travis Vitek wrote: > > I'm seeing some weird errors when porting some code to > acc-6.16, and I > > figured that I'd mention it because I've wasted a > considerable amount of > > time trying to figure out why my code isn't compiling. The > following is > > a transcript of what I've been seeing... > > Yeah, there's a problem with implicit rules... Use -r to disable > them and to avoid compiling and linking in one step (the +nostl > option can't be used for compilation with aCC because we're > using its C++ libc headers such as ). I was about to ask if there were separate options for the C++ header search path and the C header search path. Brad.
Another potential hole in the tuple specs
Here's another potential problem with the tuple spec. The latest draft
declares std::ignore like so:
namespace std {
const /*unspecified*/ ignore;
}
The type of std::ignore is implementation-defined but for illustration,
let's say its defined like this:
namespace std {
struct _Ignore
{
template
_Ignore& operator= (const _Type& value) { return *this; }
};
const _Ignore ignore = _Ignore ();
} // namespace std
(The need for the operator will become evident shortly.)
Here's how the tie() function is specified, quoting from the standard:
template tie(Types&... t);
4 Returns: tuple(t...). When an argument in t is ignore,
assigning any value to the corresponding
tuple element has no effect.
5 [ Example: tie functions allow one to create tuples that
unpack tuples into variables. ignore can be used for
elements that are not needed:
int i; std::string s;
tie(i, ignore, s) = make_tuple(42, 3.14, "C++");
// i == 42, s == "C++"
-end example ]
In the example, the return type of the call to the tie() function is
std::tuple. Note that the
second element type in the tuple is a constant reference. Regardless of
the implementation-defined type of std::ignore, isn't it impossible to
change the value of a constant reference once initialized? This would
mean the example shown above is ill-formed I believe.
Brad.
RE: Makefile issues on hp-ux
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, July 07, 2008 4:24 PM > To: dev@stdcxx.apache.org > Subject: Makefile issues on hp-ux > > > I'm seeing some weird errors when porting some code to acc-6.16, and I > figured that I'd mention it because I've wasted a > considerable amount of > time trying to figure out why my code isn't compiling. The > following is > a transcript of what I've been seeing... > > $ pwd > /build/vitek/4.3.0/11S/tests > $ gmake 20.meta.trans.sign > aCC -AA -g +d +DD64 +w +W392,655,684,818,819,849 > +W2193,2236,2261,2340,2401,2487 +W4227,4229,4231,4235,4237,4249 > +W4255,4272,4284,4285,4286,4296,4297 +W3348 -D_RWSTDDEBUG > -D_RWSTD_EXT_CXX_0X -I/amd/devco /vitek/stdcxx/4.3.x/include Looks like there's a missing "-I" before that last directory. Brad.
RE: svn commit: r673865 - in /stdcxx/branches/4.3.x/tests/utilities: 20.forward.cpp 20.tuple.cnstr.cpp 20.tuple.creation.cpp 20.tuple.elem.cpp 20.tuple.helpers.cpp 20.tuple.rel.cpp
I think there should be an implicit #define directive in : #if defined _RWSTD_NO_VARIADIC_TEMPLATES //|| defined _RWSTD_NO_RVALUE_REFERENCES if actually required for C++0x extensions # define _RWSTD_NO_EXT_CXX_0X #endif What does everyone think? Brad. > -Original Message- > From: Travis Vitek > Sent: Monday, July 07, 2008 2:00 PM > To: Eric Lemings > Subject: RE: svn commit: r673865 - in > /stdcxx/branches/4.3.x/tests/utilities: 20.forward.cpp > 20.tuple.cnstr.cpp 20.tuple.creation.cpp 20.tuple.elem.cpp > 20.tuple.helpers.cpp 20.tuple.rel.cpp > > > Yes, I'm porting to aCC and none of the tuple tests compile > (lack of rvalue reference). Actually, now that I think about > it I should probably have added a check for variadic templates. Ugh. > > >-Original Message- > >From: Eric Lemings > >Sent: Monday, July 07, 2008 11:02 AM > >To: Travis Vitek > >Subject: RE: svn commit: r673865 - in > >/stdcxx/branches/4.3.x/tests/utilities: 20.forward.cpp > >20.tuple.cnstr.cpp 20.tuple.creation.cpp 20.tuple.elem.cpp > >20.tuple.helpers.cpp 20.tuple.rel.cpp > > > > > > > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, July 03, 2008 5:26 PM > >> To: [EMAIL PROTECTED] > >> Subject: svn commit: r673865 - in > >> /stdcxx/branches/4.3.x/tests/utilities: 20.forward.cpp > >> 20.tuple.cnstr.cpp 20.tuple.creation.cpp 20.tuple.elem.cpp > >> 20.tuple.helpers.cpp 20.tuple.rel.cpp > >> > >> Author: vitek > >> Date: Thu Jul 3 16:26:24 2008 > >> New Revision: 673865 > >> > >... > >> Modified: stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp > >> URL: > >> http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/tests/utili > >> ties/20.tuple.cnstr.cpp?rev=673865&r1=673864&r2=673865&view=diff > >> == > >> > >> --- stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp > >> (original) > >> +++ stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp > >> Thu Jul 3 16:26:24 2008 > >> @@ -29,7 +29,8 @@ > >> #include > >> > >> // compile out all test code if extensions disabled > >> -#ifndef _RWSTD_NO_EXT_CXX_0X > >> +#if!defined (_RWSTD_NO_EXT_CXX_0X) \ > >> +&& !defined(_RWSTD_NO_RVALUE_REFERENCES) > > > >Just to verify, your reasoning for this is that C++0x > >extensions can be enabled but without support for rvalue references? > > > >If so, sounds reasonable. Just wanted to double check. > > > >Brad. > >
RE: Tuple status
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Thursday, July 03, 2008 9:16 AM > To: dev@stdcxx.apache.org > Subject: Re: Tuple status > > Eric Lemings wrote: > > ... > > > > I agree though: there is a lot of duplication and if it were not for > > the special pair ctors and assignment operators, there > would probably > > be only one class template. > > Hmm. That's too bad. The prevailing opinion among the C++ committee > is that pair is exceeding less useful now that we have tuple and that > it would be best removed or deprecated or some such. It would be a > shame to compromise the design of type just to accommodate something > that most of us seem to think is a wart and shouldn't be used. If > there's just no way to have a clean tuple because of pair we might > want to formally propose to eliminate the coupling between the two. > We have at most 2 months to do this. You could propose this but I very much doubt it would pass, at least in the upcoming revision of the standard. It would have a much better chance of being approved in the subsequent revision of the standard. My reasoning is this. The current standard has pairs but no tuples so existing code that requires such facilities would be, of course, using pairs. The next standard will contain tuples and the committee expects new code to be written with tuples and existing code to MIGRATE to tuples. The pair specialization facilitates this migration. Without it, there is no migration path. Now after a decade or so, code would have enough time to migrate to tuples and a proposal to remove pairs would more likely be approved for standardization. > ... > > > > Without the cast, the argument type passed to the internal ctor is > > still `std::tuple<_TypesT...>' and, because of the template ctors, > > the compiler would therefore bind to the templated copy ctor wisely > > deeming this ctor a better "fit". > > Would this be prevented by not deriving tuple from __rw_tuple (or > not deriving it directly)? FWIW, it seems to me that in order to > implement the space optimization we discussed this morning, we > might need to make some changes in this area anyway. We should > keep the cast issue in mind while designing a solution. I'll have to look into this further but I'm almost certain the changes required to implement this optimization would make the code even more complicated and -- if the solution is what I think it may be -- might even require another base class and possibly more casts. Brad.
RE: [Stdcxx Wiki] Update of "C++IssueStatus" by MartinSebor
I'm guessing the procedure for analyzing these issues is to:
1.) Post which issues you plan to analyze to the list.
2.) Once analyzed, update the Wiki page with your analysis.
Correct?
Brad.
> -Original Message-
> From: Apache Wiki [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 01, 2008 10:53 PM
> To: [EMAIL PROTECTED]
> Subject: [Stdcxx Wiki] Update of "C++IssueStatus" by MartinSebor
>
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on
> "Stdcxx Wiki" for change notification.
>
> The following page has been changed by MartinSebor:
> http://wiki.apache.org/stdcxx/C++IssueStatus
>
> The comment on the change is:
> Added issue 775.
>
> --
>
> || {*} || [http://tinyurl.com/ytwhtt#705 705] ||<(>
> type-trait `decay` incompletely specified || CHECK || ||
> || {X} || [http://tinyurl.com/ytwhtt#706 706] ||<(>
> `make_pair()` should behave as `make_tuple()` wrt.
> `reference_wrapper()`|| '''TO DO ''' || ||
> || {X} || [http://tinyurl.com/ytwhtt#712 712] ||<(>
> `seed_seq::size` no longer useful || '''TO
> DO''' || ||
> -
> + || {X} || [http://tinyurl.com/ytwhtt#775 775] ||<(> Tuple
> indexing should be unsigned?|| '''TO DO''' || ||
>
> Legend:
>
>
RE: error on tuple copy ctor
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, July 02, 2008 5:17 PM > To: dev@stdcxx.apache.org > Subject: Re: error on tuple copy ctor > > Eric Lemings wrote: > > ... > AFAICS, this is the same as S(S&&). Doesn't preferring a template > over an ordinary function with the same signature seem wrong? Wrong, possibly. Certainly not what one might expect. Brad.
RE: error on tuple copy ctor
Off list, the original tuple construction example, i.e.,
#include
int main () {
std::tuple t;
std::tuple u (t);
}
will not compile with the GNU libstdc++ tuple implementation either
without the additional `tuple (tuple&)' ctor. That's the main reason I
suggested adding the additional ctor as a workaround.
gcc-4.3.1/include/c++/4.3.1/tuple:
...
227 tuple(const tuple& __in)
228 : _Inherited(static_cast(__in)) { }
229
230 tuple(tuple&& __in)
231 : _Inherited(std::move<_Inherited>(__in)) { }
...
242 // XXX
http://gcc.gnu.org/ml/libstdc++/2008-02/msg00047.html
243 template
244 tuple(tuple<_UElements...>& __in)
245 : _Inherited(static_cast&>(__in))
246 { }
Brad.
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 02, 2008 3:55 PM
> To: dev@stdcxx.apache.org
> Subject: Re: error on tuple copy ctor
>
> Eric Lemings wrote:
> >
> >
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> >> Sent: Wednesday, July 02, 2008 3:18 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: Re: error on tuple copy ctor
> >>
> > ...
> >>> Should we add the ctor even if the standard does not
> >> (currently) specify it?
> >>
> >> I don't think it's needed or desirable. In the test case I
> >> posted, we want to call the const T& overload.
> >
> > That's the only workaround I can think of. You have another one in
> > mind?
>
> A workaround for what? This is a valid definition of
> a CopyConstructible and MoveConstructible class (like tuple):
>
> struct S {
> S (const S&);
> S (S&&);
> };
>
> I don't see why S would need another copy ctor with the signature
> of S(S&). I realize tuple is quite a bit more complicated than S,
> too complicated for me to understand why the ctor might be
> necessary if, if fact, it really is. Could you show in a small
> isolated example the problem that this ctor works around?
>
> Martin
>
RE: error on tuple copy ctor
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 02, 2008 3:55 PM
> To: dev@stdcxx.apache.org
> Subject: Re: error on tuple copy ctor
>
> Eric Lemings wrote:
> >
> >
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> >> Sent: Wednesday, July 02, 2008 3:18 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: Re: error on tuple copy ctor
> >>
> > ...
> >>> Should we add the ctor even if the standard does not
> >> (currently) specify it?
> >>
> >> I don't think it's needed or desirable. In the test case I
> >> posted, we want to call the const T& overload.
> >
> > That's the only workaround I can think of. You have another one in
> > mind?
>
> A workaround for what? This is a valid definition of
> a CopyConstructible and MoveConstructible class (like tuple):
>
> struct S {
> S (const S&);
> S (S&&);
> };
>
> I don't see why S would need another copy ctor with the signature
> of S(S&). I realize tuple is quite a bit more complicated than S,
> too complicated for me to understand why the ctor might be
> necessary if, if fact, it really is. Could you show in a small
> isolated example the problem that this ctor works around?
It would probably bind as expected if not for the template ctors in
tuple. Apparently the compiler will prefer binding to a template ctor
any chance it gets because the constructed type and argument types are
"better", if not exact, matches in a template ctor. Not so for trivial
copy ctors.
For binding to a `S (const S&)' ctor given an object value of S, there
is an implicit const conversion involved.
Here's a small test case to illustrate:
#include
using namespace std;
struct S {
S () {}
S (const S&) { cout << "trivial copy ctor called" << endl; }
template
S (T&&) { cout << "templated move ctor called" << endl; }
};
int main () {
S s1;
S s2 (s1); // trivial copy or templated move?
return 0;
}
Brad.
RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> -Original Message-
> From: Eric Lemings
> Sent: Wednesday, July 02, 2008 3:42 PM
> To: 'dev@stdcxx.apache.org'
> Subject: RE: svn commit: r672395 - in
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
>
>
>
> > -Original Message-
> > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> > Sent: Saturday, June 28, 2008 2:51 PM
> > To: dev@stdcxx.apache.org
> > Subject: Re: svn commit: r672395 - in
> > /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> >
> ...
> >
> >5. The definitions of even trivial non-empty functions should
> > never appear on the same line as the function signature. I.e.,
> > the above should be:
> >
> > type& get() const {
> > _RWSTD_ASSERT (0 != _C_ptr);
> > return *_C_ptr;
> > }
>
> I assume empty function definitions are exempted from this convention?
>
Hey... I also see one-line trivial functions in , , and
headers.
Brad.
RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 2:51 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r672395 - in
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
>
...
>
>5. The definitions of even trivial non-empty functions should
> never appear on the same line as the function signature. I.e.,
> the above should be:
>
> type& get() const {
> _RWSTD_ASSERT (0 != _C_ptr);
> return *_C_ptr;
> }
I assume empty function definitions are exempted from this convention?
Brad.
RE: Tuple status
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, July 01, 2008 11:08 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Tuple status
>
...
>
>c) in ctor initializer lists spanning multiple lines, please
>avoid dropping the colon or the comma; i.e.,
>
>struct A: Base {
>int _C_i;
>A (int i): Base (), _C_i (i) { /* empty */ }
>
>or (for long initializer lists):
>
>A (int i):
>Base (very_long_sequence_of_arguments),
>_C_i (i) {
>// empty
>}
>
Not the comma but I do see the colon being dropped on a newline in
$SRCDIR/include/vector for example.
Brad.
RE: error on tuple copy ctor
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, July 02, 2008 3:18 PM > To: dev@stdcxx.apache.org > Subject: Re: error on tuple copy ctor > ... > > > > Should we add the ctor even if the standard does not > (currently) specify it? > > I don't think it's needed or desirable. In the test case I > posted, we want to call the const T& overload. That's the only workaround I can think of. You have another one in mind? Brad.
RE: Tuple status
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, July 01, 2008 11:08 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Tuple status
>
...
>c) in ctor initializer lists spanning multiple lines, please
>avoid dropping the colon or the comma; i.e.,
>
>struct A: Base {
>int _C_i;
>A (int i): Base (), _C_i (i) { /* empty */ }
>
>or (for long initializer lists):
>
>A (int i):
>Base (very_long_sequence_of_arguments),
>_C_i (i) {
>// empty
>}
>
Sure I can do that. Just curious though if you're aware of the
rationale behind that convention. I assume that you've seen it before
or no?
Oh, and I'm not arguing or proposing anything, just asking. :) I, for
one, am starting to take Sutter and Alexandrescu's Rule #0 to heart.
Brad.
RE: Tuple status
> -Original Message- > From: Eric Lemings [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 02, 2008 10:45 AM > To: dev@stdcxx.apache.org > Subject: RE: Tuple status > > > > > -Original Message- > > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of > Martin Sebor > > Sent: Tuesday, July 01, 2008 11:08 PM > > To: dev@stdcxx.apache.org > > Subject: Re: Tuple status > > ... > > >3. why is is the base class __rw_tuple rather than std::tuple? Ah. I misread this question and so didn't really answer this it correctly. std::tuple inherits from __rw_tuple because the latter class template exposes the accesssors for head and tail. The public class does not expose these internal accessors. Could you move the accessors into std::tuple? Yes, if it were not for the pair specialization as I mentioned in the first reply. Brad.
RE: error on tuple copy ctor
Ohhh...now I remember. That's the case that is not currently covered by
the standard. The standard only specifies the following ctor:
tuple (const tuple&);
It does not require this ctor:
tuple (tuple&);
And because of the stricter type checking I mentioned earlier, a
`tuple' value will not bind to a `const tuple&' ctor (which I
really found surprising).
See the following thread from GNU libstdc++ for more info:
http://gcc.gnu.org/ml/libstdc++/2008-02/msg00047.html
Should we add the ctor even if the standard does not (currently) specify
it?
Brad.
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 02, 2008 12:32 PM
> To: dev@stdcxx.apache.org
> Subject: error on tuple copy ctor
>
> As a heads up, while playing with the brand spanking new tuple
> I ran into the error below. Looks like some of the ambiguities
> we talked about are still there.
>
> $ cat z.cpp \
>&& make CPPOPTS=-D_RWSTD_EXT_CXX_0X CXXOPTS=-std=gnu++0x z
> #include
>
> int main () {
> std::tuple t;
> std::tuple u (t);
> }
> gcc -c -I/home/sebor/stdcxx-4.3.x/include/ansi -D_RWSTDDEBUG
> -pthread
> -I/home/sebor/stdcxx-4.3.x/include
> -I/build/sebor/stdcxx-4.3.x-gcc-4.3.0-15D/include
> -I/home/sebor/stdcxx-4.3.x/examples/include -D_RWSTD_EXT_CXX_0X
> -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow
> -Wwrite-strings -Wno-long-long -Wcast-align -std=gnu++0x z.cpp
> /home/sebor/stdcxx-4.3.x/include/rw/_tuple.h: In constructor
> '__rw::__rw_tuple<_HeadT, _TailT ...>::__rw_tuple(_HeadU&&, _TailU&&
> ...) [with _HeadU = std::tuple&, _TailU = , _HeadT =
> int, _TailT = ]':
> /home/sebor/stdcxx-4.3.x/include/tuple:110: instantiated from
> 'std::tuple<_Types>::tuple(_TypesU&& ...) [with _TypesU =
> std::tuple&, _TypesT = int]'
> z.cpp:5: instantiated from here
> /home/sebor/stdcxx-4.3.x/include/rw/_tuple.h:115: error:
> cannot convert
> 'std::tuple' to 'int' in initialization
> make: *** [z.o] Error 1
>
>
RE: error on tuple copy ctor
Doh. Hard to believe I missed something that common in the tests but
not unthinkable. :P
Will add it to the list of changes to address previous comments.
Brad.
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 02, 2008 12:32 PM
> To: dev@stdcxx.apache.org
> Subject: error on tuple copy ctor
>
> As a heads up, while playing with the brand spanking new tuple
> I ran into the error below. Looks like some of the ambiguities
> we talked about are still there.
>
> $ cat z.cpp \
>&& make CPPOPTS=-D_RWSTD_EXT_CXX_0X CXXOPTS=-std=gnu++0x z
> #include
>
> int main () {
> std::tuple t;
> std::tuple u (t);
> }
> gcc -c -I/home/sebor/stdcxx-4.3.x/include/ansi -D_RWSTDDEBUG
> -pthread
> -I/home/sebor/stdcxx-4.3.x/include
> -I/build/sebor/stdcxx-4.3.x-gcc-4.3.0-15D/include
> -I/home/sebor/stdcxx-4.3.x/examples/include -D_RWSTD_EXT_CXX_0X
> -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow
> -Wwrite-strings -Wno-long-long -Wcast-align -std=gnu++0x z.cpp
> /home/sebor/stdcxx-4.3.x/include/rw/_tuple.h: In constructor
> '__rw::__rw_tuple<_HeadT, _TailT ...>::__rw_tuple(_HeadU&&, _TailU&&
> ...) [with _HeadU = std::tuple&, _TailU = , _HeadT =
> int, _TailT = ]':
> /home/sebor/stdcxx-4.3.x/include/tuple:110: instantiated from
> 'std::tuple<_Types>::tuple(_TypesU&& ...) [with _TypesU =
> std::tuple&, _TypesT = int]'
> z.cpp:5: instantiated from here
> /home/sebor/stdcxx-4.3.x/include/rw/_tuple.h:115: error:
> cannot convert
> 'std::tuple' to 'int' in initialization
> make: *** [z.o] Error 1
>
>
RE: Tuple status
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, July 01, 2008 11:08 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Tuple status
>
> Eric Lemings wrote:
> >
> > I got this problem fixed with my latest change.
> >
> > The tuple test suite needs to be bolstered (suggestions for
> additional
> > test strategies greatly appreciated BTW) but the implementation as a
> > whole is stable enough for code review.
>
> Excellent! It looks very clean -- I like it. Just a few quick
> questions and comments on the implementation (I haven't looked
> at the tests yet):
>
>1. should only #include the traits header(s) for the
>the traits it needs, not all of , and use only
>the __rw_xxx traits (not std::xxx)
I stopped including individual headers at one point when I reached
7 or 8 headers so I just included the whole lot. That was before
my last big change however so I could probably go back to individual
headers.
>
>2. would it be possible (and would it make sense) for
>to forward declare reference_wrapper instead of #including the
>whole definition of the class to reduce the size of translation
>units that don't use the class?
I believe it would.
>3. why is is the base class __rw_tuple rather than std::tuple?
>(seems there's a lot of duplicate code between the two)
It's primarily because of the specialization for pairs. For that
specialization to work with the tuple helpers, it needs to have the
same structural layout (i.e. recursive inheritance and data storage)
as the generalization. The best way for both to work in the same
helpers (mini-algorithms really) is to use a common base.
I agree though: there is a lot of duplication and if it were not for
the special pair ctors and assignment operators, there would probably
be only one class template.
>
>4. assuming the answer to (3) is yes, are the casts in tuple
>copy ctor and copy assignment necessary or might there be
>a cleaner way to accomplish the same thing? if not, please
>consider adding a brief comment explaining why they are
>important
The casts are necessary to make sure the public ctors and operators
bind to the correct ctors and operators in the internal base class.
The copy ctor for example:
tuple (const tuple& __tuple)
: _Base (_RWSTD_STATIC_CAST (const _Base&, __tuple)) { /* empty
*/ }
The object type and argument type are both `std::tuple<_TypesT...>'.
We want this ctor to call the corresponding ctor in the base class.
Namely,
__rw_tuple (const __rw_tuple& __tuple)
...
Without the cast, the argument type passed to the internal ctor is
still `std::tuple<_TypesT...>' and, because of the template ctors,
the compiler would therefore bind to the templated copy ctor wisely
deeming this ctor a better "fit".
template
__rw_tuple (const __rw_tuple<_HeadU, _TailU...>& __tuple)
...
This is not what we want. (On a side note, it appears that the C++0x
mode in GCC 4.3.x -- because of rvalue references I'm guessing -- is
much more type strict than current and past versions.)
In the helper functions, the accessors are defined in the internal
class template. (The public class template doesn't even really have
a head and tail.) So in this case, the casts are needed to expose
these internal accessors.
>
>5. assuming the answer to (3) is yes, would it be better to
>define the [in]equality comparison for __rw_tuple as (possibly
>member) functions called _C_equal and _C_less to avoid the
>casts in the same operators in tuple and reduce the size of
>the overload set?
I tried doing it that way but the terminating specialization proved a
little tricky (they would have to be added to the empty specialization)
so I just wrote them outside the template.
>
>6. we can and should remove the _RWSTD_NO_EXT_CXX_0X guards
>from all implementation headers under include/rw/
The assumption is that only we include those headers and presumably
we only include them in the right public headers and IF end users
include these internal headers (which they shouldn't do) then they
should get errors?
>
>7. the right place to #define _RWSTD_XXX macros is
Which ones in particular?
>
>8. why is std::ignore typedef'd to __rw_ignore when the latter
>isn't used anywhere (AFAICS), and shouldn't it be defined in
>a .cpp file to avoid multiply defined symbols?
It can be used in the tie() function which I still need to implement.
>
>9. shouldn't tuple_element take size_t as template argument
>as per LWG issue 755
Yes.
>
>10. the non-trivial bits could use so
RE: Tuple status
I got this problem fixed with my latest change. The tuple test suite needs to be bolstered (suggestions for additional test strategies greatly appreciated BTW) but the implementation as a whole is stable enough for code review. Brad. > -Original Message- > From: Eric Lemings [mailto:[EMAIL PROTECTED] > Sent: Monday, June 30, 2008 4:42 PM > To: dev@stdcxx.apache.org > Subject: RE: Tuple status > > > Committed. > > Note, there is still a problem with using reference wrappers with > make_tuple() which I'm currently working on but I didn't want > to hold up > this rather large change any longer. > > Brad. > > > -Original Message- > > From: Eric Lemings [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 30, 2008 10:46 AM > > To: dev@stdcxx.apache.org > > Subject: Tuple status > > > > > > Just a brief status on tuple progress. > > > > I got the remaining portions of tuple (except the tie() > function) work > > late Friday. I did a personal code review over the weekend and am > > applying some cleanup and other finishing touches. Should > be checking > > in a lot of changes later today. So just a heads up. > > > > Brad. > > >
RE: implementation of Unary Traits
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, June 30, 2008 10:51 PM > To: dev@stdcxx.apache.org > Subject: Re: implementation of Unary Traits > > Travis Vitek wrote: > > > [...] > > If you ask what I prefer, I'm going to tell you I prefer the second > > option (that is essentially what I wrote originally). But, > honestly, for > > me to care either way, I need to know that there actually a > noticeable > > performance difference between the two techniques. > > FYI: I used gcc 4.3 and EDG eccp to measure the difference between > the compilation times of each of the two approaches (i.e., using > specialization vs using remove_cv). > > In a program involving 10,000 invocations of is_void on distinct > types, the specialization approach was 5 and 10 times faster than > the one using remove_cv when using gcc and eccp, respectively. In > the same program using only 1000 types, the specialization solution > compiled 2 and 3 times faster, respectively. > > With gcc, the compiler also required about half the amount of system > memory to compile the specialization-based solution than the other > one. (I didn't measure eccp memory usage). > > This confirms that template metaprogramming is significantly more > costly in terms of system resources than alternative approaches, > at least in the gcc and eccp implementations. We should re-run the > same tests with other compilers to get a complete picture. That's not unexpected: like everything in computing, it's a tradeoff. To get a really complete picture, you'd have to compare the metaprogramming approach to the run-time alternatives. I would expect to see a corresponding speed increase and storage savings compared to the runtime counterparts. Brad.
RE: C++ 0x testing
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, June 30, 2008 6:47 PM > To: dev@stdcxx.apache.org > Subject: Re: C++ 0x testing > > Eric Lemings wrote: > > ... > > Anyways, > > the gcc.config flag appends the appropriate compiler flags and > > defines only if this make variable is defined; e.g. > > > > ifeq ($(_RWSTD_EXT_CXX_0X),1) > > CXXFLAGS += -std=gnu++0x -D_RWSTD_EXT_CXX_0X > > endif > > I'm suggesting we unconditionally enable it on 4.3.x in builds > with gcc 4.3 (and all other compilers where it's intended to > be tested). IIUC, the approach outlined above won't help us test > the implementation in nightly builds because it'll still leave > C++ 0x disabled unless we also change the buildntest script to > define the make variable the way you show. If we were to take > this approach I don't see the advantage over simply setting > CXXOPTS=-std=gnu++0x instead. It seems to me that most users > are more likely to be familiar and comfortable with using > compiler options than with #defining our config macros. My thought is that since 4.3.0 will be released (we hope) long before the C++0x standard even reaches FCD status (much less be ratified about a year later), the C++0x extensions would be disabled by default. In the 5.0.0 release, which should occur somewhat simultaneous with ratification of the standard, C++0x conformance would be enabled by default. As for testing C++0x in the 4.3.x branch, we would just have to modify the nightly build and test scripts. You don't think we should bother testing gcc 4.3.x builds WITHOUT the C++0x extensions? Brad.
RE: Tuple status
Committed. Note, there is still a problem with using reference wrappers with make_tuple() which I'm currently working on but I didn't want to hold up this rather large change any longer. Brad. > -Original Message- > From: Eric Lemings [mailto:[EMAIL PROTECTED] > Sent: Monday, June 30, 2008 10:46 AM > To: dev@stdcxx.apache.org > Subject: Tuple status > > > Just a brief status on tuple progress. > > I got the remaining portions of tuple (except the tie() function) work > late Friday. I did a personal code review over the weekend and am > applying some cleanup and other finishing touches. Should be checking > in a lot of changes later today. So just a heads up. > > Brad. >
RE: C++ 0x testing
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, June 30, 2008 3:54 PM > To: dev@stdcxx.apache.org > Subject: C++ 0x testing > > Unless I'm missing something, C++ 0x testing is currently disabled > in nightly builds. I.e., because tests for the newly added C++ 0x > features are guarded by the _RWSTD_NO_CXX_0X macro and because > _RWSTD_EXT_CXX_0X is not #defined, the tests are compiled into > what essentially amounts an empty main(). > > With type traits and tuple being nearly done, I think it's time > to start exercising these and any other new components in nightly > builds. One approach that might be easily implementable at least > for gcc is the one suggested in a recent thread: for 4.3.x, add > -std=gnu++0x to the set of compiler options for gcc 4.3 and > beyond, and make _RWSTD_EXT_CXX_0X synonymous with gcc's > __GXX_EXPERIMENTAL_CXX0X__. > > Is there a better approach? I'd like to get things set up > sometime this week. Rather than hard-code the flags, I suggest a command-line make definition; e.g. make _RWSTD_EXT_CXX_0X=1 ... I thought this is the way it was originally proposed. Anyways, the gcc.config flag appends the appropriate compiler flags and defines only if this make variable is defined; e.g. ifeq ($(_RWSTD_EXT_CXX_0X),1) CXXFLAGS += -std=gnu++0x -D_RWSTD_EXT_CXX_0X endif Brad.
RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 2:51 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r672395 - in
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
>
...
>5. The definitions of even trivial non-empty functions should
> never appear on the same line as the function signature. I.e.,
> the above should be:
>
> type& get() const {
> _RWSTD_ASSERT (0 != _C_ptr);
Should we still use integral constant `0' for null pointers when writing
C++0x code or should we use the new `nullptr' name? Or (more likely),
an internal macro aliasing one or the other; e.g., _RWSTD_NULLPTR?
Brad.
Tuple status
Just a brief status on tuple progress. I got the remaining portions of tuple (except the tie() function) work late Friday. I did a personal code review over the weekend and am applying some cleanup and other finishing touches. Should be checking in a lot of changes later today. So just a heads up. Brad.
RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 2:51 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r672395 - in
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
>
...
> > @@ -45,10 +45,11 @@
> >
> >
> > #include
> > +#include
>
> The #include directive should be guarded by #ifndef
> _RWSTD_NO_EXT_CXX_0X. That way non-C++ 0x users won't be penalized
> by #including the header and we won't have to worry about wrapping
> the whole contents of in a pair of these #ifdef/
> #endif directives.
I don't have a problem with this really but are you certain this
"penalty" is really worth adding redundant compile guards, considering
that the header already contains guards, albeit within the header? I'm
not sure the perceived penalty is really worth the trouble.
>
...
> >
> > template
> > -class __rw_ref_wrap
> > +class reference_wrapper
> > {
> > +_Type* _C_ptr;
> > +
> > +public:
> > +
> > +typedef _Type type;
> > +
> > +reference_wrapper (_Type& __x)
> > +: _C_ptr (&__x) { /* empty */ }
> > +
> > +reference_wrapper (const reference_wrapper<_Type>& __x)
> > +: _C_ptr (__x._C_ptr) { /* empty */ }
> > +
> > +reference_wrapper& operator= (const
> reference_wrapper<_Type>& __x) {
> > +_C_ptr = __x._C_ptr;
> > +return *this;
>
>1. We prefer to use the public types in favor of those of template
> parameters in definitions of standard templates. This is in
> contrast to the spec which prefers the template paramaters for
> some unknown reason. Our rationale is that the public names are
> more stable and more familiar to users and maintainers alike.
Hmm. I have no problem with that either. I'd like to have a more
convincing
rationale (for either case) though.
Does the compiler treat a typedef and a template parameter the same or
are
there actually slight differences?
>
>2. We omit redundant template arguments in the definition of
> a template class. The rationale is simplicity.
> Thus, the declaration of the assignment operator should look
> like so:
>
> reference_wrapper& operator= (const reference_wrapper& __x)
Oh right. I usually do it that way myself. Not sure why I explicitly
named them here.
>
>3. We omit definitions of special member functions (ctors, non
> virtual dtors, and assignment operators) that are normally
> implicitly generated by the compiler (provided the effects
> are right, of course). The rationale is efficiency and
> simplicity.
Simplicity, yes. Not sure its any less efficient.
But there should be a comment explicitly stating that the
compiler-generated members are expected/acceptable? If for example
another ctor were added, the comment would remind the developer that the
compiler-generate members are no longer there and must be added.
> In reference_wrapper, we can safely omit the definition of
> not just the dtor but also that of the copy ctor and the
> copy assignment operator.
>
> > +}
> >
> > +operator _Type& () const { return *_C_ptr; }
> > +
> > +_Type& get() const { return *_C_ptr; }
>
>4. Function invariants should be asserted wherever possible.
Yep, good point.
>
>5. The definitions of even trivial non-empty functions should
> never appear on the same line as the function signature. I.e.,
> the above should be:
>
> type& get() const {
> _RWSTD_ASSERT (0 != _C_ptr);
> return *_C_ptr;
> }
No problem.
Good suggestions. :)
Brad.
RE: [VOTE] naming convention for variadic template arguments
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 12:17 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [VOTE] naming convention for variadic template arguments
>
> Travis Vitek wrote:
> >
> >
> >> Eric Lemings wrote:
...
> >
> >> In this case, it depends on whether the two parameters are
> actually part
> >> of the same type list. If _TypesT and _Types are actually
> part of the
> >> same type list then they should be named either _TypeT and _TypesT
> >> respectively (or _Type and _Types as shown in #2). If
> they are not part
> >> of the same type list, then they should be named _TypeT and _TypesU
> >> (similar to #4).
>
> This makes sense. The only potential problem is that (I suspect)
> it may not necessarily be known at the point of the declaration
> of every template whether the types are related or not (just like
> an InputIterator in some container member function templates may
> not be an iterator at all but size_type). But that case can be
> handled by simply assuming that the types are related (analogous
> to the InputIterator case).
That's a slightly different case. This parameter, whether it is an
iterator or an offset type, is still separate from the other parameters.
In the variadic template case (e.g. _Head, _Tail...), the parameters
are logically the same template parameter; that is, they are actually
part of the same type list and only named separately to to implement
the variadic template.
>
...
>
> I realize the convention I proposed has at least one other
> shortcoming in that it doesn't scale to member templates:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> To account for this, taking into account the existing convention
> (and assuming your _TTypes was really meant to be _TypesT), the
> generic case would look like so:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> Applying Brad's proposal (if I understand it correctly) to related
> types, we'd have this:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> and for unrelated types this:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> Does this look okay to everyone?
Uhm, that depends. :)
Are you proposing that we are limited only to these specific names or to
this naming _pattern_? (I would prefer to specify conventions --
especially new conventions -- as patterns rather than limiting them to
specific rules.)
In other words, I (prefer to) only use the name "Type" (or "TypeT") when
the template parameter can actually be any type: no requirements, no
restrictions. If, for example, the template parameter must be an
integral type, would the following naming conventions for variadic
templates also apply?
For type lists:
template
struct Parent {
template
Child {
template
Grandchild { };
};
};
For types other than type lists:
template
struct Parent {
template
Child {
template
Grandchild { };
};
};
If we are proposing this pattern as a naming convention for variadic
template parameters, then I would find that acceptable.
Brad.
User-defined compiler flags
What is the proper build procedure for specifying additional user-defined compiler flags? Thanks, Brad.
RE: [VOTE] naming convention for variadic template arguments (was: Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.
This mean you're quiting SourcePro/Rogue Wave but and starting work on STDCXX now that know one can tell you otherwise? :P > -Original Message- > From: Liviu Nicoara [mailto:[EMAIL PROTECTED] > Sent: Friday, June 27, 2008 3:10 PM > To: dev@stdcxx.apache.org; dev@stdcxx.apache.org > Subject: RE: [VOTE] naming convention for variadic template > arguments (was: Re: svn commit: r668318 - in > /stdcxx/branches/4.3.x: include/rw/_tuple.h > include/rw/_tuple_traits.h include/tuple > tests/utilities/20.tuple.cnstr.cpp) > > > -Original Message- > > From: Martin Sebor on behalf of Martin Sebor > > Sent: Fri 6/27/2008 3:05 PM > > To: dev@stdcxx.apache.org > > Subject: [VOTE] naming convention for variadic template > arguments (was: Re: svn commit: r668318 - in > /stdcxx/branches/4.3.x: include/rw/_tuple.h > include/rw/_tuple_traits.h include/tuple > tests/utilities/20.tuple.cnstr.cpp) > > > > This thread kind of fizzled out so let me resurrect it and reiterate > > the proposed naming convention to follow unless more specific names > > are appropriate: > > > > template # 1 > > > > [...] > > Check the box below to vote: > > > > [x] In favor (of #1) > [ ] Opposed (suggest an improvement and rationale) > > -L >
RE: [VOTE] naming convention for variadic template arguments (was: Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Friday, June 27, 2008 3:05 PM > To: dev@stdcxx.apache.org > Subject: [VOTE] naming convention for variadic template > arguments (was: Re: svn commit: r668318 - in > /stdcxx/branches/4.3.x: include/rw/_tuple.h > include/rw/_tuple_traits.h include/tuple > tests/utilities/20.tuple.cnstr.cpp) > > This thread kind of fizzled out so let me resurrect it and reiterate > the proposed naming convention to follow unless more specific names > are appropriate: > > template # 1 > > This is in contrast to other styles, including: > > template # 2 > template # 3 > template # 4 > > The rationale for the proposed convention (#1) is that: > >A) unlike the alternatives, the first name (_TypeT) follows > a well-established and entrenched convention for template > parameters used throughout the library >B) also unlike the alternatives, it is being used in the > implementation of >C) unlike (#2) (although not as well as #3) it more clearly > distinguishes between the name of the first parameter and > the parameter pack > > Check the box below to vote: > >[ ] In favor >[x] Opposed (suggest an improvement and rationale) In this case, it depends on whether the two parameters are actually part of the same type list. If _TypesT and _Types are actually part of the same type list then they should be named either _TypeT and _TypesT respectively (or _Type and _Types as shown in #2). If they are not part of the same type list, then they should be named _TypeT and _TypesU (similar to #4). In any case, a plural name should implicitly denote a template parameter pack (which actually should rule out #3 even though I've already been using it). :P Brad.
Does this compile?
Anyone else getting compile errors with this? #include #include Brad.
RE: spacing suggestion for new code
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Friday, June 27, 2008 10:16 AM > To: dev@stdcxx.apache.org > Subject: RE: spacing suggestion for new code > > ... > > As long as the number of lines of whitespace doesn't > outnumber the number of lines of 'code', I'm fine with using > multiple lines of whitspace. Other than that, I don't really > have a preference. I think that's an acceptable exception: the number of blanks lines don't exceed the number of lines with code. Brad.
RE: implementation of Unary Traits
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Thursday, June 26, 2008 5:45 PM > To: dev@stdcxx.apache.org > Subject: implementation of Unary Traits > > The implementation of Unary Traits (e.g., is_void) uses explicit > specialization on all four combinations of cv-qualifiers for each > trait (plain, const, volatile, and const volatile). I'm wondering > if the alternative approach of stripping the qualifiers before > "dispatching" to just one explicit specialization has been > considered. The potential advantage of this approach is fewer > declarations, smaller translation units, and thus (presumably) > faster compilation. Though I'm using a relational (binary) type trait, I'm getting warnings because the cv-qualifiers are not being stripped. gcc -c -I/work/stdcxx/branches/4.3.x/include/ansi -D_RWSTDDEBUG -pthread -I/work/stdcxx/branches/4.3.x/include -I/build/stdcxx-4.3.x-15D/include -I/work/stdcxx/branches/4.3.x/tests/include -std=gnu++0x -D_RWSTD_EXT_CXX_0X -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h: In instantiation of '__rw::__rw_is_convertible_impl': /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:93: instantiated from '__rw::__rw_is_convertible_3' /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:122: instantiated from '__rw::__rw_is_convertible_2' /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:145: instantiated from '__rw::__rw_is_convertible_1' /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:163: instantiated from '__rw::__rw_is_convertible' /work/stdcxx/branches/4.3.x/include/tuple:68: instantiated from 'std::tuple::_C_is_compatible' /work/stdcxx/branches/4.3.x/include/tuple:123: instantiated from 'std::tuple<_Types>::tuple(_TypesU&& ...) [with _TypesU = int, _TypesT = const int]' /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp:103: instantiated from here /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:77: warning: type qualifiers ignored on function return type Brad.
RE: spacing suggestion for new code
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, June 26, 2008 5:21 PM
> To: dev@stdcxx.apache.org
> Subject: spacing suggestion for new code
>
> While reviewing all the new code that's been added I'm finding it
> difficult to spot where one namespace-scope definition ends and
> another starts because the spacing between them (the number of
> newlines) is the same as the spacing between members, namely 1
> blank line. I find code easier to read when namespace scope
> definitions of functions and classes that span more than one
> line are separated by two blank lines.
>
> Existing code likely isn't completely consistent in this regard,
> and I'm sure examples of both styles could be found, but I'd like
> to think the two-line style is prevalent. Either way, in the
> interest of readability, I'd like to suggest that we adopt the
> two-line spacing style for all new code. Yes?
That's my general preference as well. I prefer to use two lines to
separate unrelated logical groups. If the groups are related, I'll use
1 line to separate them. Within a logical group, I do not use any blank
lines.
In the case of namespaces, I'd use 2 blank lines to separate the
namespace from its non-namespace members though I would use only 1 blank
line to separate the namespace from nested namespaces.
namespace A {
namespace B {
class T;
} // namespace B
enum { E = 1 };
} // namespace A
Brad.
RE: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, June 26, 2008 2:12 PM
> To: dev@stdcxx.apache.org
> Subject: Re: __rw_and (Was RE: Some internal aliases for
> __rw_integral_constant?)
>
> Eric Lemings wrote:
> >
> >
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> >> Sent: Thursday, June 26, 2008 12:32 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: Re: __rw_and (Was RE: Some internal aliases for
> >> __rw_integral_constant?)
> >>
> > ...
> >> I can't say I understand this use case. What's S meant to
> represent?
> >
> > That was just a contrived example; not intended to be realistic.
>
> Sorry, but I find it difficult to think about the utility of a feature
> without a realistic example.
Understandable. Hmm, I can't think of a realistic example off hand for
the explicit/finite context.
The ones I have for the variadic contexts though are in fact used in the
tuple code I'm writing.
>
...
> >
> >> template
> >> struct S:
> >> __rw_conditional<__rw_is_class::value && 0 !=
> I, T, ???>
> >> { };
> >>
> >> (Or enable_if instead of conditional, depending on what you want
> >> to do with S).
> >>
> >>> template struct O {
> >>> template struct I
> >>> : __rw_and::value...> {}; //
> >>> variable arguments
> >> Same here.
> >
> > Try writing that without __rw_and. :) I did. Well, tried
> at least.
> > It is NOT easy. In fact, this was the main reason I wrote
> the __rw_and
> > class template to begin with.
>
> I would if I knew what I is supposed to be/do.
"Given two type lists T and U (such as variadic template arguments),
determine a.) if the length of the type lists is the same, and b.) for
each pair of types Ti and Ui where 0 <= i <= sizeof... (T), type Ui is
convertible to type Ti."
Not easy an easy problem to solve (if at all) without variadic
templates.
>
> >
> >>> };
> >>>
> >>> The other reason is portability. Case in point. Travis
> >> recently ran
> >>> into a problem where the compiler rejected a simple
> >> constant expression
> >>> like `sizeof (T) < sizeof (U)' but worked with the metafunction
> >>> equivalent of `__rw_less_than::value'.
> >> This sounds like an argument for __rw_less_than, not for __rw_and.
> >>
> >> Btw., I'm not opposed to __rw_and in principle. I just want to see
> >> some of its uses and the rationale for it (in case there's a better
> >> or simpler way of doing the same thing).
> >
> > The "is_convertible" use case is the best rationale for it
> that I can
> > think of.
>
> std::is_convertible? But that doesn't make use of anything that
> resembles __rw_and.
I meant the __rw_and use case that employed is_convertible as terms in
the logical expression.
>
> > Such metafunctions essentially allow type traits to be used
> > on type _lists_ rather than individual types; e.g.,
> >
> > template
> > struct all_integral_types
> > : __rw_and::value...> {};
> >
> > I dunno 'bout you, but I think that's pretty darn cool. :)
> Oh, and a
> > lot simpler than the alternative. (I'm not convinced there even is
> > one.)
>
> Is this the alternative you're looking for?
>
> template
> struct all_integral_types;
>
> template
> struct all_integral_types: is_integral { };
>
> template
> struct all_integral_types
> : const_integral::value
> &&
> all_integral_types::value>
> { };
Yes, that's type kind of code that this is meant to simplify: writing
one template rather than three.
Also, I was referring to alternatives for binary (relational) type
traits.
Brad.
RE: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, June 26, 2008 12:32 PM
> To: dev@stdcxx.apache.org
> Subject: Re: __rw_and (Was RE: Some internal aliases for
> __rw_integral_constant?)
>
...
>
> I can't say I understand this use case. What's S meant to represent?
That was just a contrived example; not intended to be realistic.
> It looks like some sort of a type trait. If so, why isn't plain &&
> sufficient?
Portability. As I said, some compilers have problems evaluating certain
expressions at compile-time without metafunction wrappers.
>
> template
> struct S:
> __rw_conditional<__rw_is_class::value && 0 != I, T, ???>
> { };
>
> (Or enable_if instead of conditional, depending on what you want
> to do with S).
>
> >
> > template struct O {
> > template struct I
> > : __rw_and::value...> {}; //
> > variable arguments
>
> Same here.
Try writing that without __rw_and. :) I did. Well, tried at least.
It is NOT easy. In fact, this was the main reason I wrote the __rw_and
class template to begin with.
>
> > };
> >
> > The other reason is portability. Case in point. Travis
> recently ran
> > into a problem where the compiler rejected a simple
> constant expression
> > like `sizeof (T) < sizeof (U)' but worked with the metafunction
> > equivalent of `__rw_less_than::value'.
>
> This sounds like an argument for __rw_less_than, not for __rw_and.
>
> Btw., I'm not opposed to __rw_and in principle. I just want to see
> some of its uses and the rationale for it (in case there's a better
> or simpler way of doing the same thing).
The "is_convertible" use case is the best rationale for it that I can
think of. Such metafunctions essentially allow type traits to be used
on type _lists_ rather than individual types; e.g.,
template
struct all_integral_types
: __rw_and::value...> {};
I dunno 'bout you, but I think that's pretty darn cool. :) Oh, and a
lot simpler than the alternative. (I'm not convinced there even is
one.)
Brad.
Unnamed template parameters
Anyone recall if some compilers might have problems and/or issue warnings about unnamed template parameters? E.g., template struct S; Or is this safe practice? Brad.
RE: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, June 26, 2008 11:31 AM
> To: dev@stdcxx.apache.org
> Subject: Re: __rw_and (Was RE: Some internal aliases for
> __rw_integral_constant?)
>
...
>
> Maybe I misunderstood the purpose of the __rw_and template. I wasn't
> asking to see a solution w/o variadic templates, but one without
> __rw_and. If I understand your response correctly, you're proposing
> to add __rw_and to hide the dual implementation of ANDing variable
> numbers of constraints, one with variadic templates and the other
> without. I.e., __rw_and would be more than just syntactic sugar.
> Correct?
Yes, simplifying compile-time expressions by using it in either context
would be one reason, e.g.:
template
struct S :
__rw_and, 0 != I> {}; // explicit/finite
arguments
template struct O {
template struct I
: __rw_and::value...> {}; //
variable arguments
};
The other reason is portability. Case in point. Travis recently ran
into a problem where the compiler rejected a simple constant expression
like `sizeof (T) < sizeof (U)' but worked with the metafunction
equivalent of `__rw_less_than::value'.
Brad.
RE: !ERROR! from gcc 4.3?
NVM. I found it.
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2008 11:24 AM
> To: dev@stdcxx.apache.org
> Subject: !ERROR! from gcc 4.3?
>
>
> Any idea why the GCC 4.3 preprocessor is translating this:
>
> template
> class reference_wrapper
> {
> _Type* _C_ptr;
>
> public:
>
> typedef _Type type;
> ...
>
> to this:
>
> template
> class reference_wrapper
> {
> _Type* _C_ptr;
>
> public:
>
> typedef _Type !ERROR!;
> ...
>
> Brad.
>
!ERROR! from gcc 4.3?
Any idea why the GCC 4.3 preprocessor is translating this:
template
class reference_wrapper
{
_Type* _C_ptr;
public:
typedef _Type type;
...
to this:
template
class reference_wrapper
{
_Type* _C_ptr;
public:
typedef _Type !ERROR!;
...
Brad.
RE: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Thursday, June 26, 2008 9:45 AM > To: dev@stdcxx.apache.org > Subject: Re: __rw_and (Was RE: Some internal aliases for > __rw_integral_constant?) > > Eric Lemings wrote: > > > [...] > > Okay, another proposal for inclusion though this particular utility > > may be a stretch unless you understand variadic templates very well. > > Can you show what the code looks like w/o __rw_and for comparison? I could try but you would want to read it about as much as I would want to write it. :) Basically, it would require all the hackery required for simulating variadic templates. Not pretty. > > In general, an important design principle behind stdcxx is efficiency, > both in time and in space. And in terms of time, both compilation as > well runtime efficiency is important. In contrast to the ordinary > kind, template metaprogramming tends to increase compilation times > much more noticeably. In C++ 0x a good amount metaprogramming code > is dictated by the standard already but as a rule we need exercise > restraint when introducing templatized helper code, especially > when template recursion is involved. Right. The way I see it, utilities like this are indended to simplify the required metaprogramming code. In order to do that though, other developers would have to reuse it. :) That's why I said at the bottom of the email that I'll probably hold off on moving it up the chain of includes to a more generic header where it would be more reusable until such a time when other developers find more need for it. (I doubt tuples will be the only place requiring compile-time logical operators.) But it's posted now so we're all aware of it at least. BTW, is template recursion really costly in terms of compile times? Brad.
RE: 22.locale.codecvt.out test failure
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 25, 2008 5:26 PM > To: dev@stdcxx.apache.org > Subject: 22.locale.codecvt.out test failure > > > The named test fails on all platforms with an EXEC error. It > looks like > the problem is that when trying to build the executable > '22.locale.codecvt.out', it actually generates an output file for the > test '22.locale.codecvt', which is obviously not going to be > executable. > > $ gmake 22.locale.codecvt.out > gcc -c -I/amd/devco/vitek/stdcxx/trunk/include/ansi -D_RWSTDDEBUG > -I/amd/devco/vitek/stdcxx/trunk/include > -I/build/vitek/5.0.0/11S/include > -I/amd/devco/vitek/stdcxx/trunk/tests/include -pedantic > -nostdinc++ -g > -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long > -Wcast-align > /amd/devco/vitek/stdcxx/trunk/tests/localization/22.locale.codecvt.cpp > gcc 22.locale.codecvt.o -o 22.locale.codecvt > -L/build/vitek/5.0.0/11S/rwtest -lrwtest11S > -L/build/vitek/5.0.0/11S/lib -lstd11S -lsupc++ -lm > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/build/vitek/5.0.0/11S/lib > ./22.locale.codecvt >22.locale.codecvt.out 2>&1 > > I know this worked at one time because I was involved in the > discussion > for fixing this problem the last time it came up > [http://tinyurl.com/5nv7qx]. > > Any ideas why this problem is back to haunt us? My guess would be a suffix rule for *.out files. Somehow the suffix rule is pulling in 22.locale.codecvt which IIRC is a completely different test. Brad.
RE: svn commit: r669723 - in /stdcxx/branches/4.3.x: include/rw/_meta_cv.h include/rw/_tuple.h include/tuple tests/utilities/20.tuple.elem.cpp
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 25, 2008 2:10 PM
> To: dev@stdcxx.apache.org
> Subject: RE: svn commit: r669723 - in /stdcxx/branches/4.3.x:
> include/rw/_meta_cv.h include/rw/_tuple.h include/tuple
> tests/utilities/20.tuple.elem.cpp
>
>
...
>
> >+template
> >+_TYPENAME tuple_element<_Index, tuple<_Head, _Tail...> >::_Ref
> >+get (tuple<_Head, _Tail...>& __tuple)
> >+{
> >+typedef tuple_element<_Index, tuple<_Head, _Tail...> > _Tuple;
> >+return _Tuple::__get (__tuple);
> >+}
> >+
> >+template
> >+_TYPENAME tuple_element<_Index, tuple<_Head, _Tail...> >::_ConstRef
> >+get (const tuple<_Head, _Tail...>& __tuple)
> >+{
> >+typedef tuple_element<_Index, tuple<_Head, _Tail...> > _Tuple;
> >+return _Tuple::__get (__tuple);
> >+}
>
> I just noticed LWG775. We should probably consider adopting
> the proposed
> reslution.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775
Noted. Thanks for the link.
Brad.
RE: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 25, 2008 11:41 AM
> To: dev@stdcxx.apache.org
> Subject: __rw_and (Was RE: Some internal aliases for
> __rw_integral_constant?)
>
>
>
> > -Original Message-
> > From: Eric Lemings [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 24, 2008 6:01 PM
> > To: dev@stdcxx.apache.org
> > Subject: RE: Some internal aliases for __rw_integral_constant?
> >
> >
> >
> > > -Original Message-
> > > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> > Martin Sebor
> > > Sent: Tuesday, June 24, 2008 5:11 PM
> > > To: dev@stdcxx.apache.org
> > > Subject: Re: Some internal aliases for __rw_integral_constant?
> > >
> > > Eric Lemings wrote:
> > > >
> > > > Propose adding the following defs (or something similar) to
> > > > primarily for our own convenience:
> > > >
> > > > template
> > > > class __rw_bool_const: public __rw_integral_constant > > _Bool> {};
> > >
> > > I was going to suggest the same thing this morning when I noticed
> > > how pervasive __rw_integral_constant seems to be in
> > > traits definitions (I count 41 occurrences) and thinking that it
> > > would make them less verbose. (With a different spelling of _Bool
> > > to avoid potential clashes with the C99 name.)
> >
> > Good point.
> >
> > >
> > > I didn't because the only beneficiaries of the change would be us
> > > (a fairly small notational convenience) and I wasn't sure the cost
> > > in terms of the added complexity and compilation time was
> worth it.
> > > I contemplated suggesting a macro for the same purpose instead but
> > > decided against it on the assumption that it probably wouldn't be
> > > very popular ;-) But now that the cat's out of the bag and you're
> > > asking about alternatives let me throw it out there:
> > >
> > > #define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constant
> > >
> > > Usage:
> > >
> > > _RW::__rw_bool_const
> > >vs
> > > _RWSTD_BOOL_CONST (false)
> > >
> >
> > Looks good to me. I'll just add _RWSTD_BOOL_CONST for now.
>
> Okay, another proposal for inclusion though this particular utility
> may be a stretch unless you understand variadic templates very well.
>
> template
> struct __rw_and;
>
> template <>
> struct __rw_and<>: std::true_type {};
>
> template
> struct __rw_and<_Bool0, _BoolN...>
> : _RWSTD_BOOL_CONST (_Bool0 && __rw_and<_BoolN...>::value)
> {};
Actually that should probably be something like:
: std::conditional<_Bool0, __rw_and<_BoolN...>,
std::false_type>
Assuming the compiler isn't smart enough to short-circuit such
instantiations already.
Brad.
__rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2008 6:01 PM
> To: dev@stdcxx.apache.org
> Subject: RE: Some internal aliases for __rw_integral_constant?
>
>
>
> > -Original Message-
> > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> > Sent: Tuesday, June 24, 2008 5:11 PM
> > To: dev@stdcxx.apache.org
> > Subject: Re: Some internal aliases for __rw_integral_constant?
> >
> > Eric Lemings wrote:
> > >
> > > Propose adding the following defs (or something similar) to
> > > primarily for our own convenience:
> > >
> > > template
> > > class __rw_bool_const: public __rw_integral_constant > _Bool> {};
> >
> > I was going to suggest the same thing this morning when I noticed
> > how pervasive __rw_integral_constant seems to be in
> > traits definitions (I count 41 occurrences) and thinking that it
> > would make them less verbose. (With a different spelling of _Bool
> > to avoid potential clashes with the C99 name.)
>
> Good point.
>
> >
> > I didn't because the only beneficiaries of the change would be us
> > (a fairly small notational convenience) and I wasn't sure the cost
> > in terms of the added complexity and compilation time was worth it.
> > I contemplated suggesting a macro for the same purpose instead but
> > decided against it on the assumption that it probably wouldn't be
> > very popular ;-) But now that the cat's out of the bag and you're
> > asking about alternatives let me throw it out there:
> >
> > #define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constant
> >
> > Usage:
> >
> > _RW::__rw_bool_const
> >vs
> > _RWSTD_BOOL_CONST (false)
> >
>
> Looks good to me. I'll just add _RWSTD_BOOL_CONST for now.
Okay, another proposal for inclusion though this particular utility
may be a stretch unless you understand variadic templates very well.
template
struct __rw_and;
template <>
struct __rw_and<>: std::true_type {};
template
struct __rw_and<_Bool0, _BoolN...>
: _RWSTD_BOOL_CONST (_Bool0 && __rw_and<_BoolN...>::value)
{};
For example:
template
struct tuple {
template
struct __rw_is_compat
: __rw_and::value...> {
static_assert (sizeof... (_TypesT) == sizeof...
(_TypesU),
"tuple sizes must be equal");
};
};
Here are some quick tests that I tried out on it:
typedef tuple T1;
std::cout << T1::__rw_is_compat::value
<< std::endl;
std::cout << T1::__rw_is_compat::value
<< std::endl;
std::cout << T1::__rw_is_compat::value
<< std::endl;
std::cout << T1::__rw_is_compat::value
<< std::endl;
// fires the static assertion
//std::cout << T1::__rw_is_compat::value
//<< std::endl;
Might just save that one for later but worth posting at least. :)
Brad.
RE: Some internal aliases for __rw_integral_constant?
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, June 24, 2008 5:11 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Some internal aliases for __rw_integral_constant?
>
> Eric Lemings wrote:
> >
> > Propose adding the following defs (or something similar) to
> > primarily for our own convenience:
> >
> > template
> > class __rw_bool_const: public __rw_integral_constant _Bool> {};
>
> I was going to suggest the same thing this morning when I noticed
> how pervasive __rw_integral_constant seems to be in
> traits definitions (I count 41 occurrences) and thinking that it
> would make them less verbose. (With a different spelling of _Bool
> to avoid potential clashes with the C99 name.)
Good point.
>
> I didn't because the only beneficiaries of the change would be us
> (a fairly small notational convenience) and I wasn't sure the cost
> in terms of the added complexity and compilation time was worth it.
> I contemplated suggesting a macro for the same purpose instead but
> decided against it on the assumption that it probably wouldn't be
> very popular ;-) But now that the cat's out of the bag and you're
> asking about alternatives let me throw it out there:
>
> #define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constant
>
> Usage:
>
> _RW::__rw_bool_const
>vs
> _RWSTD_BOOL_CONST (false)
>
Looks good to me. I'll just add _RWSTD_BOOL_CONST for now.
Brad.
Some internal aliases for __rw_integral_constant?
Propose adding the following defs (or something similar) to
primarily for our own convenience:
template
class __rw_bool_const: public __rw_integral_constant {};
template
class __rw_int_const: public __rw_integral_constant {};
template <_RWSTD_SIZE_T _Size>
class __rw_size_const: public __rw_integral_constant<_RWSTD_SIZE_T,
_Size> {};
The name __rw_integral_constant is a bit too long for the amount of
usage that I'm anticipating. Or am I being premature?
Thoughts? Alternatives?
Brad.
RE: svn commit: r662845 - in /stdcxx/branches/4.2.x: examples/include/ examples/tutorial/ tests/iostream/ tests/localization/ tests/regress/ tests/utilities/
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 2:24 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r662845 - in /stdcxx/branches/4.2.x: > examples/include/ examples/tutorial/ tests/iostream/ > tests/localization/ tests/regress/ tests/utilities/ > > [EMAIL PROTECTED] wrote: > > Author: elemings > > Date: Tue Jun 3 10:24:08 2008 > > New Revision: 662845 > > > > URL: http://svn.apache.org/viewvc?rev=662845&view=rev > > Log: > > 2008-06-03 Eric Lemings <[EMAIL PROTECTED]> > > > > STDCXX-550 > [...] > > * tests/utilities/20.operators.cpp (RandomNumberGenerator): > > Change parameter type of RNG from hard-coded `int' to template > > parameter `T'. > > (test_random_access_iterators): Instantiate RNG using difference > > type of iterator rather than value type as specified by > > `random_shuffle' requirements. > [...] > > I suspect this change is causing the test to fail to compile > with HP aCC 3.63 (I haven't checked more recent versions or > other compilers). > > Brad, can you please take a look at it? Yeah it looks like I'll need to add conditional compilation to take debug iterators into account. I'm assuming that's how the compiler is deducing type `int*' from types `std::deque::iterator, std::basic_string::iterator, and std::vector::iterator`. Brad.
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 9:00 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r667636 - > /stdcxx/branches/4.3.x/include/rw/_forward.h > > Eric Lemings wrote: > > > > > >> -Original Message- > >> From: Martin Sebor [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, June 24, 2008 6:55 AM > >> To: dev@stdcxx.apache.org > >> Subject: Re: svn commit: r667636 - > >> /stdcxx/branches/4.3.x/include/rw/_forward.h > >> > >> Eric Lemings wrote: > > ... > >>> BTW, I'm still trying to figure out what it is that you are > >> proposing > >>> exactly. :D > >> We have an established (albeit undocumented) process and > >> infrastructure for documenting code and publishing the > >> documentation. The onus is on you and Travis to come up > >> with a proposal if you want to change how things are done. > > > > I thought I did. To repeat...for the record, write new > documentation > > using Doxygen comments now. Migrate the old HTML docs later. > > Sorry. One sentence doesn't make a proposal, certainly not > one this vague. I can write a 1000 word, detailed proposal in about an hour if that would do any good. In the meantime, most of the details are in the Jira issue. http://issues.apache.org/jira/browse/STDCXX-964 > ... > The current process is to maintain the existing docs in HTML, > using the existing infrastructure to publish the docs on the > site. You want to change it? Fine. Propose in detail how and > when this will change will take place and when we can expect > it to be done. Okay. Brad.
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 6:55 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r667636 - > /stdcxx/branches/4.3.x/include/rw/_forward.h > > Eric Lemings wrote: ... > > BTW, I'm still trying to figure out what it is that you are > proposing > > exactly. :D > > We have an established (albeit undocumented) process and > infrastructure for documenting code and publishing the > documentation. The onus is on you and Travis to come up > with a proposal if you want to change how things are done. I thought I did. To repeat...for the record, write new documentation using Doxygen comments now. Migrate the old HTML docs later. > > So far you've decided on your own, despite my objections > and without establishing consensus, to start adding Doxygen > style comments to new headers, without reconciling the > differences between the existing process and your new one, > and without providing a clear path to such a reconciliation > in the foreseeable future. Hmm. Let me see if I can summarize your objections: 1. You don't like Doxygen. I think that's pretty evident. :) Nothing wrong with that. I think it's the best damn doc tool on the market...but that's just me. But if you know of a better tool and/or format, we're all ears. 2. We shouldn't write any documentation comments because it's not conventional. Convention isn't really the right: this is becoming more like dogma. Travis and I both realize what this means -- breaking with this convention -- moving forward. It's not easy writing docs and code at the same time, and the new code will look different from the older code (for a period of time at least), but it is the right thing to do we believe. > > Unless these issues are satisfactorily resolved and until > there is a viable plan for producing a adequate replacement > for the existing class reference on a reasonable schedule > I have to insist that the Doxygen comments be removed from > the newly added headers. And then what? Hope that the documentation magically appears? I'd be glad to remove it...if you have a better plan, solution, proposal... something in mind. But just removing the documentation comments is not "a clear path to such reconciliation in the foreseeable future" either. It's the absolute last thing we should be contemplating in fact. Brad.
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
On Jun 23, 2008, at 9:31 PM, Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: [...] I gave a number of arguments against Doxygen comments in stdcxx headers: 1) existing code doesn't use it and converting the raw HTML docs to Doxygen is an enormous task that none of us has the time to take on; Doxygenating new code without doing the same for the existing code is inconsistent and won't help us produce end-user documentation for the finished product Since we aren't providing any html documentation for any c++0x code at this time, maybe we should stop using html documentation? :P So the options are-- a) not document the c++0x code at all b) write up documentation for all new code in html to be consistent with what is used currently c) move all existing documentation over to doxygen before a single doxygen comment is added to the new code Assuming we want to have C++ 0x fully documented in 5.0 or shortly thereafter which of (b) and (c) do you think is viable? I don't think any of those choice are viable _in the near term_ but if I had to choose? C. If only to get a better idea of how much work we're really talking about. But I don't think doing that right now is really necessary. I think we all agree, there's too much C++0x work to be done in the near term that virtually prohibits migrating the old HTML docs right now. But that doesn't mean we should not be writing new documentation. ... I know that at Rogue Wave we have an xslt that transforms from doxygen generated xml files to html documentation, so unless using doxygen is totally ruled out, that can be used to bridge between the old html pages and generated ones. Yes, but the transformation isn't fully automated and according to Marc requires quite a bit of human intervention. It's clear that we don't have the bandwidth to take this on and still make our target date. I agree... to a degree. We don't have the bandwidth at present but it is not at all clear (to me at least) how much work this migration will really require. ... For starters, what prevents me from browsing all new Doxygen docs is that there is no generated HTML documentation. I and everyone else would have to install Doxygen and compile the HTML docs ourselves to get the benefit. I don't think there's anything that prevents us from copying and redistributing our own documentation. You only need Doxygen installed if you need to regenerate the docs for some reason. And because the docs aren't being generated and the generated HTML looked they're likely to contain all kinds of formatting problems. I've generated them. And yes, there are formatting problems. ... Doxygen doesn't have to document everything that it sees. There are many ways to control what will be documented. You can tell it to only generate documentation for things that have doxygen style comments or you can mark things as internal so the documentation can be conditionally disabled. I've seen the libstdc++ documentation (see below) and talked to the project's maintainers. My understanding is that they're not completely happy with it for some of the same reasons I've raised here and are considering (or maybe even working on) migrating away from Doxygen to some other tool/format. A better tool/format than Doxygen? Wow. I'd be interested in reading that thread of discussion! Link? BTW, I'm still trying to figure out what it is that you are proposing exactly. :D Brad.
