RE: [boost] Re: [MPL] Making Generators
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 boost/libs/mpl/test/aux_/has_xxx.cpp test case. It also works with GCC 2.95.2 with some restrictions. I don't remember what they are offhand. Something like that the type must be a class? ... that doesn't sound quite right because we could work around it with an is_class pre-test. I wouldn't call it works: it returns 'true' if the member exists, otherwise it fails with a compilation error (whether the tested type is a class or not). Or it would fail if we didn't #ifdef'ed it to always return 'false'. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] dangerous_cast
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 | void* via static_cast). | | 1) is dangerous_cast better than reinterpret_cast? | | 2) is it well-defined to dereference the value obtained from | | U* - void* - T* | |? | | You've showed that si U == char, (the case in Dave's example) then it | is well-formed. The other cases are left undefined. | | So the key question (1) is still unanswered. | | Well, given that we have a valid use when U==(unsigned) char, I think it is | certainly better than reinterpret_cast in that case. I returned back and checked the standard paragraph from which you quoted decivise texts; you said: Also, 3.9.2p4 says: Objects of cvqualified (3.9.3) or cvunqualified type void* (pointer to void), can be used to point to objects of unknown type. A void* shall be able to hold any object pointer. A cvqualified or cvunqualified (3.9.3) void* shall have the same representation and alignment requirements as a cvqualified or cvunqualified char*. So casting a void* to/from a char* is a no-op. I tend to find that quite conviincing (and agree with you), except that it doesn't say that both pointer have the same *value* representation as it explicitly says in a paragraph just before: 3.9.2/3 [...] Pointers to cv-qualified and cv-unqualified versions (3.9.3) of layout-compatible types shall have the same value representation and align-ment requirements (3.9). I'm not sure whether 1) the difference in wordings is intended; 2) really matters in the specific case we're discussing. Now, let me attempt to address this key question I repeatedly asked Can reinterpret_castvoid*(foo) give a different from static_castvoid*(foo)? I think the answer is simple: No. The reason is that 5.2.10/1: The result of the expression reinterpret_castT(v) is the result of converting the expression v to type T. [...] and converting a Foo* to void* is well-defined. Next, reinterpret_castchar*(foo) is well-defined as char* and void* are intended to have the same memory-alias properties. I hope, that is not word-game. | However, for (2), it is only safe to dereference the resulting pointer if | there is a T at the location that the final T* points to. This is true | irrespective of what U is. However, there are very few cases in which you are | guaranteed to be able to get a valid U* that holds a valid T* --- given that U | and T may have different alignment requirements, and an implementation is | permitted to drop any unnecessary info from pointers, so T* and U* may only | store addresses which are valid multiples of the alignment for T and U | respectively, so it is unlikely that you would get a valid case, unless there | was special dispensation. | | One of these is U==char or void, as I showed. | | Another case to consider is when U is a POD-struct and T is the type of the | first data member (or vice-versa). In this case, reinterpret_cast is | guaranteed to work (9.2p17), so what about dangerous_cast? IMO, there is no | guarantee, though I would be surprised if it didn't work. Indeed, I read the | note on that paragraph to indicate that the intent is that the address is the | same, and thus static_castvoid* will yield the same result. However, I can't | find any normative guarantee. | | A third case to consider is when T and U are the types of members of the same | union. In this case, reinterpret_cast to a pointer to the union type and | back is guaranteed (since the members are to be allocated as if they were the | only member of a struct), and I would be surprised if it didn't work, but I | can't find a normative guarantee. I think I understand of the two issues you raised. I'll try to address them in a a different posting. Thanks for your analysis and patience, -- Gab ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast
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 of the object. | | | This is precisely my reasoning why reinterpret_cast is _not_ | implementation defined. | | It must be the case that it is equal to the situation of having | | Foo* - char */void* - Foo* if Foo is the dynamic type of the object. After giving more thoughts to the analysis given by Anthony and 5.2.10/1, I think I agree with you're right. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [MPL] Making Generators
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 against any other compiler by trying out boost/libs/mpl/test/aux_/has_xxx.cpp test case. It also works with GCC 2.95.2 with some restrictions. I don't remember what they are offhand. Something like that the type must be a class? ... that doesn't sound quite right because we could work around it with an is_class pre-test. I wouldn't call it works: it returns 'true' if the member exists, otherwise it fails with a compilation error (whether the tested type is a class or not). Or it would fail if we didn't #ifdef'ed it to always return 'false'. My vague memory is that it works as long as the member is not a reference type... or something. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 compilers version is greater than the last known version and BOOST_STRICT_CONFIG is set, then boost workaround-code need only check for the presence of BOOST_NO_WORKAROUNDS or whatever in addition to the compiler version. How does this sound? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm I like it. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 BOOST_DISABLE_WORKAROUNDS, as by convention BOOST_NO_XXX macros indicate defects. :-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 defined by the compiler config when the compilers version is greater than the last known version and BOOST_STRICT_CONFIG is set, then boost workaround-code need only check for the presence of BOOST_NO_WORKAROUNDS or whatever in addition to the compiler version. How does this sound? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm 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? Maybe I just don't understand the proposal, and code would help. Can you show us a rewrite of boost/detail/workaround.hpp that would correspond to what you're proposing? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
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_ possible to implement a single template along the lines of the
SHAZAM template you've mentioned early in the thread:
templatetypename T, typename U, typename V
struct my_type { ... } // Note: no ::type member
typedef SHAZAMmy_typeint, _1, _2 generator;
typedef generator::template applychar, float::type my_type_inst;
but not at the user side - the library internal mechanisms needs to be made
aware of it. I considered this before, - as well as the option of directly
supporting the reduced metafunction form, - and the latter is currently my
preference. Will see if something changes after I actually implement it (for
one, it might slow down the lambda significantly, - but we'll see).
Thanks for considering this. I think it will be quite useful. I look
forward to seeing what you come up with!
-Dave
--
Some little people have music in them, but Fats, he was all music,
and you know how big he was. -- James P. Johnson
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast
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 what notion do you assume as primitive (e.g. converting an expression)? and converting a Foo* to void* is well-defined. I don't think you can say whether a conversion is well-defined or not in C++ without considering *how* it is done. Maybe these are minor points in the context of your reasoning. Sorry if that is the case, but I tend to stop reading long posts when I hit (what I think is) the first major problem. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dangerous_cast
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 contains a Foo | object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the | dynamic type of the object. | | | This is precisely my reasoning why reinterpret_cast is _not_ | implementation defined. | | It must be the case that it is equal to the situation of having | | Foo* - char */void* - Foo* if Foo is the dynamic type of the object. After giving more thoughts to the analysis given by Anthony and 5.2.10/1, I think I agree with you're right. Well, for a reinterpret_cast to be valid, it must be used to cast away from the type, and return to it. In my example, I was only returning to it. I question the validity of that. If new (p) Object; takes a void* and does an implicit cast, I don't think there is any reinterpret_casting taking place on the inside. However, I think there must be some kind of cast to char* to allocate the memory in number of bytes, but I'm not sure. The size of char is not necessarily 1 byte, correct? So either way, this allocation implementation defines what happens. Again, however, I mentioned in a different post that we could always force a reinterpret_cast via new (reinterpret_castvoid* (h.storage)) Object, but if an implementation remembers that h.storage is an unsigned char*, or even if it doesn't, I think reinterpret_cast may only be valid to cast void* h.storage to unsigned char* h.storage. This is, of course, because of the wording of the standard. In reality, reinterpret_cast most likely has the expected result on all platforms. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: OpenVMS file name compatibility
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 system: Filenames cannot include more than
one
dot ('.') - i.e. names like whatever.cpp.html aren't allowed. The only
exception is (naturally) in directory specifications, e.g:
DISK$USER:[DIR.SUBDIR.ANOTHER_SUBDIR].
I do realize that VMS platforms might not be of highest priority, but it
sure would be nice to be compatible. And, one never knows, when(ever)
the
IA64 OpenVMS port is completed we might have a revival ;-)
[... and I've not even been able to start _building_ the boost libraries
yet - I guess I'll be in for a whole lot more of problems then ...]
Johan,
Do you know of specific problems we have? I would be a bit shocked if
VMS incompatibilities hadn't crept into the bjam sources, for example.
Haven't got that far yet. I 've just recently managed to bootstrap bjam, but
haven't had the time to actually use/test it. Boost.thread is one thing I've
been planning to use, but that's probably not going to be realized until
next year. As you say, I would also be a bit surprised if there didn't exist
any VMS incompatibilities - I've been using classic jam for a while, and
even with that one there was a problem with the dependency checking / header
scanning stuff.
I'll get back to the list once I've got something more specific. This is
unfortunately on a pretty low priority right now, and I haven't got VMS at
home ;-). It is, however, in my own interest to put in some work for VMS
compatibility.
// Johan
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast
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 really understand what that phrase means? To avoid a possible misunderstanding: I was not attacking you, that would be the last straw. It's _the sentence_ that is IMHO a little meaningless; I think it's just a rough, informal description (sort of preamble) of what is specified in the subsequent paragraphs. 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 guess there's not much room for proving your equivalence. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 unknown compiler versions, and BOOST_DISABLE_WORKAROUNDS (do we need separate compiler/library macros?) would be applied unconditionally, regardless of whether the compiler has known defects. What's the use of distinguishing those? Surely the person who's doing the testing doesn't care about whether we think we know that particular compiler version? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast
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 guess there's not much room for | proving your equivalence. Clause 4 defines, among other things, what it means to convert a T* to a void*. Certainly, that clause defines implicit conversions; but it is not just about that. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast
--- 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 concerns casting | to pointers to *object types*). So I guess there's not much room for | proving your equivalence. Clause 4 defines, among other things, what it means to convert a T* to a void*. Certainly, that clause defines implicit conversions; but it is not just about that. Yes. But, as I said, here it's a matter of *how* do you do the conversion. As to doing it with reinterpret_cast, 5.2.10/1 says: Conversions that can be performed explicitly using reinterpret_cast are listed below. No other conversion can be performed explicitly using reinterpret_cast. Where is it listed that you can do a conversion to void*? Genny. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost config macro
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 could come up with :( -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast
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 | | which are left unspecified (the guarantee of 5.2.10/7 concerns casting | | to pointers to *object types*). So I guess there's not much room for | | proving your equivalence. | | Clause 4 defines, among other things, what it means to convert a T* to | a void*. Certainly, that clause defines implicit conversions; but it | is not just about that. | | Yes. But, as I said, here it's a matter of *how* do you do the conversion. As | to doing it with reinterpret_cast, 5.2.10/1 says: | |Conversions that can be performed explicitly using reinterpret_cast | are listed below. No other conversion can be performed explicitly | using reinterpret_cast. | | Where is it listed that you can do a conversion to void*? Do you mean it is invalid to reinterpret_cast to void*? -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] License: Apache
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_wiki/wiki.pl?Boost_License Thanks, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] License: Apple Public Source
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 licenses at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License Thanks, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost config macro
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... BOOST_NO_NON_RETURN_PATH_COMPREHENSION is the best I could come up with :( What about having BOOST_UNREACHABLE_RETURN(0) or BOOST_UNREACHABLE_RETURN() I think we need to return values for types other than int. Mark ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] SourceForge Vandalism
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 wiki backup available? I'll also attach my simple script for anyone else who may want to use it. --Dan Nuffer do_boost_backup.sh Description: Bourne shell script ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost config macro
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? I'm not happy with it, but... BOOST_NO_NON_RETURN_PATH_COMPREHENSION is the best I could come up with :( What about having BOOST_UNREACHABLE_RETURN(0) or BOOST_UNREACHABLE_RETURN() I like it! I think we need to return values for types other than int. Of course. My suggestion would have just been used thus: #ifdef BOOST_NO_NON_RETURN_PATH_COMPREHENSION return whatever; #endif But I like yours better. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
