Re: C++

["Mag. Dr. Nikolaus Klepp" <dr.klepp@gmx.at>]

Am Montag, 5. Januar 2009 schrieb Volker Dirr:
> [...]
> Darf ich fragen, was sie in der Praxis machen? Ihre Homepage ist da leider
> nicht so aussagekräftig.
Die Homepage ist eines der Dinge, die von Monat zu Monat weitergeschoben 
werden, bis sie sich selber erledigen :-) 

90% meiner Zeit bin ich in der Produktentwicklung für Greiner Bio One, die 
restlichen paar % sind Projektbegleitung für andere Kunden. Ich hab' vor 
urdenklichen Zeiten auf CBM-Maschinen programmieren gelernt.

> Aus meiner Praxis (ich bin ja nur kleiner Hobbyprogrammierer) kann ich nur
> sagen, dass ich einige von ihnen angesprochenen Dinge (Little/Big Endian,
> Shift-Operatoren, Bits testen) nie brauchte. Viel wichtiger war für mich
> das Wissen um "Fehler" bei Wertbereichsüberschreitung, Datentypumwandlung,
> erkennen von Zugriff auf nicht definierten Speicher, Umgang mit
> Compilerwarnungen, ein sauberer Schreibstil, einen Algorithmus
> nachvollziebar schreiben, einen Algorithmus Zeiteffizient zu schreiben,
> einen Algorithmus Speichereffizient zu schrieben, Bewerten zu können wann
> welcher Algorithmus besser ist (eher der Zeit oder speichereffiziente
> Algorithmus), schon vor dem programmieren Abschätzungen über Zeit und
> Speicherbedarf zu machen, Fehler abfangen bzw. Richtigkeit mit asserts
> prüfen, ...

Ja, stimmt. Das basiert aber alles auf dem vorhanden Grundwissen. Aber 
dieses "passive" Wissen um das Wesen der Dinge fehlt sehr oft. Zum 
Beispiel, "Was ist Speicher ?" :-)

> [...]
> Z.B: Little/Big Endian, Shift-Operatoren, Bits testen? Aber dann hätte ich
> auch gerne "richtige" Beispiel aus der Praxis. Vielleicht können Sie mir
> da helfen?
>
> Little/Big Endian habe ich nie gebraucht, weil ich selbst für meine Import
> und Exportfunktionen nur den Zeichensatz einstellen muss und mich das
> genaue Endian letztendlich gar nicht kümmern muss.
>
> Bei den Shift Operatoren habe ich bisher nur Dinge gefunden, die ein
> heutiger Compiler schon von alleine macht. (z.B. Optimierung der
> Multiplikation).
>
> Bits testen? Da bin ich mir nicht 100% sicher, was sie meinen. Asserts
> baue ich in meinen Quelltext auch ein und teste damit Bits, aber
> wahrscheinlich meinen Sie etwas anderes.
>
> Ich freue mich auf gute Praxisbeispiele um sie in mein Skript einbauen zu
> können.

Klar kann das ein Compiler, dafür ist er ja da. Aber der Compiler ist 
eine "Black Box". Wie überprüft man, was Compiler/Code/System wirklich 
machen, wenn man nicht nachschauen (ein geeignete Programm schreiben) kann?

Keiner der Programmierer, die ich kenne und denen die Grundlagen fehlten haben 
diese nachgelernt. Das macht meistens nichts, sie sind eben in Sparten 
abgewandert, wo's nicht auffällt - viel Marketing, wenig Engineering. Dort 
tummeln sich sehr viele Gleichgesinnte :-)

Ein Beispiel mit Bits, z.B. ein Lauflicht mit 8 LEDs, eines leuchtet. Direkt 
als Shift-Operator zu implementieren, mit Bittest:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
        int muster=0b1011;
        int i;
        puts("\33c");
        for (;;) {
                printf("\33[1;1f");
                muster=((muster<<1) | (muster>>7)) & 255;
                for (i=0; i<8; i++) {
                        putchar( muster & (1<<i) ? '*' : '.' );
                }
                putchar('\n');
                sleep(1);
        }
	return 0;
}

Da sind die wichtigsten Bitspielereien drinnen, inclusive der mystischen Welt 
von VT100 Terminals. Klar, es geht auch mit Strings, Arrays etc., überall, wo 
eben ein Shiftoperator definert ist. Es funktioniert auch mit GUIs, nur wird 
der Overhead riesig (deshalb Konsole, klassisch). Und es funktioniert mit ein 
paar Modifikationen auch in der realen Welt, ATTiny + 8 Leds + Steckbrett + 
Knopfzelle und schon hat man was zum schauen :-)


Das Skript find' ich eigendlich ganz gut, erinnert mich an die 
ADIM-Skripte ;-)

Compiler-Warnings sollen aber als Fehler betrachtet werden. Eine Warnung ist 
ein ernstes Problem, das der Compiler selber löst. Nur ist in der Regel die 
Interpretation des Compilers nicht jene, die der Programmierer erwartet. Was 
a priori aber nicht heißt, dass das Programm nicht funktioniert, aber wenn 
man den Compiler wechselt (gcc 3.X auf gcc 4.X) wird's lustig.

Eine Beschreibung der Maschine fehlt mir, was ist Speicher, Userspace, 
Kernelspace, welche Rolle spielt das Betriebsystem, Binärsystem ... die Basis 
eben.

Seite 22&23: Die Größenangaben sind architekturspezifisch und 
compilerabhängig, z.B."int" kann alles sein, von 8 bit (oder was auch immer 
die kleinste Speicherzelle ist) bis 256bit oder mehr (GPU). 
Test: printf("INT hat %d Bytes\n", sizeof(int)); liefert bei 4 (gcc 32-Bit 
Maschine) oder 8 (gcc 64-Bit Maschine).

Seite 25, 4.6: Big Endian/Little Endian (dass es das gibt und was es ist), 
Mantissendarstellung (die dürfte dann aber wohl zu schwierig sein) ...


Nik



>
> MfG
> Volker Dirr
>
> > Mag. Dr. Nikolaus Klepp
> > IT Consultant
> > EinnehmerstraÃ?e 14
> > A-4810 Gmunden
> > Tel.: +43 650 82 11 724
> > email: office@klepp.biz
> >        dr.klepp@gmx.at
> >
> > --
> > User mailing list User@skolelinux.de
> > subscribe/unsubscribe: https://www.skolelinux.de/mailman/listinfo/user
> > mailing list
> > Bitte beachten:
> > http://www.skolelinux.de/wiki/MailingListe



-- 

Mag. Dr. Nikolaus Klepp
IT Consultant
Einnehmerstraße 14
A-4810 Gmunden
Tel.: +43 650 82 11 724
email: office@klepp.biz
       dr.klepp@gmx.at