Problem: argv und string
-
wie wäre es eigentlich wenn du dir das bereits erwähnte strcpy ansiehst?
-
ich meinte strcpy, nicht strlen.
aber ich hatte schond as erste mal strcpy gesagt.also machs bitte jetzt auch.
-
printf ist schneller als cout, da es keine Klassen verwendet.
das halb c halb c++ ist mein Stil zu Programmieren, vielleicht ist es nicht nachvollziehbar, aber wenn, dann ist das mein Problem, aber Danke für den Hinweis

soviel ich weiß gibt es in den Standartbibliotheken auch keine Funktion, um argv in einem c-String zu speichern
-
gewi schrieb:
printf ist schneller als cout, da es keine Klassen verwendet.
Mann, Du hast ja wirklich die Weisheit mit dem Löffel gefressen. Mal im ernst: das ist patenter Quatsch. Klassen sind *nicht* a priori langsamer als Funktionen.
soviel ich weiß gibt es in den Standartbibliotheken auch keine Funktion, um argv in einem c-String zu speichern
Doch. 'std::strcpy'. Wie jetzt schon mehrmals gesagt worden ist.
-
gewi schrieb:
printf ist schneller als cout, da es keine Klassen verwendet.
Autsch.
gewi schrieb:
das halb c halb c++ ist mein Stil zu Programmieren, vielleicht ist es nicht nachvollziehbar, aber wenn, dann ist das mein Problem, aber Danke für den Hinweis

Es wird zu "unserem" Problem wenn du hier im Forum schreibst.
gewi schrieb:
soviel ich weiß gibt es in den Standartbibliotheken auch keine Funktion, um argv in einem c-String zu speichern
Lern lesen.
-
tut mir Leid, das erste strlen hat mich verwirrt, mit strcpy geht es, vielen Dank
man lernt echt nie ausZu dem Punkt, dass c schneller als c++ ist:
Ich habe ein Programm geschrieben, dass mir alle Zahlen von 1-10^7 in eine Datei schreibt. Dabei hat es c++ (ofstream) verwendet und die Zeit gemessen, und diese ausgegeben (mit printf). Dann wieder die gleichen Zahlen mit fprintf in eine Datei geschrieben, und die dafür benötigte Zeit mit printf ausgegeben, deswegen bin ich der Auffassung, dass c schneller als c++ ist.mfg gewi
-
Dann programmiere doch gleich in C, wenn es deiner mEinunge nach so viel schneller ist.
-
gewi schrieb:
Ich habe ein Programm geschrieben, dass mir alle Zahlen von 1-10^7 in eine Datei schreibt. Dabei hat es c++ (ofstream) verwendet und die Zeit gemessen, und diese ausgegeben (mit printf). Dann wieder die gleichen Zahlen mit fprintf in eine Datei geschrieben, und die dafür benötigte Zeit mit printf ausgegeben, deswegen bin ich der Auffassung, dass c schneller als c++ ist.
Ja, darum gab es auch schon einige Diskussionen im Forum. Zwei Bemerkungen dazu:
- Diese Ergebnisse sind je nach verwendetem Compiler und verwendeter Implementierung der Standardbibliothek *stark* unterschiedlich. Mal ist das eine schneller, mal das andere. Es gibt an sich keinen Grund, wieso C++-Streams langsamer sein sollten als C-Methoden.
- Der Grund, aus dem C++-IO theoretisch langsamer sein *könnte* ist der, dass die C++-IO-Klassen virtuelle Funktionen verwenden. Virtuelle Funktionen sind in der Tat langsamer als "normale" Methoden. Allerdings ist das in diesem Fall nicht ausschlaggebend.
Mit Klassen hat das aber in keinem Fall etwas zu tun. Die Verwendung von Klassen macht einen Code *nicht* langsamer.
-
ich habe MSVC++ verwendet
ok, dann habe ich wieder etwas dazu gelernt: c++ und c sind in etwa gleich schnell, die Unterschiede sind vernachlässigbar klein oder je nach Compiler anders. Danke für diese Info
mfg gewi
-
lässt sich so pauschal auch nicht sagen. viele reinen c-methoden, gerade diejenigen, die direkt auf dem speicher arbeiten, sind rasend schnell. aber das sind dinge, um die man sich nen kopf machen kann, wenn man in der lage ist, robuste und effiziente programme zu designen. das ist ein langwieriger prozess, der jahre dauert. und erst wenn man diesen stand erreicht hat, dann lohnt es sich, mal auf "mikrooptimierungen" zu achten. aber bevor man soweit ist, sollte man lieber auf standards zurückgreifen, die das problem anständig lösen. wenn vielleicht auch ne halbe sekunde langsamer.
-
gewi schrieb:
tut mir Leid, das erste strlen hat mich verwirrt, mit strcpy geht es, vielen Dank
man lernt echt nie ausZu dem Punkt, dass c schneller als c++ ist:
Ich habe ein Programm geschrieben, dass mir alle Zahlen von 1-10^7 in eine Datei schreibt. Dabei hat es c++ (ofstream) verwendet und die Zeit gemessen, und diese ausgegeben (mit printf). Dann wieder die gleichen Zahlen mit fprintf in eine Datei geschrieben, und die dafür benötigte Zeit mit printf ausgegeben, deswegen bin ich der Auffassung, dass c schneller als c++ ist.mfg gewi
öh, schreib das Programm nochmal, aber lass das schreiben der Zahlen in die Datei via Template-Metaprogrammierung erledigen und schau mal dann, was bei der Ausführung schneller ist

