Forum du club des développeurs et IT Pro - C++ https://www.developpez.net/forums/ F.A.Q C++]]> fr Mon, 26 Oct 2026 16:21:03 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.png Forum du club des développeurs et IT Pro - C++ https://www.developpez.net/forums/ Pourrons-nous enfin utiliser les modules C++ en 2026 ? https://www.developpez.net/forums/showthread.php?t=2186190&goto=newpost Thu, 15 Oct 2026 15:58:50 GMT *Pourrons-nous enfin utiliser... Pourrons-nous enfin utiliser les modules C++ en 2026 ? par Mathieu Ropert

Tous les 6 à 12 mois, j’essaie d’utiliser les modules C++, je me heurte à un obstacle, je m’en plains peut-être sur les réseaux sociaux, puis je passe à autre chose. Même après avoir regardé de nombreuses conférences sur le sujet, il y a toujours quelque chose qui vient tout gâcher. Ma plus grande réussite à ce jour a été de parvenir à utiliser le module VulkanHpp dans ma bibliothèque de rendu, après quoi tout a commencé à dérailler. Mais après avoir de nouveau fait quelques progrès la semaine dernière (et rencontré de nouveaux obstacles), j’ai le sentiment d’avoir suffisamment d’éléments pour dresser un bilan cohérent.

À titre de mise en garde, je tiens à préciser que j’ai partagé certaines de mes conclusions sur l’état actuel des modules avec d’autres programmeurs C++ et qu’ils n’étaient pas tous d’accord avec moi. Cependant, je pense que les modules souffrent d’un fort problème de « biais d’expert » qui fait que de nombreux contre-arguments ressemblent à « sur ma machine, ça marche » pour des personnes comme moi qui n’ont pas eu beaucoup d’expérience avec ce sujet et n’ont pas suivi de près le processus de normalisation. Je ne prétends pas être un expert en la matière, mais je m’y connais en systèmes de compilation et je pense avoir passé bien plus de temps à essayer de bidouiller les modules dans mes projets que le programmeur C++ moyen ; je pense donc que cet article peut parler au nom de l’utilisateur passionné moyen (ou plutôt de l’utilisateur en devenir).

Ah, et je me concentre principalement sur MSVC. Je mentionnerai peut-être brièvement Clang ou GCC, mais mon expérience se limite principalement à Windows.

Les aspects simples

Contrairement à ce que vous avez peut-être entendu, les cas d’utilisation simples sont assez faciles à mettre en œuvre, à condition de respecter un ensemble strict de contraintes. Par exemple, comme je l’ai mentionné précédemment, j’ai utilisé le module fourni par VulkanHpp dans ma bibliothèque de rendu et cela fonctionne très bien. Ou plus précisément, cela fonctionnait, jusqu’à ce qu’ils modifient quelque chose en amont, ce qui a entraîné un problème lié à l’ensemble de contraintes auquel j’ai fait allusion. Nous reviendrons sur les détails plus tard. En attendant, voici à quoi cela ressemble dans mon CMake :

Code:
1
2
3
4
5
6
7
8
9
10
11
add_library( VulkanHppModule )
target_sources( VulkanHppModule PRIVATE
  FILE_SET CXX_MODULES
  BASE_DIRS ${Vulkan_INCLUDE_DIR}
  FILES ${Vulkan_INCLUDE_DIR}/vulkan/vulkan.cppm
)
target_compile_definitions( VulkanHppModule PUBLIC
  VULKAN_HPP_NO_SETTERS
  VULKAN_HPP_NO_CONSTRUCTORS
)
target_link_libraries( VulkanHppModule PUBLIC Vulkan::Vulkan )


Je n’ai même pas eu à écrire ces lignes moi-même, elles figuraient dans la documentation du projet. Tout ce que j’ai vraiment dû personnaliser, ce sont les définitions de compilation si nécessaire (dans ce cas précis, j’ai désactivé les setters et les constructeurs pour m’appuyer à la place sur les initialiseurs désignés de C++ 20).

