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.


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>