On 3/17/21 8:28 PM, Chris Green via Std-Proposals wrote:
> So it's a form of specialization where a non-virtual function in the
> base class will be recompiled when used in a derived class, with the
> compilation context being that "this" would be the derived class
> instead of the base one? So:
>
> class EditorBase
> {
> enum dummy = 1;
> public:
> static virtual void Clear() {};
> static virtual void Insert( std::string x ){}
> static virtual void InitBuffer( Clear(); Insert ( "*empty*" );
> printf ("%d", dummy ) }
> };
>
> class RealEditor : public EditorBase
> {
> enum dummy = 2;
> public:
> std::string m_buffer;
> static virtual void Clear() override { m_buffer = ""; }
> static virtual void Insert( std::string x ) override { m_buffer += x; }
> };
>
> Would create a RealEditor class where IntiBuffer actually does
> something, as if Clear and Insert were virtual. Would it print "2" or "1"?

InitBuffer() would print 1 if RealEditor is instantiated because the
access scope of InitBuffer at compile-time is in EditorBase.

>
> Useful, but : I'm curious about how many cases there are for this that
> the compiler couldn't conceptually handle the devirtualization for
> automatically. especially with "final" and link time code generation.?
Huh?
>
> On Wed, Mar 17, 2021 at 5:16 PM D'Alessandro, Luke K via Std-Proposals
> <std-proposals_at_[hidden]
> <mailto:std-proposals_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
>
> --
> 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>