The macro of interest for C++ is NORI_REGISTER_CLASS(cls, name)
- name is the string for querying the class name as a variable.
- cls is the actual class name in C++ for the macro.
This creates two things:
- a factory function that can be used to generate an instance of that class: cls *cls##_create(const PropertyList &list) where cls##_create creates an identifier where cls is taken from the macro
- a static struct whose constructor calls the factory method for registering the class as part of the automated factory system (NoriObjectFactory), which is actually instantiated in-place, and thus the constructor is called (exactly once).
The only trick is you don’t get the knowledge of when the instantiation happens (its order), you just know it’ll happen before main is called typically.
This is not needed for the students for this week, but it’s a neat thing to know in case you want to make it look fancy.
The whether it’s instantiated or not is simply decided by whether you are actually linking the object (or not).
You don’t need to include it with C++.
```
Bless you Alexandre. This will be something to check in on / take a day with, as ponyo progresses.
**2019 11 06**
For build / include / etc:
...
...
@@ -8,6 +34,8 @@ For build / include / etc:
- init code is for turning hardware on, and now classes can report whether they need to be singletons, or what hardwares they need, etc. we can use their string name from the class declaration as well, etc. hardware startups are only allowed on init(), ok
- great, that's much easier haha
I.E. here I was basically thinking to include some static code at each object, including the ponyo singleton, and then running ponyo->include(thing); and then thing includes a factory for itself...
**2019 10 21**
Today I think I will take my time on the compile-time build/sys for Ponyo. Answering questions like:
- how do I \#define classes so that they don't compile when I build an instance for a particular device?
