Ich möchte gerne ein Bitmap lesen. Mir geht es zunächst um den Header. Die Daten dafür habe ich mir einfach bei wotsit.org geholt, die Struktur ist:

struct BitmapFileHeader
	{
		unsigned char	type[2];		// 2 bytes
		unsigned long	size;			// 4 bytes
		unsigned short	zero1;			// 2 bytes
		unsigned short	zero2;			// 2 bytes
		unsigned long	offsetToData;	        // 4 bytes
	};

Ich wollte jetzt einfach nur mit ifstream::read arbeiten, aber das klappt nicht. Ich bin hier Mal über Umwege mit memcpy gegangen, um das Problem zu verdeutlichen, das ich auch ohne den Umweg habe. Mein Code ist daher gerade:

ifstream header(filename.c_str(), ios::in | ios::binary);

		if(!header)
			return;

		char cs[14];
		header.read(cs, 14);

		memcpy(&bitmapFileHeader_, cs, 14);

Hab vorher mit sizeof schon Mal geschaut, dass die Größe 14 ist. Bin halt schon im Debugging. So, und nach memcpy ist dann irgendeine irrelevante Anweisung, in der ein Haltepunkt sitzt und Folgendes sind die Daten, die ich nicht verstehe:

-		cs	0x0020fb00 "BMbš"	char [14]
		[0]	66 'B'	char
		[1]	77 'M'	char
		[2]	98 'b'	char
		[3]	-102 'š'	char
		[4]	5 ''	char
		[5]	0	char
		[6]	0	char
		[7]	0	char
		[8]	0	char
		[9]	0	char
		[10]	54 '6'	char
		[11]	0	char
		[12]	0	char
		[13]	0	char

-		bitmapFileHeader_	{type=0x0020f6f8 "BMbš" size=5 zero1=0 ...}	OpenGL::BitmapFileHeader
-		type	0x0020f6f8 "BMbš"	unsigned char [2]
		[0]	66 'B'	unsigned char
		[1]	77 'M'	unsigned char
		size	5	unsigned long
		zero1	0	unsigned short
		zero2	54	unsigned short
		offsetToData	3435921408	unsigned long

Das stimmt ja einfach nicht überein. Ich meine, wieso ist size = 5? Size müsste doch das 3. Byte sein. Der Wert 5 entspricht aber vielmehr dem 5. Byte. Erstmalig erkannt hab ich das Problem dadurch, dass zero2 nicht 0 ist, was es laut Spezi von wotsit aber sein sollte. Na ja, wo ist mein Fehler?

Lg

Na ja, wo ist mein Fehler?

Alignment, musst du (Compilerspezifisch) für diese struct ausschalten.

Mrrr, und wenn ich compilerunspezifischen Code bauen will? Ich meine, das ist ja total schlecht portabel auf diese Weise. Sollte ich vielleicht einfach einen anderen Ansatz des Parsens wählen?

Wie du magst. Du kannst
- Compilerswitches einbauen, so dass je nach Compiler entsprechend das Alignment hier ausgeschaltet wird
- Anders einlesen: file.read( &bfh.type, 2 ); file.read( &bfh.size, 4 ); ...
- Eine vorgefertigte Bibliothek nehmen

#pragma pack( 1 )
struct peter
{
};
#pragma pack( )

Außerdem: Die 4Bytes sind unzuverlässig.

Ich les dann einzeln ein, glaub ich.

zum 1. gibts hier scho was:
der 3.letzte Beitrag von Werner
ist zwar die ausgabe-variante, aber geht mit sicherheit auch umzuschreiben

2. sollte np sein

bb

> liest immer entsprechend so viel Byte, wie der rechtsseitige Datentyp lang ist?

Ich les dann einzeln ein, glaub ich.

Genau.
Das geht dann überall.
Wenn du dir ein paar Hilfsfunktionen bastelst, ist das auch halbwegs erträglich.

Und vergiss nicht dass du die Endianness berücksichtigen solltest, falls du es wirklich portabel hinbekommen willst.

> liest immer entsprechend so viel Byte, wie der rechtsseitige Datentyp lang ist?

ja - allerdings meinte ich, dass du deinem struct einen solchen operator spendierst und dort sinnvollerweise genau das machst, was du beim speichern (dann mit op<<) machst...
weil du das Alignment ja nicht unbedingt mit speichern musst... ^^

bb

Hm, wo gibt es denn little und wo big endian?

Guckst du Wikipedia???

