c++ equivalent for C#'s "sealed override"?

This is a discussion on c++ equivalent for C#'s "sealed override"? within the C++ Programming forums, part of the General Programming Boards category; i want to end a virtual function chain at a particular class in a hierarchy. is there a way in ...

  1. #1
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839

    c++ equivalent for C#'s "sealed override"?

    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?

  2. #2
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,264
    I can't think of any way of doing this in C++.
    bit∙hub [bit-huhb] n. A source and destination for information.

  3. #3
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Try explicitly recasting this in the call to the method you want.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by abachler View Post
    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);
    //}

  5. #5
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by brewbuck View Post
    I think the question is more about how to prevent subclasses from overriding a virtual method. This is not directly possible in C++.
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by abachler View Post
    Which begs the question of what is the point of preventing a subclass from overriding a method?
    I don't know, but you might ask the people who created Java's "final" keyword and C#'s "sealed" keyword.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    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.

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by King Mir View Post
    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.
    I think the compiler will take the low hanging fruit. For instance, it would probably inline in this case:

    Code:
    MyClass foo;
    foo.InlineFunction();
    And possibly this case:

    Code:
    MyClass *foo = new MyClass();
    // Nothing in between that could change the type of *foo
    foo->InlineFunction();
    But not in the general case, obviously.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  11. #11
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    Quote Originally Posted by abachler View Post
    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.
    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.

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    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).
    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

  13. #13
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by King Mir View Post
    You can prevent a typical compiler from inlining a method by calling it in a different transaction unit than it is defined.
    That must be C#, specific, I've never heard of transaction units in C++.

    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.
    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.

    Quote Originally Posted by MSDN
    Under The Hood: Link-time Code Generation
    In the past, you could frequently get a function to be inlined by declaring it in a header file, and including that header file appropriately. This happened often with small C++ class methods such as accessor methods like get and set. However, if the back end hasn't seen the source code for a function during the current compilation run, there's no way it can inline it. Thus, functions in another source file, no matter how small, would never be inlined.
    Which implies that this is no longer the case.
    Quote Originally Posted by MSDN
    When the linker is invoked with IL-based OBJ files, it calls COM methods in the back end (C2.DLL) to generate the final, processor-specific code. When the linker invokes the back end, it gives the back end all of the IL from all the OBJs (as well as any pregenerated code like you might find in a .LIB file.) Because the code generator now has almost perfect knowledge of the code, it can be much more aggressive when it optimizes. The primary changes you'll notice from LTCG-generated code is that many more functions are inlined, and that many functions are called without using one of the standard calling conventions. I'll drill into some of these later.
    Which confirms that this is the case.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,275
    Quote Originally Posted by abachler
    That must be C#, specific, I've never heard of transaction units in C++.
    King Mir probably meant translation unit.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #15
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    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.

Page 1 of 4 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Equivalent of Dos 'copy' in C ?
    By YetBo in forum C Programming
    Replies: 17
    Last Post: 11-04-2009, 10:10 PM
  2. Pointer equivalent to array notation
    By bekkilyn in forum C Programming
    Replies: 4
    Last Post: 12-06-2006, 08:22 PM
  3. Replies: 10
    Last Post: 08-18-2005, 12:17 AM
  4. Header File Question(s)
    By AQWst in forum C++ Programming
    Replies: 10
    Last Post: 12-23-2004, 11:31 PM
  5. Replies: 0
    Last Post: 11-01-2002, 11:56 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21