Way to know the class


#1

Hi, is there a better way than using a dynamic cast to determine the class of a juce component ?

Currently I’m using:

Slider*slider = dynamic_cast<Slider*>(component); if (slider) { // it's a slider! }
What I’m looking is a possible virtual function like:

Is that present already ? of any way to avoid the “slow” dynamic cast ?


#2

C++ classes are different from Java classes in that they don’t have any clue of their own properties (name, member functions, etc). What is called “reflection” is not available in C++.
So, C++ developers have a set of techniques to work around this restriction and do a specific action depending on the actual type of an object: visitors, polymorphism, double dispatch, etc.

But to be able to tell you which pattern suits your problem, you’d need to give a bit more information on what you actually intend to do (the context where you need it). And read a bit more about C++ programming, because those techniques will always be trickier than a simple function call.


#3

Hi, well actually I’m not looking for anything related to java. I’m simply afraid of using the dynamic casting which does exactly what I want to but which one is also very slow… In another framework I’m using, there is a className() virtual function which simply returns the class name of the object. Obviously it does not work with multiple heritage but that is still much faster than dynamic casting an object. This is why I’m wondering if there is something in the JUCE libs to achieve so. There is a little article talking about this here if you see what I mean.
The context is not very important but just to show it, I’m enumerating all the contents in a view and would like to know if they are a button, a slider or anything else in order to then init them. It’s more an optimization issue than a design pattern one. Thank you for your answer in anyway :slight_smile:


#4

So many fallacies in one sentence…!

  1. Is it slow? How fast is it? Unless you can quote me an actual time, you can’t make that assertion.
  2. What makes you think that anything else could do the same job faster? If it was possible, don’t you think the compiler would already do it in a faster way?
  3. Even if it was incredibly slow, then to actually be a performance problem you’d have to call it a serious number of times. Have you profiled your app and found this to be a hotspot? If not, you’re wasting your time in even thinking about this.

If you really are calling dynamic_cast so often that it genuinely causes a performance problem, then you don’t need a faster alternative, you need a better overall design that requires less type-checking!


#5

Ok let’s be relative:

  1. Slower than a regular cast (200 times)
  2. The paper I read and some experiences, an int comparison is still faster than virtually parsing a whole object in a class
  3. Of course it depends on the usage, for a gui init that is not really a problem

Maybe I’ve the printer coder syndrome, I worked on several projects where speed really matter given the very little CPU we had…
This said, I’m glad to know that I’m the only one to worry about the slowness of a dynamic cast, I simply won’t from now on :wink:


#6

I’d be more worried about the maintenance costs of function that used dynamic_cast on “every possible subclass” to figure out what it is.

WHY do you need to do such a thing? If you really need to know, why don’t you take advantage of the Component object’s “property” interface and store a string for each created object:

Component::getProperties


#7

Basically, I built an environment where I could store objects into (like a scripting language). When you would like to invoke a method on one of those object you need obviously to know which native c++ class is behind. If you can ask the object itself to tell what it is that’s still better. This is useful for serialization. I use also this a lot for json schema validation (in my framework there is 4 classes for array, dictionary, numbers and strings) and therefore have to know which class is behind to know if it does match the schema at runtime. Still in our framework, we do have a setValueForKeyPath, when you set the value you can accept more than one type (and the type is not always only one of the 4 above) here again it is quicker to ask the class instead of casting to objects.


#8

You can do this using multiple inheritance, just subclass each JUCE Component-derived class you want to use, and add a common parent. The parent can expose some “getClassName” interface, or whatever you want.

An easier way to serialize, again, is to give each created object a common base class interface using multiple inheritance. Then, walk the tree of components and call each object to serialize. There’s supporting classes and a complete example in the VFLib docs for doing this:

componentBroadcast


#9

Good =) that’s funny that it just came from a simple casting question. I saw that you managed to put Lua into juce, that is possibly something that I will look about “some day”.


#10

There’s no integration of Lua and JUCE together, other than VFLib includes a vf_lua module. Beyond that they are separate.


#11

Basically, I built an environment where I could store objects into (like a scripting language). When you would like to invoke a method on one of those object you need obviously to know which native c++ class is behind. If you can ask the object itself to tell what it is that’s still better. This is useful for serialization. I use also this a lot for json schema validation (in my framework there is 4 classes for array, dictionary, numbers and strings) and therefore have to know which class is behind to know if it does match the schema at runtime. Still in our framework, we do have a setValueForKeyPath, when you set the value you can accept more than one type (and the type is not always only one of the 4 above) here again it is quicker to ask the class instead of casting to objects.[/quote]

If this is your use case, I refer you back to:

Unless your language is a extremely basic, the overhead of your dispatcher is going to be far more of a bottle neck than a one dynamic cast per method call.

I’ve built a medical imaging application builder out of Lua and JUCE. We use this to develop medical imaging apps, observer studies, and command line utils (which often are running on servers). Every single method call is going to terminate in a dynamic_cast somewhere, but the cost of this is beyond negligible when compared to the overall cost of Lua, itself extremely efficient. Trust me, any performance issues we run into are going to a) the cost of doing busy loops in an interpreted language, or b) my crappy image processing code. The cost of masquerading C++ classes as Lua libraries is not something I’ve ever needed to worry about.

That said, if you really want a little extra speed, just have all your classes inherit from an ABC that has a classID() method that returns an enum. I personally would shudder to do this for the very pertinent reason given by The Vinn a few posts back.


#12

FWIW I’ve only ever seen one project that genuinely did need a faster (and very clever) alternative to dynamic_cast, and that’s in the Clang parser. But their situation is incredibly unusual, and those guys really know what they’re doing.