On Thursday, 2 August 2012 at 12:38:10 UTC, Andrei Alexandrescu
wrote:
On 8/2/12 5:26 AM, monarch_dodra wrote:
One of the *big* reasons I'm against having a hand chosen
padding, is
that the implementation *should* be able to find out what the
most
efficient padding is on the current machine (could be 32 on
some, could
be 64 on some)
In my neck of the woods they call that "non-portability".
If your code is dependent on the machine's characteristics you
use version() and whatnot.
Well, isn't that the entire point: Making your code NOT dependent
on the machine's characteristics?
By forcing the developer to chose the bitfield size (32 or 64),
you ARE forcing him to make a choice dependent on the machine's
characteristics. The developer just knows how he wants to pack
his bits, not how he wants to pad them. Why should the developer
be burdened with figuring out what the optimal size of his
bitfield should be?
By leaving the field blank, *that* guarantees portability.