Et ça a fonctionné : il m’a suffi d’écrire import vulkan_hpp dans ma bibliothèque de rendu pour utiliser les liaisons C++ de Vulkan. Si je n’avais pas réussi à le faire fonctionner, je serais probablement revenu à l’API C de Vulkan avec mes propres wrappers RAII personnalisés, car les temps de compilation avec les #include standard étaient exécrables. Cela fonctionnait également de manière récursive (là encore, avec des limitations que j’expliquerai plus tard), ce qui signifie que ma bibliothèque de rendu pouvait inclure l’importation de VulkanHpp dans ses en-têtes publics et que cela se transmettait sans problème lorsqu’elle était intégrée à mes projets utilisant #include <renderer/renderer.h>.

Vous avez peut-être lu qu’il fallait un peu bricoler CMake pour faire fonctionner les modules, qu’il fallait utiliser des indicateurs ésotériques tels que CMAKE_CXX_SCAN_FOR_MODULES, CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP ou CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API, mais aucun d’entre eux n’est nécessaire pour le moment, à condition d’utiliser une version récente de CMake (idéalement la 4.x, mais les paramètres par défaut devraient fonctionner à partir de la version 3.28).

Et voilà : en peu de temps, j’avais remplacé les 9 secondes interminables qu’il fallait pour inclure VulkanHpp par un temps négligeable de quelques millisecondes. Je considère cela comme une belle victoire. Mais c’est là que les ennuis commencent…

IntelliNonSense

Voici une anecdote amusante : vous pouvez trouver des comptes-rendus de réunions du SG15 datant de 2019 dans lesquels Microsoft affirme que les modules fonctionnent parfaitement en interne pour l’équipe Edge. Et pourtant, si vous ouvrez un projet utilisant des modules avec Visual Studio 2026, vous êtes accueilli par ce message incroyable :

Code:
C++ IntelliSense support for C++20 Modules is currently experimental.


Eh oui. Ça fait 7 ans, et ils n’arrivent toujours pas à faire en sorte qu’IntelliSense analyse correctement les directives d’importation. Je sais que le serveur de langage est basé sur EDG et non sur VC++, mais franchement, je m’en fiche. C’est une entreprise valant près de 3 000 milliards de dollars au moment où j’écris ces lignes qui nous dit qu’elle n’arrive pas à faire fonctionner une fonctionnalité une décennie après avoir milité pour la normalisation des modules en s’appuyant sur sa propre réussite interne. Je ne sais pas s’ils ont exagéré leurs affirmations à l’époque, s’ils n’ont pas suffisamment financé l’équipe Visual Studio depuis, ou quoi d’autre, mais on ne peut pas me dire que huit ans n’ont pas suffi pour faire fonctionner la coloration syntaxique avec les modules. Et si c’est le cas, alors peut-être y avait-il quelque chose de profondément erroné dans leur proposition et le comité aurait dû demander à voir les justificatifs avant de voter pour.

Quoi qu’il en soit, voici comment résoudre le problème :

Code:
1
2
3
4
5
6
#if defined( __INTELLISENSE__ )
#include <vulkan/vulkan.hpp>
#include <vulkan/vulkan_raii.hpp>
#else
import vulkan_hpp;
#endif


Cela permet à votre compilateur (et au temps d’itération) de rester sur la voie rapide du module, et IntelliSense peut alors continuer à analyser les fichiers d’en-tête en arrière-plan, ce qui vous offre la mise en évidence et l’autocomplétion. Est-ce une astuce ? Absolument. Mais c’est une astuce que j’utilise depuis 6 mois et qui me permet de me concentrer sur autre chose.

Maintenant que cela est dit, nous pouvons aborder le véritable problème.

Les modules sont un système « tout ou rien »

