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

On Wed, Mar 17, 2021 at 5:16 PM D'Alessandro, Luke K via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

-------- Original Message --------

On Mar 17, 2021, 19:10, Phil Bouchard < boost@fornux.com> 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@fornux.com> 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@lists.isocpp.org> 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

--

Phil Bouchard

Founder

C.: (819) 328-4743

--

Phil Bouchard

Founder

C.: (819) 328-4743

--

Phil Bouchard

Founder

C.: (819) 328-4743

--

Phil Bouchard
Founder
C.: (819) 328-4743

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--

Phil Bouchard
Founder
C.: (819) 328-4743