Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

vesoljc

my own RTTI

This topic is 5413 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
RTTI is bad design in almost every case. Can''t you come up with some basic class structure instead?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
@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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.


Share this post


Link to post
Share on other sites
@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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!