Discussion :

[ceugniet]

Bonjour � tous,

J'ai post� le message suivant dans le mauvais forum, de plus dans un sujet dit "r�solu". Je pense qu'il a de ce fait peu de chance d'�tre lu par quelqu'un.
Je le poste donc � nouveau, j'esp�re au bon endroit.

Ce qui suit concerne des programmes "console".

Depuis quelque temps (� vrai dire je ne sais pas bien depuis quand, car j'ai parfois de longues p�riodes sans rien coder), donc peut-�tre quelques semaines ou deux ou trois mois, j'ai des probl�mes avec mes #include lorsque les fichiers en question ne sont pas dans le m�me dossier que mon fichier .cpp. Le syst�me me r�pond syst�matiquement que le fichier en question n'existe pas.

M�me probl�me avec les library.

M�me probl�me avec les fichiers qui doivent �tre ouverts � l'ex�cution (avec fopen_s) qui ne sont pas dans le m�me dossier que celui qui contient le .exe.

Je pr�cise que ces nombreux programmes qui ne marchent plus, ont march� de nombreuses ann�es : subitement un programme qui marchait correctement, ne marche plus et on me dit � chaque fois "impossible d'ouvrir le fichier xxx, ce fichier n'existe pas".

� chaque fois, je contourne le probl�me avec un copier-coller � la main dans mon code .cpp ou en copiant le fichier � inclure dans le m�me dossier que celui de mon .cpp, s'il s'agit d'un include, ou en copiant le fichier que je voulais ouvrir � l'ex�cution dans le m�me dossier que celui o� se trouve mon .exe.

Mais, c'est p�nible...

Je suppose que quelque chose a chang� dans la syntaxe d'appel de fichiers, soit des fichier � inclure dans le code, soit des fichiers � lire � l'ex�cution, mais quoi ? Qu'est-ce qui a chang� ?

S'il y a une nouvelle syntaxe, je m'y conformerai, mais justement, j'ignore quelles sont les nouvelles r�gles !

Merci d'avance pour toute aide.

[bacelar]

Vous faites beaucoup d'erreurs et d'impr�cisions dans votre demande d'aide.
J'ai l'impression que vous �tes un novice en C++ (et en C) malgr� vos plus de 21 ans de pr�sence sur ce site.

Le fait que vous ayez post� dans un forum "Visual C++" n'indique donc pas forc�ment que vous utilisez "Visual Studio" comme IDE, n'est-ce pas ?

La gestion des fichiers d'inclusion dans un IDE et les chemins de fichier � l'ex�cution d'un programme n'ont pas grand-chose en commun, donc les mettre "� �galit�" dans une demande d'aide semble montrer une compl�te m�connaissance de leurs fonctionnements respectifs.

Je suppose que quelque chose a chang� dans la syntaxe d'appel de fichiers, soit des fichier � inclure dans le code, soit des fichiers � lire � l'ex�cution, mais quoi ? Qu'est-ce qui a chang� ?

�a sent plus un truc qui est "tomb� en marche" depuis des ann�es et que vos jours de chance se sont taris.

S'il y a une nouvelle syntaxe, je m'y conformerai, mais justement, j'ignore quelles sont les nouvelles r�gles !

Pas de nouvelle syntaxe ou r�gles, mais j'ai l'impression que vous ne connaissiez pas les "anciens" => "tomb� en marche".

Ce qui suit concerne des programmes "console".

Rien de ce que vous pr�sentez dans votre message n'a de sp�cificit� "console".
Vos jours de chance ne sont vraisemblablement pas encore tous taris en m�me temps.

j'ai des probl�mes avec mes #include lorsque les fichiers en question ne sont pas dans le m�me dossier que mon fichier .cpp

Bizarrement, vous ne mentionnez pas la diff�rence entre '#include "xxx.h"' et '#include <xxx.h>'. La seconde forme �tant � privil�gier en cas d'utilisation de fichier d'en-t�te "externe" au module (librairies, autres couches ou modules du projet).
je suppute qu'un fichier "pas dans le m�me dossier" n'est pas dans le m�me module, donc, avez-vous bien utilis� la second forme dans ce cas-l� ?
L'utilisation de la premi�re forme peut fonctionner un temps si votre IDE (Integrated Development Environment) est "bien" configur� (par chance ou par laxisme).

Le syst�me me r�pond syst�matiquement que le fichier en question n'existe pas.

Qu'entendez-vous pas "syst�me" ???
Contrairement � l'acc�s aux fichiers � l'ex�cution d'un programme, le syst�me d'exploitation n'a rien � voir (directement) avec la g�n�ration d'un ex�cutable ; qu'il soit console, fen�tr�, driver, service, etc...
C'est votre chaine de g�n�ration (pr�processeur + compilateur + �diteur de lien + optimiseur + etc... ) utilis�/configur� dans votre IDE qui est param�tr�e pour savoir o� aller chercher dans l'arborescence de fichier ces fichiers d'en-t�te "externes".

Comme vous n'avez jamais mentionn� ni votre IDE ni votre chaine de g�n�ration, je suppose qu'ils �taient, par chance, "bien" configur�s avant.
Un simple anti-virus, un changement de variable d'environnement, une mise � jour des outils etc..., peut casser cet alignement de plan�tes qu'est votre "chance".

Donc v�rifiez que (ou apprenez � vous servir efficacement de) votre IDE et/ou chaine de g�n�ration soi(en)t correctement param�tr�(s) pour vos projets.

M�me probl�me avec les library.

cf. probl�me des fichiers d'en-t�te "externes" ci-avant, ainsi que la probl�matique de la configuration de l'IDE que vous utilisez.

M�me probl�me avec les fichiers qui doivent �tre ouverts � l'ex�cution (avec fopen_s) qui ne sont pas dans le m�me dossier que celui qui contient le .exe.

Cela n'a rien � voir avec les fichiers d'en-t�te, et vous ne mentionnez pas le plus important : le r�pertoire de travail.
Les chemins relatifs le sont par rapport au r�pertoire de travail, pas par rapport r�pertoire contenant l'ex�cutable.
Il se peut que des OS mal configur�s/s�curis�s font croire que ce n'est pas important mais avec un patch de l'OS, vous vous retrouvez le bec dans l'eau.

Je pr�cise que ces nombreux programmes qui ne marchent plus, ont march� de nombreuses ann�es :

Probablement par chance, mais n'oublions pas qu'un anti-virus peut mettre en quarantaine tout et n'importe quoi, et cela, du jour au lendemain.
Les mis � jour de s�curit� peut aussi boucher un trou de s�curit� que vous utilisez indirectement par inadvertance.

subitement un programme qui marchait correctement, ne marche plus et on me dit � chaque fois "impossible d'ouvrir le fichier xxx, ce fichier n'existe pas".

Si votre mode de lancement a chang� le r�pertoire de travail ou qu'il ne fixe pas syst�matiquement (donc l'h�rite d'un machin qui, lui, a �volu� : variables d'environnement, liens, launcher, anti-virus, etc..), c'est "normale" que le "comportement" de votre programme change aussi.

ou en copiant le fichier que je voulais ouvrir � l'ex�cution dans le m�me dossier que celui o� se trouve mon .exe.

C'est que votre syst�me d'exploitation est toujours une passoire s�curitaire, et que votre programme est potentiellement un trou de s�curit�.

[ceugniet]

Bonjour bacelar,

