On 3/18/21 6:03 PM, Phil Bouchard via Std-Proposals wrote:
>
>
> 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...
>
Ok it looks like the equivalent can be achieved with "nested
requirements". Good job guys!


>
>>
>> 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>
>

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