C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Extension to runtime polymorphism proposed

From: Muneem <itfllow123_at_[hidden]>
Date: Sat, 4 Apr 2026 09:39:04 +0500
Hi, again, Mr.Steve!

Short answer:
The current techniques/(std::variant) is to verbose and too hard to
optimize at a intermediate representation level. It also obscures intent,
makes code hard to reason with, and optimizing it can backfire since it's
mostly at an llvm level where the constructs don't provide too much intent
and context (it's too low level), or at least not as much as the original
code itself. It's safe in everyway because the compiler has full say from
the very first phases of compilation.


Long answer:

Why is the current techniques not viable:
2. For my example, it is still very very verbose and obscures the intent
even more from not only me but the compiler.
2.I posted many benchmarks(using std:: variant and visit) to show that the
current techniques isn't efficient.
3. Thiago Marciena contested that llvms can optimize it, but my goal is a
construct that can give the compiler enough intent to optimize the code
before the code reaches to be in llvm/any intermediate code representation,
so as to take advantage of both the context and intent that this construct
provides.
4. Sorry if my previous responses were too long and verbose


Regards, Muneem



On Sat, 4 Apr 2026, 9:26 am Steve Weinrich via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I am going to ignore everything except the “This is the problem” section.
>
>
>
> We have some data. We would like to store the data in one of several
> different containers. It is not important what the criteria is for
> choosing the container. We will assume that the discrimination function to
> determine which container returns an int, specifying the container.
>
>
>
> The question at hand is given the int from the discrimination function,
> how to we “dispatch” operations to use the correct container?
>
>
>
> The standard approach:
>
>
>
> class Data {// TBD };
>
> class Key {// TBD};
>
>
>
> int discriminator (const Data &) { // do something}
>
>
>
> class Storage
>
> {
>
> public:
>
> virtual void put (const Key &, const Data &) = 0;
>
> virtual Data get (const Key &) const = 0;
>
> };
>
>
>
> class FlavorOne : public Storage
>
> {
>
> private:
>
> void put (const Key &, const Data &) override {// do something}
>
> Data get (const Key &) const override {//do something}
>
>
>
> std::vector<Data> data;
>
> };
>
>
>
> FlavorOne flavorOne;
>
>
>
> class FlavorTwo : public Storage
>
> {
>
> private:
>
> void put (const Key &, const Data &) override {// do something}
>
> Data get (const Key &) const override {//do something}
>
>
>
> std::list<Data> data;
>
> };
>
>
>
> FlavorTwo flavorTwo;
>
>
>
> class FlavorThree : public Storage
>
> {
>
> private:
>
> void put (const Data &) override {// do something}
>
> Data get () const override {//do something}
>
>
>
> std::deque<Data> data;
>
> };
>
>
>
> FlavorThree flavorThree;
>
>
>
> std::array<Storage &, 3> storage(flavorOne, flavorTwo, flavorThree);
>
>
>
> To store some data: storage[discriminator(data)].put(data);
>
>
>
>
>
> Muneem, given the above approach, what issue(s) are you having?
>
>
>
> Cheers,
> Steve
>
>
>
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf
> Of *Muneem via Std-Proposals
> *Sent:* Friday, April 3, 2026 9:33 PM
> *To:* std-proposals_at_[hidden]
> *Cc:* Muneem <itfllow123_at_[hidden]>
> *Subject:* Re: [std-proposals] Extension to runtime polymorphism proposed
>
>
>
> I am really really sorry for the gap in communication that we all had,
> like our cultures defer, unfortunately, so I can't really understand how to
> phrase things properly (sadly). Thank you to both Mr. Jason and Mr. Steven
> for their guidance and support.
>
>
>
> First let me (as Steven told me to provide a simple aspect of this
> feature) before moving on to the actual code(discussion section):
>
> *********This is the problem*********
>
> Try reading input from the user to push, pop, insert, push into the
> element type, etc, to any of this types show in less than a thousand lines:
>
> namespace type_information_storage_facilities{
>
> std::vector<Type_info_t>
> vector_containing_type_collections;
>
> std::deque<Type_info_t>
> deque_containing_type_collections;
>
> std::vector<Type_info_t>
> map_containing_type_collections;
>
> std::vector<Type_info_t>
> hash_map_containing_type_collections;
>
> std::list<Type_info_t>
> list_containing_type_collections;
>
> std::forward_list<Type_info_t>
> forward_list_containing_type_collections;
>
> }
>
>
>
> Basically trying to decide between the advantages of each container's(or
> any group of objects) space and time gurrentied at runtime.
>
>
>
> *********This is the problem*********
>
>
>
> *********The proposed syntax*********
>
> /*The defintion of all those containers and enums are here in a proper
> namespace hierarchy*/
>
> //Forgive me if the style of my code is unorthodox:
>
> (Syntax from my proposal from GitHub):
>
> {vector_containing_type_collections, deque_containing_type_collections,
> map_containing_type_collections,
>
> hash_map_containing_type_collections,
>
> list_containing_type_collections,
>
> forward_list_containing_type_collections}
>
> return_index_chosen(any integer that ful fills the is integral concept
> index);
>
> //In short indexed using return_index_chosen(int), but the (proper)
> example is below:
>
> inline void change_collection_of_types
>
> (const std::string& string_to_read_from,
> std::string::size_type* pos){
>
> auto type_info=
> get_collections_of_types_from_string(string_to_read_from, pos);
>
>
>
>
>
>
>
> //*********Expression where my proposed syntax is used*********:
>
> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
> pos)).at(read_from_string<Get_cont_size_type_t<decltype(array_containing_types))>>(string_to_read_from,
> pos))= std::move(type_info);
>
> }
>
>
>
> //The diffiency is the syntax currently used by my code
>
> *********The proposed syntax*********
>
>
>
>
>
> *********The diffiency*********
>
>
>
> It's all in the "
> type_information_storage_facilities_and_functions_to_access_them::main_interface_to_get_type_information"
> namespace of this file:
>
>
> https://github.com/HjaldrKhilji/The-Turing-virtual-machine/blob/main/Output_modules%2Fsrc%2Fhelper_option_templates_for_arithmetic_related_options.cpp
>
> But as an example:
>
> inline void change_collection_of_types
>
> (const std::string& string_to_read_from,
> std::string::size_type* pos){
>
> auto type_info=
> get_collections_of_types_from_string(string_to_read_from, pos);
>
> Which_type_facility_to_change
> facility_to_change=
>
>
> static_cast<Which_type_facility_to_change>
>
>
> (read_from_string<uint8_t>(string_to_read_from, pos));
>
> switch(facility_to_change){
>
> case
> Which_type_facility_to_change::change_array_tag:
>
> array_containing_types.at
> (read_from_string
>
>
> <Get_cont_size_type_t<decltype(array_containing_types)>>
>
> (string_to_read_from,
> pos))= std::move(type_info);
>
> break;
>
> case
> Which_type_facility_to_change::change_vector_tag:
>
>
> vector_containing_type_collections.at(read_from_string
>
>
> <Get_cont_size_type_t<decltype(vector_containing_type_collections)>>
>
> (string_to_read_from,
> pos))= std::move(type_info);
>
> break;
>
>
> case
> Which_type_facility_to_change::change_deque_tag:
>
>
> deque_containing_type_collections.at(read_from_string
>
>
> <Get_cont_size_type_t<decltype(deque_containing_type_collections)>>
>
> (string_to_read_from,
> pos))= std::move(type_info);
>
> break;
>
> case
> Which_type_facility_to_change::change_map_tag:
>
>
> map_containing_type_collections.at(read_from_string
>
>
> <Get_cont_size_type_t<decltype(map_containing_type_collections)>>
>
> (string_to_read_from,
> pos))= std::move(type_info);
>
> break;
>
> case
> Which_type_facility_to_change::change_hash_map_tag:
>
>
> hash_map_containing_type_collections.at(read_from_string
>
>
> <Get_cont_size_type_t<decltype(hash_map_containing_type_collections)>>
>
> (string_to_read_from,
> pos))= std::move(type_info);
>
> break;
>
> case
> Which_type_facility_to_change::change_list_tag:
>
>
> at_for_containers_that_dont_support_it(list_containing_type_collections,
> read_from_string
>
>
> <Get_cont_size_type_t<decltype(list_containing_type_collections)>>
>
> (string_to_read_from,
> pos))= std::move(type_info);
>
> break;
>
> case
> Which_type_facility_to_change::change_forward_list_tag:
>
>
> at_for_containers_that_dont_support_it(forward_list_containing_type_collections,
> read_from_string
>
>
> <Get_cont_size_type_t<decltype(forward_list_containing_type_collections)>>
>
> (string_to_read_from,
> pos))= std::move(type_info);
>
> break;
>
> default:
>
> throw std::string{"invalid
> type location!!!"};
>
> }
>
> }
>
>
>
> *********The diffiency*********
>
>
>
>
>
>
>
> *********Clarifications on previous discussions*********
>
>
>
> 1. The reason that I kept on discussing the backend was because I was
> asked about it. Like I had to talk about them because people were asking
> questions about them, and without answering them, I can't learn.
>
> 2. The reason that I was confident about unproven claim is that they were
> the fundamentals of compiler theory, but I should've used standard terms
> when describing them, so I admit that it's totally my fault.
>
> *********Clarifications on previous discussions*********
>
>
>
> *********Notes and admissions*********
>
>
>
> I can totally admit that I made immense amount of mistakes in the way I
> explain myself but what I rely on to fix it is feedback from legends like
> you guys. Please keep giving feedback and sorry for any short comings. ❤️
>
>
>
> *********Notes and admissions*********
>
>
>
>
>
>
>
> Discussion(real world event):
>
>
>
> My problem was that I was making a Virtual Machine on GitHub and that
> Virtual machine, and I had a very interesting type that used
> std::pmr::monotonic_buffer_resource to allocate size:
>
> 1.For a tag suggesting that this region is allocated using a monolithic
> buffer
>
> 2.A type info about a list of objects.
>
> 3. The std::pmr::vector<void*, std::pmr::polymorphic_allocator> they are
> to be stored in.
>
> 4. The size allocated.
>
> 5. The buffer resource itself.
>
> This type was provided for the memory to be efficient (cache friendly).
> Once, allocated, I read the type of the objects and allocated the objects
> with the type info that I had beforehand.
>
> What's the problem with this?
>
> The problem is that every time that this time required the promise that:
>
> unlike other types that promised a constant latency, this type promised
> maximum bandwidth, but to get that bandwidth, I had to make the user give
> me all the type info of all the list of objects all at once (from a
> string), and to make it even better, I made him be able to store/"cache"
> this information in any of the multiple containers from which he can use it
> later:
>
> namespace type_information_storage_facilities{
>
> std::vector<Type_info_t>
> vector_containing_type_collections;
>
> std::deque<Type_info_t>
> deque_containing_type_collections;
>
> std::vector<Type_info_t>
> map_containing_type_collections;
>
> std::vector<Type_info_t>
> hash_map_containing_type_collections;
>
> std::list<Type_info_t>
> list_containing_type_collections;
>
> std::forward_list<Type_info_t>
> forward_list_containing_type_collections;
>
> std::array<Type_info_t, 100>
> array_containing_types{};
>
> }
>
> To manage these types in these containers, I use a list of functions that
> the user can use, and all of them had to use switch case statements, which
> was verbose, and led to me asking AI write down 2000+ lines of code. This
> would probably backfire as binary code bloat and now my code hates me and
> cries when I open it. This optimization technique was meant to be the main
> thing that made my tool faster, but the cost was making my code unreadable.
> The important part of my code is just a few lines(1500), while the rest is
> this. My code:
>
>
> https://github.com/HjaldrKhilji/The-Turing-virtual-machine/blob/main/Output_modules%2Fsrc%2Fhelper_option_templates_for_arithmetic_related_options.cpp
> .
>
>
>
> This wouldn't be much of a issue on code that is trying to program the
> backend of my brothers fashion brand, but for a feature in a virtual
> machine that promises to be cache friendly, like that special type, this
> matters because it reads from a single string all at once and then it sends
> that information to those containers.
>
>
>
>
>
>
>
> On Sat, 4 Apr 2026, 7:22 am Jason McKesson via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
> On Fri, Apr 3, 2026 at 10:07 PM Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > The problem is why use branch constructs to branch through multiple
> branches that call the same functions on a list of objects?
> >
> > Please tell me what am I missing?
>
> What you're missing is that what you said doesn't describe an actual
> problem. It describes your desired solution, phrased in the form of a
> problem.
>
> When you say "use branch constructs to branch through multiple
> branches that call the same functions on a list of objects", what you
> are describing is the code you want to write. That is not a "problem";
> it is an implementation of a solution to a problem. The "problem" is
> the thing that made you think that writing this code in this way was a
> thing you should be doing.
>
> For example, I could say that I have a series of polymorphic classes
> derived from a shared base that allows the derived classes to respond
> to an arbitrary set of events with behavior specific to that class. I
> could also say that I have a series of classes that contain an
> event-receiver, allowing them to respond to an arbitrary set of events
> with behavior specific to that class. Maybe I could even "use branch
> constructs to branch through multiple branches that call the same
> functions on a list of objects".
>
> But none of those are the problem I'm trying to solve; they're just
> the *implementation* of the problem I'm trying to solve. That problem
> being "I have a series of game entities that need to be able to
> respond to similar events in different ways, specific to the nature of
> that entity."
>
> That's what a problem description looks like.
> --
> 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
>

Received on 2026-04-04 04:39:19