mikrocontroller.net

Forum: Offtopic Was ist Codevervollständigung?


Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In einem anderen Beitrag las ich, daß man beim Programmieren nicht ohne 
"Codevervollständigung" auskäme.

Was ist das?

Ist das so wie bei Google-Eingaben, wenn man ein paar Buchstaben tippt, 
daß dann bereits mal gesuchte Wörter vorgeschlagen werden?

Ich würde sowas extrem nervig finden, es würde den Schreibfluß hemmen.


Peter

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ist das so wie bei Google-Eingaben, wenn man ein paar Buchstaben tippt,
>daß dann bereits mal gesuchte Wörter vorgeschlagen werden?

Ja. nennt sich Auto-Vervollständigen.
Kenne ich aber nur von SPS-Programm-Compilern (CoDeSys zB).
(Ich glaube MS Visual Studio hats auch)

Man gibt zB den Anfang eines Variablennamens ein, und dann kommt eine 
Auswahlliste mit Variablen, die so beginnen.
Man kann aber normal weitertippen, das Fenster wird angepasst, bzw, bei 
normaler Eingabe wieder geschlossen.

Ein Screen-Shot kann ich morgen auf Arbeit ja mal machen, wenn ich dran 
denke.

sieht etwa so aus:
http://de.wikipedia.org/wiki/Bild:Autov.png

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweise will man (wenn man eine will) eine syntaxabhängige 
Codevervollständigung. Gute stören den Tippfluß nicht.

Autor: Dr. G. Reed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne die (kontextabhängige) Codevervollständigung aus meiner Delphi 
IDE, und ich finde sie meist sehr nützlich. Variablen/Methodennamen etc 
werden als Vorschlag in einem kleinen Popup-Menü angezeigt, wennn man 
will kann man den Vorschlag übernehmen, wenn nicht, tippt man einfach 
weiter. Damit kann man wirklich recht effektiv arbeiten!


Auch kann man bestimmte Schlüsselworte definieren, die dann automatisch 
zu vollständigen Quelltext-Blöcken erweitert werden, so ähnlich wie bei 
Word das mfg zu einem 'Mit freundlichen Grüssen' umgewandelt wird.

Oft benötigte Konstrukte wie Schleifen, Standard-Dialoge etc kann man so 
sehr zeitsparend Tippen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Ich würde sowas extrem nervig finden, es würde den Schreibfluß hemmen.

Das zeigt nur, dass du es noch nie richtig benutzt hast oder nie gelernt 
hast es richtig zu benutzen. Es ist, wie angesprochen, schon sehr 
praktisch, weil man dann nicht u.U. Variablen/Klassen/Whatever-Namen 
nachschlagen muss, sondern sich einfach ein Popup aufruft, wo vorhandene 
Namen beginnend mit dem bereits Eingetippten angezeigt werden.
Übrigens kann man die meistens auch so einstellen, dass sie sich nur 
öffnen, wenn man beispielsweise Strg+Leertaste drückt (Microsoft IDEs 
bspw.).

Nötig ist es nicht, aber ziemlich praktisch, zumindest wenn sie 
(vernünftig) funktioniert.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man sich nicht irgendwelche unaussprechlichen Symbolnamen einfallen 
lässt, geht es auch sehr gut ohne. Vermutlich kommt das "Feature" aus 
der Java-Welt, wo man ohne wirklich aufgeschmissen ist - Java lässt halt 
keinen anderen Stil zu.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Wenn man sich nicht irgendwelche unaussprechlichen Symbolnamen einfallen
> lässt, geht es auch sehr gut ohne. Vermutlich kommt das "Feature" aus
> der Java-Welt, wo man ohne wirklich aufgeschmissen ist - Java lässt halt
> keinen anderen Stil zu.

Ich finde, es stört nicht, wenn man es hat. Auch wenn man es nur 
spärlich braucht. Zumindest, wenn man es richtig einrichtet und benutzt.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Das zeigt nur, dass du es noch nie richtig benutzt hast oder nie gelernt
> hast es richtig zu benutzen.

Daß ich es noch nie benutzt habe, sollte klar sein, sonst hätte ich die 
Frage ja nicht gestellt.

Um es auszuprobieren, müßte ich erstmal nen entsprechenden Editor finden 
und installieren.

Ich habe es bisher noch nie vermißt, da ich nur C (AVR, 8051) und kein 
C++ progge.
Auch mache ich gern viele kleine Module, so daß keine großen Mengen an 
globalen Variablen entstehen.
Und für die Register und Bits muß man ja eh im Datenblatt nachsehen, wie 
sie heißen und was sie bedeuten.


> Nötig ist es nicht

Das dachte ich mir.

> aber ziemlich praktisch, zumindest wenn sie
> (vernünftig) funktioniert.

Ja, da scheint es wohl kleine aber feine Unterschiede zu geben.
Warscheinlich sitzt man dann  erstmal einige Tage an der Konfiguration, 
bis alles richtig läuft.


Peter

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur ist es halt leider oft die Begründung dafür, lieber eine Minute 
weniger über einen wirklich sinnvollen Namen nachzudenken. Die 
Refaktorisierung wird's schon richten...

Autor: Kachel - Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also in AVR-Studio (ASM) habe ich dieses Feature noch nicht vermisst.

In VB6 käme ich zwar auch ohne aus, finde es aber recht nützlich und 
benutze es auch. Sehr hilfreich ist es bei der Auswahl der 
vordefinierten Konstanten, da kontextabhängig nur die zur Auswahl 
angeboten werden, die auch Sinn machen.

KH

Autor: Matthias S. (da_user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich finde es in VC#08Ex auch relativ nützlich, gerade auch für mich 
als Anfänger. Man hat nunmal nicht alle Methodennamen richtig in Kopf. 
Da hilft das doch ganz sinnvoll weiter. Und das ganze funktioniert sogar 
ohne tagelange Konfiguration (genauer: komplett ohne) einwandfrei.

Nur die "Autokorrektur" bei Visual Express machte mir bei etwas 
ungünstiger gewählten Variablennamen mal Probleme, ärgerlich dafür dass 
sie nichtmal While in while korrigiert.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt wissenschaftliche Studien die zeigen, dass Programmierer die mit 
Codevervollständigung in OO-Sprachen arbeiten, schlechteren Code 
schreiben.

Der Grund ist recht einleuchted: Die Programmierer "suchen" sich in den 
Methoden der Klassen das was gerade am besten passt. Dabei ensteht Code, 
der ständig gegen das Gesetz von Demeter verstößt.

Ein anderes (verwandtes) Problem ist, dass der Programmierer das Problem 
nicht komplett überblickt und löst, sondern Methoden verwendet, die 
irgendwie am besten passen. Das Ergebniss: Das Programm wird 
"hinprobiert" bis es irgendwie funktioniert, und nicht entwickelt.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C/C++ bieten einem eine wunderbare Möglichkeit den Überblick zu 
behalten. Man lässt nebenher einfach alle wichtigen Header offen, darin 
findet man eine gut dokumentierte Liste aller vorhandenen Funktionen... 
naja, sie sollte jedenfalls gut dokumentiert sein.

Stell ich jedesmal von neuem fest, wenn ich was in Java machen muss. Da 
hat man eine .java mit vielleicht 10k Zeilen. Ohne zusätzliche Tools 
bekommt man da nie einen Überblick.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich würde sowas extrem nervig finden, es würde den Schreibfluß hemmen.

Ich kenne es (aus Eclipse) so, dass man es per Tastenkombination 
aufrufen muss. Stört in der Form also nie, wer es nicht mag der benutzt 
es nicht, die anderen sparen unproduktive Tipparbeit.

Dagegen hat Eclipse auch eine solche Funktion, die automatisch 
eingreift (allerdings nicht immer und ohne erkennbares Muster), die 
finde ich auch ziemlich nervig.

> Ich habe es bisher noch nie vermißt, da ich nur C (AVR, 8051) und kein
> C++ progge.

Ich hätte sie auch nicht vermisst, wenn ich sie nie gekannt hätte. 
Dasselbe gilt aber auch für Syntax-Highlighting, automatische 
Compilierung, Fehler-Highlighting im Code, und und und...

Andere kommen auch ohne Computer aus und vermissen sie nicht, selbst 
nachdem sie zum dritten Mal einen Brief wegen eines Schreibfehlers neu 
anfangen mussten ;)

> Ja, da scheint es wohl kleine aber feine Unterschiede zu geben.
> Warscheinlich sitzt man dann  erstmal einige Tage an der Konfiguration,
> bis alles richtig läuft.