Merci pour votre r�ponse rapide et particuli�rement d�taill�e.

Je pense que je vous dois quelques �claircissements.

Je suis aujourd'hui retrait�. Et je suis effectivement un novice en C.

J'utilise l'IDE Visual studio, pour visual C++. Mais je ne n'utilise que mes (maigres) connaissances en C.

Notamment : 1-Pour ouvrir et lire un fichier "fich" situ� dans le dossier D:\a\b\c
j'ai jusqu'� pr�sent utilis� la ligne

fopen_s(&f,"D:\\a\\b\\c\\fich", "rb");

2-Pour ins�rer des lignes de code situ�es dans le fichier "fichcode.h" du dossier D:\e\f\g pr�-existantes � un programme en cours, j'ai jusqu'� pr�sent utilis� l'instruction

#include "D:\\e\\f\\g\\fichcode.h"

Dans l'un et l'autre cas, ceci ne fonctionne plus chez moi. M�me si

La gestion des fichiers d'inclusion dans un IDE et les chemins de fichier � l'ex�cution d'un programme n'ont pas grand-chose en commun

j'y ai vu quand m�me une similitude et j'ai pens� qu'� l'occasion d'une mise � jour certaines r�gles pour g�rer l'acc�s aux fichiers avaient �volu�.

Votre conclusion

les mettre "� �galit�" dans une demande d'aide semble montrer une compl�te m�connaissance de leurs fonctionnements respectifs.

est certes tout � fait correcte.

C'est la raison pour laquelle je demande de l'aide...

Bizarrement, vous ne mentionnez pas la diff�rence entre '#include "xxx.h"' et '#include <xxx.h>'

J'utilise la forme #include <xxx.h> �galement par ignorance. J'ai vu des exemples de cette forme dans l'aide de l'IDE. Et j'utilise parfois cette forme en supposant que le compilateur ira chercher dans un dossier par d�faut :
par exemple, pour utiliser la fonction _getch(), j'utilise #include <conio.h>
et le compilateur va chercher <conio.h> quelque part. Je n'ai pas de probl�me � ce sujet.
Mais pour ce qui concerne les include de mes fichiers, j'ai pens� qu'il me fallait bien pr�ciser o� le compilateur doit aller chercher ce fichier. Il semble que cela ait march� jusqu'� maintenant.

Donc v�rifiez que (ou apprenez � vous servir efficacement de) votre IDE et/ou chaine de g�n�ration soi(en)t correctement param�tr�(s) pour vos projets.

Excellente id�e ; existe-t-il un tutoriel pour �a ? Que dois-je changer dans mes param�tres ?

En cliquant sur Projet puis propri�t�s, il y a r�pertoires Include et aussi R�pertoires Include externes et j'y trouve

$(VC_IncludePath);$(WindowsSDK_IncludePath);

Suis-je cens� ajouter ici le r�pertoire o� se trouve mon fichier include ?

Par ailleurs, vous dites que cela n'a rien � voir, mais alors comment puis-je remplacer la ligne

fopen_s(&f,"D:\\a\\b\\c\\fich", "rb");

pour que �a marche...

Merci en tous cas de votre aide.

[bacelar]

Je suis aujourd'hui retrait�. Et je suis effectivement un novice en C.

J'utilise l'IDE Visual studio, pour visual C++. Mais je ne n'utilise que mes (maigres) connaissances en C.

Attention, "Visual C++" aka MSVC n'est pas une chaine de g�n�ration C, mais C++.
MSVC ne respecte pas les normes C mais les normes C++.
Ce n'est donc pas un instrument � utiliser "sortie de l'�tag�re" pour faire du C "standardis�".

Pour utiliser une chaine de compilation respectant les normes C et non C++ dans Visual Studio, cela repr�sente, il me semble, un travail non n�gligeable et inaccessible � un d�butant.

Notamment : 1-Pour ouvrir et lire un fichier "fich" situ� dans le dossier D:\a\b\c
j'ai jusqu'� pr�sent utilis� la ligne

fopen_s(&f,"D:\\a\\b\\c\\fich", "rb");

"fopen", c'est de l'acc�s au syst�me de fichier au runtime, pas aux fichiers d'en-t�te.
Il s'agit d'un chemin absolu, car il commence par une lettre suivi de ":".
Il n'est donc pas relatif au r�pertoire de travail du processus ( processus <> de l'ex�cutable).
"fopen_s", c'est loin d'�tre un long fleuve tranquille (cassage de compatibilit� ascendante, normalisation C, partage "lisible" ou pas, etc...):
https://learn.microsoft.com/fr-fr/cp...?view=msvc-170
Je ne vois pas de rapport avec le fait de mettre les fichiers dans le m�me r�pertoire que le fichier "image" du processus, mais des rustines de r�trocompatibilit� ne sont pas � exclure.

Moi, je n'utilise jamais ces primitives si bas niveau de l'API C de Win32 mais les API C++ "filesystem" standard, pour ne pas avoir � jongler avec des rustines.

Question b�te, le lecteur "D:" de vos chemin, c'est un "vrai" disque ou un mapping "r�seau" ?
Cela peut expliquer que ces chemins jadis "valides" ne le sont plus avec cette antiquit� de "fopen_s" si la nature du lecteur "D:" ait chang�.

Par ailleurs, vous dites que cela n'a rien � voir, mais alors comment puis-je remplacer la ligne

fopen_s(&f,"D:\\a\\b\\c\\fich", "rb");

pour que �a marche...

Commencez par comprendre pourquoi cela ne fonctionne pas.
"D:" existe ?
"D:" c'est un "vrai" disque ?
"a" existe ?
etc...
Avec la documentation de "fopen_s", on voit que les cas qui d�connent avec cette antiquit�, c'est pas ce qui manque.

2-Pour ins�rer des lignes de code situ�es dans le fichier "fichcode.h" du dossier D:\e\f\g pr�-existantes � un programme en cours, j'ai jusqu'� pr�sent utilis� l'instruction

#include "D:\\e\\f\\g\\fichcode.h"

La diff�rence entre '#include "xxx.h"' et '#include <xxx.h>', c'est que la premi�re formule indique qu'il faut commencer la recherche du fichier "xxx.h" comme un chemin relatif au r�pertoire contenant le fichier en cours de compilation (le fichier .cpp ou .c) => donc "xxx.h" c'est rechercher dans "./xxx.h" avec "." le r�pertoire contenant le fichier .c ou .cpp en cours de compilation.
Si le fichier "./xxx.h" n'est pas trouv� dans le m�me r�pertoire que le fichier .c ou .cpp, le pr�processeur commence � regarder dans les r�pertoires indiqu�s dans la "liste des r�pertoires d'include" jusqu'� le trouver (donc l'ordre dans cette liste est importante), puis dans la "liste des r�pertoires d'include externes".
Avec '#include <xxx.h>', on indique au compilateur qu'il ne faut pas chercher � partir du r�pertoire contenant le fichier .c ou .cpp en cours de compilation mais directement dans la "liste des r�pertoires d'include".
Il est donc assez absurde de mettre un chemin absolu dans un #include.
La d�marche, c'est d'utiliser des '#include "../module/sousmodule/xxx.h"' pour des fichiers d'en-t�te "interne" au projet ; et des '#include <module/sousmodule/xxx.h>' pour des fichiers d'en-t�te externes, en ajoutant les racines des modules externes dans la "liste des r�pertoires d'include externe". Pour un "gros" projet, vous pouvez aussi fixer un r�pertoire interne au projet comme "racine" des fichiers d'en-t�te du projet et ajouter ce r�pertoire dans la liste des r�pertoires d'include "internes".

