¿Es correcto exportar miembros de datos? (C ++)

Question

Como sugiere el título, ¿es correcto o válido importar / exportar datos estáticos desde una clase de C ++?

Descubrí mi problema: el autor de la clase que estaba viendo estaba intentando exportar datos estáticos de escritura que no son compatibles con esta plataforma.

Muchas gracias por las respuestas, sin embargo.

Answer 1

¿Es correcto en la medida en que funcionará y hará lo que usted espera? Suponiendo que está hablando sobre el uso de _declspec (dllexport / dllimport) en una clase o miembro de la clase, sí, puede hacer eso y debería darle el resultado esperado: los datos estáticos serían accesibles fuera de su dll y otros códigos C ++ podrían acceder siempre que la especificación de acceso a C ++ (pública / protegida / privada) no bloquee el acceso externo en primer lugar.

¿Es una buena idea? Personalmente no lo creo, ya que estaría exponiendo los aspectos internos de la clase no solo dentro de su biblioteca sino también al mundo exterior, lo que significa que será casi imposible cambiar lo que es un detalle de implementación al final del día. Pregúntese si está 100% seguro de que la interfaz de esta clase y gran parte de su implementación nunca, nunca cambiará ...

Answer 2

Una clase de C ++ exportada significa que los clientes de DLL deben usar el mismo compilador que la DLL debido a la manipulación de nombres y otros problemas. Esto es realmente un problema bastante grande, una vez tuve que escribir envoltorios de C en un grupo de clases de C ++ porque los programas cliente se habían cambiado a MSVC9, mientras que la DLL en sí misma estaba usando MSVC71. [Hubo algunas otras complicaciones con el cambio de la DLL a MSVC90]. Desde entonces he sido bastante escéptico sobre este negocio de exportar clases, y prefiero escribir un contenedor de C para todo.

Ahora, si está dispuesto a pagar el precio de las clases de exportación, yo diría que exportar datos estáticos no empeora el problema. Podría decirse que, entre los tipos de cosas que podría exportar, es más seguro exportar constantes estáticas. Aun así, prefiero no hacerlo, porque, como dice Timo, ahora estás bloqueado en esta implementación.

Uno de los marcos en los que trabajé requería que sus clientes proporcionaran un conjunto de constantes de código de error. Con el tiempo, descubrimos que el uso de un grupo simple de constantes era demasiado frágil, y cambiamos a un diseño OO. Tuvimos una implementación predeterminada que devolvería los códigos de error comunes, pero se accedió a cada uno de los códigos de error mediante una función virtual que podría ser anulada por los clientes individuales, y la utilizaron de un manejo avanzado de errores específicos del dispositivo. Esta solución demostró que lejos es más escalable que la que se basa en la exportación de constantes.

Le sugiero que piense detenidamente sobre cómo espera que evolucione el componente antes de exportar variables estáticas.

Answer 3

dllexport (o importar) en un miembro de datos (no estático) de clase no hace nada. Exportado " cosas " son funciones o datos globales (aunque esta es una opción de diseño cuestionable). dllexport en una clase es solo un atajo para decir " exportar todas estas funciones " ;.