-
Template-Metaprogrammierung sollte ich mir echt mal anschaun, wenn es so viel schneller ist.
-
geht halt nur, wenn die Informationen zur Compiletime vorliegen ...
/Edit:
Bei deinem Geschwindigkeitswahn solltest du dir mal Assembler anschauen.
-
mal ganz ehrlich. nen programm, dass paar millarden fortlaufende zahlen in ne datei schreibt. wen juckt da die geschwindigkeit? das macht man einmal, dann hat man die datei.
-
ne 60 MB/s platte kann grob 10 mio zahlen die sekunde aufnehmen.
auf ner 2 GHz box sind das dann 200 takte je zahl.platte und CPU halten sich da wohl noch die waage.
du hast deine festplatte mit gemessen.
wie waers, wenn du die performance nicht an hand von festplatten oder INC operationen misst?
probiers doch mal mit methodenaufrufen und rekursion.
-
gewi schrieb:
printf ist schneller als cout, da es keine Klassen verwendet....
Warum nimmst Du dann nicht printf() ?
Übrigens: Wenn Du std::string genauso verwendest wie CStrings (keine dynamische Längenveränderung), ist es auch nicht langsamer, sondern eher schneller (explizite Längenangabe auslesen ist schneller als jedesmal '\0' suchen).
Achja: Wenn Geschwindigkeit Dein einziges Kriterium ist, solltest Du wrklich zu ASM wechseln. Wenn Du dagegen irgendwann mal fertig werden willst mit programmieren (und Dein Programm ohne Fingerbruch debuggen/weiterentwicklen) willst, fährst Du mit C++ besser.
Was programmierst Du eigentlich, dass Performance für Dich so viel wichtiger ist als unser 24/7-Multitasking-Server (der mit super-Performance seit Jahren unter C++ läuft) ?
Gruß,
Simon2.
-
~wenns mir auf performance nicht ankommt, nehm ich persoenlich scriptsprachen.
da wird man wenigstens mal fertig.~
-
thordk schrieb:
lässt sich so pauschal auch nicht sagen. viele reinen c-methoden, gerade diejenigen, die direkt auf dem speicher arbeiten, sind rasend schnell. aber das sind dinge, um die man sich nen kopf machen kann, wenn man in der lage ist, robuste und effiziente programme zu designen. das ist ein langwieriger prozess, der jahre dauert. und erst wenn man diesen stand erreicht hat, dann lohnt es sich, mal auf "mikrooptimierungen" zu achten. aber bevor man soweit ist, sollte man lieber auf standards zurückgreifen, die das problem anständig lösen. wenn vielleicht auch ne halbe sekunde langsamer.
Viele reine C++-Methoden, die direkt auf dem Speicher arbeiten sind rasend schnell.
Die Schnelligkeit von C gegenüber C++ ist eine Legende. C ist häufig schneller als C++, weil da unsauberer programmiert wird. "strcpy" gegenüber "std::string" ist ein gutes Beispiel.
"strcpy" ist prinzipiell schneller als eine Zuweisung an einen "std::string", da es keine Pufferprüfung macht. Eine Zuweisung an einen "std::string" reserviert ausreichend Speicher bevor es den String kopiert. Das tut strcpy nicht. Will ich in C das nachprogrammieren, habe ich deutlich mehr Arbeit und bin dann genauso "langsam" wie C++.
Diese Mehrarbeit ist auch der Grund, warum C für Pufferüberläufe anfällig ist und C++ nicht. Es ist einfach aufwändig, korrekte C-Programme zu schreiben.
Ein paar weitere Vorschläge, wie Du Dein Programm schneller machen kannst (so rein provokativ): verzichte auf Fehlerprüfung - das kostet Zeit, die normalerweise unnötig ist. Verwende feste Puffer und hoffe, daß die ausreichend groß sind. Dann werden nicht so zeitraubende Speicherallokationen vorgenommen.
-
c.rackwitz schrieb:
~wenns mir auf performance nicht ankommt, nehm ich persoenlich scriptsprachen.
da wird man wenigstens mal fertig.~~
Na, vielleicht bei 80-PJ-Projekten auch nicht mehr.
(wobei ich nicht genau weiß, welche "Skriptsprachen" Dir vorschweben).
Außerdem ist das Feld zwischen "Performance ist alles" und "Interessiert niemanden wann das PG fertiggerechnet hat" ziemlich weit...Gruß,
Simon2.
~
-
was meinst du, warum ich gesagt hab, dass man sich über solche "optimierungen" erstmal keine gedanken machen soll, tntnet?
es gibt durchaus fälle, in denen es auf jedes fitzelchen performance ankommt, man in wohl definierten parametern arbeitet und genau aus diesem grund auf fehlerkontrolle, zugunsten von performance, verzichten kann.
überlicherweise sollte dies allerdings tunlichst vermieden werden.