Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Skyrunner]

When you store the INHx pointers in a vector<BASE *> they are implicitly cast to that type, so your overloads of idenitfy will definitely not do what you wish. But as you can see the correct reimplemented virtual function is called, so that's what you have to work with.

The cleanest is to make a virtual id() function (return an int or enum or whatever), reimplement for each inheriting class and test against that in identify(BASE id). The alternative is dynamic_cast and test for non-NULL, which tends to be discouraged (but is sometimes useful).

It's pretty sad that what would seem like a perfect usage of OOP-thingies doesn't actually work in C++.

The fun thing is, I have been working on a project that adds some reflection to C++ classes. The ReflectBase class and Reflect.h header file are where most of the work is done. Note that this requires using GCC, as it uses the GNU C++ ABI functions. I'm not sure if MSVC has a compatible set of functions.

Darn, I guess I won't be using those. o_O

[MorleyDev]

It's not clean, but there is a pattern that can work. If you typeid and store the address of the result of that with your type, and then use another map to map between handling functions. I usually use this when I can give it to the container in it's fullest form via templatyes, and then you pull it in it's fullest form, and hide that it gets turned to an interim type.

But honestly, if you're relying on this behaviour at a high level (I only really find need of it it for type-safe event systems) it's usually a design flaw, a sign either your base classes do too much or your higher level classes do too little.

[Skyrunner]

Code: [Select]

if (part->type() == "cannon")
      {
      auto partpointer = dynamic_cast<ShipCannons*>(part);
      getProfile(*partpointer, line);
      }
    else if (part->type() == "armor")
      {
      auto partpointer = dynamic_cast<ShipArmor*>(part);
      getProfile(*partpointer, line);
      }
    else if (part->type() == "statue")
      {
      auto partpointer = dynamic_cast<ShipStatue*>(part);
      getProfile(*partpointer, line);
      }
    else if (part->type() == "sails")
      {
      auto partpointer = dynamic_cast<ShipSails*>(part);
      getProfile(*partpointer, line);
      }
This is the code I went with. It's pretty much what you said, map between handling functions. getProfile() is overloaded for each derived class.

[olemars]

What in the getProfile overloads require that the pointer is of the derived type?

[Siquo]

What in the getProfile overloads require that the pointer is of the derived type?

Yeah, it's this what I don't get. Most of the fun of inheritance is that it shouldn't matter which of the derived classes it is.

[Skyrunner]

What in the getProfile overloads require that the pointer is of the derived type?

Yeah, it's this what I don't get. Most of the fun of inheritance is that it shouldn't matter which of the derived classes it is.

I know, but the thing is.

Spoiler (click to show/hide)

Well crap.

Link to my quandry.

If you can't tell what it is by the code, it's that even if you have a vector of BASE*, which all point to various inherited classes, their type is still BASE* even when dereferenced. That means an overloaded function can't tell what type the input is. I can't think of a clean way to make them identify properly.

The current output is

I am BASE. Identified as BASE
I am INHERITED 1. Identified as BASE
I am INHERITED 2. Identified as BASE
I am INHERITED 3. Identified as BASE
I am INHERITED 4. Identified as BASE
I am BASE. Identified as BASE
I am INHERITED 1. Identified as BASE

Ideal output is

I am BASE. Identified as BASE
I am INHERITED 1. Identified as INH1
I am INHERITED 2. Identified as INH2
I am INHERITED 3. Identified as INH3
I am INHERITED 4. Identified as INH4
I am BASE. Identified as BASE
I am INHERITED 1. Identified as INH1

What am I missing here? What I want to do is store multiple inherited classes in one vector, and then be able to tell what type they are via overloaded functions. I don't think an OOP language would miss this very obvious usage of OOP... would it? >_>

(This kinda sounds like reflection.)

edit: someone pointed me towards RTTI, which I kinda want. The wiki article seems to imply that it's a trial-and-error process and that there's nothing as clean as simply class in overloaded function out

As I detailed in the quote in the spoiler, I want to store all my ___Parts in a single vector, but the very act of storing a class in a vector in C++ obliterates its identity as a derived class In an ideal world I'd just call getProfile(**part) and the compiler would do all the magic for me.


.. Am I missing something?

[olemars]

It doesn't obliterate its identity. The onlooker just sees the object then and there as an instance of the parent class, but if you ask the object something it will behave like the derived class it really is.

The only time you really need a pointer to an object of the derived class is during creation or if you've extended the interface and need to call a function not declared in the parent class.

[Siquo]

.. Am I missing something?

I'm not able to try it out, but what if you remove identify(BASE obj)? That will force the runtime to find a better match.

[olemars]

You can't implicitly downcast like that.

[Siquo]

No, I just tried it, it feeds a BASE* of course. Duh.

* Siquo smacks forehead

Anyway, the proper solution would be for "identify" to be on the BASE object (such as myName is). The problem with your solution is that every time you add a new derived class, you also need to add stuff outside of that object pertaining to that object, leading to spaghetti.

I know this sounds a lot like the hated "you should not be doing that in the first place"-type "solutions", but I implore you to see if it's not possible to have a more generic outside function that can handle any type of BASE, using (either virtual or not) methods of that BASE (or derived) object, without it knowing what type of BASE it is.

[ECrownofFire]

Why not just have getProfile(line) as a virtual member function?

The cleanest solution when dealing with polymorphism is... more polymorphism!

[Skyrunner]

No, I just tried it, it feeds a BASE* of course. Duh.

* Siquo smacks forehead

Anyway, the proper solution would be for "identify" to be on the BASE object (such as myName is). The problem with your solution is that every time you add a new derived class, you also need to add stuff outside of that object pertaining to that object, leading to spaghetti.

I know this sounds a lot like the hated "you should not be doing that in the first place"-type "solutions", but I implore you to see if it's not possible to have a more generic outside function that can handle any type of BASE, using (either virtual or not) methods of that BASE (or derived) object, without it knowing what type of BASE it is.

Well, if I wrap my current solution in a function that's exactly what it is xD
Or if I'm understanding it wrong: because C++ doesn't have reflection or stuff, and because that function is intimately tied to what data the derived class has, I can't make a more generic function than this.

Why not just have getProfile(line) as a virtual member function?

The cleanest solution when dealing with polymorphism is... more polymorphism!

This seems to be a pretty solid idea, though in my specific case it's a bit clunky. O.o

[Mego]

I did some research - MSVC has a function that can supposedly demangle type names, but apparently it doesn't work unless the type is in the global scope. If it's a nested type or inside of a namespace, it doesn't work.

Unfortunately, it looks like your options are as follows:

1. Lots of boilerplate code, adding a pure virtual function in an abstract base class, and override it in every single subclass, so that it returns the type name of the class.
2. Switch to GCC, use the GNU C++ ABI header, and drop support for MSVC.

[MadocComadrin]

I'm currently working with some half-finished code which implements a bastardized form of the command pattern. Long story short, I now have to implement a switch over an enum with over 100 cases. I just finished the 'c's.

Arrrrghbhsadsphfpharghupaofh.

Edit: Oh, and I can't even use reflection to pick out the methods that need to be invoked because the enum is set up weirdly.

[Skyrunner]

I did some research - MSVC has a function that can supposedly demangle type names, but apparently it doesn't work unless the type is in the global scope. If it's a nested type or inside of a namespace, it doesn't work.

Unfortunately, it looks like your options are as follows:

1. Lots of boilerplate code, adding a pure virtual function in an abstract base class, and override it in every single subclass, so that it returns the type name of the class.
2. Switch to GCC, use the GNU C++ ABI header, and drop support for MSVC.

I feel that msvs compatibility is worth having clunky code in pplaces. Its debugger is unparallelled.