C++ Logo


Advanced search

Re: [std-proposals] dynamic_cast<void*>(void*)

From: Andrey Semashev <andrey.semashev_at_[hidden]>
Date: Mon, 26 Feb 2024 15:25:23 +0300
On 2/26/24 14:53, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Mon, Feb 26, 2024 at 11:43 AM Andrey Semashev wrote:
>> dynamic_cast from void* to void* is currently well-defined.
> I don't see that in the C++ Standard. The following 4 compilers complain:

Yes, I was mistaken there, [expr.dynamic.cast]/2 requires the pointed
type to be complete, and void is not.

However, your suggestion still contradicts [expr.dynamic.cast]/3
(assuming we modified [expr.dynamic.cast]/2 to explicitly allow void* as
the dynamic_cast argument), which says that the trivial conversion
should be a no-op.

And you still haven't presented a rationale for this.

> Microsoft
> the operand of a pointer dynamic_cast must be a pointer to a
> complete class type
> GNU g++
> cannot 'dynamic_cast' 'v' (of type 'void* const') to type 'void*'
> (source is not a pointer to class)
> LLVM clang++
> 'void' is not a class type
> Intel ICX
> 'void' is not a class type
> Just now I tried the same code on Microsoft Visual Studio 2022, and it
> crashes. I'm not sure if it's also possible with the Microsoft ABI --
> I'll read up on the Microsoft layout of vtables and try code it.

Analyzing implementations is pointless beyond assessing implementability
of an otherwise well defined proposal, which should include the "what"
and "why" first and foremost. At this point, the "what" is only vaguely
defined, and the "why" is missing completely.

If your goal is to do something specific to your code and compiler then
this is not the reason to modify the standard. You should present a
widely enough encountered problem and then present a proposed solution
and reason about why this solution is better than the alternatives.

Received on 2024-02-26 12:25:26