Date: Wed, 31 Jul 2024 01:43:46 +0400
Hi Sebastian,Recall that we have two type of information.The apparent typeThe 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 isBut the effective type:effective_decltype(foo<char>); // void(*)<char>(int), and it depends on the template argumentObserve 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 optionsEither you write:std::vector<effective_decltype(foo)> myVec;orstd::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:01Betreff: Re: [std-proposals] Function overload set type information lossAn: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>; CC: Sebastian Wittmeier <wittmeier_at_[hidden]>; body { font-family: monospace; } As far as the constructor of A above is concerned, it accepts argumentof 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 intwith 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 tobe templated. Thus that class cannot be used as a container template parameter.
-------- 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:01Betreff: Re: [std-proposals] Function overload set type information lossAn: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>; CC: Sebastian Wittmeier <wittmeier_at_[hidden]>; body { font-family: monospace; } As far as the constructor of A above is concerned, it accepts argumentof 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 intwith 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 tobe templated. Thus that class cannot be used as a container template parameter.
Received on 2024-07-30 21:44:00