Bonjour à tous,
 
Je cherche à récupérer la liste de tous les fichiers présents dans un répertoire, en C++. De ce que j'ai lû jusqu'à présent, le code diffère selon l'environnement :
 

 
 
J'aimerais donc savoir comment faire pour intégrer ces deux portions de code à mon application et faire en sorte de détecter l'environnement pour exécuter le bon code? J'ai pensé à des macros, mais je n'en ai encore jamais utilisé, donc si quelqu'un a un exemple sur la façon de faire?...
 
Ou, encore mieux, un code portable qui m'évite d'avoir à détecter l'environnement?    
 
Merci d'avance!

Salut

boost::filesystem est portable.

#include <stdio.h>
#include <dirent.h>
C'est du C, pas du C++.

Bonjour,
 
j'ai déjà utilisé dirent sous WIN32 sans problème...

Salut,
 
dirent doit fonctionner sous windows en effet. Mais c'est du C, pas du C++. Enfin le code posté est entièrement en C donc je ne sais pas trop ce que veut Wouzz.

Certes mais le C++, c'est aussi du C    
 

Testé et approuvé!
La prochaine fois j'essayerai avant de demander    
 
Merci beaucoup.  

En aucun cas!!!
Je ne sais pas qui t'a mis cette con****ie  dans la tête mais oublie tout de suite.

Ce que je veux dire c'est qu'un code C passe avec un compilateur C++, et c'est tout ce qu'il me faut.

http://en.wikipedia.org/wiki/Compa [...] nd_C%2B%2B

 
Il y a un large sous-ensemble partage (un peu moins large avec C99), mais rares sont les programmes ecrits en C idiomatique qui compilent sans modification avec un compilateur C++.  (Pb n 1: le resultat de malloc() n'est traditionnellement pas caste en C, c'est une erreur en C++).

Ouais ok ça marche mais bon il y a une bonne différence entre quelque chose qui marche et quelque chose de correct. On ne m'ôtera pas l'idée que si tu es obligé de compiler un programme en C avec un compilateur C++ c'est que tu ne sais pas ce que tu fais. Et quand on ne sait pas ce qu'on fait, ça finit rarement bien en programmation.

 
Ce n'est pas incorrect d'inclure du code C dans un programme C++. Parfois même, on n'a pas le choix (bibliothèques écrites en C par exemple).
 
D'ailleurs, la totalité des appels système sous linux sont en C. Qu'on les appelle directement ou en passant par une bibliothèque C++ qui les encapsule ne change rien.

Oui mais cette bibliothèque en C est compilée par un compilateur C.
Moi aussi j'utilise des bibliothèques C dans du code en C++. Au final ce n'est qu'une édition de lien. Le code C est compilé par un compilateur C et le C++ par un compilateur C++.

Et il y a quand même une grosse différence entre appeler des fonctions d'une bibliothèque codée en C (à la limite on s'en fiche de savoir en quoi elle est codée, on appelle juste les fonctions) et compiler avec g++ un code en C  (include <stdio.h>, dirent, printf). Un code comme ça compilé avec g++ c'est soit qu'il y a un mélange entre les 2 langages et que du coup ça ne compile pas avec gcc et on se dit bon ben avec g++ ça marche c'est cool, soit que l'on considère le C++ comme un "add on" du C qui permet le code objet.

 
 
Et la bibliothèque qui encapsule ça  (boost par exemple) , tu crois qu'elle fait comment ?  
 
Son code est parfaitement valide en C++, il ne s'agit que d'appels système C , donc d'une bibliothèque codée et compilée en C comme tu le précises.
 
 
 
 
 

Nous sommes donc d'accord, le C est compilé par un compilateur C.
 
Ok pour les appels systèmes de fichiers, je m'ai trompé. [Mode j'ai toujours raison]N'empêche qu'il existe des méthodes pratiques en vrai C++ (basés sur les mêmes appels systèmes codés en C   )plutôt que de réinventer la roue.[/Mode j'ai toujours raison]
 
Pas ok pour stdio.h et printf. Pour moi ça trahit que tout le reste est pensé en C et compilé avec g++ parce qu'il laisse passer certaines choses comme les déclarations au milieu du code (il faut utiliser C99 avec gcc non?) ou alors parce qu'on peut faire de jolies classes en plein milieu du C. Ou utiliser des bouts de code attrapés de ci de là en C au milieu d'un code C++. Tout cela est possible, ça marche. Est-ce que c'est bien pour la qualité du programme et sa maintenance?
 

 
Oui dans une certaine limite...
 

 
Clairement non!!

 
Je suis d'accord avec toi aussi.  Cependant, ca ne sert à rien de sigmatiser systématiquement tout appel C dans un code C++, rien n'empêche d'écrire ses propres wrappers plutot que d'utiliser les existants (réinventer la roue c'est mal, mais des fois pas le choix).  
 
Par exemple, pour ma part, lorsque j'ai commencé le programme sur lequel je travaille depuis maintenant 7  ans ( 100000 lignes de code, commentaires et autre non-code exclus), boost n'existait pas et il était hors de question d'intégrer STL. Nous (moi au départ) avons donc réécrit nos propres structures de données (dynarray , hashtable, smart pointeur, singleton, etc ..., + des wrappers portables pour les mutex, thread, et autres) un genre de boost (very) light quoi , maintenant il serait mieux d'avoir boost pour des raisons de performances et de maintenance, mais il serait trop couteux de tout réécrire, alors on maintient ce qu'on a fait (et ca contient beaucoup de code C pardon, appel système C  et d'assembleur) et finalement, c'est pas si mal, ça permet également d'apprendre plein de choses, et lorsqu'une nouvelle plateforme apparait, il est plus facile pour nous de la réadapter (parfois même pas besoin).
 
Lorsque c'est bien cloisonné, ça ne pose aucun problème.
 
Et accessoirement, pour debugguer rapidement, il m'arrive d'utiliser un (f)printf pour aller plus vite, malgré la superbe classe de log que j'ai écrite .

paye ta code quality

On est en 2010 maintenant  
Blague à part pour moi c'est quand même  une mauvaise habitude. Si on veut réinventer la roue dans un but pédagogique (ce que je pense indispensable) en faisant du C, ben on fait du C. Faire du C++ et puis "Tiens je vais faire moi même un parcours de répertoire pour voir comment ça marche" ça ne sert qu'à ne pas apprendre la bonne manière, selon moi.