C++? C#? Pythong?

iKernelOS schrieb:
Das stimmt.
Meine eigentliche Idee ist es ein Text-Spiel mit Python zu erstellen, aber ich habe nicht im geringsten die Ahnung eine Art Zeitspanne zwischen den "geprinteten" Texten zu erstellen.

Wie bereits gesagt wurde: die Wahl der Sprache ist in deinem Fall vollkommen irrelevant. Dir fehlt einfachstes Grundwissen. Und ohne viel, viel, viel Googlen und viel, viel, viel Dokumentation lesen wird das nix.

Das Problem lässt sich in 2 Sekunden Googeln, sogar mit deutschen Begriffen:

http://lmgtfy.com/?q=python+print+warten

Der erste Link ist schon die richtige Antwort.
 
Und ohne Begründung bleibt dein post leider einfach nur überflüssig und erweckt nur den Eindruck dass du ein Fanboy bist.
 
Zuletzt bearbeitet:
1. Nicht jeder C Code ist gleichzeitig C++, siehe https://en.m.wikipedia.org/wiki/Compatibility_of_C_and_C++
2. Ist die resultierende Maschinensprache auf die von Assembler abgebildet wird meistens schneller weil der Compiler die Maschinensprache von C/C++ erzeugt. Und was automatisch von einem Programm generiert wird ist nicht immer perfekt du Schlaumeier.
3. Das Stroustrup das über C++ mit der Geschwindigkeit sagt ist ja wohl nicht wirklich eine neutrale Meinung. Andere Quelle http://stackoverflow.com/questions/6955114/is-c-notably-faster-than-c

Achja nochmal, der Compiler übersetzt in Maschinensprache und nicht Assembler. Wenn du schon klugscheisst solltest du erst mal die Grundbegriffe auseinander halten können.
 
Zuletzt bearbeitet:
Man muss ja nicht gleich beleidigend werden.

Zu 1.: Wenn mans genau nimmt, hast du Recht.
Zu 2.: hää?
Zu 3.: Stroustrup kennt sich zumindest besser mit c++ aus wie die meisten StackOvervflow user. Wo genau soll jetzt nach deiner Quelle C++ noch einmal langsamer sein?

Zu Rest: Je nach Compiler kann man auch zu Assembler übersetzen lassen, was aber eigentlich sowieso irrelevant ist, weil man Assembler eins zu eins in Maschinencode wandeln kann und umgekehrt? Schließlich entspricht das einer bijektiven Abbildung.
 
Hab mir das Video heute auch angeschaut gehabt und möchte mal dazu Stellung beziehen:
L0g4n schrieb:
2. Ist die resultierende Maschinensprache auf die von Assembler abgebildet wird meistens schneller weil der Compiler die Maschinensprache von C/C++ erzeugt. Und was automatisch von einem Programm generiert wird ist nicht immer perfekt du Schlaumeier.
Compiler kriegen üblicherweise den Assemblercode besser hin, als ein Mensch ihn schreiben könnte - eben aufgrund der krassen Optimierungen, die da gefahren werden (und damit meine ich vorallem bei kommerziellen Compilern á la Intel Compiler, etc.).

L0g4n schrieb:
Achja nochmal, der Compiler übersetzt in Maschinensprache und nicht Assembler. Wenn du schon klugscheisst solltest du erst mal die Grundbegriffe auseinander halten können.
Compiler an sich besteht aus Linker und Assembler u.a.. Wenn man den Compiler im engeren Sinne meint, dann ist das natürlich das Tool, welches Hochsprachen-Code (C, C++) in Assembler übersetzt. Man kann sich bei bspw. gcc den übersetzten Assemblercode auch generieren lassen und danach aufhören:
Code:
gcc -S helloworld.c
I.d.R. meint man mit Compiler natürlich die gesamte Suite an Tools, die da läuft - also Präprozessor, Hochsprachen-Übersetzer, Assembler und Linker.

Und zum Thema wurde eigentlich schon genug gesagt. Zum Programmieren (egal für was) braucht es vor allem Eigeninitiative.
 
Gelöst ---- Danke an alle
 
Zuletzt bearbeitet von einem Moderator:
Mickey Cohen schrieb:
entweder c oder lass es bleiben.

c++ oder gar c# sind nur für billigste excel-tabellen-alternativen gedacht.

was bei so objekt-orientierter pseudo-programmierung rauskommt hat man ja leider die letzten jahre zu oft gesehen. was früher an code ein paar kb groß war geht heute in die gigabyte, weil die leute zu dumm zum coden sind.
C oder bleiben lassen? Von welchem Planeten kommst du denn? Es gab gewiss schlechte OOP Software. Aber es gab genauso auch sehr gute. Ebenso wie es schon bescheidene und gute C-Programme gab. Das liegt meist nicht an der Sprache, sondern am Programmierer.

