is there any nicer (ie that requires writing less functions etc.) way that a base can call a derived function using a base as a parameter, and it calls the correct derived function?
ie. none of them know what type they are, yet they're executing the function I want.

I think you oversimplified your example here. What it looks like you're asking to do would be an ambiguous overload which isn't allowed. If this is for something like a copy function then you don't have to do all of this since all of the common data members would be in the base class.

EDIT: Now if 'a' and 'b' were pointers to their respective classes this would be possible. You could have the base class hold a data member that indicated what class type the pointer resolves to but at that point it seems like it would be better to redesign your code if it is still possible.

So if object 'a' is a sphere and object 'b' is a ray then you want to see if 'b' intersects 'a' right?

If I understood you then you would just have to make the array of coordinates (or what ever is defining the dimensions of the object) accessible from the base class. I'd give the base class a pointer that gets set to the array containing the objects coordinates when the object is constructed.

no, these are bounding volumes, it's not ray-anything intersection, it's rather the is a inside b type of stuff, therefore order matters (that is why I included base::_f() and the others).
it wouldn't be too great to store anything else in these except those that are required by the mathematical definition (we could have millions of these), so I gues this is not an option.

I'm just going to see my way out of this thread now. We've now gone from outputting text based on data_type to some mathematical concept that you have yet to adequately describe. You are completely changing the parameters of your request with every post you make and your sentence structure seems to be degrading at an astonishing rate.

Virtual functions provide a way to identify the type of an object, and run a different function based on that type.

So if you have 2 child classes A and B that inherit from a common parent... they would each have their own version of a function.

The problem here is the same concept... only he needs to identify two objects. So if you have those same classes A and B... you'd need four functions... one for AA pair, one for AB, one for BA, and one for BB.

This is particularly nasty not only because it grows exponentially.... but also because any solution is going to require some area of code to be aware of other classes. So it's difficult to keep it encapsulated.

The best approach I could come up with is to have each class return some kind of ID. Merge the ID from both objects involved in the collision somehow (ie, shift one of them, then OR them)... and throw that merged ID in a big switch, which will call the appropriate collision function.

With this approach, adding a new class involves several steps:
1) Add the actual class
2) Add X new intersection functions... one for where this class intersects with itself... and one for each other class.
3) Update the big switch to include those new functions.

Like I said... it's not a good approach. But I can't think of any better way to do it.

@ Disch: You only need a separate function for each data type if you need to handle each data type differently. If each class is only concerned about the properties of the base class then there is no need to define a different function for each combination of classes. LB is right, this is a design issue.

EDIT: I got flustered because the OP was posting the problem piecemeal. Every post he made added another design consideration that was never mentioned before.

You can map pairs of std::type_index to std::functions rather easily, and the map can be generated by global static initialization without any one part of the code having to know about all the classes. Even loading DLLs would work fine this way. The obvious cost is performance, but that's for the profiler to decide.

Then tell me, computergeek, how can you detect intersection between two circles without knowing they're both circles?

Or circle/rectangle?
Or rectangle/rectangle?
Or circle/triangle
etc
etc

Each shape (child class) needs to be handled differently. And each interaction needs its own logic.

EDIT:

Your previous suggestion of "making an array of points available in the base class" is one approach... but that would be extremely slow and clunky... and would restrict you to a finite, discrete coordinate system, rather than being able to work with real numbers.

To the logic of:
- Generating a finite list of discrete points in a massive array.
- Checking each and every one of those points to see if they exist inside of another circle.

EDIT2:

LB wrote:

You can map pairs of std::type_index to std::functions rather easily, and the map can be generated by global static initialization without any one part of the code having to know about all the classes.

Ultimately you're going to have to have a series of functions which cover every permutation of all shapes' intersections. So at least that part of the code will need to be aware of all classes.

Building this map automatically is also a challenge without a centralized area knowing all the classes. It doesn't seem to be as easy as you make it sound.

Whenever the N'th class is added... you have to add (at least) N permutations to the map. How can you do generate permutations without knowing what classes you're dealing with?

Ex: If I already have Square and Triangle functions set up.... when I add a 3rd class Circle... I have to add at least 3 more functions (OP said he will actually need 5):

Circle/Circle
Circle/Square (need to be aware of Square's existence)
Circle/Triangle (need to be aware of Triangle's existence)
Square/Circle (OP said order is important)
Triangle/Circle (ditto)

If you have a way to automate this that doesn't require maintaining a central list... that is exactly what the OP is asking for. I don't have a good solution. If you do, I've love to hear it, as I'm interested in this as well.

How I would do it? Off the top of my head I would try to use trigonometry; each object would hold a function that describes what Cartiesian points they occupy on the the plane. Of course that won't work for the OP since it involves iterating through all of the coordinate points in each shape but no one knew that he was dealing with bounding volumes until two hours after his initial post.

While it may have helped if the OP gave the full context up front... hopefully now we all understand what he's talking about.

So now... if you still don't understand the problem, please ask about what part is tripping you up so we can help clarify.

And if you do understand the problem, and if you have a solution, then I am very interested in hearing it. (no sarcasm intended... I've thought about this problem many times in the past and would seriously love a good solution to it)