[C++] hex uitlezen wave-file voor lengte *

[sjongenelen]

taal: visual cpp .net
programma: visual studio 2005

Ik ben op zoek naar iemand die me kan vertellen hoe ik een (willekeurig) WAVE bestand kan uitlezen. Hierna wil ik naar de Hex header chunk kijken hoe lang (lees: de totale afspeelduur) de wave-file exact is. (want volgens mij kan dit niet op een andere manier, ofwel?)

ik heb het geprobeerd met:

fopen (is verouderd)
FileStream (lukt me niet )

ik weet gewoon niet welke weg ik moet kiezen !

wat dus globaal de bedoeling is:

open de wave file
maak een array[4]
lees de headers uit.
bereken met de informatie v/d headers de benodigde zaken.

vervolgens wil ik een trackbar maken die bijhoudt hoe ver het geluidsbestand is met afspelen, maar dat is bijzaak

[ Voor 3% gewijzigd door sjongenelen op 17-12-2007 12:53 ]

[.oisyn]

Als je nou even laat zien wat je dan geprobeerd hebt dan kunnen wij ook makkelijker helpen

[sjongenelen]

.oisyn schreef op maandag 17 december 2007 @ 12:57:
Als je nou even laat zien wat je dan geprobeerd hebt dan kunnen wij ook makkelijker helpen

nou, voornamelijk deze bron:
http://www.gamedev.net/co...Title=Loading+a+Wave+File

en verder heb ik het vermeld, ik weet alleen niet precies wat ik moet doen

[.oisyn]

Ik bedoel meer: wat is je code, en waarom gaat het volgens jou niet goed. Ik snap eigenlijk ook niet waarom je zegt dat fopen() verouderd is, afgezien van het feit dat het een C functie is en dat std::fstream de C++ variant ervan is.

[sjongenelen]

C++:

FileStream ^ fp = gcnew FileStream("C:/Windows/Media/tada.wav",FileMode::Open);

hierna heb ik nog geen code, want ik kom er niet verder, wel weet ik al wat ik wil doen:

C++:

BYTE id[4];
fread(id, sizeof(BYTE), 4, fp); //lees 4 naar array id 
if  ( !strcmp(id, "RIFF")) //stringcompare
{

// doe je ding
}

edit: volgens MSDN is het ( fopen) verouderd en brengt veiligheidsrisico's met zich mee, het maakt mij niet of ik het moet gebruiken hoor, veiligheid is zeker geen issue

[ Voor 19% gewijzigd door sjongenelen op 17-12-2007 13:12 ]

[Woy]

Wat lukt er niet met de FileStream? Het is toch aardig duidelijk gedocumenteerd in de MSDN.

http://msdn2.microsoft.co...system.io.filestream.aspx

[voodooless]

Misschien moet je eens kijken wat strcmp terug geeft?

Returns an integral value indicating the relationship between the strings:
A zero value indicates that both strings are equal.
A value greater than zero indicates that the first character that does not match has a greater value in str1 than in str2; And a value less than zero indicates the opposite.

[ Voor 76% gewijzigd door voodooless op 17-12-2007 14:18 ]

[.oisyn]

TheNymf schreef op maandag 17 december 2007 @ 13:10:

C++:

FileStream ^ fp = gcnew FileStream("C:/Windows/Media/tada.wav",FileMode::Open);

Je weet dat dat C++/CLI is (de .Net variant van C++ dus) en niet gewoon normaal C++? Tenzij dat is wat je wilt, zou ik óf voor std::fstream gaan, óf gewoon de warnigs over fopen() negeren

[.oisyn]

voodooless schreef op maandag 17 december 2007 @ 14:18:
Misschien moet je eens kijken wat strcmp terug geeft?

Misschien moet je zelf even beter kijken, want wat hij daar doet klopt gewoon?

[sjongenelen]

.oisyn schreef op maandag 17 december 2007 @ 14:21:
[...]

Misschien moet je zelf even beter kijken, want wat hij daar doet klopt gewoon?

het probleem zit m ook niet in dat gedeelte, maar in filestream

[The End]

.oisyn schreef op maandag 17 december 2007 @ 14:20:
[...]

Je weet dat dat C++/CLI is (de .Net variant van C++ dus) en niet gewoon normaal C++? Tenzij dat is wat je wilt, zou ik óf voor std::fstream gaan, óf gewoon de warnigs over fopen() negeren

Het lijkt me dat hij op Windows programmeert. Ik zou dan voor CreateFile gaan.

Er staat overgens duidelijk in de documentatie bij fopen dat je fopen_s moet gebruiken ipv fopen. Heel veel van deze standaard functies hebben een _s variant gekregen om buffer overflow issues op te lossen.

[WoeiWoei]

Ik ben nog nieuw met cpp maar ik lees hex waardes uit , door het bestand byte voor byte uit te lezen.
dit doe ik op de volgende manier :

Dit is niet voor een wave bestand , maar voor een eigen toepassing en is geschreven als een visual C++ applicatie. Maar ik gok dat je er wel wat mee kan.

C++:

short int i = 0;
char value[4];

BinaryReader^ bReader = gcnew BinaryReader(File::OpenRead("./bestand.txt"), System::Text::Encoding::ASCII);

for(i = 0; i < 4; i++)
{
    value[i] = bReader->ReadByte();
}

let wel op dat je voor 16 en 32 bit waarden rekening moeten houden met little endian en big endian (zie wikipedia als je niet weet wat het is).

[voodooless]

.oisyn schreef op maandag 17 december 2007 @ 14:21:
Misschien moet je zelf even beter kijken, want wat hij daar doet klopt gewoon?

Inderdaad, ik had het uitroepteken gemist

TheNymf schreef op maandag 17 december 2007 @ 14:28:
het probleem zit m ook niet in dat gedeelte, maar in filestream

Hoe weet je dat? Je zegt dat het mis gaat? Wat gaat er dan mis? Heb je een foutmelding, gaat ie plat? Wat doet het in debugger?

[.oisyn]

The End schreef op maandag 17 december 2007 @ 14:34:
[...]

Het lijkt me dat hij op Windows programmeert. Ik zou dan voor CreateFile gaan.

Waarom precies?

Er staat overgens duidelijk in de documentatie bij fopen dat je fopen_s moet gebruiken ipv fopen. Heel veel van deze standaard functies hebben een _s variant gekregen om buffer overflow issues op te lossen.

