Funciones Pure/const en C++

Question

Estoy pensando en utilizar las funciones pure/const con mayor fuerza en mi código C++. (pure/const attribute in GCC)

Sin embargo, tengo curiosidad por lo estricto que debería ser y lo que posiblemente podría romperse.

El caso más obvio son salidas de depuración (en cualquier forma, podría estar en cout, en algún archivo o en alguna clase de depuración personalizada). Probablemente tenga muchas funciones, que no tienen ningún efecto secundario a pesar de este tipo de salida de depuración. No importa si la salida de depuración se realiza o no, esto no tendrá ningún efecto en el resto de mi aplicación.

O en otro caso estoy pensando en el uso de alguna clase SmartPointer que puede hacer algunas cosas adicionales en la memoria global cuando se está en modo de depuración. Si uso dicho objeto en una función pure/const, tiene algunos efectos secundarios leves (en el sentido de que algunos recuerdos probablemente serán diferentes) que no deberían tener ningún efecto secundario real (en el sentido de que el comportamiento está en de cualquier manera diferente).

Similar también para mutexes y otras cosas. Puedo pensar en muchos casos complejos donde tiene algunos efectos secundarios (en el sentido de que algunos recuerdos serán diferentes, tal vez incluso se crean algunos hilos, se hace alguna manipulación del sistema de archivos, etc.) pero no tiene diferencia computacional (todos esos efectos secundarios) bien podría ser dejado de lado y yo preferiría eso).

Por lo tanto, para resumir, quiero marcar funciones como pure/const que no son puros/const en un sentido estricto. Un ejemplo sencillo:

int foo(int) __attribute__((const)); 

int bar(int x) { 
    int sum = 0; 
    for(int i = 0; i < 100; ++i) 
     sum += foo(x); 
    return sum; 
} 

int foo_callcounter = 0; 

int main() { 
    cout << "bar 42 = " << bar(42) << endl; 
    cout << "foo callcounter = " << foo_callcounter << endl; 
} 

int foo(int x) { 
    cout << "DEBUG: foo(" << x << ")" << endl; 
    foo_callcounter++; 
    return x; // or whatever 
} 

Tenga en cuenta que la función foo no está const en un sentido estricto. Sin embargo, no importa qué foo_callcounter está al final. Tampoco importa si la declaración de depuración no está hecha (en caso de que no se llame a la función).

que sería de esperar la salida:

DEBUG: foo(42) 
bar 42 = 4200 
foo callcounter = 1 

Y sin optimización:

DEBUG: foo(42) (100 times) 
bar 42 = 4200 
foo callcounter = 100 

Ambos casos son totalmente bien porque lo único que importa para mi caso de uso es el valor de retorno de la barra (42).

¿Cómo funciona en la práctica? Si marcó funciones como pure/const, ¿podría romper algo (teniendo en cuenta que el código es correcto)?

---

