Return to Answer

1. We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.

2. This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.

3. Using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

1. We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.

2. This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

   When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.

3. Using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

1. We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.

2. IMO opinion it is a good design. This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.

3. IMO, and you pointed out same thing, using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

1. We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.

2. This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.

3. Using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

1. We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.

2. IMO opinion it is a good design. This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.

3. IMO, and you pointed out same thing, using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

1. We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.

2. IMO opinion it is a good design. This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.

3. IMO, and you pointed out same thing, using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.