J’ai laissé entendre dans les sections précédentes que les modules fonctionnent si l’on s’en tient à certaines contraintes strictes. Le problème, c’est que ces contraintes ne sont pas négligeables. En gros, les modules fonctionnent selon un principe « tout ou rien ». Si vous commencez à utiliser des bibliothèques via des directives d’importation, vous ne pouvez pas faire en sorte que la même unité de traduction les intègre via des #include. Et cela devient rapidement un problème.

Voici l’exemple le plus simple pour l’illustrer :

Code:
1
2
3
4
5
6
7
8
// Works, obviously
#include <array>
 
// Works even if <array> is included before and part of the std module
import std;
 
// Error, will yield a million "xxx already declared" failures
#include <utility>


En termes simples, une bibliothèque peut à la fois être importée et incluse, à condition que la directive #include apparaisse en premier et l’import en second. Je ne sais toujours pas si cela est imposé par la norme ou s’il s’agit d’une limitation d’implémentation, mais c’est quelque chose que j’ai observé directement sur MSVC et dont d’autres ont également fait mention.

Dans mon cas d’utilisation précédent, cela ne posait pas de problème, car VulkanHpp n’est importé que par ma bibliothèque de rendu, n’importe rien lui-même et n’est utilisé nulle part ailleurs dans mon arborescence de compilation. Malheureusement, les choses ont pris une mauvaise tournure lorsque la version récente a commencé à intégrer la bibliothèque standard via import std. Du coup, il y a soudainement une dépendance transitive qui importe une bibliothèque très courante ; je dois donc désormais m’assurer que ma directive import vulkan_hpp vient après tout autre #include de la bibliothèque standard. Et comme vulkan_hpp est utilisé publiquement dans ma bibliothèque de rendu, celle-ci doit désormais toujours être importée en dernier dans chaque unité de traduction. Sinon, j’obtiens un milliard d’erreurs de compilation liées à des redéclarations ou redéfinitions.

« Il suffit de passer aux modules »

La solution recommandée, m’a-t-on dit, consiste à tout transférer dans des modules. Ou du moins, si une bibliothèque commence à utiliser import std, à modifier toutes les autres bibliothèques que j’utilise pour qu’elles n’utilisent également que import std. Dans le cas de mon projet jouet, cela concernerait au moins TBB et fastgltf. Ironiquement, cela ne semble pas avoir d’impact sur les bibliothèques C++ qui s’appuient uniquement sur la bibliothèque standard C (je pense que ce serait le cas si j’utilisais import std.compat ?). C’est regrettable que cela donne raison aux auteurs de bibliothèques qui refusent d’utiliser la STL.

Notez que j’ai parlé de « modifier », et non pas simplement d’« activer un bouton ». Car bien que C++20 ait six ans, pratiquement aucune bibliothèque C++ ne propose de définition de module. Boost ne propose des modules que pour quelques bibliothèques triées sur le volet. Les affirmations que j’ai lues selon lesquelles Catch2 fournirait un module semblent n’avoir été qu’une hallucination de l’IA. La seule grande bibliothèque que j’ai pu trouver est fmt, qui est une bonne bibliothèque, mais honnêtement, si vous disposez de la prise en charge de C++20, vous avez de toute façon déjà <format> à votre disposition.

Et bien sûr, chaque bibliothèque qui décide de prendre en charge les modules doit proposer une forme de compilation double, car tous ses clients n’utilisent pas encore les modules. Et pour chacune de ses propres dépendances, elle doit décider si elle les intègre via #include, via import ou si elle laisse l’utilisateur les configurer (mon opinion actuelle est que la version module devrait toujours utiliser import et ne pas proposer d’option, afin d’éviter l’enfer combinatoire).

Prise en charge de la compilation double

J’ai ensuite essayé de prendre en charge la compilation double pour ma bibliothèque de rendu, et ce n’est pas tout à fait une mince affaire.

