From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2001-03-28 07:42:45
Jeremy Siek <jsiek_at_[hidden]> writes:
| On 27 Mar 2001, Gabriel Dos Reis wrote:
| Gabrie> |
| Gabrie> | A[indirect(begin_row_index, end_row_index)]
| Gabrie> | [indirect(being_col_index, end_col_index)]
| Gabrie> Without expression-templates I suspect that will bring in performance
| Gabrie> lost. Please, let us not trade syntax for functionalities/semantics.
| Ok... I haven't looked into this issue. What are the various alternatives?
* define a well-delimited kernel -- no fancy syntax, just keep it as
simple as possible;
* for higer-level layers, provide both traditional functions and
overloaded operators -- nifty syntax is where you don't really
care about a 5-10% of performance lost.
| Gabrie> What is really wrong with operator()?
| By operator(), do you mean indexing into an array using the notation
Sort of. The problem with operator is that it requires proxy
classes which come with their own set of extra-problems (semantics,
| ... If so, it's a bit unsavory because there will be some
| hard coded limit to the number of dimensions you can support
I understand. But a multidimensional array already has the limit hard
coded in its type. So the question is how can we statically vary
indexing arity with that of the array dimension.
Perhaps should we have to introduce an index class template...
Doing so will effectively lets one use operator, but it will break
with C-array indexing syntax.
| ... , and
| it would be nice to avoid the kind of repetitive code you see
| in Blitz++.
| ... Also, operator is what builtin arrays use.
I can understand the desire to keep C-array indexing syntax, but by
definition that syntax doesn't come with the problems we have with
We need to abstract over that syntax.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk