Ideen zu Programmiervorlesung

Die letzten Vorlesungen dem undefined behaviour widmen. Warum es 
ueberhaupt existiert (ermoeglicht starke Compileroptimierungen, in C 
nimmt der Compiler an, dass der Programmierer es besser als der Compiler 
weiss.). Welche Konstruktionen UB sind. Z.b. ist

Printf ("%s", p);
If (p) *p=1;


Mit p pointer auf char UB fall p NULL ist, und der Compiler optimiert 
somit das if(p) weg.

Dumdi D. schrieb:
> Mit p pointer auf char UB fall p NULL ist,
> und der Compiler optimiert somit das if(p) weg.
Das kann der Compiler aber nur, wenn p ein konstanter Nullpointer ist. 
In diesem Fall ist einfach die if-Abfrage immer false und wird nie 
ausgeführt. Deshalb optimiert der Compiler die Abfrage weg (er könnte 
sie auch drin lassen, aber wozu? der darin befindliche Code wird ja nie 
angesprungen). "Undefiniert" ist an diesem Verhalten gar nichts. Es ist 
lediglich "optimiert".

Aber gerade die Optimierungsstrategien des Compilers und warum z.B. eine
for(int i=0; i<1000; i++);
Schleife einfach ungefragt wegoptimiert werden kann, das sollte schon 
erwähnt werden.

Und natürlich die ganze volatile-Geschichte und Zugriffe auf globale 
Variablen im Interrupt sind ein Wort wert.

Wobei natürlich "eine VL in C" wesentlich unhandlicher und abstrakter 
ist, als "eine VL in C für Mikrocontroller"...

MaWin schrieb:
> Ist tatsächlich irgendwo festgelegt, dass man printf("%s") keinen
> NULL-Pointer mitgeben darf?
> Ich hätte da eher erwartet, dass printf sowas wie <NULL> ausgibt
So ist es:
http://codepad.org/OKkBSpww

Nicht unerwähnt bleiben sollte auch, dass eine einzelne Programmzeile 
beliebig lang oder kurz dauern kann. Denn manche meinen tatsächlich 1 
Zeile = 1 Befehl = 1 CPU-Takt. Hier wäre ein Fingerzeig auf den 
erzeugten Assemblercode und eine kurze Analyse der dortigen Befehle 
sicher interessant. Für manche Programmierer wird das zwar das einzige 
Mal im Leben sein, dass sie sowas sehen, aber es ist dann schon mal im 
Hinterkopf verankert, dass da noch mehr ist...

Bei mir damals, in den Vorlesungen, fing es mit der Geschichte von C an 
und ging dann über Zahlensysteme zum ersten "Hello-World"-Programm...
Und dann würde ich versuchen die Studys viel selber machen zu lassen.
Prgrammieren ist wie ein Handwerk...vom Zugucken lernt man es nicht...
Gruss

Felix schrieb:
> um mal eins der klugen Zitate meiner Vorlesung zu zitieren
https://fortrabbit.github.io/quotes/

Ich ratter mal die Übungsaufgaben runter die ich früher gestellt habe. 
Das war für eine Fortgeschrittenenkurs und die Leute wollten gefordert 
werden, statt nur Kinderkram zuimplementieren. Allerdings war ich bei 
den Aufgaben ziemlich einfallslos. Hinzukommt dass die Algorithmen nicht 
direkt auf die später zu schreibenden Programme abgestimmt waren.

- Implementiere eine Priority-Queue mit Red-Black Trees
- Implementiere Arbitrary Precision Arithmetik: Addition und Subtraktion
- Implementiere Arbitrary Precision Arithmetik: Multiplikation
- Implementiere Arbitrary Precision Arithmetik: Division
- Implementiere eine Skip-Liste.

- Schreibe eine eigene Version von make
- Schreibe eine eigene Version von more
- Schreibe eine eigene Version von sort
- Schreibe eine eigene Version von grep

- Schreibe ein Plotprogramm (ASCII Ausgabe)
- Schreibe einen Peephole-Optimizer für Z80 Assembler
- Schreibe einen Simulator für kontinuierliche Systeme (DGLs)

