[...]
ERT> It appears to me that you have done exactly what I would expect
ERT> an application programmer would do.
ERT> Personally, I don't care for the method you chose.
ERT> I think it is ugly and unnecessarily complicated.
Personnally I don't think so.
ERT> If the library developers must supply the definition of MatrixTraits,
ERT> then they will need to have standard names.
Why will they *need* to have standard names for traits ? Algorithms
can as well be parameterized by traits. Yes I confess it can be
ugly. But there is no necessity.
ERT> If the definition of MatrixTraits is left to application programmers,
ERT> it would be easier to rename all the types and functions.
>> So, rather than standardizing on names for classes and member functions,
>> all one needs to "standardize" on are the capabilities that a container
>> needs to have.
ERT> I suppose we could assign a number to each capability
ERT> and pretend that we weren't naming them. ;-)
ERT> But, yes, we need to "standardize" the capabilities.
ERT> We are giving them names so that we can identify them.
ERT> We are giving them standard names so that the application programmer
ERT> knows what to expect from the library.
ERT> We don't necessarily expect any of these names
ERT> to appear in application source code.
>> The MatrixTraits class could be standardized,
>> or every library could provide its own MatrixTraits type of class,
>> specifying only those capabilities that that library needs,
>> and leaving it up to the user of the library
>> to specialize this class as is appropriate for his containers.
>>
>>> doubleComplexVector v(n);
>>
>> Ack! There is no good reason for not writing generic containers -
>> this is generic programming at its most basic:
>>
>> Vector<complex<double>> v(n);
ERT> Obviously, templates could be used to implement doubleComplexVector
ERT> and the library developer could simply provide the type definition
ERT> typedef Vector<complex<double>> doubleComplexVector;
ERT> But I don't think I have any use for
ERT> Vector<complex<String>> v(n);
So you'll never write something like that. That is fine.
ERT> I don't even know if the imaginary part of a complex String has meaning
ERT> for anybody and, anyway, I don't want to specify a standard for it.
ERT> If you wish to propose a class template for Vector, please feel free to do so
ERT> but I think it has already been done. ;-)
ERT> Seriously now, the point is that I think we expect the library developer
ERT> to provide specializations for a certain limited number of types.
ERT> I don't think we expect library developers to provide any support
ERT> for types that hardly anyone ever uses.
ERT> It won't help them sell libraries and it isn't justified.
ERT> The decision about whether to use templates or not
ERT> is an implementation detail and should be left up to the library developer.
ERT> Bob Tisdale
No one doing numerics will use complex<string>, so there is no point
in trying to solve an imaginary problem.
-- Gaby