Rendimiento: typedef vs clase contenedora para tipos primitivos?

En realidad, hay dos razones por las que esto podría ser más lento.

Primero, no hay forma de crear un NodeId no inicializado. Normalmente, eso es un bueno cosa. Pero imagina que tienes un código como este:

NodeId nodeid;
foo.initializeNodeId(&nodeid);

Estarás haciendo una tarea adicional que en realidad no es necesaria.

Puede arreglar eso agregando un constructor especial. Probablemente sea mucho mejor crear un Foo::createNodeId() para que no necesite Foo::initializeNodeId(&NodeId), pero si no controla la definición de Foo, puede que no sea posible.

En segundo lugar, un NodeId no es una expresión constante en tiempo de compilación. Como sugiere dasblinkenlight, es mucho más probable que esto cause problemas con el código que no es legal que problemas de rendimiento, pero ambos son posibles. (¿Por qué? Porque puede estar obligando al compilador a insertar código para hacer algún cálculo en tiempo de ejecución que podría haberse hecho en tiempo de compilación, si estuviera usando un int. No es probable que esto sea un problema para una clase llamada NodeId... )

Afortunadamente, si usa C++ 11, puede solucionarlo con constexpr. Y si desea que su código también sea C++03 legal, puede solucionarlo con una macro.

Además, como lo señaló dasblinkenlight, te falta const en dos métodos.

Finalmente, no hay razón para escribir "en línea" en métodos que están definidos dentro de la definición de clase; ya están inherentemente en línea.

Poniendolo todo junto:

#if __cplusplus > 201000L
#define CONSTEXPR_ constexpr
#else
#define CONSTEXPR_
#endif

class NodeId
{
    int value;
public:
    struct Uninitialized {};
    CONSTEXPR_ NodeId() : value(-1) {}
    CONSTEXPR_ NodeId(Uninitialized) {}      
    CONSTEXPR_ NodeId(int value) : value(value) {}
    CONSTEXPR_ operator int() const {return value;}
    CONSTEXPR_ bool isValid() const {return value != -1;}
    //...
};

Ahora puede hacer esto para evitar el costo de una asignación adicional de -1.

NodeId nodeId(NodeId::Uninitialized());
foo.initializeNodeId(&nodeid);

Y esto, para usar legalmente un NodeId como parámetro de plantilla sin tipo:

myClassTemplate<NodeId(3)> c;

O esto, para asegurarse de que el compilador pueda inicializar legalmente x a 4:

int x = 3;
x += NodeId(1);

Si usa un compilador relativamente nuevo, entonces el código generado debería ser el mismo. El compilador no debería tener problemas para incorporar esas funciones miembro. En caso de que realmente tengas dudas al respecto, siempre puedes desmontar el ejecutable.

Si la configuración de optimización del compilador permite que el compilador alinee todo, no debería haber diferencias de rendimiento. La única desventaja que puedo detectar es que las expresiones basadas en objetos de esta clase ya no califican como constantes de tiempo de compilación, lo que puede ser importante en la programación de plantillas. Aparte de eso, obtiene claridad adicional sin costo de tiempo de ejecución.

inline operator int() const {return value;}
inline bool isValid() const {return value != -1;}

Si está planeando convertir esto en una biblioteca que pueda ser utilizada por algún otro lenguaje de programación (como si está escribiendo esto en una DLL de C++), hay ventajas definitivas en tenerlo como typedef int.

Por ejemplo, cuando está escribiendo un contenedor de python o un contenedor de Java para su API, no tiene tanto dolor de cabeza para que su clase y tipos se transfieran. Entonces todo lo que tiene que preocuparse es el tamaño de bit del int.