Tout d’abord, comme suggéré précédemment, il faut basculer des #include vers des import lors de la compilation/l’analyse en mode module. Cela implique généralement d’ajouter une définition et de faire quelques manipulations autour de chaque directive #include :

Code:
1
2
3
4
5
6
7
#ifndef RENDERER_MODULE
#include <array>
#include <utility>
#include <vector>
#else
import std;
#endif


Pour les bibliothèques qui ne comportent qu’un seul fichier d’en-tête, ce n’est pas si grave, mais pour les bibliothèques plus complexes composées de plusieurs fichiers .cpp et .h, cela s’apparente un peu plus à une chasse aux œufs de Pâques. Dans ma branche POC actuelle, j’ai fini par supprimer toutes les directives #include et les regrouper dans un seul fichier que je peux activer ou désactiver selon que l’on utilise ou non les modules. Cela ralentit la compilation sans modules, car désormais toutes mes unités de traduction chargent une multitude d’en-têtes dont elles n’ont pas personnellement besoin (je te regarde, <filesystem> 😠).

Ensuite, il faut composer avec le fait que les directives de module ne peuvent pas être exclues via #ifdef. C’est une contrainte de conception. Je ne sais pas exactement pourquoi, mais cela constitue une erreur grave selon la norme. Ce qui signifie que si vous avez un fichier d’implémentation .cpp, vous ne pouvez pas utiliser #ifdef et ses dérivés pour le déclarer de manière conditionnelle comme faisant partie d’un module. Il reste donc trois options : un hack, un autre hack ou toujours compiler votre bibliothèque en tant que module.

Commençons par la première astuce. Je ne l’apprécie pas, mais elle montre en quelque sorte la futilité d’essayer de restreindre l’utilisation de #ifdef dans la spécification. En effet, cette restriction ne s’applique pas à #include. Nous pouvons donc simplement la contourner en dupliquant chaque fichier d’implémentation :

Code:
1
2
3
4
// device_module.cpp
module renderer;
#define RENDERER_MODULE
#include <device.cpp>


Cela implique d’utiliser un ensemble différent de fichiers .cpp, que vous compiliez ou non en tant que module, et d’avoir un fichier de liaison supplémentaire pour chaque fichier d’implémentation, mais cela fonctionne. Une autre suggestion, proposée par Daniela Engert, consistait à abandonner complètement la compilation séparée de tous les fichiers .cpp et, à la place, à les intégrer tous dans la section module :private; de la définition du module à l’aide de directives #include :

Code:
1
2
3
4
5
6
7
8
9
10
export module renderer;
export {
    #include <renderer/renderer.h>
}
module :private;
#include <renderer/bindless.cpp>
#include <renderer/buffer.cpp>
#include <renderer/command_buffer.cpp>
#include <renderer/device.cpp>
// ...


Certains de mes lecteurs pourraient objecter : « mais cela placerait toute l’implémentation dans la même unité de traduction, comme dans les compilations Unity ». Ce serait exact. C’est pourquoi je préfère ne pas utiliser cette solution non plus. J’ai déjà eu affaire à des compilations Unity par le passé et je les considère toujours comme un « hack » qui va à l’encontre des attentes traditionnelles concernant les déclarations static et les espaces de namespace {}.

Des modules presque toujours ?

J’ai donc choisi de toujours compiler ma bibliothèque sous forme de module. De cette manière, je peux placer des déclarations de module dans mes fichiers .cpp sans problème. L’astuce consiste à utiliser extern "C++" de C++20. De la même manière que les noms déclarés avec extern "C" utilisent une liaison C rétrocompatible et un mangling de noms, le fait d’encadrer les déclarations export {} avec extern "C++" génère des symboles utilisant une ABI compatible avec les déclarations #include (par défaut, avec les modules, chaque symbole est préfixé par le nom de son module, ce qui rend impossible sa détection par l’éditeur de liens dans des contextes non modulaires).

