views:

568

answers:

6

Consider a class Calendar that stores a bunch of Date objects. The calendar is designed to hold a collection of any type of objects that inherit from Date. I thought the best way to do it is to have a class template such as

template<typename D> class Calendar{ 
    ...
}

But it struck me that D can now in fact be any class. My question is now, how can I make sure that D is a subclass of the date object?

I know how to do this is Java, but I'm still unfamiliar with the C++ syntax. The problem is very much similar to how some collections can only take a template variables that implement Comparable. The header would then look something like

public class Calendar<D extends Date>{
     ...
}

--------------------EDIT: ------------------------------------------

The template argument defines which actual day the calendar refers to. Different date types refer to the same day in different formats. For instance, if I make a Calendar<Gregorian> it will be able to take dates in another Date format, say the Julian calendar, or any other date format and present them in Gregorian format. This enables for conversion between calendars in different date formats. So, if I have a Calendar<Gregorian> I can easily convert it into a Calendar<Julian>. Then the following is possible:

Calendar<Gregorian> cal;
std::cout << "These events are entered as dates in 
    the Gregorian calendar" << std::endl;
cal.add_event("Christmas", 12, 25);
cal.add_event("Gregorian new year", 1, 1);
std::cout << cal << std::endl;
std::cout << "----" << std::endl;
std::cout << "And printed out as Julian dates" << std::endl;
Calendar<Julian>(cal);
std::cout << cal<< std::endl;

and outputs:

These events are entered as dates in the Gregorian calendar
2009-12-25 Christmas
2010-01-01 Gregorian new year
----
And printed out as Julian dates
2009-12-13 Christmas
2009-12-19 Gregorian new year

------------- New edit: ----------------------

The last edit now makes more sense. I had a slight disagreement with the formatting.

Thanks for all the answers.

I'm a Computer Science student on my third year, and I'd say I'm fairly familiar with OO and related concepts like Polymorphism etc. The purpose of this post was to find out whether or not there was a way in C++ to express a condition for a template argument the same way that it is in Java and solve the problem in a concise, elegant and intuitive way.

+3  A: 

I think your problem is solvable without using templates. D is always a derived class of Date, then why not just have a collection of Date objects?

leiz
Actually, I'm mostly curious of the syntax, but some functions of the class (irrelevant for the question) also require that I have an exact type.
Nubsis
A: 

If you only want to interact with Date objects, why not just use plain polymorphism and simply deal with Date*-s?

If you plan to have a collection of Dates in Calendar, which can contain instances of different Date subclasses, then I doubt templates are going to work and you have nothing but polymorphism to help you out in the first place.

As to templates, if a given type has a suitable interface, why shouldn't it work with the Calendar? (Well, concepts were planned for C++0x, but dropped, but their main motivation seemed to be to allow clearer template-related error messages.)

UncleBens
+6  A: 

What you're looking for is concept checks for template arguments. These had been part of the draft for the next C++ standard, but had been thrown out again a few weeks/months ago.

Without concepts in the language proper, there are a few libraries that try to do this, but the reason for wanting concept checks being part of the core language is that it is more or less impossible to implement them without language support.

In your concrete example this shouldn't bee too hard, though. For example, you could put some special typedef into the base class and check for that:

class date {
  public:
    typedef int is_derived_from_date;
};

template<typename D> class Calendar{ 
    typedef typename D::is_derived_from_date blah;
    ...
};

Another way would be to pick any of the is_derived<B,D>::result template meta functions floating around on the net and implement a static check for this in your Calender class. Boost has both the is_derived meta function and a static assert.

Having said all this, however, I have to question your design. What's wrong with ordinary OO polymorphism that you want to use templates' compile-time polymorphism?

sbi
Re. the last paragraph, what's wrong with templates' compile-time polymorphism, that you want to use ordinary OO polymorphism? I agree, the mix is awkward. From what info we have, it seems like both dynamic and static polymorphism could work. And then I'd prefer static.
jalf
@jalf: I might, too. But from the question it seems Marco already knows OO polymorphism pretty well, whereas IME many take quite a while to understand what advanced template stuff and static polymorphism. So for C++ beginners knowing OO, I'd suggest sticking to this until they feel more familiar with the C++ way of doing it.
sbi
true. Either approach is valid. The template route would be more idiomatic C++, I think, but the OO one is more familiar to beginners and non-C++ programmers. It's just the mix of the two that gets problematic.
jalf
@jalf: "The template route would be more idiomatic C++". We wish it would, don't we? Yet, in the last ten years, I have met only _one_ guy who knew what static polymorphism is about. (Most of the others probably thought it's a nasty STD.) I can't believe that's all been due to me being with the wrong companies...
sbi
Well, depends on how you define "idiomatic" then. It might not be the most common route, but I think (and hope) it's the one the C++ gurus would recommend. But yeah, you're right.
jalf
+2  A: 

Templates usually don't require inheritance/polymorphism restrictions. A template is designed to work with any type that satisfies the given requirements regardless of base types.

template <typename T>
T clone(const T& cloneable) {
    return cloneable.create_clone();
}

This code will work for any type that has supports a create_clone() operation, no ICloneable-interface is used!

In your case, this code will allow any type that behaves like a date to be used.

If you want base class polymorphism, just leave the templates out and use Date*.

Note that if you really want to do your template test, you can try to cast a dummy object pointer to Date* which will fail at compile time if it is no derivative of Date. But this is normally not the way template code is used.

Dario
+8  A: 

I know how to do this is Java, but I'm still unfamiliar with the C++ syntax. The problem is very much similar to how some collections can only take a template variables that implement Comparable. The header would then look something like

public class Calendar<D extends Date>{
     ...
}

True, it is the same problem, and in C++, it is usually solved by ignoring it. Why do we need to enforce that the object must implement IComparable? In Java, it's necessary because of its anemic type system. Without this constraint, we'd be unable to compare objects.

In C++, the rules are different. Containers simply try to compare the objects they store, and if the type doesn't support it, you get a compile error. No interfaces or inheritance is required.

And you'd typically do the same in your Calendar class. Simply don't enforce the "must subclass form Date constraint.

Instead, specify the members the type must expose, and what, if any, semantics should be expected from them.

For example, if your Calendar attempts to do the following operations, for date objects d0 and d1:

d0.getDay();
d0.getTime();
Time t = d0 - d1;

Then those are the operations that should be supported. Any class which supports these operations is a valid Date class, even if it doesn't subclass anything.

jalf
IMO that's the best answer so far. I wish my answer would have simply said that duck typing is fine. +1
sbi
+1 for using static polymorphism
fnieto
+1  A: 

In C++ speak, this is called concept checking. In C++, a commonly stated best practice is that inheritance is used for inheriting interfaces and not implementation. So you're not actually so much interested about whether D inherits from Date, but whether D has the interface elements of Date that you need, namely it has the requisite member functions etc. The advantage then of this is that you don't need to have future D classes needing to inherit from Date, they just need to implement certain functions.

Concept checking was removed in C++0x, but you can find it in Boost.ConceptCheck (Boost main site is here).

If you really want to enforce that D inherits from Date though, you can use Boost.StaticAssert in combination with Boost.TypeTraits to check if D inherits from Date.

blwy10