cVariableA = cArrayB[1] - 0x31;

??? cVariableA und cArrayB sind chars. cArrayB hat 10 Elemente (eigentl ja auch egal).

Wenn ich cVariableA und cArrayB als unsigned char definiere und schreibe:

cVariableA = cArrayB[1] - 0x31;

oder

cVariableA = cArrayB[1] - (unsigned char)0x31;    //Edit

schreibt der Compiler auch "conversion may loose significant digits". Was soll das? Sind doch im Prinzip drei Variablen / Werte gleichen Typs!

Ist ja eigentl. nur ne Compiler-Warnung und man kann sie auch abstellen, ich weiß, aber es wurmt mich trotzdem!

Warum schreibt der Compiler des BCB3 hier "conversion may loose significant digits":

wenn er wirklich "loose" schreibt, dann wahrscheinlich weil der texter es mit der rechtschreibung nicht so genau nimmt.

@ CStoll: Ok, Danke. Ich finds zwar Blödsinn wenn der Compiler char versteht

Ja, er weiß zwar, was ein "char" ist - aber er hält es für zu klein, um damit zu rechnen

cVariableA = static_cast<char>(cArrayB[1] - 0x31);

Der Compiler weiß halt nicht, daß in deinem Array nur Werte größer gleich '1' stehen.
Aber eigentlich solltest du dann cVariableA nicht als char, sondern als int definieren (da du ja kein Zeichen dort hineinschreibst, sondern eine Zahl (Differenz zweier Zeichen)).

Ja, er weiß zwar, was ein "char" ist - aber er hält es für zu klein, um damit zu rechnen

So ein Penner dieser Compiler! Wenn ich in den Schrank schaue sage ich auch nicht jedes Mal "die Schnapsgläser sind zu klein für einen halben Liter Milch"

@Th: genau, ich stopf ihm mit static_cast das Maul! ich werd' die wohl einfach als int definieren, ja.

CStoll schrieb:

Ja, er weiß zwar, was ein "char" ist - aber er hält es für zu klein, um damit zu rechnen

So ein Penner dieser Compiler! Wenn ich in den Schrank schaue sage ich auch nicht jedes Mal "die Schnapsgläser sind zu klein für einen halben Liter Milch"

Das ist kein Problem des Compilers - "Integral Promotion" ist im ANSI Standard vorgeschrieben.

cVariableA = (char)(cArrayB[1] - 0x31);

was ja weitestgehend Th's Variante entspricht, oder? Ist nur etwas übersichtlicher?!

Belegen die chars dann eigentlich den vollen int-Speicherplatz und mir wird nur vorgegaukelt ich würde sparen? Oder belegt ein char wirklich nur 8Bit?

Kommt z.T. auf deine Compilereinstellungen an. Bei Projektoptionen gibt es das Tab "Advanced Compiler" mit der Radio Group "Data Alignment". Bei der Defaulteinstellung Quad Word werden bei solchen Feldern, wie du es hast, immer 8 Byte auf einmal allokiert. Also bei char[10] werden 16 Byte verbraucht. Das kann komische Effekte verursachen, wenn man Datenstrukturen hat und deren Speicherbereiche direkt anspricht und davon ausgeht, dass alle Elemente direkt hintereinander im Speicher liegen. Ein Element des Arrays ist allerdings trotzdem nur 8 bit groß.

Und wie kann ich trotz Quad Word-Einstellung ein char-Feld / -Array mit 10 Elementen erstellen, das nur 80Bit / 10 Byte belegt?

Garnicht?

Naheliegend wäre wohl, auf "Byte" umzuschalten...

http://www.lugbz.org/documents/smart-questions_de.html

Wenn ich viel mit char, bool und short arbeite, sollte ich am Besten auf Byte stellen - das spart Speicher!?! Sprich, die Einstellung legt fest, wieviel Speicher für eine Variable mindestens allokiert wird!?!

Kann mir das irgendwie auf die Füße fallen? Ich überblicke die Möglichkeiten nicht ganz, die sich hinter dieser Einstellung verbergen.

#pragma pack(push) // altes alignment sichern
#pragma pack(1) // an bytegrenzen ausrichten

// diese struktur belegt 2*sizeof(char)
struct foo
{
    char bar;
    char baz;
};

#pragma pack(pop) // altes alignment wiederherstellen

bcb hat sicher etwas vergleichbares.

Wenn ich viel mit char, bool und short arbeite, sollte ich am Besten auf Byte stellen - das spart Speicher!?!

Möglicherweise, ein wenig, hängt von deinen Strukturen ab. Mach dir über Speicher im PC erst Sorgen, wenn er dir ausgeht! Wenn es soweit ist, hast du wahrscheinlich einen Designfehler oder Speicherleck. Kümmer dich lieber um wartbaren Code.

Kolumbus schrieb:

Sprich, die Einstellung legt fest, wieviel Speicher für eine Variable mindestens allokiert wird!?!

Nein.

Kolumbus schrieb:

Kann mir das irgendwie auf die Füße fallen? Ich überblicke die Möglichkeiten nicht ganz, die sich hinter dieser Einstellung verbergen.

Performance könnte drunter leiden, evtl. hat das Auswirkungen auf Speicheranforderungen. Aber mach dir darüber erst Sorgen, wenn es Auswirkungen hat. Kümmer dich lieber um wartbaren Code.

Mr. Spelling schrieb:

bcb hat sicher etwas vergleichbares.

Geht genauso mit #pragma pack(), kann man aber halt auch voreinstellen.

kleines Beispiel:

#pragma pack(8) //BCB default
struct
  {
  char c1;
  short s;
  long long l;
  char c2,c3,c4;
  } bla;

sieht im Speicher so aus:

c_ss____llllllllccc_____

#pragma pack(8)
struct
  {
  char c1;
  char c2,c3,c4;
  short s;
  long long l;
  } bla;

dagegen so:

ccccss__llllllll

#pragma pack(1)
struct
  {
  char c1;
  short s;
  long long l;
  char c2,c3,c4;
  } bla;

sieht im Speicher so aus:

cssllllllllccc

Wie gesagt, bei Direktzugriff auf den Speicherbereich kann das komisch werden, wenn plötzlich "leere" Stellen in der Struktur sind. Ohne dreckiges Bytegefummel sollte es aber kein Problem sein.

Mir ist zwar nicht ganz klar, warum Compiler-default pack(8) ist und nicht pack(1)

weil der computer viel schneller auf daten zugreifen kann, die an dword oder qword-grenzen ausgerichtet sind. auf solche zugriffe ist die architektur optimiert. bestimmte architekturen können sogar nur dann auf daten korrekt zugreifen, wenn sie entsprechend ausgerichtet sind (z. b. SSE und dessen verwandte).

und wozu man das verstellen kann

weil man es manchmal halt braucht.

weil der computer viel schneller auf daten zugreifen kann, die an dword oder qword-grenzen ausgerichtet sind. auf solche zugriffe ist die architektur optimiert. bestimmte architekturen können sogar nur dann auf daten korrekt zugreifen, wenn sie entsprechend ausgerichtet sind (z. b. SSE und dessen verwandte).

Das verstehe ich, Danke!