Delphi und C++

[Christian Seehase]

Moin Yankee,

Zitat von Yankee:

btw: was sind denn inline-Funktionen *beiWikipediaNichtsfind*

Vielleicht hättest Du mal in der C++ Referenz vom MSDN schauen sollen

Verkürzt gesagt:
Bei Inline-Funktionsaufrufen wird der Code der Funktion jedesmal in das Programm eingefügt, und nicht zu einem Unterprogrammaufruf übersetzt.

[w3seek]

Zitat von r_kerber:

Und warum mit .Net beschäftigen? Weil in den nächsten Windows .Net die Betriebssystem-API ist! Also wird jeder Windows-Entwickler sich früher oder später damit beschäftigen müssen.

Da irrst du dich gewaltig

[PierreB]

Zitat von w3seek:

Zitat von r_kerber:

Und warum mit .Net beschäftigen? Weil in den nächsten Windows .Net die Betriebssystem-API ist! Also wird jeder Windows-Entwickler sich früher oder später damit beschäftigen müssen.

Da irrst du dich gewaltig

Wenn du sowas schon schreibst, würde ich eine Erklärung/Erläuterung für sehr sinnvoll halten.

Also, warum irrt er sich ?

[yankee]

Zitat von Christian Seehase:

Verkürzt gesagt:
Bei Inline-Funktionsaufrufen wird der Code der Funktion jedesmal in das Programm eingefügt, und nicht zu einem Unterprogrammaufruf übersetzt.

Das könnte bei vielen sehr kleinen Funtkionen natürlich irgendwie schon ein Vorteil sein. Bei großen Funktionen fällt das dann wahrscheinlich garnicht ins Gewicht. Aber macht das das Programm nicht viel größer, wenn man davon viel Gebrauch macht? *kopfkratz*. Also irgendwie bin ich nicht so sehr überzeugt, dass das jetzt so ein Kick für die Geschwindigkeit ist...
Was ja auch mal interessant wäre, ist, wie es mit der Compileroptimierung aussieht. Ich kenne da ein paar Leute, die meinen gcc optimiert den c++-code viel besser als Delphi den Pascal Code. Irgendeinen Grund muss es ja schon haben, dass der Delphicompiler deutlich schneller ist.

[Tubos]

Zitat:

Zitat:

Verkürzt gesagt:
Bei Inline-Funktionsaufrufen wird der Code der Funktion jedesmal in das Programm eingefügt, und nicht zu einem Unterprogrammaufruf übersetzt.

Das könnte bei vielen sehr kleinen Funtkionen natürlich irgendwie schon ein Vorteil sein. Bei großen Funktionen fällt das dann wahrscheinlich garnicht ins Gewicht. Aber macht das das Programm nicht viel größer, wenn man davon viel Gebrauch macht? *kopfkratz*. Also irgendwie bin ich nicht so sehr überzeugt, dass das jetzt so ein Kick für die Geschwindigkeit ist...

Ob das Programm größer wird, kommt ganz drauf an. Ist die Methode/Funktion groß und wird an vielen Stellen aufgerufen wird die EXE natürlich größer. Sieht die Methode hingegen so aus (pseudocode, hab die delphi syntax schon vergessen):

Code:

inline methode GetNumber(), rückgabewert ganzzahl
begin
gebe die variable number zurück
end

... dann wird der Code überhaupt nicht größer, vielleicht sogar kleiner weil ein einzelner Variablenzugriff aus weniger Assemblerinstruktionen als ein Funktionsaufruf besteht.
Ich inline alle derartigen Funktionen. Wenn ich weiß dass ich die Methode/Funktion nur an einigen wenigen Stellen im Programm aufrufe und sie dort allerdings sehr oft aufgerufen wird, dann inline ich auch wenn etwas mehr Code drinnen steht*.
Im obigen Beispiel zeigt sich der entscheidende Vorteil: Objektorientierte Programmierung mit Get/Set-Methoden völlig ohne Performanceeinbußen!

Zitat:

Also irgendwie bin ich nicht so sehr überzeugt, dass das jetzt so ein Kick für die Geschwindigkeit ist...

Wenn du eine Funktion verdammt oft aufrufst (bei irgendwelchen Berechnungen leicht möglich) sind inline-Funktionen sehr sinnvoll. Kann je nach Code einen ganz schönen Performancevorteil bringen. Ein Funktionsaufruf ist mit einem nicht zu unterschätzenden Aufwand verbunden.
Die CPU muss an eine andere Codstelle springen, viele Register müssen in den RAM geschrieben und beim Rücksprung wieder geladen werden.

