Re: declaring constant array without initializing all the elements
On 4 mar, 14:16, Lionel B <m...@privacy.net> wrote:
On Tue, 04 Mar 2008 04:37:29 -0800, James Kanze wrote:
On Mar 4, 11:09 am, Lionel B <m...@privacy.net> wrote:
On Tue, 04 Mar 2008 00:39:50 -0800, James Kanze wrote:
On Mar 3, 4:30 pm, Lionel B <m...@privacy.net> wrote:
[...]
Doing things the hard way when there is a much simpler
solution is obfuscation. Regardless of the documentation.
Yeah, yeah, I wasn't seriously suggesting template
meta-programming as a realistic solution here, merely pointing
out that it's an option for this type of scenario.
OK. There are definitely cases where it's useful, but I don't
think that this is one of them.
On the whole I think I'd prefer the const reference array
solution from your other post; I suspect that the OP might
be happy with a const lvalue for array access.
The simplest
!!!
solution is probably the specialized iterators used to
initialize std::vector. Something like:
std::vector< int > v(
boost::make_transform_iterator(
boost::make_counting_iterator( 0 ), X() ),
boost::make_transform_iterator(
boost::make_counting_iterator( 10 ), X() ) ) ;
, where X is:
struct X : public std::unary_function< int, int > {
int operator()( int i ) const { return 2*i*i ; }
} ;
(You could also write:
std::vector< int > v(
boost::make_transform_iterator(
boost::make_counting_iterator( 0 ),
boost::bind( std::multiplies< int >(), 2,
boost::bind( std::multiplies< int >(), _1,
_1 ) ) ),
boost::make_transform_iterator(
boost::make_counting_iterator( 10 ),
boost::bind( std::multiplies< int >(), 2,
boost::bind( std::multiplies< int >(), _1,
_1 ) ) ) ) ;
, without the extra class, and I suspect that boost::lambda would work
in this case as well. In the absense of a true lambda, however, I think=
I'd go with the extra class.)
Are you serious?
For the version with bind, not really. For the first version,
yes, if you need to evaluate the initialization values
dynamically. (Otherwise, there's nothing clearer and simpler
than a simple off-line program to generate them. Two or three
lines of AWK, perl, or whatever.)
Generally, I've used filtering and transforming iterators almost
since I started C++. One of my major complaints with the STL is
that it makes them unnecessarily awkward to implement and use.
The fact that you need two iterators with an identical type
makes even the first version wordier than it should be.
That (to me) is obfuscatory overkill, if not plainly
gratuitous grandstanding. Not being overly familiar with the
Boost libraries (not even part of the Standard) I'd have to go
off and check the documentation for a raft of unfamiliar
functionality before having the faintest inkling of what is
going on here.
I'm not particularly averse to doing things the "right way" or
using generic coding styles - *if* there's something to be
gained by it. But I really don't believe that applies to this
rather simple problem.
For me, the const reference array solution is, in this case,
if not ideal then at least *way* simpler and far more
transparent in its intentions.
A lot depends on context. It's true that something like:
struct Array
{
int data[ 10 ] ;
operator int const*() const { return data ; }
int operator[]( int i ) const { return data[i] ; }
Array() {
for ( int i = 0 ; i < 10 ; ++ i ) {
data[ i ] = 2 * i * i ;
}
}
} ;
// ...
Array const arr ;
also has a lot to say for itself. The transform_iterator idiom,
however, is very, very general, and worth learning in its own
right.
--
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