i would create a base class, which would contain a bitset and in each derived class i would add a new flag (in constructor), giving my objects type id, ie: is_logable, is_whatever, etc..
pros/cons?
my own RTTI
Author
would a custom RTTI system, based on std::bitset, be worth the trouble, is it faster than typeid?
AFAIK, bitwise operations are fast, really fast
i would create a base class, which would contain a bitset and in each derived class i would add a new flag (in constructor), giving my objects type id, ie: is_logable, is_whatever, etc..
pros/cons?
i would create a base class, which would contain a bitset and in each derived class i would add a new flag (in constructor), giving my objects type id, ie: is_logable, is_whatever, etc..
pros/cons?
RTTI is bad design in almost every case. Can''t you come up with some basic class structure instead?
Yeah like for a CGameObject base class you would only need 3 public methods:
virtual void init();
virtual void update(long delta_t);
virtual void do_event(Event e);
and Event would be overridden to do EVERYTHING for your objects depending on its types. Like for a bullet event could be 'set velocity' but for a scenerery object chair 'set velocity' might not have an effect.
[edited by - sagwagon on January 25, 2004 1:34:20 PM]
virtual void init();
virtual void update(long delta_t);
virtual void do_event(Event e);
and Event would be overridden to do EVERYTHING for your objects depending on its types. Like for a bullet event could be 'set velocity' but for a scenerery object chair 'set velocity' might not have an effect.
[edited by - sagwagon on January 25, 2004 1:34:20 PM]
Author
ok, let''s leave the design questions out for now...
how does std::bitset compare to c++ built in RTTI, in terms of performace? anybody knows?
how does std::bitset compare to c++ built in RTTI, in terms of performace? anybody knows?
When in doubt try it yourself and see.
This seems fruitless however because I really doubt that RTTI would be *the* bottleneck in your application. If it is, then its probably a sign that you are abusing it. Since it probably isn''t the bottleneck, you can focus on those things that ARE slowing you down, not the ones that ''seem'' slow to you because you''ve read they are.
This seems fruitless however because I really doubt that RTTI would be *the* bottleneck in your application. If it is, then its probably a sign that you are abusing it. Since it probably isn''t the bottleneck, you can focus on those things that ARE slowing you down, not the ones that ''seem'' slow to you because you''ve read they are.
Author
@antareus
i understand ur point...
but if u(i) think that everything is too slow, why not "now" think about it?
it's not like i'm gonna devote a month to it...
one more question:
what operations go on in built in RTTI?
[edited by - vesoljc on January 25, 2004 4:58:40 PM]
i understand ur point...
but if u(i) think that everything is too slow, why not "now" think about it?
it's not like i'm gonna devote a month to it...one more question:
what operations go on in built in RTTI?
[edited by - vesoljc on January 25, 2004 4:58:40 PM]
My hunch is that what you''re planning would cause your application to perform worse overall than using native RTTI. The reason being is that you intend to embed type information in your objects on a per-object basis which will increase overall object size smacking you with decreased memory performance.
Plus, wheres the advantage? Once you''ve determined that your class is loggable, you''re going to need some kind of cast to get at it''s logging function anyway, which usually means a dynamic_cast to a logging interface.
Nevermind the small fact that capability queries are usually a bad idea in the first place.
Plus, wheres the advantage? Once you''ve determined that your class is loggable, you''re going to need some kind of cast to get at it''s logging function anyway, which usually means a dynamic_cast to a logging interface.
Nevermind the small fact that capability queries are usually a bad idea in the first place.
quote:Original post by Raloth
RTTI is bad design in almost every case. Can''t you come up with some basic class structure instead?
In a lot of cases it''s bad and the needed behavior can probably be handled with some virtual functions, but it''s pretty handy when serializing/deserializing classes to/from a file... you have to know what class to construct when loading, which means you have to save some RTTI info when saving.
Author
@SiCrane
my idea allready needs a status made out of bitwise flags (sort of a stete machine) and as such imho, the memory impact would not be so big. few bytes up or down... it''s still under 1k
my idea allready needs a status made out of bitwise flags (sort of a stete machine) and as such imho, the memory impact would not be so big. few bytes up or down... it''s still under 1k
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