Btw. an deinem Horizont musst du noch etwas arbeiten. Und an deiner Rechtschreibung übrigens auch.

greetz
hroessler
Ergänzung ()

The Ripper schrieb:
C++ soll langsamer als C sein, schon alleine dadurch falsch, da jeder C Code auch C++ Code ist. Dadurch ist C++ schon alleine mindestens so performant wie C.
Naja, die OOP bringt doch schon einen gewissen Overhead mit. C muss sich ja nicht mit Sachen wie z.B. Polymorphismus (vtables) rumschlagen. C++ wird, falls OOP programmiert, nicht ganz die Performance von C erreichen. Aber C wird auch nicht meilenweit davonziehen...

greetz
hroessler
 
Zuletzt bearbeitet von einem Moderator:
@Hroessler: C++ muss sich auch nicht mit vtables rumschlagen, wenn man keine virtuellen Funktionen nutzt. Aberr ja, in C++ ist es definitiv einfacher langsamen Code zu schreiben, weil man ineffizientem Code häufig nicht ansieht, dass er ineffizient ist.
 
Alles, was man in C machen kann, kann man genauso mit derselben Performance in C++ tun.
Benutzt man Sprachfeatures, die es in C nicht gibt, dann kann der Code zwar durch diese Features langsamer werden,
aber das ist dann natürlich kein fairer Vergleich, weil man sich ja bewusst für das langsame Feature entschieden hat.
Umgekehrt kann man z.B. vtables auch in C bauen, nur muss man das dann eben per Hand tun und schneller als die compilergenerierte vtable in C++ dürfte es nicht sein.

Andererseits bietet gerade die stark verbesserte Typsicherheit in C++ zusammen mit Templates Möglichkeiten zur Kompilieroptimierung, die sich in C nur schwer per Hand abbilden lassen (z.B. beim Sortieren eines Arrays von kleinen Structs).
 
Andererseits bietet gerade die stark verbesserte Typsicherheit in C++ zusammen mit Templates Möglichkeiten zur Kompilieroptimierung, die sich in C nur schwer per Hand abbilden lassen
Templates sind Turing-Vollständig. Das macht optimieren von C++-Code viel viel schwieriger als bei C-Code und unter Umständen sogar unentscheidbar.

Außerdem wird Optimierung dadurch erschwert, dass die Grammatik von C++ grundsätzlich nicht entscheidbar ist.
Was bedeutet folgender Ausdruck: A * B (C)? Das kann man nur entscheiden, wenn die Semantik bekannt ist.
Das selbe mit dem Ausdruck A B (C). Umso mehr, wenn A für "Template<foo>::bar" steht.

€: Grundsätzlich ist eine simple Sprache leichter zu optimieren als eine Komplexe.
C ist sehr simpel, während C++ sehr komplex ist. So sehr, dass man im Extremfall nicht einmal entscheiden kann, ob ein Programm ein C++ Programm ist, oder nicht.
 
Zuletzt bearbeitet:
@asdfman: Redest du jetzt von manueller Optimierung oder Compileroptimierung?
 
Na Compileroptimierung. Das habe ich doch zitiert. :/
 
asdfman schrieb:
Templates sind Turing-Vollständig. Das macht optimieren von C++-Code viel viel schwieriger als bei C-Code und unter Umständen sogar unentscheidbar.

Außerdem wird Optimierung dadurch erschwert, dass die Grammatik von C++ grundsätzlich nicht entscheidbar ist.
Was bedeutet folgender Ausdruck: A * B (C)? Das kann man nur entscheiden, wenn die Semantik bekannt ist.
Das selbe mit dem Ausdruck A B (C). Umso mehr, wenn A für "Template<foo>::bar" steht.

€: Grundsätzlich ist eine simple Sprache leichter zu optimieren als eine Komplexe.
C ist sehr simpel, während C++ sehr komplex ist. So sehr, dass man im Extremfall nicht einmal entscheiden kann, ob ein Programm ein C++ Programm ist, oder nicht.

Templates bieten dem Compiler in manchen Fällen deshalb bessere Optimierungsmöglichkeiten, weil der komplette Code für ihn sichtbar ist. Am Beispiel von std::sort, hier wird als Vergleichsfunktion ein funktionsähnliches Objekt übergeben. std::sort muß hier also nicht jedes Mal eine Funktion über einen Pointer aufrufen sondern kann den Vergleichscode inlinen.
 
