interface design for allowing custom parameter struct, falling back on defaults
It sounds like your primary problem right now is memory management — you're worried about how to use dynamic memory allocation without leaks or double-frees. C++ has a solution for that!

class FlyCamera {
public:
    FlyCamera(/* position, gaze, etc params */,
              std::unique_ptr&lt;FlyCameraKeyParams&gt; keyParams = nullptr) {
        if (keyParams == nullptr) {
            keyParams = std::make_unique&lt;FlyCameraDefaultKeyParams&gt;();
        }
        mKeyParams = std::move(keyParams);  // take ownership
    }

private:
    std::unique_ptr&lt;FlyCameraKeyParams&gt; mKeyParams = nullptr;
};


The destructor of unique_ptr&lt;T&gt; takes care of calling delete on the owned pointer (which will call the proper derived-class destructor as long as you've made the base-class destructor virtual).



However, for this particular problem, I don't see why you want a whole polymorphic class for FlyCameraKeyParams. Have you considered flattening things out into a more "C-like" style?

The name of the class should tip you off: I understand a desire for generic KeyBindings or something; but if your FlyCameraKeyParams are literally nothing more than Params to the FlyCamera, then you should make them params to the FlyCamera. Parameterizing the behavior of a concrete class is generally done by setting member variables.

Bonus: FlyCameraDefaultKeyParams describes the defaults of the key params of FlyCamera. So with C++11 member-variable-default-initializer syntax, we flatten that class away as well.

class FlyCamera {
public:
    FlyCamera(/* position, gaze, etc params */) { ... }

    void setFlyForwardKey(int k) { mFlyForwardKey = k; }
    void setFlyBackwardKey(int k) { mFlyBackwardKey = k; }

private:
    int mFlyForwardKey = 'W'; // Self-documenting defaults!
    int mFlyBackwardKey = 'S';
    // ... 
};




Notice in passing that I removed your virtual destructor from FlyCamera and made the protected members private, just to discourage people from inheriting from it. If you really need to allow inheritance, go ahead and put the virtual stuff back.