I want to create an "auto-registering" type-info system to avoid the niceties I would run into if I used RTTI, so I thought of this:

class WObject {
 private:
  static int NextTypeID;
  int ObjectType;

 public:
  // Constructor, destructor, ...

  static int getNextTypeID( void ) {
    int temp = NextTypeID;
    NextTypeID++;
    return temp;
  }

  int getObjectType( void ) { return ObjectType }
};
 

Now, all performance issues aside, I have a problem. Each derived class would need to get its own type ID when the first object of that class is created. I could easily do this by writing it into each constructor, but I''m looking for a way to enforce this behaviour (basically, I want to forget about it in all derived classes). Any idea how this could be done?

One reason could be that RTTI is not guarenteed across all compilers or even different runs to output the same thing.
And as for OT''s question, um....no Unless you are trying to use this system for serialization, use the RTTI system...else:

You shouldn''t need a int for each instance for each class. Instead, you need just one int for each type of class. So, you should implement a virtual function:
virtual const char* name() {...} which returns the name.

Override in each child class. There''s no other way around that, ...well, there is another way, but it''s far more complex and you *still* have to ''register'' the class in one way or another.

quote:Original post by antareus
So why are you avoiding RTTI?

Simply because its cost is unpredictable and I''d have to use it a lot. Also because it wouldn''t really fit in and its use for identifying objects would be a kludge.

I also can’t see any way to do what you are trying to do. If the derived classes are to be oblivious to the type system, then the base class somehow needs to handle it. And I don’t know how a base class can ever know which derived classes it has without getting help from those derived classes.

Since RTTI is built into the compiler, chances are it’s at least as fast any manual way of handling it. If you plan on using more than one compiler, you might have a compatibility issue as risingdragon3 said. But I’m not sure I know what you mean about it being unpredictable.

If you need to use it a lot , then you might rethink the design. If your program often needs to ask objects what class they are, it may not be very object oriented. Typically, in object oriented designs, code is together with the data it operates on so that it doesn’t need to ask what class it is except in a few cases. But then again, I don’t know exactly what you are doing. It’s just a suggestion.

quote:Original post by JimH
Since RTTI is built into the compiler, chances are it’s at least as fast any manual way of handling it. If you plan on using more than one compiler, you might have a compatibility issue as risingdragon3 said. But I’m not sure I know what you mean about it being unpredictable.

no, because every tiny class will get RTTI, which is a waste. manual RTTI on just the ''major'' classes imo is better.

quote:
Seems like the typeid() feature of RTTI is exactly what he wants, but how is it not guaranteed to return the same thing after runs?

Well, that''s the worse case - it''s not guarented in the standard. With different compilers, you will get different output but ...if you just use one compiler, you''re good.

quote:
no, because every tiny class will get RTTI, which is a waste. manual RTTI on just the ''major'' classes imo is better.

Well, as far as I know, compilers only enable RTTI when the class is polymorphic... I''m not positive.

quote:Original post by billybob
no, because every tiny class will get RTTI, which is a waste. manual RTTI on just the 'major' classes imo is better.

Well, when I read the thread, for some reason I was thinking that Shadowdancer was most concerned with performance when he said “because its cost is unpredictable”. But reading it again, now I can’t say I’m sure specifically what his concerns are. Is it memory cost or performance cost?

From Effective C++ (which I refer to a lot) Scott Meyers says, “The language specification states that we’re guaranteed accurate information on an object’s dynamic type only if that type has at least one virtual function. ... This parallel between RTTI and virtual function tables is no accident: RTTI was designed to be implementable in terms of a class’s vtbl.”

So RTTI is very likely to be implemented in the vtbl, probably with an extra pointer in the vtbl which points to the class’s type_info. Classes (and structures) that do not have a vtbl are not likely to use up space for RTTI, although I imagine a compiler would be allowed to do so if it wanted to.

Anyway, you might want to test this more depending on the compiler you’re using. I just used Visual C++ to compile a small program both with and without RTTI enabled and it was exactly the same size. The program code didn’t actually use RTTI so perhaps the compiler was smart enough to realize that and not generate RTTI info where it wasn’t needed. (But I’d need to test it more to be sure. I don’t usually need RTTI so I’ve never looked at it closely.) Also, I believe you may be able to enable RTTI on a per-file basis if you want. In any case, I don’t believe it takes up significant space; it is per-class data only.

If I only needed type information for two or three classes, I might do as you say and roll my own. But Shadowdancer said he needed to use it a lot. The compiler’s type checking is more robust and almost certainly more efficient. If you want the functionality that run-time type checking provides, you’re going to have to pay for it one way or the other.

[edited by - JimH on May 5, 2003 1:36:24 PM]

Sorry, double post.

[edited by - JimH on May 4, 2003 10:11:02 PM]