[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > But even for a POD type such as this, copying would lead to > errors if the char * data were dynamically allocated since a double delete > would probably be done. > Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable<> can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable<> cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable<> is intended for situations where large arrays of objects are moved, like vector<> reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > But even for a POD type such as this, copying would lead to > errors if the char * data were dynamically allocated since a double delete > would probably be done. > Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable<> can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable<> cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable<> is intended for situations where large arrays of objects are moved, like vector<> reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
David Abrahams wrote: > "Peter Dimov" <[EMAIL PROTECTED]> writes: > >>> I guess there is no equivalent to memcpy_moveable: but it looks >>> rather dangerous, what state is the original object left in >>> afterwards etc? >> >> None. There is no original object after the move, only raw storage. > > ...which is a different meaning from move in our move proposal Most definitely. "Our" move writes to the source, memcpy_move does not since, well, memcpy doesn't. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Peter Dimov" <[EMAIL PROTECTED]> writes: >> I guess there is no equivalent to memcpy_moveable: but it looks rather >> dangerous, what state is the original object left in afterwards etc? > > None. There is no original object after the move, only raw storage. ...which is a different meaning from move in our move proposal -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
John Maddock wrote: >>> Thats my point - you may flag some types as safely moveable and then >>> use >>> this knowledge in algorithms. User has the responsibility to do the >>> decision. >> >> Extremely dangerous and error prone. I can't even imagine a non-POD >> type where flagging it for memcpy_copyable and memcpy_moveable can >> be right. > Can >> you give an example ? >> >> Also, "flagging it" introduces some more complication on the user's >> part. How would you propose the user do this ? > > He needs to take a look at the has_trivial_* traits: > > has_trivial_assign is roughly equivalent to memcpy_copyable > > I guess there is no equivalent to memcpy_moveable: but it looks rather > dangerous, what state is the original object left in afterwards etc? None. There is no original object after the move, only raw storage. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
Pavel Vozenilek wrote:
> "Edward Diener" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Extremely dangerous and error prone. I can't even imagine a non-POD
>> type where flagging it for memcpy_copyable and memcpy_moveable can
>> be right.
> Can
>> you give an example ?
>>
> It is error prone but many other constructs are too.
>
> Example of moveable object:
>
> struct string_buffer {
> unsigned size;
>char* data; // allocated buffer
> };
According to my understanding, this is a POD type. It would be unnecessary
to flag this. But even for a POD type such as this, copying would lead to
errors if the char * data were dynamically allocated since a double delete
would probably be done. And adding a copy constructor to deal with it would
remove it from POD category and make your memcpy_copyable and
memcpy_moveable irrelevant for it.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
> see boost::is_POD. And has_trivial_copy has_trivial_assign has_trivial_destruct etc John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
>> > > Thats my point - you may flag some types as safely moveable and then > > use > > this knowledge in algorithms. User has the responsibility to do the > > decision. > > Extremely dangerous and error prone. I can't even imagine a non-POD type > where flagging it for memcpy_copyable and memcpy_moveable can be right. Can > you give an example ? > > Also, "flagging it" introduces some more complication on the user's part. > How would you propose the user do this ? He needs to take a look at the has_trivial_* traits: has_trivial_assign is roughly equivalent to memcpy_copyable I guess there is no equivalent to memcpy_moveable: but it looks rather dangerous, what state is the original object left in afterwards etc? In any case there is another promising approach to moveable objects proposed for the next standard (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Extremely dangerous and error prone. I can't even imagine a non-POD type
> where flagging it for memcpy_copyable and memcpy_moveable can be right.
Can
> you give an example ?
>
It is error prone but many other constructs are too.
Example of moveable object:
struct string_buffer {
unsigned size;
char* data; // allocated buffer
};
The user could then write:
template<> memcpy_moveable {
static bool moveable = true; // or defining some type or so
}
and container can detect moveability and use memcpy(). If type is not
flagged, memcpy() won't be used.
Usually strings, smart pointers, vectors, pimpls are memcpy moveable. Pimpl
with back pointer isn't.
(The memcpy_copyable<> is probably not that good idea and not much useful.)
/Pavel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
Pavel Vozenilek wrote: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > ... >> >> I don't believe you can use memcpy to move any non-POD types >> portably, >> i.e. without special knowledge of the compiler. >> > Thats my point - you may flag some types as safely moveable and then > use > this knowledge in algorithms. User has the responsibility to do the > decision. Extremely dangerous and error prone. I can't even imagine a non-POD type where flagging it for memcpy_copyable and memcpy_moveable can be right. Can you give an example ? Also, "flagging it" introduces some more complication on the user's part. How would you propose the user do this ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > > I don't believe you can use memcpy to move any non-POD types portably, > i.e. without special knowledge of the compiler. > Thats my point - you may flag some types as safely moveable and then use this knowledge in algorithms. User has the responsibility to do the decision. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Pavel Vozenilek" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> "Pavel Vozenilek" <[EMAIL PROTECTED]> writes: >> >> > Type traits library may be extended with: >> > - memcpy_copyable<> and >> > - memcpy_moveable<> >> >> see boost::is_POD. >> > memcpy_moveable<> may be useful for non-POD types, like some pimpls. I don't believe you can use memcpy to move any non-POD types portably, i.e. without special knowledge of the compiler. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Pavel Vozenilek" <[EMAIL PROTECTED]> writes: > > > Type traits library may be extended with: > > - memcpy_copyable<> and > > - memcpy_moveable<> > > see boost::is_POD. > memcpy_moveable<> may be useful for non-POD types, like some pimpls. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
