vorteile einer virtual machine?

[BWL-Manager]

Erklär das mal unserer Geschäftsführung, oder einem anderen WI/BWL'er

[Artchi]

Termite schrieb:

auserdem bringen VMs noch andere nette sachen mit wie z.B. garbageCollector, eine ReflectionApi und eine intigrirte Lib Schnitstelle ( zumindest in java)

GCs haben doch nichts mit VMs zu tun. GCs sind eine reine Implementierungssache. Wenn z.B. Windows keinen GC anbietet, kann das eine VM "besorgen". Aber genausogut könnte auch Windows oder ein C++ Compiler sowas mitliefern. Bufferoverflow-Schutz z.B. kann ich in meinem VC++7.1 Compiler aktivieren! Hat aber mit C++ an sich nicht viel zu tun, dann macht das halt die Runtime. Reflections könnte man auch in C++ machen, auch ohne VM. Ich kann immerhin in C++ schon mit typename den Klassennamen als String erhalten. D.h. diese Reflection-Information (ich nenn das jetzt mal so) ist schon in der Runtime drin. Kann man aber auch abschalten. Nur ist halt in C++ nicht der Reflectionumfang definiert, aber es gibt im C++ Commitee einen Vorschlag für umfassendes Reflection - trotzdem wird C++0x keine VM verlangen.

[net 0]

frenki schrieb:

Du brauchst sowieso alle Plattformen, für die du dein Programm rausgibst. Oder willst du mir erzählen, das du ein Programm, das du meinetwegen in Java unter Linux entwickelt hast einfach so für Windows freigibst, ohne es jemals getesetet zu haben?

ich kenn jemand der hat 'ne ziemlich fette anwendung in java unter windoofs gecodet. mit allem schnickschnack wie datenbankanbindung an'ne db2, client-zu-client kommunikation, client-server über's internet usw. bei der inbetriebnahme unter linux musste nur _eine_ programmzeile geändert werden (irgendwas mit der gui sah nicht so schick aus). ich schätze mal so easy geht portieren nur mit java

[Termite]

Hi

Nativ compiler für java gibts doch.

Java und .Net haben zumindest für BWL er den Vorteil, das da die sachen wie GC, Reflaction, GUI, Netzwer, ... bereits bestandteil der sprache sind. Andersrum müsste man sich das ja alles zukaufen oder seber entwickeln. Stichpunkt kosten und fehler.

Auserdem haben diese sprachen Marketingtechnische vorteile. Wenn jemand frägt ob man auch linux einsetzen könnte kann er antworten "kein problem wir setzen auf java. das läuft auf allen gängigen platformen."

Arber mir stellt sich gertade die Frage "Compile once, run anyware" hat ja mit java seine berechtigung. Die java vom gibts ja von sun für einige platformen.

Nur bei .Net frag ich mich was da eine VM Sinnmacht. Die gibts ja von MS ja nur für ihre eigenen Betriebsysteme. (Mono mal nicht betrachtet da nicht von MS) Oder ist das MS neue schnittstelle zum System? und sie haben das nur als VM entwickelt, damit die Leute sich drann gewöhnen können, wenn im nachfolger von longhorn z.B nur noch diese schnitstelle zur verfügung steht.

gruss

[Gast]

- Ich kann prozessorspezifisch optimieren.
- Compile once, run anywhere gewinnt heute an Bedeutung durch verschiedene Prozessorarchitekturen. Überlegt mal:
IA64, x86_64 und x86 mal Windows, Linux gibt schon mal 6 verschiedene Kombinationen.
- Sicherheit: Ich kann ein und das selbe Programm mit verschiedenen Sicherheitseinstellungen laufen lassen, ohne es dauernd überwachen zu müssen. Ich muss nicht bei jeder Anforderung nach einem Socket-Handle prüfen, ob das Programm das darf. Stattdessen start ich das Programm mit "no sockets!" und der JIT-Compiler pflanzt dann im native Code überall SecurityExceptions rein.
- Ich kann Code flexibler gestalten. Klassen dynamisch zur Laufzeit hinzuladen. Runtime-Reflection. Das sind Dinge, die immer mehr an Bedeutung gewinnen. Diese Flexibilität krieg ich ohne JIT-Compilierung fast nicht hin.

[Artchi]

Termite schrieb:

Nur bei .Net frag ich mich was da eine VM Sinnmacht. Die gibts ja von MS ja nur für ihre eigenen Betriebsysteme. (Mono mal nicht betrachtet da nicht von MS) Oder ist das MS neue schnittstelle zum System? und sie haben das nur als VM entwickelt, damit die Leute sich drann gewöhnen können, wenn im nachfolger von longhorn z.B nur noch diese schnitstelle zur verfügung steht.

Hem, du hast dich eben gerade unglaubwürdig gemacht. Warum muß die .NET VM von MS kommen? Das will mir nicht in mein Gehirn rein. C# und das .NET Baseframework sind in der ECMA zertifiziert: ein freier Standard, und somit kann und SOLL nicht nur MS die VM und das Framework auf anderen Plattformen implementieren. Ist also wie mit C++: jeder darf .NET implementieren. (nur WindowsForms und ein paar andere .NET-Teile sind nicht in der ECMA)

Bei Java ist das nicht so. Darfs nur deine JavaVM auch JavaVM nennen, wenn du ordentlich Kohle an SUN abgedrückt hast.

[interpreter]

BWL-Manager schrieb:

Dazu kommt, daß C++ bei den Führungskräften in dem Ruf steht schwer zu sein und Java/C# leichter zu sein.

Nicht nur bei "Führungskräften"

[Gast]

Artchi schrieb:

Bei Java ist das nicht so. Darfs nur deine JavaVM auch JavaVM nennen, wenn du ordentlich Kohle an SUN abgedrückt hast.

Sicher? Eclipse und JBuilder haben schon mal ihren eigenen Compiler und IBM ne eigene VM (1.4 glaub ich) und ich kann mir nicht so wirklich vorstellen, dass die dafür zahlen mussten.
Letztlich gibt es auch eine öffentlich einsehbare JVM specification.

[mathik]

Optimizer schrieb:

- Ich kann prozessorspezifisch optimieren.
- Compile once, run anywhere gewinnt heute an Bedeutung durch verschiedene Prozessorarchitekturen. Überlegt mal:
IA64, x86_64 und x86 mal Windows, Linux gibt schon mal 6 verschiedene Kombinationen.

eine VM muss auch für diese Plattformen irgendwie entwickelt und kompiliert werden. Und es gibt ja genug gute Compiler für diese Plattformen. Und wenn ich für den Kunden für jede Plattform eine Binärversion anbiete, was hat man da für einen Nachteil?

Optimizer schrieb:

- Sicherheit: Ich kann ein und das selbe Programm mit verschiedenen Sicherheitseinstellungen laufen lassen, ohne es dauernd überwachen zu müssen. Ich muss nicht bei jeder Anforderung nach einem Socket-Handle prüfen, ob das Programm das darf. Stattdessen start ich das Programm mit "no sockets!" und der JIT-Compiler pflanzt dann im native Code überall SecurityExceptions rein.

ja ok, aber wieso wird dafür dieser Bytecode benötigt? Man könnte doch auch den bereits vorhandenen native code mit SecurityExceptions versehen.

Optimizer schrieb:

- Ich kann Code flexibler gestalten. Klassen dynamisch zur Laufzeit hinzuladen. Runtime-Reflection. Das sind Dinge, die immer mehr an Bedeutung gewinnen. Diese Flexibilität krieg ich ohne JIT-Compilierung fast nicht hin.

Dieser ganzer "Schnickschnack" kann doch auch im native Code gemacht werden.
Klassen, die dynamisch nachgeladen werden sollen, könnten z.B. in dynamische Bibliotheken, wie DLLs, ausgelagert werden. Man bräuchte eine standardisierte Schnittstelle dafür.

[BWL-Manager]

@mathik: Warum schwer, wenn es auch einfacher geht? Bei der Entwicklung VM ist jemand anderes verantwortlich. Du sparst jede Menge Zeit und kosten.

Bei den anderen Punkten das selbe. Warum das Rad neu erfinden und viel Geld in die Entwciklung stecken?

Im Buiness läuft es halt immer nach dem selben Schema: Man muss den breakeven zwischen Kosten und Nutzen finden. Genau diesen Punkt haben Sun und MS erkannt. Eine VM erleichtert dem Programmierer die Arbeit ungemein.

[Sovok]

mathik schrieb:

