Nullen setzten

Mein Code:

ModDat->nMCStates=0xff;
itoa(ModDat->nMCStates, cString, 2);
m_pChild->Grid->Cells[3][1] = cString;

Mein Problem:

cString welcher aus 24 Bit besteht soll auch alle 24 Bits ausgeben, wobei vor den "wirklichen" Wert Nullen gesetzt werden sollen.
Bitte helft mir mein Kopf raucht scho

PAD

Stringlänge feststellen und solange 0 voranstellen bis 24 Bit erreicht sind

als C-Code

char buffer[25];
count=strlen(cString);
if (count <24)
 {
  sprintf(buffer,"%0*i",(24-count),0);
  strcat(buffer,cstring);
 }
 else
  strcpy(buffer,cstring);

in buffer steht dan der konvertierte wert mit führenden Nullen

Wenn jemand dafür eine schöne C++ Implementierung hat wäre ich interessiert

HumeSikkins

Hallo,
ich verstehe zwar die Frage nicht, aber PADs Code würde ich in C++ wohl in etwa so schreiben:

string dest(24, '0');
assert(source.length() <= 24);
dest.replace(24-source.length(), source.length(), source);
assert(dest.length() == 24);

Alternativ könnte man es auch so machen:

assert(source.length() <= 24);
string dest(source);
dest.insert(0u, 24-source.length(), '0');
assert(dest.length() == 24);

PAD

Er will eine 24 Bit Zahl binaer darstellen. die nichr Standardfunktion itoa wandelt zwar integers in
eine binaere ASCII-Darstellung um allerdings gibt es keine Möglichkeit führende Nullen ainzufügen.
Das muß man von Hand anschließend. machen

@HumeSikkins

Kannst du mit bitte das mit den assertions erklären. Das verstehe ich nicht. IMO würde das zu einer
Terminierung des Programms führen.

HumeSikkins

Kannst du mit bitte das mit den assertions erklären. Das verstehe ich nicht.

Ich hatte zu dem Zeitpunkt an dem ich den Beitrag schrieb keinen Compiler zur Hand und da ich bei sowas immer sehr gerne "off-by-one"- oder ähnliche Fehler mache, habe ich mich und andere mit den asserts abgesichert.

. IMO würde das zu einer
Terminierung des Programms führen.

Warum?

PAD

So wie ich assert kenne, fangen diese Fehler ab melden das und beenden das Programm. Hab auch vor kurzem in C/C++ Journal einen Artikel gelesen der das zur Designmethode erklärt hat.

Grundgedanke im Debug build an jeder Stelle wo ein Fehler passieren kann ein Assert hin und somit abbrechen, damit ist man gezwungen das Problem zu finden und zu lösen, antelle Umwege zu finden um trotzdem weitermachen zu können.

Prinzipiell hat die Idee etwas, speziell wenn man in einem Team arbeitet und somit den Fokus auf
Fehlerkorrektur anstelle von workaround setzt. Aber als Designmethode, ich weis nicht.

HumeSikkins

Aber als Designmethode, ich weis nicht.

Ich würde das auch nicht als Designmethode bezeichnen.
Assertions helfen dabei implizite Annahmen zu dokumentieren. Sie helfen dabei ein stabiles Design aufzubauen und Fehler so schnell und unbarmherzig wie möglich zu melden.
Aber nur weil assertions häufig im Zusammenhang mit "Design by contract" genannt werden, sind sie selbst keine Designmethode.

Aber was mich viel mehr interessiert. Warum beantwortest du nicht meine Frage?

Du:

Kannst du mit bitte das mit den assertions erklären. Das verstehe ich nicht. IMO würde das zu einer
Terminierung des Programms führen.

Ich:

Warum?

Warum führt das zur Terminierung des Programms? Wo ist mein Fehler?

PAD

Dachte ich eigentlich mit folgendem Satz

So wie ich assert kenne, fangen diese Fehler ab melden das und beenden das Programm.

Du hälst also eine 25 Bit Eingabe Ergebnis für einen so schwerwiegenden Fehler um das Programm abzubrechen?

Ich hoffe ich hab das nicht mit meinem 25 Characterstring provoziert, sinnvolle Länge wäre 33 Bytes.
Da die Eingabe ja eine unsigned long int sein soll und somit 32 Characters herauskommen könnten.

Und ein Ergebnis das nicht genau 24 Byte lang ist führt zum Abbruch?

Shade Of Mine

PAD schrieb:

Und ein Ergebnis das nicht genau 24 Byte lang ist führt zum Abbruch?

