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