• Neal Becker (11/11) Dec 23 2006 I think fixed_array could use an operator () which would be an alias
• Matthew (16/27) Dec 23 2006 return
• Neal Becker (6/40) Dec 23 2006 Thanks for the reply. It is shown that 'at' can me more efficient than
• Matthew (12/53) Dec 23 2006 const
• Neal Becker (16/16) Dec 23 2006 Speaking of efficiency, it would be useful to be able to bypass default
• Matthew (10/26) Dec 23 2006 about
• Matthew (10/26) Dec 26 2006 about

Neal Becker <ndbecker2 gmail.com> writes:

I think fixed_array could use an operator () which would be an alias
for 'at'.  

For example, in fixed_array_2d:

    reference               at(index_type i0, index_type i1);
    const_reference         at(index_type i0, index_type i1) const;

  reference               operator()(index_type i0, index_type i1) { return
at (i0,i1); }
  const_reference         operator()(index_type i0, index_type i1) const {
return at (i0,i1); }

Just notational convenience.

BTW, if compiled with optimization, is at == at_unchecked?

"Matthew" <matthew hat.stlsoft.dot.org> writes:

"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:emj9uo$13gs$1 digitaldaemon.com...
 I think fixed_array could use an operator () which would be an alias
 for 'at'.

 For example, in fixed_array_2d:

     reference               at(index_type i0, index_type i1);
     const_reference         at(index_type i0, index_type i1) const;

   reference               operator()(index_type i0, index_type i1) {

return
 at (i0,i1); }
   const_reference         operator()(index_type i0, index_type i1) const {
 return at (i0,i1); }

 Just notational convenience.

Why not just apply the subscript operator?

stlsoft::fixed_array_2d<int>    ar(2, 2);

ar[0][0] = 0;
ar[0][1] = 1;
ar[1][0] = 10;
ar[1][1] = 11;

int i0 = ar[0][0];
int i1 = ar[0][1];
int i2 = ar[1][0];
int i3 = ar[1][1];

(If you were unaware of this, I must apologise for the continued and
baffling poor quality of the documentation <g>)

 BTW, if compiled with optimization, is at == at_unchecked?

No. at() always does a runtime check and throws std::out_of_range.

Neal Becker <ndbecker2 gmail.com> writes:

Matthew wrote:

 
 "Neal Becker" <ndbecker2 gmail.com> wrote in message
 news:emj9uo$13gs$1 digitaldaemon.com...
 I think fixed_array could use an operator () which would be an alias
 for 'at'.

 For example, in fixed_array_2d:

     reference               at(index_type i0, index_type i1);
     const_reference         at(index_type i0, index_type i1) const;

   reference               operator()(index_type i0, index_type i1) {

 return
 at (i0,i1); }
   const_reference         operator()(index_type i0, index_type i1) const
   {
 return at (i0,i1); }

 Just notational convenience.

 
 Why not just apply the subscript operator?
 
 stlsoft::fixed_array_2d<int>    ar(2, 2);
 
 ar[0][0] = 0;
 ar[0][1] = 1;
 ar[1][0] = 10;
 ar[1][1] = 11;
 
 int i0 = ar[0][0];
 int i1 = ar[0][1];
 int i2 = ar[1][0];
 int i3 = ar[1][1];
 

Thanks for the reply.  It is shown that 'at' can me more efficient than
going through operator [][]..  So I thought it would be nice to have a
notation that is as efficient as 'at', but is at least a bit more
conventional notationally (used in at least some other languages, and some
other c++ array libraries).

"Matthew" <matthew hat.stlsoft.dot.org> writes:

"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:emk73m$10v7$1 digitaldaemon.com...
 Matthew wrote:

 "Neal Becker" <ndbecker2 gmail.com> wrote in message
 news:emj9uo$13gs$1 digitaldaemon.com...
 I think fixed_array could use an operator () which would be an alias
 for 'at'.

 For example, in fixed_array_2d:

     reference               at(index_type i0, index_type i1);
     const_reference         at(index_type i0, index_type i1) const;

   reference               operator()(index_type i0, index_type i1) {

 return
 at (i0,i1); }
   const_reference         operator()(index_type i0, index_type i1)



