c++ - locales - variables globales java
¿Declaras que las funciones específicas de tu módulo son estáticas? (13)
Estoy pensando que es una buena práctica declararlos como estáticos, ya que los hace invisibles fuera del módulo.
¿Cuáles son sus pensamientos sobre esto?
Acerca de la única propiedad potencialmente útil que se me ocurre para este uso de "estática" en C ++, que los espacios de nombres anónimos no proporcionan, es que hay una advertencia en GCC que puede activarse para funciones estáticas no utilizadas (una forma de código muerto) . No lo obtiene para las funciones no utilizadas en espacios de nombres anónimos, por lo que, en el caso improbable de que desee que el compilador le diga cuándo deja de usar la función, hágalo de esa manera.
Creo que C y C ++ tienen diferentes limitaciones con respecto a la static : en C no tiene espacios de nombres y los archivos .c son sus módulos, por lo que es realmente muy importante poner todas las funciones no públicas como estáticas para evitar errores.
Para C ++, una mejor que la estática es ponerlo en un espacio de nombres sin nombre (anónimo). Esta es la forma preferida de evitar la contaminación del espacio de nombres global.
namespace {
void myLocalFunction() {
// stuff
}
}
Si es realmente una función que es interna solo para ese archivo .c, entonces sí. Debería ayudar a evitar la contaminación del espacio de nombres global. Además, creo que el compilador puede hacer algunas optimizaciones con convenciones de llamadas si la función es estática ya que no sabe que ningún otro archivo fuente necesita saber cómo llamarlo. Esto solo se aplica realmente a c porque, como otros han notado, c ++ tiene espacios de nombres para abordar este problema.
Si por ''módulo'' solo quiere decir un archivo CPP, podría simplemente colocar la declaración y la definición en el archivo CPP.
En C, hago que todo (funciones y variables) sea estático en el alcance del archivo hasta que pueda demostrar que son necesarios fuera del archivo. Voy a hacer las cosas estáticas dentro de una función si solo esa función las usará y no son demasiado grandes. Básicamente, si la declaración es más grande que el resto de la función, puedo colocar la declaración fuera de la función. Y, por supuesto, hay un encabezado para los servicios públicos proporcionados por un archivo fuente.
En el código C, establezca sus funciones estáticas de forma predeterminada. Solo realice funciones no estáticas y declaraciones .h para las funciones que necesitarán otros módulos.
En el código de C ++, ponga esas funciones que son locales en el archivo en un espacio de nombres anónimo y establézcalas estáticas. En el compilador de GNU al menos, esto dará como resultado el mejor y el más pequeño código, porque no se escribirá ninguna función si todos los usos están en línea. Si pretende que esté en línea, entonces, por supuesto, marcarlo en línea es incluso mejor que la estática.
No sé por qué g ++ escribe los cuerpos de función no nombrados que están en espacios de nombres anónimos en el resultado, pero lo hace. Las funciones con visibilidad oculta parecen aparecer también; marcados como símbolos ocultos, pero aún produciendo bloques de código no utilizados en el archivo objeto. GCC probablemente no entiende que el código no es necesario en esos casos. O me estoy perdiendo algo, siempre es posible.
Había mucho sobre los detalles de implementación y no demasiado sobre el concepto.
Limitar el alcance de la variable / función, etc. es una buena práctica. Este es un concepto básico de diseño orientado a objetos; desea mantenerlo privado como privado. De esta manera, su interfaz es más limpia y el mantenimiento del código es más fácil. Y un día no encontrará que cambiar algo que consideraba una compilación privada se rompió porque a alguien en otra parte del proyecto le gustaba su función y decidió usarla.
Si está utilizando GCC, entonces debería echar un vistazo a la bandera de visibilidad (ver http://gcc.gnu.org/wiki/Visibility para una discusión completa).
Ocultará los símbolos por completo en lugar de marcarlos inalcanzables. Eso reduce la tabla de símbolos y ayuda a disminuir los tiempos de enlace.
No solo eso, abre la puerta a más ingresos, si eso es lo que buscas.
Convenido. Como consecuencia, los prototipos para las funciones estáticas deben ir en la parte superior del archivo .c, no en el archivo .h.
En C ++, declararías la función privada así:
class MyClass
{
public:
void publiclyAccessibleFunction();
private:
void onlyAccesibleFromWithinTheClass();
int some_member_parameter;
};
Tenga en cuenta la onlyAccesibleFromWithinTheClass() .
En C ++, debe usar un espacio de nombre anónimo, como ese:
// foo.cpp
namespace
{
class Core { ... };
void InternalFandango(Core *);
}
void SomeGloballyVisibleFunction()
{
InternalFandango(&core);
}
Ventaja: esto también es aplicable a las declaraciones de estructura / clase.
En C, simplemente marque las funciones "estático". No hay nada en contra de usar "estático" en C ++, también, pero he aprendido a preferir el espacio de nombres, ya que es un concepto único que funciona para todas las declaraciones.