OT: Call Derived method using Base ptr?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/03/2005 at 21:38, xxxxxxxx wrote:

User Information:
Cinema 4D Version:    
Platform:      
Language(s) :     C++  ;

---------
I know this is C++ specific and not SDK specific, but so far I haven't found an answer (looking at my CMP Developer Network resources currently).

There is a Base class and several (over 40!) Derived classes from this. Naturally, for sanity, the list of instances are stored, passed around, and accessed using Base class pointers.

When I want to call the Derived class's method, I have to cast the Base pointer to the Derived type. Is there a way to generalize this so that I don't have lists and lists of conditional statements to determine the type and then cast to that type for every Derived class method call?

If you have a more specific term on which to search or a link to a relevant article, that would be superb!

Thanks,

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/03/2005 at 22:10, xxxxxxxx wrote:

Too late to delete. ;)

Found it. Pure virtual methods are what I need. There are so so many facets to this overly, superly, extremely complex language it is easy to forget one of the million of them...

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 20/03/2005 at 07:08, xxxxxxxx wrote:

Yep, abstract base classes are the best interface to go. :) Don´t forget to have a virtual destructor and remember it´s not possible to instantiate this class.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 20/03/2005 at 10:27, xxxxxxxx wrote:

I'm relearning. ;) It's been years since I sat down and actually learned C++ (then moved onto 3D CG and Java and then back to C++ for the SDK). Yes, the base class has a virtual destructor and is never instantiated.

Have Stroustrop nearby, but he doesn't cover everything (or make it easy to find everything). For instance, there is zero mention of Class Member Function Pointer Arrays in that ~700 page tome of his. And it's not the most straight forward, intuitive solution to using them. The one thing that this CMP Developer Network needs is a better search feature. I found the solution in the first link with a Google search.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 21/03/2005 at 04:21, xxxxxxxx wrote:

:) yes, not all covered in Stroustrop but in general an excellent resource for all kind of issues (I would have been disappointed if this wasn´t the case).

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/03/2005 at 06:47, xxxxxxxx wrote:

Quote: Originally posted by kuroyume0161 on 20  March 2005
>
> * * *
>
> Have Stroustrop nearby, but he doesn't cover everything (or make it easy to find everything). For instance, there is zero mention of Class Member Function Pointer Arrays in that ~700 page tome of his. And it's not the most straight forward, intuitive solution to using them. The one thing that this CMP Developer Network needs is a better search feature. I found the solution in the first link with a Google search.
>
> * * *
In a pure OOP view of C++ it makes sense not to mention Function pointers.
Because they are a violation of some of the base concepts of OOP which are robustness, stability and reusability. Meaning that they are not at all robust, because the compiler is unable to detect wrong parameters at compiletime, the first to detect it is the user with a crash at runtime.
I am only trying to defeating Stroustrup, please dont take it as an offence. I really like the concept of OOP and i am still impressed about this guy who made a one Person revolution in programming with his work.
greetings
developer

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/03/2005 at 07:08, xxxxxxxx wrote:

Hi,

You are right concerning OOP and function pointers, but you have to consider that C++ is NOT meant to be an OOP language only, but is also used for i.e. system programming (that´s why its paradigms are OO and procedural). That´s also what Stroustrup says.

Anyway, using function pointers is sometimes even useful. For example, you can sometimes replace virtual functions with FP and gain some performance speed ups through it. Furthermore, if you use FP and you know how to handle them, they are less error prone than normal pointers, as you will never allocate or deallocate memory with them.

It´s surely not the cleanest/clearest and most readable way of programming in C++ and using function pointers should be well considered (one should always ask oneself if a function pointer is really needed) but I wouldn´t go that far to say it´s a violation.

My 2 cents..

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/03/2005 at 07:10, xxxxxxxx wrote:

In a pure OOP environment, there would be no global functions (besides main()). Every method would be attached to a class...like Java. Stroustrup definitely doesn't follow that. This is the reason I moved to Java - C++ is C + some OOP stuff. The drive towards C++ OOP has improved over the years (and it took many), but there are far better OOP implementations.

Function arrays really don't require breaking OOP, just compiler robustness as you say. Unless you expect other-party access to your code (library, sdk) and you can actually program and type, then crashes are unlikely.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/03/2005 at 07:20, xxxxxxxx wrote:

Quote: _C++ is C + some OOP stuff.
>
> * * *
_

Although C is a subset of C++ (this also has marketing strategy reasons) it´s a seperate language (see Stroustrup)!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/03/2005 at 09:10, xxxxxxxx wrote:

You are both agreeing and disagreeing with me, 3DD. ;)

That is my point completely. C++ is its own language, but it has very strong ties to C, a procedural language in all its gory glory. In C, function pointers are the norm (I should know, I've been programming in C for nearly twenty years!). But, as you say, C++ is not PURE OOP - no way. It's OOP plus procedural (thus C+OOP). Either way you look at it, there is still the subset of procedural support and standards.

So, for someone to come in and say that function pointer arrays are not mentioned in Stroustrup because of pure OOP is totally incorrect. The expected behavior would be that standard C protocol would be in use, therefore you reference K&R.; Ah, but not so in classes. So there is either no support of function pointers in class methods or there is. The answer is this: "Strictly speaking, we at C++ never want to see an array of class function pointers, but heck, there are ways around it, just do a Google search for the myriad ways in which this nonfeature is featured!" :)

Now I remember why I loved Java so much - complete departure from procedural paradigms.

Back to SDK, please...