Tenga en cuenta que sé que algunos compiladores pueden no admitir este atributo en absoluto. (Por cierto, los estoy recogiendo here.) También sé cómo hacer uso de los atributos de una manera que el código se mantiene portátil (a través de #defines). Además, todos los compiladores que son interesantes para mí lo soportan de alguna manera; así que no me importa si mi código se ejecuta más lento con compiladores que no lo hacen.

También sé que el código optimizado probablemente se vea diferente según el compilador e incluso la versión del compilador.

---

muy relevante es también this LWN article "Implications of pure and constant functions", especialmente el capítulo "Trampas". _{(Gracias ArtemGr por la pista.)}

Answer 1

Yo esperaría que la salida:

Yo esperaría que la entrada:

int bar(int x) { 
    return foo(x) * 100; 
} 

Su código se ve realmente extraño para mí. Como mantenedor, creo que foo en realidad tiene efectos secundarios o, más probablemente, lo reescriba inmediatamente en la función anterior.

¿Cómo funciona en la práctica? Si marcó funciones como pure/const, ¿podría romper algo (teniendo en cuenta que el código es correcto)?

Si el código es correcto, entonces no. Pero las posibilidades de que su código sea correcto son pequeñas.Si el código es incorrecta, esta característica puede enmascarar errores:

int foo(int x) { 
    globalmutex.lock(); 
    // complicated calculation code 
     return -1; 
    // more complicated calculation 
    globalmutex.unlock(); 
    return x; 
} 

ahora, dada la barra de arriba:

int main() { 
    cout << bar(-1); 
} 

Esto termina con __attribute__((const)) pero los puntos muertos de otra manera.

También depende en gran medida de la implementación. Por ejemplo:

void f() { 
    for(;;) 
    { 
     globalmutex.unlock(); 
     cout << foo(42) << '\n'; 
     globalmutex.lock(); 
    } 
} 

Cuando el compilador debe mover la llamada foo(42)? ¿Está permitido optimizar este código? ¡No en general! Entonces, a menos que el ciclo sea realmente trivial, no tiene beneficios de su función. Pero si su bucle es trivial, puede optimizarlo usted mismo.

EDIT: como Albert pidió una situación menos obvio, aquí se trata: F o ejemplo, si implementa operator << para una ostream, se utiliza el ostream :: centinela que bloquea el búfer de la secuencia. Supongamos que llamas a puro/const fdespués de que lanzaste o antes de lo bloqueaste. Alguien usa este operador cout << YourType() y f también usa cout << "debug info". Según usted, el compilador puede poner la invocación de f en la sección crítica. Se produce un punto muerto.

Answer 2

Definitivamente podría romper la portabilidad de su código. ¿Y por qué querrías implementar tu propio puntero inteligente, aparte de la experiencia de aprendizaje? ¿No hay suficientes disponibles para usted en bibliotecas estándar (cercanas)?

Answer 3

Estoy pensando en usar las funciones pure/const con mayor fuerza en mi código C++.

Esa es una pendiente resbaladiza. Estos atributos son no estándar y su beneficio se limita principalmente a micro-optimizaciones.

No es una buena solución de compromiso. Escriba código limpio en su lugar, no aplique tales micro-optimizaciones a menos que haya perfilado cuidadosamente y no haya forma de evitarlo. O no en absoluto.

Observe que en principio estos atributos son bastante agradables porque indican suposiciones implícitas de las funciones explícitamente tanto para el compilador como para el programador. Eso es bueno. Sin embargo, existen otros métodos para hacer suposiciones similares explícitas (incluida la documentación). Pero dado que estos atributos no son estándar, tienen sin lugar en el código normal. Deben restringirse a muy uso juicioso en bibliotecas de rendimiento crítico donde el autor intenta emitir el mejor código para cada compilador. Es decir, el escritor es consciente del hecho de que solo GCC puede usar estos atributos y ha tomado diferentes decisiones para otros compiladores.

Answer 4

Creo que nadie sabe esto (con la excepción de los programadores gcc), simplemente porque confías en el comportamiento indefinido e indocumentado, que puede cambiar de una versión a otra. Pero ¿qué tal algo como esto:

#ifdef NDEBUG \ 
    #define safe_pure __attribute__((pure)) \ 
#else \ 
    #define safe_pure \ 
#endif 

Yo sé que no es exactamente lo que quiere, pero ahora se puede utilizar el atributo pura sin romper las reglas.
Si quiere saber la respuesta, puede preguntar en los foros de gcc (lista de correo, lo que sea), ellos deberían poder darle la respuesta exacta.
Significado del código: cuando se define NDEBUG (símbolo utilizado en assert macros), no depuramos, no tenemos efectos secundarios, podemos usar el atributo pure. Cuando se define, tenemos efectos secundarios, por lo que no usará atributos puros.

Answer 5

Examinaré el asm generado para ver qué diferencia hacen. (Mi suposición sería que el cambio de flujos de C++ a otra cosa produciría un mayor beneficio real, consulte: http://typethinker.blogspot.com/2010/05/are-c-iostreams-really-slow.html)