C++ int+ char = String !?

[marykillsjane]

Originally Posted by Shadow992

int z1=10;
int z2=10;

std::cout<<(z1+z2);

Das hingegen würde 1010 ausgeben:

std::string z1="10";
std::string z2="10";

std::cout<<(z1+z2);

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 .

#include <iostream>
int main()
{
	char s1 = 1;
	char s2 = 5; 


std::cout << (s1+s2);
std::cin.get();

}

Aber wie gesagt das sollte man nicht machen ,da es so nach meinem Buch zumindest oft zu Fehlern kommen kann.

[Delinquenz]

Ich bin einfach der Meinung, dass, wenn du char dem std::string vorziehst, du unsauber codest. Es sei denn, du hast mit alten C-WinAPI Funktionen o.Ä. zu tun. Da muss man halt leider manchmal zu einem Char-Array greifen.

Gibt auch viele Tests, die das Gegenteil von deinem Test behaupten.

[Shadow992]

Originally Posted by Schlüsselbein

Du willst es einfach nicht verstehen. Wo ist dein C++, wenn du keine Virtuallen Methoden, keine sauberen Container wie std::vector, std::queue usw. benutzen kannst? Keine Iterator? Keine Streams?
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.

Ich arbeite auch mit Microcontrollern und jetzt? Ich bleibe dennoch der Ansicht, dass jeder Takt, der wegoptimiert werden kann, ein guter Takt ist.
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.

Edit:

Originally Posted by Delinquenz

Ich bin einfach der Meinung, dass, wenn du char dem std::string vorziehst, du unsauber codest. Es sei denn, du hast mit alten C-WinAPI Funktionen o.Ä. zu tun. Da muss man halt leider manchmal zu einem Char-Array greifen.

Gibt auch viele Tests, die das Gegenteil von deinem Test behaupten.

Quellen?

[Schlüsselbein]

Ich arbeite auch mit Microcontrollern und jetzt?

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.

Ich arbeite auch mit Microcontrollern und jetzt? Ich bleibe dennoch der Ansicht, dass jeder Takt, der wegoptimiert werden kann, ein guter Takt ist.

Warum benutzt du dann kein Assembler?

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.

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.

Quellen?

Das mit dem Glashaus, den Steinen usw. ist dir bekannt? Wie wäre es, erstmal selber Quellen zu seinen Tests zu posten?

[Delinquenz]

Originally Posted by Shadow992

Quellen?

(hab den Test mal selbst ausgeführt, bei mir kommt raus: printf = 9ms, cout = 25ms) als Beispiel.. ist recht umstritten.

Wenn man jedoch als Beispiel std::endl verwendet, dann verlangsamt das das ganze nochmal etwas (habs letzten im C++-Forum.de gelesen).

[Schlüsselbein]

Ach hey, was mir noch einfällt.
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!

[Shadow992]

Originally Posted by Schlüsselbein

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.

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?

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.

Ich benutze wenn möglich auch Assembler.
Aber dennoch wie oben bereits geschrieben muss man das von der Komplexität der Programme abhängig machen, hat man einfach Encryption/Decryption-Programme, dann benutze ich auch Assembler, bei String-Parsern oder Compilern wird dann aber dennoch auf C/C++ gesetzt, eben weil hier eine gewisse Abstraktion besteht.

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.

@Quellen
Nur 2 Beispiele:




Edit:

Originally Posted by Schlüsselbein

Ach hey, was mir noch einfällt.
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!

Ich programmiere so viel wie geht ausschließlich mit der WinApi.

[Delinquenz]

cout with some stuff and '\n' 2638.272046 ms
printf with some stuff and '\n' 2520.318314 ms

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.

[Seife_]

Falls es euch nicht auffällt, was ihr da rumdiskutiert ist mehr als der Threadersteller verstehen wird und will. printf und cout hin oder her, jeder entwickelt den Stil den er für richtig hält.

[Schlüsselbein]

Ich benutze wenn möglich auch Assembler.

Wie wärs damit: Benutze Assembler, wenn _nötig_.

Aber dennoch wie oben bereits geschrieben muss man das von der Komplexität der Programme abhängig machen

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).

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.

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.
Und auf Performance optimiert man eben nur dann, wenn es nötig ist.

Noch ne Sache, die dir scheints nicht in den Kopf will:
Der Flaschenhals wird zu 99% kein std::vektor, std::string oder was anderes aus der Standard-lib sein. Es wird zu 99% der Algorithmus selber sein.

@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

Hast du dir deine Beispiele eigentlich selber mal durchgelesen?
Zum ersten:

[15.1] Why should I use <iostream> instead of the traditional <cstdio>?

Increase type safety, reduce errors, allow extensibility, and provide inheritability.

Danach werden noch genug Gründe aufgezählt, warum cout einfach besser, weil moderner, ist.
Gleiches gilt auch für deinen zweiten Link.

In practice, the difference shouldn't matter for all but the weirdest cases. If you think it really matters - measure!

Genau, was ich bis jetzt immer sagte.

Ich programmiere so viel wie geht ausschließlich mit der WinApi.

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.
cout und printf könnten zB. puffern etc.

Dazu auch noch ein Link:






Gruß

[Master674b]

Es gibt kein Programm das schon bereits so stark von der eigentlichen Logik her optimiert wurde, dass Hyperoptimierung überhaupt ansatzweise Sinn machen würde...

Benutz gefälligst die STL / Boost denn genau darin liegt die Zukunft. In Sachen Geschwindigkeit schreibt die STL gar nicht vor wie etwas implementiert ist und auch die Compiler sind mittlerweile so intelligent, dass die sowieso jeden unnötigen Overhead weg optimieren.

[Schlüsselbein]

Das will ich ihm ja die ganze Zeit erklären, aber er scheints nicht verstehen zu wollen.
Ich kling mich hier mal aus, scheint so, als würde ich gegen eine Wand reden.

[MrSm!th]

Er ist auch ziemlich unverbesserlich. Ich würde vorschlagen ihr beendet das jetzt und jeder macht so weiter, wie er oder sein Vorgesetzter es für richtig hält.