Die Variante, die man aufrufen muss, benötigt exakt Null Konfiguration - 
es gäbe auch nichts, was man daran umstellen könnte. Tastenkombination 
--> alle Vervollständigungen, die in diesem Kontext Sinn machen, werden 
in einem Menü angezeigt, und man kann eine auswählen die dann in den 
Code gepastet wird (oder mit ESC abbrechen).

Welche Ergänzungen genau in Frage kommen, sind je nach Kontext 
Schlüsselwörter, Variablennamen, Feldnamen, Klassennamen, ... und 
richtet sich nach den Anfangsbuchstaben, die man schon getippt hat, nach 
Syntaktisch sinnvollen Elementen in dieser Position und nach 
Zulässigkeit bzgl. des statischen Typsystems.

> Nur ist es halt leider oft die Begründung dafür, lieber eine Minute
> weniger über einen wirklich sinnvollen Namen nachzudenken. Die
> Refaktorisierung wird's schon richten...

Findest du? Meiner Erfahrung nach ist genau das Fehlen von solchen 
Tools der Grund für schlecht gewählte Namen: Hauptsache kurz, damit man 
nicht soviel Tippen muss. Mit Vervollständigung kann ich einen 
ein-Wort-Namen wählen, wenn es einen sinnvollen gibt, aber auch 5 Wörter 
aneinanderreihen, wenn es absolut keinen griffigen Namen gibt.

Jemand ohne Vervollständigung würde in dem Moment zu Abkürzungen greifen 
und alles noch schlimmer machen. Überleg dir nur mal, woher Namen wie 
"strcat" in C kommen, wenn "ConcatenateStrings" deutlich lesbarer wäre. 
Das muss dann mühsam durch Auswendiglernen wett gemacht werden.

> Es gibt wissenschaftliche Studien die zeigen, dass Programmierer die mit
> Codevervollständigung in OO-Sprachen arbeiten, schlechteren Code
> schreiben.

Würd mich interessieren. Quelle?

> C/C++ bieten einem eine wunderbare Möglichkeit den Überblick zu
> behalten. Man lässt nebenher einfach alle wichtigen Header offen, darin
> findet man eine gut dokumentierte Liste aller vorhandenen Funktionen...
> naja, sie sollte jedenfalls gut dokumentiert sein.

Das ist doch genau die Liste, die ich per Tastenkombination aufrufen 
kann, sogar mit Doku. Nur dass ich mit meiner Variante nur die passenden 
gezeigt bekomme und auch per Tastendruck den Namen in den Code pasten 
kann.

> Stell ich jedesmal von neuem fest, wenn ich was in Java machen muss. Da
> hat man eine .java mit vielleicht 10k Zeilen. Ohne zusätzliche Tools
> bekommt man da nie einen Überblick.

Könnte ich genauso über C sagen... nur dass da meistens noch Gefrickel 
mit Präprozessor-Makros drin ist, an dem sogar die besten Tools 
versagen.

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Vermutlich kommt das "Feature" aus
> der Java-Welt

Nein. Man sollte seine Vorurteile gegen Sprachen nicht immer und überall 
ausleben. Die ersten Ansätze gab es in separaten "Programmiereditoren" 
irgendwann in den 70ern. Wesentlich später gab es das für die breite 
Masse in Borland IDEs auf dem PC als Code Completion. Lange bevor es 
Java gab.

Heute macht das jede moderne IDE nebenbei, egal für welche Sprache. Z.B. 
die Microsoft-IDEs, dort nennt Microsoft das überheblich IntelliSense. 
Das AVR Studio das nicht kann, ist übrigens ein Zeichen dafür, dass die 
IDE eher zur Unterklasse gehört.

Mir ist es allerdings so ein bisschen ein Rätsel, wie man heutzutage 
Programmieren kann und noch nie von so einem Feature gehört hat. Das ist 
in IDEs genauso Standard wie der Menüeintrag "File->Exit" (oder 
"Datei->Beenden" für die Deutschtümler).

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man braucht keine IDE um zu programmieren, viele Leute wissen ja 
nichtmal was da unten drunter eigentlich abläuft. Da geht man halt 
irgendwo auf "build project" und raus kommt was ausführbares.

Symbolnamen sollten, wenn sie nicht nur sehr lokal sind (zB. lokale 
Variablen in kleinen Funktionen), einer gewissen Systematik folgen und 
dabei nicht zu kompliziert sein. Das sorgt ganz einfach dafür, dass man 
als Programmierer den Überblick behält.
Den braucht man nunmal, das Nachschlagen von Funktionsnamen nimmt einem 
zwar eine Vervollständigung ab, aber die sagt einem nicht wie man das 
Programm am besten strukturiert.

Das Argument gegen C kann ich nicht nachvollziehen. Man brauchst grad 
mal 3 Zeilen Makrocode in einem Header, sonst kannst du doch vollständig 
drauf verzichten. Außerdem ist es in C ja gerade nicht so wie in Java, 
da hat man einen Header und da steht alles drinnen. Sollte es zumindest, 
wer C kann, kann nicht zwangsweise gutes und sauberes C.


PS Lass mich raten - Delphi hatte es zuerst? ;)

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man braucht keine IDE um zu programmieren, viele Leute wissen ja
> nichtmal was da unten drunter eigentlich abläuft. Da geht man halt
> irgendwo auf "build project" und raus kommt was ausführbares.

Eben. Fortschritt bedeutet, mehr Sachen zu machen, ohne darüber 
nachdenken zu müssen.

> Symbolnamen sollten, wenn sie nicht nur sehr lokal sind (zB. lokale
> Variablen in kleinen Funktionen), einer gewissen Systematik folgen und
> dabei nicht zu kompliziert sein. Das sorgt ganz einfach dafür, dass man
> als Programmierer den Überblick behält.

Selbstverständlich. Auto-Vervollständigung nimmt dir Tipparbeit ab, 
nicht die klare Struktur. Die musst du immer noch selbst schaffen. Es 
kann aber zur Schaffung klarer Strukturen helfen, wenn diese ansonsten 
viel Tipparbeit benötigen, wie z.B. beim (fiktiven) Funktionsnamen 
"ConcatenateStrings".

> Den braucht man nunmal, das Nachschlagen von Funktionsnamen nimmt einem
> zwar eine Vervollständigung ab, aber die sagt einem nicht wie man das
> Programm am besten strukturiert.

Nein, aber dafür war sie auch nie gedacht. Vervollständigung ist ein 
Werkzeug für eine ganz bestimmte, eng begrenzte Aufgabe.

> Das Argument gegen C kann ich nicht nachvollziehen. Man brauchst grad
> mal 3 Zeilen Makrocode in einem Header, sonst kannst du doch vollständig
> drauf verzichten.

Die Bemerkung über Makros war auf "Fremdcode" bezogen, der oft viele 
Makros enthält. Ist hier als Thema wohl eher nebensächlich.

> Außerdem ist es in C ja gerade nicht so wie in Java,
> da hat man einen Header und da steht alles drinnen. Sollte es zumindest,
> wer C kann, kann nicht zwangsweise gutes und sauberes C.

Nehmen wir mal sauberes C an, dann hast du vollkommen Recht: Ich schlage 
den Header auf, und da steht alles.

Allerdings unterschätzt du um Längen die Fähigkeiten, die vernünftige 
Tools bieten. In Java gibt es keine separate Code-Datei (Header), in dem 
alle Methoden einer Klasse gelistet sind. Warum auch - im .java Code 
steht ja die nötige Information drin, und per Knopfdruck kann ich mir 
daraus eine Übersicht à la Header erzeugen lassen - z.B. mit Kommentaren 
und Prototypen, aber ohne Details. Oder wie detailliert auch immer. 
Manche IDEs warten noch nicht mal auf einen Befehl dazu, sondern 
präsentieren eine immer aktuelle Übersicht in einem Nebenfenster. 
(aktualisierung automatisch bei jeder Änderung im Code)

Ein separater Header als Werkzeug zur Übersichtlichkeit war traditionell 
nötig, gerade weil es die modernen Tools (wie z.B. Vervollständigung, 
Übersicht, usw.) damals nicht gab. Heute ist es nur noch Redundanz im 
Quellcode, weil C-File und H-File bei Änderungen synchron gehalten 
werden müssen.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Java brauchst du halt ein extra Tool dafür, bei C nicht. Die 
einfache Lösung ist häufig die bessere ;).

Tools die dir aus C-Code zB. eine fertige Dokumentation erzeugen, gibt 
es auch (zB. Doxygen).

> Eben. Fortschritt bedeutet, mehr Sachen zu machen, ohne darüber
> nachdenken zu müssen.

Nicht unbeding. Die ganzen Javaprogrammierer können dir zwar irgendein 
08/15 Programm zusammenzimmern, aber wissen eigentlich nicht was die 
Klassen die sie benutzen nun genau machen. Das ist wohl eines der 
größten Probleme der Javaprogrammierer.