Code:
1
2
3
4
5
6
7
8
export module renderer;
// Don't mangle as a module for backward compatibility with non modules includes
extern "C++"
{
	export {
        #include "renderer/renderer.h"
    }
}


De cette manière, la bibliothèque n’a pas besoin d’être compilée différemment selon que les utilisateurs recourent à import ou à #include. Cela ne pose évidemment problème que pour les bibliothèques qui produisent des symboles exportés. Les bibliothèques composées uniquement d’en-têtes n’ont pas à s’en soucier.

Le fait de n’avoir qu’une seule version de compilation signifie que la bibliothèque n’utilise plus sa propre variante #include. Il est conseillé de conserver quelques tests utilisant la bibliothèque à la fois via le chemin import et via le chemin #include tant que vous prenez en charge les deux (ce qui, je suppose, prendra un certain temps compte tenu du rythme d’adoption des modules).

Alors, dois-je utiliser les modules ?

Le passage aux modules implique un coût initial important. Devoir faire passer toutes vos dépendances aux modules représente une charge de travail non négligeable et, malheureusement, le soutien des responsables de bibliothèques est pour l’instant limité. Même ceux qui déclarent utiliser les modules semblent, pour l’instant, recourir à des fourches de leurs bibliothèques tierces. Je ne sais pas s’ils n’ont pas eu envie de contribuer ou de maintenir des correctifs, ou s’ils ont soumis des correctifs qui ont été rejetés, mais cela n’est pas très encourageant. Les sondages de Meeting C++ ne montrent pas un taux d’adoption élevé pour une fonctionnalité vieille de six ans. Il s’agit peut-être d’un problème de l’œuf et de la poule (personne ne passe aux modules en raison du manque de prise en charge des bibliothèques, et les responsables de bibliothèques ne s’en préoccupent pas en raison du manque d’utilisateurs des modules).

J’envisage de proposer des correctifs pour les bibliothèques que j’utilise, mais j’avoue que même après avoir écrit cet article, je ressens encore un peu le syndrome de l’imposteur et je me demande si ma contribution serait utile. Il y a si peu d’expertise, d’expérience et de documentation sur les modules qu’il n’est pas évident de savoir ce qui constitue ou non une bonne pratique. J’ai compris le fonctionnement des nouveaux mots-clés principalement par essais et erreurs, ce qui me fait penser que la plupart des projets ne disposeront pas d’un relecteur qualifié pour évaluer la qualité d’un correctif proposé.

En attendant, la solution de facilité consiste à faire comme je l’ai fait au départ avec VulkanHpp et à limiter l’utilisation des modules aux bibliothèques qui sont lourdes à analyser mais faciles à placer en fin de chemin #include/import pour un gain rapide ; malheureusement, cela s’effondre rapidement à grande échelle en raison du facteur viral.

Addendum : Jens Weller m’a signalé l’existence de « Are We Modules Yet ? », un site web qui répertorie les projets proposant des modules. Curieusement, fastgltf fournit bien un module, mais celui-ci n’est ni compilé ni installé par vckpg, ce qui explique que je ne l’aie pas vu. Je pense que les bibliothèques devraient toujours ajouter les définitions de modules à leur liste d’installation plutôt que de les dissimuler derrière un paramètre de compilation, afin que cela ne devienne pas un problème pour le gestionnaire de paquets.

Licensed under CC BY-NC-SA 4.0

Source : Can we finally use C++ Modules in 2026?

Et vous ?

:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: C++26 : Concept et templates variables comme paramètre template, par Sandor Dargo

:fleche: Le C++ doit être du C++ : Une opinion qui est le fruit de 23 années d'expérience en C++, par David Sankel

