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
>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
Normalerweise will man (wenn man eine will) eine syntaxabhängige Codevervollständigung. Gute stören den Tippfluß nicht.
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.
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.
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.
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.
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
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...
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
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.
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.
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.
> 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.
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).
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? ;)
> 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.
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).
> 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...
> 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.
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.
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.
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.
>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?
Hab vor einer Weile mal jemanden aus Österreich gefragt, in welcher Sprache er seinen Code kommentiert... Antwort: "manchmal Dialekt, aber meistens Deutsch"...
Die meisten IDEs und Leute sprechen allerdings Englisch. Das hat nichts mit sich schämen o.ä. zu tun.
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" * ...
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?
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
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.
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...
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.
> > 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.
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.
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...
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
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.
>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."
>Ein Rollkugelmanipulator
in die Kategorie wären dan auch ein trackball einzuordnen.
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.
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.
> 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.
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
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...
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. :)
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.
> 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).
> 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.
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
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...
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.
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...
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.
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?
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.
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.
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.
20 Jahre alte Unix-Software ist nur selten ein Vorbild für guten Code.
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...
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.
> 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...
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...
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]
Alle sind Scheißprogrammierer, nur ihr selbst seit die Besten. So sieht's doch aus!
@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. ....
>(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."
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?
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...
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.
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.
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.
*Klugscheiss: Das VGA BIOS ist bei den allermeisten Computern nicht in E0000 sondern in C0000. In E0000 legt EMM386 gerne seinen EMS page frame.
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.
@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.
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.
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...
Macht für eure Grafikkarten-Diskussion bitte einen eigenen Thread auf, statt diesen hier zu kapern.
@ 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. ;-))
[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?
@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? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.