Supongo que abs y fabs se comportan de manera diferente al usar math.h. Pero cuando uso solo cmath y std::abs, ¿tengo que usar std::fabs o fabs? ¿O no está esto definido?¿Cuándo uso fabs y cuándo es suficiente usar std :: abs?
En C++, siempre es suficiente usar std::abs; está sobrecargado para todos los tipos numéricos.
En C, abs solo funciona en enteros, y necesita fabs para valores de coma flotante. Estos están disponibles en C++ (junto con toda la biblioteca C), pero no es necesario usarlos.
Todavía está bien utilizar fabs para double y float argumentos. Prefiero esto porque garantiza que si accidentalmente quito std:: del abs, el comportamiento sigue siendo el mismo para las entradas de coma flotante.
Acabo de pasar 10 minutos depurando este mismo problema, debido a mi propio error de usar abs en lugar de std::abs. Supuse que el using namespace std; inferiría std::abs pero no fue así, y en su lugar estaba usando la versión C.
De todos modos, creo que es bueno usar fabs en lugar de abs para entradas de punto flotante como una forma de documentar claramente su intención.
Eso es raro. Su llamada debería haber sido ambigua (y por lo tanto un error) ¿no? – Nick
¿No deberías estar usando fabsf para flotar? Entonces no creo que sean idénticos. – Nick
Tenga cuidado con Android NDK g ++, también cede a la función c abs() en lugar de std :: abs(). En el compilador de Visual Studio C++, sin embargo, abs siempre apunta a std :: abs() though. – southerton
Hay una razón más para recomendar std::fabs para las entradas de punto flotante explícitamente.
Si se olvida de incluir <cmath>, su std::abs(my_float_num) puede haber std::abs(int) en lugar de std::abs(float). Es difícil de notar.
"abs" y "fabs" son solo idénticos para los tipos de flotación C++, cuando se pueden traducir sin mensajes de sobrecarga ambiguos.
Estoy usando g ++ (g ++ - 7). Junto con el uso de plantillas y especialmente cuando se usa mpreal, hay casos con mensajes difíciles de "sobrecarga ambigua": abs(static_cast<T>(x)) no siempre lo resuelve. Cuando los abdominales son ambiguos, hay posibilidades de que fabs funcione como se esperaba. Para sqrt no encontré un escape tan simple.
Desde hace semanas estoy luchando duro en C++ "problemas no existentes". Estoy actualizando un viejo programa de C++ a C++ 14 para obtener más y mejor uso de la plantilla que antes. A menudo, el mismo parámetro de plantilla puede ser real cualquier float estándar o tipo complejo o un tipo de clase. Por qué alguna vez, hace mucho tiempo que actuó un poco más sensible que otros tipos. Todo estaba funcionando, y había incluido mpreal antes. Luego estaba configurando mi tipo de flotación predeterminado en mpreal y obtuve un aluvión de errores de sintaxis. Eso dio miles de sobrecargas ambiguas, p. para abs y sqrt, llorando por diferentes soluciones. Algunos necesitaban funciones de ayuda sobrecargadas, pero fuera de una plantilla. Tuve que reemplazar individualmente mil usos de 0.0L y 1.0L con el tipo constante exacto usando Zero o One o un type_cast - definición de conversión automática imposible debido a ambigüedades.
Hasta mayo encontré las conversiones implícitas muy buenas. Pero mucho más simple sería sin ninguna, y tener constantes de tipo de letra con type_casts explícitos seguros a cualquier otro tipo de constante estándar.
¿Esto se aplica en todas las plataformas? Esp. Windows y Mac OS X? ¿O está al menos en el estándar de C++? – math
@brubelsabs: sí. No hay necesidad de una función de fabs separada en C++ ya que C++ tiene una sobrecarga de funciones (abs se puede definir para muchos tipos y está en C++). También está garantizado por el estándar. Por supuesto, si busca un compilador obsoleto de más de 10 años, puede encontrar uno que no lo admita. – stinky472
Está en el estándar C++, por lo que es el caso en todas las plataformas con un compilador decente, incluyendo Windows y Mac OS X. La cláusula 26.5 dice que, además de la versión 'int' de la biblioteca C, hay sobrecargas para' long ',' float', 'double' y' long double'. La cláusula 26.2.7 también define una sobrecarga para 'complex'. –