Dann ergibt aber einiges von dem was du sagst keinen Sinn.
Templates z.B. erhöhen zwar potentiell die Compilezeiten, aber erschweren nicht die Optimierung. Im Gegenteil: dort wo sie zum Einsatz kommen (generischer Code) erleichtern sie die Optimierung im Vergleich zu äquivalentem C-code sogar. Ich das kanonische Beispiel ist wie von antred beschrieben qsort vs std::sort. Bei std::sort kann der Compiler zur Compilezeit sehr einfach feststellen, welche Funktion als Komparator aufgerufen wird und wie viele Bytes jeweils geswappt werden müssen, weil eben für jeden Typ eine eigene Funktion generiert wird was eine optimale Codegeneration erlaubt. Im Fall von qsort sind beides erst mal Laufzeitvariablen,was eine Optimierung viel schwerer macht.

Die Tatsache das Templates Turing-Vollständig sind bedeutet einfach nur, dass man den Compiler in c++ zwingen kann mehr oder weniger beliebige Berechnungen zur Compilezeit durchzuführen (auch wenn man dazu eher constexpr Funktionen nutzen sollten), während man bei C++ auf die Optimierungsfähigkeiten "hoffen" muss. Generell hat das aber keinen Einfluss auf die Optimierungsmöglichkeiten.

Generell erschweren zusätzliche Sprachfeatures imho nur dann die Optimierung, wenn sie die Freiheitsgrade des Compilers einschränken oder es dem Compiler schwerer machen lokal (also z.B. innerhalb einer Funktion) bestimmte Variablenwerte und/oder Programmpfade auszuschließen bzw. vorherzusagen. Das einzige mir bekannte C++ Feature, dass hier evtl. zu Nachteilen führen kann sind Exceptions, aber erfahrungsgemäß ist der impact Minimal. Was c++ allerdings fehlt und hilfreich wäre ist ein Äquivalent zu restrict
 
asdfman schrieb:
Templates sind Turing-Vollständig. Das macht optimieren von C++-Code viel viel schwieriger als bei C-Code und unter Umständen sogar unentscheidbar.

Außerdem wird Optimierung dadurch erschwert, dass die Grammatik von C++ grundsätzlich nicht entscheidbar ist.
Was bedeutet folgender Ausdruck: A * B (C)? Das kann man nur entscheiden, wenn die Semantik bekannt ist.
Das selbe mit dem Ausdruck A B (C). Umso mehr, wenn A für "Template<foo>::bar" steht.

€: Grundsätzlich ist eine simple Sprache leichter zu optimieren als eine Komplexe.
C ist sehr simpel, während C++ sehr komplex ist. So sehr, dass man im Extremfall nicht einmal entscheiden kann, ob ein Programm ein C++ Programm ist, oder nicht.
Wirklich, du ziehst einen Beitrag heran der ein total aus der Luft gegriffenes Template als Beispiel nimmt und so niemals in der Praxis vorkommt?
Grade durch Metaprogrammierung hilft dabei guten und wartbaren Code zu schreiben. Compiler profitieren von Templates da sie hier bessere Entscheidungen treffen können ob inline sinnvoll oder nicht. Auch weiß der Compiler ganz genau welche Typen verwendet werden was ebenfalls bei der optimierung hilft.
Das schlimmste ist Code bei denen der Entwickler meinte er wäre ganz schlau und meint er könnte Sachen welche in der STL vorhanden sind ja mit C-Style Code viel schneller schreiben was dann so gut wie immer in viel, langsamen und schlecht wartbaren Code endet. Solch dämlichen Code habe ich jeden Tag bei der Arbeit vor mir und darf die Scheisse berichtigen. Das ist dann sehr lustig wenn man nach ein wenig Refactoring statt 300 Zeilen Code der fehlerhaft ist manchmal nur noch 10 oder 20 Zeilen hat die fehlerfrei sind und auch noch schneller.

PS: C++ Truth ist so ziemlich die dämlichste Seite die mir die letzten Jahre untergekommen ist. Dort sind so viele Falschaussagen zu finden...
 
Miuwa schrieb:
Dann ergibt aber einiges von dem was du sagst keinen Sinn.
Templates z.B. erhöhen zwar potentiell die Compilezeiten, aber erschweren nicht die Optimierung.
Logisch erhöhen sie die Compilezeiten. Schließlich veranlassen Templates den Compiler Code zu erzeugen den er dann wiederum behandeln muss.
Die Compilezeiten von C++ sind sowieso schon unterirdisch. Freiwillig tut sich das doch keiner an.



