what to do with postblit on the heap?
Michel Fortin
michel.fortin at michelf.com
Tue Jun 21 08:14:41 PDT 2011
On 2011-06-21 08:38:05 -0400, "Steven Schveighoffer"
<schveiguy at yahoo.com> said:
> On Tue, 21 Jun 2011 08:25:40 -0400, Michel Fortin
> <michel.fortin at michelf.com> wrote:
>
>> While there is no doubt that 'moving' a struct can often be used as an
>> optimization without changing the semantics, if you want the @disabled
>> attribute to be useful on the postblit constructor then the language
>> needs to define when its semantics require 'moving' data and whey then
>> require 'copying' data, it can't let that only to the choice of the
>> optimizer.
>
> Another issue with appending a @disabled-postblit struct, what happens
> when you have to reallocate a block to get more space? This cannot
> possibly be a move, because the compiler has no idea at the time of
> appending whether anything else has a reference to the original data.
> So should it just be a runtime error?
That's indeed a problem.
> I'm starting to think that @disabled postblit structs *shouldn't* be
> able to be appended.
That would make sense. It should be a compile-time error.
It would also turn appending using move to an optimization, because all
the types you can append will be guarantied to be copyable.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list