Am I inherited?

[Mike - EMAIL IGNORED]

Within class MyClass, I can think of two ways
to tell if MyClass is inherited in a particular
use:

1. pass an appropriate bool in the ctor args;

2. use a virtual method that returns, for
example, a siring containing the class name.

Is there a better way?

Thanks,
Mike.

[Alf P. Steinbach]

* Mike - EMAIL IGNORED:

Within class MyClass, I can think of two ways
to tell if MyClass is inherited in a particular
use:

1. pass an appropriate bool in the ctor args;

2. use a virtual method that returns, for
example, a siring containing the class name.

Is there a better way?

Design the class so it doesn't need that knowledge.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Mike - EMAIL IGNORED]

On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:

* Mike - EMAIL IGNORED:

>Within class MyClass, I can think of two ways
to tell if MyClass is inherited in a particular
use:

1. pass an appropriate bool in the ctor args;

2. use a virtual method that returns, for
example, a siring containing the class name.

Is there a better way?

Design the class so it doesn't need that knowledge.

That is often a good idea; but in this case, it is not.

[Alf P. Steinbach]

* Mike - EMAIL IGNORED:

On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:

>* Mike - EMAIL IGNORED:

>>Within class MyClass, I can think of two ways
to tell if MyClass is inherited in a particular
use:

1. pass an appropriate bool in the ctor args;

2. use a virtual method that returns, for
example, a siring containing the class name.

Is there a better way?

Design the class so it doesn't need that knowledge.

That is often a good idea; but in this case, it is not.

That would be interesting, if true. However, I'm disinclined to believe
that claim without some concrete evidence. Please post a small example
that compiles, or where the compilation error illustrates the problem.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Mike - EMAIL IGNORED]

On Sat, 22 Jul 2006 02:28:41 +0200, Alf P. Steinbach wrote:

* Mike - EMAIL IGNORED:

>On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:

>>* Mike - EMAIL IGNORED:
Within class MyClass, I can think of two ways
to tell if MyClass is inherited in a particular
use:

1. pass an appropriate bool in the ctor args;

2. use a virtual method that returns, for
example, a siring containing the class name.

Is there a better way?
Design the class so it doesn't need that knowledge.

That is often a good idea; but in this case, it is not.

That would be interesting, if true. However, I'm disinclined to believe
that claim without some concrete evidence. Please post a small example
that compiles, or where the compilation error illustrates the problem.

Off point: the question is how, not whether to do it. There is no error.

[Alf P. Steinbach]

* Mike - EMAIL IGNORED:

On Sat, 22 Jul 2006 02:28:41 +0200, Alf P. Steinbach wrote:

>* Mike - EMAIL IGNORED:

>>On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:

* Mike - EMAIL IGNORED:
Within class MyClass, I can think of two ways
to tell if MyClass is inherited in a particular
use:
>
1. pass an appropriate bool in the ctor args;
>
2. use a virtual method that returns, for
example, a siring containing the class name.
>
Is there a better way?
Design the class so it doesn't need that knowledge.
That is often a good idea; but in this case, it is not.

That would be interesting, if true. However, I'm disinclined to believe
that claim without some concrete evidence. Please post a small example
that compiles, or where the compilation error illustrates the problem.

Off point: the question is how, not whether to do it. There is no error.

I think that protest means you know your design is triple UnGood, and
just want a quick and dirty kludge.

Which will hopefully give an endless nightmare of problems so that you
learn to do things properly. :-)

For now, if a virtual class name member function is one solution, as you
have indicated, then a version of the same idea using built-in support
is the typeid operator.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Kai-Uwe Bux]

Mike - EMAIL IGNORED wrote:

On Sat, 22 Jul 2006 02:28:41 +0200, Alf P. Steinbach wrote:

>* Mike - EMAIL IGNORED:

>>On Sat, 22 Jul 2006 00:42:59 +0200, Alf P. Steinbach wrote:

* Mike - EMAIL IGNORED:
Within class MyClass, I can think of two ways
to tell if MyClass is inherited in a particular
use:
>
1. pass an appropriate bool in the ctor args;
>
2. use a virtual method that returns, for
example, a siring containing the class name.
>
Is there a better way?
Design the class so it doesn't need that knowledge.

That is often a good idea; but in this case, it is not.

That would be interesting, if true. However, I'm disinclined to believe
that claim without some concrete evidence. Please post a small example
that compiles, or where the compilation error illustrates the problem.

Off point: the question is how, not whether to do it. There is no error.

Not off at all:

a) If we get to see your real problem, we might be able to suggest a better
design.

b) You should also consider the motivation we might have to provide you with
a solution, while there is this nagging feeling that you may be chasing a
red herring.
Best

Kai-Uwe Bux

[Mike - EMAIL IGNORED]

[...]

For now, if a virtual class name member function is one solution, as you
have indicated, then a version of the same idea using built-in support
is the typeid operator.

I just tried typeid. It appears that it doesn't know where I
would like to know: in the constructor.

FYI, the situation is a hierarchy of complex mathematical
operations, each one in its own class. Most of the classes
can function alone or in concert with others. The sequence
of events is controlled by ctor of the most inherited class.
The data for all classes are mostly the same type, voluminous,
and kept protected in a base class. Virtual inheritance is
used. The most inherited class must recognize itself in the
ctor. There are, of course, other designs, but this provides
simplicity for the unsophisticated user and ease of expansion
as other mathematical procedures and interactions are developed.

[Ian Collins]

Mike - EMAIL IGNORED wrote:

[...]

>>For now, if a virtual class name member function is one solution, as you
have indicated, then a version of the same idea using built-in support
is the typeid operator.