Mehr Sachen machen zu können ohne drüber nachdenken zu müssen ist gut 
für RAD - aber hauptsächlich nur dort. Der Mensch geht immer den Weg des 
geringsten Widerstands, und wenn einem die IDE die Tipparbeit abnimmt, 
kommen eben schnell unleserliche Symbolnamen raus, und man hat keinen 
Überblick mehr über die Funktionen, die einem eine Klasse anbietet 
(Überblick hat man im Kopf, nicht vor den Augen).

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber wissen eigentlich nicht was die Klassen die sie benutzen nun genau machen.

Ich muß ja nun nicht ganz genau wissen was JTextField intern macht...

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei Java brauchst du halt ein extra Tool dafür, bei C nicht. Die
> einfache Lösung ist häufig die bessere ;).

Bei C steckst du aber Fleißarbeit rein, die ist wesentlich teurer.

> Tools die dir aus C-Code zB. eine fertige Dokumentation erzeugen, gibt
> es auch (zB. Doxygen).

Klar, das sollte ja auch weniger ein Argument gegen C sein als gegen 
veraltete Tools.

> Nicht unbeding. Die ganzen Javaprogrammierer können dir zwar irgendein
> 08/15 Programm zusammenzimmern, aber wissen eigentlich nicht was die
> Klassen die sie benutzen nun genau machen. Das ist wohl eines der
> größten Probleme der Javaprogrammierer.

Da bist du aber sehr optimistisch, wenn du glaubst, dass es bei C anders 
aussieht :)

> Mehr Sachen machen zu können ohne drüber nachdenken zu müssen ist gut
> für RAD - aber hauptsächlich nur dort.

Du machst Täglich an deinem Computer erstaunliche Mengen an Aktionen in 
kürzester Zeit ohne darüber nachzudenken:
- Daten auf der Festplatte anordnen, so dass man alles wiederfindet 
(Dateisystem)
- Datenübertragung über mehrere Zwischenstationen zwecks Kommunikation 
mit anderen Menschen (Chat, Email)
- Dekompression von hoch komprimierten Musikdaten zwecks Wiedergabe 
(MP3-Player)

Jetzt stell dir mal diese Aktionen in ihre Einzelschritte aufgebrochen. 
Nur so als Beispiel: Wie wäre es, wenn du per extra-Tool die MP3-Dateien 
erst dekomprimieren müsstest, bevor du sie im Player öffnen kannst? Wenn 
du die Übertragungsroute für eine Email von Hand bestimmen und eingeben 
müsstest? Wenn du deine Dateien ohne Verzeichnisstruktur verwalten 
müsstest?

Dann hast du in etwa die Situation, in der C nur mit einem Editor und 
einem Compiler programmiert wird.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Und für die Register und Bits muß man ja eh im Datenblatt nachsehen, wie
> sie heißen und was sie bedeuten.

Da gefällt mir die Kombination aus Eclipse und den Headern des MSPGCC. 
Da sind im Kommentar immer schön die Bits erklärt und haben sinvolle 
Makro-Namen. Somit spart man sich das lange Suchen im Datenblatt. Oft 
zumindest.
Eclipse zeigt ja bei der Code-vervollständigung die Kommentare mit an, 
sehr praktisch.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Tools die dir aus C-Code zB. eine fertige Dokumentation erzeugen, gibt
> es auch (zB. Doxygen).

Für Java gibts auch Javadoc.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doxygen versteht sich auch auf Java ;)

Klar sind ein paar Automatisierungen nicht schlecht (zB. Betriebssysteme 
und Compiler), aber andere wirken sich halt auch negativ aus. Die 
meisten Hobbyprogramme sind formal unter aller Sau, und werden oft mit 
IDEs entwickelt die genau das verhindern sollen - offensichtlich 
funktioniert es nicht.

Mit genug Disziplin kann man Autovervollständigung auch sinnvoll 
einsetzen, ok. Aber es verleitet halt auch zur Schludigkeit. Jemandem 
der nur mal nebenbei ein bisschen programmieren möchte, empfielt man 
auch kein C/C++.


Und das es auch anders geht als "build project", zeigen zB. Makefiles. 
Die nehmen einem viel Arbeit ab und man hat trotzdem die volle 
Kontrolle.

Autor: Unverschämtheit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>in IDEs genauso Standard wie der Menüeintrag "File->Exit" (oder
>"Datei->Beenden" für die Deutschtümler).

Was ist an der deutschen Sprache so schlecht?
Schämst Du Dich deswegen?

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab vor einer Weile mal jemanden aus Österreich gefragt, in welcher 
Sprache er seinen Code kommentiert... Antwort: "manchmal Dialekt, aber 
meistens Deutsch"...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die meisten IDEs und Leute sprechen allerdings Englisch. Das hat nichts 
mit sich schämen o.ä. zu tun.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Jaeger wrote:
> Unverschämtheit wrote:
>> Was ist an der deutschen Sprache so schlecht?
>> Schämst Du Dich deswegen?
>
> Nein, ich schäme mich nur für Nazi-Wichser.

Ich bin weder links noch rechts (quasi farblos, aber auch grad mal 
volljährig) und mich regt nichts mehr auf als Anglizismen, wo sie nicht 
nötig sind:

* Die Sendeleistung hochgeswitcht
* Der Fader und die Group Outputs
* Den Quelltext ge-up-loaded, up-ge-loaded
* Die Datenbank ge-queriet
* Die Session des Users auf der Website cancellen
* Den Computer rebooten und "uppen"
* ...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D'accord. Sehe ich auch so  (deshalb eine nichtenglische Einleitung).

Allerdings ist eingedeutschte Software oftmals eine reichlich 
fragwürdige Angelegenheit, ich verwende beispielsweise bewusst nicht 
die deutschsprachigen Compiler von Microsoft. Bei denen sind -eigentlich 
konsequent- auch die Fehlermeldungen übersetzt, aber so, daß sie 
komplett unverständlich bleiben. Um sie zu verstehen, muss ich sie erst 
ins Englische übersetzen, und zwar möglichst wörtlich ...

Etwas Anglizismen-Ex täte allerdings den meisten gut.
Nur: Wenn eindeutschen, dann richtig.

Eine Maus wird bei IBM als "serial pointing device" bezeichnet. Und das 
wird als "serielle Zeigereinheit" übersetzt. Grandios, nicht?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf die Gefahr, noch weiter abzuschweifen :-)

Rufus t. Firefly wrote:
> Allerdings ist eingedeutschte Software oftmals eine reichlich
> fragwürdige Angelegenheit, ich verwende beispielsweise bewusst /nicht/
> die deutschsprachigen Compiler von Microsoft.
Naja, das geht auch anders (GCC etc.). Problem ist (unter Anderem 
übrigens auch mit Windoof Vista), dass die Leute m.W.n. die 
Übersetzungen zum ersten Mal ohne Mithilfe von Muttersprachlern erledigt 
haben. Daher kommen dann auch so Ungetüme wie 
"Windows-Datei-Ausführungsverhinderung".

> Etwas Anglizismen-Ex täte allerdings den meisten gut.
> Nur: Wenn eindeutschen, dann richtig.
Jubb.

> Eine Maus wird bei IBM als "serial pointing device" bezeichnet. Und das
> wird als "serielle Zeigereinheit" übersetzt. Grandios, nicht?
Aber letztlich immer noch richtig :-) Was ist denn technisch wohl 
korrekter? Eine "Maus" oder eine "Zeigeeinheit" (ok, Zeigegerät wär 
evtl. einfacher gewesen)...? duck

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:

> Da hat man eine .java mit vielleicht 10k Zeilen. Ohne zusätzliche Tools
> bekommt man da nie einen Überblick.

Ich würde sage, da ist dann schon vor längerer Zeit was schief gelaufen. 
Solche Codewürste maximieren nur die Suchzeiten.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Man braucht keine IDE um zu programmieren, viele Leute wissen ja
> nichtmal was da unten drunter eigentlich abläuft. Da geht man halt
> irgendwo auf "build project" und raus kommt was ausführbares.

Man braucht auch keinen Compiler. Den versteht nämlich auch fast keiner.

Ein einfacher Hex-Editor und eine Idiotenpappe des Prozessors (für den 
Anfang) reicht völlig aus. :P

> Nicht unbeding. Die ganzen Javaprogrammierer können dir zwar irgendein
> 08/15 Programm zusammenzimmern, aber wissen eigentlich nicht was die
> Klassen die sie benutzen nun genau machen. Das ist wohl eines der
> größten Probleme der Javaprogrammierer.

Und ich dachte, deren größtes Problem sei Mundgeruch...

