Pular para o conteúdo principal

C++0x vai mudar sua vida: listas de inicialização

Com a nova sintaxe para listas de inicialização, é como se agora houvesse uma notação para o valor literal de praticamente qualquer estrutura de dados.

Observe meu teste de unidade construindo um "attribute template" PKCS #11 com std::vector direto na inicialização:

std::vector attributes
{
  CK_ATTRIBUTE { CKA_CLASS, &object_class, sizeof(object_class) },
  CK_ATTRIBUTE { CKA_TOKEN, &on_token, sizeof(on_token) },
  CK_ATTRIBUTE { CKA_LABEL, &label, sizeof(label) },
  CK_ATTRIBUTE { CKA_APPLICATION, &application, sizeof(application) },
  CK_ATTRIBUTE { CKA_VALUE, &data, sizeof(data) }
};

O segredo da notação está nessa pseudo-gramática:

  type-name identifier { initializer-list };

que é análoga em significado a:

  type-name identifier ( argument-list );

ou:

  type-name identifier = type-name ( argument-list );

Comentários

Postagens mais visitadas deste blog

return void();

É uma pequeneza mas eu gostaria muito que as linguagens da família do C permitissem retornar void quando a função retorna void . Escrever da forma a seguir me aborrece. public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null)      {        log("x was null");        return;      }      bar(x, "default");    } } Eu ficaria mais feliz escrevendo assim: public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null) return log("x was null");      bar(x, "default");     } }

.NET COM Interop, IStream e Visual Studio

Investigando oportunidades para otimizar um componente, experimentei definir métodos que não solicitam dados (em arrays etc.) como argumentos mas sim instâncias de IStream , e me deparei com um problema interessante: interoperabilidade com .NET. Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto. Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação. Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream , uma interface definida pelo sistema. Pelo método do callable wrapper , a ferramenta assume que as interfaces mencionadas integram o componente...