Barrapunto

Bueno... tampoco hay que ponerse asi, que la gente no nace aprendida. Unos comentarios:

1. A veces pongo if(TRUE==a) por legibilidad; dependiendo del tipo de 'a' puede serle util al mantenedor de la aplicacion.
2. Ahi tienes razon... a veces. En un desarrollo hecho por el mismo equipo me gusta aplicar la norma de "Lo ya comprobado en una capa superior no se comprueba en una capa inferior" pero en una libreria, o si el codigo de un equipo lo usa otro equipo diferente prefiero comprobarlo todo. Al menos con sentencias ASSERT.
3. Y bueno... lo de poner return puede tener su sentido para no ver el tipico "warning: main does not return nasti de plasti" y no tener que biscar el #pragma warning de turno.
4. Y si... la espera activa es de lo peor que se puede hacer; si no se quiere meter en berenjenales con un Sleep() bien colocado alivia la carga, aunque sigue siendo un tanto chapucero :/
5. Aqui te doy toda la razon... las variables globales -e incluso las variables de clase si se usan como variables globales- son la puerta al infierno.
6. Bueno... la gente tiene que cometer errores para aprender.

1. El escribir la constante a la izquierda y la variable a la derecha es una "buena práctica" porque hace que los errores al confundir == con = salgan al compilar. Parece una tontería pero truquillos como este ahorran un montón de tiempo de depuración.
2. Ya, bueno, yo hablaba en general :P

3, 4, 5, 6: Ok.

Mmm, de vez en cuando se ven cosas interesantes entre tanto ruido como esta entrada y sus comentarios. Mi enhorabuena.

Al respecto del tema, un punto que no consigo ver es el del 100% de procesador consumido. Que hasta que no termine el hijo espere, fale, pero... ¿que esa espera sea activa? Where? Veo por ahí un waitpid(), que si no me falla la memoria bloquea a menos que especifiques alguna opción.

En general estoy bastante de acuerdo contigo, pero voy a poner yo algo de mi cosecha:

X+1) 0 no es lo mismo que NULL.

X+2) Las cosas pueden y suelen fallar. ¿Qué pasa si falla el exec()? Eso sí se puede llamar consumir CPU, y es solo un mal menor, porque el fork() debería estar protegido en la siguiente iteración al no existir la variable de entorno.

En resumen, muy mejorable, pero como dicen, nadie nace aprendido.