Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-06 09:23:51

> But does this preserve the guarantee that result<T, E> is trivially
> copyable?

Also, if you want the TRY operation to work (and you really, really do,
it is an enormous boilerplate saver), then your error type needs to be
identical throughout your program. Templating it breaks that.

> Another alternative to consider is to change something in the ring buffer
> records, so that it resembles:
> 
> ```
> struct RingBufferRecord
> {
>   enum {/*name different kind of payloads*/} _discriminator;
>   union
>   {
>     /*define different kinds of payload*/
>   }
> };
> ```
> 
> This way the enumeration tells you how to reinterpret the data. You do not
> know all possible payloads when designing the ring buffer, so you probably
> need to introduce something akin to virtual functions:
> 
> ```
> struct RingBufferRecord
> {
>   aligned_storage<256> _raw_storage;
>   void (*_interpret_raw_storage) (aligned_storage<256>&);
> };
> ```
> 
> I admit this idea is not well thought over.

You can probably set a custom ring buffer design per process, but as it
would cause error_code_extended's type signature to change in order to
prevent ABI collision, going finer grained than that probably wouldn't
be practical as again you'd lose the TRY operation.

I am currently minded to have error_code_extended no longer store a 191
byte string which lets me pack many more of them into a reasonably sized
ringbuffer. If people want to store a string, I am minded they should be
either supplying a static const char * or else return an outcome<T> with
shared_ptr payload to strings.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/