Como bien comentó nuestro compañero programator11, está practicando. Si le doy la solución definitiva... ¿qué va a practicar?

No necesariamente... tienes que separar los diferentes elementos de la ecuación... por un lado la parte real y por otro la "posible" imaginaria. Es decir, si tenemos que las dos raices son:

y1 = -b/2a + sqrt(b^2-4ac)/2a
y2 = -b/2a - sqrt(b^2-4ac)/2a

Hacemos la separación:

r = -b/2a
i = sqrt(b^2-4ac)/2a

De tal forma que:

y1 = r + i
y2 = r - i

Ahora ya tenemos que R siempre es real, mientras que I será real sólo si el interior de la raiz cuadrada no es negativo. Es decir, podríamos tener algo del tipo:

x = b^2-4ac
r = -b/2a
i = sqrt(x)

entonces, si x >= 0 podemos calcular las dos raices de la forma acostumbrada... pero si x < 0, entonces tenemos número imaginario... dado que ya tienes separada la parte imaginaria es facil conformar el número complejo:

double _Complex resimag1 = r + i * I;
double _Complex resimag2 = r - i * I;

Una aplicación que está en desarrollo se compila en modo "debug", es decir con símbolos de depuración y sin optimizaciones para poder depurar el código con facilidad. Cuando la aplicación sale "a la venta", se compila en modo release, es decir, con las optimizaciones oportunas para que la aplicación funcione lo más fluida posible.


'volatile', como se ha comentado, lo único que hace es impedir que el compilador pueda aplicar optimizaciones sobre la variable. Esta necesidad surge, por ejemplo, a partir de entornos con memoria compartida entre aplicaciones... en los que una variable es accedida a discrección por diferentes fuentes.

char* c;
cin >> c;

c es un puntero y no está inicializado.


'volatile' sigue teniendo la misma importancia que tenía en un principio... es una herramienta para casos concretos. Otra cosa es que no te hayas encontrado aún con un caso en el que sea necesario usarla... pero no por eso deja de ser importante... hay proyectos que tendrían bastantes quebraderos de cabeza si no existiese esta palabra clave.


¿problemas? ¿qué clase de problemas? ¿memoria no inicializada tal vez? ¿accesos a memoria no válida? ¿buffer overflow?

'volatile' sirve para lo que sirve. Si no te queda claro cuando has de usarlo es porque no has terminado de entender su finalidad y no te has encontrado con el problema ninguna vez. Lo dicho, deberías usarla cuando tengas, por ejemplo, memoria compartida entre varias aplicaciones.

Estás calculando el resultado de la ecuación usando las funciones de math.h... que no tienen soporte para números complejos

double _Complex resimag1 = res1;

res1 es un double normalito... no entiende de imaginarios ni sabe siquiera que existen.

El modificador volatile, efectivamente, advierte al compilador para que se abstenga de intentar aplicar optimizaciones sobre la variable afectada. Pero ojo... que no tenga el modificador no quiere decir que el compilador tenga forzosamente que aplicar optimizaciones... eso ya depende de varios factores:

• Tipo de compilador: Cada compilador tiene su propio código y su propio árbol de decisiones.
• Configuración del compilador: Por muy bueno que sea un compilador... si le dices que no optimice (por ejemplo compilando en modo debug), no aplicará ningún cambio perceptible.
• Código fuente: Que una variable se pueda optimizar depende del uso que se le de... no solo a la variable, sino también a su entorno. Si tienes más variables que registros, por ejemplo, está claro que el compilador tendrá que decidir quien se queda con los registros en cada momento.

Y toda esta parrafada para al final matizar lo comentado al principio: volatile sirve para asegurarte de que esa variable no va a sufrir optimizaciones... pero esta premisa no dice nada acerca del comportamiento esperado si se elimina el modificador.

Hasta aquí la cosa va bien. IDE tienes a patadas, aunque los más conocidos hoy en día son VisualStudio (solo Windows), CodeBlocks, QtCreator, DevCpp (no recomendado).


Empezamos a torcernos... si tu intención es aprender a programar C / C++ no debes caer en la trampa de abstracerte completamente del proceso de compilación... ya que es vital para entender determinados errores, fallos y comportamientos inesperados en el código.

Que con esto no digo que el famoso "botón de play" para compilar y probar el programa lo haya inventado el demonio... de echo yo lo uso mucho... pero esa no es excusa para no mancharse las manos conociendo cómo funciona el tema de la compilación. Ten cuidado con esto.

Un saludo.

No estoy hablando de una función concreta... hablo en general.

Porque claro, ya puestos, una vez has creado tu versión de strcat (pensando en que debe funcionar igual que la función estándar)... ¿por qué no hacer una implementación propia de strlen, strcpy, strtok, memcpy, memset... ¿eres capaz de garantizar que tus versiones van a ser igual de óptimas que las versiones estándar? estoy convencido de que no. Si miras el código fuente de algunas de estas funciones verás que están plagadas de compilaciones condicionales... precisamente para optimizar y para sortear eventualidades (no es lo mismo una arquitectura big endian que una little endian, por ejemplo)... y está claro que tú no vas a tener en cuenta estas cosas. Al final, por este camino, tu código acabaría siendo poco eficiente y no portable.... y ese no es el camino.

... y si sabes la longitud ... también.

Las cadenas de caracteres van siempre con punteros.

PD.: lo siento hoy estoy quisquilloso... te falta un free so pena de tener lagunas de memoria.

PD2.: hay que tener cuidado con las reservas de memoria ( malloc, calloc, realloc ). Estas funciones están pensadas para hacer reservas grandes de memoria... con reservas pequeñas son bastante ineficientes... además, realloc tiene el problema añadido de mover información de una posición de memoria a otra... luego andar haciendo realloc cada dos por tres no parece una opción muy atractiva... casi es mejor hacer realloc de forma exponencial... reservando bloques cada vez más grandes de memoria precisamente para realizar la menor cantidad de llamadas posibles. Escatimar recursos a este nivel solo es útil en sistemas empotrados o con recursos escasos, en el resto de casos no merece la pena.

Son cosas que pasan... es que lo he visto nada más ver el código... que, dicho sea de paso, no es culpa de la función sino de cómo ha sido declarada la variable.

Eres consciente que tu ejemplo escribe fuera del buffer, no?? ... o perdón, hablando con propiedad... provoca buffer overflow.

A ver, ya puestos, no tiene mucho sentido que el "remedio" consista en crear una versión de strcat que permita concatenar dos cadenas por vez en vez de una...

Si pretendemos ahorrar llamadas al menos tenemos que intentar hacerlo con un poco de sentido... no viene a cuento reinventar la rueda... ten por seguro que la implementación de la librería estándar es, en el peor de los casos, igual de eficiente que la tuya... lo lógico es que esa versión tienda a ser más eficiente que la tuya. Y aunque esta no fuese razón suficiente, piensa que la librería estándar va a tener muchos menos errores de código que tu versión... además que te evitas tener que mantener ese código.

char* my_strcat( char*s, const char*cad )
{
  if ( *s != 0 )
    strcat( s, " " );
 
  strcat( s, cad );
 
  return s;
}

Pd.: tampoco he entendido muy bien la utilidad de la variable "save";