I'm very bad with recursion, never used it before. I know the theory of it .. not that that helps :)) For my problem i have a structure of TCollection that contains TCollection and TCollectionItem etc .. I have to write a recursion function that will read all my TCollectionItems.
Here is graphical view:
TCollection->TCollectionItem(s)->TCollection->TCollectionItem(s)
TCollection can have 1 or even 2,3 TCollection's under him OR none.
Here are few more examples:
TCollection->TCollectionItem
TCollection->TCollectionItem->TCollection->TCollectionItem->TCollection->TCollectionItem
etc ..
Please tell me if i described the problem badly, i probably did .. please ask if something is unclear :)
Thanks for the support!
You haven't indicated the prototypes of the TCollection methods so as to enumerate and to read your TCollectionItems, and other needed details.
However, this is definitely solved by: The Composite Design Pattern.
The aim of this pattern is to traverse a recursive form, and to forward a call on a composite onto its composants and so on, until that reaches the leaves ( TCollectionItems with an empty TCollection in your case)
The only way to recursively access child TCollection objects, without knowing the class types of the owning TCollectionItem objects so you can type-cast them, is to use the VCL's RTTI information.
In C++Builder versions prior to XE, VCL-based RTTI is only available for __published properties. Given a TCollectionItem (or any general TObject) object pointer, you can use the GetPropList() function declared in TypInfo.hpp to retreive a list of that object's published property information. You can then loop through that list, checking for any properties that report a TypeKind value of tkClass. When you find one, use the GetObjectProp() function to retreive that property's TObject pointer value, and then use dynamic_cast to make sure it is really a TCollection object before you access its child TCollectionItem objects.
In C++Builder 2010, a new Enhanced RTTI system was introduced, declared in Rtti.hpp, that provides information for all members of a class, including non-published properties and fields. With this enhanded RTTI, a child TCollection does not need to be declared as a __published property anymore. Under this system, you would use the TRttiContext class to access a TRttiType object for your recursion's starting TCollectionItem object, then use the TRttiType::GetFields() and TRttiType::GetProperties() methods to look for child TRttiField and TRttiProperty items that report a TypeKind of tkClass, then use the TRttiField::GetValue() and TRttiProperty::GetValue() methods to get the TObject object pointer that can be type-casted to a TCollection pointer with dynamic_cast.
Related
In a cpp plugin I am developing in Maya API, I register a custom MPxTransform Node in the initializePlugin function:
status=pluginFn.registerTransform("mympxtransform",
myMPxTransformClass::id,
&myMPxTransformClass::creator,
&myMPxTransformClass::initialize,
&myMPxTransformMatrixClass::creator,
myMPxTransformMatrixClass::id);
And then create the node programmatically:
MDagModifier mdagmod;
MObject MyMObject;
MyMObject=mdagmod.createNode("mympxtransform",MObject::kNullObj,&status);
I can see the node properly created in the outliner.
But now, how can I access my custom myMPxTransformClass from the obtained MyMObject ?
Solution To This Problem:
You would just have to do:
myMPxTransformClass* newDerived = (myMPxTransformClass*)&transformedObj; // 1)
// For debugging
MGlobal::displayInfo(newDerived->className());
1) What we do here is basically create a pointer of your class' type and assign to it the type casted pointer to the created MObject. The compiler wouldn't allow type-casting MObject itself, but the pointer to it can be type-casted into your class' pointer (myMPxTransformClass*).
We can then just use the pointer to access the class' methods and so on.
p.s. In the case of the dynamic_cast, attempting to cast MObject directly won't work because MObject is not a polymorphic type (intentionally).
Side Recommendation:
On a side note, I wanted to add this. This is mostly my opinion. Since I don't know what you are trying to do with your code, please take this recommendation with a grain of salt.
According to core Maya's principle,
Thou shall never access member functions of a node/MObject in Maya.
Once it has been created, it is solely under Maya's control. The only way you can (sort of) control it is using Maya's provided function sets (MFn Classes) for that node type (in your case MFnTransform set because your node is a kPluginTransformNode which is a transform node).
In the case you have class data members that you might want to operate with and manipulate programmatically, you will have to make them actual Maya attributes for that node (and thereby expose them to Maya). Then, you will be able to get them as MPlugs and do your thing.
Looking at your code, I feel that there are two components you are majorly aiming to produce, a node(s) (i.e. your custom MPxTransform); and a functor kind of class (i.e. UnitClass) that does something with/to your node(s). I would recommend splitting your plugin then into two separate components: a node and a command. That way there is clear separation of responsibilities. Because, as it stands right now, just loading your plugin creates the node(s) and also operates on them. The user might be confused as to what might be happening. If you separated them into a node and a command that does the thing, they can be used in many different ways as the user sees fit. The command could be the entry point for the user to use your plugin.
Hope this helps!
Here's another way of doing it using the api:
myMPxTransformClass* node= (myMPxTransformClass*)(MFnDependencyNode(myMObject).userNode());
I'm a little new to writing in C so I hope I'm not to far off base here.
I'm working on a library to handle the control of multiple types of LED ICs. There are a ton of different types of RGB Pixel libraries each with their own unique naming, but all really perform the same basic actions. A "strip" or "strand" object is created, each pixel gets a color value set, and the strip then gets updated.
My library handles getting pixel color values from software in the back ground and providing the user with the most recent values from an array belonging to the object.
What I would like is to allow the user to initiate their LED strip object and pass a reference to that object to my library, and then allow them to pass their objects "setPixelColor()" function and "UpdateStrip()" function to the library as well. If this is achievable then I believe my library could then handle all of light control operations for any given PixelLibrary.
I believe what I'm looking for is the proper way to pass a functions pointer between objects? Not looking for someone to do this for me, but just looking for directed guidance. Been searching google for while this morning, but I don't know that I'm even using the proper terms. Any advice or guidance would be a big help. Thanks!
Sounds like what you need is a base class or virtual base/interface. You define a class with common data and methods which work across all your LEDs. This common or abstract class defines the common functions. Each of your LED strand types will then inherit the base class/interface and implement the specific functions to set an LED for example.
Using this approach the application code works using the Base class/interface methods treating all the strands the same way.
If you use this approach, I also recommend you create a static factory method which returns a base class/interface pointer after creating the specifically required object.
abstractController=CreateLEDStrandController("Strand Type");//Creates the right object, returns an abstracted base class pointer.
abstractController.SetLEDColor("RED"); //Actually calls the specific object SetLEDColor
I've been looking at some related threads but still don't find anything that answers the following question.
Let's say I have a hierarchy of classes (e.g. Widgets, HTML element) that form a tree structure. When I walk through the tree or look for a concrete element based on its ID I get a pointer to the base class (the tree algorithms only know about the base class).
Then, based on the type (the base class has a field that identifies the type) I perform a dynamic_cast in order to get a pointer to the concrete type. I've been thinking about ways to avoid this. The only thing that comes to my mind is the visitor pattern. But don't like very much this pattern.
Are there other ways/patterns to search/iterate nodes and get a pointer to the concrete class without using RTTI nor the visitor pattern?
Your approach doesn't sound like a good idea. Mostly because you have to do all the considerations before the runtime.
What you want to do is basically have the specific properties of a object listed and accessible. With dynamic casting this is possible but hardly elegant - since you have to write a trainload of switches and hardcode each and every possibility in advance so you can use it at runtime.
The solution I'd recommend as usual is the Qt framework. You can list the properties for each object at runtime, access a specific property by its name string or index and even attach properties during the runtime that don't exist in the code. And all this is type agnostic, you don't need to know an object's type to know its properties, and lastly - Qt offers a significantly faster qobject_cast for QObject derived classes instead of dynamic_cast.
The meta system allows you to know the class name, the base class name, methods, enums, constructors and pretty much everything, so besides properties, it is a good source for accessing all the functionality, available to an instance.
It really depends on the implementation of the visitor pattern. Using dynamic_cast<> is one way, another might be to use a handcrafted RTTI by defining a virtual GetType() function which can be implemented in all the subclasses. Depending on the result of that function you can do different things.
(This question is more for the people who have access to the book, It's hard to put it into context otherwise)
I've been reading through the GoF's 'Design Patterns' book and there's a sentence that confuses me a little, under 'Creational Patterns->Prototype->Sample code' (page 124).
Near the bottom of the page, there is the implemententation for BombedWall, which as I understand is a concrete prototype, as it inherits from Wall, and redefines the Clone() virtual function. BombedWall also defines another method, HasBomb(), unknown to any clients using the regular Wall interface.
The only way that BombedWall is stored in MazePrototypeFactory (the Prototype client) is as a Wall* (returned from BombedWall::Clone), and the only way to get to HasBomb() afterwards, as far as I understand, is to perform a downcast on that Wall* to a BombedWall* (dynamic or static, depending on whether I know the type), and then I can access the HasBomb() method.
This all seemed fine to me; but then later the author says (same page, last sentence, 2nd last paragraph):
"Clients should never have to downcast the return value of Clone to
the desired type"
What? Then how am I supposed to get to HasBomb()?
I must be missing something...
I gave an answer and totally rewrote it now :)
Basically, the MazePrototypeFactory only knows about the base classes it can use. It doesn't know anything about any of the subclasses you are going to make, but it still should be able to put any possible subclass out there into the maze.
The pattern basically ensures MazeFactory will get a pointer of a type that it understands, Wall, than cause the MazeFactory to need to be modified to be able to produce objects of all the subclasses.
MazeFactory is the client referred to on p 124. It doesn't need to know about HasBomb in order to build the maze.
My guess is that this method only exists to indicate that BombedWall is a different class with extended public interface. Hovewer, this interface is not used in the context of the sample: the maze building algorithm does not differentiate types of walls, while other subsystems (for example, rendering engine) may do so.
i have an accounts class
from that i have 3 types of accounts
savings, credit, and homeloan.
i created a binary search tree to hold all the accounts as type account
how do i now access the methods of the subclasses depending on the type of object?
have resolved all errors with syntax and codeing but this.
been racking my head for 2 days . does anyone know how this is done ?
The simple answer is, if you need to access the derived class functionality from a base class pointer, you have a design problem. In principle, you shouldn't need to know. If you do, something is wrong.
You're supposed (in a pure sense) to call virtual functions from the base class interface, and have the derived classes implement their overrides such that they perform correctly.
Now then, sometimes, practically, you have to. So there is the possibility of a downcast. If you have Run Time Type information in your build, you can do a dynamic_cast<type*> and if the pointer you get back is non-null, then you have an instance of that type.
If you do go down this path, wrap it in something neat and don't let it proliferate - it can get messy. I suggest you see if there isn't a better way, using polymorphism.
Have fun!