eine VM muss auch für diese Plattformen irgendwie entwickelt und kompiliert werden. Und es gibt ja genug gute Compiler für diese Plattformen. Und wenn ich für den Kunden für jede Plattform eine Binärversion anbiete, was hat man da für einen Nachteil?

n gewisser zeitaufwand wenn du updates für 20 plattformen erstellen musst

[mathik]

BWL-Manager schrieb:

@mathik: Warum schwer, wenn es auch einfacher geht? Bei der Entwicklung VM ist jemand anderes verantwortlich. Du sparst jede Menge Zeit und kosten.

Bei den anderen Punkten das selbe. Warum das Rad neu erfinden und viel Geld in die Entwciklung stecken?

Im Buiness läuft es halt immer nach dem selben Schema: Man muss den breakeven zwischen Kosten und Nutzen finden. Genau diesen Punkt haben Sun und MS erkannt. Eine VM erleichtert dem Programmierer die Arbeit ungemein.

ich bechaupte doch nicht, dass man das alles selber machen sollte, weil es dann viel besser ist. Ich finde sogar Java toll, weil diese Sprache eine solche umfangreiche Bibliothek hat, GC und Reflection anbietet. Ich würde sie allerdings noch toller finden, wenn Java-Programme auch ohne die VM laufen würden, und somit schnellere Startzeiten (Wegfall von JIT) und weniger Speicher fressen würden.

[interpreter]

Vorteile einer virtuellen Maschine:

Plattformunabhängigkeit: Programme für eine virtuelle Maschine laufen auf allen realen Maschinen, für die die virtuelle Maschine implementiert ist. Sie kann dadurch Architekturtransparenz schaffen.

dynamische Optimierung ist möglich

[BWL-Manager]

