• Neal Becker (2/2) Mar 20 2007 Please consider this patch. This eases porting of some code by providin...
• Matthew Wilson (6/8) Apr 06 2007 Neal
• Neal Becker (8/20) Apr 07 2007 Concatenated [] do work. I suspect, without proof, that the concatenate...
• Matthew Wilson (9/31) Apr 07 2007 Your suspicion is correct. (I acknowledged this in IC++ chapter 33).

Neal Becker <ndbecker2 gmail.com> writes:

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

Matthew Wilson <no-one nowhere.no.com> writes:

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

Neal Becker <ndbecker2 gmail.com> writes:

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

Matthew Wilson <no-one nowhere.no.com> writes:

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