Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > dependent inheritance?

Reply
Thread Tools

dependent inheritance?

 
 
cerr
Guest
Posts: n/a
 
      06-11-2009
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

 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      06-11-2009
* 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!
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      06-11-2009
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?
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      06-11-2009
* 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!
 
Reply With Quote
 
cerr
Guest
Posts: n/a
 
      06-11-2009
On Jun 11, 2:15*pm, cerr <(E-Mail Removed)> 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
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      06-11-2009
* cerr:
> On Jun 11, 2:15 pm, cerr <(E-Mail Removed)> 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!
 
Reply With Quote
 
cerr
Guest
Posts: n/a
 
      06-12-2009
On Jun 11, 4:13*pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * cerr:
>
>
>
> > On Jun 11, 2:15 pm, cerr <(E-Mail Removed)> 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....
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
non-dependent vs. dependent template names puzzlecracker C++ 1 08-07-2008 07:42 AM
defining a flag-dependent constant valentin tihomirov VHDL 3 11-28-2004 04:15 AM
client side dynamic dependent list box Amp Inthalangsy ASP .Net 3 11-27-2004 08:50 PM
Dependent DropDownList in DataGrid =?Utf-8?B?U2hpanUgUG95aWxpbA==?= ASP .Net 2 08-22-2004 06:15 AM
A selection changes on asp page with 6 dependent list boxes, when back Galina ASP .Net 8 02-03-2004 04:12 PM



Advertisments