*) Zu beachten ist dass der Compiler entscheiden kann, eine Funktion nicht zu inlinen obwohl ich es will. Manche Compiler inlinen auch Funktionen, die ich nicht mit inline angegeben habe. Es kann sogar vorkommen dass der Code an einigen Stellen inline und an anderen normal eingebunden wird!

[LarsMiddendorf]

Delphi2005 kann doch auch inline Funktionen.

[Stefan S.]

Volkards C++ Tutorial ist nicht nur absolut veraltet, es ist auch schlichtweg ungeeignet. Für jemanden der sich mal so nebenbei C++ anschauen möchte ist das Tutorial ganz brauchbar, wer aber die Erlernung von C++ in Erwägung zieht kann sich schonmal mit einigen Büchern eindecken! C++ ist eine wahnsinnig komlexe Sprache. Diesen Satz liest man oft in Foren. Viele wissen aber nicht was das bedeutet und was genau damit gemeint ist. Sie haben es nur mal irgendwo gehört. Erst wenn man sich über Jahre mit C++ beschäftigt beginnt man das zu verstehen. Ich musste im ersten Semester mit C anfangen (kannte nur delphi bis dato) und wir sind übergegangen zu C++. Mittlerweile habe ich schon 10 C++ Bücher gelesen und langsam beginne ich diesen Satz zu verstehen und glaube das es niemanden gibt der C++ vollständig beherrscht. Die C++ Standard Template Library ist schlichtweg der Hammer. Ich kenne keine Sprache die dermaßen viele Möglichkeiten besitzt wie C++. Und es macht enorm Spass in dieser Sprache zu programmieren . Trotzdem lerne ich gerade Java (wird von der Witschaft verlangt...), welches zum Glück sehr sehr ähnlich zu C++ ist. Was auch nicht sonderlich verwundert wenn man bedenkt das Java als Nachfolger von C++ vorgesehen war.

C/C++ wird deshalb in den meisten Stellenangeboten ausgeschrieben, weil C/C++ nunmal für Enterprise Applikationen der Industriestandard ist. Auf den Universitäten wird Delphi nicht einmal als Nebensprache in der Informatik offeriert. Die meisten Hochschulen beginnen mit C, gehen im dritten Semester zu C++ über und bleiben dabei. Grund hierfür liegt in der Möglichkeit sich sehr systemnah in der Sprache auszudrücken. In den ersten Semestern des Informatikstudium programmiert man kaum, sondern befasst sich nur theoretisch mit Algorithmen und Datenstrukturen. Diese werden dann mittels C/C++ implementiert, weil diese Sprache dafür gradezu prädestiniert ist. Java und C#, welche im übrigen ebenfalls einen großen Teil des Marktes ausmachen, werden ebenfalls unterrichtet. Microsoft hat enge Verbindungen zu Hochschulen über die Academic Alliance. Ich frage mich manchmal wie die Zukunft von Delphi aussieht?! C# in Verbindung mit .NET, JAVA und C/C++ decken alle Bereiche ab und werden von der Industrie und den jeweiligen Herstellern immens gepusht.

C/C++ hat in den letzten Jahren Bereiche an Java und C#/.NET abgeben müssen. In der Wirtschaft ist Produktivität ein kostbares Gut. C# und Java verfügen über große Klassenbibliotheken und erleichtern viele Arbeitsprozesse die in C++ einfach zu viel Zeit in Anspruch nehmen würden. .NET wird von Microsoft massiv gefördert. Die enge Verzahnung mit C# und Clientapplikationen im Internet (ASP) haben dazu beigetragen das C# stark im Kommen ist. Man könnte fast von einer schleichenden Unterwanderung auf dem Windows Sektor sprechen. C++ wurde unter der Common Language Infrastructure in .NET intergiriert, weil Microsoft seine C++ Resourcen nicht aufgeben will bzw. kann. Dennoch bleibt C++ für viele Firmen eine wichtige Programmiersprache, weil C/C++ Programmierer in der Regel über sehr viel Erfahrung und Know How interner Prozesse in der Informatik verfügen und derzeit Interpretersprachen in der Performance hinterherhinken und zu leicht zu dekompilieren sind. Weshalb für Java immer mehr Obfuscator, Ahead-of-Time- und JIT-Compiler auf den Markt drängen.

