Date: Fri, 2 Aug 2024 20:48:39 +0200
pt., 2 sie 2024 o 20:01 organicoman <organicoman_at_[hidden]> napisał(a):
>
> See Tiago last post.
> It is the same algorithm described in this propsal.
>
>
I do not ask about other solutions, I ask about your code and your "solution".
You previously said that `std::any` can't solve your problem. Now you say
then `std::any` IS solution for your problem. This means you have no idea
what your problem is and only handwave some code around.
> The advantage of my approach, is that it is more effecient and safe.
My template solution has exactly the same properties that (aka safe
and effectinet)
I proved it on your's example that you showed previously.
You did not contradict my proof.
I ask again, can you show me code that can't be solved
by current template metaprogramming? Show exactly code and problem
that fails to do it.
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
> Date: 8/2/24 9:40 PM (GMT+04:00)
> To: organicoman <organicoman_at_[hidden]>
> Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>, std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Function overload set type information loss
>
> pt., 2 sie 2024 o 18:35 organicoman <organicoman_at_[hidden]> napisał(a):
> >
> >
> >
> > Lest be charitable and assume you mean this code:
> >
> >
> > ```
> > template<typename T>
> > void foo() { cout <<typeid(T).name()<<endl;}
> >
> > auto useType(effdecltype(foo) f)
> > {
> > using T = __get_ortho_at__<0>(f);
> > f();
> > return T(0);
> > }
> >
> > template<typename T>
> > void consumeType(T t)
> > { cout << typeid(t).name(); }
> >
> > int main()
> > {
> > vector<effdecltype(foo)> vec;
> > vec.push_back(&foo<int>);
> > vec.push_back(&foo<double>);
> > vec.push_back(&foo<float>);
> > for(int i=0; i<5; ++i)
> > vec.push_back(&foo<char>);
> > for(const auto& F: vec)
> > consumeType(useType(F));
> > }
> > ```
> >
> >
> > It can be easy fixed by helper:
> >
> >
> > ```
> > template<typename T>
> > void consumeTypeHelper()
> > {
> > foo<T>();
> > return consumeType(T{});
> > }
> >
> > int main()
> > {
> > vector<void(*)()> vec;
> > vec.push_back(&consumeTypeHelper<int>);
> > vec.push_back(&consumeTypeHelper<double>);
> > vec.push_back(&consumeTypeHelper<float>);
> > for(int i=0; i<5; ++i)
> > vec.push_back(&consumeTypeHelper<char>);
> > for(const auto& F: vec)
> > F();
> > }
> > ```
> >
> > Done. Problem fixed in C++11
> >
>
>
>
>
>
> > Very good... nice try.
> > Unfortunately you miss the point.
> >
> > I showed a loop over a set of functions returning many types.
> > Imagine you have a container of slots, which returns different types ( i already said that many times)
> > Given the current state of C++ you can store them only as. Let say.
> > vector<std::any(*)(int, double)>
> > How can you tell what type the called function returned before it was hiden inside std::any?
> > Is it clear?
> >
> >
>
> Then show this code, I fixed your "example", now show code that can't
> be fixed in the same way.
> If you can't write it, then its means this code can't exist and is not
> a real life problem.
>
> See Tiago last post.
> It is the same algorithm described in this propsal.
>
>
I do not ask about other solutions, I ask about your code and your "solution".
You previously said that `std::any` can't solve your problem. Now you say
then `std::any` IS solution for your problem. This means you have no idea
what your problem is and only handwave some code around.
> The advantage of my approach, is that it is more effecient and safe.
My template solution has exactly the same properties that (aka safe
and effectinet)
I proved it on your's example that you showed previously.
You did not contradict my proof.
I ask again, can you show me code that can't be solved
by current template metaprogramming? Show exactly code and problem
that fails to do it.
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
> Date: 8/2/24 9:40 PM (GMT+04:00)
> To: organicoman <organicoman_at_[hidden]>
> Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>, std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Function overload set type information loss
>
> pt., 2 sie 2024 o 18:35 organicoman <organicoman_at_[hidden]> napisał(a):
> >
> >
> >
> > Lest be charitable and assume you mean this code:
> >
> >
> > ```
> > template<typename T>
> > void foo() { cout <<typeid(T).name()<<endl;}
> >
> > auto useType(effdecltype(foo) f)
> > {
> > using T = __get_ortho_at__<0>(f);
> > f();
> > return T(0);
> > }
> >
> > template<typename T>
> > void consumeType(T t)
> > { cout << typeid(t).name(); }
> >
> > int main()
> > {
> > vector<effdecltype(foo)> vec;
> > vec.push_back(&foo<int>);
> > vec.push_back(&foo<double>);
> > vec.push_back(&foo<float>);
> > for(int i=0; i<5; ++i)
> > vec.push_back(&foo<char>);
> > for(const auto& F: vec)
> > consumeType(useType(F));
> > }
> > ```
> >
> >
> > It can be easy fixed by helper:
> >
> >
> > ```
> > template<typename T>
> > void consumeTypeHelper()
> > {
> > foo<T>();
> > return consumeType(T{});
> > }
> >
> > int main()
> > {
> > vector<void(*)()> vec;
> > vec.push_back(&consumeTypeHelper<int>);
> > vec.push_back(&consumeTypeHelper<double>);
> > vec.push_back(&consumeTypeHelper<float>);
> > for(int i=0; i<5; ++i)
> > vec.push_back(&consumeTypeHelper<char>);
> > for(const auto& F: vec)
> > F();
> > }
> > ```
> >
> > Done. Problem fixed in C++11
> >
>
>
>
>
>
> > Very good... nice try.
> > Unfortunately you miss the point.
> >
> > I showed a loop over a set of functions returning many types.
> > Imagine you have a container of slots, which returns different types ( i already said that many times)
> > Given the current state of C++ you can store them only as. Let say.
> > vector<std::any(*)(int, double)>
> > How can you tell what type the called function returned before it was hiden inside std::any?
> > Is it clear?
> >
> >
>
> Then show this code, I fixed your "example", now show code that can't
> be fixed in the same way.
> If you can't write it, then its means this code can't exist and is not
> a real life problem.
Received on 2024-08-02 18:48:50