我刚进入一个新公司，很多代码库都使用初始化方法而不是构造函数。
struct MyFancyClass : theUberClass
{
MyFancyClass();
~MyFancyClass();
resultType initMyFancyClass(fancyArgument arg1, classyArgument arg2,
redundantArgument arg3=TODO);
// several fancy methods...
};
他们告诉我这与时间有关。一些事情必须在构造函数之后完成，否则会失败。但大多数构造函数都是空的，我真的看不到不使用构造函数的理由。
所以我向你们这些C++巫师求助：为什么要使用init方法而不是构造函数？
他们说"timing"，我想是因为他们希望它们的init函数能够调用对象上的虚拟函数。这在构造函数中并不总是有效，因为在基类的构造函数中，派生类部分的对象“尚不存在”，特别是您无法访问派生类中定义的虚拟函数。相反，如果定义了函数，则调用函数的基类版本。如果未定义（暗示该函数是纯虚函数），则会出现未定义的行为。
另一个常见的原因是希望避免异常，但这是一种相当老式的编程风格（它是否是一个好主意是一个完全独立的争论）。这与构造函数无法返回错误值的事实有关，如果出现错误，构造函数不能返回错误值。因此，就你的同事给你的真正原因而言，我怀疑这不是这个原因。
是的，我可以想到几种方式，但通常这不是一个好主意。
大多数情况下，被提出的原因是你只能通过构造函数报告异常（这是正确的），而使用经典方法可以返回错误代码。
然而，在设计良好的面向对象代码中，构造函数负责建立类不变式。允许默认构造函数会创建一个空类，因此必须修改不变式以使其接受“null”类和“有意义”的类...并且每次使用类之前都必须确保对象已经被正确构建...这很困难。
那么现在，让我们解构一下这些“理由”：
总之，总体来说，这是一个不好的主意。如果你真的想要“void”构造函数，请将它们设为私有，并使用Builder方法。它和NRVO一样有效...并且你可以在构造失败的情况下返回boost :: optional<FancyObject>。
operator =”。 - Steve Jessopvector对象上的assign方法：通过使用assign，您可以重复使用已分配的存储空间，因此不需要进行虚假的内存分配。但是正确地执行它很棘手，因此我同意在一般情况下应该使用复制和交换。 - Matthieu M.其他人列举了很多可能的原因（并对为什么大多数这些不是一个好主意进行了适当的解释）。让我发表一个关于时间安排更或少是有效使用初始化方法的实例。
在以前的项目中，我们有很多服务类和对象，每个都是层次结构的一部分，并以各种方式相互交叉引用。因此，通常情况下，要创建ServiceA，您需要父服务对象，而父服务对象又需要服务容器，后者已依赖于初始化时存在某些特定服务（可能包括ServiceA本身）。原因是在初始化期间，大多数服务都将自己注册为特定事件的监听器，并/或通知其他服务有关成功初始化事件的信息。如果其他服务在通知时不存在，则不会发生注册，因此该服务将在应用程序使用期间无法接收到重要的消息。为了打破循环依赖链，我们必须使用显式的初始化方法与构造函数分开，从而有效地使全局服务初始化成为一个两阶段过程。
因此，尽管通常情况下不应遵循此惯用法，但在我看来它具有一些有效的用途。但是，最好将其用法限制在最小范围内，尽可能使用构造函数。在我们的情况下，这是一个遗留项目，我们还没有完全理解它的架构。至少使用init方法的用法仅限于服务类 - 常规类是通过构造函数初始化的。我相信可能有一种重构该架构以消除需要服务init方法的方法，但是至少我没有看到如何做到（坦率地说，在我参与该项目时，我们有更紧迫的问题要处理）。
我能够想到的两个原因：
当你的编译器不支持异常，或者你的目标应用程序无法使用堆（通常使用堆来创建和销毁异常），init()函数是一个很好的选择。
如果需要定义构造顺序，init()例程也很有用。也就是说，如果全局分配对象，构造函数调用的顺序是未定义的。例如：
[file1.cpp]
some_class instance1; //global instance
[file2.cpp]
other_class must_construct_before_instance1; //global instance
还有我想附上一个代码示例来回答问题 #1 --
因为MSDN也说：
当调用虚方法时，实际执行方法的类型直到运行时才会选择。当构造函数调用虚方法时，可能尚未执行调用该方法的实例的构造函数。
示例：以下示例演示违反此规则的影响。测试应用程序创建DerivedType的一个实例，导致其基类（BadlyConstructedType）构造函数执行。 BadlyConstructedType的构造函数不正确地调用了虚方法DoSomething。 正如输出所示，DerivedType.DoSomething()将执行，并且在DerivedType的构造函数执行之前执行。
using System;
namespace UsageLibrary
{
public class BadlyConstructedType
{
protected string initialized = "No";
public BadlyConstructedType()
{
Console.WriteLine("Calling base ctor.");
// Violates rule: DoNotCallOverridableMethodsInConstructors.
DoSomething();
}
// This will be overridden in the derived type.
public virtual void DoSomething()
{
Console.WriteLine ("Base DoSomething");
}
}
public class DerivedType : BadlyConstructedType
{
public DerivedType ()
{
Console.WriteLine("Calling derived ctor.");
initialized = "Yes";
}
public override void DoSomething()
{
Console.WriteLine("Derived DoSomething is called - initialized ? {0}", initialized);
}
}
public class TestBadlyConstructedType
{
public static void Main()
{
DerivedType derivedInstance = new DerivedType();
}
}
}
输出：
调用基类构造函数。
派生类 DoSomething 被调用 - 初始化？否
调用派生类构造函数。
这对于进行资源管理非常有用。假设您有带析构函数的类，以便在对象生命周期结束时自动释放资源。假设您还有一个包含这些资源类的类，并且您在此上层类的构造函数中初始化它们。当您使用赋值运算符来初始化此更高级别的类时会发生什么？一旦内容被复制，旧的更高级别的类就变得无关紧要，并且所有资源类的析构函数都将被调用。如果这些资源类具有在赋值期间复制的指针，则所有这些指针现在都是无效指针。如果您改为在更高级别的类中的单独init函数中初始化资源类，则可以完全绕过资源类的析构函数，因为赋值运算符永远不必创建和删除这些类。我相信这就是所谓的“时间”要求的含义。
更多案例：
COOKING ARGS
构造函数不能调用另一个构造函数，但是初始化方法可以调用另一个初始化方法。
例如，我们有一个初始化器，它接受传统参数列表。我们有另一个初始化器，它接受名称=值对的字典。第二个初始化器可以查询字典以获取第一个初始化器接受的参数，并使用它们调用第一个初始化器。
当初始化器是初始化方法时，这很好，但当初始化器是构造函数时就不行了。
CHICKEN OR EGG
我们可能有一个汽车类，其初始化器必须具有指向发动机对象的指针，而发动机类初始化器必须具有指向其汽车对象的指针。这在构造函数中是不可能的，但在初始化方法中却很简单。
BREAKING UP ARG LIST
可能有大量的参数可以指定，但不需要指定（也许默认值足够，或者某些参数仅在其他参数的值取决于某些参数时才需要）。我们可能希望有几个初始化器而不是一个。
同样，将构造函数分解是根本不可能的，但将初始化器分解却很容易。
void。 - sellibitze