2010-09-26 6 views
3

J'utilise déjà certaines nouvelles fonctionnalités de C++ 0x dans Visual C++ 2010, comme les expressions régulières ou les fonctions lambda. Mais il y a une caractéristique majeure qui manque: l'<thread> en-tête.Espace réservé pour l'en-tête <thread> de C++ 0x dans MSVC++ 2010

Connaissez-vous un code qui pourrait agir comme de remplacement? Pour le moment j'utilise le thread de boost, mais ce n'est pas exactement le même que le standard, et ça me donne d'énormes temps de compilation. J'ai aussi trouvé juste du fil, mais étant un amateur je ne veux pas dépenser d'argent dessus.

Je ne pense pas que ce serait trop difficile à coder (bien que je puisse me tromper) mais je ne connais pas suffisamment l'API Win32 pour le faire.

Répondre

5

J'ai utilisé boost::thread dans le code de production des performances sensibles et il est beaucoup plus sophistiqué et performant que tout ce que nous aurions pu nous construire en une quantité raisonnable de temps.Le verrou lecteur-écrivain en particulier est une chose de beauté imo. Vous avez l'avantage supplémentaire que the person who wrote the code et the book sont actifs sur Stack Overflow, si vous avez besoin d'aide.

Depuis que vous êtes sur Windows, vous pouvez améliorer les temps de compilation en utilisant judicieusement Visual Studio precompiled headers, pour éviter le chargement répété des en-têtes Boost.

+3

'+ 1' pour" ... beaucoup plus sophistiqué et performant que tout ce que nous aurions pu nous construire dans un laps de temps raisonnable. " Les gens oublient souvent combien de connaissances et d'expérience ont été mises dans tout ce qui a réussi à passer l'examen de boost. Tout ce qu'un département de développement d'une seule entreprise peut proposer est forcément inférieur. Et le problème est que vous pourriez ne le savoir que lorsque, des années plus tard, quelqu'un aura besoin de ce code porté sur la plate-forme X, dont aucun d'entre vous n'a d'expérience. – sbi

-1

Vous pouvez utiliser les fonctions de threads win32. Il est plutôt simple à utiliser et ne nécessite que quelques appels de fonction pour fonctionner. Une recherche rapide sur google devrait résoudre tous vos problèmes.

+3

comment est-ce préférable? – jalf

4

Je pense que boost::thread est votre meilleur pari. C'est testé à fond, et le std::thread est basé dessus. Vous devriez juste garder à l'esprit les différents domaines et essayer de traiter avec eux le mieux possible.

Comme spécifié here:


La conception de ce fil est une évolution de boost :: thread. L'intention est de réutiliser autant de l'expérience boost :: thread que possible, en gardant le bon, et en changeant le minimum nécessaire pour répondre aux limites connues de cette expérience de terrain.

  • La sémantique non reproductible, d'un-mappage-mappage-à-un-os, d'un boost est conservée. Mais ce fil est mobile pour permettre le retour du fil des fonctions d'usine et le placement dans des conteneurs.
  • Cette proposition ajoute une annulation au boost :: thread, qui est une complication importante. Cette modification a un impact important non seulement sur le thread mais également sur le reste de la bibliothèque de threads C++. On croit que ce grand changement est justifiable en raison de l'avantage.
    • Le destructeur de threads doit maintenant appeler annuler avant de se détacher pour éviter toute fuite accidentelle des threads enfants lorsque les threads parents sont annulés.
    • Un membre de détachement explicite est maintenant requis pour permettre le détachement sans annulation.
  • Les concepts de handle de thread et d'identité de thread ont été séparés en deux classes (ils sont de la même classe dans boost :: thread). Ceci pour faciliter la manipulation et le stockage de l'identité de thread.
  • La possibilité de créer un ID de thread qui garantit une comparaison égale à aucun autre thread joignable a été ajoutée (boost :: thread ne l'a pas). C'est pratique pour le code qui veut savoir s'il est exécuté par le même thread qu'un appel précédent (les mutex récursifs sont un exemple concret).
  • Il existe une "porte arrière" pour obtenir le handle de thread natif afin que les clients puissent manipuler des threads en utilisant le système d'exploitation sous-jacent si vous le souhaitez.
Questions connexes