C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

confusion with overloads of virtual/nonvirtual or bug in Int

 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated)
View previous topic :: View next topic  
Author Message
andrew_nuss@yahoo.com
Guest





PostPosted: Sun Jun 04, 2006 6:15 pm    Post subject: confusion with overloads of virtual/nonvirtual or bug in Int Reply with quote



Hi,

I have a base class:

class Allocator {
public:
// non virtual inline alloc used 99.9% of time
void* Alloc (size_t minSize)
{
return Alloc2(minSize, true);
}

virtual void* Alloc2 (size_t minSize, bool tally) = 0;
virtual void Free (void* p) = 0;
};

Obviously my various allocator classes extend Allocator and provide
implementations
for Alloc2 and Free. They are called BuddyHeap and SimpleAllocator and
VMHeap.

90% of time my apis use Allocator& but some apis just use VMHeap& since
the VM functions
have access to all of the members of VMHeap. This works fine.

However, if in Allocator, BuddyHeap, etc. I try to change the name of
Alloc2 to Alloc, using
name overloading between a non-virtual function and virtual function,
then in those
calls to Alloc with just 1 parameter, my Linux Intel C++ Compiler
cannot resolve Alloc
with one parameter when called from VMHeap& reference. It says I'm
missing the extra
parameter since VMHeap extends BuddyHeap and BuddyHeap only provides
the 2 param
version, hoping that the one param version (non-virtual inline) from
the base class would be used.

It seems that when there is overloading, the 2 param version of Alloc
hides the one param
version in the base class. The 2 workarounds are to use Alloc2 as
above and avoid
overloading, in which case the inline version of the base class is
found for VMHeap&, OR
with overloading, explictly declare the inline version in both
Allocator and BuddyHeap.

Is this an example of my lack of understanding C++ rules regarding
overloading of names
across virtual and non-virtual functions, or is it a bug in the Intel
C++ compiler?

Thanks,
Andy


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Back to top
Heinz Ozwirk
Guest





PostPosted: Mon Jun 05, 2006 3:35 am    Post subject: Re: confusion with overloads of virtual/nonvirtual or bug in Reply with quote



<andrew_nuss (AT) yahoo (DOT) com> schrieb im Newsbeitrag
news:1149398611.511276.43260 (AT) u72g2000cwu (DOT) googlegroups.com...
....
Quote:
It seems that when there is overloading, the 2 param version of Alloc
hides the one param
version in the base class. The 2 workarounds are to use Alloc2 as
above and avoid
overloading, in which case the inline version of the base class is
found for VMHeap&, OR
with overloading, explictly declare the inline version in both
Allocator and BuddyHeap.

Is this an example of my lack of understanding C++ rules regarding
overloading of names
across virtual and non-virtual functions, or is it a bug in the Intel
C++ compiler?

I'm afraid the first one is true. Any member name in a derived class hides
all base class members with the same name, but that has nothing to do with
virtual and non-virtual member functions. That's the way C++ works. But
there is a third workaround - use a using directive:

class Base
{
public:
void foo();
};
class Derived: public Base
{
public:
using Base::foo;
void foo(int);
};

HTH
Heinz


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.