Autor: Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu, was du hier manchmal für Blödsinn schreibst...

Peter Dannegger, wenn man im Visual Studio große Projekte realisiert, 
kann es schon recht nützlich sein. Vorallem beim Zugriff auf 
Klassenvariablen oder Methoden.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> > Eine Maus wird bei IBM als "serial pointing device" bezeichnet. Und das
> > wird als "serielle Zeigereinheit" übersetzt. Grandios, nicht?

> Aber letztlich immer noch richtig :-) Was ist denn technisch wohl
> korrekter? Eine "Maus" oder eine "Zeigeeinheit" (ok, Zeigegerät wär
> evtl. einfacher gewesen)...?

"Zeigeeinheit" wäre schon besser; Du hast das 'r' übersehen.
IBM nennt das "Zeigereinheit".

"Zeigegerät", das ginge ja fast schon.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu wrote:
> I_ H. wrote:
>
>> Da hat man eine .java mit vielleicht 10k Zeilen. Ohne zusätzliche Tools
>> bekommt man da nie einen Überblick.
>
> Ich würde sage, da ist dann schon vor längerer Zeit was schief gelaufen.
> Solche Codewürste maximieren nur die Suchzeiten.

Solche großen Dateien sind bei größeren Projekten leider die Regel. Und 
in Java kannst du nichtmal wirklich was dagegen tun, in C/C++ könntest 
du, ist aber unsauber.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Und
> in Java kannst du nichtmal wirklich was dagegen tun,

Wie wärs denn mit einem ordentlichen Design? Eine Klasse mit 100 
Methoden ist eine Perversion der objektorientierten Programmierung.

> in C/C++ könntestdu, ist aber unsauber.

Das halte ich für ein Gerücht. Keiner hindert einen daran, jede Methode 
in einer einzelnen .cpp-Datei zu implementieren. -- Aber das 
Designargument gilt natürlich auch hier...

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bzgl. Maus, Zeigegerät, etc.

Ich glaube es war Siemens, die den englischen Begriff "mouse" anfangs 
mit "Rollkugelmanipulator" übersetzten...

Ah ja, hier stehts:
> Worum handelt es sich bei einem Rollkugelmanipulator?
> Der Begriff stammt aus dem Beginn des Computer-Zeitalters.
> Damals war es u.a. der Firma "Siemens" ein wichtiges Anliegen,
> englisches Fachvokabular zu vermeiden – und alles gnadenlos
> einzudeutschen. Ein Rollkugelmanipulator war nichts anderes,
> als eine Computer-Maus.
Quelle: http://tv.orf.at/groups/show/pool/fragen_16_3/story

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
100 Klassen sind auch 'ne Perversion der objektorientierten 
Programmierung. Jedesmal wenn ich an Java GUIs denken muss, überkommt 
mich ein spontaner Brechreiz. Und irgendwie musst du deinen Code nunmal 
unterbringen.

Eine C++ Klasse über mehrere cc sources zu implementieren geht zwar, ist 
aber... ähm... "ungewöhnlich".
Etwas sauberer wäre es das mit verschachtelten Klassen zu 
implementieren, und die dann in getrennten sources zu implementieren. 
Aber auch das ist nicht schön, und in Java hilft dir das zB. garnicht 
weiter.

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In einem anderen Beitrag las ich, daß man beim Programmieren nicht
>ohne "Codevervollständigung" auskäme.

>Was ist das?

Hier sieht man schön, dass dieser Thread wieder nur zur 
Selbstprofilierung dienen soll. Frei nach dem Motto: "Ich kann 
programmieren und hab' Peilung, ihr nicht."

Autor: Bereits Fort (Firma: D.ade) (bereitsfort)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ein Rollkugelmanipulator

in die Kategorie wären dan auch ein trackball einzuordnen.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> 100 Klassen sind auch 'ne Perversion der objektorientierten
> Programmierung. Jedesmal wenn ich an Java GUIs denken muss, überkommt
> mich ein spontaner Brechreiz. Und irgendwie musst du deinen Code nunmal
> unterbringen.

Das geht sogar in Java: Man teilt die Klasse in mehrere und leitet davon 
dann (linear) die endgültige Klasse ab.

> Eine C++ Klasse über mehrere cc sources zu implementieren geht zwar, ist
> aber... ähm... "ungewöhnlich".

Ist es mit nichten. Das mache ich so, seit ich C++ programmiere.

Bei C war es sogar ein Entwurfsziel, Module leicht aufteilen zu können 
und C++ hat an den Möglichkeiten dazu nichts eingebüßt.

> Aber auch das ist nicht schön, und in Java hilft dir das zB. garnicht
> weiter.

Daß Java keine Mehrfachvererbung zuläßt, ist zwar etwas hinderlich, aber 
kein Ausschlußgrund, die Sourcefiles überschaubar zu halten.

Woran es letztlich nur mangelt, ist Phantasie und Abstraktionsgabe der 
Entwickler in der Entwurfsphase.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu wrote:
> I_ H. wrote:
> Das geht sogar in Java: Man teilt die Klasse in mehrere und leitet davon
> dann (linear) die endgültige Klasse ab.

AUA! Ja, das geht... theoretisch. Hier zeigt sich ein leider 
alltägliches Problem... das ist nämlich verdammt langsam. Wenn du 
konsequent solche Sachen machst, verschenkst du einen riesenhaufen 
Performance.

Die meisten Programmierer haben leider keine Ahnung wieviel Leistung sie 
mit solchen Sachen verballern, weil sie keine Ahnung haben was unten 
drunter vorgeht. Und dann wundern sich die Leute, dass vista 
Mindestanforderungen hat, mit denen man vor 10 Jahren in der Top500 
gestanden hätte.


> Ist es mit nichten. Das mache ich so, seit ich C++ programmiere.

In größeren Projekten hab ich sowas noch nicht beobachtet. Und kleine 
Hobbyprojekte sind nunmal ein anderes Gebiet, da kann man fast alles 
machen.


> Bei C war es sogar ein Entwurfsziel, Module leicht aufteilen zu können
> und C++ hat an den Möglichkeiten dazu nichts eingebüßt.

Nur kennt C keine Klassen, um die es gerade geht. C programmieren ist 
eine ganz andere Philosophie als C++ programmieren.

> Daß Java keine Mehrfachvererbung zuläßt, ist zwar etwas hinderlich, aber
> kein Ausschlußgrund, die Sourcefiles überschaubar zu halten.
>
> Woran es letztlich nur mangelt, ist Phantasie und Abstraktionsgabe der
> Entwickler in der Entwurfsphase.

Siehe oben. Woran es wirklich mangelt sind Entwickler, die wissen was 
sie kostenlos machen können, und was nicht (kostenlos = kostet zur 
Laufzeit keine Performance). Außerdem mangelt es an Entwicklern, die 
sich durch große Sources durchfinden.
Vermutlich verstehen viele Javaprogrammierer gerade desswegen die 
Eleganz von C++ Templates nicht. Die sind nämlich wirklich kostenlos.

Die 100'000 Klassen sind in Java leider gewollt, weil die 
Winkeladvokaten (Untergruppe der Akademiker) das damals ganz toll 
fanden.
Ein paar davon fanden es damals auch toll neue Standards für FPU 
Berechnungen zu entwickeln, so dass CPUs das nicht in Hardware rechnen 
konnten.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein paar davon fanden es damals auch toll neue Standards für FPU
> Berechnungen zu entwickeln, so dass CPUs das nicht in Hardware rechnen
> konnten.

Macht schon Sinn, von den x86-FPUs rechnet jede ein bisschen anders 
(Intel vs AMD usw.). Kommt nicht so gut in der Netzwerkspiel-Entwicklung 
z.B.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, es gibt IEEE Standards die die Genauigkeit vorschreiben, und die 
wird auch eingehalten. Beim berühmten FDIV-Bug im Pentium1 wurde der 
Standard zB. nicht eingehalten.

-> http://en.wikipedia.org/wiki/IEEE_754

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann gibt es wohl auch neuere CPUs mit Fehlern, ein Spieleentwickler hat 
mal erzählt das er irgendwelche FPUs extra behandeln musste weil sonst 
das Spiel desynchronisiert hat. Nachweis kann ich leider keinen mehr 
bringen...

Autor: na sowas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly (rufus) (Moderator) wrote:

> Eine Maus wird bei IBM als "serial pointing device" bezeichnet. Und das
> wird als "serielle Zeigereinheit" übersetzt. Grandios, nicht?

Also ich habe für einen älteren zweit bzw. dritt PC nach ein 
Rollkugeleingabegerät zur Hand. Dies nutze ich dann auf meiner 
Rollkugeleingabegeräte-Unterlegematte. :)

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rollst du noch oder strahlst du schon ;)

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So direkt kann ich mir der Aussage jetzt nix anfangen. Man muss 
inzwischen aufpassen, woher man seine Zeit bezieht.

