Re: [boost] Re: Re: Boost Array Initialization Technique
In-Reply-To: <d80h47$irf$1@sea.gmane.org> technews@kangaroologic.com (Jonathan Turkanis) wrote (abridged):
array can't be given constructors without sacrificing the aggregate initialization syntax.
OK... although I'd rather have constructors than aggregate initialisation syntax. If the problem is performance, surely the compiler can optimise away the difference (given that it's a standard library component with known semantics)? Anyway, it sounds like this battle is already lost. Is there a rational for not allowing zero-sized arrays? What is the intended semantics of: array<int> a; // Or array<int,0>. assert( a.empty() ); ? Isn't this kind of thing likely to occur in generic template code? -- Dave Harris, Nottingham, UK.
Dave Harris wrote:
In-Reply-To: <d80h47$irf$1@sea.gmane.org> technews@kangaroologic.com (Jonathan Turkanis) wrote (abridged):
array can't be given constructors without sacrificing the aggregate initialization syntax.
OK... although I'd rather have constructors than aggregate initialisation syntax. If the problem is performance, surely the compiler can optimise away the difference (given that it's a standard library component with known semantics)?
No, it's not performance -- it's compatibility with built-in arrays. Furthermore, array initializers are considered pretty natural, and the trend is to try to make user-defined types more like arrays in that respect. (See, e.g., http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1509.pdf; this may not be the most recent paper.)
Anyway, it sounds like this battle is already lost.
Is there a rational for not allowing zero-sized arrays? What is the intended semantics of:
array<int> a; // Or array<int,0>. assert( a.empty() );
Zero sized arrays are allowed, at least by TR1: 6.2.2.4 Zero sized arrays [tr.array.zero] array shall provide support for the special case N == 0. In the case that N == 0, begin() == end() == unique value. Also An instance of array<T, N> stores N elements of type T, so that size() == N is an invariant. This implies that an array has size 0 iff it empty() is true.
? Isn't this kind of thing likely to occur in generic template code?
I don't know. Jonathan
brangdon@cix.compulink.co.uk (Dave Harris) writes:
In-Reply-To: <d80h47$irf$1@sea.gmane.org> technews@kangaroologic.com (Jonathan Turkanis) wrote (abridged):
array can't be given constructors without sacrificing the aggregate initialization syntax.
OK... although I'd rather have constructors than aggregate initialisation syntax. If the problem is performance, surely the compiler can optimise away the difference (given that it's a standard library component with known semantics)?
FWIW, you can always add constructors and initialization in a wrapper layer (e.g. derived class), but you can never take it away. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
FWIW, you can always add constructors and initialization in a wrapper layer (e.g. derived class), but you can never take it away.
But then you lose PODness as well, if that matters to you. In the case of boost/tr1 array I'm not sure what it brings that you cannot get from the data() member. -- AlisdairM
"AlisdairM" <alisdair.meredith@uk.renaultf1.com> writes:
David Abrahams wrote:
FWIW, you can always add constructors and initialization in a wrapper layer (e.g. derived class), but you can never take it away.
But then you lose PODness as well, if that matters to you.
Of course. You can't have both. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
AlisdairM -
brangdon＠cix.compulink.co.uk -
David Abrahams -
Jonathan Turkanis