const
   {
 return at (i0,i1); }

 Just notational convenience.

 Why not just apply the subscript operator?

 stlsoft::fixed_array_2d<int>    ar(2, 2);

 ar[0][0] = 0;
 ar[0][1] = 1;
 ar[1][0] = 10;
 ar[1][1] = 11;

 int i0 = ar[0][0];
 int i1 = ar[0][1];
 int i2 = ar[1][0];
 int i3 = ar[1][1];

 Thanks for the reply.  It is shown that 'at' can me more efficient than
 going through operator [][]..

Indeed. It occured to me that might have been your motive for posting one
second after I sent my reply. ;-)

(btw, may I infer from this that you've read Imperfect C++? <g>)

  So I thought it would be nice to have a
 notation that is as efficient as 'at', but is at least a bit more
 conventional notationally (used in at least some other languages, and some
 other c++ array libraries).

The trouble is, one man's (or woman's) useful extra operator is another's
more-gratuitous-obfuscation.

In this case, I did consider the function call operator, but decided to
follow the std library and have an unchecked subscript operator and a
checked at() method, with the additional method at_unchecked(), which, as
you note, is the fastest-possible alternative in a 2+ dimension situation.

Neal Becker <ndbecker2 gmail.com> writes:

Speaking of efficiency, it would be useful to be able to bypass default
construction completely.  Yes, I know about do_construction_never.  What
this does, is use memset (0).  Still can be a waste of time.  I want to
really bypass construction.

I have used some other libraries with these semantics:

array (size, init)

constructs an array of 'size' elements, each initialized to 'init'.

array (size)

constructs an array of 'size' elements with really uninitialized storage.

This is particularly useful for std::complex, which is widely used. 
Unfortunately (IMO), std::complex has a default constructor.  It is
important to be able to construct a large array of std::complex without
iteratively constructing each element, for cases where the values are about
to be overwritten anyway.

How to fit this into stlsoft::fixed_array?  Maybe a new construction policy
can specify this behavior?

"Matthew" <matthew hat.stlsoft.dot.org> writes:

"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:emk7g9$28o2$1 digitaldaemon.com...
 Speaking of efficiency, it would be useful to be able to bypass default
 construction completely.  Yes, I know about do_construction_never.  What
 this does, is use memset (0).  Still can be a waste of time.  I want to
 really bypass construction.

 I have used some other libraries with these semantics:

 array (size, init)

 constructs an array of 'size' elements, each initialized to 'init'.

 array (size)

 constructs an array of 'size' elements with really uninitialized storage.

 This is particularly useful for std::complex, which is widely used.
 Unfortunately (IMO), std::complex has a default constructor.  It is
 important to be able to construct a large array of std::complex without
 iteratively constructing each element, for cases where the values are

about
 to be overwritten anyway.

 How to fit this into stlsoft::fixed_array?  Maybe a new construction

policy
 can specify this behavior?

Will check this out and get back to you.

(FYI: I plan to be releasing STLSoft 1.9.1 beta 34 very soon. Your suggested
change, if accepted, will *not* go into that, but will appear in another
beta very soon after.)

Cheers (and season's greetings!)

Matthew

"Matthew" <matthew hat.stlsoft.dot.org> writes:

"Neal Becker" <ndbecker2 gmail.com> wrote in message
news:emk7g9$28o2$1 digitaldaemon.com...
 Speaking of efficiency, it would be useful to be able to bypass default
 construction completely.  Yes, I know about do_construction_never.  What
 this does, is use memset (0).  Still can be a waste of time.  I want to
 really bypass construction.

 I have used some other libraries with these semantics:

 array (size, init)

 constructs an array of 'size' elements, each initialized to 'init'.

 array (size)

 constructs an array of 'size' elements with really uninitialized storage.

 This is particularly useful for std::complex, which is widely used.
 Unfortunately (IMO), std::complex has a default constructor.  It is
 important to be able to construct a large array of std::complex without
 iteratively constructing each element, for cases where the values are

about
 to be overwritten anyway.

 How to fit this into stlsoft::fixed_array?  Maybe a new construction

policy
 can specify this behavior?

I've done it. And yes, it's just another policy: do_initialisation_never.

It was a lot easier than I expected. It made me realise I'd done a nice job
with the original design. Who'd have thought!? LOL. :-)

It'll be released in beta 35 very shortly.

Cheers

Matthew