TCHAR buffer[512] = "";
	DWORD largo_buffer;// = MAX_PATH;

largo_buffer debería contener el tamaño máximo del buffer... y sin embargo la variable está sin inicializar, eso puede provocar que se pise memoria al leer datos del registro. Por cierto, "largo_buffer=MAX_PATH" seguirá estando mal, ya que el tamaño que estás asignando al buffer es 512.

Además, creo recordar que estas funciones trabajan con wchar_t, no con char... sería conveniente poner el prefijo "L" al string de la ruta: L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall"

Por lo demás no he visto nada raro.

Un saludo.

Si lo piensas, no es escusa. No vas a conseguir hacer nada por tu cuenta si no eres capaz de leer y entender la documentación de una API.

¿Que cuesta? sí, pero es un paso necesario y después verás que no es para tanto. Lo que está claro es que si sigues vendiendo que eres novato para justificar el echo de no perder ni 2 minutos en leer la documentación de una función... de la librería estándar... te vas a acabar estrellando contra un muro. Yo únicamente te aviso.


A diferencia de algo tangible y material, el código es algo virtual que no tiene forma, el código crea un universo propio en el que todo está conectado con todo y en el que se exige una armonía casi total entre los diferentes elementos del programa para que éste no de problemas... las chapuzas en programación no solo pueden dar resultados inesperados en cualquier momento... su corrección a posteriori puede resultar traumática porque sus efectos se pueden propagar de forma similar a como lo puede hacer un cáncer.

Por este motivo te digo que no, no es lo mismo hacer algo bien a hacer una chapuza y dejarlo así simplemente porque funciona. Obviamente tú, en calidad de autor de la aplicación, puedes hacer y dejar todas las chapuzas que quieras en tu código, pero luego cuando tengas que lidiar con fallos anclados en estas chapuzas recuerda lo que te estoy diciendo.


Especificación http ver 1.1

Si vas a trabajar con el protocolo http, la especificación de dicho protocolo debe ser la base de tu documentación. Después seguramente necesites material adicional, como ejemplos o comentarios de gente que ya se haya pegado con eso... pero la base es fundamental para entender lo que estás haciendo... si no es intentar entender un libro de astronomía sin tener ni idea de matemáticas, física, geometría, ...


Intentas ir demasiado rápido, y no lo digo por este tema en concreto sino por todos los que has creado en este foro. Aprende primero la base con ejemplos más sencillos y con más tranquilidad podrás lanzarte a la aventura.

Da la sensación de que tus únicos objetivos en este foro pasan por sacar partido sin aportar absolutamente nada ( es decir, te sacamos las castañas del fuego, tus programas funcionan y después, si te he visto no me acuerdo ). Y si no no hay más que ver otros hilos, en lo que lo único que te preocupaba era que alguien te diese la respuesta concreta y exacta a tu pregunta... nada de darte ideas sobre cómo resolverlo...


Nuevamente te falta leer la documentación. En este caso referente a sockets: documentación recv

Tu estás partiendo de la base de que el contenido recibido por un socket nunca va a ser binario... y eso es un error. Por un socket puedes enviar contenido binario sin ningún problema. Ello implica que los sockets no tienen por qué terminar las cadenas de envío/recepción con un '\0'. Es por eso que recv te retorna la longitud exacta de lo que almacena en el buffer.


Si tu buffer es de 20000, por muy bien que quieras hacer el resto ya tienes un problema.

Además, si te fijas, verás que su respuesta está comprimida con gzip... ¿ves como es importante conocer la especificación?

Y para terminar, por si acaso matizo: No intento ser borde, los foros son fríos porque no transmiten ni emociones ni lenguaje no verbal.

Y sí, me he leído tu mensaje hasta el final

Un saludo.

Deberías plantearte dejar de imitar a firefox y leerte la especificación http... ya que es ahí donde vas a ver para qué sirve cada uno de los elementos que componen una cabecera http, cómo se usan, cuándo hay que usarlos y cuáles son obligatorios y por qué.

Además, como te han recomendado, una de tus prioridades debería ser simplificar el código y crear un control de flujo limpio, ordenado y fácil de mantener.