Früher hat man dafür gern den TSC genommen, der gibt die Zahl der seit 
Systemstart vergangenen CPU Takte zurück und ist damit der genaueste 
Timer den es im System gibt. Man misst einfach kurz die Taktrate der CPU 
und dann kann man immer auf die Zeit zurückrechnen.

Dann kamen Stromspartechniken wie CnQ und SpeedStep auf den Desktop. 
Damit läuft der TSC nicht immer gleich schnell. Ältere Programme haben 
damit ziemlich Probleme, manche Spiele liefen wirklich je nach CPU Takt 
unterschiedlich schnell, oder konsequent zu schnell (Taktrate wird am 
Anfang kurz ermittelt, wegen der hohen Last wird die CPU etwas später 
hochgetaktet).
Manche CPUs (zB. Transmeta Efficeon) lassen den TSC desswegen immer mit 
der gleichen Geschwindigkeit laufen, unabhängig vom CPU Takt.

Das nächste Problem kam mit Dualcores auf. Die TSCs laufen auf den 
einzelnen Kernen nicht synchron (eine wurde früher initializiert als die 
andere), und das OS verschiebt einen Task häufer zwischen den CPUs. Man 
bekommt also immermal andere Werte, und die Werte können von einem 
Auslesen auf's Nächste auch mal kleiner werden.


Heute kann man mit dem TSC desswegen nix mehr anfangen, zumindest nicht 
bei längeren Sachen. Der Zugriff auf den TSC ist halt kinderleicht und 
er ist ab 686 (Pentium2, glaub AMD K5 und Cyrix M2) immer vorhanden.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> AUA! Ja, das geht... theoretisch. Hier zeigt sich ein leider
> alltägliches Problem... das ist nämlich verdammt langsam. Wenn du
> konsequent solche Sachen machst, verschenkst du einen riesenhaufen
> Performance.

100% ACK (um mal einen Anglizismus zu verwenden...)

Das ist leider eine gängige Lösung in Java (und überhaupt im modernen 
Programmieren), mit Laufzeit-Datenstrukturen die Probleme beim Managen 
von großem Code zu erschlagen. Leider ist das blanke C/C++ Programmieren 
zwar "schneller" in diesem engen Sinne, löst dafür die 
Code-Management-Probleme auch nicht so gut. Das ist einer der Gründe, 
warum ich so sehr für gute Tools plädiere (Automatische Ergänzung ist da 
nur eines von vielen).

> Vermutlich verstehen viele Javaprogrammierer gerade desswegen die
> Eleganz von C++ Templates nicht. Die sind nämlich wirklich kostenlos.

Jein. Man muss wieder wissen, was man genau macht. Templates können auch 
dazu verleiten, große Mengen ähnlichen Codes unnötig zu erzeugen, und 
großer Code ist auch langsam (-> Instruction Cache Misses).

> Ein paar davon fanden es damals auch toll neue Standards für FPU
> Berechnungen zu entwickeln, so dass CPUs das nicht in Hardware rechnen
> konnten.

Ohne genau zu wissen, auf welchen Teil der Java-Spec du damit 
ansprichst:

Das hatte glaub ich vor allem damit zu tun, die FPU-Berechnungen 
systemübergreifend zu standardisieren. Ziel war es, dass ein 
Java-Programm auf allen Systemen mit minimalen Portierungsaufwand läuft, 
und FPU-Berechnungen gehören nun mal dazu. Wenn es schon einen Standard 
gegeben hätte, hätte man sicher keinen neuen erfunden, aber es gab nun 
mal nur einen halben (IEEE 754, aber der lässt halt ewig viele Optionen 
offen, z.B. was das Runden angeht).

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> So direkt kann ich mir der Aussage jetzt nix anfangen. Man muss
> inzwischen aufpassen, woher man seine Zeit bezieht.

Das "desynchronisieren" bezog sich nicht auf Zeitbestimmung, sondern auf 
aufgeschaukelte Unterschiede in den FPU-Berechnungen auf verschiedenen 
Rechnern, auf denen das Spiel lief. Gerade Rundungsfehler sind ein guter 
Kandidat für sowas. Beispiel: der eine Rechner rundet immer nach 
-Unendlich, der andere immer zur Null hin, also gibt es verschiedene 
Ergebnisse bei negativen Werten. Da unterscheidet sich nur das letzte 
Bit, merkt man kaum, aber wenn damit weitergerechnet wird, dann gibt es 
Folgefehler, und irgendwann sind sich die Rechner uneinig über den 
Spielzustand.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tools helfen halt auch nur bedingt. Eigentlich ist Abstraktion von 
Assembler ja auch 'ne tolle Sache, wenn's aber dazu führt, dass die 
Programierer keine Ahnung haben wie langsam und unnötig das ist, was sie 
da verbrochen haben...

Es ist, wie es immer ist. Für Leute, die den Hintergrund gut kennen und 
auch ohne auskämen, ist es 'ne tolle Sache. Wer aber von Anfang an mit 
solchen Sachen loslegt (egal ob abstrakte Sprachen oder Managementtools) 
wird nur verhätschelt.


Die Idee bei Java war wirklich, dass Floatoperationen über alle 
Plattformen hinweg exakt die selben Ergebnisse liefern. Wenn die 
Performance dabei aber auf <10% sinkt, ist das der Sache einfach nicht 
dienlich, wie toll es in der Theorie auch sein mag. Desswegen ist es 
auch wieder rausgeflogen.


Das hier ist übrigens recht interessant in Bezug auf Java und Floats: 
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Uhu Uhuhu wrote:
> AUA! Ja, das geht... theoretisch. Hier zeigt sich ein leider
> alltägliches Problem... das ist nämlich verdammt langsam. Wenn du
> konsequent solche Sachen machst, verschenkst du einen riesenhaufen
> Performance.

Na ja, ich bleibe dabei: Solchen Mülleimerklassen zu schreiben läßt auf 
nicht vorhandenes Design schließen.

>> Ist es mit nichten. Das mache ich so, seit ich C++ programmiere.
>
> In größeren Projekten hab ich sowas noch nicht beobachtet. Und kleine
> Hobbyprojekte sind nunmal ein anderes Gebiet, da kann man fast alles
> machen.

Ich schreibe keine Hobbyprojekte in C++...

>> Bei C war es sogar ein Entwurfsziel, Module leicht aufteilen zu können
>> und C++ hat an den Möglichkeiten dazu nichts eingebüßt.
>
> Nur kennt C keine Klassen, um die es gerade geht.

Na ja, man kann auch C-Code mit den Techniken der objektorientierten 
Programmierung strukturieren. Dazu braucht man weder Klassen, noch 
C++...

> C programmieren ist
> eine ganz andere Philosophie als C++ programmieren.

Üblicherweise ja.

> Siehe oben. Woran es wirklich mangelt sind Entwickler, die wissen was
> sie kostenlos machen können, und was nicht (kostenlos = kostet zur
> Laufzeit keine Performance).

Das ist bei Sprachen wie Java, oder auch Basic nicht ganz leicht heraus 
zu bekommen. Bei C und C++ reicht es aus, den Maschinencode anzusehen.

> Außerdem mangelt es an Entwicklern, die sich durch große Sources
> durchfinden.

Na ja. Wenn das ein Ersatz für ordentlich strukturierte Großprojekte 
sein soll, dann gute Nacht...

> Vermutlich verstehen viele Javaprogrammierer gerade desswegen die
> Eleganz von C++ Templates nicht. Die sind nämlich wirklich kostenlos.

Der Ansatz von Java ist abstrakt, während C eigentlich nur ein 
Highlevel-Assembler ist und C++ der Versuch, da Abstrakte Struturen 
drüberszstülpen.

Daß Templates "wirklich kostenlos" sind, stimmt nicht. Man kann damit 
ganz beachtliche Halden von Maschinencode produzieren...

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Große Klassen haben nix mit Mülleimercode zu tun. Eine große Klasse 
macht oft auch komplizierte Dinge. Wenn du dich da nicht durchfindest, 
ist das doch dein Problem.

Objektorientierte Strukturierung kannst du in C nicht machen, dafür 
fehlen dir zB. schon abgetrennte Namespaces. Klar kannst du Klassen 
nachbilden, aber das mit den Namespaces geht nicht so einfach. Und 
Kapselung ist nunmal eine der wesentlichen Eigenschaften von OO.

