Mensajes

Puedes usar la librería openssl: http://stackoverflow.com/a/10324904/1794803

Aunque lo correcto es tirar por lo que ha dicho `engel lex` (buscar una librería), si estás en linux al menos, siempre puedes hacer una llamada a `system` con un script PHP utilizando el `she-bang`:

Código (bash) [Seleccionar] Expandir


#!/usr/bin/php + opciones que sean necesarias.

// tus llamadas a md5()

// guardar el valor en un fichero


Y luego tu código C++:

Código (c++) [Seleccionar] Expandir


system("./script-php");

// Leemos el fichero escrito por el script

O también podrías crear un fichero temporal, y en la llamada a `system` redirigir la salida estándar de dicho script php a dicho fichero temporal. También puedes buscar algún wrapper de PHP para C++. O utilizar una librería para lanzar un proceso en vez de llamar a `system` (para hacer a la aplicación independiente de la plataforma), y utilizar sockets para comunicar PHP con C.

En fin... no se me ocurre nada más.

Tienes razón en lo del carácter fin de línea. Mi solución es, quizás, más adecuada para cadenas recibidas como parámetro (`sscanf`), que para comprobar directamente la entrada. De todas formas, ¿no es ésta una solución más sencilla?

Código (cpp) [Seleccionar] Expandir


/* Con barras invertidas para que tenga más "pinta" de fecha :)
leidos = scanf("%2u/%2u/%4u%c", &dia, &mes, &anno, &truco);

if (leidos < 3)
    exit(EXIT_FAILURE);

if (leidos > 3 && truco != '\n'))
   exit(EXIT_FAILURE);

De ésta forma, solo permitimos una fecha seguida inmediatamente por un salto de línea. No creo que haga falta comprobar todo lo que venga detrás, sencillamente, con obligar al usuario a escribir la fecha y luego justo después, pulsar "Intro", sería suficiente.

Sí, lo sé. Pero estoy convencido de que debe haber una solución no iterativa al problema, y el no encontrarlo me está sacando de quicio, jeje. Cuando tenga más tiempo lo intentaré de nuevo.

Es orientado a objetos porque el uso de objetos forman el núcleo del lenguaje... pero, también acepta muchos otros tipos de programación, sobre todo gracias a la plantillas: programación funcional (contenedores, functores y algoritmos basados en rango), cómputo basado en tipos (metaprogramación), estructurada (estilo C), etc. Pero tu característica más fundamental (aunque no la más potente para mi gusto xD), es la orientación a objetos.

Pues yo he intentado hacer una versión no iterativa (ni recursiva, claro), de éste algoritmo, con alguna cadena finita de operaciones binarias... y casi pierdo la cabeza.

Primero "duplicaba" la máscara (por ejemplo, 0x6) para que tuviera mismo ancho que el `unsigned` con el que me comparo (por ejemplo, 0x66666666), y luego realizaba el XOR con el número original.

Como el XOR lo que hace es filtrarte los bits diferentes, estuve intentando construir otra máscara con un AND (para obtener los bits "iguales"), y luego, con algún tipo de resta y AND entre ambas máscaras, conseguir que los bits que han superado ambos test, se "sumen" (que deben estar exclusivamente encerradas en las cuartetas que no sean 0x6), de modo que al aplicar ésta máscara final con el número original, solo se hagan a cero las cuartetas oportunas.

¡Pero no hay forma! Os reto a que lo intentéis (una versión no interativa de éste problema --excepto quizás para construir una máscara original). De verdad, me parece increíble que algo tan trivial sea tan escurridizo.

Eso de los namespace si que esta prácticamente prohibido al programar librerías , porque el código de la librería podría entrar en conflicto con la del usuario. Pero no entiendo porque un programa sencillo no se puede usar eso...

De hecho, como bien dices, yo lo uso en código de usuario, y si hubiese un conflicto con una librería que no utilice yo directamente (librería utiliza indirectamente por las librerías que yo he añadido conscientemente), siempre puedo "evitar el conflicto con `::mivariable`, para indicar que la variable `mivariable` está en el espacio de nombres global.

En código de librería también estoy de acuerdo contigo en que no se debería usar, pero con un matiz: sólo en ficheros de cabecera. En ficheros de implementación (los `.cpp` de la librería), sí que creo que se podría utilizar sin problemas.

Aunque yo no domino mucho los matices de los espacios de nombres, he visto que muchas librerías importantes (sí, a veces me enfado tanto con los errores de ejecución que a veces me embarco en la horrorosa aventura de mirar el código fuente de una librería), utilizan nombres de espacio anónimos en los `.cpp`, porque los espacios de nombres anónimos hacen que todos los símbolos en él tenga enlazado estático, lo que significa que desde otras unidades de compilación no se puedan acceder a ellos:

Código (cpp) [Seleccionar] Expandir


// libreria.hpp
namespace libreria {

    class loquesea {
    public:
         void fun1();
         void fun2();
    };
}

// libreria.cpp
#include "libreria.hpp"

namespace {
   using namespace std; // Al fin y al cabo, ahora el usuario es el implementador de la librería.

   // Clases y funciones auxiliares que realmente hacen el trabajo.
}

namespace libreria {

    void loquesea::fun1() { /* Implementacion utilizando las clases/funciones auxiliares */ }
    void loquesea::fun1() { /* Implementacion utilizando las clases/funciones auxiliares */ }

}

