Construtores são como 'funções de inicialização". Eles transformam uma pilha de bits sem significado em um objeto. No mínimo eles incializam os campos usados internamente. Eles podem também alocar recursos (memória, arquivos, semáforos, sockets, etc)

ctor é normalmente a abreviação de construtor.

Suponha que List é o nome de uma classe. A função f() declara um objeto local List denominado x:

Se você chama um outro construtor, o compilador inicializa um objeto local temporário; ele não inicializa este objeto. Você pode combinar dois construtores usando um parâmetro default, ou você pode compartilhar o código comum entre eles em uma função membro private init().

Não há modo de se dizer ao compilador para chamar um construtor que não seja o construtor default. Se sua classe Fred não possui um construtor default, a tentativa de criar uma matriz de objetos Fred resulta em um erro em tempo de compilação.

Por exemplo: esse construtor inicializa o objeto membro x_ usando uma lista de inicialização:

Fred::Fred(); x(qualquercoisa) {}

Do ponto de vista de performance, é importante notar que a expressão qualquercoisa não causa automaticamente a criação de um objeto em separado e copiado para dentro de x_: se os tipos forem os mesmos o resultado de qualquercoisa será coinstruido diretamente dentro de x_.

Em contraste, o seguinte construtor usa atribuição de valor:

Fred::Fred{} {x_ = qualquercoisa; }.

Nesse caso a expressão qualquercoisa causa a criação, em separado, de um objeto temporário, e esse objeto temporário é transferido para dentro do operador de atribuição de valor a x_ e então é destruído no ;  Isso é ineficiente.

