如何正确实现C++中的工厂方法模式

How to implement the factory method pattern in C++ correctly

C++中有一件事情让我感到很不舒服，因为我真的不知道怎么做，尽管听起来很简单：

如何正确实现C++中的工厂方法？

目标：使客户机能够使用工厂方法而不是对象的构造函数来实例化一些对象，而不会造成不可接受的后果和性能损失。

"工厂方法模式"是指对象内的静态工厂方法或在另一个类中定义的方法，或全局函数。一般来说，"将类X的正常实例化方法重定向到构造函数之外的任何地方的概念"。

让我浏览一下我想到的一些可能的答案。

0)不做工厂，做施工员。

这听起来不错(而且往往是最好的解决方案)，但不是一般的补救办法。首先，有些情况下，对象构造是一个足够复杂的任务，足以证明将其提取到另一个类中是正确的。但即使将这一事实放在一边，即使对于仅使用构造函数的简单对象，通常也做不到。

我知道的最简单的例子是二维向量类。这么简单，但又很棘手。我想能够用笛卡尔坐标和极坐标来构造它。显然，我不能：

1
2
3
4
5

struct Vec2 {
Vec2(float x, float y);
Vec2(float angle, float magnitude); // not a valid overload!
// ...
};

我的自然思维方式是：

1
2
3
4
5

struct Vec2 {
static Vec2 fromLinear(float x, float y);
static Vec2 fromPolar(float angle, float magnitude);
// ...
};

这将导致我使用静态工厂方法，而不是构造函数…这实质上意味着我正在以某种方式实现工厂模式("类成为它自己的工厂")。这看起来不错(并且适合这个特定的情况)，但在某些情况下失败了，我将在第2点中描述。继续阅读。

另一种情况是：试图通过某些API的两个不透明的typedef(例如不相关域的guid或guid和bitfield)进行重载，类型在语义上完全不同(理论上是有效的重载)，但事实证明它们是相同的，如无符号int或void指针。

1)Java方式

Java之所以简单，是因为我们只有动态分配的对象。制造工厂就像：

1
2
3
4
5
6
7
8

class FooFactory {
public Foo createFooInSomeWay() {
// can be a static method as well,
// if we don't need the factory to provide its own object semantics
// and just serve as a group of methods
return new Foo(some, args);
}
}

在C++中，翻译成：

1
2
3
4
5
6

class FooFactory {
public:
Foo* createFooInSomeWay() {
return new Foo(some, args);
}
};

Cool？的确如此。但是-这迫使用户只使用动态分配。静态分配是C++复杂的原因，也是经常使它强大的原因。另外，我认为存在一些不允许动态分配的目标(关键字：embedded)。这并不意味着这些平台的用户喜欢编写干净的OOP。

不管怎样，哲学除外：在一般情况下，我不想强迫工厂的用户受到动态分配的限制。

2)按值返回

好的，所以我们知道1)当我们需要动态分配时很酷。为什么不在上面添加静态分配呢？

1
2
3
4
5
6
7
8
9

class FooFactory {
public:
Foo* createFooInSomeWay() {
return new Foo(some, args);
}
Foo createFooInSomeWay() {
return Foo(some, args);
}
};

什么？返回类型不能超载？哦，当然我们不能。所以让我们更改方法名来反映这一点。是的，我写了上面的无效代码示例，只是为了强调我有多不喜欢更改方法名的需要，例如，因为我们现在不能正确地实现语言不可知的工厂设计，因为我们必须更改名称-而且此代码的每个用户都需要记住实现与特定。

1
2
3
4
5
6
7
8
9

class FooFactory {
public:
Foo* createDynamicFooInSomeWay() {
return new Foo(some, args);
}
Foo createFooObjectInSomeWay() {
return Foo(some, args);
}
};

好啊。。。我们找到了。它很难看，因为我们需要更改方法名。这是不完美的，因为我们需要写两次相同的代码。但一旦完成，它就会起作用。对吗？

嗯，通常是这样。但有时不是。在创建FoO时，我们实际上依赖于编译器对我们进行返回值优化，因为C++标准对编译器厂商来说是足够仁慈的，而不必指定对象在什么时候被创建，以及何时在C++中以值返回临时对象时将被复制。因此，如果FOO的复制成本很高，这种方法是有风险的。

