class DeviceWrapper
{
public:
    DeviceWrapper()
    {
        // Initialize MyDevice here, according to RAII principles
    }

    ~DeviceWrapper()
    {
        // RAII again: clean up MyDevice
    }

private:
    ID3D11Device* MyDevice;
};

class ConstantBuffer
{
public:
    ConstantBuffer(DeviceWrapper& wrapper)
        : MyDeviceWrapper(wrapper)
    {
    }

private:
    DeviceWrapper& MyDeviceWrapper;
};

class Renderer
{
private:
    DeviceWrapper MyWrappedDevice;         // IMPORTANT - must be first (order of construction is crucial)

    ConstantBuffer MyConstBuffer;

public:
    Renderer()
        : MyConstBuffer(MyWrappedDevice)
    {
    }
};

Constructor bodies are still useful in some cases where you need to perform additional logic beyond just constructing members. For instance, the constructor of the DeviceWrapper is the perfect place to do your D3D device initialization.

A pointer (or smart pointer) is totally legitimate if you want it to be nullable and/or portray some specific ownership semantics. I prefer references when possible, since they are a little less error-prone, but nobody is going to hang you by your entrails for using a pointer to a component that you need access to - especially if the lifetime/ownership semantics of that component are nontrivial.

Renderer::Renderer()
 : device(CreateDevice())
 , cbuffer(device)
{}

Something I've gradually started to come to prefer over the years is to not actually bind, in this example, the device to the renderer but to just pass the renderer a reference to the device in every method that needs to use it. Renderer an odd example, but a more realistic example, a Texture, I used to do:

class Texture
{
public:
    Texture(GraphicsDevice &graphics);

    void load(const std::string &path);

private:
    GraphicsDevice *graphics;
};

I've come to prefer:

class Texture
{
public:
    Texture();

    void load(GraphicsDevice &graphics, const std::string &path);
};

I'd be hard pressed to say exactly why I find this easier to deal with and maintain if I'm honest but over the course of an entire system, it feels cleaner to me. Since I can't actually identify clear reasons, this may be me being superstitious.

EDIT: Suppose one thing I like is I'm not hiding dependancies. I.e. with approach 1, if I pass a Texture around I am silently and invisibly passing a GraphicsDevice around as well. With the second approach, this is explicit and so easier to track where the GraphicsDevice object is moving to. Bit moot if the Texture interface never exposes the GraphicsDevice though to be fair.

In your case, you might want to consider NOT requiring ConstantBuffer to have an initialized device in the constructor. I would then defer the initialization to "init" methods. Something like:

// headers

class Renderer {
private:
    ID3D11Device* device;
    ConstantBuffer cbuffer;
public:
    bool init();
}
 
class ConstantBuffer {
public:
    ConstantBuffer();
    bool init(ID3D11Device* device);
}

// cpps
void Renderer::init() {
 // inialize ID3D11Device
 // ...
 cbuffer.init( device );
 // ...
}

void ConstantBuffer::init() {
  // ...
}
 

This gives you some flexibility when dealing with errors, for example. The only way a constructor can notify errors is by throwing exceptions, but you may not want to use them (either now or a in a future port). Having a init method let you fail via exceptions or via returning error values.

Having a separate init method also let you re-initialization, which you may want in the future.

This design pattern, by the way, is called Two-Phase Construction: http://developer.nokia.com/community/wiki/Two-phase_construction.

The only way a constructor can notify errors is by throwing exceptions, but you may not want to use them (either now or a in a future port). Having a init method let you fail via exceptions or via returning error values.

You can return an error value from a constructor through an out-parameter.

Emmm, yep, I completely forgot about that one. The problem is that you still end up with a messed up object resulting from calling the constructor, but it is in a permanent uninitialized state. With two-phase construction at least you can go from uninitialized to initialized via the init method :)

Regadless, I am with you that the best constructor is one which simply cannot fail :) I like your method if encapsulating Direct3D in the API is not the point of Renderer and ConstantBuffer...

I'd be hard pressed to say exactly why I find this easier to deal with and maintain if I'm honest but over the course of an entire system, it feels cleaner to me.