Anteru's blog
  • Consulting
  • Research
    • Assisted environment probe placement
    • Assisted texture assignment
    • Edge-Friend: Fast and Deterministic Catmull-Clark Subdivision Surfaces
    • Error Metrics for Smart Image Refinement
    • High-Quality Shadows for Streaming Terrain Rendering
    • Hybrid Sample-based Surface Rendering
    • Interactive rendering of Giga-Particle Fluid Simulations
    • Quantitative Analysis of Voxel Raytracing Acceleration Structures
    • Real-time Hybrid Hair Rendering
    • Real-Time Procedural Generation with GPU Work Graphs
    • Scalable rendering for very large meshes
    • Spatiotemporal Variance-Guided Filtering for Motion Blur
    • Subpixel Reconstruction Antialiasing
    • Tiled light trees
    • Towards Practical Meshlet Compression
  • About
  • Archive

Episode III and some C++

May 21, 2005
  • General
  • Programming
approximately 1 minutes to read

Woohaa, went to the cinema yesterday to watch StarWars:Episode III. Great! Surely the best of the first 3 movies, with some really amazing scenes, and, of course, incredible visual effects. This time it’s not a demo reel any more (like Episode II), but an interesting and emotional movie (reminds me of “The Empire strikes back”).

Rolling out your own RTTI

For my engine, it turned out that I would need some kind of RTTI system to be able to determine the exact type of resources I’m loading using plug-ins. This system would have to provide the following features:

  • Has to work in a multi-threaded environment
  • Must not import/export any kind of static data
  • Type checks have to be efficent
  • Support at least single inheritance, if possible, multiple inheritance
  • Does not need to support virtual inheritance
  • Easy to use
  • Only activated in classes that need it

C++’s built-in RTTI system was no option, as it was activated for all classes with a virtual function, something which I wanted to avoid. Moreover, it does not provide all the information I would like to store per-class. Hence, I decided to write my custom RTTI system. Turned out to be far more difficult than I thought it would be, took me now two weeks, in which I surely tried 4-5 different approaches which mostly solved the feature list, unfortunately not all of them. The final design uses a combination of static and virtual access functions, and a static class member that stores all type information. When performing run-time checks, the virtual function is called which returns the actual type of the class.

For querying parent classes, the static function is called which returns the static type of a class. This is all encapsulated into some template functions, which also produce compile-time errors when used with non-rtti classes. Type checking is done by two function pointer calls and a single pointer compare, which is efficient enough. All the developer has to do is to add a AR_DEFINE_CLASS to the class definition and a corresponding AR_IMPLEMENT_CLASS to the class source file.

Previous post
Next post

Recent posts

  • Data formats: Why CSV and JSON aren't the best
    Posted on 2024-12-29
  • Replacing cron with systemd-timers
    Posted on 2024-04-21
  • Open Source Maintenance
    Posted on 2024-04-02
  • Angular, Caddy, Gunicorn and Django
    Posted on 2023-10-21
  • Effective meetings
    Posted on 2022-09-12
  • Older posts

Find me on the web

  • GitHub
  • GPU database
  • Projects

Follow me

Anteru NIV_Anteru
Contents © 2005-2025
Anteru
Imprint/Impressum
Privacy policy/Datenschutz
Made with Liara
Last updated February 20, 2019