如果foo根本不可复制怎么办？哦，多哈。(请注意，在C++ 17中，保证复制删除，不可复制对于上面的代码不再是问题)

结论：对于某些情况(如前面提到的二维向量)，通过返回对象来创建工厂确实是一种解决方案，但仍然不是一般的构造函数替换。

3)两相施工

另一个可能会被人想到的事情是分离对象分配和初始化的问题。这通常会导致如下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Foo {
public:
Foo() {
// empty or almost empty
}
// ...
};

class FooFactory {
public:
void createFooInSomeWay(Foo& foo, some, args);
};

void clientCode() {
Foo staticFoo;
auto_ptr<Foo> dynamicFoo = new Foo();
FooFactory factory;
factory.createFooInSomeWay(&staticFoo);
factory.createFooInSomeWay(&dynamicFoo.get());
// ...
}

人们可能会认为它很有魅力。我们在代码中支付的唯一价格…

既然我写了这一切，把它留作最后一个，我也一定不喜欢它。为什么？

首先…我真的不喜欢两阶段结构的概念，当我使用它的时候我感到内疚。如果我设计对象时断言"如果它存在，它就处于有效状态"，那么我觉得我的代码更安全，更不容易出错。我喜欢那样。<

相关讨论

stackoverflow.com/questions/4992307/&hellip；副本
@扎克，虽然题目很相似，但实际问题是不一样的。
很好的副本，但这个问题的文本本身是有价值的。
是否不需要私有构造函数？回想一下这个问题，我认为封装对象创建的最佳方法是使用单独的管理器类，它是私有构造函数的朋友。这将迫使任何外部对象通过管理器拥有的工厂功能。
@赛利比策——不，更确切地说，"来吧，你是这样一个各自的汽车品牌，为什么我找不到一辆没有坏掉的车呢？他们在其他地方都卖好车，我也希望你也能这样。
我认为您的第一个示例实际上是描述"命名构造函数"习惯用法，而不是工厂模式(en.wikibooks.org/wiki/more_c%2b%2b_习惯用法/named_constructor&zwnj；&8203；)
"彼得，"DMCKE:我同意这个问题是更彻底的，但是，本质上是一样的问题："我如何正确地使用C++中的工厂设计模式？"
@扎克：我的观点是，这个问题应该保持未删除和未合并，即使它作为一个副本关闭。
嗯，你不是想说：foo*foofactory:：CreateDynamicFooinsomeway()；foo foofactory:：CreateStaticFooinsomeway())
我冒昧地改变了原来问题中的例子。我本来打算调用第二个createStaticFoointSomeWay()，但这不是正确的-它更像是createDynamicCallyalLocatedFoointSomeWayAnderTurnPtr()和createFoovalueandRetrCopy()，但这些太冗长了。(如果这类事情有一个标准的命名约定，我想听听。)
@Krazyglew谢谢你的编辑，这是一个很好的捕捉。
在问了两年之后，我还有几点要补充：1)这个问题与几个设计模式有关([摘要]工厂、构建器，您可以命名它，我不喜欢钻研它们的分类法)。2)这里讨论的实际问题是"如何将对象存储分配与对象构造完全分离？".
UM，你是第2段)不描述EDOCX1 0分配，它是堆栈分配，AKA本地，又名EDCOX1 1×C++
您在C++中提供的动态分配选项不会创建内存泄漏吗？
@丹尼斯：只有当你不这样做的时候。只要调用者拥有指针的所有权(读：在适当的时候负责删除它)，这种方法就非常好。
@boris@dennis你也可以通过返回一个unique_ptr而不是T*来非常明确。
我不明白在不使用指针的情况下工厂的意义是什么：如果不使用指针(因此也不使用多态性)，那么在编写代码时必须知道具体的类型。那你为什么需要一个工厂呢？如果你想把(堆栈)对象塞进一个指针，那么，这有点复杂，我不知道它在哪里/什么时候有用(尽管，永远不要说永远)。
@Bartgol我发现自己处于这个位置，因为我想统一测试一个类，它在它的一些方法中创建对象，而我没有任何堆。所以我需要堆栈分配，我需要能够根据生产代码还是测试代码来改变类型。

