Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Hite, Christopher (Christopher.Hite_at_[hidden])
Date: 2012-01-26 10:28:47

> I don't personally think that the style of programming that optional is intended for is suitable for high performance/performance critical situations in the first place.

You may be right, but you're talking about different use cases.  I've got a protocol de/encoders so I want a friendly high level representation of messages that I want to hand off between modules. Imagine a struct with an optional substruct.

Valid alternatives: a pointer to the substruct.  Even if I can put the second structure on the stack, this might mean less cache hits.  The total extra size is also increased bool=>pointer.

Another option sometimes possible is a nullable value.  FAST-FIX's nullable integer for example increments all non-negative values and uses 0 to represent a null.

Another option is to use a presence map at the top of a structure with one bit(or byte) per optional field.  That might help with alignment.

> I find that it is quite easy to write safe C++ interfaces without using optional...

Yes I used optional because I knew it would do things correctly.

> you haven't convinced me

Just focus on #1 first.  Not writing to m_initialized in the deconstructor would benifit all use cases of optional.

It can't be the solution to just not use boost everytime there's a performance issue.