Das ist Definitionssache.
Hume hat seinen Code so geschrieben, dass er 24Byte handhaben kann.
siehe (string dest(24,'0); )

Natürlich kann man das ändern, zB:

string foo(string const& source, unsigned size)
{
  string dest(size, '0'); 
  assert(source.length() <= size); 
  dest.replace(size-source.length(), source.length(), source); 
  assert(dest.length() == size);
  return dest;
}

Die asserts Dokumentieren doch nur die impliziten Annahmen die Hume gemacht hat.

wenn source länger als dest ist - gibts Probleme
wenn dest am Ende nicht genauso lang ist, wie es sein soll (nämlich source.length() + führende Nullen) - dann hat die Funktion versagt.

PAD

Gott sei Dank, dann hatte ich das richtig verstanden.

Jetzt noch eine Frage, IMO sind asserts üblicherweise nur im Debug-Code aktiv nicht in einer release Version, wäre dann nicht eine Fehlermeldung die vom Aufrufer ausgewertet werden muss, sinnvoller, die Reaktion des Aufrufenden sollte dann eine kontrollierter Shutdown der Software
sein. Da ich mit Geräten wie Drehtischen, Klimakammern , u. ä. arbeite ist mir ein harter Ausstig im Debug alla assert irgendwie suspekt (speziell da er im release IMHO nicht stattfindet), ich muß ja mindestens in der Lage sein die Klimakammern auf Raumtemperatur und die Drehtische zum Stand zu bringen. 500 °/sec und 90°C übers Wochende wegen einer Assertion am Freitag um 23.00Uhr, da werden meine Prüflinge eingermassen sauer.

Shade Of Mine

Wann man assert() verwenden soll ist nicht einheitlich geregelt (sprich: jeder macht es anders)

Ich verwende assert() immer dann, wenn ein Fehler ein Logikfehler ist - ein Fehler, der eigentlich nicht vorkommen kann

zB index Überschreitung teste ich mit assert()
Oder auch 0-Zeiger

Humes erstes assert() kann durchaus auch durch ein if(...) throw "string too long"; ersetzt werden. Da kommt es darauf an, was dir lieber ist.

Mir persönlich ist das assert() lieber, denn IMHO soll der Aufrufer richtige Werte übergeben (er soll sicherstellen, dass die Werte valid sind).

Das zweite assert() sollte aber ein assert() bleiben, denn es ist eine Art Sicherstellung dass die Funktion richtig funktioniert. Denn das assert() kann nur dann Fehlschlagen, wenn die Funktion fehlerhaft ist. Sowas testet man in der Debug Version, aber in der Release Version sollte man schon so viel vertrauen zu dem Code haben, dass man diesen Test weglassen kann.

PAD

Wie kann ich erreichen das ein Teil der asserts in der Release Version aktiv bleiben.

Die throw catch lösung für das erste assert gefällt mir besser.

denn IMHO soll der Aufrufer richtige Werte übergeben (er soll sicherstellen, dass die Werte valid sind.

Hier halte ich es eher mit einem Spruch der HP-Measurement Division.

precise talking, forgiven listening

Selber Korrekte Daten erzeugen, aber mit dem DAU rechnen und falls möglich die SW dagegen sichern.

Shade Of Mine

PAD schrieb:

Wie kann ich erreichen das ein Teil der asserts in der Release Version aktiv bleiben.

Garnicht.

Die throw catch lösung für das erste assert gefällt mir besser.

Wie gesagt, da sind beide Lösungen üblich. Je nachdem was einem besser liegt.

Selber Korrekte Daten erzeugen, aber mit dem DAU rechnen und falls möglich die SW dagegen sichern.

Ich teste halt nur in der Debug Version - danach bin ich mir sicher, dass ich keine falschen Daten mehr habe.

Ich glaub bei fast jedem größeres Projekt schreiben die Entwickler sich ihr eigenes assert.

Shade Of Mine

schrieb:

Ich glaub bei fast jedem größeres Projekt schreiben die Entwickler sich ihr eigenes assert.

Ich wuerde sowieso Vorschlagen, dass sich jeder sein eigenes assert() schreibt.

davie

PAD schrieb:

Wie kann ich erreichen das ein Teil der asserts in der Release Version aktiv bleiben.

das würde dann doch etwas peinlich sein, wenn der endbenutzer nach stundenlanger tipparbeit mit einer assertion und einem programmabruch abgefertigt werden würde

Ich wuerde sowieso Vorschlagen, dass sich jeder sein eigenes assert() schreibt.

Echt? Hast du dafür auch eine Begründung?

Shade Of Mine

PAD logged out schrieb:

Ich wuerde sowieso Vorschlagen, dass sich jeder sein eigenes assert() schreibt.

Echt? Hast du dafür auch eine Begründung?

Ja, assert ist böse

operator void

Vielleicht sollte da noch der Hinweis rein, dass man _dieses_ Assert dann besser nicht in Destruktoren verwenden sollte. Hab ich zumindest beim flüchtigen Überfliegen nicht sehen können.

Zu dem Thema habe ich mir auch noch http://www.cuj.com/documents/s=8464/cujcexp0308alexandr/ gebookmarkt, aber bisher nicht gelesen

mist, wollte gerade so eine klasse für mich schreiben wie es Shade beschrieben hat und dann die schlechte Nachricht von operator void.