class ApplicationWindow
{
public:
	ApplicationWindow();
	virtual ~ApplicationWindow();
	void *GetWindow();
	int32_t GetWidth();
	int32_t GetHeight();

protected:
	void *windowHandle;
	int32_t width;
	int32_t height;
};

class EGLDisplayWindow : public ApplicationWindow
{
public:
	EGLDisplayWindow();
	~EGLDisplayWindow();
	void CreateWindow(void *windowHandle);

private:
	void CreateAndroidWindow();
	void CreateIOSWindow();
	void DestroyWindow();


};

The android/ios names suggest to me that this is for different window types on different platforms? Presumably you need to build different binaries for different platforms, so why not use #ifdef directives to control this instead (I mean... how would you implement CreateIOSWindow on android anyway?)

void EGLDisplayWindow::CreateWindow(void * windowHandle)
{
     this.windowHandle = windowHandle;

#if defined(_ANDROID_)
   
    CreateAndroidWindow(this.windowHandle);

#endif

//Other platforms that need EGL Windows

}

Your code above, however, is not using a void* but trying to instantiate a void. That's not gonna work.

The protected keyword in C++ is ugly. It's usually a good hint there's a better design hiding somewhere. That's off topic though

Personally, I like to make my own opaque pointer types for better self-documentation.

Why is protected bad in C++? How else do you hide data members from everyone and only expose them to the inherited classes?

Because data members should never be protected, and few functions should use it. It does have some uses, but protected is rarely useful in C++, and most code can get away with never using it.

Herb Sutter (the chair of the C++ language committee basically for the past 20 years) has written several articles on it. I've included some links to some of the writing, there are probably better write-ups.

Basically it looks like this:



PUBLIC:
* Interface functions should be public. (The public functions should not be virtual. A surprisingly huge amount of bad code uses public virtual functions to achieve it's problems. When you can replace both the interface and behavior you can subvert things easily, both to be evil and as an accidental source of bugs.)
* Data members of POD classes/structs that serve as data bundles rather than logical classes.
* Base class destructor that is virtual and requires polymorphic destruction.

PROTECTED:
* Non-virtual utility functions to be used by child classes that relies on other member data in this base class. (Rare situation)
* Base class destructor that is non-virtual. (Rare situation)

* Virtual functions to be used by base classes that cannot be private because base classes must call them explicitly. (Design smell and source of bugs. Virtual functions are customizations that are an implementation detail. Why do you need to explicitly call a parent's customization? How do you know that customization will never change? If you have a tendency to do this, will you retrofit all other classes when it becomes necessary for others to use it? Instead put that into a protected utility function so all descendants can use it. )

PRIVATE:
* All data members, unless this is a data-only bundle.
* Any function not part of the publicly visible interface. This includes utility functions and virtual functions.

The vast majority of all code belongs in the public and private arena. There are occasional uses of protected, but they are rarely encountered.