conversion may loose significant digits
-
Kolumbus schrieb:
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.

-
Toller Beitrag! Da kannst du dir auf die Schulter klopfen, dass du heut mal wieder wirklich jemandem weitergeholfen hast!
-
@ CStoll: Ok, Danke. Ich finds zwar Blödsinn wenn der Compiler char versteht, mich aber immer wieder darauf hinweisen will, dass da was schiefgehen könnte... Aber dafür kann man die Warung ja abschalten.
-
Kolumbus schrieb:
@ 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

-
Dann schreib doch halt:
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)).
-
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"

@Th: genau, ich stopf ihm mit static_cast das Maul!
ich werd' die wohl einfach als int definieren, ja.
-
Kolumbus schrieb:
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.
-
auch das noch. 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?
Ich mach's jetzt übrigens so:cVariableA = (char)(cArrayB[1] - 0x31);was ja weitestgehend Th's Variante entspricht, oder? Ist nur etwas übersichtlicher?!
-
Kolumbus schrieb:
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? Oder geht nur das Eine ODER das Andere? Nur so interessehalber... Falls es mal gebraucht wird... Irgendwas ist ja immer...
-
Kolumbus schrieb:
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...
-
Dem entnehme ich:
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.
-
du solltest selektiv festlegen können, wie datenstrukturen "gepackt" werden. in visual c++ geht das mit #pragma pack().
#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 wiederherstellenbcb hat sicher etwas vergleichbares.
-
Kolumbus schrieb:
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:
cssllllllllcccWie 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.
-
Danke an alle Beteiligten für die Aufklärung.
Mir ist zwar nicht ganz klar, warum Compiler-default pack(8) ist und nicht pack(1) und wozu man das verstellen kann, aber soweit bin ich halt einfach noch nicht. Sicher kommt der Aha-Effekt, wenn es eine Rolle spielt. Bis dahin merke mir nur, was die Einstellung "DataAlignment" direkt macht und das ich nicht daran rumschrauben muss.
Ansonsten, habe ich verstanden - wartbarer Code ist das A und O! Und wartbar verstehe ich: klare Variablennamen, einen sauber strukturierten Quellcode und nicht 1000 Zeiger die sich gegenseitig kreuz und quer referenzieren. Ist das Ok?
-
Kolumbus schrieb:
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.
-
Mr. Spelling schrieb:
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!