J'utilise la forme #include <xxx.h> �galement par ignorance. J'ai vu des exemples de cette forme dans l'aide de l'IDE. Et j'utilise parfois cette forme en supposant que le compilateur ira chercher dans un dossier par d�faut :
par exemple, pour utiliser la fonction _getch(), j'utilise #include <conio.h>
et le compilateur va chercher <conio.h> quelque part. Je n'ai pas de probl�me � ce sujet.

Cela montre que la "liste des r�pertoires d'include externe" de vos projets sont assez bien configur�es "de base".

En cliquant sur Projet puis propri�t�s, il y a r�pertoires Include et aussi R�pertoires Include externes et j'y trouve

$(VC_IncludePath);$(WindowsSDK_IncludePath);

Suis-je cens� ajouter ici le r�pertoire o� se trouve mon fichier include ?

Non, pas ceux de votre projet, uniquement les r�pertoires des biblioth�ques externes que vous utilisez dans votre projet, si elles n'y sont pas encore.

Pour les fichiers d'include de votre projet, utilisez la forme '#include "/toto/xxx.h"' avec un chemin relatif au r�pertoire contenant le fichier en cours de compilation. Comme d�j� indiqu�, pour un "gros" projet, vous pouvez aussi fixer un r�pertoire interne au projet comme "racine" des fichiers d'en-t�te du projet et ajouter ce r�pertoire dans la liste des r�pertoires d'include "internes".

j'y ai vu quand m�me une similitude et j'ai pens� qu'� l'occasion d'une mise � jour certaines r�gles pour g�rer l'acc�s aux fichiers avaient �volu�.

C'est parce que vous utilisez mal les m�canismes #include et que si une mise � jour "casse" un lecteur ou un chemin "en dur", c'est tous ces bugs latents qui vous arrivent � la figure.

Mais pour ce qui concerne les include de mes fichiers, j'ai pens� qu'il me fallait bien pr�ciser o� le compilateur doit aller chercher ce fichier. Il semble que cela ait march� jusqu'� maintenant.

Pas avec un chemin absolu en dur, �a fonctionnait par chance. Imaginez si vous vouliez d�placer le code source ailleurs sur votre disque ?

Excellente id�e ; existe-t-il un tutoriel pour �a ? Que dois-je changer dans mes param�tres ?

Vous avez trouvez les propri�t�s du projet, vous reste � comprendre comment �a marche.

[M�dinoc]

Selon la version de Visual Studio, le "r�pertoire courant" par d�faut lors de l'ex�cution du programme n'est pas le m�me, mais normalement on peut le r�gler explicitement dans les options du projet.
Mais tu peux d�j� commencer par d�terminer empiriquement quel est ce r�pertoire, en utilisant _getwcd() ou GetCurrentDirectory() dans l'ex�cution du programme...

[ceugniet]

Vous avez trouvez les propri�t�s du projet, vous reste � comprendre comment �a marche.

Oui, mais je ne comprends pas grand-chose aux propri�t�s.

J'ai essay� d'ajouter le r�pertoire o� se trouve une librairie appel�e par mon code, l'�diteur de lien ne se plaint plus de l'absence de ma librairie, mais d�sormais il se plaint de l'absence d'un autre librairie ("Kernel qqchose"); j'avais pourtant ajout� ma librairie � la fin, apr�s les librairies d�j� indiqu�es. Donc �a ne va pas non plus.

Existe-t-il un tuto qui explique ce que je dois changer dans les propri�t�s, et comment les changer ?

Finalement la ligne

fopen_s(&f,"D:\\a\\b\\c\\fich", "rb")

est-elle vraiment un sacril�ge ? Que dois-je faire pour que ce soit bien compris (et accept�) par l'ID ?

cet alignement de plan�tes

se reproduira-t-il ?

P.S. Le D: fait effectivement r�f�rence � un disque dur. Mais ce genre de r�f�rence � un fichier d'un support quelconque C:, D:, E: (cl� USB,CD) m'est tout � fait coutumier. Tout cela marchait bien (par chance ?), et cela ne marche plus.

[ceugniet]

Bonjour M�dinoc,

Merci de vous joindre � notre discussion.

Je n'ai pas de souci avec le "r�pertoire courant". J'utilise souvent la fonction _getwcd().

Lorsque je fais r�f�rence � un fichier, en g�n�ral, il se trouve dans le r�pertoire o� je me trouve en lan�ant le programme dans une invite de commande.

Mon probl�me est :

1 Que d�sormais, pour les fichiers qui ne sont pas dans mon r�pertoire de travail et pour lesquels je donne une position non pas relative, mais absolue, j'obtiens le message que mon fichier n'existe pas.

2 M�me chose pour les #include ---> Le fichier que je veux inclure n'existe pas

3 - M�me chose pour les librairies ---> la librairie n'existe pas !


Alors, que tout cela fonctionnait tr�s bien auparavant !!!

[bacelar]

Vous ajoutez dans le scope les librairies au moment de la compilation, c'est encore autre chose.
Pour vous, le probl�me est le m�me pour #include, fopen_s et les .lib en entr�e de l'�diteur de lien, mais c'est 3 "probl�mes" bien distincts.

Oui, mais je ne comprends pas grand-chose aux propri�t�s.
...
Existe-t-il un tuto qui explique ce que je dois changer dans les propri�t�s, et comment les changer ?

https://learn.microsoft.com/en-us/cp...?view=msvc-170

J'ai essay� d'ajouter le r�pertoire o� se trouve une librairie appel�e par mon code, l'�diteur de lien ne se plaint plus de l'absence de ma librairie

Qu'entendez-vous par "librairie", SVP ?
Si c'est une librairie "headers-only", ok, c'est li� au contenu de la propri�t� "Propri�t�s de configuration -> R�pertoires VC++ -> R�pertoires Include" pour r�cup�rer les .h de la "librairie".
Mais s'il s'agit d'une librairie ".lib", vous devez ajouter le r�pertoire contenant le fichier ".lib" dans "Propri�t�s de configuration -> R�pertoires VC++ -> R�pertoires de biblioth�ques" ainsi que le nom du fichier ".lib" dans "Propri�t�s de configuration -> Editeur de liens -> D�pendances suppl�mentaires"
Vous mentionnez l'�diteur de lien mais c'est dans "Propri�t�s de configuration -> Editeur de liens" que cela se configure, pas dans "Propri�t�s de configuration -> R�pertoires VC++ -> R�pertoires Include".
Si c'est une erreur d'�dition de lien, ce n'est pas la m�me chose qu'une erreur de compilation.
Il faut juste �tre rigoureux avec ces r�glages et pas tous confondre.

mais d�sormais il se plaint de l'absence d'un autre librairie ("Kernel qqchose"); j'avais pourtant ajout� ma librairie � la fin, apr�s les librairies d�j� indiqu�es. Donc �a ne va pas non plus.

�a doit �tre "Kernel32.lib", mais normalement, elle fait partie de la variable d'environnement "CoreLibrairyDependencies", mais si c'est l'�diteur de lien qui ne trouve pas "Kernel32.lib", c'est vraisemblablement que vous avez mal compris et modifi� "Propri�t�s de configuration -> R�pertoires VC++ -> R�pertoires de biblioth�ques pour qu'il contienne le r�pertoire o� "Kernel32.lib" est contenu dans votre installation de Visual Studio.