Ein guter Programmierer sollte auch wissen, was unter der Haube vorgeht. 
Und mit ein bisschen Hintergrundwissen kannst man die Laufzeit auch grob 
abschätzen. Vererbung ist in Java zB. recht langsam (in C++ auch). 
Solche grundlegenden Dinge muss man einfach wissen.


Mit Templates kann man auch Mist bauen, ja. Aber bei den heutigen L2 
Caches macht ein bisschen mehr Code nix aus. Mit -O3 erzeugt der GCC 
auch größeren Code als mit -O2, der ist aber trotzdem häufig schneller.

Schau dir doch mal an wo in der STL überall Funktoren verwendet werden. 
Die Dinger sind abstrakt und dank Templates kostet es keine zusätzliche 
Zeit.
Man kann mit Templates und unrolling sogar Code schreiben, der schneller 
ist als übliches C.


Wo C++ nicht abstrakt sein soll, verschließt sich mir. Java ist 
minimalistischer, das hat aber nicht unbedingt was mit Abstraktion zu 
tun.
Mit einem Makroassembler hat C inzwischen auch nicht mehr viel zu tun.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Große Klassen haben nix mit Mülleimercode zu tun. Eine große Klasse
> macht oft auch komplizierte Dinge.

Große Problem lassen sich üblicherweise in kleinere zerlegen.

> Wenn du dich da nicht durchfindest, ist das doch dein Problem.

Wie könnte es anders sein... ein echter I_ H. mal wieder...

> Objektorientierte Strukturierung kannst du in C nicht machen, dafür
> fehlen dir zB. schon abgetrennte Namespaces. Klar kannst du Klassen
> nachbilden, aber das mit den Namespaces geht nicht so einfach. Und
> Kapselung ist nunmal eine der wesentlichen Eigenschaften von OO.

Aua aua, Namespaces sind syntaktischer Zucker, sonst nichts. Da wo der 
Compiler keine zur Verfügung stellt, da macht man sie sich eben selbst, 
mit etwas Disziplin, indem man Präfixe definiert. Das haben sogar die 
alten Assemblerfüchse vor 40 Jahren schon gewußt...

> Ein guter Programmierer sollte auch wissen, was unter der Haube vorgeht.
> Und mit ein bisschen Hintergrundwissen kannst man die Laufzeit auch grob
> abschätzen. Vererbung ist in Java zB. recht langsam (in C++ auch).
> Solche grundlegenden Dinge muss man einfach wissen.

Ja eben. Z.B. bei Namespaces...

> Mit Templates kann man auch Mist bauen, ja. Aber bei den heutigen L2
> Caches macht ein bisschen mehr Code nix aus. Mit -O3 erzeugt der GCC
> auch größeren Code als mit -O2, der ist aber trotzdem häufig schneller.

Na ja, wenn du ein Template mi 10 Memberfunktionen schreibst und das mit 
50 verschiedenen Datentypen anwendest, dann hast du schlappe 500 
Funktionen und wenn du dich blöd anstellst, kriegst du damit jeden Cache 
zu.

> Schau dir doch mal an wo in der STL überall Funktoren verwendet werden.

Deswegen ist Code, der STL verwendet ja auch so ziemlich undebugbar... 
und wenn du dann noch die Compilerfehlermeldungen dazunimmst...

> Die Dinger sind abstrakt und dank Templates kostet es keine zusätzliche
> Zeit.

Das ist ein Irrglaube - Speicher gegen Zeit.

> Man kann mit Templates und unrolling sogar Code schreiben, der schneller
> ist als übliches C.

Na ja, in C ernährt sich das Eichhörnchen eben etwas mühsamer, aber ein 
geschickter Copy&Paster kriegt Unrolling auch zu Fuß hin...

> Wo C++ nicht abstrakt sein soll, verschließt sich mir.

C++ ist im wesentlichen - nicht ganz - eine Obermenge von C. Du mußt 
keine Klassen und keine Namespaces verwenden...

> Java ist minimalistischer, das hat aber nicht unbedingt was mit
> Abstraktion zu tun.

Java läuft auf einer abstrakten Maschine, absichlich abgehoben von der 
Hardware. Wie die implementiert ist, das kann man bestenfalls 
irgendwelchen Hintergrundbeschreibungen entnehmen; mit einem 
Assemblerdebugger ist es kaum zu rekonstruieren und für den echten 
Abstraktionsfuzzi sind Implementierungsdetails unterhalb der Sprachebene 
doch sowieso äh bäh.

Ursprünglich war Java auch nicht für irgend welche komplexen 
Applikationen gedacht, sondern für kleine Päckchen, die übers Web 
verschickt werden.

> Mit einem Makroassembler hat C inzwischen auch nicht mehr viel zu tun.

Von Macroassembler habe ich auch nicht gesprochen - einem Macro-ASM kann 
der CPP nämlich nicht im entfernten das Wasser reichen.

C ist vom Maschinencode, der daraus erzeugt wird, nicht weit entfernt - 
deswegen Superassmbler und mit etwas Übung kann man die C und 
C++-Maschinencode-Konstukte auch ganz gut identifizieren und dem 
Quelltext zuordnen; habe ich lange genug gemacht...

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar lassen sich große Probleme in kleinere zerlegen. Aber nicht immer 
geht das elegant, und wenn doch brauchst du halt 'ne neue Klasse. 
Entweder machst du das sauber als Subklasse (-> im der selben Datei) 
oder du definierst noch eine Zusatzklasse, womit der Namespace noch ein 
Mitglied bekommt.

Du kannst es drehen wie du willst, irgendwas wird mit größerem Code 
immer komplizierter. Entweder werden die Funktionen länger, oder du hast 
mehr Klassen. Du willst das doch wohl jetzt nicht ernsthaft in Frage 
stellen, oder? Also was soll der Quatsch? So'ne Altklugen Äußerungen 
bringen rein garnix.

Namespaces dienen der Kapselung. Damit kannst du schon ein bissel mehr 
machen als den einen einzubinden, und den anderen nicht. Im Soustrup 
sind 'n paar nette Beispiele dazu, guck sie dir an.


Deine Aussage zu Templates ist auch nicht gerade hilfreich. Wenn du dich 
doof genug anstellst machst du einfach ein rekursives Template und 
stellst das Limit vom Compiler aus. Auf Biegen und Brechen kann man mit 
allem Mist machen, du kannst dich auch mit Vitamin D umbringen.

Templates sind in den allermeisten Fällen kostenlos, gerade in den 
Fällen, wo du den Code sonst per Hand schreiben würdest.



Ich hab jetzt keine Lust mehr. Entweder willst du es nicht verstehen, 
oder du kannst es nicht. Ich bin mir nicht sicher, was davon zutrifft, 
aber eins auf jeden Fall. Ist ja nicht die erste Diskussion mit dir, die 
in diese Richtung abdriftet.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:

> Ich hab jetzt keine Lust mehr. Entweder willst du es nicht verstehen,
> oder du kannst es nicht. Ich bin mir nicht sicher, was davon zutrifft,
> aber eins auf jeden Fall. Ist ja nicht die erste Diskussion mit dir, die
> in diese Richtung abdriftet.

Ich hab nur das gemacht, was du so üblicherweise treibst und dir den 
Spiegel vorgehalten - hast du das etwa nicht gemerkt?

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oben ging's darum, dass solche Tools Programmierer hervorbringen, die 
einen Murks nach dem anderen Veranstalten. Das passiert leider viel zu 
häufig.
Oben hab ich aber schon geschrieben, dass die Tools für Leute die damit 
umgehen können auch was bringen.

Sourcen mit 10k Zeilen findest du auch sehr häufig. Natürlich nicht auf 
Mikrocontrollern, aber es gibt auch noch andere Sachen.

Es bleibt dabei, in meinen Augen willst du nur rumtrollen.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Sourcen mit 10k Zeilen findest du auch sehr häufig.

Sorry, das kann ich nicht bestätigen. Zum Glück sind sie die Ausnahme.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich erspar's mir jetzt mal alles in /usr/portage/distfiles zu entpacken 
und aufzulisten. In xorg-server hab ich recht schnell was mit 400kB 
gefunden, 200 und 300kb waren häufiger vertreten.

Es ist nunmal so. 10k Zeilen hast du des öfteren.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
20 Jahre alte Unix-Software ist nur selten ein Vorbild für guten Code.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher, der Code wurde in den letzten 20 Jahren nur minimal verändert. 
Eigentlich zählen die X Leute einfach nur die Versionsnummern hoch, um 
den Eindruck zu erwecken es gäbe Fortschritt.

kdelibs-3.5.9:

239     ./khtml/khtml_part.cpp - 7.5k Zeilen
181     ./kdecore/malloc/malloc.c
175     ./kioslave/http/http.cc
166     ./kdefx/kimageeffect.cpp - 5k Zeilen

