Hallo. Kennt jemand ein Buch oder Tutorial bzw. Beispiele, in dem ein OBJEKT definiert ist? Also angenommen ich will eine OOP-Sprache bzw. Struktur "herstellen" - und möchte eine Basisklasse "Objekt" haben. Wie würde diese Struktur oder die Basisklasse aussehen (können)? Gibt es da ein gut verständliches Beispiel? Warscheinlich ist es nicht ganz so einfach. Ich wüsste (auf die schnelle) jedenfalls nicht, wie ich so etwas Aufbauen kann, oder wie ich weitere Typen (z.B. String) durch meinen Code von OBJEKT Ableiten oder Definieren kann. Klar ist alles irgendwann nur noch ein Byte-Array... Mir fehlt also irgendwo die Basis, wie es von Adressen, Pointern und "Byte-Schaufeln" in einem Listing zum "brauchbaren" Objekt kommt, und wie so eine "Programmiersprache" roh im inneren aussieht, die diesen "OOP Abstaction-Layer" bereit stellt. Und wie das ganze dann in einem Loop "Runtime" hat. Was ich suche ist also ein "Programmiersprachen-Template". Muss nichts besonderes sein also kein Exceptionhandling und noch nix Reflection-Artiges können. Einfach nur zum lernen. Um so näher an der Hardware desto besser. Kennt da jemand was simples kleines? Oder kann das jemand gut erklähren? Edit: Ja, Ich hab bereits einige Threads u. Infos dazu gelesen. -Objekte in C?, -Frage zu OOP, -usw.
:
Bearbeitet durch User
Tim S. schrieb: > Mir fehlt also irgendwo die Basis, wie es von Adressen, Pointern und > "Byte-Schaufeln" in einem Listing zum "brauchbaren" Objekt kommt, Wenn ich dich richtig verstehe, dann fange mal zB. hier an: https://www.itwissen.info/Objektorientierte-Programmierung-object-oriented-programming-OOP.html
Teo D. schrieb: > Wenn ich dich richtig verstehe, dann fange mal zB. hier an: > https://www.itwissen.info/Objektorientierte-Programmierung-object-oriented-programming-OOP.html Ich weiß was OOP ist und wie man es benutzt usw. Also ich kann mit prozeduraler Programmierung und mit OOP umgehen. Kein Ding. In dem Link steht praktisch nichts neues. Meine Frage ist: Wie schaud OOP im Source aus? (z.B. interner Ablauf bei Vererbung von OBJEKT auf meinen TYPEx. Bzw. "Unter-Typen") [Ich frage, weil ich immer erst wissen will wie es funktioniert, bevor ich es anwende. Das hatt aber in dem Fall nicht so ganz geklappt. Learning by Doing usw. Also ich weiß was mit OOP geht, aber noch nicht wie es funktioniert auf der "Byte-Schaufel"-Ebene] Spekulation: Wenn ich TYPEx für "Diese Instanz" brauche, steht im "Stack" irgendwo, dass jetzt das OBJEKT die Definitionen (grob Struct) ab "Adresse für TYPEx" bis zu irgend einem EOLine mit einbeziehen (reservieren u. laden) soll, oder so ähnlich. (Geraten) Ich hab da irgend nen Knoten momentan, und kann es mir nichtmal gescheid vorstellen, wie OOP mir dann einen Member in diesen Objekt bereitstellen soll, den ich zur Laufzeit nochmal gezielt "ansprechen" kann. (Geht das dann erstmal trotzdem alles immer nur mit Pointern???) Es wird aber immer klarer und verständlicher... Daher wäre ein Source ganz nett.
:
Bearbeitet durch User
Tim S. schrieb: > Meine Frage ist: Wie schaud OOP im Source aus? (z.B. interner Ablauf bei > Vererbung von OBJEKT auf meinen TYPEx. Bzw. "Unter-Typen") Hab ich noch einen versuch? :/ Is nich einfach da was zu finden, bzw die richtigen Suchbegriffe. Eventuell ist dies ja mal ein Anfang: http://www.lerneprogrammieren.com/blog/praxis/stack-und-heap (Ich habs natürlich nur überflogen)
Ich denk, du haust einiges durcheinander. Die sprichst einerseits vom Source-Code und EOLs, andererseits von Stacks und Adressen. Du solltest Compiletime und Runtime getrennt betrachten und überlegen, welche Informationen wann benötigt und wie sie benutzt werden. Tipp: viele Sprachen benötigen zur Runtime keinerlei Typinformationen mehr. Btw, es vereinfacht die Sache auch, wenn man etwas konkreter ist und sich eine Sprache als Beispiel nimmt.
Danke für die Infos.... Ja der zweite URL beschreibt gut, wie man das macht. Zum Teil auch was da passiert. Aber es ist hald immernoch "zu C". Was mich hald interessiert ist, was "im übertragenen Sinne" bei new(TYPEx) oder malloc(TYPEx) passiert. Und wie das dann danach "gehandelt" wird. Ob es eine Instanz-Liste mit den Start-Adressen(?) gibt, usw. und wie das (und ein Zugriff darauf) RAW ausschaut!? foobar schrieb: > Ich denk, du haust einiges durcheinander. Ja das kann durchaus sein. ;-) foobar schrieb: > Die sprichst einerseits vom Source-Code und EOLs, "Irgendwie" muss es ja "definiert funktionieren", um das ganze "Programm" dann abzuarbeiten. Also das User-Programm läuft noch nicht direkt auf der Hardware, sondern über diesen "OOP Interpreter" den ich suche. foobar schrieb: > andererseits von Stacks und Adressen. ...das "seltsam beschriebene" war dann schon alles Runtime. foobar schrieb: > Tipp: viele Sprachen benötigen zur Runtime keinerlei Typinformationen mehr. Ok das wusste ich nicht - und habs immer mitnehmen wollen. - das vereinfacht dann doch ziemlich. Es wird dann wohl im endeffekt nur noch "dummes" Byte-Schaufeln mit irgendwelchen Listen und Pointer Adressen geben, wenns nach dem Compilen keine Type-Infos mehr dazu gibt...(!!??) Ich kann es nicht sonderlich gut ausdrücken... ^^ OOP mit Types zur Runtime - dachte ich - wäre eigentlich ganz normal. OK das erklährt auch warum das compilierte meist sooooo extrem viel kleiner ist, und sich z.T. überhaupt nicht mehr decompilieren lässt. foobar schrieb: > Du solltest Compiletime und Runtime getrennt betrachten Ja schon, nur eben genau "das dazwischen" fehlt mir noch... ^^ Ein OOP Source, der dann Runtime laufen kann. Der dann eine Runtime "anbietet". [Dieser Abstaction-Layer] Damit dass, was in meinem später geladenen Programm ist, auch ausgeführt werden kann. Da hatte ich irgend einen Denkfehler. Ohne Typinfos zur Runtime ist das wesentlich leichter erstmal. Ja du hast eben einige dieser "Knoten" gelößt. Mir fällt insgesammt nur ein Wort zu dem ein, was ich suche: > "Programmiersprachen-Template" ... mit "Managed-Code zur Runtime" sozusagen - So wie das z.B. bei Win .Net Applications über das Framework passiert. Ich hoffe jemand weiß was ich meine. Beispiel: Ich hab so nen mini "Interpreter" mal auf nen AVR gebaut. (lange her). Allerdings ohne OOP und der konnte nur paar Standard-Instructions "durchreichen", die man von irgendwo anders geladen hat. So etwas würde ich gerne für OOP können und irgendwann mal machen. Ziel: Dass zur Laufzeit ein "New(TypeX);" bei einem Event / Interrupt instanziiert werden kann. ;-) Ich bin ja bestimmt nicht der einzige oder erste, der das sucht oder will.
:
Bearbeitet durch User
Wenn Du weißt, was ein c-compiler macht, also wie er Strukturen und funktionsptr in Code umsetzt, dann ist es ein kleiner Schritt zur oop. Klassen sind structs mit Funktionen mit implizitem this, nee ist ein malloc mit implizitem Konstruktor-Aufruf. Also so, wie man auch in C programmieren würde, aber viel einfacher und sicherer. Templates quasi ein aufgemotzter Präprozessor, der typischer den jeweils konkret erforderlichen Code bereitstellt bzw auch in sich zusammenfallen lassen kann. Die ersten C++-compiler waren quasi präprozessoren-konstrukte.. Das gerade C++ sich ständig rapide weiter entwickelt, lässt den heutigen Stand vielleicht wie etwas völlig anderes erscheinen. Geh den Weg einfach von C aus nach.
Hallo Tim S., Tim S. schrieb: > Mir fehlt also irgendwo die Basis, wie es von Adressen, Pointern und > "Byte-Schaufeln" in einem Listing zum "brauchbaren" Objekt kommt, und > wie so eine > "Programmiersprache" roh im inneren aussieht, die diesen "OOP > Abstaction-Layer" bereit stellt. Und wie das ganze dann in einem Loop > "Runtime" hat. Tim S. schrieb: > Meine Frage ist: Wie schaud OOP im Source aus? (z.B. interner Ablauf bei > Vererbung von OBJEKT auf meinen TYPEx. Bzw. "Unter-Typen") Die obere Frage ist genau das Gegenteil von der unteren Frage. Ich gehe davon aus, dass die untere Frage gemeint ist. Ich würde ein minimales Programm schreiben, dass Deine Strukturen benutzt und dann debuggen. Dann siehst Du, was der Compiler aus der abstrakten, prozessorfern erscheinenden Sprache real auf Maschinenspracheebene gemacht hat.
Tim S. schrieb: > Also angenommen ich will eine OOP-Sprache bzw. Struktur > "herstellen" Du könntest dir GTK mit GObject ansehen, da wird ja in C objectorientiert gearbeitet. Die verwenden da u.a. einen Haufen von C Macros, um die Funktionen richtiger OOP Sprachen in C nachzubilden. Aber wenn Du wirklich eine OOP Sprache entwicken willst, solltest Du auch bedenken, dass der Trend etwas von OOP weggeht, bei vielen modernen Sprachen wie Go, Rust, Nim steht OOP nicht mehr im Mittelpunkt.
Im Prinzip geht's wie die vorgaengige Methode des Prozeduralen Programmierens. OOP ist ein Layer fuer den Compiler, der muss OOP nach Prozedural uebersetzen. Unten dran ist es dasselbe. OOP tut so, wie wenn Code und Daten zusammengehoeren. Der Code is nur einmal vorhanden, der Datenteil des Objektes wird sooft instanziert wie deklariert. Vererbung tut so wie wenn gewisse Objekte mehr Moeglichkeiten haetten. Es ist einfach mehr code, der auf neue Daten zugreift. Der Compiler merkt sich zu welchen Daten welcher Code Zugriff hat. Da ist kein Hokus-Pokus dahinter.
Einfacher ausgedrückt: µController (Bare Metal): Der Compiler setzt Deinen Quellcode in Maschinencode für die Ziel-CPU um (vergleichbar mit Assembler, guck Dir im Debugger das Disassembly an, dann weisst Du was ich meine). Dabei ist es egal, was die Quell-Sprache war (C, C++, BASCOM, Arduino, ...). Die CPU arbeitet Instruktionen nur sequenziell ab. IMMER. Irgendeine Sprache mit Runtime Environment (Java, C#, ... ): Deine Quelle wird in eine "Intermediate-Language" übersetzt und ist nicht direkt auf der CPU-Lauffähig. Es benötigt eine RTE (RunTimeEnvironment), nämlich die JavaVM, das .Net-Framework etc. Darin ist meist ein JustInTime-Compiler enthalten, der den Intermediate-Code dann in den Maschinencode der Ziel-CPU übersetzt, wenn er gebraucht wird. Vorteil: Plattformunabhängigkeit (zumindest theoretisch). Und dann gibt es noch richtige Interpretersprachen, wo die Quelle gar nicht übersetzt wird, sondern der Interpreter etwas tut, was er vorher in einer Textdatei (der Quelle) gelesen hat.
Tim S. schrieb: > Meine Frage ist: Wie schaud OOP im Source aus? Mal so ganz grob: ein Objekt ist eine List von Adressen, nämlich die Adressen der Variablen (Eigenschaften) und der Methoden. Vererbt man was, kommen Einträge zu der Liste dazu. Im Sourcecode taucht das nicht auf, weil in den mir bekannten Sprachen das (Basis-) Objekt ein vordefinierter Typ ist. Wie die Listen genau aufgebaut sind, ist möglicherweise irgendwo dokumentiert, interessiert aber kein Schwein (ausser dir). Georg
Danke für die Antworten... ;-) Peter M. schrieb: > Ich würde ein minimales Programm schreiben, [...] Dann siehst Du, was der Compiler [...] gemacht hat. Klugscheisser schrieb: > Der Compiler setzt Deinen Quellcode in Maschinencode für die Ziel-CPU [...] > Die CPU arbeitet Instruktionen nur sequenziell ab. IMMER. Ja das ist mir im Grunde schon bewusst... Tim S. schrieb: > Ob es > eine Instanz-Liste mit den Start-Adressen(?) gibt, usw. und wie das (und > ein Zugriff darauf) RAW ausschaut!? georg schrieb: > Mal so ganz grob: ein Objekt ist eine List von Adressen, nämlich die > Adressen der Variablen (Eigenschaften) und der Methoden. Vererbt man > was, kommen Einträge zu der Liste dazu. Wenn ich das jetzt richtig verstanden hab: Man braucht also diese "Liste" (wie anfangs spekuliert) und diese "hält" und verwaltet sozusagen den Heap !? Alles im Ram... > Im Sourcecode taucht das nicht auf, weil in den mir bekannten Sprachen > das (Basis-) Objekt ein vordefinierter Typ ist. Ja genau dessen Source habe ich gesucht. Undzwar einen, der zur Laufzeit immer noch "Typeinfos" hat... Mit eurer Hilfe komme ich so nach und nach immer weiter. Anscheinend suche ich ein RunTimeEnvironment-Source oder mehr Verständniss darüber... > Wie die Listen genau > aufgebaut sind, ist möglicherweise irgendwo dokumentiert, interessiert > aber kein Schwein (ausser dir). Ohja. ;-) Tim S. schrieb: > weil ich immer erst wissen will wie es funktioniert, bevor > ich es anwende. Sonnst wäre es ja zu einfach!!! Okay so grob hab ich nun "Runtime" damit durchdacht, und in der Kopfsache laufen. Kann ich jetzt auch programmieren. Es werden dann viele Listen (Types, Instances, Stack) aber macht ja nix. Tausend Dank...
Tim S. schrieb: > Ja genau dessen Source habe ich gesucht. Undzwar einen, der zur Laufzeit > immer noch "Typeinfos" hat Wozu brauchst du die Typeinfos? Vielleicht formulierst du mal deine Anforderungen, also was du mit dem Projekt erreichen willst. Mein Eindruck ist, dass du irgendwo einen Denkfehler hast und dir dadurch die Sache komplexer erscheint, als es in Wirklichkeit ist. Interessant wäre auch wozu du die Typinformationen brauchst? Hier mal ein paar Aspekte zu C++, die dir für dein Verständnis vielleicht weiterhelfen. Man sieht auch, dass der Ausführenden (in diesem Fall bare metal) gar keine Typinformationen braucht, um korrekt zu arbeiten. Im Prinzip besteht alles nur aus Datenstrukturen (struct, class, int, float, ...) und Funktionen. Datenstrukturen: Die Datenstrukturen haben eine Größe und eine Adresse auf dem Heap, Stack oder im statischen Speicher. Die Adresse kann damit teilweise schon zur Compilezeit bekannt sein. Die einzelnen Elemente haben einen Typ und einen Adressoffset relativ zur Adresse der Datenstruktur. Der Typ ist nur dazu da zur Compilezeit die Korrektheit der Operationen zu prüfen und implizite Konvertierungen durchzuführen (z.B. int auf float zuweisen). Der Adressoffset wird für den Zugriff auf das Element in der Datenstruktur benötigt. Ist die Adresse der Struktur zur Compilzeit bekannt, dann kann der Compiler das schon ausrechnen. Sonst erzeugt er Code, der das zur Laufzeit anhand der Adresse der Datenstruktur ausrechnet. Damit braucht man im fertigen Code keine Typen mehr, weil alle benötigten Größen und Offsets durch den Compiler als konstanten in den Code übernommen wurden. Funktionen: Funktionen sind Stücke von Programmcode an einer Adresse im Speicher in die man springen kann und danach wieder zurückkommt (zumindest in der Regel). Für den Compiler beschreibt die Funktion aber nur welche Datenstrukturen wie übergeben werden. Damit kann dieser auf Fehler prüfen und z.B. implizite Kopien der Objekte anlegen (im Prinzip auch nur ein Aufruf einer weiteren Funktion - Copy constructor) oder nur einen Pointer. Aber was ist jetzt mit Memberfunktionen. Im Prinzip geben diese auch nur an, dass man die Funktion nur auf bestimmten Objekten aufrufen kann und das implizit der Pointer auf das Objekt übergeben wird. Zur Laufzeit sind es daher auch konstante Offsets, also keine Typinformation mehr notwendig. Einen Sonderfall stellen hier die virtuellen Methoden dar, bei denen das Sprungziel zur Laufzeit über einen vtable ausgewählt wird. Aber auch hier wird der vtable nicht für jedes Objekt, sondern nur einmalig für einen Typ angelegt. D.h. im Speicher liegt eine Tabelle die auf Funktionen zeigt. Da steht dann aber auch keine Typinformation mehr drin, weil sich diese zur Compilezeit in eine Adresse aufgelöst hat. Wir funktioniert New: Im Prinzip besteht ein new aus zwei Schritten. 1) Speicher mit einer Größe beim Heap anfordern. Die Größe kann der Compiler aurechnen und als Konstante dem Funktionsaufruf für das malloc mitgeben. 2) Objekt initialisieren. Der Compiler ruft eine Funktion aus (Constructor) und übergibt diesem den Pointer. Der Constructor enthält alles um das Objekt und bei Bedarf den Pointer auf den vtable einzurichten. Wie man hier sieht bleibt von der Typinformation nicht viel übrig, weil man es auch nicht braucht.
Tim S. schrieb: > Man braucht also diese > "Liste" (wie anfangs spekuliert) und diese "hält" und verwaltet > sozusagen den Heap !? Alles im Ram... Zunächst mal, auf einem PC ist sowieso alles im RAM. Ansonsten hat die Struktur mit dem Ort der Speicherung nur wenig zu tun, ich kann Objekte sowohl als globale Variablen definieren (also im fest allokierten Speicher), als auch mit new erzeugt (also im Heap), oder in einer Funktion lokal definiert (also auf dem Stack). Das Objekt bleibt dabei das gleiche. Im übrigen ist alles implementationsabhängig, da muss man die Dokumentation heranziehen, soweit für diese Fragen überhaupt vorhanden. Es ist ja ein beliebter Programmierstil, alles was überhaupt in einem Programm vorkommt mit new zu erzeugen. Das wirft aber die Frage auf was passieren soll wenn nicht genug Speicher dafür da ist. Ich ziehe es daher vor, zumindest für alles was für die ganze Laufzeit gebraucht wird festen Speicherplatz vorzusehen. Im Fall einer PC-Exe startet dann das Programm garnicht erst, wenn nicht genug Memory für die Variablen verfügbar ist, man muss das nicht bei jeder Variable extra prüfen und behandeln. Georg
Die Objektorientierte Programmierung ist ein Programmierparadigma. Da interessiert in erster Linie die abstrahierte "Technik" selbst. Was hilft bei der OOP-Programmierung/Grundlagen weiter? Z.B. Gute Einführungsbücher zu Java lesen und verarbeiten und viel mit Ruby herumspielen. https://de.wikipedia.org/wiki/Ruby_(Programmiersprache) Ein wenig "Compiler"-Hilfe: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours Oder: Mal angenommen, du möchtest einen Algorithmus in Assembler programmieren. Da heißt es zuerst, den Algorithmus zu verstehen. Wenn man den Algorithmus gut verstanden hat, dann ergibt sich die Implementierung fast von allein. Ein Algorithmus ist eine Sache, die Implementierung einer Programmiersprache eine andere - und die muss gar nicht hardwarenahe sein. Z.B. : http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf So ganz grob gibt es drei Ebenen, - das was schon da ist, Compilergeschichte, Metasprachen wie Bnf, Fortranbibs, Lambda-Kalkül usw. - die OO-Sprache selbst und ihre Entwurfssprache - die Lowlevelebene bzw. das, was man im Hexeditor oder im Debugger sehen kann. Nochmal das Algorithmusbeispiel: Wenn man jetzt einen Blick auf den Hexcode oder ein Listing mit Zeigern o.ä. hat - Verstehen kann man den eigentlich nur, wenn man den Algorithmus gut kennt. Man kann es auch umgekehrt machen, aber der Algorithmus aus dem Lehrbuch ist 1000 mal besser verdaulich, als die umgekehrte Erschließung aus dem Hex- oder Assemblercode. Letzteres ist sehr viel einfacher, wenn man bereits Erfahrung (+ Theorie) mit Algorithmen und deren Implememtierung hat.
Super Erklährungen.. ;-) Also warum Typeinfos: Ich versuch eine minimale OOP Sprache zu bauen. Und die Anwendungen die damit "entstehen" sollen sozusagen zur Laufzeit wissen, was sie tuhen, oder woraus sie bestehen. (Komisch beschrieben) Auch wegen der Kapselung in Objekte und Vererbung bzw nachträglicher Runtime-Erweiterung(en), und insgesamt Vereinfachung beim Debug, damit auch ich später weiß was die Anwendung grad wirklich macht brauch ich die Typeinfos. Und längerfristig soll da eine art Entwicklungsumgebung "mit eingebaut" werden. Also ein Tool zum Programmieren und "jederzeit Source erweitern" ist in der "Sprache" enthalten. Ich denk mal so sehr viel Verwaltungs-Overhead ist es ja nicht, wenn ich das mit den statischen "Offsets" beim compilieren vergleichen würde. Und die "Offsets" für Objekte und dessen Member für die Daten / Heap würde ich dann besser immer ausrechnen anhand der Typenbeschreibung und nicht compilieren. Sodass ich einen OOP-Layer recht nahe Bare-Metal hab, dazu brauch ich (beispiel µC AVR) ja nur neue "Types" [die über das "Byte" hinaus gehen. Also uint16, uint32 ..., und die Vorzeichenlosen. Dazu paar Sondertypen float string usw. Und die weiteren "Elemente" wie Interrupt Events und Hardware-Dinge] fest in den Flash auf der HW ein compilieren. Es soll dann von anderer Quelle den Code ausführen, und vorher seinen "Type Set" davon erweitern bzw. updaten können... __ Hat jemand noch ne Idee wie ich das ganze dann Crossover machen kann? Ist ja eigentlich nochmal ein Layer "Drüber" bzw. dann Compiler-Sache oder? Ich denk "mein OOP-Ding" wird so eine "Intermediate-Language" damit dass auch überhaupt Crossover geht. Dazu muss ich (am ende) jede Zeile bzw. ASM Befehl für den fertigen RTE-Code (beispiel µC AVR Flash) aus einem "Lookuptable" für die Ziel-Hardware holen und zusammensetzen. !?? Dort natürlich noch statische Offsets nehmen! Oder wie macht man das? Also ich möchte das nur zu lernzwecken machen. __ rbx schrieb: > Verstehen kann man den eigentlich nur, wenn man den Algorithmus gut > kennt. > > Man kann es auch umgekehrt machen, aber der Algorithmus aus dem Lehrbuch > ist 1000 mal besser verdaulich, als die umgekehrte Erschließung aus dem > Hex- oder Assemblercode. Daher möchte ich es selber schreiben!! Ich hatte nur ein Beispiel zum "Anlehmen" gesucht... Es wird dann eben nur ein hardwarenaher interpreter... Warscheinlich "reicht" JSON des für den "auszuführenden Sourcecode".
:
Bearbeitet durch User
Ich empfehle dir dringend, dir erstmal das nötige Grundwissen anzueignen, damit du überhaupt weißt, wovon du sprichst - z.Zt. ergeben die meisten deiner Aussagen keinen Sinn, reines Buzzword-Bingo. Als Einstieg in den Compilerbau z.B. https://en.wikipedia.org/wiki/PL/0 .
foobar schrieb: > Ich empfehle dir dringend, dir erstmal das nötige Grundwissen > anzueignen, damit du überhaupt weißt, wovon du sprichst - z.Zt. ergeben > die meisten deiner Aussagen keinen Sinn, reines Buzzword-Bingo. Ich hab ne Runtime im Plan. Im Kopf. Hab durch den Thread nur paar Sachen bestätigt bekommen. Ich kann jetzt ein OOP-Gelände bauen. Von mir aus kann das Objekt auch "Kritzikratzi" oder "Hausschuh" heißen. georg schrieb: > Im übrigen ist alles implementationsabhängig, da muss man > die Dokumentation heranziehen, soweit für diese Fragen überhaupt > vorhanden. Ich hab soweit alles verstanden was ich dazu brauche. Ja foobar dann korrigier mich hald. Noch mehr "Overhead" will ich vermeiden. Was meinst du denn eigentlich, außer dass du durch die alten negativen Worte dieses Threads (die bereits kompensiert wurden) urteilst? Was in deinem URL steht hatte ich ja auch schon beschrieben... Und da kommt so ne Art "Basic" bei raus, aber ich will´s mit JSON Syntax. Und ich mach noch diesen "statischen" layer drüber, für den Compiler und Crossover. Bingo. Ist für mich erstmal "logisch und weitsichtig" genug. Sorry wenn du´s nicht verstanden hast. Wie gesagt Danke für die Tipps.
foobar schrieb: > Ich empfehle dir dringend, dir erstmal das nötige Grundwissen > anzueignen, damit du überhaupt weißt, wovon du sprichst - z.Zt. ergeben > die meisten deiner Aussagen keinen Sinn, reines Buzzword-Bingo. Ist nicht böse gemeint, aber das ist auch mein Eindruck. Meine Frage, was du damit erreichen willst hat sich auch noch nicht beantwortet. Entweder willst du unbedingt diese Runtime schreiben. Ok, mach es, irgendwer hat auch mal Brainfuck erfunden. Vielleicht möchtest du mit der Runtime aber auch ein Projekt von dir realisieren, dann könnten wir dir bei der Suche nach den richtigen Tools helfen, die du nicht erst selbst schreiben musst.
Tim S. schrieb: > Was meinst > du denn eigentlich, außer dass du durch die alten negativen Worte dieses > Threads (die bereits kompensiert wurden) urteilst? Tim S. schrieb: > Was in deinem URL steht hatte ich ja auch schon beschrieben... Tim S. schrieb: > Sorry wenn du´s nicht verstanden hast. Ich habe überhaupt keinen URL angegeben, und ich kann in meinen Posts auch nichts finden was dir einen Grund gibt mich anzupöbeln. Also ist hier für mich Schluss. Es wird eh nichts draus, weil man Programmierprobleme nicht mit schlechtem Benehmen lösen kann, das funktioniert höchsten von Mensch zu Mensch, siehe Trump. Genausowenig kann man fehlende Kentnisse durch Agressivität kompensieren. Georg
Tim S. schrieb: > Ich denk mal so sehr viel Verwaltungs-Overhead ist es ja nicht, wenn ich > das mit den statischen "Offsets" beim compilieren vergleichen würde. > Und die "Offsets" für Objekte und dessen Member für die Daten / Heap > würde ich dann besser immer ausrechnen anhand der Typenbeschreibung und > nicht compilieren. Wow: Also ich äußere mal die gewagte These, dass du deinen "OOP-Layer" nicht an einem verregneten Nachmittag zusammenklöppelst. Da hier ja Buzzword-Bingo gespielt wird: OOP bedeutet Polymorphie, was bedeutet, dass erst zur Laufzeit entschieden wird, welche Methode einer Klassenhierarchie aufgerufen wird. D.h. du musst dich mit virtual tables rumschlagen, in denen Einsprungadressen verwaltet werden. Der GCC ist open source, schau doch einfach mal da rein, welchen Aufwand es bedeudet, das umzusetzen. BTW: Was meinst du mit JSON-Syntax? JSON ist ein Dateiformat zum Austausch von Daten, das hat mit einer Programmiersprache recht wenig zu tun. Just my 2 cents merciless (der mit Grauen an die Compilerbau-Vorlesungen zurückdenkt)
:
Bearbeitet durch User
Achim S. schrieb: > Die ersten C++-compiler waren quasi präprozessoren-konstrukte.. > > [...] Geh den Weg > einfach von C aus nach. Genau, überlege dir einfach, wie du C so erweitern könntest, dass es objektorientiert wird. Ich kein Experte im Compilerbau, aber ich vermute mal, dass jede Programmiersprache die Objektorientierung unterschiedlich umsetzt. Also überlege dir basierend auf deinem Wissen doch einfach etwas eigenes! Tim S. schrieb: > Tim S. schrieb: >> weil ich immer erst wissen will wie es funktioniert, bevor >> ich es anwende. > > Sonnst wäre es ja zu einfach!!! Ich weiß ja nicht ob du noch Student bist oder ob du in der Industrie schon erfolgreich Projekte umgesetzt hast. Aufgrund der ersten Aussage ("ich will immer erst wissen, wie es funktioniert") nehme ich mal an, dass du noch keine Projekte in einer OOP-Programmiersprache umgesetzt hast und deshalb ein gut gemeinter Ratschlag: Vergiss diese Denke! Sonst wirst du weder das Studium packen (selbst erlebt bei nem Kumpel von dem ich hier glaub schonmal berichtet habe...) noch erfolgreich irgendwelche Projekte umsetzen! Nicht falsch verstehen, es ist nie schlecht, ein solides Grundverständnis zu haben, aber manchmal muss es Zack auf Zack gehen und dann zählt nur die Anwendung.
:
Bearbeitet durch User
Tim S. schrieb: > Super Erklährungen.. ;-) > > Also warum Typeinfos: Ich versuch eine minimale OOP Sprache zu bauen. > Und die Anwendungen die damit "entstehen" sollen sozusagen zur Laufzeit > wissen, was sie tuhen, oder woraus sie bestehen. (Komisch beschrieben) Das ist Introspektion bzw. Reflektion. > Auch wegen der Kapselung in Objekte und Vererbung bzw nachträglicher > Runtime-Erweiterung(en), und insgesamt Vereinfachung beim Debug, damit > auch ich später weiß was die Anwendung grad wirklich macht brauch ich > die Typeinfos. > > Und längerfristig soll da eine art Entwicklungsumgebung "mit eingebaut" > werden. Also ein Tool zum Programmieren und "jederzeit Source erweitern" > ist in der "Sprache" enthalten. Klingt nach Smalltalk, was nicht nur Aufgrund der einfach zu implementierenden Sprache sehenswert ist. Klassisches Buch dazu wäre das Blue Book http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf oder eine der Implementierungen wie Squeak ansehen. Oberon(2) ist inkl. der Implementierungen auch sinnvoll, da selbst mit dazugehörigem OS einfach zu verstehen und zu übersetzen. Bspw. https://www.inf.ethz.ch/personal/wirth/ProjectOberon1992.pdf oder http://www-oldurls.inf.ethz.ch/personal/wirth/index.html bzw. http://www-oldurls.inf.ethz.ch/personal/wirth/Oberon/index.html Ebenso für die grundlegenden Konzepte eines Compilers 1) zu empfehlen u.a. http://www-oldurls.inf.ethz.ch/personal/wirth/CompilerConstruction/index.html Wen mehr interessiert greift bspw. zum Dragon Book (Compilers: Principles, Techniques, and Tools, Aho, Lam, Sethi, Ullman) oder macht einen Online-Kurs: https://online.stanford.edu/courses/soe-ycscs1-compilers (min. gutes Verständnis von Algorithmen und Datenstrukturen, wie bei allen Compiler-Kursen/Büchern, nötig, implementiert wird eine einfache, objektorientierte Sprache). 1) Nette Übung am Rande: Einen Lisp-Interpreter schreiben https://programmingpraxis.com/2011/11/01/rip-john-mccarthy/
:
Bearbeitet durch User
Tim S. schrieb: > [Ich frage, weil ich immer erst wissen will wie es funktioniert, bevor > ich es anwende. Das hatt aber in dem Fall nicht so ganz geklappt. > Learning by Doing usw. Also ich weiß was mit OOP geht, aber noch nicht > wie es funktioniert auf der "Byte-Schaufel"-Ebene] Dann lerne einfach Assembler und schaue dir an, was die Compiler von OO-Sprachen für die typischen OO-Konstrukte produzieren. Ich denke, ich verstehe sehr gut, was du eigentlich meinst. Ich selber habe das OO-Konzept damals(tm) auch erst auf diesem Weg wirklich kapiert. Das abstrakte akademische Geseiere alleine hat den Erkenntnis nicht purzeln lassen. Erst der Umweg über die Analyse des "ganz unten" hat mir die Konzepte wirklich klar gemacht. Allerdings: bei heutigen OO-Sprachen ist es nicht mehr ganz so einfach wie damals(tm). Der ganze Scheiß, der in modernen Sprachen zur Compile-Zeit passiert, ist so nicht zu erschließen. Also so'n Kram wie Templates in C++ oder Generics in .net-Sprachen. Um das zu kapieren, muss man die Laufzeit wirklich verstanden haben. Dann kann man das Wissen sozusagen in die Compile-Zeit "rückübersetzen", denn die grundlegenden Prinzipien sind dieselben. Es gibt nur keine (relativ) einfache Möglichkeit mehr, exakt zu verfolgen, was hier eigentlich passiert...
Tim S. schrieb: > Kennt jemand ein Buch oder Tutorial bzw. Beispiele, in dem ein OBJEKT > definiert ist? Aber ja doch. Versuche mal, dir die Dokumentation zu besorgen, die DAMALS, also vor langer Zeit mit Turbopascal oder mit Borland Pascal 7 gekommen war. Ja, das waren richtige Bücher und es gab darinnen eine wirklich gute Einführung in die Welt der objektorientierten Programmierung. Da ist m.W. keines der später erschienenen Werke herangekommen. W.S.
Sorry - dass ich mich hier so lange nicht gemeldet habe. Und nochmal tausend Dank für die vielen Infos und die Erklärungen. Dirk K. schrieb: > die gewagte These, dass > du deinen "OOP-Layer" nicht an einem verregneten > Nachmittag zusammenklöppelst. Ja richtig, das dauert ein Weilchen... > zur Laufzeit entschieden wird, welche Methode > einer Klassenhierarchie aufgerufen wird. D.h. > du musst dich mit virtual tables rumschlagen, > in denen Einsprungadressen verwaltet werden. Ja genau davon rede ich ja - bzw. das habe ich ja angefragt! Und ich hab auch einige weitere Sachen (z.T. hier) gefunden. G. P. schrieb: >> Geh den Weg >> einfach von C aus nach. > > Genau, überlege dir einfach, wie du C so erweitern könntest, dass es > objektorientiert wird. > Ich kein Experte im Compilerbau, aber ich vermute mal, dass jede > Programmiersprache die Objektorientierung unterschiedlich umsetzt. > Also überlege dir basierend auf deinem Wissen doch einfach etwas > eigenes! Das ist ja der Sinn des Threads und der Anfrage. Vorher wusste ich es noch nicht genau. Mir hat mehr oder weniger die "Bestätigung" gefehlt, bevor ich mich da irgendwo hin verlaufe beim Programmieren. Naja ich habs jetzt aber kapiert. G. P. schrieb: > Vergiss diese Denke! Sonst wirst du weder das Studium packen (selbst > erlebt bei nem Kumpel von dem ich hier glaub schonmal berichtet habe...) > noch erfolgreich irgendwelche Projekte umsetzen! [...] > Grundverständnis zu haben, aber manchmal muss es Zack auf Zack gehen und > dann zählt nur die Anwendung. Naja das ist Grundverständnis für mich. Ich finde das "OOP-Konstrukt" zum Lernen erstmal ganz ausreichend. Es ist im ersten Moment schon recht viel - Also es hilft nunmal beim logischen Denken in fast jeden Arbeitsschritt... Und das mit "Zack auf Zack" hab ich natürlich auch schon mehrfach erlebt - oder erleben müssen. Statisches Pfuschi ist das dann meist, was da raus kommt (oder verlangt wird) - wenn überhaupt was bei raus kommt (/bzw raus kommen kann). Und in neben-Thread(s) regt man sich wegen schlechter Programmierung über zig solcher Layer (übereinander) auf usw. Und nein ich bin kein Student ;-) Ich will diesen OOP Layer wie anfangs beschrieben auch selber zumindest verstanden haben - und mit den ganzen Listen und den Raw-Staff hatte ich anfangs noch einen kleinen "Knoten" in der Birne (der Knoten ist jetzt aber Disposed!) Hat sich alles kompensiert und aufgelößt... Wenn ich am PC (egal wo) irgendwass in der Richtung sehe, kann ich direkter besser Rückschlüsse ziehen usw. Und ohne das zu können, komme ich mir irgendwie albern vor ;-) wenn ichs dann trotzdem benutzen oder anwenden sollte o. müsste oder gar will - nee. Wäre ja irgendwie komisch mit "geht hald einfach so". Also Danke nochmal! Das ist wie "c-hater" es oben beschrieben hat: Beitrag "Re: OOP SourceCode" Man muss sich ja nicht gleich alle Layer und Funktionen zeilengenau reinziehen. Aber das Grundverständnis brauch ich schon... ___ Und angeregt durch den Thread (von cpu_builder), Beitrag "Re: diskrete CPU" wollte ich noch fragen, ob es möglich ist, diesesn "OOP Layer" komplett in Hardware zu realisieren, oder ob es solch eine CPU schon irgendwo gibt? dass z.B. die Hardware die "klassischen konstrukte" wie Events \ Invokes \ Handler [Exceptions] kann und die Types über 'ByteArray-Größen' in den Instanzen "kennt", und dadurch z.B. Table-Offsets auch ebenso 'gleich kennt' und nicht erst rechnen muss(?) - Kurz gesagt über so ne art Memory-Controller oder Mapper fürs OOP in HW!? Oder dass schon Hardware-Mäßig die 'Accessoren' (private public) 'nutzbar' sind!? Gibts sowas? Lernkette FPGA? ___ Tim S. schrieb: > Und da kommt so ne Art "Basic" bei raus, aber ich will´s mit JSON > Syntax. Dirk K. schrieb: > BTW: Was meinst du mit JSON-Syntax? JSON ist ein > Dateiformat zum Austausch von Daten, das hat mit > einer Programmiersprache recht wenig zu tun. Ich meinte damit ja, dass man in das ECMA-JSON 'ne Sprache oder Objekte rein-packen' kann (als Austauschformat) - also dass man eine komplette (Beschreibungs-)Sprache mit diesem Syntax bauen kann - worauf die meisten "modernen" Anwender-Sprachen ja eh schon irgendwo basieren. Ich meine damit grob 'des mit den Klammern, und kein Basic')
Tim S. schrieb: > Und angeregt durch den Thread (von cpu_builder), > Beitrag "Re: diskrete CPU" > wollte ich noch fragen, ob es möglich ist, diesesn "OOP Layer" komplett > in Hardware zu realisieren, oder ob es solch eine CPU schon irgendwo > gibt? Noch ein Klassiker ;) https://en.wikipedia.org/wiki/Rekursiv bzw. dessen Vorläufer und Nachfolger auf http://www.merlintec.com/swiki/hardware/26.html andere, die mehr oder weniger vollständig die Java-Virtual-Machine implementieren, sind z.T. hier aufgeführt: http://www.cpushack.com/CPU/cpu7.html und https://en.wikipedia.org/wiki/Java_processor
Tim S. schrieb: > Ja richtig, das dauert ein Weilchen... Also ich bin verwirrt: Gehe ich Recht in der Annahme, dass du wissen möchtst, wie OOP auf Assembler-Ebene umgesetzt wird, um sie evtl. in Hardware abzubilden? Du musst dich auseinandersetzen mit dem Compilerbau, da wird gelehrt, wie man es umsetzen könnte. Praktisches Anschauungsmaterial liefern die GNU-Compiler für OO- Sprachen, offene Java-Implementierungen, Google Go, Mono.NET-Implementierung, ... genügend quelloffene Compiler für Jahre an Reverse Engineering. Ich denke, du unterschätzt den Aufwand. Es wird kein Tutorial geben, dass dir in kurzer Zeit die ganze Problematik erklärt. Allein zur Theorie (Compilerbau, Formale Sprachen, Grammatiken) gibt es meterweise Literatur, da könnte man ein eigenes Studienfach daraus machen. Auch die praktische Umsetzung ist alles andere als trivial: C++ wird jetzt 40 Jahre alt, und erst seit einigen Jahren gibt es Compiler, die den Umgang damit erträglich gestalten. merciless
Tim S. schrieb: > Sorry - dass ich mich hier so lange nicht gemeldet habe. Du könntest auch mal das folgende lesen, dann wird deine OOP Begeisterung womöglich etwas abnehmen: https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
Dirk K. schrieb: > genügend quelloffene > Compiler für Jahre an Reverse Engineering. Naja so krass ist es auch wieder nicht. Tim S. schrieb: > Und ich mach noch diesen "statischen" layer drüber, für den Compiler und > Crossover. Der parst den Source, teilt das in Blöcke und Abschnitte auf (und kann damit optimierungen machen), und setzt das ganze "statisch" und Wörterbuch-Mäßig für die Zielhardware und dessen Register und (Stack) Eigenheiten um, und spuckt es letztendlich Binary aus. Also mal ganz ohne fremde OS Calls oder Framework Layer Eigenschaften und Funktionen dazwischen beschrieben. Da muss ich mir eher die Ziel-Plattformen Datasheets [Reverse Engineering] anschauen für den "Compilerbau". Dirk K. schrieb: > Ich denke, du unterschätzt den Aufwand. Es wird kein > Tutorial geben, dass dir in kurzer Zeit die ganze > Problematik erklärt. Allein zur Theorie (Compilerbau, > Formale Sprachen, Grammatiken) gibt es meterweise > Literatur, da könnte man ein eigenes Studienfach daraus > machen. Der Einwand ist natürlich klar. ;-) Das geht nicht alles von heute auf morgen. Und das hab ich ja jetzt drinnen. Und damit komm ich erstmal wieder weiter... ;-) Dirk K. schrieb: > Also ich bin verwirrt: Gehe ich Recht in der Annahme, > dass du wissen möchtst, wie OOP auf Assembler-Ebene > umgesetzt wird, um sie evtl. in Hardware abzubilden? Es läuft wohl darauf hinaus. Aber in Software reicht erstmal völlig. Das bekomm ich zam! - In Hardware wäre dann das Langzeit Lebensprojekt Hobby Lernkette [FPGA] fortsetzung usw. Darum auch erst die Frage ob es das schon gibt. ^^ Die Java Cpus hatte ich schon fast wieder vergessen ;-) Aber wie gesagt, nur das OOP-Konstrukt (in Software) reicht jetzt erstmal. Stefan S. schrieb: > Du könntest auch mal das folgende lesen, dann wird deine OOP > Begeisterung womöglich etwas abnehmen: > > https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 Ok habe ich gelesen. Das ist ne Anregung: Sodass du trotzdem nur die Banane haben kannst. (Ohne Gorilla der sie hält, und ohne den Urwald drum rum) Und so ein Modell stricke ich ja grade. Noch kann ich alte Krücken beseitigen oder gar nicht erst aufkommen lassen. Schwerpunkt ist Kommunikation und fürs IOT. Und ich will 'Types' und Instanzen möglichst "verlustfrei", so wie die 'grad Runtime sind' mit Modell Serialisieren und Speichern oder (übers Netz) Cross transporieren können usw. (Dazu der OOP "Layer") Insgesammt soll Source- sowie (kompilierte)Runtime- und Flash/Ram (Instanzen) und Debug Inhalt aus so ziemlich der selben Sprache bzw. Code bestehen (auch wenn es Overhead bekommt), (Ja vll sogar mal direkt in Hardware - ihr habt mich überzeugt) und ich mir dann eigentlich sogar Compiler spaaren kann. So dass ziemlich direkt in HW Startadressen von Types u. Instanzen für die Member rumgeschoben werden (MemoryCtrl. u. ArbeitsRegister), und die CPU dann gleich darauf ihren "ASM" Befehl (RechenRegister) Ausführen kann. Dass es immer nur "RuntimeCode" gibt. Und wenn (z.B) irgendwass zu 'private' ist, gibts ne Exception. Eben 'direkt' OOP. Den Stack /Layer in Hardware oder so. Ähnlich wie Grafikkarten die Triangles oder Physics übernehmen. Aber das ist ja alles wieder ein ganz anderes Thema und das dauert natürlich noch sehr viel länger. Sorry nochmal an alle, die nur Buzzwort-Bingo gelesen o. verstanden haben. Und dass ich meine vorherigen Beiträge nicht mehr gelesen hab :-) @georg: Das war aneinander vorbeigeredet und ne kleine Verwechslung - Ja ich hab bisschen übern Tisch gezogen nach den Vorwüfen (Daher kam auch die "Pause" von mir), und es war nicht dein URL. Gruß tsx
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.