Hannes J. schrieb:
> - Implementiere eine Priority-Queue mit Red-Black Trees
> - Implementiere Arbitrary Precision Arithmetik: Addition und Subtraktion
> - Implementiere Arbitrary Precision Arithmetik: Multiplikation
> - Implementiere Arbitrary Precision Arithmetik: Division
> - Implementiere eine Skip-Liste.
>
> - Schreibe eine eigene Version von /make/
> - Schreibe eine eigene Version von /more/
> - Schreibe eine eigene Version von /sort/
> - Schreibe eine eigene Version von /grep/
>
> - Schreibe ein Plotprogramm (ASCII Ausgabe)
> - Schreibe einen Peephole-Optimizer für Z80 Assembler
> - Schreibe einen Simulator für kontinuierliche Systeme (DGLs)

Und damit lernt man C? Oder Programmieren im allgemeinen?

Cyblord -. schrieb:
> Und damit lernt man C? Oder Programmieren im allgemeinen?
Ich stelle da gern andere Aufgaben, die man sowohl mit Brute Force als 
auch mit einem "schlauen" Algorithmus lösen kann und/oder soll.

So z.B. die Sache mit den Zügen, die von zwei Bahnhöfen losfahren und 
sich irgendwo treffen.
Frage 1: wo
Frage 2: wann
Und die Antwort darauf dann mit der klassischen Algebra in Form einer 
Quadratischen Gleichung. Oder als sukzessive Approximation durch 
Aufaddieren von kurzen Wegstrecken in kleinen Zeitabständen und 
Vergleich der Position.

Oder das Herausfinden der Anzahl von unterschiedlichen Kombinationen der 
Farbstreifen einer Flagge z.B. mit rot, grün und blau mit 3 
geschachtelten Schleifen oder mit einem lange laufenden 
Zufallsgenerator.

Also Aufgaben, die schon in Gedanken bzw. auf einem Blatt Papier leicht 
zu lösen sind und deren Antwort bekannt ist. Solche also, an denen nur 
die Umsetzung in die neue Programmiersprache neu ist.

- Bring den Leuten bitte moderneres C bei. Es gibt eigentlich keinen 
vernünftigen Grund, warum man heute noch K&R oder C89 verwendet.

- Best Practice, wie Unit-Tests kann man sicher auch bereits ganz am 
Anfang erfolgreich einsetzen.

- Erkläre ihnen den Unterschied zwischen Compiler und Linker und halte 
sie erst einmal von einer IDE fern! ;-)

Es stellt sich auch die Frage ob du Wissen über C oder Wissen über 
Programmierung allgemein vermitteln willst. Das sind zwei paar Schuhe 
und man kann nur davor warnen beides zu vermischen.

Nicht umsonst fängt so mancher Programmierkurs an der Uni mit 
ungeliebten (und praktisch unnützen) Sprachen an. Man kann aber gar 
nicht früh genug anfangen, den Studenten den Unterschied zwischen 
Konzepten und konkreten Programmiersprachen zu vermitteln.

Algorithmen und Datenstrukturen sind dann IMO nochmal ein drittes 
Gebiet, welches von den zwei Obigen auch etwas abgesetzt betrachtet 
werden sollte.

Felix schrieb:
> Ich äußer mich mal kurz zu ein paar Sachen.
> Also vielleicht ist das nicht so rüber gekommen. Ich stehe jetzt nicht
> mit dem Rücken zur Wand und suche verzweifelt nach Antworten. Ich habe
> die Vorlesung fast fertig und suche nach ein paar Gewürzen um die noch
> ein bisschen zu verbessern.

