www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - fixed_array, why no operator()?

reply 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?
Dec 23 2006
parent reply "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) {

 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.
Dec 23 2006
next sibling parent reply 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) {

 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).
Dec 23 2006
parent "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) {

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



   {
 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.
Dec 23 2006
prev sibling parent reply 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?
Dec 23 2006
next sibling parent "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

 to be overwritten anyway.

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

 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
Dec 23 2006
prev sibling parent "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

 to be overwritten anyway.

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

 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
Dec 26 2006