c++ - compiler - mingw windows 10

¿Qué hay de malo con este uso de offsetof?

Question

Estoy compilando un código de C ++ en MinGW GCC 4.4.0 y recibiendo advertencias con el siguiente formulario ...

warning: invalid access to non-static data member ''<membername>''  of NULL object
warning: (perhaps the ''offsetof'' macro was used incorrectly)

Este problema parece familiar, algo que intenté resolver antes y fallé, creo, pero hace un tiempo. El código se compila bien en Visual C ++, pero no he construido este código en particular recientemente en ningún otro compilador.

El código del problema es la siguiente plantilla ...

template<typename T>
class c_Align_Of
{
  private:
    struct c_Test
    {
      char m_Char;
      T    m_Test;
    };
  public:
    enum { e_Align = offsetof (c_Test, m_Test) };
};

Obviamente, probablemente pueda usar alguna compilación condicional para usar funciones específicas del compilador para esto, y creo que C ++ 0x (por fin) lo hará redundante. Pero, en cualquier caso, no puedo ver nada malo con este uso de offsetof .

Muy pedantemente, es posible que debido a que los tipos de parámetros T veces no sean POD, entonces las clases de GCC c_Test no sean POD y se quejen (y se queja y se queja, estoy recibiendo casi 800 líneas de estas advertencias).

Esto es travieso por la terminología estricta del estándar, ya que los tipos que no son POD pueden romper offsetof . Sin embargo, este tipo de no POD no debería ser un problema en la práctica: c_Test no tendrá una tabla virtual, y no se necesita engaño en tiempo de ejecución para encontrar el desplazamiento de m_Test .

Además, incluso si c_Test tenía una tabla virtual, GCC implementa el offset de macro utilizando un intrínseco que siempre se evalúa en tiempo de compilación en función del diseño estático de ese tipo en particular. Proporcionar una herramienta, luego lloriquear (lo siento, advertir) cada vez que se usa, parece tonto.

Además, no soy la única persona por aquí que hace este tipo de cosas ...

Responder a legit-uses-of-offsetof pregunta

Recuerdo haber tenido un problema con offsetof por este tipo de razones, pero no creo que el problema fuera esta plantilla.

¿Algunas ideas?

Answer 1

Bueno, la interpretación ingenua de este error en particular es tomarlo al pie de la letra: accede a un campo privado desde dentro de una enumeración. Pero presumiblemente, las enumeraciones son estáticas por definición (supongo que es por eso que es posible trabajar con constantes enum en primer lugar, son esencialmente constantes int con un nombre elegante).

Answer 2

Oops ...

El problema es que la estructura c_Test no es POD debido a que el tipo T no es POD. Aquí hay una cita del manual de GCC ...

-Wno-invalid-offsetof (C ++ y Objective-C ++ solamente)

Suprima las advertencias de aplicar la macro ''offsetof'' a un tipo que no sea POD.

De acuerdo con el estándar ISO C ++ de 1998, la aplicación de ''offsetof'' a un tipo que no sea POD no está definida. Sin embargo, en las implementaciones existentes de C ++, ''offsetof'' generalmente da resultados significativos incluso cuando se aplica a ciertos tipos de tipos no POD. (Como una simple ''estructura'' que no puede ser un tipo de POD solo en virtud de tener un constructor.) Esta bandera es para usuarios que saben que están escribiendo código no portátil y que deliberadamente han elegido ignorar la advertencia al respecto.

Las restricciones sobre ''offsetof'' pueden relajarse en una versión futura del estándar C ++.

Mi problema es que casi todos mis tipos T tienen constructores y, por lo tanto, están clasificados como no POD. Ignoré este punto como irrelevante antes, y por supuesto debería ser irrelevante para la compensación en principio. El problema es que el estándar C ++ usa una clasificación POD vs. no POD, aunque hay varias maneras diferentes de no ser POD, y el compilador es correcto para advertir sobre el uso no conforme a los estándares por defecto.

Mi solución por el momento será la opción anterior para suprimir la advertencia; ahora solo necesito descubrir cómo decirle a cmake que la use.