Há ainda uma outra fonte de ineficiência:  no segundo caso (atribuição de valor) o construtor default do objeto (chamado implicitamente antes do corpo do construtor "{") poderia, por exemplo, alocar certa quantidade de memória, ou abrir um determinado arquivo. Todo esse trabalho seria perdido se a expressão qualquercoisa e/ou o operador de atribuição de valor levasse o objeto a fechar o arquivo e/ou liberar a memória alocada. (por exemplo: se o construtor default não conseguisse alocar a quantidade requisitada de memória, ou ocorresse erro na operação de abertura do arquivo.

Conclusão: Tudo o mais sendo igual, seu código será mais veloz se você usar lista de inicialização ao invés de atribuição de valor.

O problema é que os construtores têm sempre o mesmo nome que a classe. Dessa forma, a única maneira de se diferenciar um entre vários construtores da classe é pela lista de parâmetros. Mas se houver uma lista muito grande de construtores, a diferença entre eles pode tornar-se um tanto sutil, e sujeita a erros.

Usando Named Constructor Idiom você declara todos os construtores nas seções private: ou protected: da sua classe, e você fornece métodos public static que retornam um objeto. Esse métodos static são denominados Named Constructors. Como regra geral, há um método static para cada modo diferente de construir o objeto.

Por exemplo: suponha que estamos construindo a classe Point, que representa a posição x-y em um plano. Há duas maneiras comuns de se especificar uma coordenada em um plano: coordenadas retangulares (X+Y) e coordenadas polares (Radial+Ângulo) (Não se preocupe se você não se lembra desses detalhes, o ponto aqui não é discutir o sistema de coordenadas, o que interessa é discutir que há vários modos de se criar o objeto Point). Infelizmente, os parâmetros para esses dois sistemas de coordenadas são os mesmos: dois floats. Isso criaria um erro por ambigüidade na sobrecarga dos construtores:

O Named Constructor Idiom pode também ser usado para garantir que seus objetos sejam sempre criados via comando new.

O fiasco de seqüência de inicialização static é um aspecto do C++ muito sutil, e normalmente não compreendido. Infelizmente é muito difícil de detectar. Os erros ocorrem antes do início de main()

Em poucas palavras: suponha que você tem dois objetos static, x e y, os quais existem em arquivos separados, x.cpp e y.cpp. Suponha ainda que o construtor do objeto y chame algum método do objeto x.

É isso. É simples assim.

A tragédia, nesse caso, é que você tem 50%-50% chance de morrer. Se acontecer de a  unidade de compilação para x.cpp ser inicializada primeiro, tudo estará bem. Mas se a unidade de compilação para y.cpp começar primeiro, então o construtor de y será executado antes do construtor de x, e você estará "ferrado". Ou seja, o construtor de y vai chamar um método do objeto x, antes que o objeto x esteja construido.

Se você gosta de jogar Roleta Russa pode interromper sua leitura aqui. Por outro lado, se você gosta de melhorar suas chances de sobrevivência, prevenindo-se sistematicamente contra desastres, você provavelmente vai querer ler o próximo tópico desse FAQ.

Nota: O fiasco de seqüência de inicialização static não se aplica a tipos builtin e/ou intrínsecos como int ou char*. Por exemplo, se você cria um objeto static float, nunca terá problema com a seqüência de inicialização. O único caso em que a seqüência de inicialização static é verdadeiramente um fiasco é quando seu objeto static ou global tem um construtor.

Por exemplo, suponha que você tem duas classes, Fred e Barney. Há um objeto Fred global chamado x, e um objeto Barney global chamado y. O construtor de Barney invoca o método goBowling() no objeto x. O arquivo x.cpp define o objeto x:

// File x.cpp
    #include "Fred.hpp"
    Fred x; 

O arquivo y.cpp define o objeto y;

// File y.cpp
    #include "Barney.hpp"
    Barney y; 

Para estar completo, o construtor de Barney deve se parecer com algo como:

// File Barney.cpp
    #include "Barney.hpp"
    
    Barney::Barney()
    {
      // ...
      x.goBowling();
      // ...
    } 

Como descrito no tópico anterior desse FAQ, o desastre ocorre se y for construido antes de x, o que acontece 50% das vezes, já que estão em arquivos-fonte diferentes.

Há várias maneiras de solucionar esse problema, mas a solução mais simples e completamente portável é substituir o objeto global Fred, x , por uma função global x(), que retorna objeto Fred por referência.

Uma vez que os objetos locais static são construídos unicamente na primeira vez que o controle passa por sua declaração, o comando new Fred() acima será executado uma única vez: a primeira vez que x() for chamado. Todas as chamadas subseqüentes vão retornar o mesmo objeto Fred (aquele apontado por ans). Assim, tudo o que você faz é trocar o uso de x por x():

// File Barney.cpp
    #include "Barney.hpp"
    
    Barney::Barney()
    {
      // ...
      x().goBowling();
      // ...
    } 

Isso é chamado Construct on First Use Idiom porque faz justamente isso: o objeto global Fred é construido na primeira vez em que é usado.

O lado negativo dessa abordagem é que o objetoFred nunca é destruido. O C++ FAQ Book apresenta uma segunda técnica que responde a esse problema, mas ao custo de incorrer no fiasco de seqüência de des-inicialização static.

Nota: Você não tem esse problema com tipos built-in e/ou intrínsecos como int ou char*. Por exemplo, se você cria um objeto float global ou static, não há necessidade de empacotá-lo dentro da função. O único caso em que a seqüência de inicialização static é verdadeiramente um fiasco é quando seu objeto static ou global tem um construtor.

Suponha que você tem uma classe x que possui um objeto static Fred:

// File X.hpp
    
    class X {
    public:
      // ...
    
    private:
      static Fred x_;
    }; 

Naturalmente o membro static é inicializado separadamente:

// File X.cpp
    
    #include "X.hpp"
    
    Fred X::x_; 

Naturalmente também, o objeto Fred será usado em um ou mais métodos de x:

 void X::someMethod()
    {
      x_.goBowling();
    } 

Mas aqui o perigo é alguém, de algum lugar, de alguma maneira chamar este método antes que o objeto Fred esteja construído. Por exemplo, se alguem cria um objeto static x e invoca seu método  someMethod() durante a inicialização static, então você fica mercê do compilador, de como o compilador irá construir X::x_, antes ou após someMethod() ser chamado. (Note que o comitê ANSI/ISO C++ está trabalhando nesse problema, mas ainda não estão disponíveis os compiladores com as alterações necessárias para tratar esse problema. Visite esse tópico no futuro para verificar se houve alterações).

De qualquer maneira, é sempre mais portável e mais seguro alterar o dado membro X::x_ para a função membro static:

// File X.hpp
    
    class X {
    public:
      // ...
    
    private:
      static Fred& x();
    }; 

Naturalmente este membro static é inicializado separadamente:

// File X.cpp
    
    #include "X.hpp"
    
    Fred& X::x()
    {
      static Fred* ans = new Fred();
      return *ans;
    } 

Então você simplesmente troca o uso de x_ por x():

void X::someMethod()
    {
      x().goBowling();
    } 

Nota: Você não tem que fazer isso para tipos built-in e/ou intrínsecos como int ou char*. Por exemplo, se você cria um objeto float global ou static, não há necessidade de empacotá-lo dentro da função. O único caso em que a seqüência de inicialização static é verdadeiramente um fiasco é quando seu objeto static ou global tem um construtor.