:fleche: C++26 est prêt : la nouvelle norme apporte des améliorations en matière de sécurité mémoire et serait la version « la plus aboutie » depuis C++11. Elle introduit les contrats et la bibliothèque std::execution ]]> C++ Mathieu Ropert https://www.developpez.net/forums/d2186190/c-cpp/cpp/pourrons-enfin-utiliser-modules-cpp-2026-a/ Compteur compile time qui ne fonctionne plus. (gcc à changé ses règles ?) https://www.developpez.net/forums/showthread.php?t=2186125&goto=newpost Tue, 13 Oct 2026 08:36:18 GMT Salut un membre m'avait codé un compteur compile time mais ici il ne fonctionne plus il reste toujours à 0 :

Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
#ifndef ODFAEG_COMPILETIME_COUNTER
#define ODFAEG_COMPILETIME_COUNTER
namespace odfaeg {
    namespace core {
        template <auto, auto>
        struct ADLType {
            friend consteval auto ADLFunc(ADLType, auto...);
        };
 
        template <auto InstanceIdentifier, auto x>
        struct InjectDefinitionForADLFunc {
            friend consteval auto ADLFunc(ADLType<InstanceIdentifier, x>, auto...) {}
        };
 
        template<auto InstanceIdentifier, auto x = 0, auto = []{}>
        constexpr auto ExtractThenUpdateCurrentState()->decltype(x) {
            if constexpr (requires { ADLFunc(ADLType<InstanceIdentifier, x>{}); })
                return ExtractThenUpdateCurrentState<InstanceIdentifier, x + 1>();
            else 
                InjectDefinitionForADLFunc<InstanceIdentifier, x>{};
            return x;
        }        
        template<auto InstanceIdentifier, auto x = 0, auto = []{}>
        constexpr auto ExtractCurrentState()->decltype(x) {
            return x;
        }
        template<auto InstanceIdentifier, auto x = 0, auto = []{}>
        constexpr auto ResetCurrentState()->decltype(x) {
            return 0;
        }
 
        template <auto InstanceIdentifier = []{}>
        struct Compteur {
            template <auto x = ExtractThenUpdateCurrentState<InstanceIdentifier>()>
            consteval auto next() const { return x; } 
            template <auto x = ExtractCurrentState<InstanceIdentifier>()>
            consteval auto value() const { return x; }  
            template <auto x = ResetCurrentState<InstanceIdentifier>()>
            void reset() const {
 
            }
        };
    }
}
#endif
le requires on dirait me revoie toujours false pour l'ADL fonction. ]]> C++ Laurent7601 https://www.developpez.net/forums/d2186125/c-cpp/cpp/compteur-compile-time-ne-fonctionne-plus-gcc-change-regles/ <![CDATA[Différence à l'usage entre une bibliothèque dynamique et une bibliothèque d'importation !]]> https://www.developpez.net/forums/showthread.php?t=2185431&goto=newpost Wed, 02 Sep 2026 13:18:02 GMT Salut à tous. Quel est la... Salut à tous.

Quel est la différence à l'usage entre une bibliothèque dynamique et une bibliothèque d'importation !
Je parle aussi bien du 'C' que du 'C++'.
Je trouve que l'usage de la bibliothèque d'importation est très proche de celle de la bibliothèque statique.
Quand à la bibliothèque dynamique, je trouve cela plutôt lourd pour un usage non pertinent.

Peut on me donner un exemple d'usage où la bibliothèque dynamique serait mieux que la bibliothèque d'importation ? ]]> C++ Artemus24 https://www.developpez.net/forums/d2185431/c-cpp/cpp/difference-l-usage-entre-bibliotheque-dynamique-bibliotheque-d-importation/ <![CDATA[L'IA va t elle remplacer le développement en C++?]]> https://www.developpez.net/forums/showthread.php?t=2185139&goto=newpost Thu, 13 Aug 2026 18:57:55 GMT Bonjour Je poste ici car... Bonjour
Je poste ici car l'impact de l'IA varie en fonction du langage, et j'aurai aimé connaitre l'impact sur la communauté C en particulier.
Sur des forums généralistes, je lis souvent que les devs n'ont aujourd'hui plus besoin de programmer.
Quand j'ai demandé "L'IA va-t-elle remplacer les devs" on m'a répondu: "ta question a 3 ans de retard hein, elle a déjà remplacé 90% des devs. Perso ça fait 6 mois que je ne code plus".