I just tried typeid. It appears that it doesn't know where I
would like to know: in the constructor.

Then you have a bit of a problem, don't you? You can't use virtual
methods in a constructor.

--
Ian Collins.

[Kai-Uwe Bux]

Mike - EMAIL IGNORED wrote:

[...]

>For now, if a virtual class name member function is one solution, as you
have indicated, then a version of the same idea using built-in support
is the typeid operator.

I just tried typeid. It appears that it doesn't know where I
would like to know: in the constructor.

What did you try?

I tried:

#include <typeinfo>

namespace {

template < typename B >
B unimplemented ( void );

}

template < typename B >
bool has_dynamic_type ( B const & b ) {
return ( typeid( unimplemented<B>() ) == typeid( b ) );
}
#include <iostream>

class Base {
protected:

Base ( void ) {
std::cout << has_dynamic_type< Base >( *this ) << '\n';
}

public:

bool is_base ( void ) const {
return ( has_dynamic_type< Base >( *this ) );
}

virtual
~Base ( void ) {}

static
Base* create ( void ) {
return new Base;
}

};

struct Derived : public Base {
protected:

Derived ( void ) {
std::cout << has_dynamic_type< Base >( *this ) << '\n';
}

public:

static
Derived* create ( void ) {
return new Derived;
}

};
int main ( void ) {
Base* b_ptr = Base::create();
Base* d_ptr = Derived::create();
std::cout << b_ptr->is_base() << '\n';
std::cout << d_ptr->is_base() << '\n';
}
a) I am not sure whether there is UB in the above.

b) A little bit of the code complexity is because I wanted something that
does not require default constructibilty.

c) On my machine, the output is:

1 // construction of *b_ptr
1 // construction of *d_ptr Base() part
0 // construction of *d_ptr Derived() part
1 // b_ptr->is_base();
0 // d_ptr->is_base();

FYI, the situation is a hierarchy of complex mathematical
operations, each one in its own class. Most of the classes
can function alone or in concert with others. The sequence
of events is controlled by ctor of the most inherited class.
The data for all classes are mostly the same type, voluminous,
and kept protected in a base class. Virtual inheritance is
used.

Could you provide a little example code that demonstrates the design?

The most inherited class must recognize itself in the ctor.

Note that when Base() is called, it truly constructs a Base object and
nothing else. The constructor has no way of telling how it is invoked.

Also, the other methods you mentioned in your first post have trouble in
this situation:

1. pass an appropriate bool in the ctor args;

In order to pass that bool, you would need to know already, won't you?

2. use a virtual method that returns, for
example, a siring containing the class name.

Virtual functions are not necessarily resolved the way you like in
constructors. I feel there might be some UB involved.
If you classes are just wrapping operations, then maybe you can move the
logic from the constructors to the destructors?
[snip]
Best

Kai-Uwe Bux

[Bo Persson]

"Mike - EMAIL IGNORED" <m_*************@yahoo.comskrev i meddelandet
news:pa****************************@yahoo.com...

[...]

>For now, if a virtual class name member function is one solution,
as you
have indicated, then a version of the same idea using built-in
support
is the typeid operator.

I just tried typeid. It appears that it doesn't know where I
would like to know: in the constructor.

If you need to know something in a constructor, that something should
generally be a parameter to that constructor. You could add a
protected constructor, that the subclasses can call. Then at least you
know where that call comes from.

But, as Alf said, in a base class you generally don't want to know
your subclasses. They should take care of themselves.

>
FYI, the situation is a hierarchy of complex mathematical
operations, each one in its own class. Most of the classes
can function alone or in concert with others. The sequence
of events is controlled by ctor of the most inherited class.
The data for all classes are mostly the same type, voluminous,
and kept protected in a base class. Virtual inheritance is
used. The most inherited class must recognize itself in the
ctor.

And we all wonder why. :-)

There are, of course, other designs,

Right!

but this provides
simplicity for the unsophisticated user and ease of expansion
as other mathematical procedures and interactions are developed.

To me it looks more like the "ease of expansion" is not at all obvious
here, if the base class needs to know all expansions. But, what do I
know?

Bo Persson

[Michiel.Salters]

Mike - EMAIL IGNORED wrote:

[...]

For now, if a virtual class name member function is one solution, as you
have indicated, then a version of the same idea using built-in support
is the typeid operator.

I just tried typeid. It appears that it doesn't know where I
would like to know: in the constructor.

Well, duh. In the base class ctor, the derived ctor hasn't yet run, so
it is
not inherited /yet/. typeid knows that, but it isn't psychic. It can't
tell if the
object will ever become derived (an exception may prevent the derived
ctor
from completing) so it can only tell you what's certain.

HTH,
Michiel Salters

[Mike - EMAIL IGNORED]

On Mon, 24 Jul 2006 08:43:28 -0700, Michiel.Salters wrote:

>
Mike - EMAIL IGNORED wrote:

>[...]

For now, if a virtual class name member function is one solution, as you
have indicated, then a version of the same idea using built-in support
is the typeid operator.

I just tried typeid. It appears that it doesn't know where I
would like to know: in the constructor.

Well, duh. In the base class ctor, the derived ctor hasn't yet run, so
it is
not inherited /yet/. typeid knows that, but it isn't psychic. It can't
tell if the
object will ever become derived (an exception may prevent the derived
ctor
from completing) so it can only tell you what's certain.

HTH,
Michiel Salters

Yes, I found that out. For the same reason, option 2 in
my original post is not possible. From all I have seen
in these responses, it appears that option 1 in my
original post is the way to go, which is what I have
done.

Thanks for your help,
Mike.