¿Pro Linus Torvalds? ¡Dios me libre! No creo que nadie dude que es un excelente programador de C, pero el generalizar sobre C++ de la manera en que lo ha hecho en el pasado le hace un flaco favor a la verdad. Desde luego, no es un lenguaje perfecto, ni mucho menos, pero ese es otro debate...

Respecto a:

Saber C++ de forma avanzada debería incorporar saber C de forma avanzada también, aunque gestione la memoria de forma distinta.

No estoy de acuerdo. Voy a citar del C++ FAQ Lite:

Fundamentally it boils down to this simple fact: C++ is not C. That means (this might be painful for you!!) you'll need to set aside some of your hard earned wisdom from your vast experience in C. The two languages simply are different. The "best" way to do something in C is not always the same as the "best" way to do it in C++. If you really want to program in C, please do yourself a favor and program in C. But if you want to be really good at C++, then learn the C++ ways of doing things. You may be a C guru, but if you're just learning C++, you're just learning C++ — you're a newbie. (Ouch; I know that had to hurt. Sorry.)

En el caso específico del paso de C a C++ (o viceversa), es especialmente cierto que uno tiene que "olvidarse" de ciertas prácticas que en el anterior lenguaje eran el pan de cada día. Por poco seguras, poco productivas, poco eficientes o cualquier combinación de las anteriores.

En lo relativo a la memoria, es importante saber que malloc no llama al constructor del tipo en cuestión (ni free a su destructor), no devuelve punteros del tipo en cuestión, y no permite ser sobrecargado para el tipo en cuestión. Luego, tratar a new/delete como los equivalentes a malloc/free en C++ es un error.

Precisamente la gestión de memoria es uno de los aspectos en que los métodos disponibles en C++ son muy superiores a los disponibles en C. Por ejemplo, salvo muy honrosas excepciones, por defecto uno jamás tendría que llamar a delete o delete[] manualmente en C++.

Sabes que tienes un nivel avanzado de C++ cuando puedes bajarte el codigo fuente de librerias (SDL, glew, glut) y entenderlo. Si no, sigues siendo amateur, como todos.

No estoy de acuerdo, por dos motivos:

- Las tres librerías que mencionas están escritas en C.

- No todas las librerías, y esto es especialmente cierto en el caso de librerías escritas en C++, son las fuentes más adecuadas para aprender y/o reconocer lo que es comúnmente aceptado como "buen código" en el lenguaje en cuestión.

Dicho lo cual, personalmente creo que siempre es una experiencia enriquecedora el analizar y entender código de terceros (tanto el bueno como el malo; especialmente el bueno). Pero una cosa es entender una librería de cierta complejidad y otra crearla, y creo que el conocimiento y la experiencia son notablemente más apreciables en lo segundo.

Como ha dicho Martinez, la teoría de colas proporciona el tratamiento formal de estos temas.

Para modelar tu problema pueden ser útiles los procesos markovianos, y en particular el proceso de Poisson.

¿Estás seguro de que quieres implementar A* en Lua? Puede ser útil hacerlo en un prototipo para experimentar, pero la búsqueda de caminos es una tarea costosa computacionalmente que se presta a multitud de optimizaciones particulares y puede beneficiarse de una implementación directa en C o C++.

Normalmente, desde el lado del lenguaje de scripting interesa poder manipular y definir comportamientos tácticos/estratégicos (o, en general, de más alto nivel) de la inteligencia artificial, no implementar el corazón mismo de la búsqueda de caminos.

No es el tema del hilo, pero el orden de evaluación de los argumentos de una función es un comportamiento no especificado en el estándar de C++.

Estándar que sí especifica que el orden de destrucción de variables estáticas es el inverso al de su construcción.

Los singletones en general, y las interacciones y dependencias entre ellos en particular, suelen dar más quebraderos de cabeza que beneficios (en mi experiencia personal, pero desde luego es uno de esos temas algo "religiosos" y propensos a debates eternos).

Dicho lo cual, VC++ 6 tiene muchas carencias, y entre ellas su limitada adecuación al estándar del lenguaje.

No veo tan clara la duda entre funciones virtuales (término específico de C++) y eventos (concepto genérico implementable de varias maneras), cuando normalmente se utilizan con propósitos totalmente diferentes. Personalmente, cuando leo "eventos", inmediatamente pienso en comunicación entre entidades o, a nivel más general, entre sistemas.

En este caso en concreto, ¿qué sentido tendría tratar preRender y postRender como eventos?

Para que la función acepte arrays y no punteros:

Código [Seleccionar] Expand

template <class T, int N>
bar& foo(T (&a)[N])
{
   // ...
}

No puedes garantizar que sizeof(MyIntEspecial) == sizeof(int).

El compilador es libre de insertar el padding que considere oportuno después de una variable miembro.

Aunque los compiladores definen extensiones específicas (no estándares) para personalizar las reglas de alineamiento (#pragma pack en el caso de VS).

Respecto a la conveniencia de la sobrecarga de operadores en general, es una cuestión algo "religiosa" y que no tiene una única respuesta válida. ¿Realmente les facilita el trabajo a todos los miembros del equipo? ¿O en cambio les confunde más? Personalmente, creo que es adecuado aplicar el principio de menor sorpresa a la hora de tomar este tipo de decisiones.

Dicho sea de paso, aunque no es el tema del hilo, los singletones dan pie a la introducción de tantos problemas que es una buena práctica evitar a toda costa diseños que contemplen el uso (y en la mayoría de ocasiones, abuso) de este antipatrón.

La única diferencia entre class y struct en C++ es el nivel de protección por defecto de sus miembros y clases base (privado para class, público para struct).

Teniendo en cuenta eso, puedes utilizar una u otra indistintamente (la única excepción es que struct no puede utilizarse para identificar un parámetro de tipo en un template).

Aunque esto ya son connotaciones de estilo, en código genérico es muy habitual ver struct en lugar de class para ahorrarse el 'public:'; y muchos utilizan struct cuando la clase tiene pocos métodos y tiene datos públicos.