Thomas wrote:
>STL! OK there is definitely something that I'm not understanding
>here. Why is the vector so slow ... Where is the vector slow?
>Just blindly replacing it with the STL version doesn't make
>_any_ sense to me. I'd like to know what in particular is
>slowing us down and then fix that. I'm quite happy right now that
>I don't have any dependancy on libstc++ for QNX ... adding STL
>will break that for QNX at least.
I guess it is that using the STL is an "easy-way out" to replace the
slowness of our STL-like classes. "Blind replacement" is the easy option,
and it is technically sound. I see no reason why we couldn't have STL
implementations for all of our class interfaces. Much thought and
development has gone into the STL and the C++ template system in general.
Not quite as much thought has gone into our UT_XXX classes.
This doesn't mean that our classes are bad or that we should abandon them.
Our UT_XXX classes could definitely use much improvement in their
implementation and we should work to improve them. But I don't see any real
harm in conditionally compiling STL-based versions of our classes if it
helps a few people have a better experience with AbiWord. However, we should
not make STL the default. An ABI_OPT_STL=1 flag should define something like
-DUSING_STL to our compiler. STL-aware classes should have something like
#ifdef USING_STL to condidionally compile in STL support. Abi should be able
to run flawlessly on platforms where there is no STL support. We should not,
however, deny ourselves the opportunity to run better on those platforms
where it is possible to.
Just my $0.02
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
