Re: VC++ 2005: private virtual functions

[Jochen Kalmbach [MVP]]

Hi Nemanja!
> ref class Base {
> virtual void SomeVirtualFunction()
> {Console::WriteLine(L"Base");}
> public:
> void SomeAccessibleFunction()
> {SomeVirtualFunction();}
> };
>
> ref class Derived : public Base {
> virtual void SomeVirtualFunction()
> {Console::WriteLine(L"Derived");}
> };
>
> int main(array<System::String ^> ^args)
> {
> Base^ handle = gcnew Derived();
> handle->SomeAccessibleFunction();
>
> return 0;
> }
>
> I would expect to get "Derived" as the result, right? However, I get
> "Base", and strange warnings during compilation:
>
> ".\PrivateVirtual.cpp(8) : warning C4486: 'Base::SomeVirtualFunction' :
> a private virtual method of a ref class or value class should be marked
> 'sealed'

"private" virtual functions are useless! because nobody can overwrite it!

You need to declare your virtual functions at least as "protected"!

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Nemanja Trifunovic]

Something I don't get it:

Say we have:

ref class Base {
virtual void SomeVirtualFunction()
{Console::WriteLine(L"Base");}
public:
void SomeAccessibleFunction()
{SomeVirtualFunction();}
};

ref class Derived : public Base {
virtual void SomeVirtualFunction()
{Console::WriteLine(L"Derived");}
};

int main(array<System::String ^> ^args)
{
Base^ handle = gcnew Derived();
handle->SomeAccessibleFunction();

return 0;
}

I would expect to get "Derived" as the result, right? However, I get
"Base", and strange warnings during compilation:

".\PrivateVirtual.cpp(8) : warning C4486: 'Base::SomeVirtualFunction' :
a private virtual method of a ref class or value class should be marked
'sealed'

.\PrivateVirtual.cpp(16) : warning C4486:
'Derived::SomeVirtualFunction' : a private virtual method of a ref

class or value class should be marked 'sealed'
"

If I try explicit overriding:

.\PrivateVirtual.cpp(17) : error C3671: 'Derived::SomeVirtualFunction'
: function does not override 'Base::SomeVirtualFunction'
.\PrivateVirtual.cpp(16) : warning C4486:
'Derived::SomeVirtualFunction' : a private virtual method of a ref

class or value class should be marked 'sealed'

What is going on here?

[Nemanja Trifunovic]

> private" virtual functions are useless! because nobody can overwrite it!

Read this article: http://www.gotw.ca/publications/mill18.htm

[Bo Persson]

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> skrev i
meddelandet news:ef7ldi2d...@tk2msftngp13.phx.gbl...

But note that this is so for managed code only. In real C++ it would
have worked!

Bo Persson

[Nemanja Trifunovic]

Even in "old" Managed C++ it works.

[Tamas Demjen]

It seems to be stupid from the C++ programmer's point of view, but then
.NET was not designed by C++ programmers.

Unfortunately in .NET virtual functions can't be private, they must be
protected. But even that modification won't solve your problem, you even
have to declare the function override to override a virtual function.
The correct code is

ref class Base {
protected:

virtual void SomeVirtualFunction()
{Console::WriteLine(L"Base");}
public:
void SomeAccessibleFunction()
{SomeVirtualFunction();}
};

ref class Derived : public Base {

protected:

virtual void SomeVirtualFunction()
{Console::WriteLine(L"Derived");}
};

I share your pain...

Tom

[Tamas Demjen]

Tamas Demjen wrote:
> ref class Derived : public Base {
> protected:
> virtual void SomeVirtualFunction()
> {Console::WriteLine(L"Derived");}
> };

Sorry I copied the wrong code:

ref class Derived : public Base {
protected:

virtual void SomeVirtualFunction() override
{Console::WriteLine(L"Derived");}
};

Note the override keyword, it indicates that the function is not
replacing Base::SomeVirtualFunction, but is overriding it.

