Pues la manera en que lo hacen en el link que pusiste (poniendo la terminal en modo no canónico mediante tcsetattr) es la común para Linux. Podrías añadir algo como:

term_nueva.c_lflag &=  ~(ECHO);

si no quieres que se muestre el caracter tecleado. Por lo demás, es una opción muy válida.

No había visto tu respuesta. Supongo que ya lo solucionaste (¿?) pero veo que en otro tema decías que estabas teniendo problemas de rendimiento. Si aún no los has solucionado, me parece (al menos con los detalles que proporcionaste allá), que tu problema pide a gritos paralelización, por ejemplo, mediante hilos. No especificaste qué haces con los flotantes que lees, pero si no solamente te limitas a leerlos y pasarlos a la función que grafica, sino que además realizas operaciones sobre ellos, esto podría mejorar el rendimiento de forma importante.

No es recomendable usar la función system. Además de ineficiente, trae muchas complicaciones. En tu caso, como ya te dijeron, es por la variable de entorno. Podrías pasarla explícitamente: system("read REPLY");

Pero de cualquier forma esto no arregla el problema de fondo. Lo que pasa es que system crea al menos un nuevo proceso (de hecho, 2: uno para el shell y otro para el comando), con sus propias variables de entorno, y demás. Aunque se ejecuten dentro de la misma ventana del programa principal, son procesos independientes, y no es nada fácil la intercomunicación, pues se ejecutan de forma secuencial, y cuando system regresa, los procesos hijos ya se han destruido. Quizás en tu programa esto es aceptable, pero en la enorme mayoría de los casos, system es la solución incorrecta.

¿Realmente has probado el programa a ver si funciona lento? Porque si eres nuevo en el lenguaje, optimizar va a complicar las cosas.

Porque hay unas cuantas maneras de acelerarlo. Primero, no leer el archivo línea a línea ni número por número sino en bloques grandes, y luego procesar los bytes desde RAM. Los procesadores modernos tienen instrucciones muy eficientes para ello, a las que se puede acceder mediante funciones especiales (intrinsics), y aunque no son estándar de C++, todos los compiladores modernos las proporcionan. Esto podría hacer el proceso unas 5-10 veces más rápido que usando fscanf o streams. El problema es que es demasiado complicado para alguien que empieza.

Hay algunas cosas más sencillas que podrías probar, siempre que de verdad lo necesites. En Google o en cualquier manual de C puedes encontrar explicaciones de las funciones que voy a mencionar.

Preguntabas sobre la eficiencia de fscanf, y la verdad es que depende. Varia según el tipo de datos a leer y el compilador. Para números de punto flotante, fscanf suele ser bastante más rápido que usar streams (inputFile >> flotante), así que si quieres leer directamente del archivo esa podría ser una opción a probar.

Otra cosa que se suele hacer es, como te dije al principio, leer bloques de bytes grandes de una vez (incluso el archivo completo, dependiendo de su tamaño). En este caso ya no usarías ni fscanf ni el operador >> . Podrías usar sscanf, que funciona como fscanf, pero lee desde un buffer de memoria en lugar de un archivo. El detalle es que, como estamos hablando de bloques grandes de bytes, para que sscanf funcione eficientemente, antes habría que modificar el buffer (en tu caso, básicamente sustituir los '\n' por '\0'). Aún así, seguro que sería más eficiente que las opciones anteriores. Otra forma sería usar strtok, para irte saltando los espacios y comas, y la función stof (o atof, que es más rápida, pero no detecta errores) para convertir el texto en floats. Creo que esto podría ser unas 2 o 3 veces más rápido que las soluciones obvias (fscanf/operador >>). Eso sí, si no lees el archivo completo de golpe, es posible que a veces los bloques leídos terminen a la mitad de una cantidad. No es difícil detectar esto, pero hay que tenerlo en cuenta.

Todo esto es de C, porque C++ ofrece alternativas (std::regex, std:: string y sus funciones como find_first_of, find_first_not_of, etc.) que muchas veces son más completas o seguras, pero precisamente por eso, suelen ser más lentas si lo que quieres hacer es algo simple, como en este caso.

Lo dicho, cualquiera de estas opciones hace el problema más complejo, aunque me parece que estas últimas que te puse son asequibles con leer un poco. Pero como escribí al inicio, primero deberías comprobar que de verdad necesites optimizar.

Si te interesa realmente el tema, también yo te recomendaría que leas por lo menos algún libro básico, porque, como dijo Serapis, sigues asegurando cosas (incorrectas), a pesar de que, como tú mismo has dicho, ni siquiera sabe sabes programar.

Ahora, respondo algunos puntos.


No, no es así. Al girar, la perspectiva cambia, aunque sea de forma sutil. Si no lo has notado (y hay varias razones para eso) es otra cosa, pero claro que cambia, y eso en una pantalla es aún más notorio que en el mundo real, así que los juegos tienen que calcular esa perspectiva sí o sí.


