C++ library avoid including sub classes

Let's say we have a library that has a class "Car" which has some private members of class "Wheel".

We want the user to be able to create a "Car" and use the "Drive" function(ality) of it.
This will also turn the wheels.

However, we want to avoid the user to create a "Wheel" by itself and turn it w/o the use of a car. To avoid them using the library improperly.

See example code below, where the main.cpp is the user code and the rest is the library.

main.cpp

#include <iostream>
#include "car.h"

int main()
{
    std::cout << "Hello World" << std::endl;
    Car myCar = Car();
    myCar.drive();
    
    //This should not be possible!
    Wheel someWheel = Wheel();
    someWheel.rotate();
    return 0;
}

car.h

class Wheel;//Forward declaration (to avoid '#include "wheel.h"', which would make it accessible in main.cpp.
class Car {
public:
    Car();
    void drive();
private:
    Wheel leftWheel;//Error, requires a pointer
};

car.cpp

#include <iostream>
#include "car.h"
#include "wheel.h"

Car::Car(){
    leftWheel = new Wheel();
};
void Car::drive(){
    std::cout << "Vroom!"  << std::endl;
    leftWheel.rotate();
}

wheel.h

class Wheel {
public:
    Wheel();
    void rotate();
};

wheel.cpp

#include <iostream>
#include "wheel.h"

Wheel::Wheel(){
};
void Wheel::rotate(){
    std::cout << "Wheel: *Rotates*"  << std::endl;    
}

We've found that by including the header file in the Car.cpp, we can achieve this.
However, when we make a forward declaration of 'Wheel', we can only use a pointer to Wheel as a private member from Car.

Otherwise it leads to:

> car.h:12:11: error: field ‘leftWheel’ has incomplete type ‘Wheel’

So my questions are:

• Should we at all hide 'Wheel' from the user, for his own 'safety'? Or is there a stronger reason not to do it?
  • If so, can we achieve this without the use of a pointer
    • If not, do we have to explicitly make a deconstructor that deletes the instance from memory?

Depending on the access you want the user to give to the Wheel class, simply restricting some members of the class to non-public visibility and making Car a friend can do the trick.

Alternatively you could make Wheel a protected nested class of a supertype.

Both of these alternatives result in a compiler complaining about the inaccessibility of members/types when trying to create a Wheel without a Car. This is closer to the message you're trying to convey ("Keep your hands of my Wheel class.") than a message about the type of Wheel being incomplete. (The latter is likely to be interpreted as "You're missing the correct #include".) Furthermore it avoids an extra dynamic allocation.

namespace UseFriends
{
class Car;
class Wheel
{
friend class Car;
Wheel() = default;
Wheel(Wheel&&) = default;
Wheel& operator=(Wheel&&) = default;
Wheel(Wheel const&) = default;
Wheel& operator=(Wheel const&) = default;
public:
void rotate()
{
std::cout << "Wheel: *Rotates*" << std::endl;
}
};
class Car
{
public:
Car()
{
}
void drive()
{
std::cout << "Vroom!" << std::endl;
leftWheel.rotate();
}
private:
Wheel leftWheel;
};
} // namespace UseFriends
namespace UseNestedClass
{
class Vehicle
{
protected:
class Wheel
{
public:
void rotate()
{
std::cout << "Wheel: *Rotates*" << std::endl;
}
};
};
class Car : private Vehicle
{
public:
Car()
{
}
void drive()
{
std::cout << "Vroom!" << std::endl;
leftWheel.rotate();
}
private:
Vehicle::Wheel leftWheel;
};
} // namespace UseNestedClass
int main()
{
{
using Car = UseFriends::Car;
using Wheel = UseFriends::Wheel;
std::cout << "Hello World" << std::endl;
Car myCar = Car();
myCar.drive();
Wheel someWheel = Wheel(); // compiler error: UseFriends::Wheel::Wheel() is inaccessible
someWheel.rotate();
}
{
using Car = UseNestedClass::Car;
using Wheel = UseNestedClass::Vehicle::Wheel; // compiler error: UseNestedClass::Vehicle::Wheel is inaccessible
std::cout << "Hello World" << std::endl;
Car myCar = Car();
myCar.drive();
}
}