Leuk dat MS dat besloten heeft, maar fopen() is gewoon een standaard functie, en door fopen_s te gebruiken negeer je de standaard. Maar zoals ik al zei, het is gewoon C++, dus std::fstream. Is gewoon veilig.

[sjongenelen]

oké ik was dus niet helemaal duidelijk; ik weet niet precies wat ik moet doen..!

ik wil een wav file openen en kijk naar de header-chunks, zodat ik daarmee een formule kan maken om de bitrate, frequenties, grootte etc. op te vragen. Dit wil ik zelf maken, omdat ik dus niets tegenkwam (van de DirectSound lib bijvoorbeeld) om het automatisch te doen

ik weet alleen niet hoe ik het moet programmeren, wat ik hierboven allemaal heb neergezet is wat ik tegengekomen ben op internet - ik heb geen idee of het kan doen wat ik wil

beter?

[voodooless]

Ehm... ik vrees van niet Je vertelt namelijk nog steeds niet waarom het niet werk, of je foutmelding krijgt, of wat de debugger je allemaal te vertellen had.

[Creepy]

Zie ook Programming Beleid - De Quickstart voor een soort van checklist voor een topicstart

Ik heb ook je topictitel even aangepast even er vanuitgaand dat het om C++ gaat.

[The End]

.oisyn schreef op maandag 17 december 2007 @ 15:29:
Waarom precies?

Omdat je daar bijvoorbeeld veel beter de toegang mee kan regelen.

Leuk dat MS dat besloten heeft, maar fopen() is gewoon een standaard functie, en door fopen_s te gebruiken negeer je de standaard. Maar zoals ik al zei, het is gewoon C++, dus std::fstream. Is gewoon veilig.

Het zou toch maar dat je de 'standaard' negeert... (Bijna?) alle niet _s functies worden als depricated aangemerkt in de nieuwe SDKs van MS. Deze _s functies roepen gewoon hun oude broertje aan, maar doen daarbij ook bufferchecks. Handig voor slordige programmeurs.

[matthijsln]

The End schreef op maandag 17 december 2007 @ 16:44:
Omdat je daar bijvoorbeeld veel beter de toegang mee kan regelen.

Lijkt me niet dat het in dit geval boeit, hij wil gewoon de inhoud van het bestand lezen en niet exclusive geopend hebben ofzo. fopen() voldoet prima en is nog een standaard ook! Er is namelijk geen enkele reden dat je een programma dat een bestand leest platform-afhankelijk zou moeten maken.

Het zou toch maar dat je de 'standaard' negeert... (Bijna?) alle niet _s functies worden als depricated aangemerkt in de nieuwe SDKs van MS. Deze _s functies roepen gewoon hun oude broertje aan, maar doen daarbij ook bufferchecks. Handig voor slordige programmeurs.

Ik vraag me af wie deze _s functies gebruikt. Doet MS dat zelf wel? Ik zou er eerder voor kiezen om een andere libc library te linken of compiler-flags te gebruiken wanneer je buffer-overflow checking wilt. Die oplossingen zijn volgens mij veel beter dan platform/libc-implementatie afhankelijke functies met vage suffixes te gebruiken.

[matthijsln]

TheNymf schreef op maandag 17 december 2007 @ 13:10:

C++:

FileStream ^ fp = gcnew FileStream("C:/Windows/Media/tada.wav",FileMode::Open);

hierna heb ik nog geen code, want ik kom er niet verder, wel weet ik al wat ik wil doen:

C++:

BYTE id[4];
fread(id, sizeof(BYTE), 4, fp); //lees 4 naar array id 
if  ( !strcmp(id, "RIFF")) //stringcompare
{

// doe je ding
}

Is het probleem nou met het "doe je ding" stukje of het openen en lezen van bestanden? Dat laatste is toch redelijk basic, misschien moet je eerst daarover een tutorial volgen -- nog zonder specifiek met WAV-bestanden aan de slag te gaan?

[ Voor 12% gewijzigd door matthijsln op 17-12-2007 17:16 ]

[The End]

matthijsln schreef op maandag 17 december 2007 @ 17:08:
Lijkt me niet dat het in dit geval boeit, hij wil gewoon de inhoud van het bestand lezen en niet exclusive geopend hebben ofzo. fopen() voldoet prima en is nog een standaard ook! Er is namelijk geen enkele reden dat je een programma dat een bestand leest platform-afhankelijk zou moeten maken.