fopen_s(&f,"D:\\a\\b\\c\\fich", "rb")

est-elle vraiment un sacril�ge ? Que dois-je faire pour que ce soit bien compris (et accept�) par l'IDE ?

Il faut que vous fassiez la distinction entre ce qui se passe dans l'IDE : d�veloppement en �ditant du code, la compilation, la g�n�ration de l'ex�cutable ; avec ce qui se passe quand votre code s'ex�cute (dans une console ou dans le d�bugueur de l'IDE).
Votre "fopen_s" pose probl�me au moment de l'ex�cution, au "runtime", non ?
Donc pas grand-chose � voir avec votre IDE, sauf avec le param�trage du d�bugueur, si vous utilisez le d�bugueur de l'IDE.
"fopen_s", on vous a d�j� donn� sa documentation et elle montre un bon paquet de chausse-trapes.
Donc moi, je l'utilise pas.
Si vous vous en servez, vous devez comprendre TOUTE sa documentation.
Un "D:" visible dans l'explorateur de fichier n'est pas forcement visible/accessible par un programme, cf. la documentation de "fopen_s".

G�n�ralement, on utilise pas de chemin absolu en dur dans un programme car il devient extr�mement limit� en usage.
Un chemin en dur, mais relatif au "working directory" est d�j� plus envisageable car un programme d'installation peu faire "la glue" pour qui soit "plus" utilisable.
Mais pour un programme console, il est de bon ton que les chemins soient pass�s en param�tre de la ligne de commande.

se reproduira-t-il ?

P.S. Le D: fait effectivement r�f�rence � un disque dur.

"D:" est-il une "vraie" partition d'un "vrai" disque dur ? (pas de partage r�seau, pas de partition dynamique, pas de point de montage, pas de ....)
Si votre programme console ne voit pas de "D:" c'est que tr�s vraisemblablement ce n'est pas une "simple partition".
Un probl�me de droit donnerait un autre type d'erreur.

[bacelar]

Alors, que tout cela fonctionnait tr�s bien auparavant !!!

Tout cela peut s'expliquer par la simple "disparition" de D.

[ceugniet]

Bonjour,

J'ai peut-�tre donn� l'impression de me d�sint�resser de cette discussion tr�s utile. Mais je me suis juste �loign� deux semaines pour cause de vacances scolaires.

Commencez par comprendre pourquoi cela ne fonctionne pas.
"D:" existe ?
"D:" c'est un "vrai" disque ?
"a" existe ?

Oui, oui, et oui.

Je n'ai pas parl� de la configuration de mon PC. J'ai un stockage SSD de 237Go C: et un vrai disque dur de 931 Go D:.

J'ai d�cid� au d�part d'utiliser le disque dur pour stocker toutes mes activit�s en relation avec Visual C++.

Mais avant d'acheter ce dernier PC, j'avais uniquement un disque dur C:. Il n'y avait donc aucun probl�me avec D: qui n'existait pas.

Votre remarque

Tout cela peut s'expliquer par la simple "disparition" de D.

m'a donn� une id�e.

J'ai essay� de tout transf�rer, le source, les fichiers include, les librairies n�cessaires dans un dossier du disque C:

... et j'ai eu la surprise de voir que cela marchait parfaitement, comme auparavant.

J'ai essay� �galement de ne d�placer sur C: que les fichiers include et les librairies, en laissant le source sur D:

...et �a marche bien encore.

Cela m'arrange �videmment, mais je ne comprends pas pourquoi il faut sp�cifier dans le propri�t�s du projet les directories o� se trouvent les fichiers include si j'indique le chemin absolu de ces fichiers dans l'ordre "include".

Il me reste � trouver la raison de l'impossibilit� lors de l'ex�cution de lire certains fichiers non pr�sents dans le directory de travail.

� propos de ce que j'appelle librairie, il s'agit de fichiers .lib cr��s par mes soins avec Visual C++ .

[bacelar]

Oui, oui, et oui.

Ok, mais je ne vois pas comment vous avez pu tester "rapidement" apr�s migration des fichiers sur "C:" avoir � tout changer de "D:" vers "C:" fichier par fichier.
Votre "D:", n'est-ce pas un mapping ???
G�n�ralement, quand on fait du d�veloppement, et que l'on dispose de 2 supports physiques distinctes, on a tendance � s�parer les codes sources "internes" sur un support physique ou une partition d�di�e.
Ces codes sources "internes", c'est la vraie valeur de votre travail.
En les mettant dans une partition d�di�e, vous pouvez facilement s�curiser/optimiser/p�renniser votre travail via des outils d�di�s (sauvegarde automatiques, gestionnaire de versions, etc...).

Les IDE supportent indirectement cette mani�re de faire en disposant de 2 grandes cat�gories de "sources de code" : celles venant de l'environnement de d�veloppement, et celles venant du projet lui-m�me.
C'est un peu ce qui diff�rencie '#include <...>' et '#include "....h"' en C++. Le second privil�gie les liens "internes" et le premier les court-circuite.

Ce qui est li� � l'environnement ne devrait pas d�pendre du projet, donc sa configuration ne doit pas d�pendre du projet non plus.
Votre code devrait d�pendre le moins possible de votre environnement : c'est la portabilit� de votre code.

Comme l'installation de Visual Studio est assez int�gr� � l'OS (il modifie assez fortement l'OS et sa configuration), il est assez logique d'installer VS sur la partition de l'OS. Car si l'un part en sucette, l'autre est assez souvent impact�.
Votre code devrait survivre � la "contamination" de l'OS, donc mettre votre code dans une partition d�di�, ou tout du moins autre que celui de l'OS.

Mais le fait que votre "D:" n'est pas syst�matiquement mont� me fait dire qu'il n'y a pas un montage "direct" entre le disque dur et le "D:" de l'OS (que les drivers SATA et autres sont en charge de faire).
M�fiez-vous de l'explorateur de fichier qui peut afficher des choses comme un syst�me de fichiers "standard" des choses qui ne sont pas si standard que �a. Utilisez plut�t une console 'CMD' pour "v�rifier" les chemins des syst�mes de fichiers.

De toute fa�on, votre code ne devrait pas d�pendre d'o� il est sur le syst�me de fichier ou o� est install� l'IDE. Donc tout fichier 'interne" devrait �tre "acc�d�" via des chemins relatifs.
Pour le code venant de votre environnement, comme le C-Runtime, Win32, etc..., vous devez configurer votre IDE (ou via l'installeur) pour qu'il trouve "ses petits".

Si vous n'avez pas de propri�t� intellectuelle et que l'Open Source ne vous d�range pas, je vous conseille d'utiliser des outils comme GitLab ou GitHub pour disposer d'une sauvegarde en ligne de vos codes sources, ainsi que d'un moyen tr�s pratique de partager vos codes.

En respectant cette dichotomie, vous devriez pouvoir installer votre IDE et votre code source de mani�re compl�tement ind�pendante, tr�s pratique quand on travaille en �quipe.
Donc VS et consort (Windows SDK, etc...) sur C:, et vos codes sur D: (pour �tre sur que D: "existe" quand vous lancez votre projet dans l'IDE) me semble une configuration "correcte".

Pour les librairies qui ne sont ni dans l'IDE, ni de votre cru ou d'un autre de vos projets, il faut voir comment les mainteneurs ont con�u l'int�gration de leur cr�ation dans l'IDE.

[QUOTE]J'ai essay� de tout transf�rer, le source, les fichiers include, les librairies n�cessaires dans un dossier du disque C:

... et j'ai eu la surprise de voir que cela marchait parfaitement, comme auparavant./QUOTE]
Vous avez quand m�me chang� les chemins "en dur" pour les faires point� vers le chemin en "C:" correspondant, non ? Sinon, vous avez peut-�tre utilis� malgr� vous des syst�mes de cache, qui, s'ils sont mal configur�s, risque de vous arracher les cheveux.

Si vous faites ces changements, utilisez syst�matiquement des chemins relatifs pour les liens internes, et des chemins "relatifs � l'environnement" pour ce qui vient de l'environnement.
Votre code sera alors bien plus "portable".

J'ai essay� �galement de ne d�placer sur C: que les fichiers include et les librairies, en laissant le source sur D:

...et �a marche bien encore.

S'il s'agit des fichiers include et des librairies li�es � l'environnement, ou correctement configur�s dans l'environnement, c'est "normal", si vous n'avez pas utilis� de chemins "en dur".

Cela m'arrange �videmment, mais je ne comprends pas pourquoi il faut sp�cifier dans le propri�t�s du projet les directories o� se trouvent les fichiers include si j'indique le chemin absolu de ces fichiers dans l'ordre "include".

Attention � ne pas confondre les propri�t�s de l'environnement de d�veloppement, qui ne change pas d'un projet � un autre, des propri�t�s du projet qui ne valent que pour un projet donn�.
Vous configurez votre IDE pour qu'il trouve o� sont les diff�rentes versions du compilateur, des PlateformSDK, des Framework, les diff�rents d�bugueurs, etc... pour que vous puissiez vous en servir dans l'IDE.
Vous configurez votre projet pour qu'il puisse correctement utiliser les outils offerts par l'IDE.
Ainsi, vous ne devriez plus avoir besoin de chemins absolus et donc rendre votre code beaucoup beaucoup plus portable.
Il faut bien comprendre que tous les outils de d�veloppement sont con�u pour travailler en �quipe, car tr�s tr�s peu de projets "s�rieux" peuvent se faire en solo.

Il me reste � trouver la raison de l'impossibilit� lors de l'ex�cution de lire certains fichiers non pr�sents dans le directory de travail.

Si vous utilisez des chemins relatifs, donc relatifs au "working directory" et que vous ne maitrisez pas correctement ces chemins relatifs ni la valeur de ce "working directory", vous allez tourner en rond.
Mais votre arl�sienne de "D:" va compliqu� les choses.
Faites en sorte que votre projet puisse changer d'endroit dans votre syst�me de fichiers sans avoir � changer le code source et faites aussi en sorte que votre ex�cutable puisse aussi s'ex�cuter depuis n'importe o� dans ce syst�me.
Ainsi, si vous avez encore des probl�me avec votre "D:", vous n'avez qu'� transf�rer provisoire votre code source pour continuer � travailler tant que vous n'avez pas l'explication de cet "arl�sianisme".

� propos de ce que j'appelle librairie, il s'agit de fichiers .lib cr��s par mes soins avec Visual C++ .

Attention, les ".lib" venant d'autres sources que vous demandent � suivre des r�gles qui sont fournies dans leurs documentations.
Elles sont tr�s souvent diff�rentes d'une librairie � une autres, mais assez proches. Ne pas faire pour l'une ce que vous avez fait pour une autre mais en lisant leurs documentations � chacune, vous faites quasiment la m�me chose.
Pour les v�tres, je vous conseille, pour une meilleure int�gration, gestion des d�pendances, gestion des modifications, du d�buging, etc.., de faire des "solutions" dans Visual Studio et de configurer les d�pendances entre projet dans cette "solution".

[ceugniet]

Ok, mais je ne vois pas comment vous avez pu tester "rapidement" apr�s migration des fichiers sur "C:" avoir � tout changer de "D:" vers "C:" fichier par fichier.

Je ne comprends pas ce que vous ne comprenez pas ! Transf�rer mon programme de D: � C: cela consiste � cr�er un nouveau projet sur C: puis � faire un copier-coller sur .cpp de D: dans le nouveau .cpp de C:, d'une part, � copier les deux ou trois librairies utilis�es et les deux ou trois fichiers includ�s dans un directory de C: et remplacer les r�f�rences � ces fichiers librairies et aux fichiers include dans le code du programme .cpp. Tout cela prend 10 minutes.

Votre "D:", n'est-ce pas un mapping ???

J'ignore ce qu'est un mapping !
Je vous rappelle que

J'ai un stockage SSD de 237 Go C: et un vrai disque dur de 931 Go D:.J'ai d�cid� au d�part d'utiliser le disque dur pour stocker toutes mes activit�s en relation avec Visual C++.

En fait, mis � part le syst�me Windows, je n'avais strictement rien sur C: avant d'avoir fait ces tests. Pour mon utilisation, seul D: existait. C'est un vrai disque dur. Tout se passe comme si mon disque dur s'appelait D: au lieu de C:

Mais le fait que votre "D:" n'est pas syst�matiquement mont� me fait dire qu...

Je ne sais pas ce que veut dire "mont�", si cela ne signifie pas install�, ou branch�... Encore une fois je n'ai fait aucune manip. J'ai achet� ce PC parce qu'il avait deux supports de stockage (un SSD et un disque dur). C'est en d�marrant mon nouveau PC que j'ai constat� qu'il y avait un C: et un D:, et que le syst�me �tait sur C:. Lorsque j'ai install� Visual C++ on ne m'a pas demand� o� je voulais l'installer : il s'est install� tout seul sur C: sans me demander mon avis.

� vrai dire je ne comprends pas grand chose � ce que vous m'�crivez. Je suis retrait�, ancien informaticien (principalement en FORTRAN, parfois dans d'autres langages, COBOL, LISP, APL, BASIC, PASCAL, parfois en assembleur). En fin de carri�re j'ai souhait� apprendre le C que l'on ne m'avait jamais demand� d'apprendre. J'ai commenc� en lisant un petit livre format poche, qui �tait cens� me familiariser avec C, sur les grosses machines qui �taient � me disposition. Sur mon PC, J'ai utilis� Borland C++ tant que c'�tait gratuit, et j'ai ensuite utilis� Visual C++ parce que c'�tait gratuit et que Borland C++ ne l'�tait plus ! Mais je ne connais qu'une toute petite partie de C et quasiment rien de C++. Je tape sur mon PC pour m'amuser en programmant, et occasionnellement pour r�soudre des probl�mes de maths, ou des probl�mes de traitement d'images.

J'ai l'impression que vous me consid�rez comme capable de cr�er, optimiser, tester, des logiciels pour les vendre ensuite et les maintenir, mais j'en suis incapable et je ne le souhaite pas. Je ne suis qu'un novice qui �crit seul des programmes pour son seul b�n�fice et pour son seul plaisir.

Pour les include, et les librairies, c'est bon, gr�ce � vous j'ai trouv� le moyen de m'en sortir en pla�ant les fichiers include et les librairies sur le disque C:. Ce n'est peut-�tre pas tr�s satisfaisant pour vous, mais cela me suffit.

Reste que j'aurais aim� pouvoir ouvrir et lire n'importe quel fichier situ� sur n'importe quel support (D: (ailleurs sur mon disque dur), E: (sur une cl� USB), F: (sur un CD)...), avec les commandes fopen_s,fread..., car je ne connais rien d'autre que ces

antiquit�s

.

Moi, je n'utilise jamais ces primitives si bas niveau de l'API C de Win32 mais les API C++ "filesystem" standard, pour ne pas avoir � jongler avec des rustines.

Je ne sais pas o� trouver ces outils...

Je comprends que vous avez pass� beaucoup de temps et d�pens� beaucoup d'�nergie pour me r�pondre et je vous en suis tr�s reconnaissant. Mais n'oubliez pas que je ne suis qu'un d�butant qui est incapable de comprendre tous ces termes techniques qui ne sont accessibles qu'� des personnes ayant re�u un enseignement en bonne et due forme, ce qui n'est malheureusement pas mon cas.

[bacelar]

et remplacer les r�f�rences � ces fichiers librairies et aux fichiers include dans le code du programme .cpp. Tout cela prend 10 minutes.

Sur un projet plus "cons�quent", c'est le genre de chose qui ne se fait pas en 10 minutes, et encore moins sans erreurs.
En utilisant "correctement" les chemins relatifs, la configuration de votre projet et la configuration de votre IDE, c'est le genre de manipulation (changer l'endroit o� est le code) qui doit se faire sans aucune modification du code source, de quelques formes que se soit.

Vous devriez prendre rapidement cette habitude, votre code source ne devrait pas d�pendre de sa localisation dans le syst�me de fichier.
Tout un pan du C, et, par extension, du C++ n'est l� que pour pouvoir faire cette portabilit� : ne pas d�pendre de la localisation "absolue" du code source.

Attention, le C++ n'est pas/plus une extension du C mais un langage distinct.
Visual C++ est un compilateur/IDE C++ et non C. Il y a du code C "valide" qui ne compile pas correctement sous Visual C++.

J'ignore ce qu'est un mapping !

D�sol� pour mon jargonnage.
Sous Windows, il est assez courant qu'une "lettre" du syst�me de fichier (D:, E:, etc...) ne corresponde pas un "disque/partition physique" mais � un r�pertoire partag� sur le r�seau ou � un sous-r�pertoire dans une "autre lettre" (ou encore bien d'autres cas).
L'association d'une lettre � ce type de ressources (partage r�seau, sous-r�pertoire, etc...) est dit "mapper une lettre sur ...". D'o� le terme de mapping.
Ce type d'association est moins "fiable" qu'une association avec une partition ou un disque dur.
D'o� ma question.

