dependent inheritance?

Discussion in 'C++' started by cerr, Jun 11, 2009.

  1. cerr

    cerr Guest

    Hi There,

    Am I able to define what class the current class is inherited from at
    runtime in the constructor?
    Let me try to make an example:
    We got two mother classes Car and Bus with completely different
    methods.
    Now i would like to instance a new class, let's call it NewVehicle.
    Now can I decide in NewVehicle's constructor what class it's inherited
    from (Car or Bus) if i was gonna go like:
    NewVehicle *MyInstance = NewVehicle(Car);
    ?
    Thanks,
    Ron
     
    cerr, Jun 11, 2009
    #1
    1. Advertising

  2. * cerr:
    > Hi There,
    >
    > Am I able to define what class the current class is inherited from at
    > runtime in the constructor?


    No, and it's not a good idea.


    > Let me try to make an example:
    > We got two mother classes Car and Bus with completely different
    > methods.
    > Now i would like to instance a new class, let's call it NewVehicle.
    > Now can I decide in NewVehicle's constructor what class it's inherited
    > from (Car or Bus) if i was gonna go like:
    > NewVehicle *MyInstance = NewVehicle(Car);
    > ?


    No, but you can do the following:

    * Define an abstract class Vehicle with virtual methods, and not to
    forget, a virtual destructor.

    * Define a class CarVehicle that inherits from and implements Vehicle,
    either containing a Car member or inheriting privately from Car.

    * And a ditto BusVehicle class.

    Then you can do

    Vehicle* pVehicle = new CarVehicle;


    Cheers & hth.,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
     
    Alf P. Steinbach, Jun 11, 2009
    #2
    1. Advertising

  3. Alf P. Steinbach wrote:
    > * cerr:
    >> Am I able to define what class the current class is inherited from at
    >> runtime in the constructor?

    >
    > No, and it's not a good idea.


    Out of curiosity: Why not?

    I think some programming languages allow creating classes dynamically
    at runtime. Why is that a bad thing?
     
    Juha Nieminen, Jun 11, 2009
    #3
  4. * Juha Nieminen:
    > Alf P. Steinbach wrote:
    >> * cerr:
    >>> Am I able to define what class the current class is inherited from at
    >>> runtime in the constructor?

    >> No, and it's not a good idea.

    >
    > Out of curiosity: Why not?


    Because C++ is statically typed. :)


    > I think some programming languages allow creating classes dynamically
    > at runtime. Why is that a bad thing?


    This is a different question.

    It's not a bad thing per se, for depending on the programming language it can be
    a reasonable and practical thing to do.

    On the other hand, a horror story from my time as consultant. I wasn't on that
    project but I'd had some of them as "students" and one of them came and asked me
    what to do when it all went awry. They had three serious technical issues: one
    was the choice of Visual Basic for the GUI, the second to implement each class
    as a separate DLL (and with umpteen hundreds classes I guess you can imagine how
    that turned out), and the third, the use of a dis-ingenious hack to emulate
    inheritance or whatever it was by changing vtable pointers on the fly. This
    latter meant that they'd forsaken what little static type checking the language
    provided, and were effectively lying about static types. It didn't work. But of
    course, as almost always, the core issues were not technical but managerial.
    Their manager believed in taking shortcuts and was more concerned with
    allegiance than quality, so when it all started to turn sour he (it's inevitably
    a he that does this) kept the poor consultants working overtime, not allowed
    even to participate in obligatory meetings at the firm, so the atmosphere was
    pretty charged and panick-stricken and people were simply ineffectual, not
    working as a team, so my advice mostly concerned that: the technical white
    elephants or what you might call them are often just symptoms.


    Cheers & hth.,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
     
    Alf P. Steinbach, Jun 11, 2009
    #4
  5. cerr

    cerr Guest

    On Jun 11, 2:15 pm, cerr <> wrote:
    > Hi There,
    >
    > Am I able to define what class the current class is inherited from at
    > runtime in the constructor?
    > Let me try to make an example:
    > We got two mother classes Car and Bus with completely different
    > methods.
    > Now i would like to instance a new class, let's call it NewVehicle.
    > Now can I decide in NewVehicle's constructor what class it's inherited
    > from (Car or Bus) if i was gonna go like:
    > NewVehicle *MyInstance = NewVehicle(Car);
    > ?


    Right, So I came up with following solution for my problem

    class A
    class myB : A
    class myC :A, Thread
    class Reader : Thread
    {
    if (condition)
    myB *InstB = new myB();
    else
    myC *InstC = new myC();
    }

    Hence I'd have A running in Reader's thread and C would be running in
    its own thread right?
    I'm just looking for a possibility to not let C running in the same
    thread as A as A and Reader is existing already (A running in Reader's
    thread)

    Thanks,
    Ron
     
    cerr, Jun 11, 2009
    #5
  6. * cerr:
    > On Jun 11, 2:15 pm, cerr <> wrote:
    >> Hi There,
    >>
    >> Am I able to define what class the current class is inherited from at
    >> runtime in the constructor?
    >> Let me try to make an example:
    >> We got two mother classes Car and Bus with completely different
    >> methods.
    >> Now i would like to instance a new class, let's call it NewVehicle.
    >> Now can I decide in NewVehicle's constructor what class it's inherited
    >> from (Car or Bus) if i was gonna go like:
    >> NewVehicle *MyInstance = NewVehicle(Car);
    >> ?

    >
    > Right, So I came up with following solution for my problem
    >
    > class A
    > class myB : A
    > class myC :A, Thread
    > class Reader : Thread
    > {
    > if (condition)
    > myB *InstB = new myB();
    > else
    > myC *InstC = new myC();
    > }
    >
    > Hence I'd have A running in Reader's thread and C would be running in
    > its own thread right?
    > I'm just looking for a possibility to not let C running in the same
    > thread as A as A and Reader is existing already (A running in Reader's
    > thread)


    Hm. The above code doesn't make sense as C++, nor do the questions make direct
    sense. It's possible that you just have some terminology wrong, but I think it's
    likely that you also have some concept bleed (vaguely understood concepts that
    seem to be much the same), and perhaps even language bleed (mixing concepts and
    ideas from two or more programming languages, like e.g. Java and C++).

    So:

    A *thread* is a current point of execution that moves through the code,
    associated with a routine call stack. Standard C++ per the 1998 standard
    (including the 2003 corrections) does not support more than one thread per
    program, which means it must be done by way of currently non-standard library
    functionality. Anyway multi-threading is an "advanced" topic, far beyond the
    basics of understanding classes and inheritance.

    A *class* is a type that you can create instances of. Each instance will
    generally have one or more data *members*. If you have defined one or more
    *constructors* for the class then one of them will be executed when you create
    an instance, allowing you to establish initial values for the data members in
    that instance, the *member variables*. And vice versa, calling a constructor
    creates an instance, unless you use very low level language features to
    circumvent this very tight coupling beween instance creation and constructor
    invocations, which is much of the point of constructors.

    A class definition does not directly contain executable code. A class may define
    methods that contain executable code. You can call a method "on" an instance
    (a pointer to the instance is then passed as a hidden argument to the method).
    The term *method* is however just a language-independent vague notion. In
    standard C++ terminology it is convenient to define "method" as a "non-static
    member function that is not a constructor", but some people may prefer to define
    it just as a "a member function that is not a constructor", because C++ static
    member routines correspond to what in some languages are "static methods".

    The above is just to point you in the right direction: you really need a textbook.

    Or at least a tutorial. :)


    Cheers & hth.,

    - Alf

    --
    Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
    No ads, and there is some C++ stuff! :) Just going there is good. Linking
    to it is even better! Thanks in advance!
     
    Alf P. Steinbach, Jun 12, 2009
    #6
  7. cerr

    cerr Guest

    On Jun 11, 4:13 pm, "Alf P. Steinbach" <> wrote:
    > * cerr:
    >
    >
    >
    > > On Jun 11, 2:15 pm, cerr <> wrote:
    > >> Hi There,

    >
    > >> Am I able to define what class the current class is inherited from at
    > >> runtime in the constructor?
    > >> Let me try to make an example:
    > >> We got two mother classes Car and Bus with completely different
    > >> methods.
    > >> Now i would like to instance a new class, let's call it NewVehicle.
    > >> Now can I decide in NewVehicle's constructor what class it's inherited
    > >> from (Car or Bus) if i was gonna go like:
    > >> NewVehicle *MyInstance = NewVehicle(Car);
    > >> ?

    >
    > > Right, So I came up with following solution for my problem

    >
    > > class A
    > > class myB : A
    > > class myC :A, Thread
    > > class Reader : Thread
    > > {
    > > if (condition)
    > >   myB *InstB = new myB();
    > > else
    > >   myC *InstC = new myC();
    > > }

    >
    > > Hence I'd have A running in Reader's thread and C would be running in
    > > its own thread right?
    > > I'm just looking for a possibility to not let C running in the same
    > > thread as A as A and Reader is existing already (A running in Reader's
    > > thread)

    >
    > Hm. The above code doesn't make sense as C++, nor do the questions make direct
    > sense. It's possible that you just have some terminology wrong, but I think it's
    > likely that you also have some concept bleed (vaguely understood concepts that
    > seem to be much the same), and perhaps even language bleed (mixing concepts and
    > ideas from two or more programming languages, like e.g. Java and C++).


    This is just pseudo code to demostrate what I plan to do.

    > So:
    >
    > A *thread* is a current point of execution that moves through the code,
    > associated with a routine call stack. Standard C++ per the 1998 standard
    > (including the 2003 corrections) does not support more than one thread per
    > program, which means it must be done by way of currently non-standard library
    > functionality. Anyway multi-threading is an "advanced" topic, far beyond the
    > basics of understanding classes and inheritance.


    I very well know what a thread is. I'm using the pthread library:
    https://computing.llnl.gov/tutorials/pthreads/

    > A *class* is a type that you can create instances of. Each instance will
    > generally have one or more data *members*. If you have defined one or more
    > *constructors* for the class then one of them will be executed when you create
    > an instance, allowing you to establish initial values for the data members in
    > that instance, the *member variables*. And vice versa, calling a constructor
    > creates an instance, unless you use very low level language features to
    > circumvent this very tight coupling beween instance creation and constructor
    > invocations, which is much of the point of constructors.
    >
    > A class definition does not directly contain executable code. A class may define
    >   methods that contain executable code. You can call a method "on" an instance
    > (a pointer to the instance is then passed as a hidden argument to the method).
    > The term *method* is however just a language-independent vague notion. In
    > standard C++ terminology it is convenient to define "method" as a "non-static
    > member function that is not a constructor", but some people may prefer to define
    > it just as a "a member function that is not a constructor", because C++ static
    > member routines correspond to what in some languages are "static methods"..
    >
    > The above is just to point you in the right direction: you really need a textbook.
    >
    > Or at least a tutorial. :)


    See above....
     
    cerr, Jun 12, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. maxw_cc
    Replies:
    1
    Views:
    3,197
    Martijn van Steenbergen
    Dec 21, 2003
  2. cppsks
    Replies:
    0
    Views:
    853
    cppsks
    Oct 27, 2004
  3. karthikbalaguru
    Replies:
    9
    Views:
    1,068
  4. Daniel Pitts
    Replies:
    27
    Views:
    1,956
    Mike Schilling
    Feb 27, 2008
  5. puzzlecracker
    Replies:
    1
    Views:
    546
    James Kanze
    Aug 7, 2008
Loading...

Share This Page