void* address of most derived type

[Norman J. Goldstein]

Aside from writing virtual methods to do the job, I am wondering whether
there is something like type_index/type_info to divulge the (void*)
address of the most derived type. On a related question, when
restricting to single inheritance, are compilers obliged to have the
same (void*) address for each class in the hierarchy?

[Paavo Helde]

"Norman J. Goldstein" <nor...@telus.net> wrote in news:mg7jt9$b2e$1
@speranza.aioe.org:

> Aside from writing virtual methods to do the job, I am wondering whether
> there is something like type_index/type_info to divulge the (void*)
> address of the most derived type.

As far as I understand you have a pointer to a base class and want to get a
pointer to the most derived class, without knowing the most derived class
type? That would be

dynamic_cast<void*>(...)

(assuming you have polymorphic types so dynamic_cast can be used). This
works for multiple inheritance as well.

> On a related question, when
> restricting to single inheritance, are compilers obliged to have the
> same (void*) address for each class in the hierarchy?

I believe this is not guaranteed, but will probably work in practice with
most compilers, at least when all classes are of the same type (polymorphic
or not polymorphic).

hth
Paavo

[Öö Tiib]

On Friday, 10 April 2015 07:35:00 UTC+3, Norman J. Goldstein wrote:
> Aside from writing virtual methods to do the job, I am wondering whether
> there is something like type_index/type_info to divulge the (void*)
> address of the most derived type.

You must have pointer to non-virtual base class to find out most
derived type with 'typeid(*ptr)'; 'void' is not base class. If you
know exactly from pointer to what type you did cast implicitly or
with 'static_cast' to 'void*' then you can 'static_cast' it back.
If you 'dynamic_cast<void*>' then you get address of most
non-virtually derived object, that is actually not what you want
unless you exactly know the type.

> On a related question, when
> restricting to single inheritance, are compilers obliged to have the
> same (void*) address for each class in the hierarchy?

On case of single *and* non-virtual inheritance such classes in practice
usually have same address but it is not guaranteed. The practice is
because of required order of initialization and required implicit casts
and finding vtable location (existence of what is not guaranteed at all)
are likely cheaper to implement. On case of virtual inheritance the
address is not same usually. Virtual inheritance is most expensive and
tricky. Introducing it into language was likely mistake, but I don't
care since I never use it. On case of multiple inheritance the different
base subobjects can not be at same address by simple logic.

Generally it is better to avoid casting. If you really need to then
consider making some special functions or member functions that do
it. It is easier to instrument such function with debug checks and
breakpoints.

[Norman J. Goldstein]

I wrote a test routine, and it does exactly as you say.
Many thanks.

[Norman J. Goldstein]

On 04/10/2015 12:48 AM, Öö Tiib wrote:
> On Friday, 10 April 2015 07:35:00 UTC+3, Norman J. Goldstein wrote:
>> Aside from writing virtual methods to do the job, I am wondering whether
>> there is something like type_index/type_info to divulge the (void*)
>> address of the most derived type.
>
> You must have pointer to non-virtual base class to find out most
> derived type with 'typeid(*ptr)'; 'void' is not base class. If you
> know exactly from pointer to what type you did cast implicitly or
> with 'static_cast' to 'void*' then you can 'static_cast' it back.
> If you 'dynamic_cast<void*>' then you get address of most
> non-virtually derived object, that is actually not what you want
> unless you exactly know the type.
>

On gcc 4.8, the dynamic_cast<void*> is doing the right thing, whether
the most derived object is virtually derived, or not (according to my
test routine). Why do you think virtual derivation could make a difference?

[Öö Tiib]

Sorry, I read it over and I did remember/know it incorrectly.

'dynamic_cast'ing from virtual base pointer to most derived type pointer
and 'dynamic_cast'ing from virtual base pointer to 'void*' must give same
address. That is address of most derived object.

Avoiding a feature because of its inefficiency and avoiding other feature
because of its fragility apparently may result with misremembering how
those overlap.

