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

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