Y, por cierto, ¿qué es toda esa basura que sale en tu respuesta al final de cada petición?

Lo más sencillo es leer la totalidad del fichero en memoria, creando una colección de instancias de "alumno" en el proceso, después modificas esta colección a placer y por último sobreescribes el fichero, borrando todo lo anterior y guardando lo que tienes actualmente en memoria.

No afecta... pero tampoco aporta nada... un parámetro de una función o una variable que declares únicamente pueden ser tipos nativos (int, float, double...), estructuras, clases y/o templates (que para el caso es como si fuesen clases)... los tipos nativos son conocidos por todos, luego si no es un tipo básico está claro que vas a a tratar con un objeto.

Si quieres un control total, con todas las consecuencias, la mejor opción es pasarse a linux

Opción 1: ordenamiento explícito

Nos aprovechamos de la función "sort" definida en la librería algorithm. A esta función necesitamos pasarle una función que defina la forma en la que han de ser ordenados los elementos.

#include <algorithm>
 
// ...
 
bool SortData( const Employees& emp1, const Employees& emp2 )
{
  return emp1.Naame < emp2.Naame;
}
 
int main( )
{
  // ...
 
  cout << "-------EMPLOYEES SORTED ALPHABETICALLY----- \n\n";
  std::sort( Data, &Data[LEN], SortData );
 
  // ...
}

Opción 2: sobrecarga de operadores

Si sobrecargamos el operador '<' de la clase "Employees", podemos ahorrarnos la función "SortData" definida en el ejemplo anterior:

 
struct Employees
{
    string Naame;
    unsigned int age;
    char sex;
 
    struct Direction home;
 
    bool operator<( const Employees& otro ) const
    {
      return Naame < otro.Naame;
    }
};
 
// ...
 
int main( )
{
  // ...
 
  cout << "-------EMPLOYEES SORTED ALPHABETICALLY----- \n\n";
  std::sort( Data, &Data[LEN] );
 
  // ...
}

También se puede sobrecargar el operador fuera de la estructura... en ese caso es necesario que la función sea binaria (2 operadores):

struct Employees
{
    string Naame;
    unsigned int age;
    char sex;
 
    struct Direction home;
};
 
bool operator<( const Employees& emp1, const Employees& emp2 )
{
  return emp1.Naame < emp2.Naame;
}

Otras consideraciones:

* En C++ no hace falta usar "struct" cada vez que quieres crear un nuevo elemento de tipo "Employees".

* En C++ es mejor usar "const" a "define". El motivo es que "define" no indica el tipo de valor ( entero, decimal, ... ) y eso puede dar lugar a resultados no esperados en el código.

* El parámetro "i" que pasas con tanta alegría en las 3 funciones te lo puedes ahorrar... se pueden declarar variables sin miedo dentro de las funciones.

* Salvo causas de fuerza mayor, yo sustituiría los usos de "char*" en la dirección por "std::string".

Edita el código y utiliza las etiquetas GeSHi de C++ para que el código se pueda leer sin dejarnos la vista, por favor.

Y aunque suene a obvio, lo comento por si acaso... estos cálculos tienes que hacerlos con float o double... si los haces con int vas a obtener resultados incorrectos al perder los decimales.

No hace falta hacerlo así. Te lo demuestro:

supón un cambio de 265. esto son un billete de 200, uno de 50, una moneda de 10 y otra de 5

cambio = 265
billetesA = 265 / 200 = 1 <-- 1 de 200
 
sobra = 265 % 200 = 65
billetesB = 65 / 100 = 0  <-- 0 de 100
 
sobraB = 265 % 100 = 65
billetesC = 65 / 50 = 1   <-- 1 de 50
 
sobraC = 265 % 50 = 15
billetesD = 15 / 20 = 0   <-- 0 de 20
 
sobraD = 265 % 20 = 15
monedaA= 15/10 = 1        <-- 1 de 10
 
sobraE = 265 % 10 = 5
monedaB = 5 / 5 = 1       <-- 1 de 5
 
sobraF = 265 % 5 = 0
monedaC = 0 / 2 = 0       <-- 0 de 2
 
sobraG = 265 % 2 = 0
monedaD = 0 / 1 = 0       <-- 0 de 1