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.
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
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? Another important point is that the stdcxx project doesn't have anyone volunteering time to write documentation. If we want the documentation, we're likely going to have to do it ourselves, and I find using doxygen comments _much_ simpler than writing html. I agree. But that won't help us migrate the reams of existing docs to Doxygen. Without the migration I see no point in documenting new code in one format and old code in another. A substantial amount of C++ 0x code will also involve changing the old code (such as adding new member functions to containers or adding requirements clauses). We can't very well document these changes in Doxygen and leave the existing HTML docs unchanged. 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. 2) Doxygen markups are harder to read than ordinary comments (see 3), and in the library headers the volume of such comments will, in many cases, dwarf the amount of code If the code is well written, comments are usually reserved for situations where they are necessary to describe what the code is actually supposed to be doing. Most frequently this type of comment would be found in the body of a function definition. Doxygen comments, on the other hand, usually appear with the declarations, so the type of comments that you would usually need to read aren't necessarily in the same place as the doxygen comments. Additionally, your editor can likely be configured to hide the doxygen comments if you don't want to see them. I've seen Doxygen comments. A simple example of the differences is the recently added Doxygenized documentation of the rw_prinf() format specifiers vs what we had before. I find the original raw text comments much more readable than the only moderately heavily marked up replacement. As for readability, consider this. There are currently no comments describing what a given library class or function is expected to do. If you want to see what the expected behavior is, you get to walk yourself through the implementation, or you get to fire up a web browser and look at the html documentation. If the documentation is added as doxygen comments, they are in the code. They may be slightly less readable than plain english text due to the additional markup, but there is _nothing_ that is stopping you from looking to the implementation or firing up a web browser like you did before. 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. And because the docs aren't being generated and the generated HTML looked they're likely to contain all kinds of formatting problems. 3) unless/until there is infrastructure to generate the HTML docs from the Doxygen comments documenting the library (or other parts of stdcxx) using Doxygen markups serves no purpose Which would you like first, the chick or the egg? The infrastructure will never be built to generate html documentation from doxygen comments if we don't have doxygen comments to generate documentation from. FYI: We've had Doxygen comments in place for parts of the test driver (including the whole exec utility) in place for two years now. No one has had the time or the energy to set things up. I don't see anyone stepping up and tackling any of the open documentation issues, including STDCXX-964. But to answer your question, I believe the infrastructure to generate the docs must be in place first, just like build infrastructure needs to exist before any non-trivia
Re: tests/utilities/20.meta.help.cpp
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Eric Lemings wrote:
Just a brief side note. I was just reviewing this test and
noticed that
pointers are not tested though they are valid scalar types
suitable for
use as integral_constant parameters. I think references
may be valid
parameters also.
I'm not sure.
The first thing that jumps to mind is that a pointer is not of
'integral' type. An enumeration isn't really an integral type either,
but they are implicitly convertible to one. Pointers aren't
convertible
to integral type without a cast.
According to temp.arg.nontype, a non-type, non-template template
parameter must be one of
-- an integral constant expression
-- the name of a non-type template-parameter
-- the address of an object or function with external linkage...
-- a constant expression that evaluates to a null pointer value
-- a constant expression that evaluates to a null member
pointer value
-- a pointer to member
So, yes, it is legal to use a pointer as a non-type template
parameter.
The issue I have is that the integral_constant is supposed to
define an integral constant of type T with value V. Section
expr.const
says that a constant expression is an integral constant
expression if it
is of integral or enumeration type. An integral constant
expression can
be used as an array bound, a case expression, a bit field length,
enumeration initializer, static member initializer and as integral or
enumeration non-type template arguments.
I'm pretty sure you can't use a pointer value as an array bound, case
expression, bit field length or enumeration initializer, so
they aren't
really integral constants.
So I am sure you can instantiate std::integral_constant(class_t::*)(), &class::method>, but I'm not sure if it
something that
should be tested.
If there's an implementation technique that would make the
instantiation ill-formed then I think it should be tested.
According to class.mem (p4) and class.static.data (p4) you aren't
allowed to initialize static members using a constant-initializer (i.e.
in the member declaration) if they are not of const integral or const
enumeration type. So the above instantiation on member pointer should be
prevented by the compiler. A quick test with msvc-8.0 and gcc-4.3 show
that this is the case.
Good point!
The following would be legal, but I'm already testing integral constants
for all integral types and an enum type, so I think I'm covered.
More important, though, the standard should specify the
requirements on the template arguments. If there are no
such requirements for something as fundamental as
integral_const, either in the latest working draft or
in one of the concepts papers (such as N2622), we should
at least bring it up on the list and/or open an issue to
have the spec clarified.
The standard does specify the requirements of the template arguments,
but only through association (to be an integral constant member, it has
to be a const static that is initialized with a constant-initializer,
Is this specified anywhere else besides the definition of the
class in [meta.help]? If not, I'm not sure that every detail
of a class definition shown in the spec qualifies as a normative
requirement.
and a constant initializer only works for enum and integral types). Is
this significant enough to warrant bringing up an issue?
IMO, the class should have an explicit requirement on the first
template argument. If there isn't one I would propose adding
paragraph 2 with the text:
-2- The template parameter T shall have an integral type (3.9.1).
integral_constant::value shall be a integral constant
expression (5.19).
With concepts, we would change the definition of the class like
this (I think):
template
struct integral_constant {
// ...
};
Strangely, this isn't in N2625:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2625.pdf
Incidentally, it also seems to me that value should be declared
constexpr (both in our implementation and in the spec).
Travis
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
Eric Lemings wrote: [...] Please follow the established convention and drop the spaces before class and before the closing pointy brace. Thanks! :) It would be a lot easier if these conventions were actually ESTABLISHED. Until they are established, we're going to be constantly running into this problem. Don't you agree? They are fully established (grep for "< class" vs " I can start a Wiki page for this unless you'd prefer to do it. Starting a page on coding style sounds like a great idea. [...] +template < class _HeadT, class... _TailT > In the interest of consistency we should adopt the same naming convention for the names of variadic template parameters. We have _TypeT and and Types in traits, _HeadT and _TailT here, and TTypes and UTypes in the standard. Which one should it be? It is my opinion that the T and U prefixes/suffixes are only necessary in binary contexts; i.e. where there are two different types or type lists. That may be the case but... Otherwise, we should use just a plain "Type" name. ...we have an established convention that has the T at the end. I'm opposed to using different conventions for new vs existing code and I see no compelling reason to change the thousands of lines of existing code to conform to a different convention. What I'd like us to do is establish a convention to use for variadic templates. The convention that makes the most sense to me is one that builds on the existing convention for ordinary (non-variadic) templates. Of the three choices that I gave initially: template // in type traits template // in tuple template // in the spec the one that fits the bill is the first one: template We can tweak the name of the parameter pack but I don't see how we can change the name of the first parameter without deviating from the current convention. Furthermore, generic "Type" names should only be used in truly generic contexts; i.e. contexts where just about any type can be used. Otherwise, the name should imply the restrictions/requirements on the type; e.g. _ScalarType, _IntConst. In the recursive tuple case, using generic names would make the code much harder to follow IMHO. For the non-variadic case this is quite elegantly handled by concepts. For example, the new variadic function template std::min() currently declared in the working paper like so: template const T& min (const T& a, const Args&... args); becomes: template requires SameType const T& min (const T& a , const Args&... args); [...] +template +_TYPENAME tuple_element<_Index, tuple<_Types...> >::type const& The const should come before tuple_element. For style? They are semantically equivalent though, aren't they? BTW, this is how it is specified in the draft. Yes, we discussed consistency at the last meeting. IIUC, the editor is going to make the appropriate changes to bring the new text into accord with the existing convention (i.e., change "T const&" to "const T&"). Martin
Re: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
Eric Lemings wrote:
-Original Message-
From: Travis Vitek [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2008 4:59 PM
To: dev@stdcxx.apache.org
Subject: RE: svn commit: r668225 -
/stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
Eric Lemings wrote:
Martin Sebor wrote:
My point was that I couldn't find a way to use a feature
that depends on variadic macros on platforms where they
are not supported. In other words, I can't picture what
the #else branch below would look like:
#ifndef _RWSTD_NO_VARIADIC_MACROS
# define RW_ASSERT(expr, ...) \
rw_assert (expr, 0, __LINE__, __VA_LIST__)
#else
# define RW_ASSERT(expr, ???) ...
#endif
You're right. There is no backward-compatible workaround which
essentially rules out using variadic macros in these cases.
Which is why I don't think we'll be able to (or need to) use the
config macro in our code.
I think I've showed this trick before, but it won't work with template
parameters, only function parameters.
Right. This "trick" obviates the need for variadic macros in the
case of the rw_xxx() functions.
(Note that the trick isn't a general replacement for variadic macros
because it relies on a runtime mechanism while variadic macros are
a compile-time one.)
struct Variadic
{
void operator()(const char* fmt, ...);
};
#define VARIADIC Variadic().operator()
Of course you would use it like this...
VARIADIC("hello %s", "world!");
Had forgotten about that. :)
So, we have something like this:
There's no need for the additional complexity when we can just use
the #else case unconditionally. The !_RWSTD_NO_VARIADIC_MACROS case
provides no advantage over the workaround.
#ifndef _RWSTD_NO_VARIADIC_MACROS
# define RW_ASSERT(expr, ...) \
rw_assert (expr, 0, __LINE__, __VA_LIST__)
#else
struct __rw_assert {
int operator()(int expr, const char* file, int line,
const char* fmt, ...) {
va_list va;
va_start (va, fmt);
_rw_vdiag (diag_assert, 0 == expr, file, line, fmt, va);
va_end (va);
return success;
}
};
# define RW_ASSERT __rw_assert().operator()
#endif
That pretty close?
And why is there a 2nd parameter in rw_assert() if its never used? :P
Brad.
RE: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2008 4:59 PM
> To: dev@stdcxx.apache.org
> Subject: RE: svn commit: r668225 -
> /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
>
>
>
> >Eric Lemings wrote:
> >
> >> Martin Sebor wrote:
> >>
> >>
> >> My point was that I couldn't find a way to use a feature
> >> that depends on variadic macros on platforms where they
> >> are not supported. In other words, I can't picture what
> >> the #else branch below would look like:
> >>
> >>#ifndef _RWSTD_NO_VARIADIC_MACROS
> >># define RW_ASSERT(expr, ...) \
> >> rw_assert (expr, 0, __LINE__, __VA_LIST__)
> >>#else
> >># define RW_ASSERT(expr, ???) ...
> >>#endif
> >
> >You're right. There is no backward-compatible workaround which
> >essentially rules out using variadic macros in these cases.
> >
>
> I think I've showed this trick before, but it won't work with template
> parameters, only function parameters.
>
> struct Variadic
> {
> void operator()(const char* fmt, ...);
> };
>
> #define VARIADIC Variadic().operator()
>
> Of course you would use it like this...
>
> VARIADIC("hello %s", "world!");
Had forgotten about that. :)
So, we have something like this:
#ifndef _RWSTD_NO_VARIADIC_MACROS
# define RW_ASSERT(expr, ...) \
rw_assert (expr, 0, __LINE__, __VA_LIST__)
#else
struct __rw_assert {
int operator()(int expr, const char* file, int line,
const char* fmt, ...) {
va_list va;
va_start (va, fmt);
_rw_vdiag (diag_assert, 0 == expr, file, line, fmt, va);
va_end (va);
return success;
}
};
# define RW_ASSERT __rw_assert().operator()
#endif
That pretty close?
And why is there a 2nd parameter in rw_assert() if its never used? :P
Brad.
RE: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
>Eric Lemings wrote:
>
>> Martin Sebor wrote:
>>
>>
>> My point was that I couldn't find a way to use a feature
>> that depends on variadic macros on platforms where they
>> are not supported. In other words, I can't picture what
>> the #else branch below would look like:
>>
>>#ifndef _RWSTD_NO_VARIADIC_MACROS
>># define RW_ASSERT(expr, ...) \
>> rw_assert (expr, 0, __LINE__, __VA_LIST__)
>>#else
>># define RW_ASSERT(expr, ???) ...
>>#endif
>
>You're right. There is no backward-compatible workaround which
>essentially rules out using variadic macros in these cases.
>
I think I've showed this trick before, but it won't work with template
parameters, only function parameters.
struct Variadic
{
void operator()(const char* fmt, ...);
};
#define VARIADIC Variadic().operator()
Of course you would use it like this...
VARIADIC("hello %s", "world!");
Travis
>Brad.
>
RE: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2008 3:50 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r668225 - > /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp > > Eric Lemings wrote: > > > > > >> -Original Message- > >> From: Martin Sebor [mailto:[EMAIL PROTECTED] > >> Sent: Monday, June 23, 2008 2:10 PM > >> To: dev@stdcxx.apache.org > >> Subject: Re: svn commit: r668225 - > >> /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp > >> > >> [EMAIL PROTECTED] wrote: > >>> Author: elemings > >>> Date: Mon Jun 16 09:31:03 2008 > >>> New Revision: 668225 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=668225&view=rev > >>> Log: > >>> 2008-06-16 Eric Lemings <[EMAIL PROTECTED]> > >>> > >>> STDCXX-958 > >>> * etc/config/src/VA_LIST_FUNC_MACRO.cpp: Initial version of > >>> configuration check for va-list function macros. > >> Out of curiosity, what do you expect to use this for? (FWIW, > >> I've often wished variadic macros were supported in C++ > >> compilers but I could never come up with a workaround for > >> their absence, making them essentially unusable as a general > >> purpose feature.) > > > > The most obvious use would be in RWTest printf-like functions. > > > > I'm not sure how well variadic function macros mesh with variadic > > templates but, if they do, I could take advantage of the feature > > in tuples. > > My point was that I couldn't find a way to use a feature > that depends on variadic macros on platforms where they > are not supported. In other words, I can't picture what > the #else branch below would look like: > >#ifndef _RWSTD_NO_VARIADIC_MACROS ># define RW_ASSERT(expr, ...) \ > rw_assert (expr, 0, __LINE__, __VA_LIST__) >#else ># define RW_ASSERT(expr, ???) ... >#endif You're right. There is no backward-compatible workaround which essentially rules out using variadic macros in these cases. Brad.
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 [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2008 3:02 PM
> To: dev@stdcxx.apache.org
> Subject: 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
>
> [EMAIL PROTECTED] wrote:
> > Author: elemings
> > Date: Mon Jun 16 14:16:48 2008
> > New Revision: 668318
> >
> > URL: http://svn.apache.org/viewvc?rev=668318&view=rev
> > Log:
> > 2008-06-16 Eric Lemings <[EMAIL PROTECTED]>
> >
> > STDCXX-958
> > * include/tuple, include/rw/_tuple.h,
> include/rw/_tuple_traits.h:
> > Add initial version of headers defining tuple interface and
> > implementation. (Only tested on Linux/gcc-4.3
> platforms so far.)
> > * tests/utilities/20.tuple.cnstr.cpp: Rough outline of first
> > tuple test program.
> >
> [...]
> > +#if !defined _RWSTD_NO_VARIADIC_TEMPLATES
> > +
> > +
> > +_RWSTD_NAMESPACE (std) {
> > +
> > +
> > +// 20.3.1, class template tuple:
> > +
> > +/**
> > + * @defgroup tuple Tuples [tuple]
> > + *
> > + * A fixed-size collection of values with variable,
> heterogenous types.
> > + * This class template is used to instantatiate tuple
> types. A tuple
> > + * type specifies zero or more element types for defining
> tuple values.
> > + * A tuple value can be constructed from a tuple type that
> holds one
> > + * value for each element type in the tuple.
> > + *
> > + * @param Types A list of zero or more types. No applicable type
> > + * requirements or restrictions.
> > + */
> > +template < class... Types >
>
> Please follow the established convention and drop the spaces
> before class and before the closing pointy brace. Thanks! :)
It would be a lot easier if these conventions were actually ESTABLISHED.
Until they are established, we're going to be constantly running into
this problem. Don't you agree?
I can start a Wiki page for this unless you'd prefer to do it.
>
> > +class tuple;
> > +
> > +/**
> > + * @internal
> > + * The template specialization for empty tuples.
> > + */
> > +_RWSTD_SPECIALIZED_CLASS
> > +class tuple< >
>
> Also please remove the space between the pointy braces here.
>
> > +{
> > +// empty
> > +};
> > +
> > +/**
> > + * @internal
> > + * The basic template specialization for most tuples. This class
> > + * template is used to instantiate all tuple types except for empty
> > + * tuples and tuples with exactly two element types.
> > + *
> > + * @param _HeadT First element type (required).
> > + * @param _TailT Template parameter pack for remaining
> element types.
> > + */
> > +template < class _HeadT, class... _TailT >
>
> In the interest of consistency we should adopt the same naming
> convention for the names of variadic template parameters. We
> have _TypeT and and Types in traits, _HeadT and _TailT here,
> and TTypes and UTypes in the standard. Which one should it
> be?
It is my opinion that the T and U prefixes/suffixes are only necessary
in binary contexts; i.e. where there are two different types or type
lists. Otherwise, we should use just a plain "Type" name.
Furthermore, generic "Type" names should only be used in truly
generic contexts; i.e. contexts where just about any type can be
used. Otherwise, the name should imply the restrictions/requirements
on the type; e.g. _ScalarType, _IntConst. In the recursive tuple
case, using generic names would make the code much harder to follow
IMHO.
>
> > +class tuple< _HeadT, _TailT... >
> > +: tuple< _TailT... >
> > +{
> > +typedef tuple< _TailT... > _Base;
> > +
> > +protected:
> > +
> > +_HeadT _C_head;
>
> Why protected and not private?
Good point. Given there's an internal accessor now, this could be
private I think.
>
> > +
> > +public:
> > +
> > +/**
> > + * Construct tuple with default values.
> > + */
> > +tuple ()
> > +: _C_head (), _Base () { /* empty */ }
>
> Unless tuple is somehow different from other (non-variadic
> classes) I think _Base() here should be listed first, because
> it's initialized first, no?
Yep. I think these were all done in a subsequent change.
>
> > +
> > +/**
> > + * Copy construct tuple from a different tuple value.
> > + * @param __tuple Another tuple value with same type.
> > + */
> > +tuple (const tuple& __tuple)
> > +: _C_head (__tuple._C_head), _Base (__tuple) { /*
> empty */ }
>
> Same as above.
>
> > +
> > +/**
> > + * Copy assign tuple from a different tuple value.
> > + * @param __tuple Another tuple value with same type.
> > + */
> > +tuple& operator= (const tuple& __tuple) {
> > +_C_head = __tuple._C_head;
> > +_Base::operator= (__tuple);
>
> Similarly to the ctor, the base assignment operator should
> probably be invoked first.
>
> > +return *this;
> > +}
> > +
> > +_EXPLICIT
> > +tuple (const _HeadT& __head, const _TailT&
RE: tests/utilities/20.meta.help.cpp
Martin Sebor wrote: > >Travis Vitek wrote: >> >> Eric Lemings wrote: >>> >>> Just a brief side note. I was just reviewing this test and >>> noticed that >>> pointers are not tested though they are valid scalar types >suitable for >>> use as integral_constant parameters. I think references >may be valid >>> parameters also. >>> >> >> I'm not sure. >> >> The first thing that jumps to mind is that a pointer is not of >> 'integral' type. An enumeration isn't really an integral type either, >> but they are implicitly convertible to one. Pointers aren't >convertible >> to integral type without a cast. >> >> According to temp.arg.nontype, a non-type, non-template template >> parameter must be one of >> >> -- an integral constant expression >> -- the name of a non-type template-parameter >> -- the address of an object or function with external linkage... >> -- a constant expression that evaluates to a null pointer value >> -- a constant expression that evaluates to a null member >pointer value >> -- a pointer to member >> >> So, yes, it is legal to use a pointer as a non-type template >parameter. >> >> The issue I have is that the integral_constant is supposed to >> define an integral constant of type T with value V. Section >expr.const >> says that a constant expression is an integral constant >expression if it >> is of integral or enumeration type. An integral constant >expression can >> be used as an array bound, a case expression, a bit field length, >> enumeration initializer, static member initializer and as integral or >> enumeration non-type template arguments. >> >> I'm pretty sure you can't use a pointer value as an array bound, case >> expression, bit field length or enumeration initializer, so >they aren't >> really integral constants. >> >> So I am sure you can instantiate std::integral_constant> (class_t::*)(), &class::method>, but I'm not sure if it >something that >> should be tested. > >If there's an implementation technique that would make the >instantiation ill-formed then I think it should be tested. According to class.mem (p4) and class.static.data (p4) you aren't allowed to initialize static members using a constant-initializer (i.e. in the member declaration) if they are not of const integral or const enumeration type. So the above instantiation on member pointer should be prevented by the compiler. A quick test with msvc-8.0 and gcc-4.3 show that this is the case. The following would be legal, but I'm already testing integral constants for all integral types and an enum type, so I think I'm covered. > >More important, though, the standard should specify the >requirements on the template arguments. If there are no >such requirements for something as fundamental as >integral_const, either in the latest working draft or >in one of the concepts papers (such as N2622), we should >at least bring it up on the list and/or open an issue to >have the spec clarified. The standard does specify the requirements of the template arguments, but only through association (to be an integral constant member, it has to be a const static that is initialized with a constant-initializer, and a constant initializer only works for enum and integral types). Is this significant enough to warrant bringing up an issue? Travis
Re: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
Eric Lemings wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 2:10 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp [EMAIL PROTECTED] wrote: Author: elemings Date: Mon Jun 16 09:31:03 2008 New Revision: 668225 URL: http://svn.apache.org/viewvc?rev=668225&view=rev Log: 2008-06-16 Eric Lemings <[EMAIL PROTECTED]> STDCXX-958 * etc/config/src/VA_LIST_FUNC_MACRO.cpp: Initial version of configuration check for va-list function macros. Out of curiosity, what do you expect to use this for? (FWIW, I've often wished variadic macros were supported in C++ compilers but I could never come up with a workaround for their absence, making them essentially unusable as a general purpose feature.) The most obvious use would be in RWTest printf-like functions. I'm not sure how well variadic function macros mesh with variadic templates but, if they do, I could take advantage of the feature in tuples. My point was that I couldn't find a way to use a feature that depends on variadic macros on platforms where they are not supported. In other words, I can't picture what the #else branch below would look like: #ifndef _RWSTD_NO_VARIADIC_MACROS # define RW_ASSERT(expr, ...) \ rw_assert (expr, 0, __LINE__, __VA_LIST__) #else # define RW_ASSERT(expr, ???) ... #endif Martin In any case, I figured we'll need the config test sooner or later. If we do come up with a use for the feature, I'd like to suggest renaming the config test VARIADIC_MACRO.cpp. Fine by me. :) Brad.
automating merges (was: [Fwd: Re: Attn New Committers])
FYI: I think Bill makes a good point WRT the ChangeLogs. Joe's script might be useful to us too. Original Message Subject: Re: Attn New Committers Date: Sat, 14 Jun 2008 22:42:42 +0200 From: Ruediger Pluem <[EMAIL PROTECTED]> To: APR Developer List <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> On 06/14/2008 10:20 PM, William A. Rowe, Jr. wrote: Please don't do this; --- Revision 663845 - Directory Listing Modified Fri Jun 6 07:39:52 2008 UTC (8 days, 12 hours ago) by henryjen backport r663342 from trunk --- Such commit messages aren't legible when comparing a branch to trunk, please repeat the purpose of the commit in the log message for the backport! There is an IMHO pretty cool script from Joe Orton that is very helpful for backporting trunk revisions. It creates a file with all the original commit messages that could be used as commit message for the backport plus it adds the numbers of the revisions that get backported. It can be found here: http://people.apache.org/~jorton/svn.merge Regards Rüdiger
RE: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2008 2:10 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r668225 - > /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp > > [EMAIL PROTECTED] wrote: > > Author: elemings > > Date: Mon Jun 16 09:31:03 2008 > > New Revision: 668225 > > > > URL: http://svn.apache.org/viewvc?rev=668225&view=rev > > Log: > > 2008-06-16 Eric Lemings <[EMAIL PROTECTED]> > > > > STDCXX-958 > > * etc/config/src/VA_LIST_FUNC_MACRO.cpp: Initial version of > > configuration check for va-list function macros. > > Out of curiosity, what do you expect to use this for? (FWIW, > I've often wished variadic macros were supported in C++ > compilers but I could never come up with a workaround for > their absence, making them essentially unusable as a general > purpose feature.) The most obvious use would be in RWTest printf-like functions. I'm not sure how well variadic function macros mesh with variadic templates but, if they do, I could take advantage of the feature in tuples. In any case, I figured we'll need the config test sooner or later. > > If we do come up with a use for the feature, I'd like to > suggest renaming the config test VARIADIC_MACRO.cpp. Fine by me. :) Brad.
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
[EMAIL PROTECTED] wrote:
Author: elemings
Date: Mon Jun 16 14:16:48 2008
New Revision: 668318
URL: http://svn.apache.org/viewvc?rev=668318&view=rev
Log:
2008-06-16 Eric Lemings <[EMAIL PROTECTED]>
STDCXX-958
* include/tuple, include/rw/_tuple.h, include/rw/_tuple_traits.h:
Add initial version of headers defining tuple interface and
implementation. (Only tested on Linux/gcc-4.3 platforms so far.)
* tests/utilities/20.tuple.cnstr.cpp: Rough outline of first
tuple test program.
[...]
+#if !defined _RWSTD_NO_VARIADIC_TEMPLATES
+
+
+_RWSTD_NAMESPACE (std) {
+
+
+// 20.3.1, class template tuple:
+
+/**
+ * @defgroup tuple Tuples [tuple]
+ *
+ * A fixed-size collection of values with variable, heterogenous types.
+ * This class template is used to instantatiate tuple types. A tuple
+ * type specifies zero or more element types for defining tuple values.
+ * A tuple value can be constructed from a tuple type that holds one
+ * value for each element type in the tuple.
+ *
+ * @param Types A list of zero or more types. No applicable type
+ * requirements or restrictions.
+ */
+template < class... Types >
Please follow the established convention and drop the spaces
before class and before the closing pointy brace. Thanks! :)
+class tuple;
+
+/**
+ * @internal
+ * The template specialization for empty tuples.
+ */
+_RWSTD_SPECIALIZED_CLASS
+class tuple< >
Also please remove the space between the pointy braces here.
+{
+// empty
+};
+
+/**
+ * @internal
+ * The basic template specialization for most tuples. This class
+ * template is used to instantiate all tuple types except for empty
+ * tuples and tuples with exactly two element types.
+ *
+ * @param _HeadT First element type (required).
+ * @param _TailT Template parameter pack for remaining element types.
+ */
+template < class _HeadT, class... _TailT >
In the interest of consistency we should adopt the same naming
convention for the names of variadic template parameters. We
have _TypeT and and Types in traits, _HeadT and _TailT here,
and TTypes and UTypes in the standard. Which one should it
be?
+class tuple< _HeadT, _TailT... >
+: tuple< _TailT... >
+{
+typedef tuple< _TailT... > _Base;
+
+protected:
+
+_HeadT _C_head;
Why protected and not private?
+
+public:
+
+/**
+ * Construct tuple with default values.
+ */
+tuple ()
+: _C_head (), _Base () { /* empty */ }
Unless tuple is somehow different from other (non-variadic
classes) I think _Base() here should be listed first, because
it's initialized first, no?
+
+/**
+ * Copy construct tuple from a different tuple value.
+ * @param __tuple Another tuple value with same type.
+ */
+tuple (const tuple& __tuple)
+: _C_head (__tuple._C_head), _Base (__tuple) { /* empty */ }
Same as above.
+
+/**
+ * Copy assign tuple from a different tuple value.
+ * @param __tuple Another tuple value with same type.
+ */
+tuple& operator= (const tuple& __tuple) {
+_C_head = __tuple._C_head;
+_Base::operator= (__tuple);
Similarly to the ctor, the base assignment operator should
probably be invoked first.
+return *this;
+}
+
+_EXPLICIT
+tuple (const _HeadT& __head, const _TailT&... __tail)
+: _C_head (__head), _Base (__tail...) { /* empty */ }
+
+# if !defined _RWSTD_NO_RVALUE_REFERENCES
+
+tuple (tuple&& __tuple)
+: _C_head (std::move (__tuple._C_head))
+, _Base (std::forward<_Base> (__tuple)) { /* empty */ }
The initialization order should follow the default ctor case
(i.e., _Base first). Also, the existing convention doesn't
drop the comma.
+
+tuple& operator= (tuple&& __tuple) {
+_C_head = std::move (__tuple._C_head);
+_Base::operator= (__tuple);
Same as the other assignment operator.
Also, I think it would make the class easier to read if
overloads were kept together wherever possible (i.e., all
ctors, all assignment operators, etc.) Although I think
I see why you didn't -- to avoid duplicating the rvalue
references test. Hmm. Have we decided on the list of
required compiler features yet? I saw your Compiler
Requirements page on the wiki (thanks for starting it,
btw.) and rvalue references isn't there. Do we think we
can provide a useful implementation of C++ 0x without
rvalue references?
+return *this;
+}
+
+# endif // !defined _RWSTD_NO_RVALUE_REFERENCES
+
+# if !defined _RWSTD_NO_MEMBER_TEMPLATES
I think we can safely rely on member templates in C++ 0x.
Do we all agree?
[...]
Added: stdcxx/branches/4.3.x/include/rw/_tuple_traits.h
[...]
+template
+struct constructible_with_allocator_prefix;
+
+/**
+ * Allows tuple construction with an allocator prefix argument. This
+ * trait informs other library components that tuple can be constructed
+ * with an allocator preï¬x argument.
Re: svn commit: r668225 - /stdcxx/branches/4.3.x/etc/config/src/VA_LIST_FUNC_MACRO.cpp
[EMAIL PROTECTED] wrote: Author: elemings Date: Mon Jun 16 09:31:03 2008 New Revision: 668225 URL: http://svn.apache.org/viewvc?rev=668225&view=rev Log: 2008-06-16 Eric Lemings <[EMAIL PROTECTED]> STDCXX-958 * etc/config/src/VA_LIST_FUNC_MACRO.cpp: Initial version of configuration check for va-list function macros. Out of curiosity, what do you expect to use this for? (FWIW, I've often wished variadic macros were supported in C++ compilers but I could never come up with a workaround for their absence, making them essentially unusable as a general purpose feature.) If we do come up with a use for the feature, I'd like to suggest renaming the config test VARIADIC_MACRO.cpp. Martin
Re: svn commit: r667637 - in /stdcxx/branches/4.3.x: etc/config/src/STATIC_ASSERT.cpp include/rw/_meta_cat.h include/rw/_meta_ref.h include/rw/_meta_rel.h include/rw/_static_assert.h
[EMAIL PROTECTED] wrote: Author: elemings Date: Fri Jun 13 13:20:48 2008 New Revision: 667637 URL: http://svn.apache.org/viewvc?rev=667637&view=rev Log: 2008-06-13 Eric Lemings <[EMAIL PROTECTED]> STDCXX-916 * include/rw/_meta_cat.h, include/rw/_meta_ref.h, include/rw/_meta_rel.h: Include missing headers. * include/rw/_static_assert.h [_RWSTD_STATIC_ASSERT]: Reverse definitions. Add Mesg parameter to internal definition so both definitions have same number of parameters. * etc/config/src/STATIC_ASSERT.cpp (main): Change main() to a regular function so config scripts don't find main() and (unnecessarily) link (and run?) program. [...] Modified: stdcxx/branches/4.3.x/include/rw/_static_assert.h URL: http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/include/rw/_static_assert.h?rev=667637&r1=667636&r2=667637&view=diff == --- stdcxx/branches/4.3.x/include/rw/_static_assert.h (original) +++ stdcxx/branches/4.3.x/include/rw/_static_assert.h Fri Jun 13 13:20:48 2008 @@ -53,14 +53,12 @@ } // namespace __rw #ifndef _RWSTD_NO_STATIC_ASSERT - -# define _RWSTD_STATIC_ASSERT(Cond) \ +# define _RWSTD_STATIC_ASSERT(Cond,Mesg) static_assert(Cond, Mesg) There's a missing space after the comma. +#else +# define _RWSTD_STATIC_ASSERT(Cond,Mesg) \ typedef \ _RW::__rw_static_assert) != 0> \ _RWSTD_PASTE(__static_assert,__LINE__) Same here. Martin
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
[EMAIL PROTECTED] wrote:
Author: elemings
Date: Fri Jun 13 13:16:06 2008
New Revision: 667636
URL: http://svn.apache.org/viewvc?rev=667636&view=rev
Log:
2008-06-13 Eric Lemings <[EMAIL PROTECTED]>
STDCXX-958
* include/rw/_forward.h: New header file containing initial
implementation of std::identity class template; std::forward()
and std::move() functions; and internal _RWSTD_MOVE() macro.
Added:
stdcxx/branches/4.3.x/include/rw/_forward.h
Added: stdcxx/branches/4.3.x/include/rw/_forward.h
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/include/rw/_forward.h?rev=667636&view=auto
==
--- stdcxx/branches/4.3.x/include/rw/_forward.h (added)
+++ stdcxx/branches/4.3.x/include/rw/_forward.h Fri Jun 13 13:16:06 2008
[...]
+template
Please follow the current naming convention for the names
of template parameters.
+struct identity
+{
+/** Identifies template parameter type. */
+typedef _Type type;
+
+/**
+ * Conversion operator. This operator converts the parameter value
+ * to the wrapped identity type.
+ *
+ * @param __x An value convertible to identity type.
+ * @returns Same value as the function argument with identity type.
+ */
+const _Type& operator() (const _Type& __x) {
The member function is supposed to be const.
+return __x;
+}
+};
+
+
+#if !defined _RWSTD_NO_RVALUE_REFERENCES
+
+/**
+ * Forwards appropriate rvalue or lvalue reference type. This function
+ * is used to ensure that the appropriate reference type is used in move
+ * semantics.
+ *
+ * @param _Type An lvalue or rvalue reference type.
+ * @param __x An lvalue reference or rvalue reference.
+ * @returns An lvalue if __x is an lvalue reference; otherwise, an rvalue.
+ */
+_EXPORT
Only out-of-line templates need to be declared exported.
Out-of-line function templates must be defined in .cc
files, and .cc files containing exported definitions
need to be explicitly #included in export.cpp.
This function template as well as move() below should be
declared inline.
+template
+_Type&&
+forward (_TYPENAME identity<_Type>::type&& __x)
+{
+return __x;
+}
+
+/**
+ * Move a value to an rvalue reference. This function is used to
+ * explicitly bind constructors and other functions with rvalue
+ * references that employ move semantics.
+ *
+ * @param __x An lvalue or rvalue.
+ * @returns Same value as parameter with rvalue reference type.
+ */
+_EXPORT
+template
+_TYPENAME _RW::__rw_remove_reference<_Type>::type&&
+move (_Type&& __x)
+{
+return __x;
+}
+
+/**
+ * @internal
+ * Internal wrapper macro to utilize move semantics if available.
+ * @param __x An lvalue or rvalue.
+ */
+# define _RWSTD_MOVE(__x) std::move (__x)
^
This should be _STD::move (__x).
Thanks!
Martin
+#else // no rvalue references
+# define _RWSTD_MOVE(__x) (__x)
+
+#endif // !defined _RWSTD_NO_RVALUE_REFERENCES
+
+
+} // namespace std
+
+
+# endif // !defined _RWSTD_NO_EXT_CXX_0X
+
+#endif // _RWSTD_RW_FORWARD_INCLUDED
Re: svn commit: r667365 [1/3] - in /stdcxx/branches/4.3.x: etc/config/src/ include/ include/rw/ tests/utilities/
Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: Are you sure the traits are correct for char and wchar_t? No. Also, do you believe the working draft to be unambiguous and correct? No. For reference, I've pulled the requirements from the standard and pasted them below. There is at least one obvious ambiguity. Assume that char is signed. Should std::make_signed::type be 'char' or 'signed char'? Yes. This needs to be clarified. Could you bring it up on [EMAIL PROTECTED] to make sure it's not a known problem that's already being handled? I'll help you write up the issue if it isn't. Okay. How formal is this list? Can I just post a quick message showing a testcase and asking if the issue is known, or should I go through the trouble to pull all of the necessary quotes from the draft, proposal and papers? You don't need to quote the spec like you did here. A small test case is always nice, although in this case, I'm not sure it's necessary. All we need to know, I think, is whether make_signed::type is intended to be signed char or plain char if T is char and CHAR_MIN < 0, and what the intended effects are for T being wchar_t. And maybe also for T being an enumeration. Same goes for std::make_signed::type when sizeof(enum_t) == sizeof(char). If both 'char' and 'signed char' are signed integral types, which of the two should be used? I didn't think enums could be smaller than int but that's probably going to change with scoped enums. If I'm reading the standard correctly, specifically decl.enum p4 and 5, it seems that it is allowed. It also seems wrong to have std::make_signed::type be 'signed char' only when 'char' is unsigned. It seems that users would like to be able to expect that the resulting type be consistent regardless of the signed-ness of char. Sounds like a valid point to me. OTOH, the actual type may not matter all that much just as long as the signedness is right. In my experience, in the handful of cases when I've ever needed an unsigned form of a (possibly) signed type all I cared about was the absence of signedness. Sure, but it would be nice if there was a requirement. Absolutely! Martin
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2008 11:38 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: Travis Vitek [mailto:[EMAIL PROTECTED] > >> Sent: Monday, June 23, 2008 10:13 AM > >> To: dev@stdcxx.apache.org > >> Subject: RE: svn commit: r667636 - > >> /stdcxx/branches/4.3.x/include/rw/_forward.h > >> > >> > >> > >> Martin Sebor wrote: > >>> Eric Lemings wrote: > > Gah. I have to update my docs as well: template parameters are > documented using the @tparam tag rather than the @param tag. > >>> I thought we said we wouldn't be using doxygen comments in > >>> library code. Am I misremembering? > >>> > >> I know that it was requested that I remove the doxygen > >> comments from the > >> type traits stuff I have been working on, but I decided it > >> would be best > >> to commit them with the comments intact and remove them only if > >> necessary. I mentioned this to Brad in our off-list > >> correspondence, and > >> he has opted to do the same. > >> > >> As I sit here thinking about it, I can't remember exactly > why it was > >> decided that they should be removed. Perhaps it is best to > have this > >> discussion again, but on the list this time. > >> > >> To start, I'm not sure I understand the motivation for _not_ using > >> doxygen in the library headers. I realize that having > documentation in > >> the code is a departure from what stdcxx has done in the > past, but I'm > >> not convinced that this is a bad thing. > > > > I'll add a couple points to that for the record. > > > > Much of this was precipitated when I noticed that GNU libstdc++ also > > includes their documentation right in the library headers and source > > code. Why? Because most, if not all, C/C++ preprocessors > will strip > > comments by default during a first pass. Thus, the impact > of extensive > > documentation comments on overall build times is negligible. > > Of course preprocessors strip comments. It's required by > the language standards. But regardless of the translation > stage at which the stripping takes place, it isn't without > cost. > > 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 What Travis said: if we don't write it ourselves, it probably won't get written. :) I also agree: I'd rather write doc comments than update the existing raw HTML docs. > > 2) Doxygen markups are harder to read than ordinary comments > (see 3), and in the library headers the volume of such > comments will, in many cases, dwarf the amount of code That's subjective. Because they are more structured than free-form comments, I find them easier to read. > > 3) unless/until there is infrastructure to generate the HTML > docs from the Doxygen comments documenting the library (or > other parts of stdcxx) using Doxygen markups serves no > purpose I consider that icing on the cake. You can still generate docs without having them published online. > > 4) the HTML generated from stdcxx headers is unavoidably > ugly because of the necessity to uglify names (leading > underscores, etc.) This can be controlled with conditional sections and comments, using @if tags, @internal tags, _RWSTD_EXT_DOXYGEN macro, and other such mechanisms. Brad.
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Martin Sebor wrote: > >Eric Lemings wrote: >> >> Travis Vitek wrote: >>> >>> Martin Sebor wrote: I thought we said we wouldn't be using doxygen comments in library code. Am I misremembering? >>> I know that it was requested that I remove the doxygen >>> comments from the >>> type traits stuff I have been working on, but I decided it >>> would be best >>> to commit them with the comments intact and remove them only if >>> necessary. I mentioned this to Brad in our off-list >>> correspondence, and >>> he has opted to do the same. >>> >>> As I sit here thinking about it, I can't remember exactly why it was >>> decided that they should be removed. Perhaps it is best to have this >>> discussion again, but on the list this time. >>> >>> To start, I'm not sure I understand the motivation for _not_ using >>> doxygen in the library headers. I realize that having documentation >>> in the code is a departure from what stdcxx has done in the past, >>> but I'm not convinced that this is a bad thing. >> >> I'll add a couple points to that for the record. >> >> Much of this was precipitated when I noticed that GNU libstdc++ also >> includes their documentation right in the library headers and source >> code. Why? Because most, if not all, C/C++ preprocessors will strip >> comments by default during a first pass. Thus, the impact of >> extensive documentation comments on overall build times is >> negligible. > >Of course preprocessors strip comments. It's required by >the language standards. But regardless of the translation >stage at which the stripping takes place, it isn't without >cost. > >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 Another important point is that the stdcxx project doesn't have anyone volunteering time to write documentation. If we want the documentation, we're likely going to have to do it ourselves, and I find using doxygen comments _much_ simpler than writing html. 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. >2) Doxygen markups are harder to read than ordinary comments > (see 3), and in the library headers the volume of such > comments will, in many cases, dwarf the amount of code If the code is well written, comments are usually reserved for situations where they are necessary to describe what the code is actually supposed to be doing. Most frequently this type of comment would be found in the body of a function definition. Doxygen comments, on the other hand, usually appear with the declarations, so the type of comments that you would usually need to read aren't necessarily in the same place as the doxygen comments. Additionally, your editor can likely be configured to hide the doxygen comments if you don't want to see them. As for readability, consider this. There are currently no comments describing what a given library class or function is expected to do. If you want to see what the expected behavior is, you get to walk yourself through the implementation, or you get to fire up a web browser and look at the html documentation. If the documentation is added as doxygen comments, they are in the code. They may be slightly less readable than plain english text due to the additional markup, but there is _nothing_ that is stopping you from looking to the implementation or firing up a web browser like you did before. >3) unless/until there is infrastructure to generate the HTML > docs from the Doxygen comments documenting the library (or > other parts of stdcxx) using Doxygen markups serves no > purpose Which would you like first, the chick or the egg? The infrastructure will never be built to generate html documentation from doxygen comments if we don't have doxygen comments to generate documentation from. > >4) the HTML generated from stdcxx headers is unavoidably > ugly because of the necessity to uglify names (leading > underscores, etc.) I thought leading underscores made code run faster. :) Doxygen doesn't have to document everything that it sees. There are many ways to co
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Eric Lemings wrote: -Original Message- From: Travis Vitek [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 10:13 AM To: dev@stdcxx.apache.org Subject: RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h Martin Sebor wrote: Eric Lemings wrote: Gah. I have to update my docs as well: template parameters are documented using the @tparam tag rather than the @param tag. I thought we said we wouldn't be using doxygen comments in library code. Am I misremembering? I know that it was requested that I remove the doxygen comments from the type traits stuff I have been working on, but I decided it would be best to commit them with the comments intact and remove them only if necessary. I mentioned this to Brad in our off-list correspondence, and he has opted to do the same. As I sit here thinking about it, I can't remember exactly why it was decided that they should be removed. Perhaps it is best to have this discussion again, but on the list this time. To start, I'm not sure I understand the motivation for _not_ using doxygen in the library headers. I realize that having documentation in the code is a departure from what stdcxx has done in the past, but I'm not convinced that this is a bad thing. I'll add a couple points to that for the record. Much of this was precipitated when I noticed that GNU libstdc++ also includes their documentation right in the library headers and source code. Why? Because most, if not all, C/C++ preprocessors will strip comments by default during a first pass. Thus, the impact of extensive documentation comments on overall build times is negligible. Of course preprocessors strip comments. It's required by the language standards. But regardless of the translation stage at which the stripping takes place, it isn't without cost. 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 2) Doxygen markups are harder to read than ordinary comments (see 3), and in the library headers the volume of such comments will, in many cases, dwarf the amount of code 3) unless/until there is infrastructure to generate the HTML docs from the Doxygen comments documenting the library (or other parts of stdcxx) using Doxygen markups serves no purpose 4) the HTML generated from stdcxx headers is unavoidably ugly because of the necessity to uglify names (leading underscores, etc.) Martin
RE: svn propchange: r667365 - svn:log
Martin Sebor wrote: > >[EMAIL PROTECTED] wrote: >> Author: vitek >> Revision: 667365 >> Modified property: svn:log >> >> Modified: svn:log at Mon Jun 16 09:47:35 2008 >> >--- >--- >> --- svn:log (original) >> +++ svn:log Mon Jun 16 09:47:35 2008 >> @@ -2,13 +2,32 @@ >> >> STDCXX-916 >> * include/type_traits: New file defines C++0x type traits. >> -* include/rw/_config-gcc.h: Add macros for compiler support. >> -* include/rw/_config-msvc.h: Ditto. >> +* include/rw/_config-gcc.h [_RWSTD_TT_IS_ENUM, >_RWSTD_TT_IS_UNION, > > >Not to be an overly pedantic PITA but my reading of the GNU >coding standards is that the brackets are for conditionals, >not for lists of added or changed names, so the names here >should be in parentheses. Do you read it differently? > You are correct. They should be in parens. Will update log. >Martin >
Re: svn commit: r670674 - in /stdcxx/branches/4.3.x: doc/ include/ include/rw/ tests/utilities/
[EMAIL PROTECTED] wrote: Author: elemings Date: Mon Jun 23 09:53:09 2008 New Revision: 670674 URL: http://svn.apache.org/viewvc?rev=670674&view=rev Log: 2008-06-23 Eric Lemings <[EMAIL PROTECTED]> STDCXX-958 * include/tuple: * include/rw/_tuple.h: * include/rw/_tuple_traits.h: * include/rw/_forward.h: * include/rw/_ref_wrap.h: * tests/utilities/20.forward.cpp: * tests/utilities/20.tuple.h: * tests/utilities/20.tuple.cnstr.cpp: * tests/utilities/20.tuple.elem.cpp: * tests/utilities/20.tuple.helpers.cpp: * doc/Doxyfile: Add svn:eol-style=native and svn:keywords=Id properties. * tests/utilities/20.forward.cpp: Likewise. Also fix copyright date. [...] Modified: stdcxx/branches/4.3.x/tests/utilities/20.forward.cpp URL: http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/tests/utilities/20.forward.cpp?rev=670674&r1=670673&r2=670674&view=diff == --- stdcxx/branches/4.3.x/tests/utilities/20.forward.cpp (original) +++ stdcxx/branches/4.3.x/tests/utilities/20.forward.cpp Mon Jun 23 09:53:09 2008 @@ -22,7 +22,7 @@ * implied. See the License for the specific language governing * permissions and limitations under the License. * - * Copyright 1994-2008 Rogue Wave Software. + * Copyright 2008 Rogue Wave Software. This is still missing the ", Inc." bit at the end. But as I said before, if it's too much of a pain to be keeping all these little details in mind I think it'd be just fine to stop adding the copyright to new files. Alternatively, we might want to write a script to check for these things on a regular basis. Martin
RE: svn commit: r667365 [1/3] - in /stdcxx/branches/4.3.x: etc/config/src/ include/ include/rw/ tests/utilities/
Martin Sebor wrote: > >Travis Vitek wrote: >> >> Martin Sebor wrote: >> >>> Are you sure the traits are correct for char and wchar_t? >> >> No. >> >>> Also, do you believe the working draft to be >>> unambiguous and correct? >> >> No. For reference, I've pulled the requirements from the standard and >> pasted them below. >> >> There is at least one obvious ambiguity. Assume that char is signed. >> Should std::make_signed::type be 'char' or >'signed char'? > >Yes. This needs to be clarified. Could you bring it up on >[EMAIL PROTECTED] to make sure it's not a known problem >that's already being handled? I'll help you write up the >issue if it isn't. Okay. How formal is this list? Can I just post a quick message showing a testcase and asking if the issue is known, or should I go through the trouble to pull all of the necessary quotes from the draft, proposal and papers? > >> Same goes for std::make_signed::type when sizeof(enum_t) == >> sizeof(char). If both 'char' and 'signed char' are signed integral >> types, which of the two should be used? > >I didn't think enums could be smaller than int but that's >probably going to change with scoped enums. If I'm reading the standard correctly, specifically decl.enum p4 and 5, it seems that it is allowed. >> >> It also seems wrong to have std::make_signed::type be 'signed >> char' only when 'char' is unsigned. It seems that users >would like to be >> able to expect that the resulting type be consistent >regardless of the >> signed-ness of char. > >Sounds like a valid point to me. OTOH, the actual type may >not matter all that much just as long as the signedness is >right. In my experience, in the handful of cases when I've >ever needed an unsigned form of a (possibly) signed type >all I cared about was the absence of signedness. > Sure, but it would be nice if there was a requirement. >> >> Both of these issues make me think that the definition of make_signed >> should have said 'signed integer type' instead of 'signed integral >> type'. > >You mean just signed/unsigned integers (I had to look up the >difference). I suspect most people would find a make_signed >that didn't work with char to be broken. Yeah, my proposed change wouldn't be sufficient. It would need to say something about using explicit signed/unsigned qualifications for char. > >> >>> Based on my reading, make_signed >>> ::type should be the same as T if T is a signed integral type. >>> IIUC, our make_signed::type is defined to signed char >>> regardless of the signed-ness of char. Ditto for wchar_t. > >Right. That's what caught my attention because it goes >against the requirement. > >Martin > >>>
Re: svn commit: r669999 - /stdcxx/branches/4.3.x/include/rw/_meta_other.h
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Fri Jun 20 10:27:42 2008
New Revision: 66
URL: http://svn.apache.org/viewvc?rev=66&view=rev
Log:
2008-06-20 Travis Vitek <[EMAIL PROTECTED]>
STDCXX-926
* include/rw/_meta_other.h: Remove unnecessary whitespace,
simplify workaround for msvc.
Modified:
stdcxx/branches/4.3.x/include/rw/_meta_other.h
Modified: stdcxx/branches/4.3.x/include/rw/_meta_other.h
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/include/rw/_meta_other.h?rev=66&r1=669998&r2=66&view=diff
==
--- stdcxx/branches/4.3.x/include/rw/_meta_other.h (original)
+++ stdcxx/branches/4.3.x/include/rw/_meta_other.h Fri Jun 20 10:27:42 2008
@@ -266,31 +266,31 @@
struct __rw_biggest
{
typedef typename
-__rw_conditional<( sizeof _Type1 < sizeof _Type2),
+__rw_conditional<(sizeof _Type1 < sizeof _Type2),
The type argument to sizeof needs to be enclosed in parens.
If the code compiles as is we should report it as a bug to
the compiler vendor.
Martin
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2008 10:13 AM > To: dev@stdcxx.apache.org > Subject: RE: svn commit: r667636 - > /stdcxx/branches/4.3.x/include/rw/_forward.h > > > > Martin Sebor wrote: > > > >Eric Lemings wrote: > >> > >> Gah. I have to update my docs as well: template parameters are > >> documented using the @tparam tag rather than the @param tag. > > > >I thought we said we wouldn't be using doxygen comments in > >library code. Am I misremembering? > > > > I know that it was requested that I remove the doxygen > comments from the > type traits stuff I have been working on, but I decided it > would be best > to commit them with the comments intact and remove them only if > necessary. I mentioned this to Brad in our off-list > correspondence, and > he has opted to do the same. > > As I sit here thinking about it, I can't remember exactly why it was > decided that they should be removed. Perhaps it is best to have this > discussion again, but on the list this time. > > To start, I'm not sure I understand the motivation for _not_ using > doxygen in the library headers. I realize that having documentation in > the code is a departure from what stdcxx has done in the past, but I'm > not convinced that this is a bad thing. I'll add a couple points to that for the record. Much of this was precipitated when I noticed that GNU libstdc++ also includes their documentation right in the library headers and source code. Why? Because most, if not all, C/C++ preprocessors will strip comments by default during a first pass. Thus, the impact of extensive documentation comments on overall build times is negligible. I believe Travis did some quick performance tests to verify these empirical conclusions. Brad.
Re: svn commit: r668340 - /stdcxx/branches/4.3.x/tests/utilities/20.meta.unary.prop.cpp
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Mon Jun 16 16:07:26 2008
New Revision: 668340
URL: http://svn.apache.org/viewvc?rev=668340&view=rev
Log:
2008-06-16 Travis Vitek <[EMAIL PROTECTED]>
STDCXX-920
* tests/utilities/20.meta.unary.prop.cpp: Use size_t instead
of _RWSTD_SIZE_T. Update test to correctly reflect behaviors
required by standard.
Modified:
stdcxx/branches/4.3.x/tests/utilities/20.meta.unary.prop.cpp
Modified: stdcxx/branches/4.3.x/tests/utilities/20.meta.unary.prop.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/tests/utilities/20.meta.unary.prop.cpp?rev=668340&r1=668339&r2=668340&view=diff
==
--- stdcxx/branches/4.3.x/tests/utilities/20.meta.unary.prop.cpp (original)
+++ stdcxx/branches/4.3.x/tests/utilities/20.meta.unary.prop.cpp Mon Jun 16
16:07:26 2008
@@ -27,6 +27,8 @@
*
**/
+#include
Any reason why this shouldn't be like in all other
tests?
Martin
+
#include
// compile out all test code if extensions disabled
@@ -208,15 +210,15 @@
void test_trait (int line,
const char* trait, const char* type,
- _RWSTD_SIZE_T value, _RWSTD_SIZE_T expect)
+ size_t value, size_t expect)
{
rw_assert (value == expect, 0, line,
"%s<%s>::value is %zu, expected %zu",
trait, type, value, expect);
}
-void test_trait (int line, _RWSTD_SIZE_T depth,
- _RWSTD_SIZE_T value, _RWSTD_SIZE_T expect,
+void test_trait (int line, size_t depth,
+ size_t value, size_t expect,
const char* trait, const char* type)
{
rw_assert (value == expect, 0, line,
@@ -374,9 +376,9 @@
static void test_is_trivial ()
{
TEST (std::is_trivial, long, true);
-TEST (std::is_trivial, C long, false);
+TEST (std::is_trivial, C long, true);
TEST (std::is_trivial, V long, true);
-TEST (std::is_trivial, CV long, false);
+TEST (std::is_trivial, CV long, true);
TEST (std::is_trivial, long&, false);
TEST (std::is_trivial, C long&, false);
@@ -418,6 +420,7 @@
static void test_is_standard_layout ()
{
TEST (std::is_standard_layout, long, true);
+TEST (std::is_standard_layout, non_empty_t, true);
// no non-static data members of non-standard-layout type
TEST (std::is_standard_layout, member_t, false);
Re: svn propchange: r667365 - svn:log
[EMAIL PROTECTED] wrote: Author: vitek Revision: 667365 Modified property: svn:log Modified: svn:log at Mon Jun 16 09:47:35 2008 -- --- svn:log (original) +++ svn:log Mon Jun 16 09:47:35 2008 @@ -2,13 +2,32 @@ STDCXX-916 * include/type_traits: New file defines C++0x type traits. - * include/rw/_config-gcc.h: Add macros for compiler support. - * include/rw/_config-msvc.h: Ditto. + * include/rw/_config-gcc.h [_RWSTD_TT_IS_ENUM, _RWSTD_TT_IS_UNION, Not to be an overly pedantic PITA but my reading of the GNU coding standards is that the brackets are for conditionals, not for lists of added or changed names, so the names here should be in parentheses. Do you read it differently? Martin + _RWSTD_TT_IS_CLASS, _RWSTD_TT_IS_POD, _RWSTD_TT_IS_EMPTY, + _RWSTD_TT_IS_POLYMORPHIC, _RWSTD_TT_IS_ABSTRACT, _RWSTD_TT_IS_BASE_OF, + _RWSTD_TT_HAS_TRIVIAL_CTOR, _RWSTD_TT_HAS_TRIVIAL_COPY, + _RWSTD_TT_HAS_TRIVIAL_ASSIGN, _RWSTD_TT_HAS_TRIVIAL_DTOR, + _RWSTD_TT_HAS_NOTHROW_CTOR, _RWSTD_TT_HAS_NOTHROW_COPY, + _RWSTD_TT_HAS_TRIVIAL_ASSIGN, _RWSTD_TT_HAS_VIRTUAL_DTOR, + _RWSTD_TT_ALIGN_OF, _RWSTD_ALIGNED_POD, _RWSTD_MAX_ALIGNMENT]: Add + macros for compiler support. + * include/rw/_config-msvc.h [_RWSTD_TT_IS_ENUM, _RWSTD_TT_IS_UNION, + _RWSTD_TT_IS_CLASS, _RWSTD_TT_IS_POD, _RWSTD_TT_IS_EMPTY, + _RWSTD_TT_IS_POLYMORPHIC, _RWSTD_TT_IS_ABSTRACT, _RWSTD_TT_IS_BASE_OF, + _RWSTD_TT_IS_CONVERTIBLE, _RWSTD_TT_HAS_VIRTUAL_DTOR, + _RWSTD_TT_HAS_TRIVIAL_CTOR, _RWSTD_TT_HAS_TRIVIAL_ASSIGN, + _RWSTD_TT_HAS_TRIVIAL_COPY, _RWSTD_TT_HAS_TRIVIAL_DTOR, + _RWSTD_TT_HAS_NOTHROW_CTOR, _RWSTD_TT_HAS_NOTHROW_ASSIGN, + _RWSTD_TT_HAS_NOTHROW_COPY, _RWSTD_TT_ALIGN_OF, _RWSTD_TT_ALIGNED_POD, + _RWSTD_TT_MAX_ALIGNMENT]: Ditto. * include/rw/_config.h [_RWSTD_EXT_CXX_OX]: Disable C++0x extensions unless defined. * include/rw/_defs.h [_RWSTD_SWCHAR_INT_T]: Add new macro that defines a type that has same size and layout a the fictional signed wchar_t. + [_RWSTD_UWCHAR_INT_T]: Modify definition to handle case where + unsigned long is not the same size as unsigned int. Add case for + unsigned long long. * etc/config/src/STATIC_ASSERT.cpp: Add configuration test to check for C++0x static_assert. * include/rw/_static_assert.h [_RWSTD_STATIC_ASSERT]: Add a
Re: svn commit: r655960 - in /stdcxx/branches/4.2.x/tests: include/ localization/ src/
[EMAIL PROTECTED] wrote: Author: vitek Date: Tue May 13 11:21:50 2008 New Revision: 655960 URL: http://svn.apache.org/viewvc?rev=655960&view=rev Log: 2008-05-07 Travis Vitek <[EMAIL PROTECTED]> STDCXX-536 * tests/include/rw_thread.h (rw_thread_pool): Add timeout parameter with default value. FWIW, it occurred to me that this is what rw_threadattr_t was/is meant to be for. Do you see any reason not to make the change? If not, I'll try to remember to put together a patch. Martin
Re: svn commit: r667365 [1/3] - in /stdcxx/branches/4.3.x: etc/config/src/ include/ include/rw/ tests/utilities/
Travis Vitek wrote: Martin Sebor wrote: Are you sure the traits are correct for char and wchar_t? No. Also, do you believe the working draft to be unambiguous and correct? No. For reference, I've pulled the requirements from the standard and pasted them below. There is at least one obvious ambiguity. Assume that char is signed. Should std::make_signed::type be 'char' or 'signed char'? Yes. This needs to be clarified. Could you bring it up on [EMAIL PROTECTED] to make sure it's not a known problem that's already being handled? I'll help you write up the issue if it isn't. Same goes for std::make_signed::type when sizeof(enum_t) == sizeof(char). If both 'char' and 'signed char' are signed integral types, which of the two should be used? I didn't think enums could be smaller than int but that's probably going to change with scoped enums. It also seems wrong to have std::make_signed::type be 'signed char' only when 'char' is unsigned. It seems that users would like to be able to expect that the resulting type be consistent regardless of the signed-ness of char. Sounds like a valid point to me. OTOH, the actual type may not matter all that much just as long as the signedness is right. In my experience, in the handful of cases when I've ever needed an unsigned form of a (possibly) signed type all I cared about was the absence of signedness. Both of these issues make me think that the definition of make_signed should have said 'signed integer type' instead of 'signed integral type'. You mean just signed/unsigned integers (I had to look up the difference). I suspect most people would find a make_signed that didn't work with char to be broken. Based on my reading, make_signed ::type should be the same as T if T is a signed integral type. IIUC, our make_signed::type is defined to signed char regardless of the signed-ness of char. Ditto for wchar_t. Right. That's what caught my attention because it goes against the requirement. Martin [basic.fundamental] p2 There are five standard signed integer types: "signed char", "short int", "int", "long int", and "long long int". In this list, each type provides at least as much storage as those preceding it in the list. [...] The standard and extended signed integer types are collectively called signed integer types. [basic.fundamental] p3 For each of the standard signed integer types, there exists a corresponding standard unsigned integer type: "unsigned char", "unsigned short int", "unsigned int", "unsigned long int", and "unsigned long long int", each of which occupies the same amount of storage and has the same alignment requirements as the corresponding signed integer type. [...] The standard and extended unsigned integer types are collectively called unsigned integer types. [basic.fundamental] p7 Types bool, char, char16_t, char32_t, wchar_t, and the signed and unsigned integer types are collectively called integral types. [meta.trans.sign] If T names a (possibly cv-qualified) signed integral type then the member typedef type shall name the type T; otherwise, if T names a (possibly cv-qualified) unsigned integral type then type shall name the corresponding signed integral type, with the same cv-qualifiers as T; otherwise, type shall name the signed integral type with smallest rank for which sizeof(T) == sizeof(type), with the same cv-qualifiers as T.
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Martin Sebor wrote: > >Eric Lemings wrote: >> >> Gah. I have to update my docs as well: template parameters are >> documented using the @tparam tag rather than the @param tag. > >I thought we said we wouldn't be using doxygen comments in >library code. Am I misremembering? > I know that it was requested that I remove the doxygen comments from the type traits stuff I have been working on, but I decided it would be best to commit them with the comments intact and remove them only if necessary. I mentioned this to Brad in our off-list correspondence, and he has opted to do the same. As I sit here thinking about it, I can't remember exactly why it was decided that they should be removed. Perhaps it is best to have this discussion again, but on the list this time. To start, I'm not sure I understand the motivation for _not_ using doxygen in the library headers. I realize that having documentation in the code is a departure from what stdcxx has done in the past, but I'm not convinced that this is a bad thing. Travis >Martin > >> >> http://www.stack.nl/~dimitri/doxygen/commands.html#cmdtparam >> >> Brad.
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Eric Lemings wrote: Gah. I have to update my docs as well: template parameters are documented using the @tparam tag rather than the @param tag. I thought we said we wouldn't be using doxygen comments in library code. Am I misremembering? Martin http://www.stack.nl/~dimitri/doxygen/commands.html#cmdtparam Brad. -Original Message- From: Travis Vitek Sent: Monday, June 16, 2008 11:47 AM To: Eric Lemings Subject: RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h Damn, now I have to update my dox. -Original Message- From: Eric Lemings Sent: Monday, June 16, 2008 10:44 AM To: Travis Vitek Subject: RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h -Original Message- From: Travis Vitek Sent: Monday, June 16, 2008 10:21 AM To: Eric Lemings Subject: RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h Author: elemings Date: Fri Jun 13 13:16:06 2008 New Revision: 667636 +/** + * An identity wrapper. Similar to the identity property, the identity + * wrapper is a class template that simply reflects the type of its + * template parameter. This class template is used when a template + * parameter type must be explicitly specified in order to apply the + * correct move/forwarding semantics, usually in the \c std::forward() + * function. + * + * @param _Type Any type. No restrictions or requirements. + * @see std::forward + */ +template +struct identity Does doxygen handle @param when we are talking about a template parameter? Not yet. http://www.mail-archive.com/[EMAIL PROTECTED] /msg163022.html
Re: Inconsistent indentation in preprocessing directives
Eric Lemings wrote: I was just looking at the indentation in the $TOPDIR/include/rw/_static_assert.h header. Why are the defines within the `#ifndef _RWSTD_NO_STATIC_ASSERT' indented but the directives outside this #if/#else/#endif block are not? Should they all be indented uniformly or not indented at all? I agree it's inconsistent but I'm not sure there is much to be gained from indenting the body of the top level blocks. The purpose of the indentation is to aid readability and Since virtually every header is always enclosed in a pair of #ifdefs, indenting its contents wouldn't do anything to help in this regard. Martin I realize this is not conventional but if we want to indent preprocessing directives, this file should look like this: #ifndef _RWSTD_RW_STATIC_ASSERT_H_INCLUDED # define _RWSTD_RW_STATIC_ASSERT_H_INCLUDED # include ... # ifndef _RWSTD_NO_STATIC_ASSERT #define _RWSTD_STATIC_ASSERT(Cond) ... # else #define _RWSTD_STATIC_ASSERT(Cond,Mesg) static_assert(Cond, Mesg) # endif // _RWSTD_NO_STATIC_ASSERT #endif // _RWSTD_RW_STATIC_ASSERT_H_INCLUDED Otherwise, we shouldn't indent at all. Thanks, Brad.
RE: svn commit: r670099 - in /stdcxx/branches/4.3.x/include: rw/_ref_wrap.h tuple
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Sunday, June 22, 2008 5:48 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r670099 - in > /stdcxx/branches/4.3.x/include: rw/_ref_wrap.h tuple > > Travis Vitek wrote: > > > > Brad, > > > > I just noticed that you aren't applying SVN properties to > all of the files that you are adding. New headers and source > should get the svn:eol-style and svn:keywords properties set. > Ideally this would be done before you submit the file for the > first time, but you can add the properties later. > > > > I believe that the command sequence on non-windows systems is > > > > $ svn propset svn:eol-style native > > $ svn propset svn:keywords Id > > Or enable auto-props in your $HOME/.subversion/config file and set > these there (via: svn:eol-style=native;svn:keywords=Id). Here are > some more details: > http://svnbook.red-bean.com/en/1.4/svn.advanced.confarea.html# > svn.advanced.confarea.opts.config Good tip. Thanks.
Re: svn commit: r667638 - /stdcxx/branches/4.3.x/tests/utilities/20.forward.cpp
Eric Lemings wrote: [...] We ususally don't use the __FILE__ tag with code that is in the original test file. I'm not exactly sure why, but I don't recall ever seeing it used. Perhaps this is to reduce the amount of output generated in the output files? Hehe. Who knows why some files omit it. Passing null to rw_assert() makes the driver substitute the file name argument passed to rw_test(). I think its just something that's been carried over without a second's thought. Sort of like why many template parameters are named "_TypeT" when there is only one type parameter. The name "_TypeT" is actually only needed in contexts where there's a corresponding "_TypeU". Otherwise, the name "_Type" is sufficient. FYI: The reason for the _Type prefix to T or U is to prevent collisions with system macros named _T (or _U). When we found the problem we just globally inserted the _Type prefix into the names of all typed template parameters. I personally like the T in there for consistency with all the other names. Another thing to note is that most of the stdcxx tests don't display anything other than the header when they run, unless something fails. Ah. The --trace option is new to me. I guess it's supposed to act sort of like the the rw_info() calls. I'll keep that in mind when writing test code in the future. Right. The option makes the informational messages pretty much redundant. Martin
Re: tests/utilities/20.meta.help.cpp
Travis Vitek wrote: Eric Lemings wrote: Just a brief side note. I was just reviewing this test and noticed that pointers are not tested though they are valid scalar types suitable for use as integral_constant parameters. I think references may be valid parameters also. I'm not sure. The first thing that jumps to mind is that a pointer is not of 'integral' type. An enumeration isn't really an integral type either, but they are implicitly convertible to one. Pointers aren't convertible to integral type without a cast. According to temp.arg.nontype, a non-type, non-template template parameter must be one of -- an integral constant expression -- the name of a non-type template-parameter -- the address of an object or function with external linkage... -- a constant expression that evaluates to a null pointer value -- a constant expression that evaluates to a null member pointer value -- a pointer to member So, yes, it is legal to use a pointer as a non-type template parameter. The issue I have is that the integral_constant is supposed to define an integral constant of type T with value V. Section expr.const says that a constant expression is an integral constant expression if it is of integral or enumeration type. An integral constant expression can be used as an array bound, a case expression, a bit field length, enumeration initializer, static member initializer and as integral or enumeration non-type template arguments. I'm pretty sure you can't use a pointer value as an array bound, case expression, bit field length or enumeration initializer, so they aren't really integral constants. So I am sure you can instantiate std::integral_constant, but I'm not sure if it something that should be tested. If there's an implementation technique that would make the instantiation ill-formed then I think it should be tested. More important, though, the standard should specify the requirements on the template arguments. If there are no such requirements for something as fundamental as integral_const, either in the latest working draft or in one of the concepts papers (such as N2622), we should at least bring it up on the list and/or open an issue to have the spec clarified. Martin Brad.
Re:
Travis Vitek wrote: Martin Sebor wrote: [...] In all library headers: 1. standard headers (C++, including stdcxx own, C, or POSIX are never included (there are a shrinking number of exceptions to this rule) So, as an example, if one of us needed to use std::integral_constant in some header, the definition of that type would need to be moved to some private header and included from both places to avoid including . I can buy this as it fits with the unnecessary namespace polution problem that keeps coming up. Right. Although it should be balanced against the cost of #including a whole header for just a single definition. That's why we have headers such as or : to group the most commonly needed sets of definitions and not a separate header for each of the definitions in these headers. 2. include directives are in alphabetical order, with rw/_defs.h being last (it still ends up getting included first, indirectly, by the first header); the exception here is when a stdcxx config macro needs to be tested before the first #include directive Okay, and what is the rationale for including rw/_defs.h last? If it provides defines that are needed by the current file, why not just put it in the list in alphabetical order like the others? It used to be first. IIRC, the idea behind including it last was to make it more likely for things to break if the #include directive was missing. I'm not sure how well well thought out it was. If it's causing trouble and going back to how it used to be way back when makes more sense (i.e., eliminates the exceptional case) I have no problem with it. 3. each #include directive in every standard header is guarded with a preprocessor conditional testing the XXX_INCLUDED macro for the corresponding header for compile-time efficiency I'm assuming that you're talking about this kind of thing... #ifndef _RWSTD_RW_ALGOBASE_H_INCLUDED # include #endif // _RWSTD_RW_ALGOBASE_H_INCLUDED #ifndef _RWSTD_RW_ITERBASE_H_INCLUDED # include #endif // _RWSTD_RW_ITERBASE_H_INCLUDED I looked in a handful of standard headers and didn't see this model anywhere. I do see it in many of the private headers, but it is not being used consistently. I thought I had implemented it this way but it looks like I misremembered. Do we have any evidence that shows this 'optimization' is actually improving compile times? I haven't done any benchmarking with stdcxx but what's in stdcxx now was done based on a user request: http://issues.apache.org/jira/browse/STDCXX-213 Other than that, as I already said in another thread, there is plenty of evidence out there that #include directives can have a dramatic impact on compile times. That's why many modern compilers provide this optimization either via special purpose mechanisms like #pragma once or even automatically. In library sources: 1. sets of C++, C, POSIX, and stdcxx-private headers are included in separate blocks of their own, in alphabetical order within each block 2. C headers are included using the xxx.h form (as opposed to the cxxx form) for better portability Martin
