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