From: ootiib@hot.ee
On Tuesday, 26 March 2013 07:50:05 UTC+2, Seungbeom Kim wrote:
> On 2013-03-25 13:43, Francis Glassborow wrote:
> > And in C++, do not use arrays, use a vector of vectors instead.
>
> I'm not sure if a M-element vector of N-element vectors is better than
> a M*N-element vector.
That is true. vector of vectors is not usually "better". The performance
of multidimensional containers usually affects overall performance, so
choice matters. However that choice may be made later. We do not write
software onto rock.
Also 'vector a(M*N);' is not best. If 'array a;' compiles then
it is usually better.
Note that if the array is sparse then it is sometimes good to
take it into account with 'std::array>,N>'
or 'std::array,N>'
or 'std::map, T>' depending on usage.
> You'll have M+1 allocations, worse locality,
> and weird and much more verbose declarations:
>
> std::vector> matrix(M, std::vector(N));
> std::vector>::size_type sz = matrix.size();
> std::vector>::const_iterator it = matrix.end();
That factor is not too important ... more idiomatic would be to assume that
typedefs are always done ...:
typedef std::vector Column;
typedef std::vector Matrix;
Matrix::size_type sz = matrix.size();
...also 'auto' was modified exactly because of that:
auto it = matrix.end();
> in exchange for the nice access syntax 'm[i][j]'.
That is nicest but rarely optimal access syntax.
> On the other hand, I have written and used a wrapper that hides a M*N-
> element vector inside and provides a nice access syntax m[i][j] or
> m(i, j), but not being standardized, it doesn't tend to last long.
IMHO the choice of container should be always implementation detail. In
OOP sense two-dimensional container is just a 1 to M*N relation. It is
not good to expose carriers of relations for any by-passer to adjust.
> And why not std::valarray? We even have std::[g]slice, but I have
> rarely seen anyone actually use or recommend them.
std::valarray we usually do not need because we usually store more
"mundane" things (like accounts, queries, requests, devices) ... than
numbers. If we need numbers then we again often can save some time with
math library (like Boost.Basic Linear Algebra Library) ... in comparison
with std::valarray. If it is image that we are processing then modern
processors are so powerful and memory speed is so limiting that it is
often best to keep images in a compressed format most of the time.
> There's also Boost.MultiArray, but when asked "What's the best way to
> have a multidimensional array in C++?", I hate to have to answer
> "Oh, you have to install Boost first, and ..."
Why? The sooner novices realize that standard library is only little
and homey introduction to ocean of libraries we use (where boost is
also among the friendliest) ... the better. Boost has lot of interesting
(and often close to optimal) containers in it.
> What's the canonical way to have a multidimensional array in C++?
> What a pity I haven't found the answer yet. So I just allow myself to
> use the C arrays 'T a[M][N];', at least for simple cases.
There can not be canonical ways since the purpose of one can't be
canonical. If the space of usage is dim then it is fine to start from
std::vector, std::array or boost::multi_array and refactor it later into
more suitable container.
I also have lot of usages of C arrays for immutable containers like ...
T const A[][N] = {{ /*...*/ }, /*...*/ };
Note, that key here is immutability and that compiler calculates the
count of columns thanks to aggregate initialization (no such luxury
for non-aggregates). If things become mutable then C array is
dangerously too low level.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
