Re: Another question about multidimensional vectors
On Oct 29, 8:16 pm, "BobR" <removeBadB...@worldnet.att.net> wrote:
James Kanze wrote in message...
On Oct 29, 1:21 am, "BobR" wrote:
Juha Nieminen wrote in message...
std::vector<std::vector<int> > values(xSize, std::vector<int>(ySize=
));
For that, all you need is:
size_t xSize( 20 ), ySize( 30 );
std::vector<std::vector<int> > values( xSize, ySize ); // 20x30
Are you sure? The actual wording in the standard says that this
should work, but the fact that it works is generally considered
to be an accidental side effect of the way the paragraph was
formulated, and is the subject of DR 438. The current status of
DR 438 is still DR, which means that it is still under
discussion, but according to the documentation of the issue,
there seems to be a consensus that this shouldn't work, and that
the only reason the issue is still open is that there are
problems finding the exact words to replace those in the
standard.
In the meantime, the code will compile with some library
implementations, and not with others. (It compiles with 2 out
of 4 that I have access to.) Given that its status is unsure,
however, I'd avoid it; once the wording is finalized, it's quite
possible (even probable) that it will cease working in later
versions of the compilers which currently support it.
That's a real shame. With 2D arrays so common, it sure *was* handy.
From the point of view of the design of std::vector, of course,
it sure is a hack. It only works because it converts the size_t
into a vector<T>, despite the fact that the constructor is
declared explicit.
Of course, hacks can be useful things; pragmatics rule. But try
to explain why it works to a beginner.
I'd vote to keep it. How much trouble could it cause? If GCC
can do it, it should be easy for other implementors to copy (I
can still provide a default value when needed (modifying
Juha's example).).
Are we eliminating practical things in order to provide
wording in the standard?
I'd vote to keep it, too, if for no other reason than removing
it does represent a significant change in what used to be
guaranteed; I don't think it belongs there logically, and it
doesn't extend to further dimensions.
On the other hand, I wouldn't oppose some real support for
multi-dimension arrays. It's not that hard to implement, and
something standard would seem to be in order---something which
guarantees that all of the rows have the same length, for
example. But I've not seen a proposal along these lines.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34