pon., 1 sie 2022 o 23:56 Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Mon, Aug 1, 2022 at 3:11 PM Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> > Unless you're aiming at getting negative chance of getting your proposal
> > through, I suggest you decouple compiler options from it.
>
>
> I don't actually have a use case for my "proposal". <-- they're scare quotes
>
> I can't think of a good use off-hand for being able to modify v-tables
> at runtime.
> This is all just a thought experiment -- which I believe is needed to
> keep discussion
> lubricated.

Then your proposal should be rejected on the spot.
All proposals NEED to have a use case and a big segment of users that
will use it.
Otherwise the cost of implementing it and maintaining it will not be justified.

Not to mention that it makes it impossible (or very hard) to implement
other proposals than
touch v-tables. And some of them could have use cases and a lot of
users that could benefit from it.

> We can get really comfortable with ideas like "object-orientated" and
> "polymorphism",
> and how they apply to C++, but irrespective of how comfortable we ever become, I
> think we should always be throwing out wild and wacky ideas just to get people's
> creative juices flowing.
>

Then make your own language and see how it will work, you can easily
experiment and
check some wild ideas and see what the result will be.

Every wrongly specific feature for C++ can have consequences that will
be pain for every one for decades.
See how much problems cause utf8 literals, or in python transition for
version 2 to 3.
Or even exceptions, if we go back in time and implement them as
"deterministic exceptions" could have
wider usage and not have a split in community.

And you propose that we will have another split, editable and not
editable v-table by compiler options.
Then we will have 4 versions of C++, and add RTTI that will be 8 versions.

> In the year 2070, the idea of a 'class' might be quite similar to what
> it is today. But
> then again, someone might come up with a mad idea that nobody had fathomed --
> and maybe even everyone will baulk at it at first -- but our previous ideas of
> polymorphism might begin to seem very limited when we explore the new idea.
>
> If discussion about adding compiler options to the Standard opens up
> new doors of
> creativity in people's minds, and brings forth new strange ideas, then
> let's talk about it.
> I want to evaluate weird, odd, strange ideas and see where it takes us
> -- even if it's
> talk about editing v-tables at runtime (with atomic pointers in
> writeable memory).
>
> Can anyone reading this post right now think of a very good use for
> standardised compiler
> options?
>

I can make a compiler without user options. This will be limiting but
still conforming.
If I need to use it only for very specific cases, why should I add any
new options?

> P.S. In a previous post a day or two ago, I shared some code that
> malfunctioned when
> compiled with -O2 or -O3 (however it worked fine with -O1). Today I
> was tinkering with it
> more and I got it to work properly at ever optimisation level by
> simply changing the v-table
> pointer from "void *" to "void volatile *".
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals