Elle doit déjà exister sous le nom PATH, ou Path.... vérifie dans un terminal en ligne de commande avec la commande
echo %PATH%

Si y a rien qui vient à part %PATH% c'est qu'elle existe pas, crée là

"Je pense que ça dépends de quel genre d'optimisations on parle, des optimisations au niveau algorithmique sont à considérer dès le départ, personne n'a jamais dit le contraire, en revanche des optimisation bas-niveau avec des petits trucs de hacker sont plutôt à considérer seulement après avoir fait du profiling."

Non plus. Par ce que c'est optimization de bas niveau sont tout aussi importante. Elle peuvent te donner un facteur 10 ou 100 de performances. Mais elles demandent de changer le layout des donnees en memoire. Et si ton code est objectifie avec de l'allocation dynamique de partout (ce qui est le schema standard) alors tu te retrouve a avoir un layout qui est impose par l'architecture globale de ton application.

Par exemple, si tu decide d'envoyer une partie des calcul sur ton GPU programmable, il faut que les donnees soit contigue en memoire pour avoir le maximum de bande passante entre la memoire et le GPU.

Ou encore, les histoire de "structure of array Vs array of structure" fait la difference entre une execution scalaire qui trashe le cache et un code super scalaire qui tient dans le cache.

Oui mais comment on crée la variable ? :O

https://www.google.be/search?q=cr%C3%A9er+variable+path+windows+7&oq=cr%C3%A9er+variable+path+windows+7&aqs=chrome..69i57j0l2.3651j0j7&sourceid=chrome&espv=210&es_sm=122&ie=UTF-8

Voici une vidéo vraiment pas mal pour ceux qui ont vécu des réunions horribles ^^ https://www.youtube.com/watch?v=BKorP55Aqvg

Salut ! J'aimerais tester un peu autre chose que du graphique avec SDL, du coup je pensais à GTK+

Qu'est-ce que vous pensez de cette bibliothèque (qui m'a l'air assez importante) ?

Je précise que je code toujours en C.

Que cherches-tu à faire déjà outre le fait de seulement tester ?

En fait j'ai dans l'idée de faire un petit éditeur d'image, avec palette limitée. Rien de prétencieux, c'est pour moi éditer des sprites. Je sais que c'est même possible avec SDL mais je trouvais plus pratique d'avoir des menus classiques.

Mmm, finalement mon choix se porte sur la bibliothèque QT. Du coup j'ai entamé l'apprentissage de C++ (ça me changera du C après ces années )

J'ai une petite question, au niveau des références. Je ne peux pas m'empêcher de remarquer leurs similitudes avec les pointeurs, et du coup j'ai un peu de mal à y voir une utilité... Si j'ai bien compris, c'est à peut près pareil sauf qu'on ne peut pas toucher aux adresses avec les références ?

VampireGirl -> En simplifiant un peu, il n'y a rien que tu puisses faire en C++ que tu ne pourrais pas très bien faire en C avec d'autres mécanismes moins restrictifs. L'intérêt de ces restrictions est sémantique, sécuritaire (niveau code correct) et permet d'utiliser certains autres mécanismes.

De façon générale, je te décourage à penser "je n'en vois pas l'utilité". En programmant en C++ tu devrais penser l'inverse: Toujours utiliser des références (plus restrictif) et n'utiliser le pointeur que si tu y es absolument obligée.

En poussant à l'extrême, je dirais même qu'en C++11 tu ne devrais jamais:
- Utiliser de pointeur style C (-> soit référence, soit shared_ptr ou unique_ptr).
- Utiliser new (-> conteneur standard, make_shared ou make_unique).
- Utiliser des arrays style C (-> au moins std::vector ou std::array).
- Utiliser de cast syle C (-> static_cast dans la plupart des cast)

J'exagère un peu, mais c'est un set de règles que j'enfreins rarement sur une application de bureau. Ça doit au moins tirer au alarme quand c'est le cas.

Oh, et vis-à-vis du deuxième point, si new est en général à éviter, malloc() est totalement à proscrire (encore une fois, sauf exception hein, en C++ plus qu'ailleurs y a rien d'absolu .

Merci de tes conseils Mjonir Oui j'ai été un peu vite en disant que ça n'avait aucune utilité, ça permet clairement de ne pas chipoter aux adresses, et le code est plus clair à lire je trouve.

Pour malloc j'imagine, je viens de voir ce que sont les "vector" et c'est vrai que ça a l'air super pratique ces bêtes là !

"make_unique" n'est pas disponible en C++11 de ce que je sache, mais le sera avec C++14, donc le "new" est toujours utile, mais delete de sert plus à rien.

Ah yep, c'est vrai, j'oubliais. C'est apparemment un oublié du comité, je l'ai bien vite rajouté à mon header d'utilitaires :P

Trop bizarre par contre, les fichiers sont fermés à la fin des blocs Moi qui suis habituée à fclose...

Est-ce une bonne pratique si une fois que je n'en ai plus besoin je demande explicitement de les fermer ?

J'ai jamais fait autrement qu'en fermant explicitement perso.

Fais ce qu'il y a de plus clair. 3 cas de figure (avis personnel ici uniquement):

1) Si quand t'en as fini avec le fichier tu es à la fin du bloc => ce serait une ligne pour rien.
2) Tu utilises juste le fichier localement pour faire une opération et tu peux faire un scope local, fais le. Ex:

int x;

// Loading x
{
std::ifstream file("my_x")
file >> x
}

3) Si par contre ton fichier est utilisé au milieu du bordel, que tu as besoin de variables qui viennent avant et que certaines doit partir après, et que tu serais donc forcée de faire des déclarations hors du bloc, autant fermer explicitement. Personnellement je n'ai jamais rencontré ce cas de figure en pratique, y a toujours moyen de découper proprement.

Le C++ c'est strict, mais en échange les destructeurs c'est magique

Salut

Mon dieu...

C'est l'avenir de l'enseignement.