My 5 cent here:

In PHP there is something called "late static binding". I am a PHP programmer, but used it only once in production.

Technical explanation is very difficult and I am not sure I understand it correctly,
but it allows to execute overridden static method in child class:

https://www.php.net/manual/en/language.oop5.late-static-bindings.php

I believe it will be interesting to take a look.

I must say, PHP is a language derived from C (not C++), but all classes are Java like - all non-static methods are virtual,
so every PHP class has vtable (or even pointer to all methods) and is not difficult to do functionality like that.

Nikolay


On Fri, Mar 19, 2021 at 12:05 AM Phil Bouchard via Std-Proposals <std-proposals@lists.isocpp.org> 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...



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@iu.edu> 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
Fornux
                                          Logo
--

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

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

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

--

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

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

Fornux Logo

--

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

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