It is generally inappropriate for a library writer to force smart pointer semantics on consumers of a public library. It's more inappropriate to obscure that via typedef.

I think that an important thing to accomplish in any API is to separate the interface from the implementation. One way of doing this is through the pimpl idiom. Another way is through the use of Interfaces, which are essentially Pure Abstract Classes. I like this approach a lot, because it allows for late binding and completely hides implementation (keep those public header files light and devoid of implementation details).

Example:


//Window.h - part of the public API

class IWindow
{
public:
static IWindow* New(int width, int height);
virtual ~IWindow() {}
virtual void setSize(int width, int height) = 0;
virtual void setTitle(const std::string& title) = 0;
}; //notice no implementation details here

//MyWindowImpl.h - private header

#include "Window.h"
class MyWindowImpl : public IWindow
{
public:
MyWindowImpl(int width, int height);
void setSize(int width, int height);
void setTitle(const std::string& title);
};

//Window.cpp - code file, not a part of the public API

#include "Window.h"
#include "MyWindowImpl.h"

IWindow* IWindow::New(int width, int height)
{
//we could dynamically choose which type of window to return
return new MyWindowImpl(int width, int height);
}

//example usage

#include "Widnow.h"

int main()
{
IWindow* wnd = IWindow::New(640, 480);
wnd->setTitle("Hello, World!");
delete wnd;
}


That's great, because the only thing the user need be exposed to is the interface. However, the one disadvantage is that you are stuck with pointers. I think most modern C++ programmers try to avoid pointers as much as possible. The STL for example, is an API mostly devoid of pointers. We don't create pointers to string or stream objects after all. I think most programmers expect a good modern API to have value semantics similar to:


int main()
{
Window wnd(640, 480);
wnd.setTitle("Hello, World!");
}


They want to be able to create their objects on the stack and benefit from RAII. Wouldn't it be nice if we could have our cake and eat it too? One solution would be to use smart pointers. We could do this instead:


//Window.h
class IWindow
{
public:
typedef std::shared_ptr<IWindow> Ptr;
...
}

//example

int main()
{
IWindow::Ptr wnd(IWindow::New(640, 480));
wnd->setTitle("Hello, World!");
}


You still have pointer semantics, but at least you don't have to worry about managing it's lifetime. However, I was working on a slightly different approach which may bring the it a bit closer to value semantics.


//Window.h

#include "SmartRef.h"

class IWindow
{
public:
virtual ~IWindow() {}
virtual void setSize(int width, int height) = 0;
virtual void setTitle(const std::string& title) = 0;
}; //very clean interface definition

typedef SmartRef<IWindow, int, int> Window;


//SmartRef.h

template <class T, class... InitArgs>
class SmartRef
{
public:
typedef SmartRef<T, InitArgs...> ref_type;
static ref_type New(InitArgs...) {}
SmartRef(InitArgs... args)
{
*this = ref_type::New(args...);
}
SmartRef(T* ptr)
: _ptr(ptr)
{}
T* operator->() { return _ptr.get(); }
private:
std::shared_ptr<T> _ptr;
};


//Window.cpp

#include "MyWindowImpl.h"

template<>
Window Window::New(int width, int height)
{
return new MyWindowImpl(width, height);
}


//example usage

#include "Window.h"

int main()
{
Window wnd(640, 480); //alternatively Window wnd = Window::New(640, 480);
wnd->setTitle("Hello, World!");
}


You are still stuck using the pointer operator, but everything else about it is like value semantics. These semantics look similar to Google's V8 API.

What exactly are your thoughts?

There is nothing wrong with pointer use for polymorfic types it often makes it clearer that the type could be a derived type instead of the base class.

Also use a factory to create these class and the user neednt even see the implementations of the concrete types.

Virtual interfaces irk me when they're actually not required. Reference-counted pointers also irk me when there's one logical owner (if it's acting like a value on [font="'Courier New"]main[/font]'s stack, it should be destructed when [font="'Courier New"]main[/font] unrolls - no need to ref-count in such a case).
My preferred re-write, as food-for-thought:[source lang=cpp]//Window.h
class Window
{
public:
static Window* New(int width, int height);
static void Delete(Window*);
void setSize(int width, int height);
void setTitle(const std::string& title);
private:
friend class MyWindowImpl;
Window(){}
~Window(){}
Window(const Window&);
Window& operator=(const Window&);
};


//MyWindowImpl.h - private header, not a part of the public API
#include "Window.h"
class MyWindowImpl : public Window
{
public:
MyWindowImpl(int width, int height);
void setSize(int width, int height);
void setTitle(const std::string& title);
};


//Window.cpp - code file, not a part of the public API
#include "MyWindowImpl.h"

Window* Window::New(int width, int height)
{
return new MyWindowImpl(int width, int height);
}
void Window::Delete(Window* p)
{
delete (MyWindowImpl*)p;
}

MyWindowImpl& Cast(Window* p) { return *(MyWindowImpl*)p; }
void Window::setSize(int width, int height) { Cast(this).setSize(width, height); }
void Window::setTitle(const std::string& title) { Cast(this).setTitle(title); }


//MyPointerHelpers.h
tempalte<class T>
class AutoPointer
{
public:
AutoPointer() : m_ptr() {}
~AutoPointer() { T::Delete(m_ptr); }
//todo - the usual constructors and operators here
private:
T* m_ptr;
};


//example
int main()
{//choice of pointer type is not coupled with the Window class. In this case, I'll use a single-owner RAII pointer.
AutoPointer<Window> wnd = Window::New(640, 480);
wnd->setTitle("Hello, World!");
}[/source]Also, if I was writing this in my own engine, I'd pass an allocator into [font="Courier New"]Window::New[/font] instead of using [font="Courier New"]new[/font]/[font="Courier New"]delete[/font], so that the allocation region isn't as coupled with the Window class (e.g. allowing it to actually be allocated on [font="'Courier New"]main[/font]'s stack like a regular local value).