David Abrahams wrote:
> > MPL's implementation ("boost/mpl/aux_/has_xxx.hpp") is
> > known to work on Comeau, Intel (all versions), MSVC (all versions),
> > Metroweks 8.3/8.2 and GCC 3.2. There is no known way to make it
> > work on Borland. You can test it against any other compiler by
> > tryi
David A. Greene wrote:
> But consider this testcase:
>
> //#define CT_DEBUG
>
> //#include "ct_print.hh"
> #include
> #include
>
> template
> struct my_type {
> };
>
> template
> struct my_type_generator {
>typedef my_type type;
> };
>
> template class Base,
>typename T, typename
Hi,
Anthony Williams <[EMAIL PROTECTED]> writes:
[...]
| > You made youself clear.
| >
| > However, there are two running issues originating from a claim of Dave
| > that dangerous_cast<> might be better than reinterpret_cast<> in
| > casting from U* to T* (dangerous_cast<> uses the inter
"Eric Woodruff" <[EMAIL PROTECTED]> writes:
[...]
| > Thus, given that h.storage is properly aligned, (which is the purpose of
| the
| > other union member), after "new(h.storage) Foo", h.storage contains a Foo
| > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the
| > dyn
> I'm still not sure that BOOST_STRICT_CONFIG is the right macro to
determine if
> workarounds are enabled or not, but if John agrees then I'm happy with it.
> Regardless of what macro determines which BOOST_WORKAROUND is used, I like
> the above definition (+ dumb compiler workarounds).
OK let me
> If this fails to compile, we may need to add a dummy "return 0;" at
> the end. I know of two compilers which act this way: Metrowerks and
> HP.
What do you want to call it?
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> > MPL's implementation ("boost/mpl/aux_/has_xxx.hpp") is
>> > known to work on Comeau, Intel (all versions), MSVC (all versions),
>> > Metroweks 8.3/8.2 and GCC 3.2. There is no known way to make it
>> > work on Borland. You
On Saturday 07 December 2002 06:47 am, John Maddock wrote:
> Maybe we need something new for those folks: something like
> BOOST_NO_WORKAROUNDS or whatever, that disables all compiler workarounds?
> To keep things centralised BOOST_NO_WORKAROUNDS should be defined by the
> compiler config when the
From: "Douglas Gregor" <[EMAIL PROTECTED]>
> On Saturday 07 December 2002 06:47 am, John Maddock wrote:
> > Maybe we need something new for those folks: something like
> > BOOST_NO_WORKAROUNDS or whatever, that disables all compiler
workarounds?
[...]
>
> I like it.
Looks reasonable, although I'd
Douglas Gregor <[EMAIL PROTECTED]> writes:
> On Saturday 07 December 2002 06:47 am, John Maddock wrote:
>> Maybe we need something new for those folks: something like
>> BOOST_NO_WORKAROUNDS or whatever, that disables all compiler workarounds?
>> To keep things centralised BOOST_NO_WORKAROUNDS sho
From: "David Abrahams" <[EMAIL PROTECTED]>
> > I like it.
>
> I don't (yet). Why do we need yet another macro which means "turn off
> the workarounds?" Would BOOST_STRICT_CONFIG then be obsolete?
I think that the idea is that BOOST_STRICT_CONFIG applies only to unknown
compiler versions, and BOOST
Aleksey Gurtovoy wrote:
That's because the MPL's lambda works only with metafunctions which template
parameters are _types_, and only types:
That's what I suspected.
3) a metafunction with template template parameter, can't be used in lambda
expressions:
Again, what I suspected.
It _is_ p
On 07 Dec 2002 12:26:35 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
>5.2.10/1:
> The result of the expression reinterpret_cast(v) is the result of
> converting the expression v to type T. [...]
Are you saying you really understand what that phrase means? Can you
explain it, and say plea
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Eric Woodruff" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | > Thus, given that h.storage is properly aligned, (which is the purpose
of
> | the
> | > other union member), after "new(h.storage) Foo
"Eric Woodruff" <[EMAIL PROTECTED]> writes:
| "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| > "Eric Woodruff" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | > Thus, given that h.storage is properly aligned, (which is the purpose
| of
"David Abrahams" <[EMAIL PROTECTED]> skrev i meddelandet
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Johan Nilsson" <[EMAIL PROTECTED]> writes:
>
> > [cross-posted, but it seemed appropriate]
> >
> > Hi,
> >
> > just wanted to bring this one up: I've come across some problems putting
> > boost
On Sat, 07 Dec 2002 17:16:42 +0100, Gennaro Prota
<[EMAIL PROTECTED]> wrote:
>On 07 Dec 2002 12:26:35 +0100, Gabriel Dos Reis
><[EMAIL PROTECTED]> wrote:
>
>
>>5.2.10/1:
>> The result of the expression reinterpret_cast(v) is the result of
>> converting the expression v to type T. [...]
>
>Are yo
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>> > I like it.
>>
>> I don't (yet). Why do we need yet another macro which means "turn off
>> the workarounds?" Would BOOST_STRICT_CONFIG then be obsolete?
>
> I think that the idea is that BOOST_STRICT_CONFIG
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| Well, in fact those subsequent paragraphs intentionally give very few
| guarantee, and reinterpret_cast is exactly one of the cases
| which are left unspecified (the guarantee of 5.2.10/7 concerns casting
| to pointers to *object types*). So I gue
--- Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> Gennaro Prota <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Well, in fact those subsequent paragraphs intentionally give very few
> | guarantee, and reinterpret_cast is exactly one of the cases
> | which are left unspecified (the guarantee of 5.2.1
"John Maddock" <[EMAIL PROTECTED]> writes:
>> If this fails to compile, we may need to add a dummy "return 0;" at
>> the end. I know of two compilers which act this way: Metrowerks and
>> HP.
>
> What do you want to call it?
I'm not happy with it, but...
BOOST_NO_NON_RETURN_PATH_COMPREHENSION is
Gennaro Prota <[EMAIL PROTECTED]> writes:
| --- Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > Gennaro Prota <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | Well, in fact those subsequent paragraphs intentionally give very few
| > | guarantee, and reinterpret_cast is exactly one of the case
My summary of the Apache license is now available at
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Apache_Software_License
Reminder: If you haven't done one yet, please take a moment to review
one of the licenses at
http://www.crystalclearsoftware.com/cgi-bin/boost
David Abrahams <[EMAIL PROTECTED]> writes:
My summary of the Apple Public Source license is now available at
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Apple_Public_Source_License
Reminder: If you haven't done one yet, please take a moment to review
one of the
From: "David Abrahams" <[EMAIL PROTECTED]>
> "John Maddock" <[EMAIL PROTECTED]> writes:
>
> >> If this fails to compile, we may need to add a dummy "return 0;" at
> >> the end. I know of two compilers which act this way: Metrowerks and
> >> HP.
> >
> > What do you want to call it?
>
> I'm not hap
Jeff Garland wrote:
Point taken. I could probably try to do the same as sourceforge.
Put the Wiki data backup in a public place that others could
copy down on a daily basis -- you for example :-)
I've started running my boost backup script.
Could you let me know the URL when you've got the wik
"Mark Rodgers" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>> "John Maddock" <[EMAIL PROTECTED]> writes:
>>
>> >> If this fails to compile, we may need to add a dummy "return 0;" at
>> >> the end. I know of two compilers which act this way: Metrowerks and
>> >> HP.
>>
27 matches
Mail list logo
