Discussion :

[NiamorH]

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 :

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
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() );
}

[Sylvain Togni]

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.

[NiamorH]

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 :

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 ?

[Invité]

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

[NiamorH]

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.

[Invité]

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