«

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.

* 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?

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.

* 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?

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.

* 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?

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

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

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.

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