Esto no es técnicamente correcto. Ahí estás indicando que las variables num, x y result van a utilizarse para manejar números con signo de un tamaño ( generalmente ) de 32 bits.

Es decir, ahí no estás asignando valores, solo reservando memoria para esas variables. De hecho, si haces un printf ... o un cout de cualquiera de esas variables antes de hacer el scanf verás que suelen tener valores extraños... eso es porque la memoria se ha cogido tal cual, sin inicializar.

Debido a que en c y c++ la memoria no se inicializa es necesario hacerlo de forma manual en numerosas ocasiones, como cuando vas a manejar punteros, para evitar resultados extraños.

Con lo cual, en tu programa sólo le das valor a num en la línea 8.

jajajajaja.

Por curiosidad, cuántos bytes ocupan los datos que envías ??

si son una docena o incluso unas pocas centenas de bytes olvídate de optimizar, ya que el rendimiento va a ser prácticamente el mismo y a cambio te vas a complicar bastante el envío.

Me explico:

Las redes, sean del tipo que sean, tienen definido un tamaño máximo del paquete de datos que puede circular por ella (MTU).

Si tu envías un paquete de menor tamaño este circula sin problemas... si intentas enviar uno más grande, el equipo tiene que trocearlo en paquetes más pequeños que se envían de forma individual.

El problema cuando se trocean los paquetes depende del protocolo utilizado ( TCP o UDP ):

* TCP es un protocolo negociado, no se pierden paquetes y todos llegan ordenados, pero es lento por toda la negociación que lleva asociada... en este caso trocear paquetes implica un período de latencia mayor y para determinadas aplicaciones esto es un problema.

* UDP es un protocolo más crudo, la negociación la tienes que programar tú, los paquetes pueden perderse e incluso llegar desordenados. Debido a la falta de negociación, el protocolo es bastante más rápido. El problema asociado a este protocolo viene de que no posees control sobre los paquetes troceados... pueden producirse problemas si se pierde algún paquete...

Para que te hagas una idea, valores normales de MTU son 576 y 1500 bytes. En redes locales el valor normal es 1500.

Enviar un paquete de 1500 bytes a través de una red local típica ( 100 Mbps ) llevaría ( 1500 * 8 ) /  1e8 = 0,00012 s = 0,12 ms ( milisegundos ).

Si en vez de enviar 1500 bytes consigues reducirlo a 1000 el paquete se enviará en 0,08 ms.

En serio te compensa complicarte la programación del envío y la recepción de los paquetes para ahorrarte 40 microsegundos por paquete??

Aún así, en el caso de que tuvieses que enviar paquetes grandes ( imagínate que necesitas enviar un archivo ), la opción más empleada es dividir el archivo en paquetes de un tamaño preestablecido ( por ejemplo 400 bytes ) y enviar cada uno de esos paquetes tal cual. Luego en el receptor se reensambla el fichero y listo.

Nota: Y antes de que alguno me salte a la yugular, la conversión de Kb a b depende del medio... en memorias y discos hay que dividir por 1024, en redes el factor es 1000.

o eso o aprende a limpiar el buffer de entrada antes de hacer una lectura...

Existen varias formas de limpiar el buffer de entrada... algunas gustan más, otras gustan menos y otras dan problemas en según que plataformas.

Si te interesa aprender a hacer esto, hay un tema en el foro que ya lo comenta:
http://foro.elhacker.net/programacion_cc/lo_que_no_hay_que_hacer_en_cc_nivel_basico-t277729.0.html

Exacto, yo es que vengo de un proyecto donde las aplicaciones tienden a ser monstruosas y es fácil encontrarse una docena de breaks en un for... se te cae el alma a los pies cuando tienes que depurar eso XDDDD

Pues depende.

Si lo almacenas en memoria necesitas 64 bits por cada número, cógete el tamaño medio y máximo ( o aproximado si eres capaz de calcularlo ) y multiplica ese numero por 8 para calcular los requisitos de memoria.

Si lo almacenas en un archivo de texto tienes dos posibles escenarios:

* Se almacena como un archivo binario, los requisitos de espacio son los mismos que los calculados antes, 8 bytes por número.

* Se almacena como archivo formateado ( XML, INI, TXT legible, ... ) Depende del formato elegido, pero como norma general será siempre superior a ( 10 + 1 ) * cifras_en_el_diccionario. El 10 sale del número de cifras que tiene el archivo de texto y el suponiendo un carácter de separación ( lo normal es que acabe siendo más de uno )

Vaya, veo que no has usado nada de lo que te puse... la próxima vez me ahorro el esfuerzo.

        cuatro_en_linea(tablero,opcion);
        sumador++;
        ganadores[ganador].jganador=cuatro_en_linea();

La función cuatro_en_linea sin argumentos no existe...

deberías eliminar la primera llamada y dejar la segunda, en la que estableces jganador, con los dos argumentos de la primera.

... por eso se llama c++ ( c = c + 1 )

Aún así... si alguien me dice que aprende más rápido c++ que c es porque no está aprendiendo lo que sucede por debajo cuando alguien crea una clase.

Esto se ve con facilidad cuando muchos no entienden que sea más óptimo pasar una clase a una función una referencia constante en vez de por valor.

C++ tiene muchísimas más cosas que C y para comprenderlos al mismo nivel el esfuerzo a realizar en c es siempre inferior.

Vale que manejar arrays de tipo char para las cadenas es algo confuso al principio... pero debe ser lo único... con c++ seguro que podemos sacar muuuchas más cosas.

Vuelvo al ejemplo, si alguien dice que sabe usar clases de c++ pero no sabe la diferencia entre un constructor copia y un operador de asignación... no sabe usarlas y, en el mejor de los casos, hará un uso incorrecto e inadecuado de ambos por mero desconocimiento.

Creo que es peligroso que alguien crea que controla sobre algún tema cuando realmente solo ha alcanzado a arañar la superficie.

jajajajajaja

si, dar una idea equivocada de lo que se intenta hacer suele dar malos resultados

Eso lo entiendo, pero claro, uno que está empezando no puede decir que sabe programar.

Hasta que no controla un mínimo todas esas cosas... que son conceptos clave del lenguaje no puede decir que sabe programar en c++.

Me baso simplemente en esto para decir que aprender c++ es más difícil que aprender c