Aquí está lo que te decía. Afirmas que es fácil o al menos relativamente fácil, y que "simplemente" tienes que establecer las distancias, cuando en realidad, de simple no tiene nada. Como ya te dijo Serapis, no es práctico hacerlo. Calcular todas las imágenes posibles, tendiendo en cuenta que en 3D tenemos 3 ejes , y que hay que calcular todas las combinaciones posibles, la cantidad de memoria requerida sería enorme, y el resultado sería bastante inútil para un juego, ya que con esto sólo habrías obtenido las imágenes desde un punto concreto. Si el jugador da un paso a la izquierda, o adelante, o a donde sea, eso cambia completamente la perspectiva de todos los objetos en pantalla, por lo que necesitarías un conjunto de imágenes distinto para cada punto posible. La cantidad de memoria requerida lo hace prácticamente inabordable. Y de todas formas, como también te dijo ya Serapis, la diferencia de velocidad entre la memoria y la potencia de CPUs y GPUs haría que, con toda probabilidad esta "solución" fuera mucho más lenta que realizar los cálculos en tiempo real, como se hace en la actualidad. Y ni hablemos de sombras, brillos o reflejos...

Lo de los desenfoques y demás tampoco es muy útil. No sólo son efectos relativamente costosos, en términos de procesamiento, sino que los ángulos de visión, puntos muertos, etc. dependen de la persona, del tamaño de la pantalla, y la distancia a la que esté sentada, además de que nada impide que en cualquier momento dirija la vista a cualquier punto de la pantalla, cosa que el juego no puede predecir. Y si cuando hablabas de seguimiento ocular te referías realmente a usar algún dispositivo físico, estaríamos creando más problemas de los que supuestamente resolvemos: hacer que el jugador tenga que invertir en un aparato potencialmente invasivo, inseguro, y a ver si tiene la velocidad necesaria para no introducir una latencia notable...


De nuevo, no. Depende de cada caso, pero por lo general, especialmente en mundo abierto, y precisamente aprovechando el hecho de que en el mundo real nuestra visión es limitada, los juegos muestran modelos de distintas "resoluciones" (número de polígonos) según las posiciones de los objetos en pantalla, e incluso, como te dijo Serapis, a veces simplemente texturas planas. A medida que el jugador camina hacia ellos (y por ende, los "enfoca" mejor) se van mostrando modelos de mejor calidad.

Te reitero, si quieres entender el tema, lee algún libro. Sin saber siquiera programación, no es muy racional creer que se te va a ocurrir alguna solución que nadie más haya pensado antes (lo digo por aquello que pusiste de "Una nueva rama de la ciencia del 3d simulado"), cuando cientos, sino es que miles, de expertos, entre matemáticos e ingenieros, llevan estudiando estos asuntos desde hace décadas, cuando no siglos. Todo lo que has comentado, incluyendo lo del campo de visión de los ojos y los puntos muertos, es bien conocido desde hace décadas al menos. Si algunas de tus ideas no se han implementado, es porque se encontró que no eran realmente útiles, o que había alternativas mejores, no porque a nadie se le hayan ocurrido.

Es que no estás siendo del todo claro, y así es difícil conseguir respuestas concretas. Esto:


es confuso. Das a entender que quieres que las instrucciones de los dos .exe se unan en uno sólo y se ejecuten como un único proceso. Por muchas razones, difícilmente vas a encontrar un programa general que lo haga (con un .dll sería otra cosa, pero tú hablas de dos .exe), y tampoco creo que sea realmente lo que quieres.

Imagino que más bien lo que necesitas es simplemente que al abrir la aplicación ejecute los dos .exe simultáneamente (aunque obviamente sería como dos procesos distintos y lo de la inyección aquí no pintaría nada), que es más o menos lo que hace el programa del último link que pusiste. Si es así, como ya te dijeron, busca binders o joiners, que seguro alguno habrá que haga lo que quieres.

Ahora, si sabes programar y te mueves con soltura dentro de la API de Windows, es relativamente sencillo hacer un programa que haga precisamente eso: a partir de dos .exe, generar un programa que los ejecute de manera simultánea. Si no encuentras nada hecho y te interesa probar a programarlo, te podría dar alguna orientación. No el código completo de un programa, pero sí alguna ayuda, que al final se supone que es el objetivo del foro.

Como ya te dijeron, no hay forma estándar ni portable. O usas bibliotecas multiplataforma, como las que ya te mencionaron, o recurres a funciones específicas de cada sistema operativo. En Windows, la forma más sencilla y parecida a lo que se hace en Pascal es usar las funciones _kbhit() y _getch() (debes incluir "conio.h"). La primera verifica si hay una tecla presionada, y la segunda lee una tecla (que puede ser una de las "especiales", como Esc, las flechas, etc) sin esperar a que se presione Enter. Obviamente esto es muy distinto a lo que hace getchar().

