I uploaded my latest proposal and I know instruction cache matters, that is
precisely why switch case statements fail; We need something that gives the
compiler more context that what we want is subscription a homogenous list,
or else we would either suffer from massive latency of std::visit or the
code bloat of switch case statements. I hate both of them, and what I want
is to give the compiler context to determine what should be done.
I would really really appreciate for a counter proposal on what could be
better than the things that I described in my updated proposal.
Thank you for your feedback!
regards, Muneem

On Fri, Apr 3, 2026 at 5:27 AM Adrian Johnston via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Regarding: Extension to runtime polymorphism
>
> The problem with this kind of thing is that there is also an
> "instruction cache" as well as a "data cache." Every time you run
> more code you increase the risk of running off of, or thrashing your
> instruction cache and taking instruction cache misses instead.
>
> I understand the cache problems with virtual functions, but there are
> problems with too much code bloat as well. Your examples describe
> creating more cache pressure than just using a virtual function call.
>
> (And I wouldn't advise waiting around for the authors of the C++
> compilers to add JIT. It sounds like the latest standards have put a
> lot of work in front of them.)
>
>
>
> On Tue, Mar 31, 2026 at 7:44 AM Jason McKesson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Mon, Mar 30, 2026 at 4:48 PM Muneem via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >
> > > Recently, I faced some issues in writing code that relied heavily on
> repetitive branching, which forced me to use AI. This proposal proposes
> techniques to counter this, in cases where the overhead of single dispatch
> is highly undesirable.
> >
> > Have you considered that what you're trying to do is perhaps not an
> > effective way to implement whatever that is? And that there's probably
> > a better way that doesn't require using a `switch` in the middle of
> > various functions?
> >
> > For example, let's take your initial code:
> >
> > ```
> > void push_multiple_to_container(const std::string string_to_read_from,
> > std::string::size_type* pos) {
> > switch(static_cast<where_to_push_enum>(
> >
> absolute_base::read_from_string<get_integer_for_size<sizeof(where_to_push_enum)>>))
> > {
> > case push_to_vector:
> > implementation_template_function_f(vector,
> read_content_to_push);
> > break;
> > case push_to_deque:
> > implementation_template_function_f(deque,
> read_content_to_push);
> > break;
> > // ... and so on
> > }
> > }
> > ```
> >
> > I don't see where `where_to_push_enum` comes from. Since you're doing
> > a `static_cast` to it, this is a type. I don't see a template header,
> > so I'm guessing that this is a member of a template class where
> > `where_to_push_enum` is provided as a template argument.
> >
> > So it stands to reason that you could reduce this function to
> > something like this:
> >
> > ```
> > implementation_template_function_f(_get_container(),
> read_content_to_push);
> > ```
> >
> > Where `_get_container` has your switch/case statement and returns this
> > container. And the containers it can return are appropriate for
> > calling `implementation_template_function_f`.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>