Nimms mir nicht überl, du weisst nicht was Prozentrechnung ist aber willst wissen was in Compilerbau an Arbeit steckt ? Nö !Ich kann mir vorstellen wie viel Aufwand ist es einen Kompiler zu bauen !
Das ist doch aber kein Vorurteil von mir pluto, ich hab mich ne ganze weile zurückgehalten aber ich bin nunmal ziemlich direkt das ist einfach so.Ich weiß ja das du mir nicht all zu viel zumutetes das ist mir inzwischen auch
doch, genau damit komm ich weil es so ist. am compilerbau zerbrechen sich hochschulprofessoren den kopf, ich kann das auch lange nicht einschätzen was da in welcher funktion für mühe steckt und ich programmiere viel microcontroller wo man wirklich extrem hardwarenah arbeitet. ich optimiere auch oft indem ich mir den assemblercode anschaue der für eine codezeile erstellt wurde und dann überlege wie man es anders lösen könnte trotzdem ist mir oft total suspekt was der c compiler da hinrotzt. Pascal ist noch ein paar stufen härter c ist ne ganze ecke näher an assembler dran als pascal. Ich würde nie auf den Gedanken kommen zu sagen das ich irgendwas im compilerbau einschätzen könnte das können warscheinlich noch nichtmal die compilerbauer.voll kommen egal Denke was du möchtes. Aber komme bitte nicht mit sowas das kann ich nicht einschätzen und so !
Bin ich auch nicht aber auf dumme Fragen gibts dumme Antworten ganz einfach. Ich stelle auch oft mal ne dumme Frage worauf man mir durchaus ne dumme Antwort geben kann. Hab ich kein Problem mit.Ich bin auch nicht hier Angemledet um zu zeigen das ich der Beste bin.
Und wenn jemand ne Frage stellt wie "Gibt es sowas ?" oder "Geht sowas" Was mach ich da bitte falsch wenn ich mit Ja oder Nein antworte ?!
Hakts ? Die Hoffnung geb ich langsam auf.Ich hoffe wir verstehen uns jetzt !
Hui, wenn du schonmal was mit c oder C++ zu tun hattest solltest du die Frage beantworten können.zum Problem: Warum ist dass dann in C++ bzw c möglich ?
(das habe ich eine ganze Zeitlang unter dos gemacht)
Aber ich probiers mal:
Unter C/C++ gibt es einen sogenannten Präprozessor, der sogenannte includes vereinigt. Dabei wird aus allen Quellcodedateien (jedenfalls dem quasi interfaceteil) eine große gemacht und die wird dann compiliert.
Dabei entsteht ein riesiger Nachteil nämlich das man nur einen namespace in einem programm hat alle Variablen müssen also unterschiedlich heissen. Und das sowohl in den Systembibliotheken als auch im Benutzercode.
In Pascal ist das ein komplett anderes prinzip dort hat jede Unit ihren eigenen Namespace Variablen können also in 2 Units gleich benannt werden. In Delphi haben sie sogar pro Klasse eigene Namespaces.
Ausserdem wird in den Units interface und implementationteil in einer Datei gehalten was in C auf 2 aufgeteilt ist. Dieses Unitkonzept führt dazu das man eben etliche vereinfachungen gegenüber C hat, aber auchd azu das der Compiler dei Units verwalten muss und die entsprechenden Namespaces dazu was wiederum dazu führt das es dieses Cirkulare Unit problem gibt. Das lässt sich nicht auflösen da man dann 2 namespaces vereinigen müsste und das nunmal nicht geht da der Compiler dann bei 2 Variablen die gleich heissen nicht mehr weiss welche er für was benutzen soll.
Ich hoffe ich hab das jetzt verständlich genug erklärt und du verstehst das es eben nicht anders lösbar ist. Jedenfalls nicht Pascal konform. Und warum genau das in C/C++ geht...
Verein
Links
Suche