[Norman J. Goldstein]

Thanks for checking!

[Paavo Helde]

嘱 Tiib <oot...@hot.ee> wrote in
news:72a22d2d-0229-4625...@googlegroups.com:

> 'dynamic_cast'ing from virtual base pointer to most derived type
> pointer and 'dynamic_cast'ing from virtual base pointer to 'void*'
> must give same address. That is address of most derived object.
>
> Avoiding a feature because of its inefficiency and avoiding other
> feature because of its fragility apparently may result with
> misremembering how those overlap.

Inefficiency is always relative. There are lots of usage cases where the
speed is not so critical. For example I have used dynamic_cast quite
successfully in some MFC-based projects (working around MFC design
deficiences via multiple derivation and dynamic_casting between my and MFC
class hierarchy trees). Worked pretty well actually, at least when compared
to the rest of the MFC mess.

Cheers
Paavo

[Norman J. Goldstein]

On 04/10/2015 12:06 PM, Paavo Helde wrote:
> Öö Tiib <oot...@hot.ee> wrote in
> news:72a22d2d-0229-4625...@googlegroups.com:
>

>> Avoiding a feature because of its inefficiency and avoiding other
>> feature because of its fragility apparently may result with
>> misremembering how those overlap.
>
> Inefficiency is always relative. There are lots of usage cases where the
> speed is not so critical. For example I have used dynamic_cast quite
> successfully in some MFC-based projects (working around MFC design
> deficiences via multiple derivation and dynamic_casting between my and MFC
> class hierarchy trees). Worked pretty well actually, at least when compared
> to the rest of the MFC mess.
>

I will be using the void* cast to ensure that a shared_ptr
is written to disk only once. So, the disk IO will dominate the dynamic
casts.

The conversations in this thread were quite helpful.

Regards,
Norm

[Mr Flibble]

It is very rare to avoid dynamic_cast for performance reasons, it is
more common to avoid dynamic_cast because using it is a code/design
smell: consider refactoring your design so you can use virtual functions
instead sausages.

/Flibble

[Norman J. Goldstein]

On 04/10/2015 01:16 PM, Mr Flibble wrote:
> On 10/04/2015 20:28, Norman J. Goldstein wrote:
>>
>> I will be using the void* cast to ensure that a shared_ptr
>> is written to disk only once. So, the disk IO will dominate the dynamic
>> casts.
>>

> It is very rare to avoid dynamic_cast for performance reasons, it is
> more common to avoid dynamic_cast because using it is a code/design
> smell: consider refactoring your design so you can use virtual functions
> instead sausages.
>

The problem with virtual functions is that you need to implement them,
and that precludes using classes that you either cannot, or do not want,
to modify. I suppose the two approaches can be combined: If the
virtual method exists, then use it; otherwise, do the dynamic cast.

[Mr Flibble]

If you have classes that you cannot modify or do not want to modify yet
require modification in order to correct a shite design then you need to
have a word with yourself.

I have very few dynamic_cast in my codebase and none at all in my
non-library code sausages.

/Flibble

[Ian Collins]

That doesn't make any sense.

The only virtual functions you need to implement in a derived class are
pure virtual functions.

To use a dynamic cast the types have to be polymorphic so they will
already have at least one virtual function.

--
Ian Collins

[Paavo Helde]

Ian Collins <ian-...@hotmail.com> wrote in
news:cor3u1...@mid.individual.net:

> Norman J. Goldstein wrote:
>>
>> The problem with virtual functions is that you need to implement
>> them, and that precludes using classes that you either cannot, or do
>> not want, to modify.
>

> That doesn't make any sense.
>
> The only virtual functions you need to implement in a derived class
> are pure virtual functions.

I guess Norman meant "implementing" in a broader sense, i.e. adding needed
virtual function interfaces to a class hierarchy. Using some other word
would have been more suitable to avoid confusion.