Please consider this patch.  This eases porting of some code by providing an operator () as an alias to 'at'.

Neal Becker Wrote:

> Please consider this patch.  This eases porting of some code by providing an operator () as an alias to 'at'.

Neal

Just started to address this issue.

Can you give me some more information on why you need this, and why neither at() nor concatenated subscript operators do not suffice?

Cheers

Matthew

Matthew Wilson wrote:

> Neal Becker Wrote:
> 
>> Please consider this patch.  This eases porting of some code by providing an operator () as an alias to 'at'.
> 
> Neal
> 
> Just started to address this issue.
> 
> Can you give me some more information on why you need this, and why neither at() nor concatenated subscript operators do not suffice?
> 

Concatenated [] do work.  I suspect, without proof, that the concatenated[] _may_ be slower on some compilers.  Isn't this the same reason that we have at?

There is nothing wrong with at.  I propose () as a convenient alias.  The
reason is just to aid porting code and improve readability.  Imagine
porting some dense code (maybe from fortran), and filling it
with 'at_unchecked'.

Neal Becker Wrote:

> Matthew Wilson wrote:
> 
> > Neal Becker Wrote:
> > 
> >> Please consider this patch.  This eases porting of some code by providing an operator () as an alias to 'at'.
> > 
> > Neal
> > 
> > Just started to address this issue.
> > 
> > Can you give me some more information on why you need this, and why neither at() nor concatenated subscript operators do not suffice?
> > 
> 
> Concatenated [] do work.  I suspect, without proof, that the concatenated[] _may_ be slower on some compilers.  Isn't this the same reason that we have at?

Your suspicion is correct. (I acknowledged this in IC++ chapter 33).

It's not the reason for at() - they have quite different contracts - but it _is_ the reason for at_unchecked(). :-)


> There is nothing wrong with at.  I propose () as a convenient alias.  The
> reason is just to aid porting code and improve readability.  Imagine
> porting some dense code (maybe from fortran), and filling it
> with 'at_unchecked'.

Hmm, you're making an increasingly convincing case. I totally hate function operators, but I like the idea of attracting lots of Fortran programmers over to The STLSoft Way!

I was toying with adding them in the presence of an opt-in pre-processor symbol, e.g. STLSOFT_FIXED_ARRAY_ALLOW_MULTI_FN_OP.

But I think the way to go is to add them, and to instead have an opt-out symbol (STLSOFT_FIXED_ARRAY_NO_MULTI_FN_OP).

If this doesn't appear in the next beta, feel free to email me a flea for my ear. :-)

Cheers

Matthew