Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: DE (satan66613_at_[hidden])
Date: 2011-03-04 12:23:33

this is not a review

hi all
congratulations for you, chad, on that you got so far
i hope all your effort will pay back you a good value

i wanted to say a word on the copy-on-write thing
as someone wisely noted on this list cow is in no way worse than plain
copying
in general when you make a copy you allocate new storage for the newly
created copy
and the allocation procedure, in general, locks a mutex in order not
to corrupt the heap
this is much more expensive even than atomic reference counting
this only statement convinces me personally to use cow in newly
created pieces of software
moreover cow enables the size of the object on the stack (or in an
array) ==sizeof(void*)
then allocation of an array of such objects saves the heap
and e.g. virtually any sorting procedure of an array with all its
possible copies and moves becomes relatively cheap
also it's not forbidden to implement move semantics along with cow
(which appears to be trivial -- just swap the pointers)

and i think that the

  struct storage
  {
    int_t ref_count;
    //other instance data
    value_type array[1];
  };

idiom *should* be used (by default) for the cow internal
implementation (by default the compiler cares about alignment of
'storage' members for you so you don't even get into it)

in the end i have a question to chad: for what reason integer_t
inherits its implementation *virtualy* ?
you know that virtual inheritance involves (possibly unneeded)
overhead

-- 
Pavel
P.S.
if you notice a grammar mistake or weird phrasing in my message
please point it out
p.p.s.
i'm the person who suggested to add algorithmic complexity estimates
to the docs
so blame me