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?

"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.

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).

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?

"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> 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

"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