i want to end a virtual function chain at a particular class in a hierarchy. is there a way in std c++ to do this?
i want to end a virtual function chain at a particular class in a hierarchy. is there a way in std c++ to do this?
I can't think of any way of doing this in C++.
bit∙hub [bit-huhb] n. A source and destination for information.
Try explicitly recasting this in the call to the method you want.
I think the question is more about how to prevent subclasses from overriding a virtual method. This is not directly possible in C++.
If you insist on doing it, you can wrap the class you want to "seal" in another class which just passes all method calls through directly -- the virtual method you want to "seal" will not be virtual in this wrapper so it can't be overridden. Unfortunately this breaks the inheritance hierarchy, but you're breaking it anyway by trying to seal off a virtual function
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Which begs the question of what is the point of preventing a subclass from overriding a method? If you don't want to override it, just don't implement it in the subclass, or make it protected. There is no such thing as security in the source code, you cant prevent another user from overriding the function any more than you can prevent them from accessing protected or private objects by simply changing the header to make everything public. These features are there to prevent accidentally accessing them incorrectly, not to prevent manipulating the code.
I don't know about sealed, but java's final keyword can be used to make a method non virtual. This in turn allows inlining. I suspect sealed is the same.
If you want a virtual method to be inlinable, I suppose you can make the virtual function that overrides it's base call call a non-virtual inline method, and prefer the use of the non-virtual method when accessing the object through the derived class.
EDIT:A curious thing is that a quick test shows virtual and inline not to be mutually exclusive. It must be hard for a compiler to prove the method can be implemented inline in such a case.
Last edited by King Mir; 12-16-2009 at 06:29 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I think the compiler will take the low hanging fruit. For instance, it would probably inline in this case:
And possibly this case:Code:MyClass foo; foo.InlineFunction();
But not in the general case, obviously.Code:MyClass *foo = new MyClass(); // Nothing in between that could change the type of *foo foo->InlineFunction();
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
inline is an optional keyword, there is no guarantee that the function will be inlined even if you use it, the compiler is free to ignore it. Also, a virtual function can be inlined even without the inline keyword, AFAIK the only way to explicitly stop the compiler inlining is to use #pragma NOINLINE and then only if the compiler supports it.
The primary function of inline, in the view of the compiler, is a question of linkage: if the linker sees multiple implementations of an inline function, it has to merge them, while for normal functions it will complain. So yes, a function may be virtual and inline.
C++0x's attribute system will support the 'final' attribute.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
You can prevent a typical compiler from inlining a method by calling it in a different transaction unit than it is defined. Compilers compile one source at a time and don't look at what's in other transaction units untill linking. Since it is common practice for methods of a class to declare in their own source file, this effectively prevents non inline public and protected methods from being inlined if they are not declared as inline functions.
Hypothetically, yes a compiler could be made to inline at the linking stage, but especially because of the existence of the inline keyword and the features it provides, this is not done.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
VC++, Intel C++, LLVM-based compilers, most recently even GCC all do that. It's called LTO (link time optimization) or LTCG (link time code generation).Hypothetically, yes a compiler could be made to inline at the linking stage, but especially because of the existence of the inline keyword and the features it provides, this is not done.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
That must be C#, specific, I've never heard of transaction units in C++.
This is implementation specific, there are parallel compilers that compile multiple source files simultaneously and there are several commercial compilers that inline at link time. Visual Studio for one.Compilers compile one source at a time and don't look at what's in other transaction units untill linking. Since it is common practice for methods of a class to declare in their own source file, this effectively prevents non inline public and protected methods from being inlined if they are not declared as inline functions.
Which implies that this is no longer the case.Originally Posted by MSDN
Which confirms that this is the case.Originally Posted by MSDN
King Mir probably meant translation unit.Originally Posted by abachler
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
I'm proven wrong then.
Yeah, I meant translation unit.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.