Tom

[Nemanja Trifunovic]

Hi Tom.

>Unfortunately in .NET virtual functions can't be private, they must be protected

But I am pretty sure CLR allows private virtual functions. It works
fine with old MC++.

>But even that modification won't solve your problem, you even have to declare the function override to override a virtual function.

Yep, just noticed this in the C++/CLI spec. Actually, I pretty much
like this "controlled virtuality". Just have no idea why to disable
private virtual functions. Any clues?

[Tamas Demjen]

Nemanja Trifunovic wrote:

> Yep, just noticed this in the C++/CLI spec. Actually, I pretty much
> like this "controlled virtuality". Just have no idea why to disable
> private virtual functions. Any clues?

The reason I don't like this override keyword is that because if you
miss it, the function won't work like a virtual function anymore, and
there's not even a compiler warning. No override keyword == non-virtual
function, even if the virtual keyword is there. It's very frustrating
when you have a virtual function and it's not polymorphic.

If I make the virtual function private, I get the following .NET runtime
exception:

<quote>
An unhandled exception of type 'System.TypeLoadException' occurred in
Virtual.exe

Additional information: Method 'SomeVirtualFunction' on type 'Derived'
from assembly 'Virtual, Version=1.0.1999.26811, Culture=neutral,
PublicKeyToken=null' is overriding a method that is not visible from
that assembly.
</quote>

This is not a language feature, it's a .NET runtime exception, which
clearly states that overriding a private virtual function is not
supported by the runtime library.

I don't know if it's intentional, but this is happening with VC++ 2005
Beta2.

Tom

[Nemanja Trifunovic]

You are right - it does throw. However, with VC++ 2003, the following
code works just fine:

__gc class Base {
virtual void SomeVirtualFunction()
{Console::WriteLine(S"Base");}
public:
void SomeAccessibleFunction()
{SomeVirtualFunction();}
};
__gc class Derived : public Base {

virtual void SomeVirtualFunction()
{Console::WriteLine(L"Derived");}
};

int _tmain()
{
Base* handle = new Derived();
handle->SomeAccessibleFunction();
return 0;
}

Did they introduce this "feature" in CLR 2.0? That would be very
strange, indeed.

[Alexei]

Nemanja Trifunovic wrote:
> Yep, just noticed this in the C++/CLI spec. Actually, I pretty much
> like this "controlled virtuality". Just have no idea why to disable
> private virtual functions. Any clues?

Let me take a wild guess. Interoperability with other .NET languages?

[Nemanja Trifunovic]

And the same code on VC++2005 with /clr:oldsyntax gives the following
warning:

.\PrivateVirtual.cpp(46) : warning C4445: 'void
Base::SomeVirtualFunction(void)' : in a managed type a virtual method
cannot be private
.\PrivateVirtual.cpp(54) : warning C4445: 'void
Derived::SomeVirtualFunction(void)' : in a managed type a virtual
method cannot be private

But it works just fine!!!

Hehehe, is it weird or what? I'm gonna start ILDasm now to see what's
going on...

[Nemanja Trifunovic]

Hmmm.. here's the difference:

"/clr:oldsyntax":

