From: Robbie Vogt (r.vogt_at_[hidden])
Date: 2005-06-22 18:22:46
>>Syntacticly this is elegant but allowing container semantics to change is
>The containers have some different behaviour, but then so do
>vector/deque/list. That doesn't stop us writing generic code, you just
>need to be aware of what the containers allow.
This is not a strong argument. Although the STL containers iterators
were intended to facilitate very generic code, the differences between
the containers has proven to hamper authors from writing truly generic
code. Books such as Scott Meyers' "Effective STL" exist solely for this
>>In generic code this brakes your portable code criteria. For example
>>template <class V>
>>multA (V& l, const V& r)
>>l = prod (A, r);
>>Without knowing it's implementation it is impossible to know if 'multA (y,
>>y)' is correct.
>Sure. But is this really any different to
>template <class Container>
>void foo(Container& c)
> typename Container::iterator a = c.begin();
> typename Container::iterator b = a;
> c.erase(b); // undefined behaviour? maybe!
Erasing is a perfect example of the shortcomings in the STL design.
This one has no doubt caught out many programmers in the past.
In my opinion it is a mistake to try and build in different semantics to
uBLAS at this point. There is too much existing code that relies on the
current behaviour and any change is likely to either a) cost a lot of
man-hours in converting user code to adhere to the new semantics; or b)
cause many subtle bugs that are difficult to track down.
As an aside, the seemingly innocuous change of vector/matrix
initialisation semantics from 1.31 to 1.32 caused me a lot of head-aches
(and wasted time).
>>A separate topic. It would be interesting to how much optimisation a
>>compiler of C++ with 'restrict' could gain when compiling uBLAS.
>>It would be easy in uBLAS to enforce 'restrict' internally and I suspect
>>it would help optimise expression evaluation a lot.
This does sound interesting...does GCC accept "restrict" in C++?