Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. Inheritance

Inheritance

Scheduled Pinned Locked Moved C#
helpoopquestion
21 Posts 9 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C ClockEndGooner

    Hi, Luker; The related MSDN help topic for the similar compiler error I receive for the example at http://msdn.microsoft.com/en-us/library/s9zta243.aspxm, is: "A derived class cannot access protected members of its base class through an instance of the base class. An instance of the base class declared in the derived class might, at run time, be an instance of another type that is derived from the same base but is not otherwise related to the derived class. Because protected members can be accessed only by derived types, any attempts to access protected members that might not be valid at run time are marked by the compiler as not valid." If I'm following this explanation correctly, methods or member functions declared as protected can only be accessed by an immediate descendant of the base class. In the example above, since SecondDerived does not inherit its structure and behavior from FirstDerived, FirstDerived.DoSomething() cannot be called as the language is enforcing the scope and access of the protected method DoSomething(). Even if AbstracstBase.DoSomething() wasn't declared as abstract, the restricted access of the protected qualifier takes precedence. Moreover, I don't think using the internal qualifier would help, as the compiler treats this as an error, in which the derived class, FirstDerived, was trying to change the access on a method that was inherited and declared as protected in the AbstractBase class. The internal keyword, in conjunction with a correctly defined assembly attribute, can only allow the runtime to access internal methods between friend assemblies. This approach for the friend qualifier seems specific to .NET, and unfortunately, is not the same as a friend function in C++. Is it possible to provide an additional method in FirstDerived that would correctly expose and allow a call to FirstDerived.DoSomething() on behalf of the FirstDerived's consumer, or, could having the common polymorphic behavior of DoSomething() be expressed and implemented using an Interface instead? I hope this was of help. If I missed something in your question, or incorrectly stated anything with regards to the use and application of the protected and internal keywords, please let me know. Best Regards... Bill

    C Offline
    C Offline
    ClockEndGooner
    wrote on last edited by
    #21

    My apologies for any redundancies or oversights for the previous posts on my part.... Bill

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups