Salut,
 
Une question pratique à deux balles. Je suis un train d'écrire un système de lecture/ecriture trés bas niveau (faut gérer un système de recovery pour une application critique) et j'hésite entre utiliser directement:

• read/write (pas de buffer)
• ou fread/fwrite (stream, buffer)

J'étais joyeusement parti sur read/write, en recréant un buffer quand je me suis aperçu que fread/fwrite avait mon buffer! Mais comme je cherche un code clean et optimisé pour mon utilisation, j'aimerais savoir de quel buffer on parle:
1) c'est juste un buffer pour regrouper les commandes?
2) le buffer est intelligent et si j'écris le code dessous, il n'ira pas faire d'accés disque pour le lire le contenu mais il s'apercevra qu'il a déjà ce que je lui demande dans son buffer?

(désolé pour les erreurs de code, c'est juste l'idée qui compte)
 
Merci de vos éclaircissements!

Mais j'y pense read/write n'est pas standardisé??? Ca fait du vieux standard Unix C...

et faire du C++, ça te dit? si oui laisse tombr tes cast à la con, et utilise les std::fstream

 
Tiens j'y avais pas pense Les fstream (sur lesquels on a aucun controle) pour gerer un systeme de recovery, c'est tres moyen!
Cela dit, si les fstream se comportent comme mon 2), j'achete...

ben heureusement que les fstream sont buferrises!!!!

 
Pareil? ils gerent un systeme de page/cluster et on pas besoin d'aller charger une page sur le disque s'ils l'ont deja charge?
 
Oh putain, la revelation , toujours utilises sans me soucier du buffer (j'avais pas de prb de perf!)
 
Edit: Ben oui, je viens de me taper la specification...monstrueux!!

t'es completement à la masse toi... tu débarques d'ou?

ouais mais regarde son nom, le gars c'est willyzekid quoi

 
Cela dit, ca me donne pas beaucoup (suffisament?) de contrôle sur le buffer. Pour l'algorithme ARIES, il faut au minimum (!) que je sache ce qui est commited et ce qui ne l'ai pas. Or même en héritant de basic_filebuf et en le passant à mon fstream, je suis même pas sûr de pouvoir obtenir cette info.

ben de toutes façon aucun système te donnera cette assurance. si tu veux avoir un controle tres precis, sous linux par exemple, ben si tu recuperes le descripteur de fichier, tu peux faire ce que tu veux. tu peux aussi dimensionner la taille du buffer à ta guise. maintenant, je crois que t'as interet à utiliser une version standard bufferisé, par ce que je te sens pas du tout faire ta propre version

 
Le buffer est construit/géré par la STL ou la STL ne fait que reprendre le buffer et la stratégie de l'OS? Et quid de fwrite/fread?
 
Sinon existe-t-il une fonction (standardisé, on peut réver) qui permet d'accéder aux fichiers sans buffer?

ben tout dépend... de l'implémentation... tu peux meme avoir de fstream basé sur les FILE*. pour les acces non bufferisés fo voir avec ton OS. moi j'utiliserai sans crainte les fonctions standard bufferisés par ce que les performances n'ont un peu rien à voir.

Bon, c'est pas la joie....Je vais effectivement utiliser la STL dans un premier temps. Et peut-être créer un système de buffer autour de système call basiques si les inconvenients de la STL l'emportent sur le bordel que c'est d'écrire un truc portable et efficace (!!!!)
 
Dans l'état, je vois deux problèmes de la STL (j'indique l'état de mes recherche pour monter un peu le niveau de ce topic et pour aider d'autres personnes qui passeraient par là).

• Toujours le problème de système de recupération de crash ingérable sans accés aux flags du buffer.
• Je gére de gros fichiers (type database) sur Win et Linux. La STL et FILE* (sur laquelle l'implémentation Windows de la STL repose) utilisent la stratégie du LRU (Least Recently Used) pour gérer le cache. Or c'est pas bon pour gérer des gros fichiers qui peuvent être lu séquentiellement. Avec un fichier de 10000 records parcourus 2 fois séquentiellement, avec 50ms d'overhead par record passé a un buffer contenant 1000 records, on a 100 000ms d'overhead du au buffer dans le cas de la LRU (a chaque lecture, on a une ecriture dans le buffer). Avec la MRU (Most Recently Used), on a (2*(10000-1000)+1000)*50=95000 seulement (au deuxième parcours du fichier, on a déjà 1000 records en mémoire). Soit 5% de perf en plus...Est-ce que ca vaut le coup de se faire chier pour 5%?

A titre d'info, voici une comparaison intéressante entre les différents moyen d'accés / librairies :
http://www.cs.utk.edu/~plank/plank [...] cture.html
 
Edit: pour rendre ce post un peu plus clair