Pure virtual function problem.

Started by
10 comments, last by MaulingMonkey 18 years, 11 months ago
The teacher for my computer graphics class gave us a java interface that he wants us to implement in a raytracer that we're doing for the class. I've decided that I want to do this program in C++ so I've been trying to write the C++ equivalent of an interface. This is what the base class looks like:

class IntersectObject
{
    public:
        virtual Vertex* intersect(const Vertex& p1, const Vertex& p2)=0;
        // more similiar functions
}

// Then I have another class:

class Plane : public IntersectObject
{
    public:
        Plane(...);
        ~Plane();

        Vertex* intersect(const Vertex& p1, const Vertex p2);
       // more similiar functions
}

Elseware in my program I have a data structure that is storing pointers to IntersectObjects. When I call something like this:

IntersectObject* tempObj;
Vertex* temp = NULL;

// ...

tempObj = (IntersectObject*)objects.get(i);
temp = tempObj->intersect(p1, p2);

I get an access violation error with intersect. Is there something that I need to do so that it knows that it should be calling the right function? Should the this pointer handle all of that? Thanks.
Advertisement
The syntax is fine. Looks like your interface function isn't returning a valid pointer.
Do you know for sure that tempObj is non-null?

Also, why do you need to explicitly cast to (IntersectObject*)? If objects.get() returns a compatible pointer type, the cast shouldn't be nessesary. If the cast is nessesary to get to to compile, then there's probably a design error, afaik.
Quote:
Do you know for sure that tempObj is non-null?

Also, why do you need to explicitly cast to (IntersectObject*)? If objects.get() returns a compatible pointer type, the cast shouldn't be nessesary. If the cast is nessesary to get to to compile, then there's probably a design error, afaik.

The cast is not necessary (just for cleanliness) and tempObj is not null.

Quote:
The syntax is fine. Looks like your interface function isn't returning a valid pointer.

If this is the case, how would I fix that? Or if you can't answer that with what I've given, do you know what could cause that?

[Edited by - Fibonacci One on April 24, 2005 2:04:38 PM]
Quote:Original post by Fibonacci One
The cast is not necessary (just for cleanliness) and tempObj is not null.
That's not cleanliness in most people's book. Cast's are inherrently dirty and the less the better. Unnecessary casts are just code dirt.

make sure you don't do anything stupid like:
IntersectObject::IntersectObject(){  memset(this, 0, sizeof(*this)); // DON'T DO THIS!!!}
Also check that the pointer returned is not 0xCDCDCDCD, or 0xCCCCCCCC or something funny like that.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
What does objects.get(i) look like? Odds are your problem is there. Also, when casting you should use static_cast<IntersectObject*>(obj), using a C-style cast will probably stuff up when using multiple inheritence.
"Voilà! In view, a humble vaudevillian veteran, cast vicariously as both victim and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity, is a vestige of the vox populi, now vacant, vanished. However, this valorous visitation of a bygone vexation stands vivified, and has vowed to vanquish these venal and virulent vermin vanguarding vice and vouchsafing the violently vicious and voracious violation of volition. The only verdict is vengeance; a vendetta held as a votive, not in vain, for the value and veracity of such shall one day vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage veers most verbose, so let me simply add that it's my very good honor to meet you and you may call me V.".....V
Quote:Original post by iMalc
That's not cleanliness in most people's book. Cast's are inherrently dirty and the less the better. Unnecessary casts are just code dirt.
I'll keep that in mind.

Quote:
make sure you don't do anything stupid like:
IntersectObject::IntersectObject(){  memset(this, 0, sizeof(*this)); // DON'T DO THIS!!!}

check.

Quote:Also check that the pointer returned is not 0xCDCDCDCD, or 0xCCCCCCCC or something funny like that.
Maybe this will help:
Image Hosted by ImageShack.us
The address it keeps trying to access is the 0th one on that list. As for why a whole bunch of them are zero, I don't know. Right now my program only (trys to) calls the first (index 0) and third (index 2) functions in the class.

Also, in the main I have a global (only while debugging) variable declared as
IntersectObject* io
Then I create it with:
io = new Plane(...)
virtual Vertex* intersect(const Vertex& p1, const Vertex& p2)=0;//...        Vertex* intersect(const Vertex& p1, const Vertex  p2);                                                     ---^---


Is this a typeo or are you really missing it?

In theory you shouldn't be able to instantiate the plane with that function - but a buggy compiler might be letting it slide and causing all sorts of problems?

Now if you'll excuse me I just spilt rootbeer on my keyboard. It needs cleaning. :(
Quote:Is this a typeo or are you really missing it?

Dangit, I really wish I had made that mistake. Unfortunitely that was just a typo when writing it up here. =/

I went ahead and set my program to work with a specific type of object so I could get some work done in another area. For the lighting I'm using the data structure that our teacher wrote (same one I use for the objects). I'm getting some weird cases where some values are going in as one thing and coming out as another. I have a feeling I'm either using the list wrong or that there is some bug in it.

Sorry about the keyboard man, that can be a killer pain to get cleaned properly. =


Quote:Original post by Fibonacci One
Quote:Is this a typeo or are you really missing it?

Dangit, I really wish I had made that mistake. Unfortunitely that was just a typo when writing it up here. =/


It's probably best to show the real code. We're debugging what you think it should be doing rather than what it's actually doing...

This topic is closed to new replies.

Advertisement