RE: [boost] Re: [MPL] Making Generators

2002-12-07 Thread Aleksey Gurtovoy
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 trying out

Re: [boost] dangerous_cast

2002-12-07 Thread Gabriel Dos Reis
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 intermediate step

Re: [boost] Re: dangerous_cast

2002-12-07 Thread Gabriel Dos Reis
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 | dynamic type

Re: [boost] Re: [MPL] Making Generators

2002-12-07 Thread David Abrahams
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 can test it

Re: [boost] [Config] Testing instructions for compiler vendors

2002-12-07 Thread Douglas Gregor
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

Re: [boost] [Config] Testing instructions for compiler vendors

2002-12-07 Thread Peter Dimov
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 prefer

Re: [boost] [Config] Testing instructions for compiler vendors

2002-12-07 Thread David Abrahams
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 should be

Re: [boost] [MPL] Making Generators

2002-12-07 Thread David A. Greene
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_

[boost] Re: dangerous_cast

2002-12-07 Thread Gennaro Prota
On 07 Dec 2002 12:26:35 +0100, Gabriel Dos Reis [EMAIL PROTECTED] wrote: 5.2.10/1: The result of the expression reinterpret_castT(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 please

[boost] Re: Re: dangerous_cast

2002-12-07 Thread Eric Woodruff
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, h.storage

[boost] Re: OpenVMS file name compatibility

2002-12-07 Thread Johan Nilsson
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 source to an OpenVMS

[boost] Re: dangerous_cast

2002-12-07 Thread Gennaro Prota
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_castT(v) is the result of converting the expression v to type T. [...] Are you saying you

Re: [boost] [Config] Testing instructions for compiler vendors

2002-12-07 Thread David Abrahams
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 applies only to

Re: [boost] Re: dangerous_cast

2002-12-07 Thread Gabriel Dos Reis
Gennaro Prota [EMAIL PROTECTED] writes: [...] | Well, in fact those subsequent paragraphs intentionally give very few | guarantee, and reinterpret_castvoid* 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

Re: [boost] Re: dangerous_cast

2002-12-07 Thread Gennaro Prota
--- Gabriel Dos Reis [EMAIL PROTECTED] wrote: Gennaro Prota [EMAIL PROTECTED] writes: [...] | Well, in fact those subsequent paragraphs intentionally give very few | guarantee, and reinterpret_castvoid* is exactly one of the cases | which are left unspecified (the guarantee of 5.2.10/7

Re: [boost] Proposed Boost config macro

2002-12-07 Thread David Abrahams
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 the best I

Re: [boost] Re: dangerous_cast

2002-12-07 Thread Gabriel Dos Reis
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_castvoid* is exactly one of the cases | |

[boost] License: Apache

2002-12-07 Thread David Abrahams
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

[boost] License: Apple Public Source

2002-12-07 Thread David Abrahams
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

Re: [boost] Proposed Boost config macro

2002-12-07 Thread Mark Rodgers
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 happy with it, but...

Re: [boost] SourceForge Vandalism

2002-12-07 Thread Dan Nuffer
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

Re: [boost] Proposed Boost config macro

2002-12-07 Thread David Abrahams
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. What do you want to call it?