Projekt Testen / Verifizieren

Fachdiskussionen rund um Themen und Veranstaltungen ohne Zuordnung zu einem bestimmten Semester (Allgemeine organisatorische und verwaltungstechnische Themen, die NICHT in unmittelbarem und direktem Zusammenhang mit einer Veranstaltung zu sehen sind, bitte in "Studienverwaltung allgemein" einsortieren!)

Moderator: (M) Mod.-Team Allgemein

habermann24
TalkING. Newbie
TalkING. Newbie
Beiträge: 5
Registriert: Sa, 06. Dez. 08, 23:30

Beitrag von habermann24 » Mo, 02. Feb. 09, 11:58

Huhu...wow ist der Thread gewachsen...

Schonmal vielen Dank an Herrn Rosenstiel für die "korrekte" md5-Summe. Habe die jetzt auch (414462c034a3e9c08d7e5b0a3e42c33a). Falls jemand meine md5-Summe vom Anfang des Threads hat, dann liegt es an der Vertauschung von left und right Branch
:shock:

Hätte man sich totsuchen können, dass der CKnot konstruktor die Parameter in vertauschter Reihenfolge (also right, left) übergeben bekommt...
Naja hätt ich mal vorher ins Talking geschaut, hehe!

Edit:

Keine ahnung ob sich die Fragen schon geklärt haben...aber...
ich arbeite mit "gcc version 4.0.1 (Apple Inc. build 5490)" unter Mac Os X ...
Kann mir kaum vorstellen, dass es an gcc versionen liegt, dass manche noch Probleme haben...aber naja man weiß ja nie.

ReadOnly
TalkING. Newbie
TalkING. Newbie
Beiträge: 6
Registriert: Sa, 12. Apr. 08, 18:51

Fertich :)

Beitrag von ReadOnly » Di, 03. Feb. 09, 10:51

So, ich habe endlich auch die richtige Checksum. Gleiches Problem wie Jan... hab mich halb-doof gesucht um endlich darauf zu kommen, dass leftBr und rightBr der Grund ist...

Checksum
Also, jetzt auch (mit initialisiertem CBitArray) meine CheckSum
md5(tuvision.huf)=414462c034a3e9c08d7e5b0a3e42c33a

CodeCoverage
Das war besonders einfach: Ich hatte noch Dev-Cpp vom Assembler und ProgMetho installiert, da ist mingw 3.4.2 dabei. Einfach den Pfad der binaries ("C:\Dev-Cpp\bin") in eure %PATH%-Variable schreiben, in der Command ins Huffman-Verzeichnis wechseln und - wie in der Anleitung beschrieben - "mingw32-make" ausführen. Bei mir kommen dann folgende Abdeckungen raus:

main.cpp -> 60.00% of 20
CFile.cpp -> 92.50% of 40
CHistogramm.cpp -> 100.00% of 14
CHuffmanFile -> 90.48% of 21
CHuffmanTree -> 100.00% of 30
CImage -> 54.55% of 22
CKnot -> 100.00% of 8

ganz ehrlich: Schön, dass ich jetzt die Werte hab, aber was sagen die mir? Ist das gut oder schlecht? Das sagt doch nur aus, wie viele Zeilen des von mir geschriebenen Codes abgearbeitet werden. D.h. werfe ich eine Exeption (als Beispiel), dann habe ich durch das "throw x" eine Zeile mehr, die nicht abgearbeitet wird, richtig?
Was bringt mir also diese Angabe? Oder habe ichs nicht so richtig verstanden?
Was habt ihr denn da so raus?
Und: Sollen die Dateien mit ins SVN-Repo geladen werden?

Fazit
An sich fand ich das ein sehr schönes Projekt, sehr gut strukturiert, wenn man sich einmal in den Aufbau hineinversetzt hat einfach zu verstehen und zu Programmieren. Ein paar kleine Haken hier und da (leftBrgrrrrr... ;-) ), aber sonst sehr viel besser durchdacht als die Vorherigen. Eine kleine Anmerkung: Ich finde den ganzen Kram drumherum zwar sinnvoll, habe aber feststellen müssen, dass mich die Dokumentation (nicht das schreiben, das ist einfach. Das PDF-Erzeugen jedoch nicht...), etc. viel mehr Zeit gekostet hat, als das Programmieren selbst. Ich weiß nicht wem es ähnlich ging, aber ich finde, dieses Zeit-Verhältnis könnte mehr in Richtung Programm gehen.
Was natürlich auch ein bisschen schade ist, ist die Tatsache, dass man die gespeicherten Dateien nicht wieder als Bild auslesen kann (auch nicht theoretisch, weil ja die Tabelle nicht integriert ist). Aber da fällt mir jetzt spontan auch keine Lösung ein. Nur so als Hinweis...
An sonsten hat mir das TalkIng-Forum eine Menge gebracht, hier wurde (auch oder grade durch die Teilnahme von Herrn Rosenstiel) auf eigentlich jedes Problem eine Antwort gefunden.
Und dass die Aufgabenstellung nicht alle Nase lang geändert wurde war ebenfalls hilfreich (nicht so wie in Info I... um da noch ein bisschen drauf herumzuhacken)

Also. Fertich... :P

Rosenstiel
Uni-Mitarbeiter
Uni-Mitarbeiter
Beiträge: 83
Registriert: Fr, 14. Sep. 07, 15:28

Beitrag von Rosenstiel » Mi, 04. Feb. 09, 11:01

Hi ReadOnly,

vielen Dank für das positive Feedback. Durch euer intensives Durcharbeiten sind viele weitere Fehler in unserem zweiten Durchgang dieses Praktikums aufgedeckt worden. Besonders die leftbr-Geschichte ist sehr ärgerlich, zumal dieser Fehler beim letzten Mal irrelevant war.

Man könnte das erneute Einlesen durch einen definierten Header ermöglichen. Evtl. werde ich das als optionale Erweiterung noch in die Aufgabenstellung schreiben, wahrscheinlich wird es jedoch kein fester Bestandteil, da ich die Aufgabe nicht weiter aufblähen möchte.

Bzgl. der Dokumentation und Erstellung muss unsere Aufgabenstellung noch deutlich besser werden und mehr sinnvolle Beispiele liefern. Besonders unglücklich bin ich zur Zeit mit der Code Coverage, weil die jetzige Aussage relativ sinnlos ist und lediglich der Anwendung des Code Coverage Tools dient. Für eine sinnvolle Anwendung müsste man entsprechende Unit Tests schreiben, die jedoch die Aufgabenstellung aufblähen würden. Andererseits suggeriert die Code Coverage zur Zeit, dass Exceptions schlecht sind, was natürlich genau das Gegenteil von dem bewirkt, was wir erreichen wollen.

Ich freue mich, dass wir mit der Aufgabe dennoch auf einem guten Weg sind, auch wenn es noch einige Ecken und Kanten zu schleifen gibt :wink:.

Viele Grüße

Marcus Rosenstiel

xift
TalkING. Freak
TalkING. Freak
Beiträge: 95
Registriert: Do, 07. Feb. 08, 11:01

Beitrag von xift » Sa, 07. Feb. 09, 12:46

hmm habe meinen fehler immernoch nicht gefunden...

habe immernoch 2 verschiedene checksummen unter windows und linux...
gcc machts zum glück richtig deshalb mache ich mir da keine sorgen ums bestehen... trotzdem blöd!

Benutzeravatar
plaicy
TalkING. Champion
TalkING. Champion
Beiträge: 972
Registriert: So, 19. Okt. 03, 17:37
Wohnort: Hamburg

Beitrag von plaicy » Sa, 07. Feb. 09, 12:56

xift hat geschrieben:habe immernoch 2 verschiedene checksummen unter windows und linux...
Ich würde mir genauer anschauen, was sich unterscheidet. Mögliche Vorgehensweise, wenn du kein Programm hast, was es direkt kann: Beide Dateien mit "hexdump -C" (gibt es unter Linux und unter Cygwin) in jeweils eine Text-Datei konvertieren. Anschließend mit diff -u die Text-Dateien vergleichen.
Man sollte Links grundsätzlich nicht trauen und Mods sollten ihre Änderungen namentlich kennzeichnen.

xift
TalkING. Freak
TalkING. Freak
Beiträge: 95
Registriert: Do, 07. Feb. 08, 11:01

Beitrag von xift » So, 08. Feb. 09, 11:06

es geht ^^ ich war doch schuld und mein eigener tipp mit dem ios::binary hat mir geholfen :D

Benutzeravatar
plaicy
TalkING. Champion
TalkING. Champion
Beiträge: 972
Registriert: So, 19. Okt. 03, 17:37
Wohnort: Hamburg

Beitrag von plaicy » So, 08. Feb. 09, 12:05

xift hat geschrieben:es geht ^^ ich war doch schuld und mein eigener tipp mit dem ios::binary hat mir geholfen :D
Vorher hattest du aber geschrieben:
xift hat geschrieben:gleich lang, ziemlich sicher binary geöffnet und laut diff gibt es auch nur 2 unterschiede ^^ ganz seltsam
Deshalb hatte es mich irritiert. Eigentlich müsste die Datei dadurch aber ein zwei Byte länger geworden sein. Was du mit dem "symbolisch gleich" aber "binär verschieden" gemeint hast, was du inzwischen wieder wegeditiert hast, wäre mir auch nicht klar gewesen.
Man sollte Links grundsätzlich nicht trauen und Mods sollten ihre Änderungen namentlich kennzeichnen.

xift
TalkING. Freak
TalkING. Freak
Beiträge: 95
Registriert: Do, 07. Feb. 08, 11:01

Beitrag von xift » So, 08. Feb. 09, 16:06

das hat mir kdiff gesagt.

hatte alles bis auf genau diese datei im binary modus geöffnet ^^
hatte aber die letzten wochen auch keine lust nachzusehen.
Auch egal alles.

gruß,
michael

Benutzeravatar
plaicy
TalkING. Champion
TalkING. Champion
Beiträge: 972
Registriert: So, 19. Okt. 03, 17:37
Wohnort: Hamburg

Beitrag von plaicy » So, 08. Feb. 09, 16:29

xift hat geschrieben:hatte alles bis auf genau diese datei im binary modus geöffnet ^^
hatte aber die letzten wochen auch keine lust nachzusehen.
Auch egal alles.
Okay danke. Dann eigent sich das Programm wohl auch nicht so für binäre Dateien. Hatte gedacht, du hättest vielleicht etwas besseres als hexdump+diff.

Code: Alles auswählen

echo -ne "\r\n" >A
echo -ne "\n" >B
A ist ein Byte lang und B zwei. Da meldet kdiff3 dann:
Die Dateien A und B haben den gleichen Text, sind aber nicht binär identisch.
Entspricht also wohl deinem Text.
Man sollte Links grundsätzlich nicht trauen und Mods sollten ihre Änderungen namentlich kennzeichnen.

Antworten