Nullen setzten

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.

PAD

Nur zur Klarstellung

PAD logged out

Das bin ich nicht

PAD

[quote=SHADE]Ich teste halt nur in der Debug Version - danach bin ich mir sicher, dass ich keine falschen Daten mehr habe. [/quote]

Du Glücklicher, ich habs mit Geräten zu tun für die ich/wir auf ihre QualitätsPrüfProgramme schreiben. Diese haben auch digitale Kommunicationsschnittstellen und selbst DAU´s sind dagegen manchmal angenehme Zeitgenossen. Wenn einer der Prüflinge spinnt sind falsche Daten in Inhalt und Form eher die Regel als die Ausnahme.

Shade Of Mine

operator void schrieb:

Vielleicht sollte da noch der Hinweis rein, dass man _dieses_ Assert dann besser nicht in Destruktoren verwenden sollte.

ein assert() in einem Destruktor?
Wieso sollte so etwas vorkommen, bzw. inwiefern sollte dies schlechter sein als ein normales assert()?

Ich hatte noch nie ein assert() in einem Dtor, aber selbst wenn es auftreten sollte wäre es immer noch besser als ein assert() - denn bei meinem Assert() kann es zu Resourcenlöchern kommen, beim echten ássert() kommt es dazu.

Welche Lösung würdest du vorschlagen?

Im Prinzip bleibt einem nichts anderes übrig als eine Exception zu werfen.

davie

imho ist das im prinzip dann sowieso schon egal. 2 ausnahmen.. da stinkt was
aber eventuell könnte man ein assert machen, das das programm nur abbricht, wenn uncaught_exception() false liefert

Was passiert denn, wenn eine Exception im Destruktor ausgelöst wird? Ist das dann undefiniertes Verhalten?

Noch eine Frage, Shade:

Warum hast du hier exp nochmal geklammert?

if(!(exp))