First of all, there are cases when
object construction is a task complex
enough to justify its extraction to
another class.

我认为这一点是错误的。复杂性并不重要。相关性就是它的作用。如果一个对象可以在一个步骤中构造(不像在构建器模式中那样)，那么构造器就是正确的地方。如果您确实需要另一个类来执行该作业，那么它应该是一个从构造函数使用的助手类。

1 2	Vec2(float x, float y); Vec2(float angle, float magnitude); // not a valid overload!

有一个简单的解决方法：

1
2
3
4
5
6
7
8
9
10

struct Cartesian {
inline Cartesian(float x, float y): x(x), y(y) {}
float x, y;
};
struct Polar {
inline Polar(float angle, float magnitude): angle(angle), magnitude(magnitude) {}
float angle, magnitude;
};
Vec2(const Cartesian &cartesian);
Vec2(const Polar &polar);

唯一的缺点是它看起来有点冗长：

1	Vec2 v2(Vec2::Cartesian(3.0f, 4.0f));

但好的是，您可以立即看到正在使用的坐标类型，同时不必担心复制。如果您想要复制，而且复制成本很高(当然，通过分析可以证明这一点)，那么您可能希望使用类似qt的共享类来避免复制开销。

至于分配类型，使用工厂模式的主要原因通常是多态性。构造器不能是虚拟的，即使可以，也没有什么意义。使用静态或堆栈分配时，不能以多态方式创建对象，因为编译器需要知道确切的大小。所以它只适用于指针和引用。从工厂返回一个引用也不起作用，因为虽然技术上的对象可以通过引用来删除，但是它可能相当混乱和容易出错，参见返回C++引用变量的做法吗？例如。所以指针是唯一剩下的东西，也包括智能指针。换句话说，工厂在与动态分配一起使用时最有用，因此您可以这样做：

1
2
3
4
5
6
7
8
9
10
11
12
13

class Abstract {
public:
virtual void do() = 0;
};

class Factory {
public:
Abstract *create();
};

Factory f;
Abstract *a = f.create();
a->do();

在其他情况下，工厂只是帮助解决一些小问题，比如那些你提到过的过载问题。如果能以统一的方式使用它们，那就太好了，但这可能是不可能的，这并不会造成太大的伤害。

相关讨论

