The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

C++ Types, Templates, and Inheritance

This problem is hard for me, so even describing it is a challenge.  I apologize in advance for that.

I have an interface which defines an enumeration and a subclass based on that enumeration:
struct A {
  enum Test { X, Y, Z };
  template <Test test> struct Internal {};
  ...
};

I further have an implementation of that interface:
struct B : public A {
  templat <Test test> struct Internal
      : public A::Internal<test> {};
...
};

Making it more complex, in reality the constructor for A::Internal takes a different parameter for each template specialization.

The problem is I need a function that takes a compile time type, a run-time parameter of an appropriate type, and returns an B::Internal object of that type.

But I need to have the function be callable through the A interface.

I'm looking to avoid switches or if-statement chains.  Does anyone know a way to do this?  Thanks for the help.
Masamune
Wednesday, May 30, 2007
 
 
Ok, for reference, I've convinced myself that it cannot be done.  I'll just go with the back-up plan.

Wednesday, May 30, 2007
 
 
In cases like this, it is often helpful to take a good hard look at your design. You'll often find you're trying to shoehorn a construct into a design that is simply not suitable for it.

Your example looks like a nice case of template-abuse. Templates are great, but using is a bit like sculpting with dynamite: You have to know extremely well what you are doing, or the whole thing will blow up and turn into a pile of rubble.
Jeroen
Thursday, May 31, 2007
 
 
We could help you with your achitecture if you could provide a description of what you actually want to achieve, not what your problem is.

Personnaly, it may be obvious but I didn't understand why your inner struct was a template in the first place because you don't show us any specialization. Without saying how you will specialize it, showing just the template can be a little obscure...
Vincent Robert Send private email
Thursday, May 31, 2007
 
 
I think what you described is actually possible - as noted above, it's difficult to tell, because your presentation of the problem is too abstract.

You can't return a B::Internal from the A interface, but you can return a pointer or reference to a B::Internal, because that will be disguised as an A.... In other words, the interface is designed to return an A::Internal pointer, the implementation B will construct a B::Internal, and return the A::Internal pointer to it.  NOTE: using a smart pointer would be better.

Your issue with the constructor arguments, that probably gets solved using traits.
Danil Send private email
Thursday, May 31, 2007
 
 
I want to serialize a specific type in my program.  Essentially, I want a function that takes a type and returns an integer.  (T => () -> int)

There are a changing number of types.  In order to minimize the code that changes with the addition or removal of types, I wanted to keep one master list of types.  The closest I could come is using the enumeration.  (int -> T => () -> int)

The second issue is that there are multiple serialization function implementations which share a common interface.  But that conflicts with the templates.

So I want to minimize the changes needed when I add or remove a type.  RTTI is not enabled.

Thursday, May 31, 2007
 
 
How about using a CRC32 of the typename? This should provide you with a unique number for each type.
Coopsnakes Send private email
Friday, June 01, 2007
 
 
"This should provide you with a unique number for each type"
...most of the time.
Jeff Zanooda Send private email
Monday, June 04, 2007
 
 
"Essentially, I want a function that takes a type and returns an integer."

That part definitely sounds like it should be solved with traits.

As for the other, I wonder if a decorator, or perhaps a snap-in, would be a better choice than inheritance (effectively separating the responsibility of serialization from that of the objects actual behavior).
Danil Send private email
Tuesday, June 05, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz