--- David Abrahams <dave@boost-consulting.com> wrote:
You are hitting the nail on the head. Experience with my own reference-counted array type tells me that the issue of immutability/constness needs extreme care. My own solution has the glaring shortcoming of not providing a const-reference-counted array type (excuses available on request :-). But having said that, I found it a lot worse not to be able to write a function that returns a new array without incurring a deep copy.
It seems quite a few compilers implement one or another form of RVO.l
Sorry, I don't know what RVO.l is. Is it portable? Does code exploiting RVO.l to achieve move semantics look intuitive?
I guess you haven't read the MTL concept breakdown:
Right. When I started with my array library (two years ago) it was clear that MTL is too specialized for my purposes.
- Shape - Storage (I think this is what you're calling memory management) - Orientation (row-major, column-major, diagonal-major...)
Is "Orientation" a specialization of "Shape". Couldn't both be viewed as "Indexing models?"
1. I found the following memory management models for arrays to be essential in practical applications (i.e. I implemented them all, and make heavy use of all):
stack, fixed size stack, variable size, fixed capacity heap, variable capacity, one owner (e.g. std::vector) heap, variable capacity, shared ownership reference to any of these (i.e. "no management")
That's storage.
Right. Which of these are you going to support?
3. A general purpose array library should provide a mechanism for reusing memory management models and indexing models in various combinations. This could lead to:
memory_model<typename ValueType, typename IndexingModelType> or indexing_model<typename ValueType, typename MemoryModelType>
I don't understand why you think one of them should take the other as a parameter.
That's what I could cope with at the time with with my 12 months C++ experience and Visual C++ 6 support in mind (brrrrrr). [I settled on memory_model<>; it works OK for me; the biggest disadvantage is that I had to replicate the algebras for each memory model.]
4. Array algebras (unary and binary operators, functions) are a third property that is ideally separated from memory models and, if applicable, indexing models. This could lead to:
Does my generic array design look too daunting? Do we have to wait for another language before array libraries can be implemented in such a generic way?
5. Expression templates are an optimization on top of all this and in my practical experience the least important of all the points mentioned here. In all likelihood the 5-10% of code that matter for runtime performance have to be hand-optimized anyway, usually leading to distortions of the original, intuitive code beyond recognition.
The aim is to make the library smart enough to do those optimizations correctly so you don't have to do it by hand.
A case of "premature optimization?" I am still waiting for an example of real-world code where the critical section is so large that the reduction in code size/gain in maintainability due to the availability of expression templates would justify the cost of implementing the ET library and the increased compile times. -- Maybe I am just too spoiled by Python. :-) I am constantly taking a performance hit of about two orders of magnitude, writing only the critical code in C++, and it turns out to be very practical because the old 90-10 rule is true! Sometimes I even win out compared to brute force number crunching approaches because the very high abstraction level of Python allows me to push bookkeeping and high-level decision making to a point where I know how to skip much of the brute force work. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail