C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Every variable is volatile, everything is laundered, no optimisation

From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Date: Sat, 26 Aug 2023 14:50:29 +0200
sob., 26 sie 2023 o 14:40 Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> napisaƂ(a):
>
>
>
> On Saturday, August 26, 2023, Marcin Jaczewski wrote:
>>
>>
>> What "repair job"??? You only break code pass point of no return.
>> Standard should NEVER allow code like this.
>> Reinterpret casting one pointer type to another and then dereferencing
>> it is pure UB.
>>
>> There is simple solution for all this:
>>
>> ```
>> class ComHandler
>> {
>> std::variant<IXYZComHander*, IABCComHandler*> _data;
>> public:
>> //common API here
>> }
>> ```
>>
>> And use `ComHandler` everywhere instead of butchering the whole C++
>> object model.
>
>
>
>
> The aforementioned dynamic_cast is inside the SDK, and it always yields a nullptr (obviously it was never tested). I needed to give them code that would work with the SDK binary that they currently have. I couldn't apply the simple solution you suggested, as I can't give out a new binary for the SDK. So alternatively I gave them a quick fix that works.
>

What fix??? how casting anything in your code could fix `dynamic_cast`
in the library? Library only gets `NewMicroscope*`, yes?
Show real "data flow" in this program instead of some unrelated code
snippets that make no sense as a whole.

What is your code that can be changed, and what is code that can't be
changed, and what code needs to work.

> C++ is a real-world language that should accommodate real-world difficult situations. Marking a function as '__verbose' would be helpful for situations where we need to improvise.
>

No it would not, besides you do not prove that code you write does not
crash some users.

>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2023-08-26 12:50:41