Re: [lmi] Code review: product editor

[Greg Chicares]

On 2007-3-12 13:41 UTC, Vadim Zeitlin wrote:
> On Mon, 12 Mar 2007 14:32:08 +0100 Evgeniy Tarassov <address@hidden> wrote:
> 
> ET> > On 3/5/07, Greg Chicares <address@hidden> wrote:
> ET> > > Can you integrate what you've got with HEAD as it stands at
> ET> > > this moment, and put the result into a new branch? (Or update
> ET> 
> ET> As you have suggested I have created a new branch (from HEAD as of
> ET> 20070312T1141Z) and committed the patch there.
> ET> 
> ET> product-editor2_branch (Version: lmi-20070312T1120Z-product-editor2)
> ET> 
> ET> Patch summary: rewrite MultiDimGrid using templates instead of
> ET> boost::preprocessor library, eliminating the use of macros.
> 
>  FWIW I'm personally still sceptical about the merits of this replacement.
> Formally speaking, there are no macros any more, of course, but I'm not
> sure if the goal of making the code simpler to understand and maintain was
> achieved by removing them. I'm probably not 100% objective here but it
> seems to me that macros were simpler than the new type-list based code (but
> using type lists is the only alternative for implementing a type-safe
> interface to these classes).

Why don't we just write two separate typesafe class templates:
  template<typename ValueType> UnidimensionalTable;   // MultiDimTable1
  template<typename ValueType> MultidimensionalTable; // MultiDimTable7
without any metaprogramming? I.e., neither preprocessor metaprogramming
nor template metaprogramming. (I had thought that we might be able to
save a little duplication by adding one nontype parameter for "1" or "7",
but that wouldn't make much difference anyway, and I guess we've proved
that it's not practical.)

A ValueType template parameter seems valuable because it lets us use
both numeric and string types, along with slightly more exotic things
like std::pair<double,double>. That means we'll be able to combine all
the product files together someday instead of having four separate kinds.

But we don't need to make the axes generic. There are only two cases:
 (1) one single axis;
 (2) one single set of multiple axes.
In case (2), the axes are always the same. If we ever add a new axis,
we'll add it for all entities. Thus, MultiDimTable7 might become
MultiDimTable9 (which is why I'd rename it as above), but we won't have
both MultiDimTableX and MultiDimTableY (for X!=Y!=1) at the same time.
We can hardcode the axes.