dependent inheritance?

[cerr]

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

 

[Alf P. Steinbach]

* 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

 

[Juha Nieminen]

* cerr:

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?

 

[Alf P. Steinbach]

* Juha Nieminen:

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

 

[cerr]

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

 

[Alf P. Steinbach]

* cerr:

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

 

[cerr]

* cerr:







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