Discussion :

[Invité]

Bonjour,

Tout est dans l'intitulé. Je voudrais savoir si il existe une bibliothèque C/C++ permettant de lister le contenu d'un répertoire de manière portable.

[Bousk]

boost::filesystem

[Abacar94]

Bonjour,

Tout est dans l'intitulé. Je voudrais savoir si il existe une bibliothèque C/C++ permettant de lister le contenu d'un répertoire de manière portable.

En C++ c'est facile

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
system(dir > nomfichier)

C'est une commande system elle permet d’écrire le contenu du répertoire dans le fichier qu'on veut.....mais sa c'est la commande sur Windows

[ternel]

Du coup, ce n'est pas portable du tout.

boost::filesystem est probablement la meilleure réponse générale.

[camboui]

Pareil pour boost::filesystem
(d'ailleurs, filesystem n'est-il pas prévu d'être incorporer dans le standard C++ ?)

Sinon, en trois coup de cuillère à pot j'ai pondu ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
void InsideDir(std::_tstring const & path)
{
	std::_tstring vFileName(path);
	_tfinddata_t vFileData;
	intptr_t vHandle;
 
	vFileName.append(_T("*"));
	vHandle = _tfindfirst(vFileName.c_str(), &vFileData);
 
	int vRet = 0;
	while (vHandle > 0 && vRet == 0)
	{
		if (!(vFileData.attrib & _A_SUBDIR))
		{
			std::_tstring filename(vFileData.name);
			...
			your code
			...
		}
		else if (vFileData.name[0] != _T('.'))
		{
			vFileName = path;
			vFileName += vFileData.name;
			vFileName += _T('\\');
			InsideDir(vFileName);
		}
		vRet = _tfindnext(vHandle, &vFileData);
	}
}

Je ne suis pas sûr que les macros commençant par _t... soient standards telles quelles, mais le code est compréhensible et les fonctions C sous-jacentes assez évidentes

[ac_wingless]

La librairie Boost::filesystem n'était pas portable (de nombreux compilateurs ne proposant pas Boost), mais vient d'être promue au standard C++17: http://en.cppreference.com/w/cpp/filesystem
Du coup, maintenant elle est ... toujours pas portable! (de nombreux compilateurs n'étant pas à jour pour C++17). Mais bon, ça va dans le bon sens et devrait arriver rapidement chez la majorité des développeurs C++.

[bacelar]

@ac_wingless, vous confondez standard et portable.

[ac_wingless]

@ac_wingless, vous confondez standard et portable.

Je ne crois pas... Relisez?

[ternel]

Justement.

Un compilateur ne fournit pas Boost. Il n'a pas à le faire.

Boost est un ensemble de bibliothèques utilisables en C++.
Boost.filesystem est l'une d'elle, et c'est l'une des rares qui ne soit pas header only.
Du coup, la version compilée pour un système donné n'est pas utilisable sur un autre. Mais la bibliothèque en tant que telle est portable, puisqu'elle est compilable sur tous les systèmes classiques (et pleins d'autres plus spécifiques).

La portabilité d'un code n'est pas d'être fourni par un compilateur, mais d'être compilable sur plusieurs cibles. En fait, est portable (sur un système) ce qui peut être porté (sur ce système), c'est à dire compilé moyennant un ou deux réglages (genre, détecter la bitness).

Ce qui est standard, c'est uniquement la bibliothèque standard, c'est à dire celle prévue par la norme

[jblecanard]

Je pense que ce que ac_wingless veut dire est : le code utilisant std::filesystem n'est pas portable. Et c'est exact en raison du support incomplet des compilateurs. Ca deviendra portable, à terme.

Du code utilisant boost::filesystem sera, lui, portable dès aujourd'hui.

[ac_wingless]

Je dis simplement que Boost n'est pas portable, ce qui est curieusement contredit par ternel ("la bibliothèque en tant que telle est portable, puisqu'elle est compilable sur tous les systèmes classiques"). Il suffit de voir le nombre de compilateurs qui ne peuvent pas la compiler. Voir la page de compatibilité de Boost et les nombreuses macro de portage avec perte de fonctionnalité. Des compilateurs majeurs (Embarcadero avant qu'ils en viennent enfin à Clang) ont du proposer pendant de nombreuses années (2007-2013) des patches de Boost, d'autres (Sun) ont toujours quelques versions de retard.

Pour revenir au concret de la question originale: si votre compilateur ne propose pas encore std::filesystem (hautement probable), mais qu'il fournit boost::filesystem (déjà bien plus courant), je vous conseille une directive using qui sera facilement modifiable une fois votre compilateur conforme au C++17. Faites attention à n'utiliser que les fonctionnalités sanctifiées par le standard, car il y a parfois de la perte entre boost et std. Par exemple, std::lock ne permet pas des verrous multiples sur une paire d'itérateurs, alors que boost::lock le proposait. Normalement, Boost amende sa documentation une fois qu'une librairie passe en std::, en labellisant clairement comme extensions les fonctions non retenues dans le standard.

[koala01]

Salut,

Pour revenir au concret de la question originale: si votre compilateur ne propose pas encore std::filesystem (hautement probable), mais qu'il fournit boost::filesystem (déjà bien plus courant), je vous conseille une directive using qui sera facilement modifiable une fois votre compilateur conforme au C++17. Faites attention à n'utiliser que les fonctionnalités sanctifiées par le standard, car il y a parfois de la perte entre boost et std. Par exemple, std::lock ne permet pas des verrous multiples sur une paire d'itérateurs, alors que boost::lock le proposait. Normalement, Boost amende sa documentation une fois qu'une librairie passe en std::, en labellisant clairement comme extensions les fonctions non retenues dans le standard.

En fait, tout le problème vient du fait que tu utilise le terme "fournir", alors que tu devrais pour bien faire utiliser un terme proche de "est capable de compiler" quand tu parles de boost (quelle que soit la partie envisagée de ce framework)...

Car aucun compilateur n'a à "fournir" la moindre bibliothèque externe, à l'exception bien sur de la S(T)L (*)

Il existe, effectivement, quelques (versions de) compilateurs (généralement les plus anciennes) qui éprouvent "quelques difficultés" à compiler boost. On peut donc dire qu'il y a "des problèmes de compatibilité" avec boost. Cela, personne de sensé ne pourra le contredire. Tout comme on doit considérer qu'il y a des "problème de compatibilité" entre la version de la S(T)L proposée par les normes C++11 (et ultérieures) et celles proposées par les normes antérieures à C++11.

Il n'y a en effet aucune raison pour qu'un compilateur qui (prétend) respecte(r) une "ancienne norme" de C++propose le support d'une fonctionnalité qui n'est arrivée que... bien après la sortie de la norme qu'il respecte . std::(experimental::)filesystem a donc bel et bien pour vocation d'être portable, dans le sens où tous les compilateurs respectant la norme C++17 seront obligés d'en fournir une implémentation correcte. Mais il est tout à fait logique que, si tu décide d'utiliser VC++6 ou gcc3 (qui datent de ... bien longtemps avant la sortie de C++17), ils risquent effectivement de t'envoyer sur les roses si tu essaye d'y avoir recours

Certains de ces "problèmes de compatibilité" peuvent être relatifs à un(e version d'un) compilateur particulier. D'autres sont plus embêtant car ils sont relatifs à une architecture ou à un système d'exploitation particulier.

Mais, de là à dire que ce n'est pas portable, il y a de la marge!!! D'autant plus que la notion de portabilité est totalement indépendante du compilateur, mais s'attarde d'avantage sur... l'architecture ou sur le système d'exploitation utilisé. Si bien que "dés qu'il est possible" de trouver "un compilateur" (qui n'est peut être pas celui que tu utilises!!!) susceptible supporter une bibliothèque externe pour l'architecture (ou pour le système d'exploitation), on peut effectivement dire que "la bibliothèque externe est portable" sur cette architecture (ou ce système d'exploitation particulier).

Boost (en générale) et boost::filesystem (en particulier) entre(nt) donc bel et bien dans la catégorie des "bibliothèques externes portables", car elle il est -- effectivement -- possible d'en profiter sur plusieurs architectures et avec plusieurs système d'exploitation totalement différents. A l'inverse de biblothèques comme winsok (par exemple) qui ne peut être utilisée que... sur windows.

Quant à la perte de fonctionnalité, elle rentre effectivement dans le cadre de ces "problèmes de compatibilité". Mais, si tu regarde boost::filesystème (vu que cet l'exemple qui nous déchire pour l'instant), il est "normal" que l'on ne puisse -- par exemple -- pas définir les droits (lecture/écriture/exécution) associés à un utilisateur, à un groupe ou au "reste du monde"(comme il est possible de le faire sous unixoide) sous windows, vu que... la gestion des droits sous windows se fait de manière totalement différente.

Mais tous les systèmes d'exploitation que je connais proposent des fonctionnalités permettant de gérer des dossiers et des fichiers. Et, même si, au final, les seules fonctionnalités de boost que l'on a la certitude de retrouver quel que soit le système d'exploitation dans boost::filesystem se limite à l'ensemble des fonctionnalités qui sont communes à tous les systèmes d'exploitation (sur lesquels il est possible de compiler boost::filesystem), cette bibliothèque est bel et bien compatible que l'appel à une fonction qui n'est accessible que pour un système d'exploitation particulier (et ce, même si cette fonctionnalité est disponible sur "la plupart des versions de ce système d'exploitation).

Or, tout ce qui a trait à la commande system est, par nature, limité à un système d'exploitation particulier. Et ca, c'est un frein majeur à la notion de portabilité

(*) Car oui, bien qu'une (ou plusieurs) version(s) de la S(T)L soi(en)t fournie(s) d'office avec tous les compilateurs qui prétendent respecter une norme bien particulière, on peut considérer la S(T)L comme une bibliothèque externe, vu qu'elle implique l'inclusion de fichiers d'en-tête et des flags spécifiques lors de la compilation et de l'édition de liens, même si ces flags sont "automatiquement" rajoutés dans les différents outils.

[ac_wingless]

Tu as raison sur l'utilisation du vocable "fournir", mal choisi pour le cas général (même si certains compilateurs la fournissent bien).
Sur le fond, les opinions sur la portabilité de Boost peuvent diverger le long d'un spectre, je note la tienne, la mienne diffère. En l'occurrence pour ma société, il y a une corrélation entre la taille de nos clients et le niveau d'interdiction de Boost. J'expliquais déjà dans un post ancien comment un projet de 2-3 programmeurs pouvait profiter de boost (1.43 à l'époque du post...), mais que c'était irréaliste dans un environnement industriel, quasiment systématiquement hétérogène et en retard par construction (équilibre entre "avoir fait ses preuves" et "être à la pointe"). Mes interlocuteurs sont convaincus lorsque cet équilibre penche du coté qui les concerne (portabilité à long terme), par exemple lorsque la librairie en question sort de boost, perçu plutôt comme incubateur que comme référence par la plupart des groupes avec lesquels nous travaillons.

La portabilité de Boost mérite peut-être un débat (bof - la situation est très claire pour tout le monde), mais je rappelle que je répondais à une remarque abrupte et là pour le moins totalement infondée, disant que je confondais standard et portabilité. std::filesystem est standard, boost::filesystem ne l'est pas. Aucune n'est portable aujourd'hui. Je ne dis pas autre chose dans mon post initial de deux lignes. Fallait-il vraiment des sous-titres?

[Danny-k]

Aucune n'est portable aujourd'hui. Je ne dis pas autre chose dans mon post initial de deux lignes. Fallait-il vraiment des sous-titres?

Sur quelle plateforme boost::filesystem n'est pas portable ? Car je l'utilise au travail, je l'ai compilé sur les visual allant de VC++ 6 a Visual Studio 2015, GCC 3.4.6 a 6.0, Clang 3.4 a 3.9, Sun Studio.
J'ai un comportement identique (hormis le '/' sous Linux, et le '\\' sous windows, mais ça change rien au final) sur chacune de ces plateformes.