usw, Größe in kB. Sind nur die ersten 4, es wurden immer mehr...

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal'n richtiger Klopper, qt4:

201     ./src/gui/graphicsview/qgraphicsitem.cpp
204     ./src/gui/painting/qpainter.cpp
207     ./src/gui/styles/qcleanlooksstyle.cpp
208     ./src/corelib/tools/qstring.cpp
210     ./src/3rdparty/libmng/libmng_object_prc.c
210     ./src/qt3support/itemviews/q3table.cpp
212     ./src/xml/qdom.cpp
224     ./src/qt3support/text/q3textedit.cpp
230     ./src/3rdparty/libpng/pnggccrd.c
231     ./src/qt3support/itemviews/q3listview.cpp
244     ./src/3rdparty/libmng/libmng_chunk_xs.c
250     ./src/3rdparty/freetype/src/truetype/ttinterp.c
265     ./src/3rdparty/libmng/libmng_display.c
266     ./src/gui/kernel/qwidget.cpp
266     ./src/qt3support/text/q3richtext.cpp
268     ./src/xml/qxml.cpp
283     ./src/gui/styles/qplastiquestyle.cpp
332     ./src/3rdparty/libmng/libmng_chunk_io.c
467     ./src/corelib/tools/qunicodetables.cpp
501     ./tools/designer/src/designer/extra/oublietteresource3.cpp
594     ./tools/designer/src/designer/extra/oublietteresource1.cpp
609     ./src/3rdparty/libmng/libmng_pixels.c
620     ./tools/designer/src/designer/extra/oublietteresource2.cpp
644     ./src/plugins/codecs/jp/qjpunicode.cpp
664     ./tools/designer/src/designer/extra/oublietteresource.cpp
757     ./src/plugins/codecs/tw/qbig5codec.cpp
987     ./src/plugins/codecs/cn/qgb18030codec.cpp
2100    ./src/3rdparty/sqlite/sqlite3.c

damit es übersichtlich bleibt alles ab 200kB. Die größten enthalten auch 
Tabellen mit Daten, aber es ist denke ich nicht zu übersehen, dass da 
ganz allgemein sehr viel großes bei ist.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 239     ./khtml/khtml_part.cpp - 7.5k Zeilen

Und die dazugehörige .h-Datei hat 1.4k. Soviel zu der Theorie dass 
Header-Dateien irgendwie der Übersichtlichkeit dienen...

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In den meisten Fällen tun sie das.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als ich anfing, C++ zu benutzen - auf dem PC - hatte ich einen C++ - 
Preprozessor, der aus den Quellen C-Code generierte; der wurde 
anschließend durch einen C-Compiler geschickt.

Da DOS seinerzeit standardmäßig nur 640 KB bereit hielt, wurde es sehr 
schnell eng - lange, lange vor 10.000 Zeilen. Die Auswirkungen zu großer 
Module waren drastisch: Die Kiste stürzte einfach total ab.

Ich baute dann in meine Entwicklungsmühle eine zusätzliche Speicherkarte 
mit 64 KB ein, was die Situation etwas entspannte. Hinter der 
Speicherkarte kam die Graphikkarte und der Bildschirm diente fortan als 
Indikator dafür, daß mal wieder ein Modul zu groß geworden ist: 
Spätestens, wenn die obere Hälfte des Bildschirms wild blinkende, wirre 
Zeichen enthielt, mußte man was tun...

Da früher die Compiler zwar deutlich schneller waren, als heute, die 
Rechner dafür aber elend langsam, wurde man auch dadurch zu kleinen, 
überschaubaren Modulen erzogen.

Vermutlich wurden diese C/C++-Riesenmodule, die heute angeblich üblich 
sind, von Leuten endlos weiter aufgebläht, die diese Zeiten nicht 
mitbekommen haben und auch so nicht recht wissen, was sie eigentlich 
tun.

Bei vielen der ausgesprochen sparsam kommentierten Quelltexte mag die 
Versuchung, einfach drauflos zu pfuschen, wohl auch relativ stark 
sein...

Autor: Bereits Fort (Firma: D.ade) (bereitsfort)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tja in Zeiten von giga/terabyte im Heim PC ist speichersparendes 
programieren nicht mehr gefragt. Es wird aufgebläht was das Zeug hält. 
Plopp! Speicher hat man, zum übertragen kompromiert man und die Rechner 
werden immer zum Glück schneller. Geht ja ganz leicht. Ne Tube 
copypaste,
nen Bildchen drumrum und vertig ist der eyecatcher.

[kotz]

Am Ende bootet Vista zwar länger als mein 8bit ATARI und ich kann auch 
nicht mehr wirklich überwachen was das Ding so tut, aber eines ist 
gewiss, wenn ich's hochfahre gehe ich wie zu alten Zeiten erst mal Kaffe 
kochen wenn der gebrüht ist melde ich mich an und wenn ich ihn trinken 
kann ist Vista auch so weit.

[/kotz]

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alle sind Scheißprogrammierer, nur ihr selbst seit die Besten. So 
sieht's doch aus!

Autor: Bereits Fort (Firma: D.ade) (bereitsfort)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@simon,

bist du aber negativ ;-)
lächeln!

Wo klappts denn nicht? Freundin oder Programm

ist doch Quatsch, das liegt doch auf der Hand endlose Streams zu 
genrieren und zu verwursteln ist einfacher als alles Kommendes 
vorherzusehen und leichter ist was angetüdelt als von vorn herein was 
Modular konzeptiert.
Zumal das Grundgerüst erstmal braucht bevor man ein einfaches Modul 
testen kann (und als Tätigkeitsbeweis vorlegen). Also wird beim Modul 
(blinkibunti)  angefangen und der Rest drum herum gehäkelt. ....

Autor: Bereits Fort (Firma: D.ade) (bereitsfort)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(kompromiert)-->kopmprimiert

ja und noch mehr ist verwurstelt

Liebe Rechtschreibpolizisten/Innen ich habe keine Berechtigung mehr das 
geradezuschieben. Als schreibt auf "Der Winne ist schuld und getürmt."

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Alle sind Scheißprogrammierer, nur ihr selbst seit die Besten. So
> sieht's doch aus!

Ich würde mal vermuten, daß ich schon mehr Fehler produziert hab, als du 
- bin ich deswegen besser?

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob der Code nun in einer großen Datei sitzt oder vielen kleinen ändert 
am entstehenden Programm doch nix.

@Uhu

Das mit deiner Speicherkarte klingt sehr merkwürdig. Die ersten 640kB 
RAM gehen bis kurz vor 0x9FFFF (da kommen dann noch'n paar Tabellen vom 
Bios). 0xA0000-0xAFFFF ist für VGA Graphikkarten reserviert, 
0xB0000-0xBFFFF für alle Graphikkarten (mit'm Textbuffer für 80*25 ab 
0xB8000).

Normalerweise werden Speicherkarten in den Bereich 0xC0000-0xDFFFF 
gemappt, danach kommt dann das VGA Bios in 0xE0000, und das normale Bios 
in 0xF0000.
Caldera Dos bot im Memory Manager sogar an 0xA0000-0xAFFFF als normalen 
RAM zu benutzen, dann ging halt kein Graphikmodus mehr, aber es waren 
über 700kB.

Ginge also nur mit einer nicht-VGA Graphikkarte, aber auch da wurde 
üblicherweise nix nach 0xA0000 gemappt.
Du hättest auch den High Memory nehmen können (oder war's der upper? 
komm damit immer durcheinander), also die knapp 64kB über physikalisch 
1MB.

Der GCC übersetzt übrigens alles erst in eine Zwischensprache, egal ob 
C, C++, Java (gcj) oder Fortran. Sind die Sprachen desswegen nur 
Aufsätze auf die Zwischensprache vom GCC? Ich denke eher nicht...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Ob der Code nun in einer großen Datei sitzt oder vielen kleinen ändert
> am entstehenden Programm doch nix.

Ich gehe mal davon aus, dass er nicht die Größe des Binaries meinte, 
sondern die größe der Textdatei, die ja schließlich für das Editieren in 
den RAM geladen werden muss. Da fehlt's dann an Speicher.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> @Uhu
>
> Das mit deiner Speicherkarte klingt sehr merkwürdig. Die ersten 640kB
> RAM gehen bis kurz vor 0x9FFFF. 0xA0000-0xAFFFF ist für VGA
> Graphikkarten reserviert, 0xB0000-0xBFFFF für alle Graphikkarten (mit'm
> Textbuffer für 80*25 ab 0xB8000).

War auch keine VGA, sondern eine Hercules. 
http://de.wikipedia.org/wiki/Hercules_Graphics_Card

