Date: Wed, 2 Oct 2024 10:07:25 +0000
Please don’t waste your time.
This user is a known troll. Nothing they propose makes sense. Ever!
Nothing will ever come out of this.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Robin Savonen Söderholm via Std-Proposals
Sent: Wednesday, October 2, 2024 12:03 PM
To: std-proposals_at_[hidden]
Cc: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>
Subject: Re: [std-proposals] Not quite a template virtual function
It does not matter... Take the following example:
class virtual_foo {
// What we see here depends on header inclusion order inside a compilation unit...
template <typename T>
requires(requires(T const& t) { ns::foo(t); }
void do_foo(T const& t) { ns::foo(t); }
public:
virtual void foo(auto&& f) { do_foo(f); }
};
// Robin
PS: I want to point out that you may already be able to achieve what you are looking for by doing something along these lines:
template <typename T>
class base_foo_template {
public:
virtual void foo(T t) { ns::foo(std::forward<T>(t); }
};
class my_virtual_foo : public base_foo_template<int const&>, public base_foo_template<float&&> {};
and you could even have a helper class that takes a variadic template argument to write:
class my_virtual_Foo : publix base_foo_multi_template<int const&, float&&> {};
. But it is hard to know if this is a good idea without knowing the problem you are actually trying to solve..
On Wed, Oct 2, 2024 at 11:44 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
I reply to Robin and Lénárd:
Robin wrote:
>
> That example is potentially ODR breaking as you could have
> different compilation units that see different "SomeGlobalFunction":s
Lénárd wrote;
>
> Even seeing the same functions in different order would be potentially ODR-breaking.
This can be alleviated by restricting it even further. Previously I wrote:
"A class shall not have a non-static virtual method with the
parameter list "auto&&... args" unless the inline body of the method
contains an invocation of a non-template-and-non-variadic function
with the arguments "static_cast<decltype(args)>(args)..." -- in which
case the virtual method will be given an instantiation for each of the
overload signatures of the aforementioned
non-template-and-non-variadic function."
But we can change "non-template-and-non-variadic function" to
"non-template-and-non-variadic member function". Since you can only
have one definition of a class, there won't be any case of one
translation unit seeing member functions that another translation unit
doesn't see -- nor any case of seeing them in a different order.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
This user is a known troll. Nothing they propose makes sense. Ever!
Nothing will ever come out of this.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Robin Savonen Söderholm via Std-Proposals
Sent: Wednesday, October 2, 2024 12:03 PM
To: std-proposals_at_[hidden]
Cc: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>
Subject: Re: [std-proposals] Not quite a template virtual function
It does not matter... Take the following example:
class virtual_foo {
// What we see here depends on header inclusion order inside a compilation unit...
template <typename T>
requires(requires(T const& t) { ns::foo(t); }
void do_foo(T const& t) { ns::foo(t); }
public:
virtual void foo(auto&& f) { do_foo(f); }
};
// Robin
PS: I want to point out that you may already be able to achieve what you are looking for by doing something along these lines:
template <typename T>
class base_foo_template {
public:
virtual void foo(T t) { ns::foo(std::forward<T>(t); }
};
class my_virtual_foo : public base_foo_template<int const&>, public base_foo_template<float&&> {};
and you could even have a helper class that takes a variadic template argument to write:
class my_virtual_Foo : publix base_foo_multi_template<int const&, float&&> {};
. But it is hard to know if this is a good idea without knowing the problem you are actually trying to solve..
On Wed, Oct 2, 2024 at 11:44 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
I reply to Robin and Lénárd:
Robin wrote:
>
> That example is potentially ODR breaking as you could have
> different compilation units that see different "SomeGlobalFunction":s
Lénárd wrote;
>
> Even seeing the same functions in different order would be potentially ODR-breaking.
This can be alleviated by restricting it even further. Previously I wrote:
"A class shall not have a non-static virtual method with the
parameter list "auto&&... args" unless the inline body of the method
contains an invocation of a non-template-and-non-variadic function
with the arguments "static_cast<decltype(args)>(args)..." -- in which
case the virtual method will be given an instantiation for each of the
overload signatures of the aforementioned
non-template-and-non-variadic function."
But we can change "non-template-and-non-variadic function" to
"non-template-and-non-variadic member function". Since you can only
have one definition of a class, there won't be any case of one
translation unit seeing member functions that another translation unit
doesn't see -- nor any case of seeing them in a different order.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-10-02 10:07:28