Policy classes for making widgets

I have been learning C++ for the past few weeks, and I made my first try with policy classes. Ultimately my goal is to use policy classes to manufacture wrapper classes on an std::vector. Part of what the wrapper class does is generate a custom allocator class that depends on the policy classes.

That's the inspiration for what I have below, which is a widget maker that makes widgets with a printing function that depends on the templated inputs.

Printing policy classes:

template 
struct Chatty
{
  static void logVal(T val){
    std::cout 
struct Silent
{
  static void logVal(T val){}
  static void logS(std::string s){}
};

Widget:

class Widget {
public:
  int x;
  int y;
  std::function print;
  Widget()
    :x(0), y(0), print([](std::string){})
  {};
};

WidgetManager:

template  class CreationPolicy, template  class LoggingPolicy>
class WidgetManager : public CreationPolicy, public LoggingPolicy
{
public:
  WidgetManager() {};
  static Widget* doAll(){
    Widget* w = WidgetManager::Create();
    std::function f1 = WidgetManager::logS;
    w->print = WidgetManager::logS;
    return w;
  }
};

I would appreciate feedback on all aspects of the code, but I also have two specific questions:

• My biggest concern: is there a better way to assign functions to the Widgets I am making? For example, perhaps I could directly assign member functions of Widgets from my WidgetManager, but then I'd have to bind the WidgetMaker's static functions to individual instances of Widgets, which seems like more overhead. What's best performance-wise?

• I am sure WidgetManager::doAll() is not the way to go, but I am struggling to find another way to call functions from various policies all together. What's a better way to do this?

In Widget, the members x and y should be private. They should not be exposed to the interface in such a way. You can either add the private keyword above them, or just move the public keyword below them (members are private by default, so both are essentially the same).

StackExchange Code Review Q#98708, answer score: 3