Hast recht hab das mit char durcheinander gebracht , denn dort kann man statt mit "" Text zuzuweisen es auch wie im folgenden Beispiel handhaben ,und ihnen integrale Typen zuweisen /damit rechnen .Quote:
Das hingegen würde 1010 ausgeben:Code:int z1=10; int z2=10; std::cout<<(z1+z2);
Code:std::string z1="10"; std::string z2="10"; std::cout<<(z1+z2);
#include <iostream>
int main()
{
char s1 = 1;
char s2 = 5;
std::cout << (s1+s2);
std::cin.get();
}
Ich arbeite auch mit Microcontrollern und jetzt? Ich bleibe dennoch der Ansicht, dass jeder Takt, der wegoptimiert werden kann, ein guter Takt ist.Quote:
Wenn du auf jeden Takt hinaus willst, landest du gezwungenermaßen bei Assembler.
Ich Programmiere auch µC und weiß sehr wohl, wann es auf Geschwindigkeit ankommt. Aber hier bist du einfach falsch.
Vorallem wird sich der Flaschenhals niemals bei std::cout/std::string o.ä. befinden.
Natürlich wird das da gemacht. Programmiert er hier etwas zeitkritisches? Wie schon angedeutet, arbeite ich auch mit µCs und weiß sehrwohl, dass es oft auf jedes einzelne Bit ankommt. Aber wir sind hier an Desktoprechnern und man benutzt keine Sprache wie C++, um dann auf all die tollen Vorzüge zu verzichten.
Quellen?Quote:
Gibt auch viele Tests, die das Gegenteil von deinem Test behaupten.
Dann scheint es mir logisch, dass du so einseitig denkst. Denn richtig Software (also für n Desktop-Rechner) hast du noch nicht entwickelt - sonst wüsstest du, dass deine Art der "Optimierung" einfach eine veraltete ist. Und mit Entwickelt meine ich jetzt nicht, daheim im Kellerchen alleine dies oder das gecodet.Quote:
Ich arbeite auch mit Microcontrollern und jetzt?
Warum benutzt du dann kein Assembler?Quote:
Ich arbeite auch mit Microcontrollern und jetzt? Ich bleibe dennoch der Ansicht, dass jeder Takt, der wegoptimiert werden kann, ein guter Takt ist.
Also widersprichst du mir in der Aussage, dass die von mir genannten Features Vorzüge von C++ sind? Denn das sind sie, da wirst du mir ja zustimmen. Und diese nicht zu benutzen, weil man damit _anscheinend_ ein paar Takte sparen kann, sehe ich definitiv als Misshandlung von C++ an. Als wolle man seinen Porsche nur im ersten Gang fahren.Quote:
Man muss ja nicht auf alle Vorzüge verzichten, aber man kann ein "richtig" oder "falsch" programmieren nicht als "Vorzüge benutzen" oder "Vorzüge nicht benutzen" sehen.
Das mit dem Glashaus, den Steinen usw. ist dir bekannt? Wie wäre es, erstmal selber Quellen zu seinen Tests zu posten?Quote:
Quellen?
[Only registered and activated users can see links. Click Here To Register...] (hab den Test mal selbst ausgeführt, bei mir kommt raus: printf = 9ms, cout = 25ms) als Beispiel.. ist recht umstritten.Quote:
Abgesehen von einem Browsergame auf Code-Basis, die 100% Handarbeit war, das ich leite, habe ich auch noch nie kommerzielle Software entwickelt, da hast du Recht. Dafür aber genug Open-Source Projekte, vor allem Parser.Quote:
Warum benutzt du dann kein Assembler?
Also widersprichst du mir in der Aussage, dass die von mir genannten Features Vorzüge von C++ sind?
Das mit dem Glashaus, den Steinen usw. ist dir bekannt? Wie wäre es, erstmal selber Quellen zu seinen Tests zu posten?
Ich programmiere so viel wie geht ausschließlich mit der WinApi.Quote:
Du könntest noch ein paar Takte sparen, wenn du komplett auf cout/printf verzichtest. Wie wäre es, ganz auf Winapi-Ebene runterzugehen und selber mit der Console rumzuspielen? Da lässt sich ganz sicher noch der ein oder andere Takt sparen!
Steht im 1. Link von dir. Jo, sprich sofern man bei einem cout eine Variable mitgeben möchte (was ja auch in meinem Test der Fall war) soll man aufgrund von Performanceverbesserung im ms Bereich zu printf statt cout greifen. Finds schwachsinnig, da es einfach unsauberer Code ist, wenn man nach Lust und Laune (oder eben nach Performance) mal printf mal cout benutzt.Quote:
cout with some stuff and '\n' 2638.272046 ms
printf with some stuff and '\n' 2520.318314 ms
Wie wärs damit: Benutze Assembler, wenn _nötig_.Quote:
Ich benutze wenn möglich auch Assembler.
Genau, und da scheinst du dir ein wenig selbst zu widersprechen. Du führst das Beispiel komplexe 3D-Spiele an. Genau richtig, es gibt Passagen, in denen man alles auf Performance setzt. In allen anderen Situationen (in denen es nicht nötig ist), verwendet man lieber vector/list statt nem Array oder cout statt printf (von irgendwelchen vorgeschriebenen guidlines mal abgesehen).Quote:
Aber dennoch wie oben bereits geschrieben muss man das von der Komplexität der Programme abhängig machen
Doch, das heißt es im gewissen Maße. Wenn man C++ schreibt, dabei alle tollen, hochoptimierten(!) Features der Sprache nutzt, das Programm keine Performanceprobleme macht und der Code sauber und übersichtlich ist, dann ist das richtig programmiert.Quote:
Nein ich widerspreche da nicht, aber dennoch kann man nicht sagen, dass "richtig" programmieren heißt die Vorzüge auszunutzen, man kann "richtig" programmieren definieren wie man will.
Hast du dir deine Beispiele eigentlich selber mal durchgelesen?Quote:
@Quellen
Nur 2 Beispiele:
printf vs cout in C++ - Stack Overflow
cout or printf which of the two has a faster execution speed C++? - Stack Overflow
Danach werden noch genug Gründe aufgezählt, warum cout einfach besser, weil moderner, ist.Quote:
[15.1] Why should I use <iostream> instead of the traditional <cstdio>?
Increase type safety, reduce errors, allow extensibility, and provide inheritability.
Genau, was ich bis jetzt immer sagte.Quote:
In practice, the difference shouldn't matter for all but the weirdest cases. If you think it really matters - measure!
Was trotzdem nicht immer das schnellste ist (auch das hab ich dir schon versucht zu erklären). Funktionen der Standardlib oder auch der STL können so weit optimiert sein, dass diese nicht langsamer, sondern auch schneller sind.Quote:
Ich programmiere so viel wie geht ausschließlich mit der WinApi.