+1表示笛卡尔和极性结构。一般来说，最好创建直接表示其预期数据的类和结构(而不是一般的vec结构)。您的工厂也是一个很好的例子，但是您的例子并不能说明谁拥有指针"a"。如果工厂"f"拥有它，那么当"f"离开作用域时，它可能会被破坏，但是如果"f"不拥有它，开发人员必须记住释放内存，否则会发生内存泄漏。
当然，对象可以通过引用删除！请参阅stackoverflow.com/a/752699/404734，如果通过引用返回动态内存是明智的，当然会引发这样的问题，因为通过复制可能分配返回值的问题(当然，调用方也可以执行int a=*returnsionIntertoInt()之类的操作，然后会遇到同样的问题，如果动态allcoaTED内存会被返回，就像引用一样，但是在指针版本中，用户必须显式地取消引用，而不是仅仅忘记显式引用，这是错误的)。
@凯瑟鲁迪，说得好。我没想到，但这仍然是一种"邪恶"的做事方式。编辑了我的答案以反映这一点。
如何创建不同的不可变的非多态类？工厂模式是否适合在C++中使用？
@daaxix，为什么需要工厂来创建非多态类的实例？我不明白不可变性与这些有什么关系。
@Sergeytachenov假设我们需要复杂不可变类的不同(但不是多态)实例。一旦用所需的属性实例化了一个类，就不能再更改它了。工厂(或类似工厂的助手函数/类)在这里似乎很适合，当类的细节很复杂时简化不可变的类创建，并且必须在初始化时全部设置。有更好的方法吗？
@daaxix，如果不能用构造函数完成，那么工厂，或者更确切地说是构建器模式，是正确的方法。如果可以用构造函数来完成，那么最好用构造函数来完成。我不知道把一个构造函数变成一个噩梦有多复杂。
我不喜欢笛卡尔/极性结构的解。向量是相同的，不管表示是什么，实现向量的添加或复制都需要笛卡尔、笛卡尔极性、极性笛卡尔和极性极性重载，这会很麻烦。
@凯文，我只建议引入不同的构造器来避免"无效的重载"问题。一旦构造了一个向量，它仍然是相同的，那么为什么需要不同的重载来进行复制或添加呢？当时，人们甚至不知道在施工时使用了什么表示法！把Vec2(Cartesian(x, y))看作一种表示坐标系的句法糖。在为子类编写构造函数时，您只需要不同的重载，但为此目的，它仍然优于工厂方法。
哦，糟透了。我误解了你的解决办法。您只需要在vec2对象的构造中使用极性和笛卡尔对象。我以为你在建议两个独立的类——极坐标和笛卡尔坐标——基本上都实现了vec2的接口，或者类似的东西。现在我明白了，我更喜欢你的解决方案-对不起。
您可以简单地执行"typedef float angle"并在有效重载中使用它，而不是创建新的结构。在这种情况下似乎很奇怪，因为您必须在构造函数调用中静态转换，但在其他情况下可能很好。(例如，如果原始类型如此复杂，以至于无论如何都要使用局部变量。
@普库比，这是行为标准吗？我认为typedef只是别名，与重载无关，而且大多数编译器都将该类型视为原始类型。事实上，我刚刚在MSVs2013中尝试过，它在第二个构造函数上给出了member function already defined or declared错误，即使我没有尝试实际使用构造函数。
@谢尔盖·塔奇诺夫，我的错，你是对的。我不知道我怎么会犯这样的错误。不管怎样，您可以通过使用一个采用float和float-cast运算符的构造函数来声明类来模拟const-strong typedef。还要注意，指定一个单位包装可以与C++ 11自定义文字一起使用。
很好，很自然。一旦定义了Polar和Cartesian，我首先要问的问题是"现在vec2类有什么好处？"
@凯文：相反，我主张使用Polar和Cartesian来代替Vec2。基本上，除了数学运算(通过重载类型的运算符)、相互转换(通过定义转换运算符)、规范(通过定义单个重载的自由函数)之外，与Vec2没有太多的接口。重载是C++的一部分，如果其他类型的话，它将充当一个大的隐形编译时间。运算符重载和隐式/显式转换也是C++的一部分。它们是添加到C++中的特性。我们不应该和语言作斗争。

简单工厂示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// Factory returns object and ownership
// Caller responsible for deletion.
#include <memory>
class FactoryReleaseOwnership{
public:
std::unique_ptr<Foo> createFooInSomeWay(){
return std::unique_ptr<Foo>(new Foo(some, args));
}
};

// Factory retains object ownership
// Thus returning a reference.
#include <boost/ptr_container/ptr_vector.hpp>
class FactoryRetainOwnership{
boost::ptr_vector<Foo> myFoo;
public:
Foo& createFooInSomeWay(){
// Must take care that factory last longer than all references.
// Could make myFoo static so it last as long as the application.
myFoo.push_back(new Foo(some, args));
return myFoo.back();
}
};

相关讨论

-1用于使用智能指针
@卢卡斯1985：为什么？
@因为使用智能指针是释放对内存控制的最简单方法。与其他语言相比，C/C++语言的控制是最高的，从中获得最大的优势。没有提到智能指针产生类似于其他托管语言的内存开销的事实。如果您希望在Java或C语言中实现自动内存管理的启动编程，但不要把这些乱糟糟的东西放入C/C++中。
关于在工厂里有一个装有物品的容器的非常有趣的想法
@Lukasz1985该示例中的unique_ptr没有性能开销。管理资源，包括内存，是C++在任何其他语言上的最大优势之一，因为你可以在没有失去控制的情况下做到这一点，而不会失去控制，但你恰恰相反。有些人不喜欢C++所隐含的东西，比如通过智能指针来进行内存管理，但是如果你想要的东西是明确的，那么就要使用C；权衡是数量级更少的问题。我认为你否决一项好建议是不公平的。
@埃德马斯特：我以前没有回应，因为他显然是在捣乱。请不要喂巨魔。
@他可能是个巨魔，但他说的话可能会让人困惑。
顺便说一下，在保留引用示例中，用C++ 11也可以通过EDCOX1×2加上很少的相应的修改来替换EDCOX1×1。
刘：是的。但是：boost::ptr_vector<>的效率稍微高一点，因为它知道它拥有指针，而不是将工作委托给子类。但是boost::ptr_vector<>的主要优点是它通过引用(而不是指针)暴露其成员，因此在标准库中很容易与算法一起使用。
我现在有一个问题，我试图成为一个好的编码人员，并返回了一个唯一的_ptr，但是在代码的后面，我们需要动态地将其转换为派生类型，至少有时是这样。最后，动态铸造一个独特的指针并不意味着一个可行的事情。所以…难题。它在VC100中使用stackoverflow中的一个列表工作，但之后就不工作了。
@克里斯托弗：这就是你要找的吗？如何使用唯一的指针执行动态强制转换
@LokuAstari是的，我去过那个页面，但是Jarod的答案是不安全的，当演员失败时会泄露，Sehe的答案甚至没有在VC140中编译。我用我在注释中留下的代码克服了这个问题，从那以后我得到了他的答案。

你有没有想过不使用工厂，而是好好利用类型系统？我可以想到两种不同的方法来做这种事情：

选项1：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

struct linear {
linear(float x, float y) : x_(x), y_(y){}
float x_;
float y_;
};

struct polar {
polar(float angle, float magnitude) : angle_(angle), magnitude_(magnitude) {}
float angle_;
float magnitude_;
};

struct Vec2 {
explicit Vec2(const linear &l) { /* ... */ }
explicit Vec2(const polar &p) { /* ... */ }
};

它可以让你写一些东西，比如：

1	Vec2 v(linear(1.0, 2.0));

选项2：

您可以像STL对迭代器等使用"标记"。例如：

1
2
3
4
5
6
7

struct linear_coord_tag linear_coord {}; // declare type and a global
struct polar_coord_tag polar_coord {};

struct Vec2 {
Vec2(float x, float y, const linear_coord_tag &) { /* ... */ }
Vec2(float angle, float magnitude, const polar_coord_tag &) { /* ... */ }
};

第二种方法允许您编写如下所示的代码：

1	Vec2 v(1.0, 2.0, linear_coord);

它也很好，表达能力也很强，同时允许您为每个构造函数拥有独特的原型。

您可以在http://www.codeproject.com/articles/363338/factory-pattern-in-cplusplus中阅读一个非常好的解决方案。

最好的解决方案是"评论和讨论"，参见"不需要静态创建方法"。

基于这个想法，我做了一个工厂。请注意，我使用的是qt，但是您可以更改qmap和qstring作为std等价物。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#ifndef FACTORY_H
#define FACTORY_H

#include <QMap>
#include <QString>

template <typename T>
class Factory
{
public:
template <typename TDerived>
void registerType(QString name)
{
static_assert(std::is_base_of<T, TDerived>::value,"Factory::registerType doesn't accept this type because doesn't derive from base class");
_createFuncs[name] = &createFunc<TDerived>;
}

T* create(QString name) {
typename QMap<QString,PCreateFunc>::const_iterator it = _createFuncs.find(name);
if (it != _createFuncs.end()) {
return it.value()();
}
return nullptr;
}

private:
template <typename TDerived>
static T* createFunc()
{
return new TDerived();
}

typedef T* (*PCreateFunc)();
QMap<QString,PCreateFunc> _createFuncs;
};

#endif // FACTORY_H

样品使用情况：

1
2
3
4
5
6
7

Factory<BaseClass> f;
f.registerType<Descendant1>("Descendant1");
f.registerType<Descendant2>("Descendant2");
Descendant1* d1 = static_cast<Descendant1*>(f.create("Descendant1"));
Descendant2* d2 = static_cast<Descendant2*>(f.create("Descendant2"));
BaseClass *b1 = f.create("Descendant1");
BaseClass *b2 = f.create("Descendant2");

我主要同意所接受的答案，但是有一个C++ 11选项，在现有的答案中没有被覆盖：

按值返回工厂方法结果，以及
提供廉价的移动构造函数。

例子：

1
2
3
4
5
6
7
8

struct sandwich {
// Factory methods.
static sandwich ham();
static sandwich spam();
// Move constructor.
sandwich(sandwich &&);
// etc.
};

然后可以在堆栈上构造对象：

1	sandwich mine{sandwich::ham()};

作为其他事物的子对象：

1	auto lunch = std::make_pair(sandwich::spam(), apple{});

或动态分配：

1	auto ptr = std::make_shared<sandwich>(sandwich::ham());

我什么时候可以用这个？

如果在公共构造函数上，不经过初步计算就无法为所有类成员提供有意义的初始化器，那么我可以将该构造函数转换为静态方法。静态方法执行初步计算，然后通过一个私有构造函数返回一个值结果，该构造函数只执行成员初始化。

我之所以说"可能"，是因为它取决于哪种方法可以提供最清晰的代码，而不会产生不必要的效率低下。

相关讨论

Loki既有工厂方法，也有抽象工厂。两种都被广泛记录在现代C++设计中，由Andei Alexandrescu。factory方法可能更接近于您所追求的，尽管它仍然有点不同(至少在内存可用的情况下，它要求您先注册一个类型，然后factory才能创建该类型的对象)。

相关讨论

我不想回答我所有的问题，因为我认为这太宽泛了。只是几条注释：

there are cases when object construction is a task complex enough to justify its extraction to another class.

这个类实际上是一个构建者，而不是一个工厂。

In the general case, I don't want to force the users of the factory to be restrained to dynamic allocation.

然后你可以让你的工厂用一个智能指针来封装它。我相信这样你就可以吃蛋糕了。

这也消除了与按值返回相关的问题。

Conclusion: Making a factory by returning an object is indeed a solution for some cases (such as the 2-D vector previously mentioned), but still not a general replacement for constructors.

的确。所有设计模式都有其(语言特定的)约束和缺点。建议仅在它们帮助您解决问题时使用它们，而不是为了它们自己。

如果你是经过"完美"工厂实施的，那么，祝你好运。

相关讨论

这是我的C++ 11风格的解决方案。参数"base"用于所有子类的基类。创建者是用于创建子类实例的std:：function对象，可能是与子类"static member function"create(某些参数)的绑定。这也许不完美，但对我有用。这是一种"通用"的解决方案。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

template <class base, class... params> class factory {
public:
factory() {}
factory(const factory &) = delete;
factory &operator=(const factory &) = delete;

auto create(const std::string name, params... args) {
auto key = your_hash_func(name.c_str(), name.size());
return std::move(create(key, args...));
}

auto create(key_t key, params... args) {
std::unique_ptr<base> obj{creators_[key](args...)};
return obj;
}

void register_creator(const std::string name,
std::function<base *(params...)> &&creator) {
auto key = your_hash_func(name.c_str(), name.size());
creators_[key] = std::move(creator);
}

protected:
std::unordered_map<key_t, std::function<base *(params...)>> creators_;
};

使用示例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

class base {
public:
base(int val) : val_(val) {}

virtual ~base() { std::cout <<"base destroyed
"; }

protected:
int val_ = 0;
};

class foo : public base {
public:
foo(int val) : base(val) { std::cout <<"foo" << val <<"
"; }

static foo *create(int val) { return new foo(val); }

virtual ~foo() { std::cout <<"foo destroyed
"; }
};

class bar : public base {
public:
bar(int val) : base(val) { std::cout <<"bar" << val <<"
"; }

static bar *create(int val) { return new bar(val); }

virtual ~bar() { std::cout <<"bar destroyed
"; }
};

int main() {
common::factory<base, int> factory;

auto foo_creator = std::bind(&foo::create, std::placeholders::_1);
auto bar_creator = std::bind(&bar::create, std::placeholders::_1);

factory.register_creator("foo", foo_creator);
factory.register_creator("bar", bar_creator);

{
auto foo_obj = std::move(factory.create("foo", 80));
foo_obj.reset();
}

{
auto bar_obj = std::move(factory.create("bar", 90));
bar_obj.reset();
}
}

我知道这个问题3年前就已经被回答过了，但这可能是你想要的。

几周前，谷歌发布了一个库，允许轻松灵活的动态对象分配。这里是：http://google-opensource.blogspot.fr/2014/01/introducing-infact-library.html

工厂模式

1
2
3
4
5
6

class Point
{
public:
static Point Cartesian(double x, double y);
private:
};

如果编译器不支持返回值优化，那么放弃它，它可能根本不包含太多优化…

相关讨论