Die Zukunft gehört definitiv den Interpretersprachen. Java und C# werden bald den Großteil in der Wirtschaft ausmachen. Selbst PHP-Programmierern (Scriptsprachen) werden die $$$ hinterher geschmissen. C/C++ genießt den Vorteil das es eine ausgereifte und bewährte Programmiersprache ist, vollständig in nativen Code kompiliert, ein riesiger Codebestand existiert und systemnahe Programmierung zulässt. Die Zukunft Delphi's sehe ich leider als nicht sonderlich rosig an .

So, wer bis hier durchgehalten hat - ein großes Lob !

cu

[runger]

Hallo,

die Einschätzung, dass die Internetsprachen die Zukunft beherrschen, teile ich nicht.
Längst wurde eingesehen, dass wir mit den alten Programmiersprachen flexibler und Hardware-näher programmieren können. ( Programmier mal mit Java Prozesskommunikation über serielle Schnittstelle )
Die ganze Prozess-verarbeitung und visualisierung ist längst wieder weg von Java und Ähnlichem.

Rainer

[ripper8472]

hardwarenah ok. ich mag c allein wegen der pointergeschichten und assembly bin ich auch nicht abgeneigt.

aber von flexibel kann nicht die rede sein. wenn du einmal python programmiert hast, wirst du dir deine behauptung nochmal durch den kopf gehen lassen.
hoch- und scriptsprachen haben vorteile, die mit performanceverlusten erkauft werden. dafuer ist die entwicklungszeit wesentlich kleiner und man kann sich auf die aufgabe konzentrieren.

von "websprachen" wuerd ich nicht reden. java ist keine websprache sondern plattformunabhaengig.

[Stefan S.]

Zitat von runger:

Hallo,

die Einschätzung, dass die Internetsprachen die Zukunft beherrschen, teile ich nicht.
Längst wurde eingesehen, dass wir mit den alten Programmiersprachen flexibler und Hardware-näher programmieren können. ( Programmier mal mit Java Prozesskommunikation über serielle Schnittstelle )
Die ganze Prozess-verarbeitung und visualisierung ist längst wieder weg von Java und Ähnlichem.

Rainer

Lies dir mal folgenden Link durch http://www.elektroniknet.de/topics/e...0006/index.htm!

Ich habe nicht geschrieben das Interpretersprachen generell die Sprachen der Zukunft sein werden. Ich schrieb das sie mehr und mehr an Bedeutung gewinnen werden! Eine ausführlichere Erklärung für meine Ansicht findest du in dem oben angegebenen Link. Auch Assembler ist heute noch in der Industrie die erste Wahl wenn es um zeitkritische Routinen oder um systemnahe Programmierung, z.B. von Mikrocontrollern geht. Client-seitige Programmierung, Internet-Applikationen nehmen allerdings immer größere Bereiche in der Softwarebranche ein. Um das zu erkennen bedarf es keines Experten. Dazu reicht ein Blick in die Stellenanzeigen (http://www.getafreelancer.com/ ...).

Java verbessert sich schrittweise jedes Jahr. Mit dem JDK 5.0 wurden einige Funktionen aus C/C++ eingeführt darunter die Generics. Die Industrie hat zwischen 1998-2003 massiv auf Java gesetzt. Mittlerweile switcht man aber teilweise wieder auf C/C++ um. Eben weil Teilbereiche der Programmierung nicht von Java abgedeckt werden können. Das ändert allerdings nichts an der Tatsache das C++ Bereiche an Java abgeben musste. Mit der Einführung von C# und Microsoft's Entscheidung die Sprache fest im Markt zu verankern ergibt sich nun die Situation, das es de facto drei Programmiersprachen gibt die sich den Markt in Zukunft teilen werden. Alle drei stehen nicht im direkten Konkurrenzkampf zueinander, da sie größtenteils unterschiedliche Sektoren abdecken und ihre individuellen Stärken und Schwächen (Comparison of Java to C++) haben. Dennoch spricht vieles für Interpretersprachen, auch wenn sie in naher Zukunft die herkömmlichen Programmiersprachen sicher nicht verdrängen werden. Es stellt sich aber dann die Frage, welchen Sprachen ich größere Prioritäten einräume und welchen weniger. Diese Frage sollte jeder für sich selbst beantworten !