spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"carli"«

Zitat von »"dot"«

Funktionsaufrufe sind in C wie in C++ normalerweise ziemlich lightweight.

Nicht bei VisualStudio (bei anderen Sachen konnte ich mangels Lust, den GDB anzuschmeißen nicht nachprüfen)

Unsinn, VS versucht nach bestem Wissen und Gewissen zu optimieren (und das kann VS gut, garantiert). Weiß nicht was daran teuer ist. Ein Overhead entsteht hauptsächlich durch mitgeschleifte Debuginformationen.

Zitat von »"carli"«

kann sein - ich hab das VStudio nach den ersten disassembles von der Platte geschmissen (aber es ging irgendwie nicht runter!)

Warum denn? Visual Studio kommt mit einem (mittlerweilen) erstklassigen Compiler.

also mir ist es egal wie der maschinencode aussieht. hauptsache er ist möglichst leicht(wichtig ist übersichtlichkeit) zu erstellen, schnell, klein und liefert das erwartete ergebnis oder nicht?

//aus dem anderen thead, verspätet, weil während der ursprünglichen spaltung geschrieben...

Zitat von »"carli"«

Gibt es nicht - ich habs selbst disassemblet. C++ hingegen macht einen Riesen Overhead wenn ich z.B. eine Funktion aufrufe, schiebt er erstmal alle möglichen Register rum und ruft irgendwelche Funktionen auf (die ich niemals ganz durchtracen konnte) - dass nenne ich Overhead!

Zitat von »"carli"«

Das ist so ne Frage.
Unter allen Delphi-Versionen (welche allesamt win32 sind) funktioniert der Handoptimierte Code immer noch - einfach weil die Parameterübergabe in den Registern standardisiert ist.

das ist ebenn der punkt: die Aufrufkonvention:
Delphi hat eine aufrufkonvention, die deiner aussage nach mit registern arbeitet.
C++ hat standardmäßig cdecl, was eben ausschließlcih über den stack arbeitet, daher das registergeschubse. Kannst aber auch problemlos auf fastcall umstellen, dann hast du parameterübergabe in registern...

ein wenig zusätzliches Registergeschubse dürfte außerdem bei virtuellen funktionen während der dereferenzierung entstehen.

Zu den mysteriösen funktionen: das werden wahrscheinlich die kopierkonstruktoren irgendwelcher übergebenen objekte sein, falls die nciht geinlined werden - und selbst eventl. wieder funktionen aufrufen...deshalb soll man in C++ komplexe objekte ja möglichst per referenz übergeben

für mich sind die gründe, c++ zu nehmen:
- c++ ist kostenlos, die Delphi-Entwicklungsumgebung ist kostenpflichtig
- c++ hat eine (meiner meinung nach sehr einfache syntax (die Begin und End;-Anweisungen finde ich schrecklich unübersichtlich))
- kann man mit delphi überhaupt mit zeigern arbeiten?
- c++ hat mehr operatoren, so wie ++,--,==,&& etc..., wobei diese in Delphi AND, OR, = und vor allem <> heißen, mit welchem ich gar nicht zurecht komme
- auch die schleifen sind viel einfacher, so muss in Delphi bei der for-schleife als bedingung immer der endwert dastehen, wobei dies in c++ vollkommen frei ist...

es mögen alles kleine und zweifelhafte punkte sein, aber dadurch (und manches andere) steht für ich die entscheidung fest: C++

mfg CBenni::O

Zitat von »"carli"«

C ist eine Sprache aus den frühen 70ern und beherrscht ja nichtmal das Konkatenieren von Strings......

Oha, da hat jemand aber den Sinn von C nicht so recht verstanden und was das "Besondere" an strings gegenüber primitiven Datentypen ist.

Das selbe ist auch zu beziehen auf deine anderen Postings. In C die nicht existierende Objektorientierung zu Bemängeln im Vergleich zu einer hybriden Sprache wie C++ ist schon so schwachsinnig dem Papst bei seinem Geburtstag einen Porno von Gina Wild zu schenken.

Und noch was am Rande: C und C++, Pascal und co. kennen keine Konsole. Im Standard steht nichts von "Console".

Also bitte, nicht soviel Blödsinn daher reden und sich so zu präsentieren als ob man nicht mehr alle Latten am Zaun hat, sondern mehr nachdenken. Jede Sprache hat seine Existenzberechtigung und sein spezielles Anwendungsgebiet. Ach noch was: Dein Delphi-Compiler und das JDK sind in C geschrieben. Nur so nebenbei.

Zitat

Ach noch was: Dein Delphi-Compiler und das JDK sind in C geschrieben. Nur so nebenbei.

Eiffelstudio (IDE/Compiler für Eiffel) geht da noch einen Schritt weiter und generiert C Code, den er dann sogar mit meinem C++ Compiler compiled..

Ist eigentlich der normale weg. Bis Visual Studio 2003 wurde der C++ Code erst in C "konvertiert" und dann "assembliert". Da eine VTBL zu erzeugen so einfacher ist.

Matlab hatte glaube ich auch so eine relativ "interessante" Einstellung, dass es auch C-Code erzeugt.

Zitat von »"unsigned long"«

Ist eigentlich der normale weg. Bis Visual Studio 2003 wurde der C++ Code erst in C "konvertiert" und dann "assembliert". Da eine VTBL zu erzeugen so einfacher ist.

Jup. Ich finde das einfach einen sehr interessanten Aspekt. Vor allem um zu zeigen, dass man in den meisten Sprachen eigentlich alles tun kann.
Ich finde es rein Entwicklungstechnisch sogar eine gute Sache. Wofür denn auch die ganze Basis neu schreiben, wenn das ja bereits getan ist (sogar noch weiter entwickelt wird). Als Programmierer nervt das ständige doppelte compilen aber irgendwann ein wenig.

Och das macht nichts. C ist für viele Hochsprachen oft der kleinste gemeinsame Nenner mit dem man praktisch alles abbilden kann und auf portablem Wege - wenn man nicht gerade APIs mit einbezieht.