> Normalerweise werden Speicherkarten in den Bereich 0xC0000-0xDFFFF
> gemappt, danach kommt dann das VGA Bios in 0xE0000, und das normale Bios
> in 0xF0000.

Du siehst, daß das mit normalerweise immer so eine Sache ist...

> Caldera Dos bot im Memory Manager sogar an 0xA0000-0xAFFFF als normalen
> RAM zu benutzen, dann ging halt ein Graphikmodus mehr, aber es waren
> über 700kB.
>
> Ginge also nur mit einer nicht-VGA Graphikkarte, aber auch da wurde
> üblicherweise nix nach 0xA0000 gemappt.

Mit üblicherweise ist es auch nicht besser...

> Der GCC übersetzt übrigens alles erst in eine Zwischensprache, egal ob
> C, C++, Java (gcj) oder Fortran. Sind die Sprachen desswegen nur
> Aufsätze auf die Zwischensprache vom GCC? Ich denke eher nicht...

Das ist bei Mehrpaßcompilern immer so. C ist allerdings als 
Einpaß-Sprache konzipiert worden - aus Effizienzgründen.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> I_ H. wrote:
>> Ob der Code nun in einer großen Datei sitzt oder vielen kleinen ändert
>> am entstehenden Programm doch nix.
>
> Ich gehe mal davon aus, dass er nicht die Größe des Binaries meinte,
> sondern die größe der Textdatei, die ja schließlich für das Editieren in
> den RAM geladen werden muss. Da fehlt's dann an Speicher.

Ahso... nicht ganz clever programmierte Software gab's auch schon 
damals, 'ne Fehlermeldung ala "out of memory" wär ja nicht unangebracht 
gewesen.
Wenn man unter DOS mit einem NULL Pointer weiterarbeitet muss meistens 
(nicht immer) als erstes die Interupt Vektor Tabelle dran glauben, und 
dann passieren witzige Dinge.

@Uhu

Das ändert nix dran, dass Speicherkarten normalerweise nicht nach 
0xA0000 gemappt werden. War also ziemlich non-standard.

Der Standard ist nicht nur einfach zum Spaß da, sondern das ist etwas an 
das man sich üblicherweise hält. Wenn du bei allem mit "ja, aber" 
kommst, würde nichtmal dein Kühlschrank funktionieren. Prinzipiell kann 
man zwar vorhersagen was da passiert, aber so ganz genau isses halt doch 
nicht (noch hat man keine Weltformel).

Beachte in dem Zusammenhang auch den ersten Satz an dich in meinem 
letzten Beitrag. Den hast du einfach ignoriert. Da steht nicht, dass es 
unmöglich ist, sondern, dass es merkwürdig ist!

Aber diese Art ist für dich leider geradezu typisch.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*Klugscheiss: Das VGA BIOS ist bei den allermeisten Computern nicht in 
E0000 sondern in C0000. In E0000 legt EMM386 gerne seinen EMS page 
frame.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:

> @Uhu
>
> Das ändert nix dran, dass Speicherkarten normalerweise nicht nach
> 0xA0000 gemappt werden. War also ziemlich non-standard.

Willst du damit sagen, daß ich mir das alles aus den Fingern gesogen 
habe?

Du weißt wirklich alles, und das auch noch besser...

> Der Standard ist nicht nur einfach zum Spaß da, sondern das ist etwas an
> das man sich üblicherweise hält.

Junge, Junge, bist du ein Klugscheißer.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@*.*

Hast recht. Ist doch schon etwas her.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Uhu

Nein, ich habe geschrieben, dass es "merkwürdig" ist. Nicht mehr und 
nicht weniger. Lesen und Verstehen musst du schon selber.

Wenn du mal ein bisschen nachdenkst, kommst du auch selber drauf, dass 
das mit anderen Graphikkarten so nicht gehen konnte.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://en.wikipedia.org/wiki/Conventional_memory

Zitat:
The AllCard, an add-on memory management unit (MMU) for XT-class 
computers, allowed normal memory to be mapped into the A0000-EFFFF (hex) 
address range, giving up to 952 kB for DOS programs. Programs such as 
Lotus 1-2-3, which accessed video memory directly, needed to be patched 
to handle this memory layout. Therefore, the 640 kB barrier was removed 
at the cost of hardware compatibility.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Trick bei dem C++-Präprozessor war, daß er unverändert in dieser 
Konfiguration lief. Der Effekt, wenn der Quellmodul zu groß wurde, war 
lustig und man konnte so arbeiten. Das war damals noch C++ 1.x - das war 
noch deutlich anders, als das, was man heute als C++ kennt. Z.B. mußte 
man vor überladene Meberfunktionen das Schlüsselwort overload 
schreiben.

An Templates dachte damals noch keiner...

Für die Speicherkarte hatte die c't eine Bauanleitung veröffentlicht und 
lieferte auch eine Platine dafür. Da war Platz für 10 x 43256 CMOS-Rams 
drauf, von denen bestückte ich ich zwei und bastelte mir noch eine 
kleine Logik dazu, mit der man die Karte mit einem Schalter in einem 
freien Slotblech abschalten konnte.

Das Teil hab ich noch in meinem Museum...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Macht für eure Grafikkarten-Diskussion bitte einen eigenen Thread auf, 
statt diesen hier zu kapern.

Autor: Bereits Fort (Firma: D.ade) (bereitsfort)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ I_H. diese Fakten sind mir alle bekannt und bewusst nur mache ich 
darum keinen Hipe (für amifreaks Hype)

Jaja die A20 Tür das war auch immer so ein Dilemma, Win oben und schon 
Klemmen alle Doserweiterung.

Ich sag dir was. Ich liebe meinen 8 Bit ATARI(320K/1MB Erweiterungen) 
leider war der Adressraum beschränkt und Code nur mit 
Neucompilieren/assemblieren verschiebbar.

Aber wenn ich das Kleingeld gehabt hätte hätte nie ein 386 oder 
Nachfolger das innere meiner 4 Wände gesehen. Bankswitsching und 
Pagemode schön und gut, aber die Segmentadressierung war mir stehts ein 
Graus obwohl ich sie beherrsche und TSR-programmierung(auch das hab ich 
gemacht) für Echtzeitanwendungen schlicht Katastrophen, da lieber 
aufeinem 8 Bitter 24 Bänke switchen in einer Page verwaltet als das. 
Obgleich ich nicht drumrum kam.  Aber jetzt  gibt es ja Gott (Atmel)? 
sei dank AVR und man kann Windowsmaschinen davor bewaren echtzeitfähig 
sein zu müssen. Wir merken ja eh alles erst wenns schon einene Sekunde 
um die Ecke ist. ;-))

Autor: Bereits Fort (Firma: D.ade) (bereitsfort)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[ot]

sorry wir waren im bereits totgelaufenen OT-thred OT. Jetzt hat aber die 
OT police  zugehauen. Die machen Überstunden am weekend. Ist das ne 
Strafarbeit?

[/ot]

Admin lächeln!

Der Strang hatte Drifttendenz und zwei wollten sich fast prügeln da kann 
man doch mal beschwichtigend eingreifen und muss nicht gleich als OT 
Scherge durch die Lande ziehen, im OT kopfschüttel

Manche nehmen sich aber sehr wichtig.

Soll ich den gelöschten Beitrag wieder einstellen oder tust du es?
oder werde ich jetz gesperrt?

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@letzter Beitrag: Da sind wir sogar mal einer Meinung...


@vorletzter: Der 386er hat mit Problemen von TSRs in DOS nix zu tun. 
Segmentierung kennt der 386er im PM zwar auch, aber die funktioniert 
gänzlich anders als im RM.
Üblicherweise macht man 2 Segmente über die vollen 4GB + eins für jede 
CPU zum Taskwechsel und stellt die Segmentierung damit praktisch aus, da 
logische Adressen == lineare Adressen, die dann mittels Paging in 
physikalische Adressen übersetzt werden.
Die PM Segmentierung ist ziemlich leistungsfähig, ganz im Gegensatz zur 
RM Segmentierung, die eigentlich nur stört.

Im Real Mode hat die CPU mehr Gemeinsamkeiten mit einem Taschenrechner 
denn mit einer ausgewachsenen CPU. Man muss Intel beim PM zugute halten, 
dass '82 noch kein einheitliches Konzept vorhanden war, wie moderne OS 
aufgebaut sind. Daher kann der 386er einiges was heute obsolete ist 
(Segmentierung, Hardware-Taskswitching), kann man aber alles 
ausschalten. OS/2 ist das einzige OS, das im PM die Segmentierung 
wirklich benutzt hat.

Übrigens sind die meisten ausgewachsenen OSs nicht echtzeitfähig, das 
beißt sich einfach mit anderen Eigenschaften moderner OSs.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.