PATCH: remove_all() method added to the containers

Dear all,
of course there are several ways in the current version of GiNaC to erase all the elements from a GiNaC container. However, as far as I can tell, they are either obscure or inefficient or both (removing one element at a time is inefficient, assigning from an empty container is obscure and still measurably inefficient and so forth). Removing all the elements of a container is a very common operation and forcing users to resort to kludges is, I believe, not a very good idea. Moreover, not providing the right method for a common operation reduces the implementor's latitude for future choices (what if you would like to use a different representation for containers? What if this new representation is such that the user's kludges for erasing all the elements are seriously inefficient?) You don't want your users to ask you whether _today_ it is best to clear all the elements using the technique A or by the tecnique B, right? It is not by chance that all the STL containers have a clear() method.
Enough for advocacy, please find below a patch adding a remove_all() method to the containers. I feel that the name "remove_all" fits well with the others. The patch allows `make check' to complete successfully and the documentation looks good. I have been careful to follow your coding style. Please let me know if I haven't been successful and I will submit a revised patch. All the best
Roberto

Hi,
On Sun, 20 Jan 2002, Roberto Bagnara wrote: [...]
public: virtual ${CONTAINER} & append(const ex & b); virtual ${CONTAINER} & remove_last(void);
- virtual ${CONTAINER} & remove_all(void);
[...]
This changes lst's vtable layout and is therefore likely to break binary compatibility. Whatever is decided on this, we should not put it in CVS for this reason.
Until November we have not been nice to people w.r.t. compatibility. I hope we manage to be a little bit more civilized from now on. The scheme I am having in mind is currently this: During 1.0.n, don't break binary compatibility, i.e. never set BINARY_AGE to zero. (Of course, INTERFACE_AGE may be set to zero, though.) Accumulate such paches as the above or Douglas' safe_bool and throw them all into 1.1.0. Repeat the game for 1.1.n.
I know how to handle my libraries and others may know also, but let's face it: this stuff is somewhat advanced and we don't want to run around and explain LD_PRELOAD and friends to the people. It also helps package maintainance on distro-side as a whole. Because then, a package libginac0 bringing with it the file $prefix/lib/libginac-1.0.so.0.2.1 can live on its own and have other packages depend on it and later on a package libginac1 can be added and just adds $prefix/lib/libginac-1.1.so.1.0.0 but does not replace the old library. That one can be phased out when no other packages depend on it downstream. Dazed and confused? Hmm, shared library management tends to confuse people but the libtool scheme can potentially solve all the problems, so let's enforce it a bit.
Now the real question is: How do we introduce branches in our CVS tree?
Regards -richy.
participants (2)
-
Richard B. Kreckel
-
Roberto Bagnara