On 3/18/21 2:46 PM, Phil Bouchard via Std-Proposals wrote:
>
> Double-checking here...
>
> As long as there's an equivalent to pure virtual at compile-time
> (forcing derived classes to override required member functions) other
> than explicitly adding concepts for each member functions.
>
I guess I would add inheritance to concepts then. I think you all
understand what I mean here and why...


>
> On 3/17/21 11:59 PM, Ryan P. Nicholl wrote:
>> I think they are, and more importantly, I think C++ is moving in the
>> direction of discouraging OOP in favor of generics + concepts.
>> Inheritance in OOP tends to cause more problems than it solves. There
>> are certainly use cases for it but I think most of them are better
>> solved with variants or interfaces (which must be implemented via
>> templates as C++ has no first class interfaces, closest we have are
>> concepts and abstract classes.).
>>
>> Now sure sometimes inheritance/polymorphism can make sense, but I'm
>> not generally a fan of it in most cases. The biggest problem is lack
>> of built in copy support by C++. Interfaces implemented with
>> templates can easily support copying without the many to many
>> implementation issues with polymorphism. You need a separate "clone"
>> call for each interface you support via polymorphism, but copy
>> construction can be implemented by an interface via compile time
>> dynamic dispatch tables (type erasure). That has to be an advantage,
>> imo, for type erasure over OOP.
>>
>> Sent from ProtonMail mobile
>>
>>
>>
>> -------- Original Message --------
>> On Mar 17, 2021, 8:14 PM, D'Alessandro, Luke K < ldalessa_at_[hidden]> wrote:
>>
>>
>>
>>>>>> -------- Original Message --------
>>>>>> On Mar 17, 2021, 19:10, Phil Bouchard < boost_at_[hidden]
>>>>>> <mailto:boost_at_[hidden]>> wrote:
>>>>>>
>>>>>>
>>>>>> - A runtime virtual table needs an indirect lookup to the
>>>>>> proper member function, based on its type;
>>>>>>
>>>>>> - At compile-time there is no need for these indirect
>>>>>> lookups.
>>>>>>
>>>>>> The compiler will fail if you do not use a derived type.
>>>>>> The idea is to create cleaner, safer header libraries and
>>>>>> not tons of error messages because the error can be
>>>>>> isolated more easily.
>>>>>>
>> Are you sure these concerns aren’t already resolved through the
>> use of concepts?
>>
>> Luke
>>>>>>
>>>>>> On 3/17/21 7:01 PM, Ryan P. Nicholl wrote:
>>>>>>> Ok, so your proposal is that the code runs in compile
>>>>>>> time, so how is it faster? Some kind of runtime/compile
>>>>>>> time hybrid?
>>>>>>>
>>>>>>> Does the compiler fail to compile if it can't figure out
>>>>>>> the assigned type at compile time? Isn't this the same
>>>>>>> use case as auto?
>>>>>>>
>>>>>>> Why is this better than type deduction using auto &?
>>>>>>> What can be accomplished that cannot be done using type
>>>>>>> deduction?
>>>>>>> -------- Original Message --------
>>>>>>> On Mar 17, 2021, 18:50, Phil Bouchard < boost_at_[hidden]
>>>>>>> <mailto:boost_at_[hidden]>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Like I said, it won't create a virtual table and
>>>>>>> much faster resulting code when handled at compile-time.
>>>>>>>
>>>>>>> On 3/17/21 6:46 PM, Ryan P. Nicholl via
>>>>>>> Std-Proposals wrote:
>>>>>>>> And what would this *do* that function overriding
>>>>>>>> does not?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> On Mar 17, 2021, 17:12, Phil Bouchard via
>>>>>>>> Std-Proposals < std-proposals_at_[hidden]
>>>>>>>> <mailto:std-proposals_at_[hidden]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> It won't create a run-time virtual table.
>>>>>>>>
>>>>>>>> On 3/17/21 5:03 PM, Andrey Semashev via
>>>>>>>> Std-Proposals wrote:
>>>>>>>>> On 3/17/21 10:41 PM, Phil Bouchard via
>>>>>>>>> Std-Proposals wrote:
>>>>>>>>>
>>>>>>>>>> New keyword proposal to allow inheritance at
>>>>>>>>>> compile-time. Ex:
>>>>>>>>>>
>>>>>>>>>> template <typename T>
>>>>>>>>>>
>>>>>>>>>> struct container
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>>
>>>>>>>>>> static_virtual T * begin() {...}
>>>>>>>>>>
>>>>>>>>>> static_virtual T * end() {...}
>>>>>>>>>>
>>>>>>>>>> static_virtual T * rbegin() {...}
>>>>>>>>>>
>>>>>>>>>> static_virtual T * rend() {...}
>>>>>>>>>>
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> template <typename T>
>>>>>>>>>>
>>>>>>>>>> struct list : container<T>
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>>
>>>>>>>>>> static_virtual T * begin() {...}
>>>>>>>>>>
>>>>>>>>>> static_virtual T * end() {...}
>>>>>>>>>>
>>>>>>>>>> static_virtual T * rbegin() {...}
>>>>>>>>>>
>>>>>>>>>> static_virtual T * rend() {...}
>>>>>>>>>>
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> template <typename T>
>>>>>>>>>>
>>>>>>>>>> ostream & ostream(ostream & out, container<T>
>>>>>>>>>> const & c)
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>>
>>>>>>>>>> for (auto i = c.begin(); i != c.end();
>>>>>>>>>> ++ i)
>>>>>>>>>>
>>>>>>>>>> out << * i << endl;
>>>>>>>>>>
>>>>>>>>>> return out;
>>>>>>>>>>
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>>
>>>>>>>>>> list<int> l;
>>>>>>>>>>
>>>>>>>>>> l.push_back(1);
>>>>>>>>>>
>>>>>>>>>> l.push_back(2);
>>>>>>>>>>
>>>>>>>>>> l.push_back(3);
>>>>>>>>>>
>>>>>>>>>> cout << l << endl;
>>>>>>>>>>
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I'm not sure how it is different from the good
>>>>>>>>> old virtual.
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Phil Bouchard*
>>>>>>>> Founder
>>>>>>>> C.: (819) 328-4743
>>>>>>>> Fornux Logo <http://www.fornux.com/>
>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Phil Bouchard*
>>>>>>> Founder
>>>>>>> C.: (819) 328-4743
>>>>>>> Fornux Logo <http://www.fornux.com/>
>>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Phil Bouchard*
>>>>>> Founder
>>>>>> C.: (819) 328-4743
>>>>>> Fornux Logo <http://www.fornux.com/>
>>>>>>
>>>>> --
>>>>>
>>>>> *Phil Bouchard*
>>>>> Founder
>>>>> C.: (819) 328-4743
>>>>> Fornux Logo <http://www.fornux.com/>
>>>>
>>> --
>>>
>>> *Phil Bouchard*
>>> Founder
>>> C.: (819) 328-4743
>>>
>>> Fornux Logo <http://www.fornux.com/>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> <mailto:Std-Proposals_at_[hidden]>
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
>
> *Phil Bouchard*
> Founder
> C.: (819) 328-4743
>
> Fornux Logo <http://www.fornux.com>
>

-- 
*Phil Bouchard*
Founder
C.: (819) 328-4743
Fornux Logo <http://www.fornux.com>