[GiNaC-devel] Class container vs. the holy standard?

Richard B. Kreckel kreckel at ginac.de
Thu Jul 20 00:00:34 CEST 2006


Hi!

On 2006-05-09, I wrote:

>
> I'm undecided: check that in or check in the other alternative that 
> basically makes all containers std::allocator<ex> based?  In any case, 
> I don't think this is anything for the 1.3 branch since it changes the 
> signature of everything containing a GiNaC::lst.  Maybe toss a coin?
>

GCC 4.2 is slowly drawing nearer, according to [0]. And with that 
release, compilation of GiNaC will fail. I would like to fix the problem 
in CVS, but I still have no strong feeling about which of the two 
proposed patches to apply. To recapitulate: The problem was the 
definition of template <template <class> class C> container where C is 
std::list<ex> or another STL container. But the container declaration 
doesn't account for the allocator template argument, which is in 
conflict with the standard.

Patch 1 ([1a] or [1b]):
Turn the template <template <class> class C> container into template 
<template <class T, class = std::allocator<T> > class C> container. Pro: 
Binary compatible (can be applied to 1.3-branch). Con: The intent is to 
express container of something and some allocator but rather container 
of something.

Patch 2 ([2]):
Add template <template <class, class> class C> container_with_allocator 
and use that for STL types. Pro: Expresses the original idea. Con: Not 
binary compatible (function signatures containing a lst& will differ) 
and may only be applied to HEAD. Some code duplication.

There is another possiblity, very similar to Patch 2, but with the two 
types named differently:

Patch 3):
Change template <template <class> class C> container into template 
<template <class> class C> container_without_allocator and add a 
template <template <class, class> class C> container to be used with STL 
types. Pro: Binary compatible (can be applied to 1.3-branch). Con: 
Attaches a strange name to the "normal" case and a clear name to the 
special case. Same code duplication as in patch 2.

Although it may appear confusing I am inclined to check in patch 3 to 
the 1.3-branch and patch 2 to HEAD. I'm going to do that within a few 
days unless somebody raises objections.

This might be a good time for asking about the status of HEAD and the 
branch. Are there any projects pending? Jens, could you roll a release 
(whichever version) in the not so far future (including regenerated 
Bison files)?

Regards
  -richy.

[0] <http://gcc.gnu.org/ml/gcc/2006-07/msg00394.html>
[1a] <http://www.ginac.de/pipermail/ginac-list/2006-April/000830.html>
[1b] <http://www.ginac.de/pipermail/ginac-devel/2006-April/000932.html>
[2] <http://www.ginac.de/pipermail/ginac-devel/2006-May/000959.html>

-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>




More information about the GiNaC-devel mailing list