Qu'en est il réellement? Avez vous senti un changement notable? Le métier de développeur C est il mort?
J'ai une formation en développement et j'ai toujours rêvé de faire du C, mais voir ce qui se trame me rend perplexe sur mon futur métier...

Merci de votre attention ]]> C++ Maubius https://www.developpez.net/forums/d2185139/c-cpp/cpp/l-ia-va-t-remplacer-developpement-cpp/ Mod pour MAME https://www.developpez.net/forums/showthread.php?t=2183198&goto=newpost Tue, 14 Apr 2026 08:02:00 GMT Bonjour, Je souhaite... Bonjour,

Je souhaite ajouter une fonctionnalité à MAME:
Lorsque un jeux de tuiles est affiché (touche F4), ajouter la possibilité de le sauvegarder dans un fichier PNG via la touche F12) tout en gardant les informations de transparence.

J'ai repris le code source de Steve Moody (https://eab.abime.net/showthread.php?t=41610&page=3) pour l'intégrer au code source,
voir la classe gfx_writer sur mon github (https://github.com/Deedolith/mame-gf...ontend/mame/ui).

Cela fonctionne bien, par contre je n'ai pas compris comment détecter les pixels transparents.
La documentation de MAME indique comment gérer la transparence, mais d'après ce que j'ai compris, cela concerne l'affichage sur un écran, aucune idée si cela peut être adapté pour un bitmap:
https://wiki.mamedev.org/index.php?t...tilemap_system ]]> C++ deedolith https://www.developpez.net/forums/d2183198/c-cpp/cpp/mod-mame/ Avis sur vieux livres C++ offerts https://www.developpez.net/forums/showthread.php?t=2182653&goto=newpost Sun, 15 Mar 2026 14:34:00 GMT Bonjour à tous, Un voisin... Bonjour à tous,
Un voisin qui déménage m'a offert sa collection de livres d'informatiques. Comme j'ai un projet personnel en C++ cette année, je souhaite votre avis sur la pertinence des ces ouvrages pas particulièrement récents :

  • C++ en action de D. Ryan Stephens (2006)
  • Professional Multicore Programming: Design and Implementation for C++ Developers (2008)
  • C++ Template Metaprogramming de David Abrahams (2004)
  • Beyond the C++ Standard Library: An Introduction to Boost (2005)
  • undle of Algorithms in C++, Parts 1-5: Fundamentals, Data Structures, Sorting, Searching, and Graph Algorithms (2002)
  • Modern C++ Design: Generic Programming and Design Patterns Applied (2001)
  • Secure Programming Cookbook for C and C++ (2003)
  • The Boost Graph Library: User Guide and Reference Manual (2002)
  • La programmation orientée de Hugues Bersini (2008)
  • Standards de programmation en C++ de Herb SUTTER et Andrei ALEXANDRESCU

J'ai un peu étudié le C++ il y a longtemps, je ne sais pas si les librairies, et la pratique du C++ ont tellement évoluées que ces livres sont périmés ou à éviter. Par contre pour mon projet j'aurai à travailler sur des graphes.
Votre avis ? ]]> C++ Quami https://www.developpez.net/forums/d2182653/c-cpp/cpp/avis-vieux-livres-cpp-offerts/ <![CDATA[Incompréhension erreur "invalid conversion from 'DWORD' {aka 'long unsigned int'} to 'DWORD* (*)()"]]> https://www.developpez.net/forums/showthread.php?t=2181073&goto=newpost Sat, 20 Dec 2025 15:35:37 GMT Bonjour j'ai un problème de compilation.

