Thread: Class method overloading

This has been one of my deepest forays into C++ programming, having been scared off in the past by the arcana of memory management . I 'cured' my memory management problems by incorporating garbage collection thanks to Hans Boehm. (OK I don't like writing destructors or remembering when to call them.)

I now however have run into an interesting problem with function overloading in an inherited class.
I have a situation that looks something like this:

Code:

class Foo {
public:
void setdims()
{
.....
}

void func1 ()
{
setdims() ;
}

} ;  /* end class Foo */

class Bar: public Foo {
public:
void setdims()
{
.....  /* different implementation */
}

} ; /* end class Bar */

I did not label setdims() as virtual since the behavior I want is for setdims to be overloaded for a class of type Bar and the Foo's setdims() to be hidden. However what happens when I call the inherited function func1() for a class of type Bar? (e.g. Bar x ; x.func1() ; ) Apparently with MS's compiler it calls Foo's setdims() and not Bar's setdims(). This is not the behavior I want. Basically I'd like to reuse Foo's code, since the only major functional change for many methods is what get's allocated in the function setdims(). Thus I'd like to call the parent's class func1() but have it call the overloaded setdims() not the parent's setdims().

How do I fix this? Do I need the virtual descriptor here? Is this what is supposed to happen?
Thanks in advance for your help.

Originally Posted by dwks

Err . . . you shouldn't have to call destructors. They should automatically be called when a class goes out of scope or is deleted. Perhaps you meant that you don't like remembering when to delete classes.

Yes that's what I meant thanks, and by the way how nice it is to not have to worry about that stuff. I suppose I could have also played around with some of those smart pointer types as well to help with this, but garbage collection seems to work pretty well if you have memory to burn.

I think that's what virtual functions are supposed to do, isn't it?

http://www.parashift.com/c++-faq-lit...functions.html

So yes, I think you should try making Foo's setdims() virtual. (virtual functions that are overloaded automatically have "virtual" in front of them, or at least they act that way; but putting "virtual" in front of Bar's setdims() can't hurt.)

Yes I just tried it and you are correct, it seems to fix the problem and it even makes sense now. Moreover I don't think the virtual table overhead will be an issue for my problem either. Thanks for the help.

Originally Posted by SevenThunders

This has been one of my deepest forays into C++ programming, having been scared off in the past by the arcana of memory management . I 'cured' my memory management problems by incorporating garbage collection thanks to Hans Boehm. (OK I don't like writing destructors or remembering when to call them.)

GC is a pretty hackish solution to resource management in C++, since we have containers, smart pointers, and RAII. I would hate to think that my objects might never be deleted at all, at the whim of the GC, or deleted in an order I have no control over.

As far as overriding methods, whether you use "virtual" depends on whether you want to make calls to the objects through a pointer or reference to one of its base classes. Since you use GC, I assume you've got pointers all over the dang place, and so you probably want to be using "virtual." Polymorphism can't work without it.

Originally Posted by brewbuck

GC is a pretty hackish solution to resource management in C++, since we have containers, smart pointers, and RAII. I would hate to think that my objects might never be deleted at all, at the whim of the GC, or deleted in an order I have no control over.

As far as overriding methods, whether you use "virtual" depends on whether you want to make calls to the objects through a pointer or reference to one of its base classes. Since you use GC, I assume you've got pointers all over the dang place, and so you probably want to be using "virtual." Polymorphism can't work without it.

I don't know why it's that hack'ish. Java, D, Haskell, O'Caml and many other useful languages use garbage collection. The only real performance hit is that it's not as memory efficient but then again memory is cheap. IMHO C++ tends to generate a lot of memory leaks, especially for beginners like me.

I think it makes C++ a lot more pleasant to program, but then I haven't messed around with some of the smart pointer stuff yet.

Originally Posted by SevenThunders

I don't know why it's that hack'ish. Java, D, Haskell, O'Caml and many other useful languages use garbage collection. The only real performance hit is that it's not as memory efficient but then again memory is cheap. IMHO C++ tends to generate a lot of memory leaks, especially for beginners like me.

I think it makes C++ a lot more pleasant to program, but then I haven't messed around with some of the smart pointer stuff yet.

One of the things I don't like about languages like Java is that they have a new keyword, but no delete. Yes, it has garbage collection, but what if I don't want to wait for something that might never happen? I also want destructors and stack based objects so I can have RAII objects...

Originally Posted by cpjust

One of the things I don't like about languages like Java is that they have a new keyword, but no delete. Yes, it has garbage collection, but what if I don't want to wait for something that might never happen? I also want destructors and stack based objects so I can have RAII objects...

I confess I have never even heard of RAII until now. It sounds interesting, I see how it could be useful. You are correct that in most languages where the garbage control is built in, you do not have fine control over the collector. With the Hans Boehm collector you do have control in that you can explicitly free or suspend the collector if you need a computation to run in a finite period of time etc.

Here is some propaganda with regards to D's garbage collector.
http://www.digitalmars.com/d/2.0/garbage.html
I guess it's possible to control the behavior of D's collector as well to some extent.

Originally Posted by SevenThunders

I don't know why it's that hack'ish. Java, D, Haskell, O'Caml and many other useful languages use garbage collection.

I believe I qualified my statement with the words "in C++..." There are better ways to do it in C++.

Java forces you to "new" everything, there is no such thing as an automatic variable, and it gives you no "delete" and so the only choice is GC.

Haskell and O'Caml aren't even imperative languages so they inherently can't support a concept such as RAII -- well, at least without using those "monad" things.

And I have no idea about D.

GC makes sense in a lot of languages. I think C++ is not one of them.

Originally Posted by brewbuck

I believe I qualified my statement with the words "in C++..." There are better ways to do it in C++.

Java forces you to "new" everything, there is no such thing as an automatic variable, and it gives you no "delete" and so the only choice is GC.

Haskell and O'Caml aren't even imperative languages so they inherently can't support a concept such as RAII -- well, at least without using those "monad" things.

And I have no idea about D.

GC makes sense in a lot of languages. I think C++ is not one of them.

I know we are drifting waaaay off topic, but it is an interesting point to some extent. I think most C++ programmers would agree with you. However I still think GC has some good applications in C++. It eases the burden of writing destructors, worrying about dangling references etc. and is actually has some performance benefits when a lot of small objects are being created and destroyed. Even Microsoft has a compacting GC with it's "Managed C++", though I understand it requires a language extension.

For memory critical applications and if real time is important, then I will concede the point.

I just can't see what's so scary about writing destructors? Most of the time, I don't even need one since I don't create many object-level pointers... but if I allocate something in the constructor, I deallocate it in the destructor.

part of your program was written by Neanderthals

I run into this problem far too often.