Con el advenimiento de las instalaciones de subprocesamiento en el STL para el nuevo estándar de C++ (C++ 0x), ¿será mejor cambiar el código existente que está utilizando el enhebrado POSIX o incluso el subproceso de Windows para usar el subproceso STL? ?C + + 0x subprocesamiento
Siempre puede cubrir sus apuestas ... escriba su propia API de subprocesos simple que es lo suficientemente característica como para hacer lo que necesita su aplicación, y cambie su código para apuntar solo a su API de subprocesos. Luego puede implementar las partes internas de su API de subprocesamiento personalizado utilizando Windows o Posix o STL o lo que sea, y cambie la implementación cada vez que lo necesite sin tener que tocar toda la base de código cada vez.
Al hacerlo de esta manera, podría comenzar con la implementación de STL, y luego si resulta que, por ejemplo, Windows tiene un problema difícil de resolver al usar eso, solo podría incluir una implementación de API de Windows alternativa dentro de my_threading_api.cpp (dentro de un #ifdef WIN32) y volvería a estar en el negocio.
Una gran cantidad dependerá de cuánto te importe la portabilidad y de cuánto aprovechas las características que puede proporcionar tu API nativa que la biblioteca estándar no ofrece. La biblioteca estándar de enhebrar es lo suficientemente similar a POSIX que (al menos de forma directa) No puedo pensar en mucho de lo que ganaría quedándome con POSIX (y debido a la similitud, portar para usar la biblioteca estándar normalmente debería ser bastante fácil).
El enhebrado de Windows es lo suficientemente diferente que es más probable que se tope con algo que no será trivial de puerto a usar con la biblioteca estándar, e incluso en el mejor de los puertos probablemente no sea trivial.
No se sabe cuánto tiempo pasará antes de que las características de la biblioteca C++ 0x sean comúnmente admitidas, por lo que la respuesta podría depender de qué tan vinculado a un compilador en particular le gustaría ser. También es posible que desee considerar un marco o biblioteca que funcione sobre la implementación de la biblioteca nativa o C++ 0x, como Boost Threads o Intel Threading Building Blocks, y deje que esa biblioteca maneje los detalles de si usa las características de C++ 0x o la plataforma APIs
No cambie a menos que realmente lo necesite. Supongo que su código actual está funcionando bien.
Depende.
C + + 0x no es ampliamente compatible aún (creo que GCC lo implementa, pero MSVC no, y no sé cuándo planean agregar ese soporte, pero sospecho que consideran es una característica de baja prioridad)
Si su código funciona como es, ¿para qué cambiarlo? Para las nuevas aplicaciones C++, y suponiendo el soporte del compilador, iría con los subprocesos C++ 0x, simplemente porque son estándar, y es una API mucho mejor que cualquiera de los subprocesos Win32 o POSIX.
Esto es lo que hemos hecho. Hemos creado nuestra propia "capa de abstracción de SO" con diferentes implementaciones de back-end para POSIX, Windows y algunos otros RTOS que utilizamos. También tenemos clases de semáforos, mutexes, temporizadores, etc. Es algo muy útil de tener. –
+1: ¡Solución muy interesante! – Alerty