.method private virtual instance void SomeVirtualFunction() cil
managed
{
...

"/clr":

.method private hidebysig strict virtual
instance void SomeVirtualFunction() cil managed
{

So the difference is "hidebysig strict" part. AFAIK hidebysig is
ignored by runetime and is used only by tools, but what the heck is
"strict"? I don't remember seing it before...

[Ronald Laeremans [MSFT]]

Nemanja Trifunovic wrote:
> Hmmm.. here's the difference:
>
> "/clr:oldsyntax":
>

> ..method private virtual instance void SomeVirtualFunction() cil
> managed
> {
> ....
>
> "/clr":
>
> ..method private hidebysig strict virtual

> instance void SomeVirtualFunction() cil managed
> {
>
> So the difference is "hidebysig strict" part. AFAIK hidebysig is
> ignored by runetime and is used only by tools, but what the heck is
> "strict"? I don't remember seing it before...
>

It means exactly what this thread is about: It prevents a private member
function from being overriden in a derived class. The reason the CLR
added this (and all the Microsoft languages emit this) is that the
design of the BCL and FX and common design pattersn in .NET make this a
security issue. Many base classes base security and threat model
analysis on the fact that a derived class cannot be inserted and change
behavior in the base class (like validation) that needs to bge immune to
being changed by further derived classes.

Ronald Laeremans
Visual C++

[Brandon Bray [MSFT]]

Nemanja Trifunovic wrote:
> Yep, just noticed this in the C++/CLI spec. Actually, I pretty much
> like this "controlled virtuality". Just have no idea why to disable
> private virtual functions. Any clues?

Private virtual functions are still useful for one scenario. In ref classes,
in order to override a virtual function, you have to have access to call it.
Since a private virtual function can never be called from outside the class,
it can never be overridden. Thus, to make the compiler stop issuing a
diagnostic for the private virtual function, you can use the "sealed"
keyword.

Now, virtual functions are also used to implement interface contracts. So,
if you want to implement an interface without changing the API exposed
directly from the type, you can implement the funtion with a private sealed
virtual function.

The last thing to bring up is why overriding a virtual function to which you
do not have access is a security issue in ref classes but not native
classes. For ref classes, types can be derived accross assembly boundaries.
Inheriting native classes have never been supported across DLL boundaries
with any fidelity. Many times a ref class would make its virtual functions
"internal" because they were only needed inside the assembly. In version 1.0
of the CLR, any type could override a virtual function. That was intentional
because the CLR wanted to support the C++ semantics. The security issue was
found after 1.0 shipped, and the strict semantics were introduced in version
1.1. C# used the strict semantics in 1.1, and we chose to follow suit with
the new C++ syntax in Visual C++ 2005.

Hope that helps!

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/

[Brandon Bray [MSFT]]

We wanted C++ to be as secure as other languages. :-) It was determined that
giving up the ability to override inaccessible virtual functions was a good
tradeoff with the coding practices that would have to be employed to avoid
the security problems (see my other post).

[Brandon Bray [MSFT]]

Tamas Demjen wrote:
> The reason I don't like this override keyword is that because if you
> miss it, the function won't work like a virtual function anymore, and
> there's not even a compiler warning. No override keyword == non-virtual
> function, even if the virtual keyword is there. It's very frustrating
> when you have a virtual function and it's not polymorphic.

I'm not sure why you're not seeing a warning because there are plenty of
them for this scenario. In any case, the compiler team decided to change the
warnings into errors after Beta 2. When Visual C++ 2005 ships, you'll be
required to put the "new" or "override" keyword there. The code will not
compile otherwise.

[Nemanja Trifunovic]

> Hope that helps!

Absolutelly. Thanks a lot for your detailed explanation. I wasn't aware
of the security issue you mention.

[Nemanja Trifunovic]

Thanks Ronald, it makes sense.

Was "strict" added in CLR 2.0? I don't remember it from v1.1.

[Nishant Sivakumar]

Interesting thread - thanks Nemanja :-)

--
Regards,
Nish [VC++ MVP]
http://www.voidnish.com
http://blog.voidnish.com

"Nemanja Trifunovic" <ntrif...@hotmail.com> wrote in message
news:1119575920.9...@g43g2000cwa.googlegroups.com...

[Tamas Demjen]

Brandon Bray [MSFT] wrote:

> I'm not sure why you're not seeing a warning because there are plenty of
> them for this scenario. In any case, the compiler team decided to change the
> warnings into errors after Beta 2. When Visual C++ 2005 ships, you'll be
> required to put the "new" or "override" keyword there. The code will not
> compile otherwise.
>

There is indeed a warning that I overlooked. Excellent, thanks, Brandon.
Sorry for the confusion.

Tom