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
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
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
[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
[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
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_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 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
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<>
--- 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.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] Re: dangerous_cast<>
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 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] [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
[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_cast(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_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 guess there's not much room for proving your equivalence. Genny. ___ 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 .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
Re: [boost] Re: Re: dangerous_cast<>
"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 | > | 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. Not necessarily: It is permitted to have the source type be identitical to the target type. But that is a minor nit. | 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. Certainly, there is no reinterpret_cast<> happening here. However, the result of reinterpret_cast<>ing a Foo* to void* is the result of converting a Foo* to void* (that is what I understand from 5.2.10/1), therefore the two happen to have the same value there. | 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. I'm afraid I don't undertand this part. Could you elaborate? What do you mean by "The size of char is not necessarily 1 byte". | Again, however, I mentioned in a different post that we could always force a | reinterpret_cast<> via new (reinterpret_cast (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. Anthony convincingly showed that provided (1) h.storage is properly aligned (2) an object is properly constructed at h.storage the type rules allows one to reinterpret_cast<>/static_cast<> to a Foo* -- even an implementation that monitors memory access ought to to accept that usage. Or do you think I misundertstand your point? -- Gaby ___ 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_cast (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: 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_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 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
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:
template
struct my_type { ... } // Note: no ::type member
typedef SHAZAM > generator;
typedef generator::template apply::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
Re: [boost] [Config] Testing instructions for compiler vendors
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. ___ 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] [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
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] 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] Proposed Boost config macro
> 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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
> 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 try and explain what I had in mind when those macros were introduced: BOOST_NO_XXX_CONFIG: disables automatic configuration of compiler/stdlib/platform, generally used in conjunction with a customised boost/config/user.hpp to prevent dependencies on the config system. Should *not* disable compiler workarounds. BOOST_STRICT_CONFIG: defined when the user is testing a new compiler version (one newer than boosts automatic config is aware of, and which may or may not require configuration), should disable compiler specific fixes only if the compiler version is greater than the last version we've tested. Remember these were designed for users, not compiler vendors. 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 ___ 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] 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_cast(&foo) give a different from static_cast(&foo)? I think the answer is simple: No. The reason is that 5.2.10/1: The result of the expression reinterpret_cast(v) is the result of converting the expression v to type T. [...] and converting a Foo* to void* is well-defined. Next, reinterpret_cast(&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_cast 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] [MPL] Making Generators
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 U, typename V>
> struct trivial_generator {
>typedef Base type;
> };
>
> int main(void)
> {
>typedef my_type_generator generator;
>//CT_PRINT(my_type_generator_result_is, generator::type);
>
>typedef trivial_generator t_generator;
>//CT_PRINT(trivial_generator_result_is, t_generator::type);
>
>// Try to make some generators
>typedef boost::mpl::lambda boost::mpl::_2> >::type lambda_generator;
>typedef lambda_generator::apply lg_apply_result;
>//CT_PRINT(lambda_generator_result_is, lg_apply_result::type);
>
>// Does not work
>typedef boost::mpl::lambda boost::mpl::_1, boost::mpl::_2> >::type lambda_trivial_generator;
>// g++ 3.2 claims apply doesn't exist.
>typedef lambda_trivial_generator::apply ltg_result;
>//CT_PRINT(lambda_trivial_generator_result_is, ltg_result::type);
>
>return(0);
> }
>
That's because the MPL's lambda works only with metafunctions which template
parameters are _types_, and only types:
1) a "canonical" metafunction, OK:
template< typename T > struct identity
{
typedef T type;
};
typedef lambda< identity<_> >::type f;
BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int);
2) a metafunction with non-type template parameter, can't be used in lambda
expressions:
template< typename T, int i = 0 > struct identity
{
typedef T type;
};
typedef lambda< identity<_> >::type f;
BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int); // error!
3) a metafunction with template template parameter, can't be used in lambda
expressions:
template< typename T > struct something;
template< typename T, template< typename > class F = something > struct
identity
{
typedef T type;
};
typedef lambda< identity<_> >::type f;
BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int); // error!
Strictly speaking, (2) and (3) are not even metafunctions in MPL's
terminology.
>
> >>But I can construct a generic trivial generator:
> >>
> >>template class Base,
> >> typename T, typename U, typename V>
> >>struct trivial_generator {
> >>typedef Base type;
> >>};
> >>
> >>Then I can use MPL lambda facilities. Unfortunately, I need a
> >>trivial_generator for every arity of class template.
> >
> > Only as part of the implementation. You just need a nice
> > wrapper over the top to hide it all.
>
> Right. Can you point me to the MPL equivalent as a guide of
> how to do this?
Actually, even ignoring the aforementioned lambda issue, it's not possible
to write a single template (a wrapper or not) that would take template
template parameters of different arity - if it were, the library itself
would use the technique to implement the single 'quote/mem_fun' template
instead of providing the family of 'mem_fun1', 'mem_fun2', etc. constructs.
It _is_ possible to implement a single template along the lines of the
SHAZAM template you've mentioned early in the thread:
template
struct my_type { ... } // Note: no ::type member
typedef SHAZAM > generator;
typedef generator::template apply::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).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