De ésta forma, todo aquello que vaya más allá de la interfaz pública con el usuario, es innacesible desde fuera, debido a que los símbolos del espacio de nombres anónimo tienen enlazado estático, y por tanto, pertenecen solamente a "ésta unidad" de compilación, como cuando declaras una función externa "static". Incluso los símbolos de la `std`, como se han "introducido" dentro de un espacio de nombres anónimo, desde fuera tampoco están visibles, y el usuario final (a no ser que escriba `using namespace std` en su código), no tendrá conflictos ni con la librería, ni con la `std`.

Es una forma se reduce muchísimo la cantidad de símbolos que el enlazador tiene que buscar.

• Hacer tus propios experimentos: http://coliru.stacked-crooked.com/
• cppreference.com
• stackoverflow.com

Hay tantas situaciones que no creo que exista ningún libro lo suficientemente bueno, y para los detalles "de nivel medio", cualquiera te puede valer.

Lo más importante es saber "qué está pasando" en tu programa, y conocer bien `printf` es un buen comienzo, así que repasa todas sus opciones con detalle. ¡O utilizar un debuggeador como `gdb`!

Pero no te enfades xD (sé que en realidad no te enfadas). Y perdona, a veces soy muy precipitado... cosas del dormir poco.

Ok. ¿Y no puedes "ver" qué devuelve la función `escritura`? ¿Qué devuelve, un fichero temporal?

De todas formas, como esa función `escritura()` devolverá un `FILE*` (sea el fichero temporal o no), sencillamente, haz una copia de ese fichero en disco y ponle un nombre. Añade el siguiente código justo después de llamar a dicha función `escritura()`:

Código (c) [Seleccionar] Expandir


// Es decir, justo despues de que obtengas el fichero para que lo leas.
FILE* fichero = escritura();

FILE* copia = fopen("micopia.txt", "w+");

long pos = ftell(fichero); // Guardamos la posicion actual de `fichero`.

char buff[100]; // Buffer para leer de 100 en 100 caracteres.
unsigned leidos; // Si leidos == 0 (valor devuelto por `fread`) es que hemos llegado al final del fichero.

// Copiamos todo en el fichero "micopia.txt"
while ((leidos = fread(buff, sizeof(char), 100, fichero) != 0)
   fwrite(buff, sizeof(char), leidos, copia);

fseek(fichero, pos); // Dejamos el fichero original como estaba.
fclose(copia); // Cerramos nuestro fichero copia.

// Resto de tu programa.

Y con ésto, capturaras el fichero y crearás una copia ("micopia.txt") que puedes ver con un editor de texto cualquiera para saber qué devuelve.