ben la réponse est dans la question, tu viens de le dire toi meme, structure de données :/ . ..

maintenant si tu sais pas ce qu´est une une SD, c´est juste la façon d´organiser tes données : les piles, les files, les vecteurs, les classes, etc. tout ça c´est des façon de stocker et organiser des infos. Certaines sont tres connues et ont des utilisations bien spécifiques ( les conteneurs, les arbres de toute sortes, . ..). Si ton bouquin est orienté jeux, il y aura certainement un substitut allegé à la STL ( avec tous les conteneurs qui vont bien), des choses sur les quad/octree, les BSP, les automates, les graphes, bla bla, plein d ´autres.

DarkGift: ca dépend de tes intérêts. explique . ..

ben je voudrais essayé de faire un jeu mais je n´arrive même pas à affiché une image à cause des fatal error !

DarkGift: quel api?, detail.....

. .. tu as commencé la pratique du langage depuis combien de temps ?

avec moins de qq mois, tu peux envisager des " jeux" en ligne de commande, style " trouve le nombre", les allumettes ( à prendre par 2 ou 3 et pas la derniere), etc. Des trucs bateau pour se familiariser un peu. Tu parlais déjà de triangle et autres, donc j´imagine mode graphique & cie... Mon point de vue, oublie pour qq temps.

Le minimum pour se lancer un projet moyen terme, c´est bien maitriser les bases, savoir construire un projet qui compile proprement, qq notions d´algorithmiques, et la connaissance minimale d´api diverses pour s´aider. Et tout ça, meme ça reste niveau débutant, ça prend du temps... Donc sois patient

ok jvé essayé d´attendre est faire des truc basik mais ça veut dire koi ça :

Les objets cin, cout, cerr et clog sont donc des instances des classes istream et ostream, qui sont associées aux flux d´entrée / sortie standards du programme. En fait, la bibliothèque standard définit également des versions capables de manipuler des flux basés sur le type wchar_t pour les programmes qui désirent travailler avec des caractères larges. Ces objets sont respectivement wcin ( instance de wistream), wcout, wcerr et wclog ( instances de wostream). Tous ces objets sont initialisés par la bibliothèque standard automatiquement lorsqu´ils sont utilisés pour la première fois, et sont donc toujours utilisables.

mais dans le cadre de l´exemple de JYY, s´il n´y avait aps d´objet de proté globale, mais juste celui déclaré dans le premier if est-ce qu´il serait visible à l´extérieur de ce if ? ( bon, je vais tester) . ..

je viens de vérifier et c´est impossible, dans ce cadre là, je en comprend pas la question de JYY, parce que lorsque l´on arrive au deuxième if et donc au quatrième a, on peut acceder au 2 et au 4ième a ( et peut-être même au premier en enchainant les :: ? ) mais le 3ième n´existe tout simplement plus ( enfin c´est comme ça que je comprend la porté de ces variables) donc je ne vois pas comment on pourrait y acceder.

sinon je repose la question que j´ai posé sur l´autre topic : comment cin et cout sont-il déclaré de manière à être eccessible dans tout les fichier qui inclue iostream sans problème au linkage.

par ce que la solution de LGV d´utiliser le mots clef extern n´est pas la solution mise en oeuvre par le C++ puice qu´il n´est pas nécessaire de déclarer une instance réelle de ces objets où que ce soit.

alors peut-être que c´est le trus du singleton, mais comme je n´ai pas la moindre idée de quoi il s´agit, je ne dirait pas non pour une petite explication ( qui me semble rentrée dans le cadre de ce topic).

merci.

" peut-être même au premier en enchainant les :: ? "

non, l´opérateur de résolution de portée ne marche pas " par niveau", il n´y a aucune idée de la portée " précédente", ou des limites des portées locales ; ça marche disons par " domaine". Les namespaces definissent des domaines ( namespace::data), les classes aussi ( class::staticData), etc. Il existe un domaine particulier qui est la portée globale obtenu sans spécifier de nom ( ::data) tout court

" utiliser le mots clef extern n´est pas la solution mise en oeuvre par le C++ puice qu´il n´est pas nécessaire de déclarer une instance réelle de ces objets où que ce soit."

ils sont définis dans les libs ( donc dans le code des libs), que tu linkes avec ton projet. De cette manière, l´objet existe DEJA dans le code que tu linkes, c´est pourquoi tu n´as pas à la créer toi meme. Par contre si tu faire ce mécanisme pour une donnée à toi, tu DOIS la déclarer qqpart ; et le extern ne sert qu´à renseigné les autres bouts de code que cette donnée existe, qqpart ( et le linker se debrouille pour savoir où).

" alors peut-être que c´est le trus du singleton, mais comme je n´ai pas la moindre idée de quoi il s´agit"

c´est un design pattern classique qui répond au probleme d´avoir une seule instance d´une classe donnée qui existe au sein du programme. Les objets qui s´y pretent bien sont en général des " managers" ; un truc qui manage tes textures par exemple, doit etre unique dans ton programme ( pour l´exemple..). Mais comme tu définis une classe, un programmeur pourrait tres bien créer 25 objets de ce type.. C´est pas ce que tu veux : le singleton permet de forcer cette contrainte d´unicité ( en gros pour une version simple : un pointeur membre static sur l´unique instance, un getter static pour l´unique instance, la forme canonique en privée à l´exception du destructeur ; la première fois que le getter est appelée, il crée l´instance unique -vu que LUI a acces au constructeur- et garde un pointeur dessus pour les fois suivante). Bon, ça sort du cadre de ta question de cin/cout mais c´est pour le principe. ( tu peux aussi facilement faire un template de singleton qu´il suffit d´hériter pour que n´importe quelle classe en devienne un...)

merci, pour le singleton j´ai compris.

pour le extern je sais à peu près comment ça marche, mais ça marche pas !

en gros j´ai une lib avec son en tête qui définit une classe advio.

dans l´en tête je définit une variable :
extern advio console;
et dans l´un des fichier . cpp de la lib ( c´est une lib statique) je crée advio console;

mais dans un programme qui utilise la lib, il n´arrive pas à trouver l´instance de l´objet et il me mets unresolved external symbol advio consol ( à quelques petit truc pret).

j´ai regardé dans iostream et lui il déclare effectivement les cin comme extern ( j´était passé à coté) avec le mot clef __declspec(dllimport) j´ai essayé, mais ça ne change rien ( idem si je déclare en plus la véritable instance de la classe comme dllexport).

si tu fais une lib statique ( .lib) et non dynamique ( .dll) tu n´as pas besoin de la décoration de nom type __declspec.

Va voir du coté de tes options de linkage si tu n´aurais pas oublié qqch, mais tu dois etre proche d´un truc qui marche ; la forward declaration extern dans les headers et la " vraie" declaration dans une lib statique, c´est tout ce qu´il faut pour ça marche