|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
 |
|
|
|
|
|
|
|
Gehen tat das doch schon immer: inline Code eben.
Aber wenn man die Beispiele sieht, daß da sowieso mit struct statt class gearbeitet wird und damit ohnehin alles public ist, dann ist das sowieso nicht mehr weiter beachtenswert. Ich finde ja, Variablen sollten sowieso immer privat sein und es gibt dann öffentliche get und eventuell set-Methoden. Sowas sollte automatisch vom Compiler gemacht werden, wenn keine explizite get-Methode da ist, das wäre mal was sinnvolles.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...nicht das der dann zu meinen privaten Variablen ne get-Methode macht!
Ich finds ganz gut wenn man noch weiss was man (selber) macht.
|
|
|
|
|
|
|
|
|
|
|
|
|
Hm, ok. Vielleicht ein passendes Schlüsselwort davor, wie wäres mit "public"?
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 13:22 MEW (#8)
|
|
|
|
|
1. inline bedeutet, dass eine Funktion hinterher keine echte Funktion ist! Eine inline-Funktion kann z.B. nicht rekursiv sein.
2. structs sind per default public. Das heisst nicht, dass man nicht innerhalb einer struct "private:" deklarieren darf.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 15:02 MEW (#9)
|
|
|
|
|
Ist inline in C++ wirklich so mies? Gut dass es noch C gibt und nicht nur diesen halbgaren C++-Mist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich fing hinten an ;-)
Zu 2: Klar darf es das sein, aber was ist das für ein Stil?
Zu 1: natürlich darf inline rekursiv sein. Inline-Code wird sogar erst dann inline, wenn die Code-Optimierung an ist. Sonst wird es trotzdem zu einer Funktion. Und wie Compiler mit Optimierung eine Rekursion umsetzen, weiß man auch nie so genau - eine einfache For-Schleife kann da ja auch schonmal zu einer Code-Verdopplung führen um den Sprung zu sparen.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmm...
Ganze ist speziell für diejenigen C++-Programmierer interessant, die sich an der .h-/.cpp-Aufsplittung bei objekt-orientierter Programmierung stören.
... also für jene, die C++ nicht verstanden haben (oder nicht verstehen wollen). Das ganze gab's doch schon mal von 20 jahren, mit leuten die per #define "BEGIN" und "END" erzeugt haben, damit C mehr nach pascal ausschaut.
Wer es nicht schafft hat einen header zu schreiben und zu warten muss eben bei java bleiben.
Real C programmers never die, they cast to void...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Genau.
Die .H/.C-Trennung mach sehr wohl Sinn.
Im Header-File steckt das Interface und im .C-File die Implementation. Solange das Interface nicht geaendert wird, muss auch nicht neu compiliert werden (bei gleichem Compiler mit gleichen Optionen).
Dies hat nichts mit OO zu tun. Das ging bei C auch schon so und sogar Modula-2 (resp. Turbo Pascal) hatten dies (auch wenn sie es nur bedingt verwendeten).
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 12:37 MEW (#6)
|
|
|
|
|
Die .H/.C-Trennung mach sehr wohl Sinn.
Im Header-File steckt das Interface und im .C-File die Implementation. Solange das Interface nicht geaendert wird, muss auch nicht neu compiliert werden (bei gleichem Compiler mit gleichen Optionen).
Dies hat nichts mit OO zu tun. Das ging bei C auch schon so und sogar Modula-2 (resp. Turbo Pascal) hatten dies (auch wenn sie es nur bedingt verwendeten).
Turbo Pascal und heute Delphi machen das immeroch so, allerdings nicht mit getrennten Dateien sondern mit sog. Interface und Implementation Sektionen einer Unit-Datei. Solange sich in der Interface Sektion nichts aendert, brauchen die sie benutzenden Units nicht neu compiliert zu werden. U.a. das sorgt fuer die extrem kurzen Comilezeiten.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 15:12 MEW (#10)
|
|
|
|
|
Du verwechselst Wirkung mit Ursache. Die Header-Dateien sind nur eine von vielen Moeglichkeiten, festzustellen, was neu uebersetzt werden muss und was nicht. make ist ja ganz nett, aber eigentlich ziemlich antiquiert und mehr eine Ansammlung von Hacks, z.B. verlaesst es sich einzig auf die Zeitstempel. Makefiles sind bei nicht ganz winzigen Projekten weder simpel noch uebersichtlich. Wie verzweifelt die Leute sind, sieht man ja daran, dass so Rotz wie Autocrap dermassen weit verbreitet ist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nah, er hat schon recht, wenn eine Headerdatei (.h-Datei ?? Sind wir hier unter Windows oder was?? Fehlt nur noch *.h) geändert wird, müssen natürlich erst recht alle C-Dateien, die diese nutzen, neu kompiliert werden.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 17:25 MEW (#17)
|
|
|
|
|
Nein, das ist ja nur der Fall-Out der genutzten Tools. Ich meinte das etwas allgemeiner. Wuerde man das Interface mit in die Object-Dateien packen oder die Tools eben automatisch solche Informationen extrahieren lassen, dann koennte man sich die Header-Dateien sparen oder zumindest das Erstellen dieser. Der Compiler koennte ja auch prinzipiell nur die Funktionen neu uebersetzen, die sich geandert haben anstatt die komplette Datei.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 21:17 MEW (#21)
|
|
|
|
|
Wenn man nur wollte koennte er das sehr wohl. Ob das sinnvoll bzw. effizienter waere, sei dahingestellt. Das Analysieren von Abhaengigkeiten, Pruefen von Checksummen, Modifizieren von Referenzen etc. braucht auch Zeit evtl. mehr als das eigentliche uebersetzen. Wobei so ein rekursiver(?) make-Anlauf beim Bauen beispielweise eines BSDs auch recht lange dauert.
Header-Dateien sind ja keine perfekte Loesung. Meist wird viel zu viel neukompiliert, wegen einer minimalen Aenderung z.B. auch nur eines Kommentars in einer Header-Datei. Wenn man aber alles in einzelne Dateien aufsplittet, dann braucht man hinterher 200 #include-Zeilen fuer 20 Zeilen Code - und oben drauf noch 100 Zeilen Lizensblabla.
Was an Java-C++ so toll sein soll, habe ich leider nicht verstanden. Will der gute Mann nicht einfach ein Tool, das ihm die passenden Header-Dateien aus den C++-Source generiert? Das sollte doch eigentlich nicht so schwer sein.
|
|
|
|
|
|
|
|
|
|
|
|
|
Wenn man nur wollte koennte er das sehr wohl.
Nein, kann er nicht. Ich hab auch schon daran getüftelt. Es ist effektiv ein Problem des Sprachdesigns. Was man machen kann, ist ein Tool, welches die Header automatisch generiert.
Header-Dateien sind ja keine perfekte Loesung. Meist wird viel zu viel neukompiliert, wegen einer minimalen Aenderung z.B. auch nur eines Kommentars in einer Header-Datei.
Das ist nicht ein Problem der Header, sondern von make. Es gibt durchaus Build-Tools, die solche Feinheiten erkennen können.
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Makefiles sind nit per se unübersichtlich, sondern nur wenn sie so erstellt werden.
Wenn ich mit die xml-files für "ant" so ansehe, denke ich mir immer wieder: Das soll ein fortschritt sein ?
Die syntax für makefiles fördert die unübersichtlichkeit, ohne frage. Aber letztendlich ist alles unübersichtlich was man nicht versteht.
Über configure&co wurde ja auch schon genug geschrieben. Wenn man jemand vom vorhaben programmierer zu werden abbringen will, muss man nur sagen: Das hier musst du für jedes deiner programme erstellen.
Real C programmers never die, they cast to void...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 17:46 MEW (#18)
|
|
|
|
|
XML und Java sind ja auch eher Seuchen als Loesungen. Scons sieht ganz interessant aus, ob es wirklich etwas taugt, ist eine andere Frage. Das nicht ueberall Python installiert ist, ist allerdings ein Nachteil. Bei make ist es allerdings aehnlich, denn GNU make macht vieles anders und eine andere Syntax als das make unter Solaris oder BSDs, wenn man nicht nur das allernoetigste nutzt.
Ehrlich gesagt finde ich es aber immer noch einfacher Makefiles von Hand zu schreiben, als mich irgendeinem Makefile-Generator auszuliefern, den ich dann erst mal 3x updaten und die Templates irgendwie zurechtbiegen muss, damit ich den Code ueberhaupt noch compilieren kann. Autocrap zu verstehen ist mindestens genauso aufwendig wie Makefiles selbst.
|
|
|
|
|
|
|
|
|
|
|
|
|
> ... also für jene, die C++ nicht verstanden haben (oder nicht verstehen wollen).
C++ definiert sich nicht durch eine von mehreren Möglichkeiten der Quellcode Anordnung.
> Das ganze gab's doch schon mal von 20 jahren, mit leuten die per #define "BEGIN" und "END" erzeugt haben, damit C mehr nach pascal ausschaut.
Warum vermischst du Syntax mit Codeanordnung?
> Wer es nicht schafft hat einen header zu schreiben und zu warten muss eben bei java bleiben.
Noe.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 29. December 2005, 19:44 MEW (#19)
|
|
|
|
|
...willst Du das jemals debuggen?
Jaja, Debuggen ist für Ladies....
|
|
|
|
|
|