Je vous rappelle que

J'ai un stockage SSD de 237 Go C: et un vrai disque dur de 931 Go D:.J'ai d�cid� au d�part d'utiliser le disque dur pour stocker toutes mes activit�s en relation avec Visual C++.

Ok, tr�s bien. C'est assez logique. Mais 931Go, juste pour vos d�veloppements, �a fait beaucoup.

Il faut bien comprendre que "C:" ou "D:" ne sont "grav�s" sur les "devices" (SSD et/ou HDD, DVD, BluRay, etc...).
C'est le syst�me d'exploitation, avec l'aide du BIOS, qui fait en sorte qu'un syst�me de fichiers soit accessible via "C:", "D:" ou m�me "E:".
Avec quelques manipulations dans le BIOS, ce que vous voyez dans Windows comme le lecteur "C:" ou "D:" peuvent facilement s'inverser.
Windows stocke des informations qui permettent de savoir � chaque d�marrage (si on ne bidouille pas le BIOS), o� trouver "physiquement" le syst�me de fichier qui sera accessible via "A:", via "B:", via "C:"; via "D:", via "E:", etc...
Par physiquement, c'est quel "device" sur quel bus de donn�es : PATA, SATA, M2, USB, etc... . Chaque "device" peut contenir un ou plusieurs syst�mes de fichiers. S'il contient plusieurs syst�mes de fichiers, on dit qu'il contient des "partitions" (ou partitions physiques).
Avec les Windows "modernes", il est possible de faire en sorte que des partitions "logiques" (avec un syst�me de fichier) soient sur plusieurs "devices" diff�rents via une agr�gation de partitions physiques pour faire ces partitions logiques.
Le syst�me va donc faire en sorte que ces diff�rents syst�mes de fichiers soient toujours associ�s aux m�me "lettre" (C:, D:, etc...) � chaque d�marrage du syst�me (quand tout fonctionne encore correctement ).
Je vous parle de �a car il est courant que les constructeurs planquent des partitions pour impl�menter leur m�canisme de restauration de la machine.

Je vous conseille donc de jeter un coup d'�il au gestionnaire des disques dans votre OS pour voir pr�cis�ment comment sont partitionn�s et mapp�s vos disques et partitions dans votre OS.
Il me semble que vous ne nous avez pas indiquer quel est votre OS. On ne peut donc pas �tre tr�s pr�cis sur "comment ouvrir le gestionnaire de disques".

Il y a peut-�tre un probl�me sur comment le constructeur a configur� l'OS au niveau du gestionnaire de disques pour que votre "D:" ne soit pas visible depuis votre IDE ou des programmes que vous lancez.

Si vous pouvez poster des copies d'�cran du gestionnaire de disques, �a peut peut-�tre �clairer nos lanternes.

Tout se passe comme si mon disque dur s'appelait D: au lieu de C:

Comme je l'ai illustr� ci-avant, les disques n'ont pas de nom (si, mais rien � voir avec les lettres des "lecteurs/device").
Si vos syst�mes de fichiers sont mapp�es arbitrairement entre C: ou D:, c'est qu'il y a un probl�me dans le BIOS, la pile sur la carte m�re, ou sur le disque de boot du syst�me. (�a sent pas bon)

Je ne sais pas ce que veut dire "mont�", si cela ne signifie pas install�, ou branch�

Encore d�sol� pour ce jargonnage.
Un terme qui provient plus d'Unix que de Windows.
Montez, "ici", c'est faire en sorte qu'un syst�me de fichier dans une partition soient associ�e, sous Windows � une lettre, sous Unix � un "chemin" arbitraire.
Comme indiqu� ci-avant, le lien entre un syst�me de fichier et une lettre n'est pas trivial et il faut un certain nombres d'�l�ments (drivers physique du bus, drivers du device, drivers pour comprendre les partitions sur le device, etc...) pour que l'utilisateur ne voit qu'une lettre : montage de tout ce bordel.

J'ai achet� ce PC parce qu'il avait deux supports de stockage (un SSD et un disque dur)

Ok, mais comme d�j� indiqu�, il est possible que cela ne soit pas si simple "physiquement".
cf. "copies d'�cran du gestionnaire de disque".

Lorsque j'ai install� Visual C++ on ne m'a pas demand� o� je voulais l'installer : il s'est install� tout seul sur C: sans me demander mon avis.

Un peu �trange, Visual C++ n'est plus distribu� seul depuis longtemps mais en bundle avec Visual Studio : l'IDE, normalement.
Je pense que vous aviez d�j� install� Visual Studio et qu'il s'est juste mis � jours avec le nouveau "WorkLoad" Visual C++ � l'endroit o� il �tait d�j� install�.
Quelle version de Visual C++ utilisez-vous, SVP ?