Ok, das wäre eine Variante. Aber im Endeffekt macht das ja keinen wirklichen Unterschied dazu alles einzeln zu setzen, nur dass es mehr nach Streams aussieht, oder?

hustbaer:
Grundsätzlich sind mir die Begriffe schon klar. Mir ging es jetzt darum, wo das hier im Einzelnen zutrifft. Ich meine, ich operiere auf Byte-Ebene und wüsste jetzt auch gar nicht, wo ich das auf einem Little-Endian-system anders umsetzen müsste bzw. wie ich es jetzt noch plattformunabhängiger gestalten könnte.

Lg

wo das hier im Einzelnen zutrifft. Ich meine, ich operiere auf Byte-Ebene und wüsste jetzt auch gar nicht, wo ich das auf einem Little-Endian-system anders umsetzen müsste

Die Daten in der Bitmap-Datei sind in Little-Endian abgelegt. Wenn dein System mit Big-Endian läuft, musst alle Datentypen mit >1 Byte um-modeln.

Ok, das wäre eine Variante. Aber im Endeffekt macht das ja keinen wirklichen Unterschied dazu alles einzeln zu setzen, nur dass es mehr nach Streams aussieht, oder?

struct data
{
 int a;
 float b;
 long c;
};

//->weiß nich, ob du das hier jemals brauchst, aber ich schreibs ma mit
Tout_stream& operator<< (Tout_stream &s, const data &these)
{
  s << these.a << these.b << these.c;
  return s;
} //<-

Tin_stream& operator>> (Tin_stream &s, data &these)
{
  s >> these.a >> these.b >> these.c;
  return s;
}

Tin_stream stream("./save.dat");
data buf;
stream >> buf;

wie es mit read und write aussieht, weist du ja selber - und wenn ich statt einer Zeile pro member nur ne hand voll Zeichen brauch, sollte ja wohl klar sein, was ich schöner find...

das du die beiden streamklasen davor noch schreiben musst, ist dann zwar nen Nachteil, aber imho lohnt es sich trotzdem - zu mal du ja schon eine klasse komplett hast (mein 1. link).

aber die probleme von wegen little/big endian bleibt - nur musst du es eben nur noch einmal im code iwo unterscheiden...

falls du hier allerdings nur bhf verstehst, solltest du den ansatz vll vergessen, da es nicht ganz trivial sein wird, die stream-klasse zu schreiben - aber dann solltest du wahrscheinlich allg. bevor du das Problem zu lösen versuchst, noch ein wenig lernen...

bb

Problem ist wohl, dass zero1 und zero2 innerhalb der Datei halt \0 sind und >> da abzubrechen scheint. Der Stream ist binary und ich habe auch versucht Manipulatoren wie std::ws, std::noskipws usw. zu nutzen. Leider war das nicht so erfolgreich.

Welchen Manip müsste ich dafür denn benutzen?

struct TinputStream
{
  typedef size_t size_type;

/*...*/

  template <typename T>
  friend TinputStream& operator>> (TinputStream& s, T& these)
  {
    return s.read(reinterpret_cast<char*>(&these), sizeof(T));
  }
  }
  template <typename T, size_type len>
  friend TinputStream& operator>> (TinputStream& s, T& (these[len]))
  {
    return s.read(reinterpret_cast<char*>(&these), sizeof(T)*len);
  }
};

bin ich mir allerdings nicht ganz sicher, ob das geht... und vor allem geht es nicht mehr, wenn irgend ne länge nicht zur compilezeit bekannt ist...
ich würd std::tr1::array oder std::vector nehmen und dann nen op>> für die zu speziallisieren - du musst halt davor die länge setzen und dann liest der op>> so viel ein, wie der vector/das array lang ist...

bb

inline std::istream& operator>>(std::istream& is, BitmapFileHeader& bfh)
	{
		is.read(reinterpret_cast<char*>(bfh.type),			2);
		is.read(reinterpret_cast<char*>(&bfh.size),			4);
		is.read(reinterpret_cast<char*>(&bfh.zero1),		2);
		is.read(reinterpret_cast<char*>(&bfh.zero2),		2);
		is.read(reinterpret_cast<char*>(&bfh.offsetToData),	4);
		return is;
	}

Ist halt auch nicht so besonders schön, verlagert den Code im Endeffekt ja nur. Außerdem ist der operator nicht Mal mehr wirklich inline...

Bei deiner Variante hätte ich Probleme mit char*, ich könnte natürlich auch nen optionalen Template-Parameter für die Größe übergeben, aber das wäre ja auch hässlich.