Re: [boost] Re: dangerous_cast<>
At 02:58 PM 12/9/2002, you wrote: >At 03:53 PM 12/8/2002, Gennaro Prota wrote: > >>On Sun, 08 Dec 2002 13:16:24 -0700, Greg Colvin >><[EMAIL PROTECTED]> wrote: >> >>>It may be time to post a question to [EMAIL PROTECTED] >> >>Thank you very much. What is that? An internal list for the C++ >>committee? Is it open to everybody, or you meant that *you* are going >>to post a question there? > >It is the committee's Core Working Group mailing list (which for historical reasons >is called a "reflector"). > >It is almost certainly protected against any except authorized posters. That means >committee members and "technical experts" that committee members have asked to >participate. Right. >Several committee members (Gaby, Dave Abrahams, Greg, me, etc.) will be happy to post >something on that list if the question is well-formed and is one that only committee >members can answer. But usually that only happens when Boosters have talked the issue >to death, and can't move forward without committee interpretation. And this conversation seems to have reached that point. >Boost seems to have an excellent reputation among committee members. Part of that is >because we don't bother them unneccessisarily. > >--Beman > > >___ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
At 03:53 PM 12/8/2002, Gennaro Prota wrote: >On Sun, 08 Dec 2002 13:16:24 -0700, Greg Colvin ><[EMAIL PROTECTED]> wrote: > >>It may be time to post a question to [EMAIL PROTECTED] > >Thank you very much. What is that? An internal list for the C++ >committee? Is it open to everybody, or you meant that *you* are going >to post a question there? It is the committee's Core Working Group mailing list (which for historical reasons is called a "reflector"). It is almost certainly protected against any except authorized posters. That means committee members and "technical experts" that committee members have asked to participate. Several committee members (Gaby, Dave Abrahams, Greg, me, etc.) will be happy to post something on that list if the question is well-formed and is one that only committee members can answer. But usually that only happens when Boosters have talked the issue to death, and can't move forward without committee interpretation. Boost seems to have an excellent reputation among committee members. Part of that is because we don't bother them unneccessisarily. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
Gennaro Prota writes: > On 08 Dec 2002 15:09:32 +0100, Gabriel Dos Reis > <[EMAIL PROTECTED]> wrote: > > >Gennaro Prota <[EMAIL PROTECTED]> writes: > > > >[...] > > > >| If void* is not a "pointer to an object" then reinterpret_cast > >| is invalid. Otherwise it just yields an undefined result. > > I should have said "unspecified", sorry. > > > I haven't > >| found a definition of "pointer to object" in the standard; anyhow > >| certainly void is not an object type. > > > >void* is the generic type of "pointer to object." > > Well, as I said I don't find any definition of the expression "pointer > to object" (though, of course, I do know that you can point to an > object through a void*). In any case, do you agree that at least the > result is unspecified? 3.9.2p1 says you may have: "pointers to void or objects or functions ... of a given type" Which implies that a pointer to void is not a pointer to an object of a given type. Also 1.8 says "An object is a region of storage." and "An object has a type (3.9). The term object type refers to the type with which the object is created." so void is not an object type, since you cannot create objects of type void, as it "is an incomplete type that cannot be completed." (3.9.1p9) Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
I'll raise the issue the committee reflector. Gennaro Prota <[EMAIL PROTECTED]> writes: [...] | > | char * p = ... | > | reinterpret_cast(p) | > | | > | is illegal, because the sentence above talks about conversion to *a | > | different* type. And the conversions that are not listed cannot be done with | > | reinterpret_cast). | > | > Well, some of us, by the very nature of our jobs have to make sense of | > some dispositions in the Standard. Which means we've to _interpret_ | > some portions. I don't know of any compiler that rejects the | > above on the ground of what you're saying. Do you? | | No. But it is an interpretation. Probably, faced with such a doubt a | compiler writer goes making a quick test with Comeau online and just I don't have any recollection that the authors of GCC went testing with Comeau online before implementing what is found in g++ in that respect -- and, actually, g++ is known to disagree in the new-style casts area from EDG-based compilers. | concludes that his interpretation is "too literal" :-) As you say, | this is "making sense" of a disposition. That shouldn't happen, the The Standard by its very nature *is* open to interpretation. | standard should always have a precise and unambiguous meaning, but it | happens in practice. And, to be fair, we should say that if reading | the standard is difficult writing it is even more so. I don't mind the Standard have some gray areas; the most important thing is that conflicting interpretations be resolved :-) -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
On Sun, 08 Dec 2002 13:16:24 -0700, Greg Colvin <[EMAIL PROTECTED]> wrote: >It may be time to post a question to [EMAIL PROTECTED] Thank you very much. What is that? An internal list for the C++ committee? Is it open to everybody, or you meant that *you* are going to post a question there? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
It may be time to post a question to [EMAIL PROTECTED] At 12:59 PM 12/8/2002, you wrote: >--- Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > >> I'm not saying I hold the truth. I'm offering my reading, just as others >> are doing. > >Yeah, that's ok. I meant: it's unlikely that we can really find a >quote from the standard that says the last word here. Maybe the intent >was to make reinterpret_casting to void* implementation-defined, maybe >the intent was to make it legal and equivalent to static_cast >or, maybe, the intent was to disallow it, exactly because such a >conversion is already possible with static_cast. I don't see enough >evidence to say which of the three possibilities is right, but maybe >it's just me. Frankly, I would ask to the writer. I remember that >Steve Adamczyk is the author of the paragraph about static_cast. >Probably he also wrote the one about reinterpret_cast and can say us >what was the intent. If you drop him a mail, I will be glad to be >cc-ed. > > >[...] >> | char * p = ... >> | reinterpret_cast(p) >> | >> | is illegal, because the sentence above talks about conversion to *a >> | different* type. And the conversions that are not listed cannot be done with >> | reinterpret_cast). >> >> Well, some of us, by the very nature of our jobs have to make sense of >> some dispositions in the Standard. Which means we've to _interpret_ >> some portions. I don't know of any compiler that rejects the >> above on the ground of what you're saying. Do you? > >No. But it is an interpretation. Probably, faced with such a doubt a >compiler writer goes making a quick test with Comeau online and just >concludes that his interpretation is "too literal" :-) As you say, >this is "making sense" of a disposition. That shouldn't happen, the >standard should always have a precise and unambiguous meaning, but it >happens in practice. And, to be fair, we should say that if reading >the standard is difficult writing it is even more so. > >Genny. > > >___ >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<>
--- Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > I'm not saying I hold the truth. I'm offering my reading, just as others > are doing. Yeah, that's ok. I meant: it's unlikely that we can really find a quote from the standard that says the last word here. Maybe the intent was to make reinterpret_casting to void* implementation-defined, maybe the intent was to make it legal and equivalent to static_cast or, maybe, the intent was to disallow it, exactly because such a conversion is already possible with static_cast. I don't see enough evidence to say which of the three possibilities is right, but maybe it's just me. Frankly, I would ask to the writer. I remember that Steve Adamczyk is the author of the paragraph about static_cast. Probably he also wrote the one about reinterpret_cast and can say us what was the intent. If you drop him a mail, I will be glad to be cc-ed. [...] > | char * p = ... > | reinterpret_cast(p) > | > | is illegal, because the sentence above talks about conversion to *a > | different* type. And the conversions that are not listed cannot be done with > | reinterpret_cast). > > Well, some of us, by the very nature of our jobs have to make sense of > some dispositions in the Standard. Which means we've to _interpret_ > some portions. I don't know of any compiler that rejects the > above on the ground of what you're saying. Do you? No. But it is an interpretation. Probably, faced with such a doubt a compiler writer goes making a quick test with Comeau online and just concludes that his interpretation is "too literal" :-) As you say, this is "making sense" of a disposition. That shouldn't happen, the standard should always have a precise and unambiguous meaning, but it happens in practice. And, to be fair, we should say that if reading the standard is difficult writing it is even more so. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
Gennaro Prota <[EMAIL PROTECTED]> writes: [...] | > | In any case, do you agree that at least the | > | result is unspecified? | > | > I don't think I agree with this part; at least if it means anything | > other that converting a Foo* to void*. | | Well, then I don't think we can establish "the truth" either. I'm not saying I hold the truth. I'm offering my reading, just as others are doing. | At this point we | are just trying to "crack" the standard in the hope of reading something that | probably the writer wasn't thinking of. That's often a danger in the "exegesis" | of the standard. I find it's up to the good sense of the reader to stop | investigating in such cases (just to give you an example: if you try at all | costs to read a meaning in every single word of the standard, you may conclude | that | | char * p = ... | reinterpret_cast(p) | | is illegal, because the sentence above talks about conversion to *a different* | type. And the conversions that are not listed cannot be done with | reinterpret_cast). Well, some of us, by the very nature of our jobs have to make sense of some dispositions in the Standard. Which means we've to _interpret_ some portions. I don't know of any compiler that rejects the above on the ground of what you're saying. Do you? -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
Gennaro Prota <[EMAIL PROTECTED]> writes: [...] | > I haven't | >| found a definition of "pointer to object" in the standard; anyhow | >| certainly void is not an object type. | > | >void* is the generic type of "pointer to object." | | Well, as I said I don't find any definition of the expression "pointer | to object" (though, of course, I do know that you can point to an | object through a void*). I don't know how formal you want a definition for pointer to object to be defined; but I, personnally, find 3.9.2 sfficiently acceptable. | In any case, do you agree that at least the | result is unspecified? I don't think I agree with this part; at least if it means anything other that converting a Foo* to void*. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
On 08 Dec 2002 15:09:32 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: >Gennaro Prota <[EMAIL PROTECTED]> writes: > >[...] > >| If void* is not a "pointer to an object" then reinterpret_cast >| is invalid. Otherwise it just yields an undefined result. I should have said "unspecified", sorry. > I haven't >| found a definition of "pointer to object" in the standard; anyhow >| certainly void is not an object type. > >void* is the generic type of "pointer to object." Well, as I said I don't find any definition of the expression "pointer to object" (though, of course, I do know that you can point to an object through a void*). In any case, do you agree that at least the result is unspecified? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
Gennaro Prota <[EMAIL PROTECTED]> writes: [...] | If void* is not a "pointer to an object" then reinterpret_cast | is invalid. Otherwise it just yields an undefined result. I haven't | found a definition of "pointer to object" in the standard; anyhow | certainly void is not an object type. void* is the generic type of "pointer to object." -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
On 07 Dec 2002 21:16:49 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: >Do you mean it is invalid to reinterpret_cast<> to void*? Well, I'm not sure. 5.2.10/7: "A pointer to an object can be explicitly converted to a pointer to an object of different type.65) Except that converting an rvalue of type "pointer to T1" to the type "pointer to T2" (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified. If void* is not a "pointer to an object" then reinterpret_cast is invalid. Otherwise it just yields an undefined result. I haven't found a definition of "pointer to object" in the standard; anyhow certainly void is not an object type. Genny. ___ 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] 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
[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: 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] 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
[boost] Re: dangerous_cast<>
"Anthony Williams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Eric Woodruff writes: > > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > > message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > 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. > > Nowhere do I see a requirement that supports your deductions. Indeed there are > very few requirements on reinterpret_cast<>, other than the fact that what it > does must be defined by the implementation. For pointers to objects, these > amount to: > > * T1* can be converted to T2* and back again unchanged (unless T2 has stricter > alignment requirements). Precisely, T1 is Foo in this case as you have already pointed out. This is simply the identity conversion T1 -> T2 -> T1, which is pretty much the only thing reinterpret_cast can do portably. > > * You can convert a pointer to the first member of a POD struct to a pointer > to the struct, and vice-versa. > > * A Null pointer of any type can be cast to a null pointer of any other type. > > Anthony > -- > Anthony Williams > Senior Software Engineer, Beran Instruments Ltd. > Remove NOSPAM when replying, for timely response. > > ___ > 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<>
Eric Woodruff writes: > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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. Nowhere do I see a requirement that supports your deductions. Indeed there are very few requirements on reinterpret_cast<>, other than the fact that what it does must be defined by the implementation. For pointers to objects, these amount to: * T1* can be converted to T2* and back again unchanged (unless T2 has stricter alignment requirements). * You can convert a pointer to the first member of a POD struct to a pointer to the struct, and vice-versa. * A Null pointer of any type can be cast to a null pointer of any other type. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
(inline) "Anthony Williams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [snip] > Gabriel Dos Reis writes: > unsigned char* has _additional_ properties to void* --- you can access the > object representation of _any_ object through an unsigned char* (and for PODs, > you can copy them around using this) > > 3.9p4: > "The object representation of an object of type T is the sequence of N > unsigned char objects taken up by the object of type T, where N equals > sizeof(T)." > > 3.10p15: > "If a program attempts to access the stored value of an object through an > lvalue of other than one of the following types the behavior is undefined: > > - the dynamic type of the object, > > ... > > - a char or unsigned char type." > [snip] > 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. [snip] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
David Abrahams <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > Thanks for your patience. | > | > Now, imagine an implementation where the original type is remembered, | > then dereferencing the pointer obtained from | > | >char* -> void* -> T* | > | > may just eject you into the outer space. | | Is remembering the original type _of_ _the_ _pointer_ actually legal? Why wouldn't it be valid for an implementation to remember the orginal type of the object from which the pointer is obtained? 1.8/1 [...] Some objects are polymorphic (10.3); the implementation generates information associated with each such object that makes it possible to determine that object s type during program execution. For other objects, the interpretation of the values found therein is determined by the type of the expressions (clause 5) used to access them. Since an implementation is already required to generate information to assist evaluations of polymorphic objects; what can't it do the same for non-polymorphic objects, as an extension? | Can you quote chapter and verse on this? Since: 1.9/1 [...] This International Standard places no requirement on the structure of conforming implementa-tions. [...] you don't expect me to quote chapter and verse from the Standard; do you? ;-) | I thought the implementation | was only permitted to eject you if you use a pointer where the actual | type _of_ _the_ _pointee_ is wrong. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. There is no explicit description that after the trip char* -> void* -> Foo* starting at h.storage, one can safely dereference the resulting pointer. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > Thanks for your patience. > > Now, imagine an implementation where the original type is remembered, > then dereferencing the pointer obtained from > >char* -> void* -> T* > > may just eject you into the outer space. Is remembering the original type _of_ _the_ _pointer_ actually legal? Can you quote chapter and verse on this? I thought the implementation was only permitted to eject you if you use a pointer where the actual type _of_ _the_ _pointee_ is wrong. -- 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<>
"David B. Held" <[EMAIL PROTECTED]> writes: | "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message | [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... | > David Abrahams <[EMAIL PROTECTED]> writes: | > | > | [...] | > | if is_pointer and is_pointer | > | return (dest_type)( | > | (unisgned)src | > | ^ sizeof(remove_pointer::type) | > | ^ sizeof(remove_pointer::type)); | > | > And why isn't that applicable to the trip | > | > char* -> void* -> Foo* | | First of all, because that trip with reinterpret_cast<> is even more | implementation-defined than char* -> Foo*. 1) that trip is what used in dangerous_cast<> 2) no, I was not talking of that trip with reinterpret_cast<>; yes, I was talking of dangerous_cast<>. 3) Either something is implementation-defined or it is not; the mapping of reinterpret_cast<> is implementation-defined. There is no notion of being "more implementation-defined" :-) | Second, because that | trip isn't even being proposed for reinterpret_cast<>, it's being | proposed for static_cast<>. That is exactly what I was talking about. | And third, Dave's "perverse | implementation" only applies to reinterpret_cast<>, not | static_cast<>. The question is why reinterpret_cast : char* -> T* can be perverse and not char* -> void* -> T* // arrow mapped by static_cast<>? That was the content of my question. | For the static_cast<> trip, consider: | | 4.10 Pointer conversions | | 2 An rvalue of type "pointer to cv T," where T is an object | type, can be converted to an rvalue of type "pointer to cv | void." The result of converting a "pointer to cv T" to a "pointer | to cv void" points to the start of the storage location where the | object of type T resides, as if the object is a most derived | object (1.8) of type T (that is, not a base class subobject). | | char* -> void* OK. | and | | 5.2.9 Static cast | | 10 An rvalue of type "pointer to cv void" can be explicitly | converted to a pointer to object type. A value of type pointer | to object converted to "pointer to cv void" and back to the | original pointer type will have its original value. | | void* -> Foo* OK. Please do note that the Standard says *nothing* about the meaning of derefencing the resulting pointer. Do notice how it actually takes special disposition to say that the sequence T* -> void* -> T* is the identity. Leaving the possibility that U* -> void* -> T* may just get you in the outer space. | Note that "implementation defined" and "undefined" do not | appear in either of those paragraphs. Maybe the standard | is not sufficiently clear to determine whether char* -> void* -> | Foo* has the intended effect. However, that seems to be a | legal reading of it. 1.3.12 [...] Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
David Abrahams <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > David Abrahams <[EMAIL PROTECTED]> writes: | > | > | "Eric Woodruff" <[EMAIL PROTECTED]> writes: | > | | > | > "David B. Held" <[EMAIL PROTECTED]> wrote in message | > | > aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]... | > | >> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message | > | >> aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED]... | > | >> > [snip] | > | >> > | > | >> > > holder h; | > | >> > > new (h.storage) Foo; | > | >> > | > | >> > What is the meaning of that syntax? | > | >> | > | >> This is placement new syntax. It means construct a Foo at the address | > | >> h.storage, without allocating any memory. | > | >> | > | > | > | > So the type really is of Foo, which has to mean that casting h.storage back | > | > to a Foo* using reinterpret_cast is covered by the standard. | > | | > | No, the standard only guarantees that you can do a round-trip | > | cast. The pointer didn't start out as a Foo*. The fact that it has the | > | same address as a Foo* doesn't mean anything. Just for example, | > | something like the following is a perverse but legal reinterpret_cast | > | implementation: | > | | > | if is_pointer and is_pointer | > | return (dest_type)( | > | (unisgned)src | > | ^ sizeof(remove_pointer::type) | > | ^ sizeof(remove_pointer::type)); | > | > And why isn't that applicable to the trip | > | > char* -> void* -> Foo* | | You mean aside from the fact that sizeof(void) is illegal? ;-) Yeah ;-) | If the implementation is such that the same bit pattern must be used | to reference a given address, using reinterpret_cast would do | something like | | p ^ sizeof(char) ^ sizeof(void) ^ sizeof(void) ^ sizeof(Foo) | | and, assuming sizeof(void) is well-defined the resulting pointer would | have been xor'ed with sizeof(char) and sizeof(Foo), so it would point | into outer space. Thanks for your patience. Now, imagine an implementation where the original type is remembered, then dereferencing the pointer obtained from char* -> void* -> T* may just eject you into the outer space. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
"David B. Held" <[EMAIL PROTECTED]> writes:
| "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
| [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
| > [...]
| > What do mean exactly by a "valid Foo*"?
|
| Hmm...I think 5.2.10/7 is more relevant. I guess it depends on what
| "unspecified" means. I assumed that it meant that you have a Foo*,
| but it might not point to an actual Foo.
OK, now, let's recall the original construct
template
struct holder
{
union {
aligned_POD::type aligner;
char storage[sizeof(T)];
};
};
the Standard makes no guarantee that you do the conversion
char* -> void* -> T*
on &h.storage[0] and have a usuable T*.
-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > What do mean exactly by a "valid Foo*"? Hmm...I think 5.2.10/7 is more relevant. I guess it depends on what "unspecified" means. I assumed that it meant that you have a Foo*, but it might not point to an actual Foo. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > David Abrahams <[EMAIL PROTECTED]> writes: > > | [...] > | if is_pointer and is_pointer > | return (dest_type)( > | (unisgned)src > | ^ sizeof(remove_pointer::type) > | ^ sizeof(remove_pointer::type)); > > And why isn't that applicable to the trip > > char* -> void* -> Foo* First of all, because that trip with reinterpret_cast<> is even more implementation-defined than char* -> Foo*. Second, because that trip isn't even being proposed for reinterpret_cast<>, it's being proposed for static_cast<>. And third, Dave's "perverse implementation" only applies to reinterpret_cast<>, not static_cast<>. For the static_cast<> trip, consider: 4.10 Pointer conversions 2 An rvalue of type "pointer to cv T," where T is an object type, can be converted to an rvalue of type "pointer to cv void." The result of converting a "pointer to cv T" to a "pointer to cv void" points to the start of the storage location where the object of type T resides, as if the object is a most derived object (1.8) of type T (that is, not a base class subobject). char* -> void* and 5.2.9 Static cast 10 An rvalue of type "pointer to cv void" can be explicitly converted to a pointer to object type. A value of type pointer to object converted to "pointer to cv void" and back to the original pointer type will have its original value. void* -> Foo* Note that "implementation defined" and "undefined" do not appear in either of those paragraphs. Maybe the standard is not sufficiently clear to determine whether char* -> void* -> Foo* has the intended effect. However, that seems to be a legal reading of it. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > David Abrahams <[EMAIL PROTECTED]> writes: > > | "Eric Woodruff" <[EMAIL PROTECTED]> writes: > | > | > "David B. Held" <[EMAIL PROTECTED]> wrote in message > | > aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]... > | >> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message > | >> aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED]... > | >> > [snip] > | >> > > | >> > > holder h; > | >> > > new (h.storage) Foo; > | >> > > | >> > What is the meaning of that syntax? > | >> > | >> This is placement new syntax. It means construct a Foo at the address > | >> h.storage, without allocating any memory. > | >> > | > > | > So the type really is of Foo, which has to mean that casting h.storage back > | > to a Foo* using reinterpret_cast is covered by the standard. > | > | No, the standard only guarantees that you can do a round-trip > | cast. The pointer didn't start out as a Foo*. The fact that it has the > | same address as a Foo* doesn't mean anything. Just for example, > | something like the following is a perverse but legal reinterpret_cast > | implementation: > | > | if is_pointer and is_pointer > | return (dest_type)( > | (unisgned)src > | ^ sizeof(remove_pointer::type) > | ^ sizeof(remove_pointer::type)); > > And why isn't that applicable to the trip > > char* -> void* -> Foo* You mean aside from the fact that sizeof(void) is illegal? ;-) If the implementation is such that the same bit pattern must be used to reference a given address, using reinterpret_cast would do something like p ^ sizeof(char) ^ sizeof(void) ^ sizeof(void) ^ sizeof(Foo) and, assuming sizeof(void) is well-defined the resulting pointer would have been xor'ed with sizeof(char) and sizeof(Foo), so it would point into outer space. or-some-equally-useful-place-ly y'rs, -- 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<>
David Abrahams <[EMAIL PROTECTED]> writes: | "Eric Woodruff" <[EMAIL PROTECTED]> writes: | | > "David B. Held" <[EMAIL PROTECTED]> wrote in message | > aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]... | >> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message | >> aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED]... | >> > [snip] | >> > | >> > > holder h; | >> > > new (h.storage) Foo; | >> > | >> > What is the meaning of that syntax? | >> | >> This is placement new syntax. It means construct a Foo at the address | >> h.storage, without allocating any memory. | >> | > | > So the type really is of Foo, which has to mean that casting h.storage back | > to a Foo* using reinterpret_cast is covered by the standard. | | No, the standard only guarantees that you can do a round-trip | cast. The pointer didn't start out as a Foo*. The fact that it has the | same address as a Foo* doesn't mean anything. Just for example, | something like the following is a perverse but legal reinterpret_cast | implementation: | | if is_pointer and is_pointer | return (dest_type)( | (unisgned)src | ^ sizeof(remove_pointer::type) | ^ sizeof(remove_pointer::type)); And why isn't that applicable to the trip char* -> void* -> Foo* ? -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
"David B. Held" <[EMAIL PROTECTED]> writes: | "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message | asli92$oqn$[EMAIL PROTECTED]">news:asli92$oqn$[EMAIL PROTECTED]... | > [...] | > > > > holder h; | > > > > new (h.storage) Foo; | > [...] | > So the type really is of Foo, | > [...] | | No, the type really is char[sizeof(T)] converted to char* const. Since the | pointer never was Foo*, I don't believe reinterpret_cast<> is obliged to | give you a valid Foo*. What do mean exactly by a "valid Foo*"? -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
"Eric Woodruff" <[EMAIL PROTECTED]> writes: > "David B. Held" <[EMAIL PROTECTED]> wrote in message > aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]... >> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message >> aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED]... >> > [snip] >> > >> > > holder h; >> > > new (h.storage) Foo; >> > >> > What is the meaning of that syntax? >> >> This is placement new syntax. It means construct a Foo at the address >> h.storage, without allocating any memory. >> > > So the type really is of Foo, which has to mean that casting h.storage back > to a Foo* using reinterpret_cast is covered by the standard. No, the standard only guarantees that you can do a round-trip cast. The pointer didn't start out as a Foo*. The fact that it has the same address as a Foo* doesn't mean anything. Just for example, something like the following is a perverse but legal reinterpret_cast implementation: if is_pointer and is_pointer return (dest_type)( (unisgned)src ^ sizeof(remove_pointer::type) ^ sizeof(remove_pointer::type)); ... -- 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<>
"David B. Held" <[EMAIL PROTECTED]> writes: | Because you want to get at the T in h in a portable way. Which brings | me to my next point. Since it seems this is the only context in which this | cast is guaranteed to give a meaningful result, maybe it should be called | placement_cast<>? But then, in which is it better than reinterpret_cast<>. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"Eric Woodruff" <[EMAIL PROTECTED]> wrote in message asli92$oqn$[EMAIL PROTECTED]">news:asli92$oqn$[EMAIL PROTECTED]... > [...] > > > > holder h; > > > > new (h.storage) Foo; > [...] > So the type really is of Foo, > [...] No, the type really is char[sizeof(T)] converted to char* const. Since the pointer never was Foo*, I don't believe reinterpret_cast<> is obliged to give you a valid Foo*. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: dangerous_cast<>
"Eric Woodruff" <[EMAIL PROTECTED]> writes: | [snip] | | > holder h; | > new (h.storage) Foo; | | What is the meaning of that syntax? placement-new: Construct a Foo at h.storage. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"David B. Held" <[EMAIL PROTECTED]> wrote in message aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]... > "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message > aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED]... > > [snip] > > > > > holder h; > > > new (h.storage) Foo; > > > > What is the meaning of that syntax? > > This is placement new syntax. It means construct a Foo at the address > h.storage, without allocating any memory. > So the type really is of Foo, which has to mean that casting h.storage back to a Foo* using reinterpret_cast is covered by the standard. > > >... > > > T* u = dangerous_cast(h.storage); // can't do this with > > > reinterpret_cast > > > > Why would you want to do that in the first place. > > Because you want to get at the T in h in a portable way. Which brings > me to my next point. Since it seems this is the only context in which this > cast is guaranteed to give a meaningful result, maybe it should be called > placement_cast<>? > > Dave > > > > > ___ > 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<>
"Eric Woodruff" <[EMAIL PROTECTED]> wrote in message aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED]... > [snip] > > > holder h; > > new (h.storage) Foo; > > What is the meaning of that syntax? This is placement new syntax. It means construct a Foo at the address h.storage, without allocating any memory. > >... > > T* u = dangerous_cast(h.storage); // can't do this with > > reinterpret_cast > > Why would you want to do that in the first place. Because you want to get at the T in h in a portable way. Which brings me to my next point. Since it seems this is the only context in which this cast is guaranteed to give a meaningful result, maybe it should be called placement_cast<>? Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "David B. Held" <[EMAIL PROTECTED]> writes:
>
> | Does this have any merit whatsoever?
> |
> | template
> | T* dangerous_cast(U* p)
> | {
> | return static_cast(static_cast(p));
> | }
>
> Is it any different from reinterpret_cast(p) ?
no because either way, the only thing you can do with that T* result is cast
it back to its original type before using it, which is the very you do with
reinterpret_cast.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
[snip] > holder h; > new (h.storage) Foo; What is the meaning of that syntax? >... > T* u = dangerous_cast(h.storage); // can't do this with reinterpret_cast Why would you want to do that in the first place. > > HTH, > -- >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 > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
