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
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
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
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
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
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
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
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
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
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
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 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
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
13 matches
Mail list logo