Mais Visual Studio et Visual C++ sur C:, si le SSD n'est pas fragile, c'est "logique".

� vrai dire je ne comprends pas grand chose � ce que vous m'�crivez.

D�sol�, n'h�sitez pas � demander des pr�cisions, �a �vitera que je m'�tale sur des d�tails inutiles.

Je suis retrait�, ancien informaticien (principalement en FORTRAN, parfois dans d'autres langages, COBOL, LISP, APL, BASIC, PASCAL, parfois en assembleur).

Oui, mais sur quels OS ?
Pas d'UNIX ? (concept de montage, de working directory, etc...)

En fin de carri�re j'ai souhait� apprendre le C que l'on ne m'avait jamais demand� d'apprendre.

Attention, C est diff�rent du C++.

Je tape sur mon PC pour m'amuser en programmant, et occasionnellement pour r�soudre des probl�mes de maths, ou des probl�mes de traitement d'images.

Oui, mais faites-vous un cadeau � vous-m�me, rendez votre code insensible � l'endroit o� les fichiers se trouvent. Sinon, il y a plein de chose dans le C ou le C++ que vous ne comprendrez pas.

Je ne suis qu'un novice qui �crit seul des programmes pour son seul b�n�fice et pour son seul plaisir.

C'est aussi agr�able de ne pas perdre des dizaines de minutes (voire des heures, des jours) en suivant les "bonnes pratiques" qui existent souvent depuis les ann�es 70, � la cr�ation du C et d'UNIX.

Pour les include, et les librairies, c'est bon, gr�ce � vous j'ai trouv� le moyen de m'en sortir en pla�ant les fichiers include et les librairies sur le disque C:. Ce n'est peut-�tre pas tr�s satisfaisant pour vous, mais cela me suffit

Si c'est des include et des librairies qui ne sont pas de votre cru, c'est ce qu'il faut faire, au moins dans un premier temps.
Pour ceux de votre cru, utilisez des chemins relatifs dans vos '#include "..."' devrait TOUT arranger.

Reste que j'aurais aim� pouvoir ouvrir et lire n'importe quel fichier situ� sur n'importe quel support (D: (ailleurs sur mon disque dur), E: (sur une cl� USB), F: (sur un CD)...)

V�rifiez avec le programme CMD.EXE s'ils sont accessibles depuis des programmes "console" lanc�s avec le m�me utilisateur Windows que vos programmes.

Je ne sais pas o� trouver ces outils...

Ils sont d�j� dans Visual C++, normalement.

[ceugniet]

Merci pour votre r�ponse, tr�s d�taill�e.

Sur un projet plus "cons�quent", c'est le genre de chose qui ne se fait pas en 10 minutes, et encore moins sans erreurs.

Il s'agissait de tester !

Vous m'avez mis la puce � l'oreille en utilisant le mot "disparition" pour le disque dur D:
Donc j'ai voulu tester si tous mes probl�mes n'�taient pas d�s au disque D:. Puisque je d�pla�ais la librairie j'�tais oblig� de changer la ligne de code faisant r�f�rence � cette librairie (et m�me si la r�f�rence �tait relative, j'aurais quand m�me d� changer la ligne).
Si je d�cide d'en rester l�, la librairie ne bougera plus et m�me si je d�place un programme, la r�f�rence en dur de la librairie n'aura pas � �tre chang�e.
D'ailleurs j'ai dit 10 minutes, mais je crois bien que c'�tait encre plus rapide car il n'y avait que deux ou trois lignes � corriger. J'ai mis dix minutes parce que j'ai fait ce test sur plusieurs programmes diff�rents...

En utilisant "correctement" les chemins relatifs, la configuration de votre projet et la configuration de votre IDE, c'est le genre de manipulation (changer l'endroit o� est le code) qui doit se faire sans aucune modification du code source, de quelques formes que se soit.

Je ne comprends pas.
Ma librairie, c'est pour cela que je l'ai cr��e, peut �tre utilis�e par un grand nombre de programmes.
Si elle est dans c:\a\b\c et que mon programme .cpp est dans D:\d\e\f\h comment r�f�rencer cette librairie avec un chemin RELATIF dans D:\d\e\f\h\monprog.cpp ?
Et comment cette r�f�rence "RELATIVE" peut rester sans changement si je d�place monprog.cpp ?

Il faut bien comprendre que "C:" ou "D:" ne sont "grav�s" sur les "devices"

Oui, je sais. Je voulais simplement dire qu'il m'arrive d'analyser le contenu d'une cl� USB ou d'un disque externe, qui ne s'appelleront en tous cas pas "C:"

Mais 931Go, juste pour vos d�veloppements, �a fait beaucoup.

J'avais �crit "J'ai d�cid� d'utiliser le disque dur pour stocker toutes mes activit�s en relation avec Visual C++.", je n'avais pas �crit "le disque dur ne sert qu'� Visual C++".
Tout ce qui concerne C++ est sur D: (enfin, �tait ; maintenant �a va changer). Mais D: contient tout, y compris mes programmes Visual C++, mis aussi mes photos, mes films, tout quoi !

Il me semble que vous ne nous avez pas indiquer quel est votre OS. On ne peut donc pas �tre tr�s pr�cis sur "comment ouvrir le gestionnaire de disques".

J'ai Windows 11 Famille, version 24H2 install� le 08/‎11/‎2024
J'ai cherch� le gestionnaire de disques, sans succ�s. Comment dois-je faire ?

(�a sent pas bon)

L�, vous m'inqui�tez !

Lorsque j'ai install� Visual C++ on ne m'a pas demand� o� je voulais l'installer : il s'est install� tout seul sur C: sans me demander mon avis.

Non, je corrige !

Lorsque j'ai install� Visual Studio on ne m'a pas demand� o� je voulais l'installer : il s'est install� tout seul sur C: sans me demander mon avis.

Je pense que vous aviez d�j� install� Visual Studio et qu'il s'est juste mis � jours avec le nouveau "WorkLoad" Visual C++ � l'endroit o� il �tait d�j� install�.
Quelle version de Visual C++ utilisez-vous, SVP ?

Visual Studio 2022

pour que l'utilisateur ne voit qu'une lettre

Bien dit ! Je suis un simple utilisateur, je ne vois qu'une lettre C, ou D, ou E... et je ne connais rien � toutes ces subtilit�s que vous avez mentionn�es.

si le SSD n'est pas fragile

J'ai achet� un nouveau PC parce que le disque dur de l'ancien fonctionnait de moins en moins bien et le PC �tait de plus en plus lent.
En achetant le nouveau, je me suis pos� la question de la solidit� du SSD par rapport � la solidit� d'un vrai disque dur.
En particulier, je sais que le syst�me est sur le SSD. C'est super ! Le d�marrage du PC, auparavant de l'ordre d'une ou deux minutes, est devenu de moins de dix secondes. Mais je crains qu'un jour sans pr�venir le SSD me l�che. Pour �viter ce genre de catastrophe, existe-t-il des moyens de "rafra�chir" les fichiers s'ils font partie du syst�me ?

Oui, mais sur quels OS ?
Pas d'UNIX ? (concept de montage, de working directory, etc...)

A part UNIX, je ne me souviens pas des noms des syst�mes. J'ai travaill� quelques ann�es sous UNIX, mais sans en conna�tre autre chose que le minimum pour un programmeur fortran.