No hay nada de malo en usar estas funciones cuando es necesario. Te lo digo porque a veces se critica de forma exagerada su uso. Sí, no son estándar de C o C++, pero es que no hay manera estándar de hacer lo que quieres, así que se justifica utilizarlas. Y conio.h es parte del runtime de C de Microsoft desde hace mucho, por lo que todo compilador para Windows que se precie la incluye, como es el caso de MinGW y, obviamente, VC++:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/getch-getwch?view=msvc-170
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/kbhit?view=msvc-170

Eso indica que no encuentra el archivo. ¿Seguro que se llama "hijo" y no "hijo.o" o algo así? Porque al parecer el ejecutable principal se llama "padre.o" (que realmente no debería tener esa extensión, pero eso es otro tema). De cualquier forma, puedes probar abriendo una terminal y desde el mismo directorio desde el que ejecutas padre, ejecuta el comando ./hijo, y ve si funciona.

En cuanto a argv, me refería a este for:

for(i=1; i<NUM_HIJOS; i++){

Como NUM_HIJOS vale 10, i tomará valores desde 1 a 9. Si al programa le pasas menos de 9 argumentos, llega un punto en el que con argv[ i ] estarás intentando ir más allá del final de argv. Nota también que el hecho de iniciar el for desde 1 significa que realmente estás limitando el número máximo de hijos a 9, no a 10, aunque creo que es un detalle sin mucha importancia.

Veo que luego vas a tener que imprimir lo que read lea. Algo que causa muchos problemas es olvidar que el búfer que te da esa función no necesariamente contiene caracter nulo '\0', así que es importante verificar el valor que te devuelve (el número de bytes leídos) y, o cierras manualmente la cadena, o le indicas a printf el número de caracteres a imprimir. Por ejemplo:

if ((num_caracteres = read(fd[0], buffer, MAXBUFFER)) > 0)
	printf("%.*s", num_caracteres, buffer);

Y te reitero, los hijos deberían cerrar fd[0], y, después del dup, fd[1]. Aunque en este caso no te dará problemas, es una mala práctica no hacerlo. Caso completamente distinto al del último exit de ese case 0, que, como te dije en el mensaje anterior, es redundante (aunque tampoco hace ningún mal). Al escribir mi primera respuesta, me enfoqué en los problemas con los pipes y fork y ni siquiera me fijé en que los hijos ejecutaban execl. Obviamente, al llamar a las funciones exec*, sólo es necesario finalizar la ejecución en caso de error, lo cual ya haces.

Ese mensaje en tu programa indica que falló execl. Asegúrate de que el archivo "hijo" exista en el mismo directorio que "padre", y que sea ejecutable. Puedes ver más detalles sobre el error si después del fprintf que muestra "Error en la ejecucion del proceso hijo\n", pones:

perror("execl");

Y te digo otra vez, revisa bien el código y lee los apuntes o manuales que tengas, porque todavía hay más errores. Por ejemplo, tu read está mal, ya que el segundo parámetro debería ser una cadena de caracteres. Y a execl le estás pasando argv[ i ]: tal y como tienes el for, eso es incorrecto. Revísalo bien y verás por qué.

Los procesos hijos deberían terminar con _exit o exit, no con return; no sé por qué cambiaste eso. De cualquier forma forma, esa última línea del case 0 no debería retornar EXIT_FAILURE; eso es sólo cuando se finaliza con error. Y ahora que lo vuelvo a ver, estrictamente hablando, en tu programa no necesitarías ese último exit (o return), ya que los hijos están llamando a execl (que los reemplaza por procesos nuevos), pero de todas formas es importante acostumbrarte a finalizar siempre todos tus procesos hijos.

Pues se usa igual que con cualquier tipo de archivo:

read(fd[0], buffer, NUM_BYTES);

Al margen de eso, revisa bien tu código y apuntes que tengas, ya que tiene varios errores. Por mencionarte algunos:

Siempre es importante cerrar los descriptors no usados, así que los hijos deberían cerrar fd[0]. De igual forma, después del dup, ya no usas fd[1] directamente (execl usa el descriptor de stdout, que apunta hacia tu pipe), por lo que también es mejor cerrarlo. Por cierto, dup2 es más recomendable que dup, aunque esto es sólo un consejo.

Estás cerrando fd[1] desde dentro del bucle, lo que significa que, a partir de la segunda iteración, estarás intentado duplicar un descriptor ya cerrado. Ese close debe ir fuera del for.

No estás terminando los procesos hijos, así que algunos de ellos van a crear sus propios procesos hijos, además de ejecutar lo que está fuera del bucle, adonde, se supone, sólo debería llegar el padre. Así que debes agregar un exit al final del case 0. Ya que estamos, normalmente es preferible que los procesos hijos finalicen con _exit en vez de exit. En tu caso no lo cambies, pero tenlo en cuenta. Si en algún ejercicio posterior tienes problemas (por ejemplo, que los mensajes salgan repetidos), busca las diferencias entre ambas funciones, ya que ahí podría estar la solución.