Wollte ich Dir auch nicht unterstellen. Aber gerade eine VM macht es einem so einfach(s. Optimizer's Beispiele).

Die langen Ladezeiten stören primär auch nur bei Desktopanwendungen. Ich pers. mag allerdings auch Binärcode lieber, aber man macht das was der Arbeitgeber möchte.

[Gast]

mathik schrieb:

Optimizer schrieb:

- Ich kann prozessorspezifisch optimieren.
- Compile once, run anywhere gewinnt heute an Bedeutung durch verschiedene Prozessorarchitekturen. Überlegt mal:
IA64, x86_64 und x86 mal Windows, Linux gibt schon mal 6 verschiedene Kombinationen.

eine VM muss auch für diese Plattformen irgendwie entwickelt und kompiliert werden. Und es gibt ja genug gute Compiler für diese Plattformen. Und wenn ich für den Kunden für jede Plattform eine Binärversion anbiete, was hat man da für einen Nachteil?

Ich habs doch grad aufgezählt, dass du gut und gerne auf 6 Versionen kommen kannst. Und es ist auch nicht völlig ausgeschlossen, wenn auch nicht das größte Problem, dass du vielleicht mal ein Problem mit einer von den 6 Versionen hast, was du sonst nicht hast.

Optimizer schrieb:

- Sicherheit: Ich kann ein und das selbe Programm mit verschiedenen Sicherheitseinstellungen laufen lassen, ohne es dauernd überwachen zu müssen. Ich muss nicht bei jeder Anforderung nach einem Socket-Handle prüfen, ob das Programm das darf. Stattdessen start ich das Programm mit "no sockets!" und der JIT-Compiler pflanzt dann im native Code überall SecurityExceptions rein.

ja ok, aber wieso wird dafür dieser Bytecode benötigt? Man könnte doch auch den bereits vorhandenen native code mit SecurityExceptions versehen.

Es geht darum, das Programm mit verschiedenen Einstellungen zu starten und du kannst den native Code nicht dynamisch anpassen. Lies es bitte nochmal.

Optimizer schrieb:

- Ich kann Code flexibler gestalten. Klassen dynamisch zur Laufzeit hinzuladen. Runtime-Reflection. Das sind Dinge, die immer mehr an Bedeutung gewinnen. Diese Flexibilität krieg ich ohne JIT-Compilierung fast nicht hin.

Dieser ganzer "Schnickschnack" kann doch auch im native Code gemacht werden.
Klassen, die dynamisch nachgeladen werden sollen, könnten z.B. in dynamische Bibliotheken, wie DLLs, ausgelagert werden. Man bräuchte eine standardisierte Schnittstelle dafür.

Nein, in dem Maße, wie es mit Java und .Net möglich ist, kriegst du das nicht mal annähernd hin. Ich sag nur: Runtime-Reflection. Ohne VM verflucht schwer und dynamisch Klassen hinzuzuladen, wie willst du das bitte bei native code machen? Ja, du brauchst ne standardisierte Schnittstelle dafür, *thumbs up*. Da bin ich gespannt, wie die aussehen soll. Vergiss es, fast nicht tragbarer Aufwand.
JIT-compilierter Code ist von Natur aus flexibler, das kannst du nicht wegdiskutieren. Du kannst für dich entscheiden ob du das willst und brauchst, aber dein fest kompilierter Native Code ist faktisch nicht so flexibel.

[Termite]

Hi

Artchi schrieb:

...
Hem, du hast dich eben gerade unglaubwürdig gemacht. Warum muß die .NET VM von MS kommen? Das will mir nicht in mein Gehirn rein. C# und das .NET Baseframework sind in der ECMA zertifiziert: ein freier Standard, und somit kann und SOLL nicht nur MS die VM und das Framework auf anderen Plattformen implementieren. Ist also wie mit C++: jeder darf .NET implementieren. (nur WindowsForms und ein paar andere .NET-Teile sind nicht in der ECMA)

...

ich geb zu ich hab noch nichts mit .Net gemacht. ich weis nur das es ein Basisframework von MS gibt und das für linux MONO entwickelt wird. Soweit ich das mal mitbekommen hat war MS federführen am .Net beteiligt. bzw hat das dan versucht es als standard festschreiben zu lassen. Mit mal wieder so schöhnen ausnahmen das ms sachen nur bei ms laufen und wo anders nicht.

Ich hab das gefühl MS den Standard nur als Alibi und wegen des Marketings gemacht hat.
Wer würde auf .Net umsteigen, wenn nur MS Compiler und Framework liefern dürfte? Und man dafür auch noch bezahlen müsste. ist ja dan so ähnlich wie mit Delphi von Borland.

[EDIT]
Weiter Vorteil für VMs. sie lassen sich ja unabhängig von der Anwendung warten. Somit kann auch eine Anwendung noch mit sicherheit patchen versorgt werden obwohl die Anwendung gar nicht mehr weiterentwickelt wird. ( sun hate ja mal nen fehler in der JRE 1.4.? ) währen das jetzt alles Nativ drin, hätte der Anwender nicht mal ne nöglichkeit so ein sicherheitsloch zu stopfen. Woher weis er was du verwendet hast, woher soll er das nötige update bekommen.

gruss

[ChockoCookie]

Ein echter Vorteil (zumindest von .net) ist ein vereinheitlichtes Klassenmodell zwischen verschidenen Sprachen (habe ich gerade "C DLLs in VB" gehört? *graus*). Das hat zwar primär nichts mit der VM zu tun, ist aber doch ein nettes Feature. Wenn .NET nur ein *wirklich* offener Standard wäre, ohne das MS wegen Sachen wie Mono mit den Patent - Ketten rasselt ...

[Ben04]

Optimizer schrieb:

mathik schrieb:

Dieser ganzer "Schnickschnack" kann doch auch im native Code gemacht werden.
Klassen, die dynamisch nachgeladen werden sollen, könnten z.B. in dynamische Bibliotheken, wie DLLs, ausgelagert werden. Man bräuchte eine standardisierte Schnittstelle dafür.

Nein, in dem Maße, wie es mit Java und .Net möglich ist, kriegst du das nicht mal annähernd hin. Ich sag nur: Runtime-Reflection. Ohne VM verflucht schwer und dynamisch Klassen hinzuzuladen, wie willst du das bitte bei native code machen? Ja, du brauchst ne standardisierte Schnittstelle dafür, *thumbs up*. Da bin ich gespannt, wie die aussehen soll. Vergiss es, fast nicht tragbarer Aufwand.
JIT-compilierter Code ist von Natur aus flexibler, das kannst du nicht wegdiskutieren. Du kannst für dich entscheiden ob du das willst und brauchst, aber dein fest kompilierter Native Code ist faktisch nicht so flexibel.

Ich hab mal nach Reflection gesucht, da ich nicht in Java eingearbeitet bin und bin auf folgenden Link gestossen:
http://java.sun.com/docs/books/tutorial/reflect/
(Fals dieser Link nicht das beschreibt was du unter Runtime-Reflection verstehst dann entschuldige ich mich im Voraus)

Ich seh da nichts was übermässig schwer mit nativ Code zu machen wäre, natürlich nur mit ein wenig Unterstüzung des Compilers und kompatiblen ABIs.

* Determine the class of an object.

typeid & dynamic_cast

* Get information about a class's modifiers, fields, methods, constructors, and superclasses
* Find out what constants and method declarations belong to an interface.

Kann der Compiler alles in den VTable packen.

* Create an instance of a class whose name is not known until runtime.

Das Factory Pattern unter der Compilerhaube.

* Get and set the value of an object's field, even if the field name is unknown to your program until runtime.

Offset und Type kann im VTable nachgeschlagen werden wenn der Compiler diese Information da reintut.

* Invoke a method on an object, even if the method is not known until runtime.

Kann man auch noch im Vtable nachschlagen. Alles was man braucht ist eine Map die den Funktionsnamen mit dem Funktionspointer assoziiert.

Hier kann man allerdings auch noch ein wenig optimiren indem man, nachdem man das erste mal den Namen nachgeschlagen hat, den Funktionsaufruf während der Laufzeit überschreiben um dann nächstes mal direkt die richtige Funktion aufzurufen. Der Compiler muss nur genügend NOPs während der Übersetzung reinpacken damit keine Sprünge durcheinander kommen. Wenn die Anzahl der Parameter bekannt ist, ist das auch kein Problem. Fals die Anzahl nicht bekannt ist kann man ein Arraypointer übergeben.

* Create a new array, whose size and component type are not known until runtime, and then modify the array's components.

Das ginge indem man std::vector von einer abstrakten Basisklasse erben lassen würde und in jeden VTable eine Funktion hinzufügen würde die ein std::vector für diese Klasse erstellt.

Jetzt mal ganz davon abgesehen, dass ich das meiste eher als Spielerei einstuffe als wirklich nützlich, ist nichts davon ohne VM unmöglisch oder wirklich schwerer als eine Implementirung ohne VM. Vieles würde ich sogar schwieriger mit einer VM die den Code in nativ Code übersetzt finden.

Der angebliche Vorteil der Anpssungfähigkeit des Bytecodes hink auch, denn wer hat gesagt, dass man dafür eine VM braucht? Man kann den Bytecode doch einfach in einem Installationsprogram in nativ Code übersetzen. Sehr ähnlich wird das doch schon heute mit sehr vielen open source Programmen gemacht, nur eben dass hier der Sourcecode zur Verfügung steht und kein Bytecode.

Weiter Vorteil für VMs. sie lassen sich ja unabhängig von der Anwendung warten. Somit kann auch eine Anwendung noch mit sicherheit patchen versorgt werden obwohl die Anwendung gar nicht mehr weiterentwickelt wird. ( sun hate ja mal nen fehler in der JRE 1.4.? ) währen das jetzt alles Nativ drin, hätte der Anwender nicht mal ne nöglichkeit so ein sicherheitsloch zu stopfen. Woher weis er was du verwendet hast, woher soll er das nötige update bekommen.

DLLs kann man auch austauschen, das heist Fehler in einer Biblothek können auch behoben werden. Ein Program in einer VM laufen zu lassen nur weil dem Compiler vielleicht ein Übersetzungsfehler unterläuft ist zwar ein Vorteil, allerings ein sehr schwacher Vorteil der Nachteile wie längere Ladezeit im Normalfall nicht aufwiegt.

Die hauptsächlichen Vorteile einer VM sind die gleichen wie die von jedem Interpreter. Der Code muss nicht installiert werden und kann daher sofort nachdem er zur Verfügung steht benutzt werden, sprich der Vorteil liegt bei vernetzten Rechnern von unterschiedlicher Platform die Code austauschen. Bei Desktoprechnern beschränkt das sich zum größten Teil auf Applets, Javascript und Ähnliches.

Man beachte bitte, dass viele Vorteile von Java Programmen weder etwas mit Java ansich, noch irgendetwas mit einer VM (wobei letzteres oft sogar ein Nachteil ist) zu tun haben. Java hat eine breitgefecherte Standard Bibliotek und wird auch ansonsten viel von Größen der IT Welt wie Sun gefördert. Das sind die wahren Vorteile von Java. Das gleiche gilt natürlich auch für .net.

Genau sowenig ist die Tatsache, dass viele Daus wahrscheinlich make als sehr schwer zu bedienen empfinden, ein teschniches Problem sondern eines einer bestimmten Implementirung. Hätte make ein GUI Interface wie viele Windows Installer, was teschnisch überhaupt kein Problem ist, würde das bereits viel bringen.

Desweiteren sind auch Portirungsproblem von C/C++ Programmen von Platform zu Platform oder Compiler zu Compiler ein Nachteil gegenüber Java allerdings kein Nachteil gegenüber einer VM. Wenn jede Java VM ihre eigenen Erweiterungen und ihre eigenen Biblioteken hätte dann würden, trotz VM, die gleichen Probleme herschen wie derzeit in der C/C++ Welt.

Viele Sprachen die eine VM haben Vorteile allerdings diese sind in der Regel nicht auf die VM zurück zu führen.

[Gast]

Ben04 schrieb:

Ich seh da nichts was übermässig schwer mit nativ Code zu machen wäre, natürlich nur mit ein wenig Unterstüzung des Compilers und kompatiblen ABIs.

* Determine the class of an object.

typeid & dynamic_cast

Das ist keine Reflection. Das Programm kennt natürlich seine Klassen, da ist nichts tolles dran. Interessant wird's erst, wenn du dynamisch Klassen hinzulädst. Ich kann z.B. ne IDE schreiben und dafür ne Plugin-Schnittstelle anbieten.
Ich les dann alle .class-Dateien in meinem plugins-Verzeichnis aus, die jeder Programmier nachträglich durch einfaches reinkopieren verändern oder hinzufügen kann. Für jedes Plugin erstelle ich einen Menüeintrag, nimm alle öffentlichen Methoden als Untermenü her und ruf sie nur noch auf, wenn der User den Eintrag auswählt.
Also (Pseudocode):

Bestimme Dateinamen aller .class Dateien
ladeKlase(dateiname)
Alle öffentlichen Methoden getten
erstelle dafür menüeinträge, die bewirken: invoke(methode)

Du kannst jetzt natürlich auch dein eigenes Format für Plugins entwerfen. Kannst irgendne config-Datei auslesen und dynamisch auf irgendwelche C-Funktionen in einer beiliegenden DLL linken. Dann hast du genau für diesen speziellen Anwendungsfall eine Lösung, die definitiv weniger schön ist.

* Get information about a class's modifiers, fields, methods, constructors, and superclasses
* Find out what constants and method declarations belong to an interface.

Kann der Compiler alles in den VTable packen.

Genau, für Klassen, die er kennt, kann er das tun. Aber nicht für Klassen, die erst zur Laufzeit hinzugeladen werden.

* Create an instance of a class whose name is not known until runtime.

Das Factory Pattern unter der Compilerhaube.

Höh? Du weißt doch zur Compilierzeit noch nicht mal, was die Klasse des zu erstellenden Objekts für Konstruktoren hat. Da bin ich ja mal gespannt. Wie du ohne JIT-Compilierung dann noch eine Factory erstellen kannst.

* Get and set the value of an object's field, even if the field name is unknown to your program until runtime.

Offset und Type kann im VTable nachgeschlagen werden wenn der Compiler diese Information da reintut.

Was für ne VTable? Es gibt keine VTable für Klassen, die du nicht compilierst. Und zur Laufzeit kriegst du die Infos nicht mehr, außer du kannst zur Laufzeit noch was reincompilieren -> JIT-compilierung

* Invoke a method on an object, even if the method is not known until runtime.

Kann man auch noch im Vtable nachschlagen. Alles was man braucht ist eine Map die den Funktionsnamen mit dem Funktionspointer assoziiert.

Wie gesagt - es gibt keine VTable.

Hier kann man allerdings auch noch ein wenig optimiren indem man, nachdem man das erste mal den Namen nachgeschlagen hat, den Funktionsaufruf während der Laufzeit überschreiben um dann nächstes mal direkt die richtige Funktion aufzurufen. Der Compiler muss nur genügend NOPs während der Übersetzung reinpacken damit keine Sprünge durcheinander kommen. Wenn die Anzahl der Parameter bekannt ist, ist das auch kein Problem. Fals die Anzahl nicht bekannt ist kann man ein Arraypointer übergeben.

Wie, wo was? Der Compiler kann zur Laufzeit in deinem Fall nichts mehr machen. Du kannst nur Methoden aufrufen
- deren Name du zur Compilierzeit kennst
- deren Signatur du zur Compilierzeit kennst

* Create a new array, whose size and component type are not known until runtime, and then modify the array's components.

Das ginge indem man std::vector von einer abstrakten Basisklasse erben lassen würde und in jeden VTable eine Funktion hinzufügen würde die ein std::vector für diese Klasse erstellt.

Auch wenn der Elementtyp und -größe erstmal zur Compilierzeit unbekannt ist? Ne. Wie willst du das machen? Du weißt ja noch nicht mal, ob dein dynamisch hinzugeladener Typ einen Standardkonstruktor hat.

Ich glaube, du hast nicht ganz bedacht, was Laufzeit-Reflection bedeutet. Du hast erstmal keine VTable und kannst sie erst zur Laufzeit erstellen, weil du vorher die Klassendefinition nicht hast. Du brauchst immer irgendein für deine Fälle angepasstes Format, oder von mir aus auch eins, was sehr flexibel ist, aber trotzdem wirst du nicht Klassen von anderen einfach reinladen können, wenn die anderen UND du dafür nicht spezielle Dinge vereinbaren.

btw. jetzt einen nativen JIT-Compiler schreiben zählt jetzt nicht.

[mathik]

Ben04 schrieb:

Man beachte bitte, dass viele Vorteile von Java Programmen weder etwas mit Java ansich, noch irgendetwas mit einer VM (wobei letzteres oft sogar ein Nachteil ist) zu tun haben. Java hat eine breitgefecherte Standard Bibliotek und wird auch ansonsten viel von Größen der IT Welt wie Sun gefördert. Das sind die wahren Vorteile von Java. Das gleiche gilt natürlich auch für .net.
...
Desweiteren sind auch Portirungsproblem von C/C++ Programmen von Platform zu Platform oder Compiler zu Compiler ein Nachteil gegenüber Java allerdings kein Nachteil gegenüber einer VM. Wenn jede Java VM ihre eigenen Erweiterungen und ihre eigenen Biblioteken hätte dann würden, trotz VM, die gleichen Probleme herschen wie derzeit in der C/C++ Welt.

Viele Sprachen die eine VM haben Vorteile allerdings diese sind in der Regel nicht auf die VM zurück zu führen.

Genau auf den Punkt gebracht. Das ist genau das, was ich meine!

@Optimizer
ich kann nicht nachvollziehen, warum man für Laufzeit-Reflection eine VM braucht. Man könnte auch jede Klasse native in eine .class Datei mit den ganzen Reflection-Informationen (wie Funktionssignaturen, Konstruktoren, etc.) packen. Dann generiert halt der Compiler für jede Klasse eine getClass():Class Methode. Diese Class hat dann die ganzen Reflection-Informationen, die man in Java auch hat. Dann kannste auch "ladeKlasse(dateiname)" aufrufen und mit den ganzen gettern die Informationen aus der .class Datei holen. (öffnet mal mit einem Editor eine .class Datei!)

In C++ ist (Laufzeit)-Reflection deswegen schwierig zu realisieren, weil es hierfür einfach keine Compiler-Unterstützung und keinen Standard fürs dynamische Laden gibt.

Ich bin ehrlich gesagt immer noch nicht von den Vorteilen einer VM überzeugt worden (außer bei den Server- und Applet-Geschichten). Der ganze andere Schnickschnack (Reflection, "SecurityExceptions") könnte meiner Meinung nach auch ohne eine VM realisiert werden.

Ich programmiere gerne in Java, weil es dort einfach eine geile Bibliothek für fast alles gibt.
Allerdings finde ich, dass Java noch erfolgreicher wäre, wenn es dort keine VM gäbe, weil dadurch die Anwendungen viel Speicher fressen und lange Startzeiten durch JIT haben. Die ganzen "Wartungssachen" sind für mich auch wirklich kein Argument. Ich denke jeder Anbieter kann es in Kauf nehmen, für jede Plattform eine native Version zu kompilieren (nicht neu zu schreiben!).