Forum: PC-Programmierung OOP SourceCode


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
-2 lesenswert
nicht lesenswert
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
von Teo D. (teoderix)


Bewertung
0 lesenswert
nicht lesenswert
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

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
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
von Teo D. (teoderix)


Bewertung
0 lesenswert
nicht lesenswert
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)

von foobar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
-2 lesenswert
nicht lesenswert
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
von A. S. (achs)


Bewertung
5 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Peter M. (r2d3)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Purzel H. (hacky)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Klugscheisser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
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...

von M.K. B. (mkbit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
-2 lesenswert
nicht lesenswert
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
von foobar (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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 
.

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
-2 lesenswert
nicht lesenswert
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.

von M.K. B. (mkbit)


Bewertung
3 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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

von Dirk K. (merciless)


Bewertung
2 lesenswert
nicht lesenswert
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
von G. P. (gpnt)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Arc N. (arc)


Bewertung
2 lesenswert
nicht lesenswert
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
von c-hater (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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...

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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')

von Arc N. (arc)


Bewertung
0 lesenswert
nicht lesenswert
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

von Dirk K. (merciless)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.