C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Function overload set type information loss

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Wed, 31 Jul 2024 00:04:35 +0200
Hi Nadir, you are pushing function pointers to a vector. How should the compiler keep track, at which position which function pointer was pushed?   You are talking about an internal compiler structure.   But at compile time it is not even known, if, how many and which pointers are pushed into the vector. So how should the compiler fill such a structure?   Overload resolution can be directly done at compile time. As the type is directly known.   -----Ursprüngliche Nachricht----- Von:organicoman <organicoman_at_[hidden]> Gesendet:Di 30.07.2024 23:44 Betreff:Re: [std-proposals] Function overload set type information loss An:Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; Hi Sebastian, Recall that we have two type of information. The apparent type The effective type.  The is applied only for the foloowing type categories -Arrays -Function templates  -Variable template   The apparent type , is the one we are using currently. Example: template<typename T> void foo(int); decltype(foo<char>); // void(*)(int) no matter what T is  But the effective type:  effective_decltype(foo<char>); // void(*)<char>(int), and it depends on the template argument  Observe that the last is tagged with the template argument value, and the 1st is not.  To store object of type foo above, we have two options Either you write: std::vector<effective_decltype(foo)> myVec; or std::vector<void(*)(int)> myVec; It is exactly the same buffer size and alignment. The only difference is that, for the 1st option, the compiler keeps and internal structure filled with the effective type of the object pushed into the vector, and tracks where that information is needed, replace it there, then trashs everything at the end. The same when it does overload resolution. Actually it is the same implementation. It is all compile time process. No runtime is affected. Sent from my Galaxy   -------- Original message -------- From: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> Date: 7/31/24 12:49 AM (GMT+04:00) To: Std-Proposals <std-proposals_at_[hidden]> Cc: Sebastian Wittmeier <wittmeier_at_[hidden]> Subject: Re: [std-proposals] Function overload set type information loss   Hi organicoman,   that is the whole point.   You want a compile time feature, where the compiler keeps the information, how an object is created. But then on the other hand, you want to store those objects into a container.   E.g. std::array<int32_t, N>   Where should this additional meta information be kept? The storing of values into the container is in the general case done at runtime. It could be dependent on user or file inputs. So the compiler (compile-time) cannot follow it any longer.   The array itself has a fixed size of 4*N bytes, just enough for the int. So we also cannot store type ids at runtime together with the ints themselves.   We loose the meta / extended type information.   It is not a language shortcoming, but there is no logical way to solve this for containers. You have to give up one of your requirements:   Either  - the container stores additional information (std::any like)  - all entries in the container will have the same meta type instead of an individual one  - it only works for containers clearly initialized in a way, which can be deduced at compile-time, e.g. std::array<int32_t, 5> myarray{1, 2, 3, 4, 5};  - it won't work with containers at all  - it only works for containers modified in consteval/constinit code (which the compiler may choose to run at compile-time)   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:organicoman <organicoman_at_[hidden]> Gesendet:Di 30.07.2024 22:01 Betreff:Re: [std-proposals] Function overload set type information loss An:Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>;   As far as the constructor of A above is concerned, it accepts argument of apparent type int, but as soon as we pass arguments with a signature like the globalVar above it will capture an effective type of this form (int)<T>  The type alias meta_int above, is just an int with some extra meta datawhen needed. With AutoWrapper class in your example, You have to be intrusive, and any data member of AutoWrapper type, imposes at any class to be templated. Thus that class cannot be used as a container template parameter.

Received on 2024-07-30 22:04:38