Ecriture binaire d'un vector

Bonjour,

Est-il correct de supposer que les données d'un vector sont stockées contiguement et de tenter une écriture binaire de la sorte :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

template<typename T> inline std::ostream & BinaryWriteArray( std::ostream & os, T const * p, size_t lg ) { return os.write( reinterpret_cast<char const *>( p ), lg*sizeof(T) ); }     void f() { vector<float> vec;   // ...   BinaryWriteArray( file, &vec[0], vec.size() ); }

---

Oui, c'est garanti par la norme.

Ce qui n'est pas garanti, par contre, c'est la représentation mémoire des éléments. Elle peut varier d'une plateforme à une autre, d'un compilateur à un autre et même d'une option de compilation à une autre.

Dans mon cas, peu importe les problèmes d'endianess, si c'est ce à quoi tu fais référence : mon fichier sera lu sur une architecture avec le même endian qu'il a été écrit.

Par contre :

Citation:

---

d'un compilateur à un autre et même d'une option de compilation à une autre.

---

Je ne vois ni de quoi tu veux parler, ni ce que ça peut impliquer ?

Hello NiamorH,

C'est toi qui as les détails du projet, mais d'une manière générale, il faut éviter les suppositions sur les plate-formes et les architectures - demande à tous les développeurs Mac dont les applis n'ont pas supporté le passage à Intel. Et si ton programme est compilé aujourd'hui en 32 bits, peut-être que demain c'est une version 64 bits qui relira les données. Les programmes ont la peau dure, quand leur programmeur est bon...

Carl

Salut, je sais que ton conseil est bon mais ces fameux fichiers que j'écris sont des wavetables (tu dois en savoir un peu sur le sujet, j'ai cru comprendre que tu t'intéressais à la mao). Ce ne sont pas des fichiers utilisateurs, dans le sens où c'est moi même qui les crées et qui les fournis avec mon appli. Si je dois distribuer mon appli sous mac, je recréerai ces wavetables qui seront distribuées en même temps que l'appli mac.

J'ai regardé par curiosité ( et puis pour visualiser avec gnuplot aussi ) la taille d'une wavetable en fichier texte encodée 96Khz, format float : 3,37Mo contre 816Ko en données brutes.

Si je dois, entre autres choses, charger plusieurs tables au démarage, les convertir de l'ascii au float, ça se ressent.

De plus, il s'agit d'un projet perso, avec pour but l'apprentissage de techniques audio.

Effectivement, si ton format de sample est fixé par une norme, cela te facilite le travail. En attendant, si on prend en compte les différences PPC/Intel et 32/64 bits, tu devras quand même générer 3 ensemble de fichiers différents, ce qui est une vraie plaie. Chez Ableton, nous compilons notre produit pour 3 cibles différentes, et que en 32 bits, et ce ne sont pas les problèmes qui manquent.

Le cas idéal, c'est celui des fichiers générés par l'appli elle-même et destinés à usage interne, comme des fichiers de cache par exemple. Dans tout autre cas, je passerai quand même un peu de temps à réfléchir aux problèmes potentiels, surtout que les solutions sont peu coûteuses à mettre en oeuvre.

Cheers,

Carl

Oh tu es chez Ableton, ce doit être passionnant. 8-)

Je confirme, c'est de la bombe!

Et le plus fascinant dans cette entreprise, c'est que l'équipe de dev est la plus âgée de la boîte! J'y suis le plus jeune (27 ans), et plusieurs pourraient être mon père! Des vieux routiers que plus rien n'étonne ; génial!

Mais on s'écarte du sujet...

Pour revenir au sujet d'origine, tout est stocké contiguement, un "bête tableau".