www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - Add operator() to fixed_array

reply 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'.
Mar 20 2007
parent reply 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
Apr 06 2007
parent reply 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'.
Apr 07 2007
parent 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
Apr 07 2007