Re: C++
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
Reply to:
- Follow-Ups:
- Re: C++
- From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
- References:
- Re: C++
- From: "Mag. Dr. Nikolaus Klepp" <dr.klepp@gmx.at>
- Re: C++
- From: "Volker Dirr" <u6m4@timetabling.de>