Liviu,
I built the library and tests before and after your change with the 64-bit
flag, and I saw no differences in the number of failed tests between the
builds. I've attached the output of 'gmake -k runall' before and after your
change to STDCXX-1072 in case you want to look over them.
I wr
Liviu,
Sorry I didn't look until just now, but it appears that I could have re-opened
STDCXX-1066. I only see the 'Reopen Issue' button for STDCXX issues, but it is
most definitely there. Perhaps there is some sort of permission issue for you?
Also, STDCXX-1066 appears to have been a duplicate
> -Original Message-
> From: Liviu Nicoara
> Sent: Friday, September 28, 2012 5:29 AM
>
>
> In short, my reading about this issue is that the kernel patch changed
> the alignment of the userland mutex objects from a machine word to a
> double-word boundary. No changes are required of th
Only major versions can break binary. The versioning policy for stdcxx can be
found here..
http://stdcxx.apache.org/versions.html
Travis
-Original Message-
From: Liviu Nicoara [mailto:nikko...@hates.ms]
Sent: Friday, September 28, 2012 3:52 AM
To: dev@stdcxx.apache.org
Subject: Re: S
I asked around and we don't have one available at this time.
Travis
Liviu Nicoara wrote:
On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/STDCXX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
Anybody around here,
Comments below...
> -Original Message-
> From: Stefan Teleman
> Sent: Monday, September 24, 2012 5:46 AM
> Subject: Re: STDCXX-1066 [was: Re: STDCXX forks]
>
> On Mon, Sep 24, 2012 at 8:21 AM, Liviu Nicoara
> wrote:
>
> > In the light of your inability to answer the simplest questions a
Liviu,
Should the volatile be to the left of the intT typename here? I know it is
equivalent, but it is weird to look at the line of code below and see that
we're following two different conventions.
Travis
___
From: Liviu Nicoara
Sent: Sunday, September 23,
> -Original Message-
> From: Stefan Teleman [mailto:stefan.tele...@gmail.com]
> Sent: Friday, September 21, 2012 2:14 AM
> To: dev@stdcxx.apache.org
> Subject: Re: STDCXX-1056 : numpunct fix
>
> On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
> wrote:
>
&
> -Original Message-
> From: Stefan Teleman
> Sent: Thursday, September 20, 2012 6:00 PM
> To: dev@stdcxx.apache.org
> Cc: Liviu Nicoara
> Subject: Re: STDCXX-1056 : numpunct fix
>
> On Thu, Sep 20, 2012 at 8:44 PM, "C. Bergström"
> wrote:
>
>
> I do have a program which triggers the r
> -Original Message-
> From: Stefan Teleman [mailto:stefan.tele...@gmail.com]
> Sent: Thursday, September 20, 2012 10:11 AM
> To: dev@stdcxx.apache.org
> Subject: Re: STDCXX-1056 : numpunct fix
>
> On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara
> wrote:
> > But have you measured the amo
On 09/05/12 04:20, Liviu Nicoara wrote:
> On 09/04/12 21:25, Martin Sebor wrote:
>> On 09/04/2012 07:02 PM, Liviu Nicoara wrote:
>>> Hi guys,
>>>
>>>
>>>
>> Looking at the test below, though, it depends on undefined behavior
>> (signed overflow) so there's no compiler bug. Making max volatile
>>
I approve the change, but with one caveat. The branching policy [1] indicates
that you should commit your changes directly to the 4.2.x branch. They should
be merged from 4.2.x to 4.3.x, and then from 4.3.x to trunk.
It has been a long time since I've worked actively on the stdcxx project, but
On Wed, May 16, 2012 at 5:47 AM, Stefan Teleman
wrote:
>
> I am going to ask the following questions in the open. Perhaps this
> way I will get an answer:
>
> 1. Apparently, "Bill's emails" were sent and replied to on the private
> list. I have not received any of them, although I am on the pr
Yes. Unfortunately I spent too much time trying to make sure I followed the
process (which I've forgotten) and not enough time making sure my code was
correct.
Will fix immediately.
Travis
> -Original Message-
> From: Martin Sebor [mailto:mse...@gmail.com]
> Sent: Wednesday, February 0
While often have little or no time for extracurricular activities, I'm willing
to start participating on a limited basis.
So -1.
Travis
-Original Message-
From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net]
Sent: Thursday, February 02, 2012 9:04 AM
To: dev@stdcxx.apache.org
Subject:
Martin Sebor wrote:
>
>Farid Zaripov wrote:
>> The latest build results on 4.2.x branch generated at Mon
>> Sep 8 15:00:25...
>
>I'm traveling this week and won't be back until next Wednesday
>but unless it gets resolved in the meantime I'll look into it
>as soon as I get back.
>
>In the meanti
Martin Sebor wrote:
>
>faridz wrote:
>>
>>
>> URL: http://svn.apache.org/viewvc?rev=693424&view=rev
>> Log:
>> 2008-09-09 Farid Zaripov <[EMAIL PROTECTED]>
>>
>> * tests/regress/18.c.limits.stdcxx-988.cpp: Resolved compilation
>> error on MSVC and ICC/Windows.
>>
>> Modified:
>>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
>Author: faridz
>Date: Tue Sep 9 03:20:19 2008
>New Revision: 693419
>
>URL: http://svn.apache.org/viewvc?rev=693419&view=rev
>Log:
>2008-09-09 Farid Zaripov <[EMAIL PROTECTED]>
>
> Merged r693416 from branc
Travis Vitek wrote:
>
>Are you sure you don't want to be using _RWSTD_DECLARE_NOTHROW
>here, and _RWSTD_DEFINE_NOTHROW with the definition. I only see
>_RWSTD_ATTRIBUTE_NOTHROW being defined for gcc, and that means
>compile error for all other configurations.
>
>What
>Author: sebor
>Date: Tue Jul 29 09:24:16 2008
>New Revision: 680756
>
>Modified: stdcxx/branches/4.2.x/include/loc/_codecvt.h
>URL:
>http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/include/loc/
>_codecvt.h?rev=680756&r1=680755&r2=680756&view=diff
>===
Martin Sebor wrote:
>
>Farid Zaripov wrote:
>
>> Martin Sebor wrote:
>>>
>>> ...attached is a test case I got from a fellow attendee of my
>>> meeting for what at first blush looks like a COW bug in
>>> stdcxx string. The expected output on line 4 is:
>>>
>>> 2. cc1: 'H'
>>>
>>
>> 21.3.1 p4:
>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.
>
It seems that
We currently have the _RWSTD_TT_* macros (referred to below as _TT_
macros). The original intent was to define them to the compiler built-in
for the named type trait. I.e., _RWSTD_TT_IS_POD(T) would expand to
__is_pod(T) on those systems that supply the __is_pod() built-in.
While porting the trai
Martin Sebor wrote:
>
>Travis Vitek wrote:
>> I've already implemented fallback support for many traits. Here is a
>> list of those that I can think of off of the top of my head...
>>
>> __rw_is_class
>> __rw_is_union
>>
Travis Vitek wrote:
>
>
>As I see it, my options are...
>
> 1. put code that will prevent instantiation in the the type
>declaration (i.e. static_assert)
> 2. provide a suitable default that is not correct, but can be
>used to detect the failure
> 3.
I've already implemented fallback support for many traits. Here is a
list of those that I can think of off of the top of my head...
__rw_is_class
__rw_is_union
__rw_is_empty
__rw_is_polymorphic
__rw_is_abstract
__rw_is_convertible
__rw_is_ba
Martin Sebor wrote:
>Travis Vitek wrote:
>> Martin Sebor wrote:
>>> Travis Vitek (JIRA) wrote:
>>>>
>>>> Well, most of these failures are destined to fail until the
>>> test is rewritten.
>>>
>>> Are you sure you meant that t
Martin Sebor wrote:
>
>Travis Vitek (JIRA) wrote:
>>
>> Well, most of these failures are destined to fail until the
>test is rewritten.
>
>Are you sure you meant that the test needs to be rewritten?
>(I'm trying to reconcile that with your subsequent comment
Eric Lemings wrote:
>
>> Eric Lemings wrote:
>>
>> 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
I'm unsure about what you me
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> This all seems to work when using the trait with a
>> non-template type. If you want to use a template, it
>> has to be instantiated first. I think I'm going to
>> put the Edison compiler
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Not always. If the template is instantiated the error would
>> not be seen.
>
>The reason I ask is because I couldn't get even a simple SFINAE
>test program to compile. I think the program is
Martin Sebor wrote:
>
>Travis Vitek wrote:
>> I'm porting the traits to the EDG compiler, and I'm running into
>> failures in the test suite. Here is a simple testcase to
>> illustrate...
>>
>> $ cat t.cpp && eccp t.cpp
>>
>Martin Sebor wrote:
>
>Anyone else seeing major delays in list mail delivery? I sent
>a response to Travis' post Re: Potential eccp-3.9 bug at 3:36
>MDT. It's now 3:53 and I still don't see it (I do see it in
>archives: http://markmail.org/message/35nmnhmbrlysknhv).
>
>I wonder if the problem i
I'm porting the traits to the EDG compiler, and I'm running into
failures in the test suite. Here is a simple testcase to illustrate...
$ cat t.cpp && eccp t.cpp
template
struct S
{
};
const bool a = __has_trivial_constructor( S<1> );
"t.cpp", line 6: error: an incomplete class ty
Martin Sebor wrote:
>
>Eric Lemings wrote:
>>
>> 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
Martin Sebor wrote:
>
>Eric Lemings wrote:
>>
>>
>>> Travis Vitek wrote:
>>>
>>>
>>> Eric Lemings wrote:
>>>>> Travis Vitek wrote:
>>>>>
>>>>> The tuple is holding the original pointer
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 == \&qu
>Author: elemings
>Date: Tue Jul 8 16:13:36 2008
>New Revision: 675044
>
>URL: http://svn.apache.org/viewvc?rev=675044&view=rev
>Log:
>2008-07-08 Eric Lemings <[EMAIL PROTECTED]>
>
> STDCXX-958
> * include/tuple: Second parameter in value move ctor of pair
> specialization mi
Eric Lemings wrote:
>
>> Martin Sebor wrote:
>>
>> 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 wo
Martin Sebor wrote:
>
>Eric Lemings wrote:
>>
>>
>>> Martin Sebor wrote:
>>>
>>> Travis Vitek wrote:
>>>>
>>> [...]
>>>> If you ask what I prefer, I'm going to tell you I prefer the second
>>>>
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
$ gma
) cleaner by not having to check
for each feature (as I recently did to the tuple tests). I hate having
to look at hacky workarounds unless they are absolutely necessary.
Travis
>Brad.
>
>> -Original Message-
>> From: Travis Vitek
>>
>>
>> Yes, I'
Martin Sebor wrote:
>
>Martin Sebor wrote:
>> The mangling of std::aligned_union depends on support for variadic
>> templates in that specializations of the template will be mangled
>> differently depending on whether _RWSTD_NO_VARIADIC_TEMPLATES is
>> #defined or not. It seems that it should be
In an effort to better organize the type traits, I'm attempting to
figure out what traits we expect to be using in the implementation.
I see that the tuple implementation is using __rw_remove_reference and
that there are already some parts of the library that use __rw_is_same
(from rw/_select.h)
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>[...]
>> Originally I wanted separate headers for each trait, but it was
>> determined that the overhead from including all of these small files
>> would be to much, so I suggested splitting traits up into
Martin Sebor wrote:
>
>Eric Lemings wrote:
>>
>>
>>Martin Sebor wrote:
>>>
>>> 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
Martin Sebor wrote:
>Travis Vitek wrote:
>>
>>
[...]
>
>I can think of a couple of options that satisfy these. I'm not sure
>how palatable I find them yet, but I might get over their (initial)
>lack of appeal if the payoff is worth it. YMMV.
>
>One is
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
>>> The implementation of Unary Traits (e.g., is_void) uses explicit
>>> specialization on all four combinations of cv-qualifiers for each
>>> trait (plain, const, vola
Martin Sebor wrote:
>
>[EMAIL PROTECTED] wrote:
>> Author: vitek
>> Date: Thu Jun 26 15:48:21 2008
>> New Revision: 672048
>>
>> URL: http://svn.apache.org/viewvc?rev=672048&view=rev
>> Log:
>> 2008-06-27 Travis Vitek <[EMAIL P
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
>>> I searched library headers and sources for how we define unions and
>>> with the exception of limits_bits.cpp we always follow this rule.
>>> Unless there is a rea
Martin Sebor wrote:
>
>I searched library headers and sources for how we define unions and
>with the exception of limits_bits.cpp we always follow this rule.
>Unless there is a reason not to make this change to aligned_union,
>I think we should change both limits_bits.cpp and aligned_union to
>a
>Eric Lemings wrote:
>> Martin Sebor
>>
>> 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:
>>
>>
Martin Sebor wrote:
>Eric Lemings wrote:
>>
>>
>>> -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
Sorry for top posting...
Yes, the __rw_is_convertible_impl::_C_make should probably be changed to
return __rw_remove_cv<_TypeT>::type (probably with a typedef). We should
probably add a case for this in the 20.meta.rel.cpp test also.
I'm on vacation today otherwise I'd make the necessary chang
Martin Sebor wrote:
>
>Martin Sebor wrote:
>> The mangling of std::aligned_union depends on support for variadic
>> templates in that specializations of the template will be mangled
>> differently depending on whether _RWSTD_NO_VARIADIC_TEMPLATES is
>> #defined or not. It seems that it should be
Martin Sebor wrote:
>
>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
>"dispatch
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>> I'm not absolutely sure I'm reading the documentation you linked to
>> correctly, but here goes...
>
>It's possible that I misread the text. I was pretty sure (and still
>am) I remembered disc
>-Original Message-
>From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
>Sent: Thursday, June 26, 2008 3:31 PM
>To: dev@stdcxx.apache.org
>Subject: Re: status of with gcc
>
>Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
>>> Travis Vitek wrote:
>>>> I'm absolutely certain it worked in the recent past, but
>I'll go back
>>>> and do a build to make sure I'm not to
Martin Sebor wrote:
>
>I'm getting compilation errors with gcc 4.3. Is the implementation
>supposed to be stable at this point with any compiler or are there
>still some major issues?
>
I just did a sync of 4.3.x and a build with CXXFLAGS="-std=gnu++0x
-D_RWSTD_EXT_CXX_0X" and didn't run into a
Martin Sebor wrote:
>Martin Sebor wrote:
>> Travis Vitek wrote:
>[...]
>>>>> The draft shows a 'typical implementation' of
>aligned_storage that
>>>>> uses the new alignas keyword,
>>>>> but alignas doesn't appear to
Martin Sebor wrote:
>Travis Vitek wrote:
>>
>> I'm absolutely certain it worked in the recent past, but I'll go back
>> and do a build to make sure I'm not totally insane.
>>
>
>You don't need to. Do a search among the older build l
Martin Sebor wrote:
>
>Eric Lemings wrote:
>>
>> Martin Sebor wrote:
>>>
>>> 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
>> metafunctio
>Martin Sebor wrote:
>Travis Vitek wrote:
>> Martin Sebor wrote:
>>
>>> If this is true, we might want to change
>>> the exec utility (which does the redirection) to send the output of
>>> tests somewhere else.
>>>
>>
>> Sur
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>> Here is a testcase...
>>
>> $ cat z.cpp && g++ --version && g++ -c z.cpp
>>
>> template
>> struct __rw_aligned_storage {
>> typedef struct {
>>
>Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> I could implement the specializations of the helper for all possible
>> values up to the upper limit and then let the compiler puke when it
>> can't honor the alignment that was requested. I
Martin Sebor wrote:
>
>Travis Vitek wrote:
>> 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 t
Eric Lemings wrote:
>
>
>Anyone recall if some compilers might have problems and/or issue
>warnings about unnamed template parameters? E.g.,
>
> template struct S;
>
Martin mentioned in a review of your code that he remmbers it not being
safe on at least one compiler. I have not encount
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
[...]
>>
>> The only functionality I have available
>> to me for
>> doing alignment (on the tested platforms) is __declspec(align(#)) on
>> Microsoft and __attribute__ ((aligned(#))) on gcc-4.3. Both
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.codecv
Martin Sebor wrote:
>
>[EMAIL PROTECTED] wrote:
>> Author: vitek
>> Date: Thu Jun 19 15:52:34 2008
>> New Revision: 669735
>>
>> URL: http://svn.apache.org/viewvc?rev=669735&view=rev
>> Log:
>> 2008-06-19 Travis Vitek <[EMAIL
>
>Author: elemings
>Date: Thu Jun 19 15:09:13 2008
>New Revision: 669723
>
>URL: http://svn.apache.org/viewvc?rev=669723&view=rev
>Log:
>2008-06-19 Eric Lemings <[EMAIL PROTECTED]>
>
> STDCXX-958
[...]
>+template
>+_TYPENAME tuple_element<_Index, tuple<_Head, _Tail...> >::_Ref
>+get (
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>> Eric Lemings wrote:
>>>
>>> Page 490, section 20.3.1.2, paragraph 1 in the latest draft
>>> says this:
>>>
>>> "Let Ui be decay::type for each Ti in Types. Then each
>
Eric Lemings wrote:
>
>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
>
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>> Martin Sebor wrote:
>>> While looking at the hoops we jump through to implement
>>> aligned_storage
>>> I recalled the gcc __attribute__ (aligned (N)). Is there
>>> any to use it to sim
Martin Sebor wrote:
>
>While looking at the hoops we jump through to implement aligned_storage
>I recalled the gcc __attribute__ (aligned (N)). Is there any to use it
>to simplify the implementation for gcc?
We already do. Have a look at the definition of the macro
_RWSTD_TT_ALIGNED_POD().
I m
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>> Martin Sebor wrote:
>>>
>>> The test fails to compile with HP aCC 3.63. The error messages
>>> point to the patch for the issue:
>>>
>>> http://svn.apache.org/viewvc?view=rev&
>Martin Sebor wrote:
>
>The test fails to compile with HP aCC 3.63. The error messages
>point to the patch for the issue:
>
> http://svn.apache.org/viewvc?view=rev&revision=629550
Actually, I think it was me that caused the problem, in the following
change:
http://svn.apache.org/viewvc?v
Martin Sebor wrote:
>
>[EMAIL PROTECTED] wrote:
>> Author: vitek
>> Date: Mon Jun 16 16:35:21 2008
>> New Revision: 668347
>>
>> URL: http://svn.apache.org/viewvc?rev=668347&view=rev
>> Log:
>> 2008-06-16 Travis Vitek <[EMAIL PROTECTE
>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 _R
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
>
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?
>>&
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 M
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 cor
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 w
Martin Sebor wrote:
>Eric Lemings wrote:
>> Consider the following:
>>
>> file $TOPDIR/include/memory:
>> ...
>> 30 #ifndef _RWSTD_MEMORY_INCLUDED
>> 31 #define _RWSTD_MEMORY_INCLUDED
>> 32
>> 33 #include
>> 34 #include
>> 35 #include
>> 36 #include
>> 37 #include
>> 38 #include
>>
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 l
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 thin
Eric Lemings wrote:
>
>
>> Author: vitek
>> Date: Thu Jun 19 16:58:34 2008
>> New Revision: 669747
>...
>>
>> +#include
>>
>
>Uhgh. The missing underscore in that header name just really bugs me
>for some reason. Any objections to renaming it as
>and updating all code that includes it?
>Eric Lemings wrote:
>
>>
>> If that is right, then it essentially says that the 'make_tuple'
>> function transforms reference_wrapper back to T& and for
>> other types does the normal decay transformation [function to
>> funciton pointer, array to array pointer, and cv-stripping of
>> all oth
>Eric Lemings wrote:
>
>Page 490, section 20.3.1.2, paragraph 1 in the latest draft says this:
>
>"Let Ui be decay::type for each Ti in Types. Then each Vi in VTypes
>is X& if Ui equals reference_wrapper,
>otherwise Vi is Ui."
>
>What do you suppose the relationship is between type `X' and ty
Eric Lemings wrote:
>
>> Travis Vitek wrote:
>>
>> So you see no problem with the following code failing at
>> runtime due to misalignment or insufficient space?
>>
>> struct incomplete_t;
>>
>> // supposed to be 'suitable for u
>Eric Lemings wrote:
>
>> Travis Vitek wrote:
>>
>>
>> I'm looking at the standard, and it appears that the following is
>> legal...
>>
>> struct incomplete_t;
>>
>> std::aligned_union<0, void, incomplete_t&
I'm looking at the standard, and it appears that the following is
legal...
struct incomplete_t;
std::aligned_union<0, void, incomplete_t>::type
aligned_t;
Does anyone have any idea what the expected behavior of such code would
be? The comments in table 51 of the current draft say
t
>Eric Lemings wrote:
>
>> Travis Vitek wrote:
>>
>> >Eric Lemings wrote:
>> >
>> >How about member templates? Are these unilaterally supported by all
>> >compilers now?
>> >
>>
>> From below...
>>
>Eric Lemings wrote:
>
>Should we define _RWSTD_STATIC_ASSERT as a no-op if _RWSTDDEBUG is
>defined?
I don't think so.
I expect to use static assertions in the traits classes to ensure that
the user is instantiating the trait templates on valid types. If this is
compiled out then I have to ad
t seems all of the compilers we support are happy. If you
move the definition out, then all bets are off.
>Brad.
>
>Martin Sebor wrote:
>>
>> Travis Vitek wrote:
>> >
>> > Eric Lemings wrote:
>> >>
>> >> Travis Vitek wrote:
>> >
>Eric Lemings wrote:
>
>I'm getting the following compile error on Linux systems:
[...]
>
>Here's the offending code:
>
> 92 union {
> 93 unsigned char __pad [_Len];
> 94 typename __rw_aligned_union<_Len, Types...>::_C_type
>__align;
> 95 } _C_type;
>
>I'm guessing t
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
mpl<> uses '_C_type' and
__rw_add_lvalue_reference<> uses 'type'.
>
>>
>> URL: http://svn.apache.org/viewvc?rev=667365&view=rev
>> Log:
>> 2008-06-12 Travis Vitek <[EMAIL PROTECTED]>
>>
>> STDCXX-916
>> * incl
1 - 100 of 277 matches
Mail list logo