Je ne sais pas o� trouver ces outils...
Ils sont d�j� dans Visual C++, normalement.

Je me suis mal exprim�. Je voulais dire je ne connais pas ces outils, et donc pas leurs modes d'emploi (je parle des "API C++ "filesystem" standard"). Qu'ils soient dans Visual C++, c'est bien, mais connaitre leurs noms et leurs mode d'emploi me permettrait de les essayer...

Merci encore du temps que vous passez pour m'aider.

[bacelar]

J'ai l'impression que vous faites souvent la confusion entre ce qui se passe au moment de la compilation et au moment de l'ex�cution.
Pourtant, sauf erreur de ma part, FORTRAN est un langage compil� et non interpr�t�, donc la distinction entre ces 2 moments devrait vous �tre famili�re, non ?

Cela fait qu'il y a 2 "probl�mes" distinctes :
- Comment g�rer les chemins dans l'environnement de d�veloppement et dans le code source en g�n�ral
- Comment g�rer les chemins lors de l'ex�cution d'un programme.

Il y a aussi un 3�me "probl�me", c'est pourquoi le lecteur "D:" se fait malle, mais c'est assez bizarre et vous ne nous donnez pas beaucoup d'informations pour ce sujet.
Voici des copies d'�cran pour voir le gestionnaire de disques de Windows 11 (remarquez que m�me avec ma configuration "basique" � un disque, c'est loin d'�tre aussi trivial) :


Si vous nous fournissez ces m�mes copies d'�cran pour votre configuration, peut-�tre qu'on aurait plus d'explications � votre probl�me de "D:" "qu'on voit, qu'on voit plus" (cf. Erik le Viking des Monty Python)

Puisque je d�pla�ais la librairie j'�tais oblig� de changer la ligne de code faisant r�f�rence � cette librairie (et m�me si la r�f�rence �tait relative, j'aurais quand m�me d� changer la ligne).

Non, si vous utilisez des chemins relatifs et que vous utilisez les bons m�canismes, vous n'aurez jamais � changer un chemin relatif.
Donnez-nous un exemple qui vous semble impossible de rendre relatif, SVP ?

Si je d�cide d'en rester l�, la librairie ne bougera plus et m�me si je d�place un programme

Je ne vous suis pas dans votre raisonnement.
Quand vous parlez de librairies, on parle de Dll (liaison Dynamique) ou de Lib (liaison Statique) ?
Dans le cas d'une Dll, c'est l'OS qui fait la liaison et les m�canismes sont bien plus complexe que "relatif versus absolu".
Dans le cas d'une Lib, le code binaire fait partie int�grante de l'ex�cutable, donc relatif ou absolu n'a aucun sens au moment de l'ex�cution. Au moment de la compilation, en fonction de la librairie, si elle est globale, comme la c-runtime, c'est un chemin relatif � l'installation de l'IDE ; si c'est sp�cifique � votre solution, c'est un chemin relatif aux projets de votre solution, etc, ; c'est toujours possible, et bien li�, en relatif.

la r�f�rence en dur de la librairie n'aura pas � �tre chang�e.

De quelle r�f�rence parlez-vous ???
A quel moment ? (ex�cution, compilation) ??
C'est vraiment pas clair, donc comme argument pour faire du "en dur", c'est tr�s moyen.
Je ne vois aucun cas o� l'utilisation de "r�f�rence en dur" n'a le moindre avantage. Pouvez-vous nous indiquer un "vrai" cas o� vous ne voyez pas moyen de faire autrement ?

D'ailleurs j'ai dit 10 minutes, mais je crois bien que c'�tait encre plus rapide car il n'y avait que deux ou trois lignes � corriger. J'ai mis dix minutes parce que j'ai fait ce test sur plusieurs programmes diff�rents...

Cela ne s'arrangera pas avec le temps.
Et vous pouvez vous retrouvez avec des cas o� �a compile par accident avec des chemins "erron�s" (MACRO � la con, vieux machin qui traine sur le disque, etc...).
Faites-vous une fleur, supprimez ces chemins "en dur".

Je ne comprends pas.

Vous n'avez pas � changer le code source de votre programme, juste parce qu'il a changer d'endroit sur le(s) disque(s). Si vous y �tes "oblig�", c'est une erreur de votre part. Que cela prenne 10 minutes, 10 secondes, mais surtout une probabilit� non n�gligeable d'erreur.

Ma librairie, c'est pour cela que je l'ai cr��e, peut �tre utilis�e par un grand nombre de programmes.

"librairie", dynamique ou statique ???
C'est quoi votre politique de compatibilit� ? (compatibilit� ascendante ou pas ?, mis � niveau automatique ?, comment g�rer les mont�s de version?, etc...)
Plus il y a de programme plus il faut une politique claire sur le sujet.
Moi, je vous conseille encore et toujours de lier vos projets dans une solution Visual Studio tant que vous n'avez pas statu� sur ce sujet.

Si elle est dans c:\a\b\c et que mon programme .cpp est dans D:\d\e\f\h comment r�f�rencer cette librairie avec un chemin RELATIF dans D:\d\e\f\h\monprog.cpp ?

On est � quel moment, SVP ??? � la compilation ou � l'ex�cution ?
Si c'est � l'ex�cution, l'endroit o� est le fichier .cpp, on s'en fout compl�tement (sauf pour le d�bugging mais c'est une autre histoire).
Si c'est � la compilation, qu'entendez-vous par "r�f�rencer cette librairie" ? Les .h, les .lib, les .dll ?
Vous disposez de toutes les options, aussi bien au niveau du projet de la librairie que du projet client de la librairie, via une solution Visual Studio ou pas, pour faire en sorte que les fichiers n�cessaires soient accessibles.
Donnez-nous un cas concret qui vous pose probl�me, SVP ?

Et comment cette r�f�rence "RELATIVE" peut rester sans changement si je d�place monprog.cpp ?

Si c'est au moment de la compilation, faut juste que le post-build du projet librairie publie ces .h publiques et .lib dans un r�pertoire relatif � la solution VS et que vous configurez vos projets client de la librairie regardent dans ce r�pertoire, par exemple.

Mais D: contient tout, y compris mes programmes Visual C++, mis aussi mes photos, mes films, tout quoi !

Tout ce qui a de la valeur. D'o� le fait de les garder dans une partie distincte, pour lui adjoindre le plus de pr�cotions : partition en RAID, sauvegardes r�guli�res, enregistrement online, etc...

J'ai cherch� le gestionnaire de disques, sans succ�s. Comment dois-je faire ?

cf. copies d'�cran ci-avant.

Mais je crains qu'un jour sans pr�venir le SSD me l�che. Pour �viter ce genre de catastrophe, existe-t-il des moyens de "rafra�chir" les fichiers s'ils font partie du syst�me ?

Si votre SSD n'est pas d'une sous-marque, le niveau de fiabilit� des SSD atteins celui des HDD (qui n'est pas increvable, loin de l�).
Le firmware et les drivers des SDD sont d�j� r�fl�chis pour faire migrer r�guli�rement les fichiers pour ne pas sur-user certaines parties des m�moires.

et donc pas leurs modes d'emploi (je parle des "API C++ "filesystem" standard"). Qu'ils soient dans Visual C++, c'est bien, mais connaitre leurs noms et leurs mode d'emploi me permettrait de les essayer...

https://en.cppreference.com/w/cpp/filesystem