Fonce schrieb:
Das schlimmste ist Code bei denen der Entwickler meinte er wäre ganz schlau und meint er könnte Sachen welche in der STL vorhanden sind ja mit C-Style Code viel schneller schreiben was dann so gut wie immer in viel, langsamen und schlecht wartbaren Code endet. Solch dämlichen Code habe ich jeden Tag bei der Arbeit vor mir und darf die Scheisse berichtigen. Das ist dann sehr lustig wenn man nach ein wenig Refactoring statt 300 Zeilen Code der fehlerhaft ist manchmal nur noch 10 oder 20 Zeilen hat die fehlerfrei sind und auch noch schneller.
Was ist denn das für ein Vergleich? In die STL wurde echt viel investiert und Du vergleichst das mit irgendeinem dahergelaufenen C Programmierer.

Wo es zum Beispiel auf Geschwindigkeit ankommt ist z.B. in Betriebssystemkernel. Dummerweise sind die meistverbreitetsten Kernel alle in C geschrieben (zumindest zum größten Teil). Entweder sind die Entwickler alle durch die Bank weg Trottel oder sie haben sich tatsächlich dabei was gedacht. :-)

Fonce schrieb:
PS: C++ Truth ist so ziemlich die dämlichste Seite die mir die letzten Jahre untergekommen ist. Dort sind so viele Falschaussagen zu finden...
Man gut, dass Du Deine Aussage gleich noch mit ein paar Beispielen untermauert hast. Sonst könnte man denken, das wär ne haltlose Behauptung. :-)
 
asdfman schrieb:
Templates sind Turing-Vollständig. Das macht optimieren von C++-Code viel viel schwieriger als bei C-Code und unter Umständen sogar unentscheidbar.

Außerdem wird Optimierung dadurch erschwert, dass die Grammatik von C++ grundsätzlich nicht entscheidbar ist.
Was bedeutet folgender Ausdruck: A * B (C)? Das kann man nur entscheiden, wenn die Semantik bekannt ist.
Das selbe mit dem Ausdruck A B (C). Umso mehr, wenn A für "Template<foo>::bar" steht.

€: Grundsätzlich ist eine simple Sprache leichter zu optimieren als eine Komplexe.
C ist sehr simpel, während C++ sehr komplex ist. So sehr, dass man im Extremfall nicht einmal entscheiden kann, ob ein Programm ein C++ Programm ist, oder nicht.

In deinem Beispiel wurde ein grotesk ineffizienter Algorithmus via Template-Metaprogramming implementiert und aufgerufen. Natürlich dauert das dann lange, was soll auch sonst passieren? Hätte man den denselben Algorithmus nicht via Template-Metaprogramming implementiert, würde das Programm eben schnell kompilieren, aber ewig rechnen. Nochmal: Schlechte Programme und ineffiziente Algorithmen lassen sich in jeder Sprache implementieren.
 
Fonce schrieb:
PS: C++ Truth ist so ziemlich die dämlichste Seite die mir die letzten Jahre untergekommen ist. Dort sind so viele Falschaussagen zu finden...

maxwell-cs schrieb:
In deinem Beispiel wurde ein grotesk ineffizienter Algorithmus via Template-Metaprogramming implementiert und aufgerufen. Natürlich dauert das dann lange, was soll auch sonst passieren? Hätte man den denselben Algorithmus nicht via Template-Metaprogramming implementiert, würde das Programm eben schnell kompilieren, aber ewig rechnen. Nochmal: Schlechte Programme und ineffiziente Algorithmen lassen sich in jeder Sprache implementieren.
(u.v.a.m.)

Ich muss mich gerade für den Link ziemlich schämen. Um Reue zu zeigen, poste ich den Link zum Paper, aus dem der Code stammt und in dem bewiesen wurde, dass Templates Turing-vollständig sind:
http://netvor.sk/~umage/docs/3rdpar...uring Complete (Todd L. Veldhuizen, 2003).pdf

Die Tatsache das Templates Turing-Vollständig sind bedeutet einfach nur, dass man den Compiler in c++ zwingen kann mehr oder weniger beliebige Berechnungen zur Compilezeit durchzuführen
Nein, es bedeutet viel mehr. Man kann eine Turingmaschine in Form von C++-Templates implementieren und damit die Entscheidbarkeit von C++ auf das Halteproblem zurückführen (Spoiler: Das Halteproblem ist nicht entscheidbar).

Generell hat das aber keinen Einfluss auf die Optimierungsmöglichkeiten.
Man kann im Allgemeinfall nicht entscheiden, ob ein vorgelegter Text ein C++-Programm ist oder nicht. Also auch nicht, ob man das Vielleichtc++programm optimieren kann, oder nicht. Das halte ich schon für einen gewissen Einfluss. So ein vager Begriff wie "Optimierungsmöglichkeiten" hat keine konkrete Bedeutung, auf die ich irgendwie antworten könnte. Manchmal kann man Code mit Templates optimieren. Aber wie kann man das quantifizieren, um deiner Behauptung Gewicht zu geben?
 
Zuletzt bearbeitet:
Zurück
Oben