J'ai isolé mon problème avec le petit source suivant :

Code:
1
2
3
4
5
6
7
8
9
10
#include <windows.h>
 
void ToCallVoid(DWORD errno) { }
 
int Caller(DWORD errno) {
	ToCallVoid(errno);
	return 0;
}
 
int wmain (int argc, wchar_t **argv, wchar_t **envp) { return 0; }


J'ai l'erreur suivante :

.\src\testp.cpp:6:20: error: invalid conversion from 'DWORD' {aka 'long unsigned int'} to 'DWORD* (*)()' {aka 'long unsigned int* (*)()'} [-fpermissive]
    6 |         ToCallVoid(errno);
      |                    ^~~~~
      |                    |
      |                    DWORD {aka long unsigned int}
.\src\testp.cpp:3:23: note: initializing argument 1 of 'void ToCallVoid(DWORD* (*)())'
    3 | void ToCallVoid(DWORD errno) { }
      |                       ^
J'utilise : c++.exe (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r3) 15.2.0

J'ai essayé différentes options de compilation mais toujours le même résultat.
Le plus simple : c++.exe -o .\src\testp.cpp.obj -c .\src\testp.cpp
donne bien la même erreur.

Quelqu'un a-t-il une explication ? ]]> C++ jmblib https://www.developpez.net/forums/d2181073/c-cpp/cpp/incomprehension-erreur-invalid-conversion-from-dword-aka-long-unsigned-int-to-dword/ Problème SDL_ttf et Code Blocks https://www.developpez.net/forums/showthread.php?t=2180754&goto=newpost Wed, 03 Dec 2025 10:08:11 GMT Bonjour,
J'utilise Code Blocks 20.03 (compilateur GNU GCC compiler) avec la librairie graphique SDL2 (SDL-devel-2.0.3-mingw). Je veux faire de l'affichage de texte et utilise SDL2_ttf-devel-2.0.18-mingw.
Mes 3 premières lignes sont #include <SDL2/SDL.h> #include <SDL2/SDL_ttf.h> ou #include <SDL_ttf.h> et #include <stdio.h>.
Quand je click sur Build pour vérifier mon programme j'ai "fatal erreur: SDL.h : No such file or directory" que cela soit dans la prog main.cpp ou SDL_ttf.h alors que ce dernier fichier est dans : Project - Build options - Projet Texte -linker settings (dans plusieurs endroits) comme le montre le fichier Projet Texte linker settings.jpg.
J'ai aussi mes 3 fichiers comme le montre Projet Texte Search dir.jpg que cela sur linker avec lib ou compiler avec include et mon fichier SDL2.dll est mis dans le répertoire de mon projet.
Est-ce que je pourrais avoir une solution pour résoudre ce problème?
Merci.
Images attachées
  
]]> C++ slmh1 https://www.developpez.net/forums/d2180754/c-cpp/cpp/probleme-sdl_ttf-code-blocks/ sstream et saisie cin https://www.developpez.net/forums/showthread.php?t=2180677&goto=newpost Fri, 28 Nov 2025 00:26:33 GMT Bonjour, pourquoi b est... Bonjour,

pourquoi b est toujours à 0 ?

une idée ?

Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <iostream>
#include <string>
#include <sstream>
 
int main(){
  std::cout<<"a= ";
  int a;
  std::string saisie;
  std::stringstream geek;
  std::cin>>saisie;
  geek<<saisie;
  geek>>a;
  geek.flush();
  std::cout<<"b= ";
  int b;
  std::cin>>saisie;
  geek<<saisie;
  geek>>b;
  std::cout<<a<<' '<<b<<std::endl;
}
Code:
1
2
3
4
$ ./a.out 
a= 56
b= 12
56 0
]]> C++ emmesse https://www.developpez.net/forums/d2180677/c-cpp/cpp/sstream-saisie-cin/