Undefined Behavior wurde schon genannt.
Secure Coding 
https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard
Dazu könnte man auch noch optional Reversing machen, um zu zeigen wie 
man solche Bugs ausnutzen kann (natürlich nicht gleich gegen moderne 
Systeme und Compiler also erstmal ASLR aus, mit -fno-stack-protector 
übersetzen, 32-Bit usw. einfache Challenges: Buffer-Overflows ausnutzen, 
Format Strings, da gibt's genug zum Austoben)

Ich würde noch einige Allgemeine Dinge einfliesen lassen:
 * Man sollte keinen Code kopieren, den man nicht versteht
 * Beispiele und best practices sind nicht der Weisheits letzter 
schluss, je nach Problemstellung und Situation können unterschiedliche 
Herangehensweisen sinn machen. Letztendlich füren immer viele wege nach 
Rom. Ich habe schon Leute getroffen die gefragt haben wie man etwas 
umsetzt, und eine art absolute Antwort gesucht haben, statt sich 
verschiedene Herngehensweisen und deren Implikationen zu überlegen.
 * C fehlen komplexere Sprachkonstrukte und Konzepte die viele andere 
Programiersprachen haben, die Sprachkonstrukte sind recht Primitiv, aber 
den anderen Sprachen keineswegs unterlegen. Häufig hat man mehr 
Kontrolle darüber was der code alles tut und wie man es umsetzen will, 
aber man kann fast alle komplexeren Konzepte wie OOP auch in C recht 
einfach nachbilden. Das Daten und Funktionen getrennt sind betrachte ich 
als grossen Vorteil von C gegenüber vielen anderen sprachen.

Der C Präprozessor ist sehr mächtig, aber nur wenige trauen sich diesen 
zunutze zu machen. Ein paar Anwendungsszenarien können nicht schaden:
 * Include guards
 * Kleine Templates
 * Mehrere korrelierende Listen:

1

#define SOME_CONSTANTS \

2

  X(TEST) \

3

  X(PIZZA)

4

5

#define X(Y) #Y,

6

const char* constant_names[] = {SOME_CONSTANTS};

7

#undef X

8

9

#define X(Y) CONSTANT_ ## Y,

10

enum constant_list {

11

  SOME_CONSTANTS

12

  CONSTANT_COUNT

13

};

14

#undef X

 * Hinzufügen von Funktionsnamen usw. bei Logging funktionen
 * Häufig verwendete non-standard Macros, z.B. Arraygrösse bestimmen, 
container_of, MIN/MAX, etc.
 * Conditional compilation
etc.

Auch interressant sind Methoden dinge ohne Heap allocationen zu tun, und 
deren Grenzen. Die linked list Implementierung im Linux Kernel zum 
Beispiel ist faszinierend, keine Dynamischen allocationen, und die 
einzige Limitation ist das ein Element nicht doppelt in der Liste sein 
kann.

Na los, felix erklaer den hier doch mal warum das printf mit nullpointer 
UB ist.

MaWin schrieb:
> Dumdi D. schrieb:
>> Na los, felix erklaer den hier doch mal warum das printf mit nullpointer
>> UB ist.
>
> Ich warte auch noch.
>
> Vielleicht war so etwas gemeint:
>
>

1

> strcpy(x, p);

2

> If (p) *p=1;

3

>

>
> strcpy dereferenziert in jedem Fall p[0]. Deshalb darf if(p) durch if(1)
> ersetzt werden.

7.21.1 String function conventions

1

... in all cases a char * or void * argument points to the initial (lowest addressed) character of the array. If an array is accessed beyond the end of an object, the behavior is undefined.

Also wie immer: ist x oder p oder sind beide Null, darf da alles 
rauskommen. Beim printf genauso:
7.19.6.1 The fprintf function

1

... the argument shall be a pointer to the initial element of an array of character type

was bei einem Nullpointer passiert ist undefiniert.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

Felix schrieb:
> @Jeff Portnoy
> “First, solve the problem. Then, write the code.”
> (John Johnson)
>
> um mal eins der klugen Zitate meiner Vorlesung zu zitieren.
> Aber danke schon mal für die guten Ideen bis jetzt.

Da hat er nicht Unrecht, der Mann. Und wenn Du schon bei Zitaten bist, 
hier gleich noch zwei: "Premature optimization is the root of all evil." 
(Donald E. Knuth) und "Measure, don't guess." (Kirk Pepperdine).

Torsten R. schrieb:
> - Bring den Leuten bitte moderneres C bei. Es gibt eigentlich keinen
> vernünftigen Grund, warum man heute noch K&R oder C89 verwendet.
>
> - Best Practice, wie Unit-Tests kann man sicher auch bereits ganz am
> Anfang erfolgreich einsetzen.
>
> - Erkläre ihnen den Unterschied zwischen Compiler und Linker und halte
> sie erst einmal von einer IDE fern! ;-)

Leider kann ich hier nur ein "lesenswert" vergeben. Ich wollte, es wären 
tausend!

NochEiner schrieb:
> Ach ja im Zusammenhang mit Coding-Style könnte man den hier bringen (als
> Negativ-Beispiel) http://www.ioccc.org/

Negativbeispiele sind für Anfänger schlecht. Die prägen sich das ein und 
Du bekommst es nur mit einem riesigen Aufwand wieder heraus.