fopen is nou eenmaal niet toereikend op Windows. Als je files gaat inlezen om informatie in te winnen, dan is het bijvoorbeeld handig als die files niet locked. (Bijvoorbeeld als je de mp3tjes als in een player hebt geladen. (Ik geloof ook dat fopen in Windows CreateFile aanroept.) En waarom zou het platform onafhankelijk moeten zijn? Als dat niet je doel is, dan zou ik er ook geen rekening mee houden.

Ik vraag me af wie deze _s functies gebruikt. Doet MS dat zelf wel? Ik zou er eerder voor kiezen om een andere libc library te linken of compiler-flags te gebruiken wanneer je buffer-overflow checking wilt. Die oplossingen zijn volgens mij veel beter dan platform/libc-implementatie afhankelijke functies met vage suffixes te gebruiken.

MS gebruikt ze zelf ook idd en zoals als ik zei zijn ze 'depricated' in de nieuwe SDKs en krijg je standaard een compiler warning als je ze gebruikt. Het is overgens een hele simpele check. Je moet gewoon bij al die functies opgeven hoe lang de buffer is die je er in stopt.

[matthijsln]

The End schreef op maandag 17 december 2007 @ 17:17:
[...]
fopen is nou eenmaal niet toereikend op Windows. Als je files gaat inlezen om informatie in te winnen, dan is het bijvoorbeeld handig als die files niet locked. (Bijvoorbeeld als je de mp3tjes als in een player hebt geladen. (Ik geloof ook dat fopen in Windows CreateFile aanroept.) En waarom zou het platform onafhankelijk moeten zijn? Als dat niet je doel is, dan zou ik er ook geen rekening mee houden.
[...]
MS gebruikt ze zelf ook idd en zoals als ik zei zijn ze 'depricated' in de nieuwe SDKs en krijg je standaard een compiler warning als je ze gebruikt. Het is overgens een hele simpele check. Je moet gewoon bij al die functies opgeven hoe lang de buffer is die je er in stopt.

Ik denk dat 't neerkomt op of je bezig bent met C++ programmeren of Windows-programmeren. Ik kies - indien geen Windows-specifieke features vereist zijn - voor het eerste.

[roy-t]

.oisyn schreef op maandag 17 december 2007 @ 15:29:
[...]

Waarom precies?


[...]

Leuk dat MS dat besloten heeft, maar fopen() is gewoon een standaard functie, en door fopen_s te gebruiken negeer je de standaard. Maar zoals ik al zei, het is gewoon C++, dus std::fstream. Is gewoon veilig.

Als _s wel veilig is tegen bufferoverflows, waarom dan zo hardnekkig vasthouden aan "de standaard" het is niet dat de functie gecompiled en alles niet meer zal werken. Ook zal je niet snel van code editor veranderen, en zelfs dan als je dezelfde compiler gebruikt is er niks aan de hand.

[sjongenelen]

dit dus:

C++:

 FileStream ^ fs = gcnew FileStream("C:/Windows/Media/Chimes.wav",FileMode::Open); 


 int nBytes = 4;
   array<Byte>^ByteArray = gcnew array<Byte>(nBytes);
   int nBytesRead = fs->Read( ByteArray, 0, nBytes );
   int i;
    for (i=0;i<4;i++)
   Console::WriteLine((Char)ByteArray[i]);

bedankt voor de inzet allemaal, ik snapte het hele idee erachter niet, nu wel ^^

p.s. het was Windows only

[ Voor 16% gewijzigd door sjongenelen op 17-12-2007 18:13 ]

[matthijsln]

therat10430 schreef op maandag 17 december 2007 @ 17:42:
[...]
Als _s wel veilig is tegen bufferoverflows, waarom dan zo hardnekkig vasthouden aan "de standaard" het is niet dat de functie gecompiled en alles niet meer zal werken. Ook zal je niet snel van code editor veranderen, en zelfs dan als je dezelfde compiler gebruikt is er niks aan de hand.

Als je fopen_s() gebruikt betekent dit niet dat er daarvoor geen buffer overflow heeft plaatsgevonden (door gebruik van bv onveilige strcpy() voor de filename). Volgens http://msdn2.microsoft.co...rary/8ef0s5kh(VS.80).aspx worden buffer overflows alleen voorkomen bij functies die naar een buffer schrijven doordat je de lengte van de buffer moet opgeven. fopen_s() checkt dus helemaal niet meer tegen buffer overflow dan fopen() (of std::fstream()) alleen zou doen.

[ Voor 7% gewijzigd door matthijsln op 17-12-2007 18:14 ]

[Verwijderd]

TheNymf schreef op maandag 17 december 2007 @ 13:10:

C++:

FileStream ^ fp = gcnew FileStream("C:/Windows/Media/tada.wav",FileMode::Open);

hierna heb ik nog geen code, want ik kom er niet verder, wel weet ik al wat ik wil doen:

C++:

BYTE id[4];
fread(id, sizeof(BYTE), 4, fp); //lees 4 naar array id 
if  ( !strcmp(id, "RIFF")) //stringcompare
{

// doe je ding
}

edit: volgens MSDN is het ( fopen) verouderd en brengt veiligheidsrisico's met zich mee, het maakt mij niet of ik het moet gebruiken hoor, veiligheid is zeker geen issue

Leuk deze code, maar je bent nu de string "RIFF" aan het vergelijken met een byte-array van lente 4, terwijl de strcmp functie 0-terminated strings vergelijkt. Je hebt dus heel waarschijnlijk te maken met een buffer overflow. Dit is direct de reden waarom de code met for(i=0 tot 4) wel werkt, want dan is de lengte van 4 hardcoded.
Edit:
Ik denk dus dat dit wel werkt:

C++:

BYTE id[5];
fread(id, sizeof(BYTE), 4, fp); //lees 4 naar array id 
id[4] = '\0';
if  ( !strcmp(id, "RIFF")) //stringcompare
{

// doe je ding
}

[ Voor 9% gewijzigd door Verwijderd op 18-12-2007 00:35 ]

[The End]

matthijsln schreef op maandag 17 december 2007 @ 18:12:
Als je fopen_s() gebruikt betekent dit niet dat er daarvoor geen buffer overflow heeft plaatsgevonden (door gebruik van bv onveilige strcpy() voor de filename). Volgens http://msdn2.microsoft.co...rary/8ef0s5kh(VS.80).aspx worden buffer overflows alleen voorkomen bij functies die naar een buffer schrijven doordat je de lengte van de buffer moet opgeven. fopen_s() checkt dus helemaal niet meer tegen buffer overflow dan fopen() (of std::fstream()) alleen zou doen.

Daarvoor gebruik je dan ook strcpy_s

Door de _s functies te gebruiken voorkom je niet meteen alle mogelijke buffer problemen, maar het helpt wel om mensen te dwingen op een bepaalde manier te programmeren. Microsoft geeft ook aan dat de originele functies niet echt 'depricated' zijn, maar dat het een advies is om de _s functies te gebruiken.

[Olaf van der Spek]

.oisyn schreef op maandag 17 december 2007 @ 14:21:
[...]

Misschien moet je zelf even beter kijken, want wat hij daar doet klopt gewoon?

Is dat zo? Volgens mij is id niet null-terminated...

Verwijderd schreef op dinsdag 18 december 2007 @ 00:33:
Leuk deze code, maar je bent nu de string "RIFF" aan het vergelijken met een byte-array van lente 4, terwijl de strcmp functie 0-terminated strings vergelijkt. Je hebt dus heel waarschijnlijk te maken met een buffer overflow.

Klinkt meer als een buffer underblow. Veel minder erg.
Waarom gebruik je geen memcmp?

The End schreef op dinsdag 18 december 2007 @ 10:51:
Door de _s functies te gebruiken voorkom je niet meteen alle mogelijke buffer problemen, maar het helpt wel om mensen te dwingen op een bepaalde manier te programmeren. Microsoft geeft ook aan dat de originele functies niet echt 'depricated' zijn, maar dat het een advies is om de _s functies te gebruiken.

Leuk advies, maar zijn de _s varianten ook op andere platformen beschikbaar?
En waarom strcpy in plaats van std::string?

[ Voor 73% gewijzigd door Olaf van der Spek op 18-12-2007 11:18 ]

[.oisyn]

Een hoop mensen hier schijnen te denken dat de secure CRT functies een soort sinecure zijn tegen buffer overflows. Dat is niet zo. Wat de *_s functies doen is simpelweg gewoon checken of de buffer waar je naar schrijft wel groot genoeg is. Zo niet, dan roept hij een error handler aan, en de default error handler terminate je applicatie middels een access violation. Het is symptoombestreiding, handig voor tijdens debug builds, maar in release builds heb je er echt geen zak aan. Als je écht veilig wil programmeren (in C), dan gebruik je bijvoorbeeld strncpy om maximaal n chars te kopiëren, ipv strcpy_s die gewoon controleert of je buffer wel groot genoeg is, en zo niet en je error handler terminate niet, dan gewoon helemaal niets doet.

En in C++ gebruik je sowieso std::string zodat je er al helemaal geen last van hebt.

[ Voor 5% gewijzigd door .oisyn op 18-12-2007 11:21 ]

[.oisyn]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 11:10:
[...]

Is dat zo? Volgens mij is id niet null-terminated...

Idd, de buffer van lengte 4 had ik even gemist.

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 11:10:
Leuk advies, maar zijn de _s varianten ook op andere platformen beschikbaar?
En waarom strcpy in plaats van std::string?

Hij gaat alleen op Windows programmeren volgens mij? Als ik alleen op Windows programmeer, dan hoef ik niet moeilijk te gaan doen om platform onafhankelijk te gaan programmeren.

@.oisyn,
Ik schrijf net dat het niet een heilige graal is... Daarbij is het een stuk beter om bij een bug altijd(!)een access violation te krijgen, dan dat je op willekeurige momenten rare crashes krijgt.

[ Voor 4% gewijzigd door The End op 18-12-2007 11:47 ]

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 11:46:
Hij gaat alleen op Windows programmeren volgens mij? Als ik alleen op Windows programmeer, dan hoef ik niet moeilijk te gaan doen om platform onafhankelijk te gaan programmeren.

Nee, maar als je twee manieren hebt die met dezelfde complexiteit en een is platform onafhankelijk en de ander niet is het wel handig voor de eerste te kiezen.

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 11:58:
Nee, maar als je twee manieren hebt die met dezelfde complexiteit en een is platform onafhankelijk en de ander niet is het wel handig voor de eerste te kiezen.

De functies zijn niet hetzelfde en als ik niet bezig ben met platform onafhankelijk programmeren, dan zal het me een worst zijn of de functie platform onafhankelijk is.

Wat heeft het voor zin om platform onafhankelijke functies te kiezen als je programma alleen op Windows gaat draaien en vaak alleen op Windows KAN draaien vanwege vele andere afhankelijkheden?

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 12:03:
De functies zijn niet hetzelfde

In dit geval niet nee.

en als ik niet bezig ben met platform onafhankelijk programmeren, dan zal het me een worst zijn of de functie platform onafhankelijk is.

Wat heeft het voor zin om platform onafhankelijke functies te kiezen als je programma alleen op Windows gaat draaien en vaak alleen op Windows KAN draaien vanwege vele andere afhankelijkheden?

Dat je delen van de code toch op een ander platform kan gebruiken. Het uitlezen van de lengte van een WAV bestand klinkt niet echt als Windows-only.

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 12:09:
Dat je delen van de code toch op een ander platform kan gebruiken. Het uitlezen van de lengte van een WAV bestand klinkt niet echt als Windows-only.

Wel als je CreateFile gebruikt. Nogmaals als je niet als doel hebt om platform onafhankelijk te programmeren, dan heeft het geen enkele zin om daar rekening mee te houden.

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 13:38:
Wel als je CreateFile gebruikt.

Natuurlijk kun je een platform afhankelijke implementatie schrijven. Maar dat maakt het oorspronkelijke probleem toch niet platform afhankelijk?
Wat is het voordeel van CreateFile in plaats van fopen?

[ Voor 26% gewijzigd door Olaf van der Spek op 18-12-2007 13:45 ]

[CyBeR]

therat10430 schreef op maandag 17 december 2007 @ 17:42:
[...]


Als _s wel veilig is tegen bufferoverflows, waarom dan zo hardnekkig vasthouden aan "de standaard" het is niet dat de functie gecompiled en alles niet meer zal werken. Ook zal je niet snel van code editor veranderen, en zelfs dan als je dezelfde compiler gebruikt is er niks aan de hand.

Wel's van portable code gehoord?

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 13:45:
Natuurlijk kun je een platform afhankelijke implementatie schrijven. Maar dat maakt het oorspronkelijke probleem toch niet platform afhankelijk?
Wat is het voordeel van CreateFile in plaats van fopen?

Dat staat hierboven al. CreateFile is de functie waarmee je files creeert en opent op het Windows platform. De mogelijkheden van CreateFile zijn dan ook veel uitgebreider.

Een belangrijke mogelijkheid van CreateFile is bijvoorbeeld dat je nauwkeurig de rechten kan regelen die je nodig hebt. Er zijn echter nog veel meer mogelijkheden waar je geen gebruik van kan maken als je fopen gebruikt. (Die voor zover ik weet ook CreateFile aanroept)

CyBeR schreef op dinsdag 18 december 2007 @ 13:50:
Wel's van portable code gehoord?

Wel eens van niet portable code gehoord?

[ Voor 10% gewijzigd door The End op 18-12-2007 13:54 ]

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 13:54:
Dat staat hierboven al. CreateFile is de functie waarmee je files creeert en opent op het Windows platform. De mogelijkheden van CreateFile zijn dan ook veel uitgebreider.

Een belangrijke mogelijkheid van CreateFile is bijvoorbeeld dat je nauwkeurig de rechten kan regelen die je nodig hebt. Er zijn echter nog veel meer mogelijkheden waar je geen gebruik van kan maken als je fopen gebruikt. (Die voor zover ik weet ook CreateFile aanroept)

Welke extra mogelijkheden heeft de topic starter (absoluut) nodig?

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 13:57:
Welke extra mogelijkheden heeft de topic starter (absoluut) nodig?

-Zo weinig mogelijk rechten 'nemen'. (Vergroot de kans dat de operatie succesvol is)
-FILE_SHARE_READ (Kan je de file ondertussen afspelen)

Daarnaast zou ik gewoon altijd aanraden om deze functie te gebruiken als je alleen voor Windows programmeert. Vooral het 'zo weinig mogelijk rechten eisen' verhaal voorkomt veel problemen. (Een van de redenen dat veel pre Windows Vista programma's niet goed op Vista draaien komt omdat ze te veel rechten eisen, terwijl ze die in veel gevallen helemaal niet nodig hebben)

[CyBeR]

The End schreef op dinsdag 18 december 2007 @ 13:54:
[...]

Wel eens van niet portable code gehoord?

Lijkt me een bijzonder slechte gewoonte om aan te nemen als beginner.

[The End]

CyBeR schreef op dinsdag 18 december 2007 @ 14:24:
Lijkt me een bijzonder slechte gewoonte om aan te nemen als beginner.

Waarom? Het maakt niks uit waar je op programmeert als beginner. Als je later iets serieus moet doen, dan ontkom je er niet/nauwlijks aan om platform afhankelijke code te schrijven.

Daarnaast zul je bij elk programma moeten bedenken voor welke platformen je het wilt schrijven. Ook de Windows specifieke calls zijn niet beschikbaar op alle Windows OSen.

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 14:08:
-Zo weinig mogelijk rechten 'nemen'. (Vergroot de kans dat de operatie succesvol is)
-FILE_SHARE_READ (Kan je de file ondertussen afspelen)

Dat werkt met fopen("", "rb"); ook.

Daarnaast zou ik gewoon altijd aanraden om deze functie te gebruiken als je alleen voor Windows programmeert. Vooral het 'zo weinig mogelijk rechten eisen' verhaal voorkomt veel problemen. (Een van de redenen dat veel pre Windows Vista programma's niet goed op Vista draaien komt omdat ze te veel rechten eisen, terwijl ze die in veel gevallen helemaal niet nodig hebben)

Onzin. Een bestand read-only openenen kan net zo goed met fopen. En schrijven in Program Files gaat net zo goed fout met CreateFile. Dat doen veel apps fout.

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 14:48:
Dat werkt met fopen("", "rb"); ook.

O, met welke rechten wordt een bestand dan geopend? FILE_SHARE_READ is overgens niet een standaard access right, maar een share mode. Hoe weet ik met fopen welke die kiest? Moet ik dat testen op elk OS?

Onzin. Een bestand read-only openenen kan net zo goed met fopen. En schrijven in Program Files gaat net zo goed fout met CreateFile. Dat doen veel apps fout.

Niet onzin. Ik heb het niet alleen over CreateFile. Je moet als je programmeert bij alle resources zo min mogelijk rechten eisen. Niet alleen bij het openen van files.

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 14:52:
O, met welke rechten wordt een bestand dan geopend? FILE_SHARE_READ is overgens niet een standaard access right, maar een share mode. Hoe weet ik met fopen welke die kiest?

Geen idee, maar daar is vast goed over nagedacht.

Moet ik dat testen op elk OS?

Als jij daar zin in hebt.
Vind je voor elk OS specifieke code schrijven eenvoudiger?

Niet onzin. Ik heb het niet alleen over CreateFile. Je moet als je programmeert bij alle resources zo min mogelijk rechten eisen. Niet alleen bij het openen van files.

Tot nu toe heb je nog niet laten zien dat fopen niet bruikbaar is.

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 14:55:
Geen idee, maar daar is vast goed over nagedacht.

Vast wel, maar je weet het niet en je kan het niet regelen.

Als jij daar zin in hebt.
Vind je voor elk OS specifieke code schrijven eenvoudiger?

Ik schrijf niet voor elk OS specifieke code. Ik schrijf code die het doet op de OSen die ik wil ondersteunen.

Tot nu toe heb je nog niet laten zien dat fopen niet bruikbaar is.

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 14:57:
Vast wel, maar je weet het niet en je kan het niet regelen.

Ik weet dat het goed werkt. Wat zou ik nog meer willen weten?

Ik schrijf niet voor elk OS specifieke code. Ik schrijf code die het doet op de OSen die ik wil ondersteunen.

Wat toevallig, ik ook.
En als bonus werkt het ook nog op OSen die ik niet direct ondersteun.

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 15:00:
Ik weet dat het goed werkt. Wat zou ik nog meer willen weten?

Je vermoed dat het goed werkt. Dat is wat anders. Ik kan je vertellen dat zo'n aanname heel risicovol kan zijn...

Wat toevallig, ik ook.
En als bonus werkt het ook nog op OSen die ik niet direct ondersteun.

De software die ik schrijf is niet platform onafhankelijk en kan dat ook heel moeilijk (of niet) gemaakt worden. Daarnaast heb ik er niets aan dat mijn software het eventueel wel zou doen op OSen die ik niet ondersteun. Dat levert alleen maar extra problemen op.

[sam.vimes]

.oisyn schreef op dinsdag 18 december 2007 @ 11:21:
Een hoop mensen hier schijnen te denken dat de secure CRT functies een soort sinecure zijn tegen buffer overflows. Dat is niet zo. Wat de *_s functies doen is simpelweg gewoon checken of de buffer waar je naar schrijft wel groot genoeg is.
(knip)

Hier komt nog bij, dat fopen_s() helemaal niet naar een buffer schrijft: beide argumenten zijn const char*. De enige controle die fopen_s() uitvoert, is of de actuele parameters geen NULL zijn (zie http://msdn2.microsoft.co...rary/z5hh6ee9(VS.80).aspx) en als je het zo ver hebt laten komen, is er al iets zwaar mis volgens mij. Geldt ook voor de meeste van de andere _s-functies: voor een gedisciplineerde programmeur voegen ze niets toe en veroorzaken ze hooguit performanceverlies.

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 15:12:
Je vermoed dat het goed werkt. Dat is wat anders. Ik kan je vertellen dat zo'n aanname heel risicovol kan zijn...

Ja, een formeel bewijs dat het goed werkt heb ik inderdaad niet nee. Maar geef nou eens eens concreet geval waarin deze aanname inderdaad fout gaat?

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 15:37:
Ja, een formeel bewijs dat het goed werkt heb ik inderdaad niet nee. Maar geef nou eens eens concreet geval waarin deze aanname inderdaad fout gaat?

Ondersteund fopen bijvoorbeeld lange padnamen? (tot ~32000 characters bijvoorbeeld?) fopen is iig niet UNICODE; daarvoor moet je _wfopen gebruiken. (Of is die ook platform onafhankelijk?)

Er kan niet gegarandeerd worden dat fopen precies hetzelfde doet op Windows 2000 en bijvoorbeeld Windows 2003.

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 15:52:
Ondersteund fopen bijvoorbeeld lange padnamen? (tot ~32000 characters bijvoorbeeld?)

Dat weet ik niet. Ik zie geen reden waarom fopen het niet zou kunnen ondersteunen en als die het niet doet is dat een keuze geweest van MS.

fopen is iig niet UNICODE; daarvoor moet je _wfopen gebruiken. (Of is die ook platform onafhankelijk?)

UTF-8 past prima in een char string, UTF-16/32 inderdaad niet.

Er kan niet gegarandeerd worden dat fopen precies hetzelfde doet op Windows 2000 en bijvoorbeeld Windows 2003.

Waarom zou dat niet gegarandeerd kunnen worden?
Voor CreateFile geldt natuurlijk hetzelfde.

[The End]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 17:06:
Dat weet ik niet. Ik zie geen reden waarom fopen het niet zou kunnen ondersteunen en als die het niet doet is dat een keuze geweest van MS.

De ansi versie van CreateFile ondersteunt ook geen lange padnamen. Echter weet je het niet. Het staat niet in de documentatie. Dat betekent dat je het op alle systemen moet testen om het zeker te weten.

UTF-8 past prima in een char string, UTF-16/32 inderdaad niet.

Werkt het dan wel of niet in China?

Waarom zou dat niet gegarandeerd kunnen worden?
Voor CreateFile geldt natuurlijk hetzelfde.

Nee, voor CreateFile staat er duidelijk of het ondersteund is op Windows 2000/2003. Er staat ook duidelijk bij als een of andere switch het niet doet op een bepaald platform. Bij fopen staat dat niet; sterker nog, je weet niet eens welke switches hij gebruikt.

Ik snap het niet; je wilde concrete voorbeelden, dan geef ik die en dan ga je er omheen zitten lullen.

[voodooless]

The End schreef op dinsdag 18 december 2007 @ 17:18:
De ansi versie van CreateFile ondersteunt ook geen lange padnamen. Echter weet je het niet. Het staat niet in de documentatie. Dat betekent dat je het op alle systemen moet testen om het zeker te weten.

fopen heeft als path beperking PATH_MAX of NAME_MAX. En deze zijn, je raad het al.. platformafhankelijk. Dus niks testen, gewoon opvragen

Werkt het dan wel of niet in China?

UTF8 werkt overal waar Unicode ook werkt, dus ook in China.

[Olaf van der Spek]

The End schreef op dinsdag 18 december 2007 @ 17:18:
Nee, voor CreateFile staat er duidelijk of het ondersteund is op Windows 2000/2003. Er staat ook duidelijk bij als een of andere switch het niet doet op een bepaald platform. Bij fopen staat dat niet; sterker nog, je weet niet eens welke switches hij gebruikt.

Er staan inderdaad geen details over de implementatie van fopen nee. Maar die details heb je ook niet (vaak) nodig. Overigens zijn er ook standaard C functies om de sharing mode aan te geven.

Ik snap het niet; je wilde concrete voorbeelden, dan geef ik die en dan ga je er omheen zitten lullen.

Waar lul ik omheen? Doel je op de maximum lengte?

[ Voor 5% gewijzigd door Olaf van der Spek op 18-12-2007 17:40 ]

[Verwijderd]

Olaf van der Spek schreef op dinsdag 18 december 2007 @ 17:39:
Er staan inderdaad geen details over de implementatie van fopen nee. Maar die details heb je ook niet (vaak) nodig. Overigens zijn er ook standaard C functies om de sharing mode aan te geven.

Nee, maar de details kun je natuurlijk even opzoeken in de Microsoft's implementatie van fopen...

[Verwijderd]

voodooless schreef op dinsdag 18 december 2007 @ 17:26:
[...]


fopen heeft als path beperking PATH_MAX of NAME_MAX. En deze zijn, je raad het al.. platformafhankelijk. Dus niks testen, gewoon opvragen


[...]

UTF8 werkt overal waar Unicode ook werkt, dus ook in China.

De Windows APIs accepteren geen UTF-8, dus als je alles in UTF-8 wil doen, moet je dus wel de file open dingen wrappen om meerdere platforms te ondersteunen.

[Olaf van der Spek]

Verwijderd schreef op dinsdag 18 december 2007 @ 17:58:
[...]


De Windows APIs accepteren geen UTF-8, dus als je alles in UTF-8 wil doen, moet je dus wel de file open dingen wrappen om meerdere platforms te ondersteunen.

MS is inderdaad weer heerlijk eigenwijs.

[barber]

Om de TS maar weer even op weg te helpen: De windows multimedia API bevat al een hele zooi functies en structures om met wave files om te gaan.

Een voorbeeld van wat je wilt staat hier:
http://blogs.msdn.com/larryosterman/archive/2007/01/10/how-long-is-a-wav-file.aspx

Let op! De tijdsduur wordt op deze manier bepaald door de lengte van de data te delen door de gemiddelde bitrate (staat in de header). Deze code gaat uit van het PCM format, meest voorkomende formaat voor .wav bestanden, maar ook het simpelste omdat deze een vaste bitrate heeft. Indien er een andere codec wordt gebruikt (compressie) dan kan dit een variabele bitrate hebben en doordat de header een gemiddelde bitrate heeft levert dit dus een afwijking op.

[The End]

voodooless schreef op dinsdag 18 december 2007 @ 17:26:
fopen heeft als path beperking PATH_MAX of NAME_MAX. En deze zijn, je raad het al.. platformafhankelijk. Dus niks testen, gewoon opvragen

Ik kom PATH_MAX alleen tegen in limits.h en die bestaat alleen als _POSIX_ is gedefinieerd. Dan nog is PATH_MAX 512 en niet ~32000 (En ga nou niet zeggen dat langere paden niet/nauwlijks voorkomen, want ik heb het meegemaakt )

UTF8 werkt overal waar Unicode ook werkt, dus ook in China.

Verwijderd schreef op dinsdag 18 december 2007 @ 17:58:
De Windows APIs accepteren geen UTF-8, dus als je alles in UTF-8 wil doen, moet je dus wel de file open dingen wrappen om meerdere platforms te ondersteunen.

[Olaf van der Spek]

The End schreef op woensdag 19 december 2007 @ 09:31:
Ik kom PATH_MAX alleen tegen in limits.h en die bestaat alleen als _POSIX_ is gedefinieerd. Dan nog is PATH_MAX 512 en niet ~32000 (En ga nou niet zeggen dat langere paden niet/nauwlijks voorkomen, want ik heb het meegemaakt )

Volgens mij is het MAX_PATH:
windef.h: #define MAX_PATH 260

Lange paden klinken leuk, maar zelfs Explorer in Windows XP ondersteund ze niet.

[The End]

Olaf van der Spek schreef op woensdag 19 december 2007 @ 09:54:
[...]

Volgens mij is het MAX_PATH:
windef.h: #define MAX_PATH 260

Lange paden klinken leuk, maar zelfs Explorer in Windows XP ondersteund ze niet.

In Windows is het idd MAX_PATH Voodooless had het volgens mij over de platform onafhankelijke versie. Ik weet niet of MAX_PATH platform onafhankelijk is.

MAX_PATH is de maximale lengte van een relatief pad. Niet van een volledig pad.

Het klopt idd dat de explorer ze b.v. niet ondersteund. Echter komen ze toch nog redelijk veel voor. (Of wat dacht je van extreem lange paden in het chinees... Probeer dan maar eens het probleem te vinden Ik heb er misschien nog ergens wel een screenshot van liggen.)

[ Voor 4% gewijzigd door The End op 19-12-2007 10:10 ]

[Olaf van der Spek]

The End schreef op woensdag 19 december 2007 @ 10:08:
Het klopt idd dat de explorer ze b.v. niet ondersteund. Echter komen ze toch nog redelijk veel voor. (Of wat dacht je van extreem lange paden in het chinees... Probeer dan maar eens het probleem te vinden Ik heb er misschien nog ergens wel een screenshot van liggen.)

Gebruiken de chinezen geen Explorer dan?

[The End]

Olaf van der Spek schreef op woensdag 19 december 2007 @ 10:31:
Gebruiken de chinezen geen Explorer dan?

Er zijn genoeg andere manieren om aan een langer pad te komen hoor:

Gebruikers kunnen bijvoorbeeld toegang hebben tot een share op een pad van 200 characters. Als dan de gebruiker ook weer een pad aanmaakt van 200 characters. (Wat kan, omdat de share + 200 character kleiner is dan MAX_PATH), dan is de totale lengte van het pad 400 characters op de fileserver.

[Olaf van der Spek]

The End schreef op woensdag 19 december 2007 @ 10:37:
Gebruikers kunnen bijvoorbeeld toegang hebben tot een share op een pad van 200 characters. Als dan de gebruiker ook weer een pad aanmaakt van 200 characters. (Wat kan, omdat de share + 200 character kleiner is dan MAX_PATH), dan is de totale lengte van het pad 400 characters op de fileserver.

Uiteraard. Toch lastige dat belangrijke onderdelen van Windows het niet ondersteunen dan.

[The End]

Olaf van der Spek schreef op woensdag 19 december 2007 @ 10:38:
Uiteraard. Toch lastige dat belangrijke onderdelen van Windows het niet ondersteunen dan.

En daarom kan je dus beter CreateFile gebruiken, zodat jou pakket het wel ondersteund...

[Olaf van der Spek]

The End schreef op woensdag 19 december 2007 @ 10:41:
[...]

En daarom kan je dus beter CreateFile gebruiken, zodat jou pakket het wel ondersteund...

De vraag is natuurlijk: waarom ondersteunt fopen geen lange namen?

[voodooless]

Olaf van der Spek schreef op woensdag 19 december 2007 @ 10:59:
De vraag is natuurlijk: waarom ondersteunt fopen geen lange namen?

Omdat MS geen belang heeft aan multiplatform compatibiliteit en dus de ISO standaarden schopt waar ze maar kunnen. Ze hebben gewoon liever dat je hun eigen api's gebruikt.

[The End]

voodooless schreef op woensdag 19 december 2007 @ 11:03:
Omdat MS geen belang heeft aan multiplatform compatibiliteit en dus de ISO standaarden schopt waar ze maar kunnen. Ze hebben gewoon liever dat je hun eigen api's gebruikt.

De ANSI versie van CreateFile ondersteund ook geen lange padnamen. Alleen de Unicode versie. Misschien vanwege performance?

[Olaf van der Spek]

The End schreef op woensdag 19 december 2007 @ 11:31:
De ANSI versie van CreateFile ondersteund ook geen lange padnamen. Alleen de Unicode versie. Misschien vanwege performance?

Performance van CreateFile? Ik kan het me niet voorstellen.
Dan nog, is deze feature niet belangrijker dan performance?

[ Voor 9% gewijzigd door Olaf van der Spek op 19-12-2007 11:54 ]

[voodooless]

Hier staat nog een stukje over CreateFile:

These functions behave differently in ANSI and Unicode. In Unicode, filenames up to 32K long are allowed by attaching "\\?\" or "\\?\UNC\" to the beginning of the filename. In ANSI, this functionality is not supported. Thus, when a pathname exceeds MAX_PATH(260), you should call API for Unicode, even when you are building with an ANSI model.

En ergens anders staat dan nog:

quote: http://www.jorendorff.com/articles/unicode/windows.html

It was mentioned earlier that the NT-based OSes use Unicode throughout the kernel. Since most programs need to run on Windows 95 and 98, most programs still call into the old non-Unicode Windows APIs. The result is that NT has to translate all string arguments from "ANSI" to Unicode UTF-16 whenever a program does anything at all. The "A" version of any function is just a stub that translates the arguments and calls the "W" version to do the real work.

Kwa performance zou dus het direct aanroepen van de unicode versie het snelste moeten zijn

[Verwijderd]

fopen is natuurlijk gewoon een wrapper rondom 'CreateFile'. (net zoals fopen een wrapper is rondom 'open' op posix systemen). fopen wrapped de 'CreateFileA' en _wfopen wrapped de 'CreateFileW' dus inprincipe hebben ze dezelfde limiten als de functies die ze wrappen. CreateFile & fopen vergelijken heeft net zo veel nut als fopen & open te gaan vergelijken. Elk heeft z'n voordelen en nadelen.

[sjongenelen]

oplossing:

C++:

SecondaryBuffer ^ buffer;

//inladen bestand met flags voor buffer.

buffer->Caps.BufferBytes / buffer->Format.AverageBytesPerSecond;

// en dan nog even het aantal header bytes tellen en controleren dat het wel een wav file is en basta!

[TheBorg]

Voorbeeldje header inlezen:

C++:

    struct RIFF
    {   char            ChunkID[4];         // Should be "RIFF"
        unsigned long   ChunkSize;
        char            Format[4];
        char            Subchunk1ID[4];     // Should be "fmt "
        unsigned long   Subchunk1Size;      // 16 bytes for PCM
        short           AudioFormat;        // PCM = 1
        short           NumChannels;
        unsigned long   SampleRate;
        unsigned long   ByteRate;
        unsigned short  BlockAlign;
        unsigned short  BitsPerSample;
        unsigned long   Subchunk2Size;
    } Header;
    
    FILE *source;

    source = fopen("sample.wav", "rb");
    fseek(source, 0, SEEK_SET);
    fread(&Header, sizeof(struct RIFF), 1, source);

[Olaf van der Spek]

TheBorg schreef op dinsdag 08 januari 2008 @ 20:29:
Voorbeeldje header inlezen:

Dat lijkt me geen portable/standaard C++ (variable sizes en struct padding enzo).

[ Voor 9% gewijzigd door Olaf van der Spek op 08-01-2008 21:04 ]

[farlane]

Olaf van der Spek schreef op dinsdag 08 januari 2008 @ 20:58:
[...]

Dat lijkt me geen portable/standaard C++ (variable sizes en struct padding enzo).

Padding ok maar waar zie jij variabele sizes eigenlijk? Volgens mij is dit prima standaard C. ( geen C++ te bekennen trouwens )

Trouwens, ik vraag me af of je de moeite wilt doen om dit soort dingen meteen portable te krijgen, je zit altijd met endianess, merk compiler etc bij dit soort dingen.

[Olaf van der Spek]

farlane schreef op woensdag 09 januari 2008 @ 22:08:
Padding ok maar waar zie jij variabele sizes eigenlijk? Volgens mij is dit prima standaard C. ( geen C++ te bekennen trouwens )

Short kan meer dan 16 bits zijn natuurlijk. Is het meer, dan werkt je struct niet meer.

[farlane]

Olaf van der Spek schreef op woensdag 09 januari 2008 @ 22:29:
[...]

Short kan meer dan 16 bits zijn natuurlijk. Is het meer, dan werkt je struct niet meer.

Mja ok dat bedoel je met variabele sizes; ik dacht dat je variable length arrays oid bedoelde. Magoed, zoals ik al zei heb je dat soort problemen altijd als je spul regelrecht in een struct inleest en ik betwijfel of het zinning is om meteen een constructie te maken die onder elk platform / compiler werkt. Das niet echt simpel te doen.

Neemt niet weg dat het onder iedere moderne C compiler zou moeten compileren, dus standaard C is het wel.

[ Voor 8% gewijzigd door farlane op 09-01-2008 22:45 ]

[Olaf van der Spek]

farlane schreef op woensdag 09 januari 2008 @ 22:44:
Neemt niet weg dat het onder iedere moderne C compiler zou moeten compileren, dus standaard C is het wel.

Ja, dan compiled het wel maar werkt het niet.
Heb je toch even fijne standaard code.

[TheBorg]

Ik moet toegeven dat C++ niet mijn sterkste taal is, dus ik ga niks beweren tegenover mensen die veel meer ervaring en kennis hebben. De snipplet komt uit een programma dat portable zou moeten zijn. Juist met dit doel ben ik gaan leren uit een C++ boek uit 1994 (Leen Ammeraal, C++ 4e druk). Het stukje code is met behulp van dit boek (en niets anders) tot stand gekomen. De Windows file functions die eerder in dit topic zijn genoemd heb ik nog nooit gezien. Ik denk dat het stukje code met iedere C++ compiler te compileren is.

Als dit niet zo is dan heb ik een probeem want ik werk al 3 jaar aan dat progsel en het zou straks ook onder Linux gebruikt moeten kunnen worden.

[Olaf van der Spek]

TheBorg schreef op donderdag 10 januari 2008 @ 00:09:
Ik denk dat het stukje code met iedere C++ compiler te compileren is.

Stel dat (unsigned) long 64 bits is. Wat gebeurd er dan?

[.oisyn]

Zelfs al is een char 8 bits, een short 16 bits en een long 32 bits, dan nog is er geen zinnig woord over te zeggen hoe de struct in het geheugen staat, anders dan dat elke member een hoger adres heeft dan het vorige member, en dat het eerste member vooraan staat zonder padding. Wat cross-platform is aan deze code is dat je een dergelijke struct naar disk kunt schrijven en weer in kunt lezen. Het daadwerkelijke formaat kan echter per platform en zelfs per compiler revisie verschillen.

In de praktijk, echter, zal de code op vrijwel elk gangbaar 32 bits platform naar behoren werken.

Olaf van der Spek schreef op woensdag 09 januari 2008 @ 22:56:
Heb je toch even fijne standaard code.

Standaard C of C++ wil zeggen dat het voldoet aan de standaard. Dat doet deze code. Het zegt niets over layout-compatibility tussen verschillende implementaties, want zo staat het immers in de standaard (sommige essentiele dingen zoals padding zijn nou eenmaal 'unspecified' danwel 'implementation defined').

[ Voor 32% gewijzigd door .oisyn op 10-01-2008 01:29 ]

[TheBorg]

Olaf van der Spek schreef op donderdag 10 januari 2008 @ 00:21:
[...]

Stel dat (unsigned) long 64 bits is. Wat gebeurd er dan?

Ik zie het probleem nu. Te snel door de reacties geskimmed. De voorbeelden op gamedev.net hebben hetzelfde probleem.

Misschien is dit iets:
http://www.devx.com/tips/Tip/14095

.oisyn schreef op donderdag 10 januari 2008 @ 01:23:
Wat cross-platform is aan deze code is dat je een dergelijke struct naar disk kunt schrijven en weer in kunt lezen.

Klopt het dan dat de weggeschreven struct op het ene platform, op een ander platform niet hetzelfde wordt inglezen?

[ Voor 31% gewijzigd door TheBorg op 10-01-2008 01:48 ]

[Olaf van der Spek]

TheBorg schreef op donderdag 10 januari 2008 @ 01:28:
[...]

Ik zie het probleem nu. Te snel door de reacties geskimmed. De voorbeelden op gamedev.net hebben hetzelfde probleem.

Misschien is dit iets:
http://www.devx.com/tips/Tip/14095

Dat is al iets beter, alhoewel je nog steeds met padding zit.

Klopt het dan dat de weggeschreven struct op het ene platform, op een ander platform niet hetzelfde wordt inglezen?

Ja, kan.