Dein oben geposteter Code scheint nicht das Problem zu sein, (ohne die Fehlermeldung genau zu kennen) tippe ich auf einen falschen index (scheint nach kurzer Webrecherche ziemlich common zu sein).

sollte laut stackoverflow relativ easy mit:

gehen


EDIT:

habe doch glatt den comment darunter überlesen:

to_string not a member of std

sollte wie folgt lösbar sein:

​edit2: weis jemand wie man eine convertierung von intenger in string macht

Das kann man mit Stringstreams machen:

Habe ich damals für eine eigene String Klasse geschrieben. Habe es mal kurz in eine statische Funktion umgeschrieben. War jedenfalls viel Arbeit sowas selbst zu schreiben, besonders die Zeile 38.

Nochmal kurz was zu std::to_string:
Das ist eine Funktion in <string>, die für alle elementaren Datentypen einmal überladen ist und sie in einen std::string umwandeln kann - so wie es die C-Funktion sprintf(char* buf, const char* format, ...), mit entsprechend eingesetztem Format, tun würde. Wenn's geht, solltest du die gegenüber Stringstreams bevorzugen, das ist nämlich effizienter.

Allerdings ist sie erst mit C++11 dazu gekommen; du solltest also erst deinen Compiler drauf einstellen, diesen Standard oder C++14 zu benutzen.

Also, vom ganzen Rest mal abgesehen...log10 wäre bei sowas seeehr hilfreich. Gibt dir dann (nachm runden), die Anzahl Stellen an die zur Darstellung der Zahl nötig sind (in Basis 10). log2 würde dir dann z.B. anzeigen wieviele Bits du benötigst um die Zahl in Binär darzustellen.

Ich habe hier ganz bewusst auf log10 verzichtet, da dies eine relativ langsame Funktion ist. Zudem wollte ich von keinen Bibliotheken abhängig sein, auch wenn sie zum Standard gehören. Und sicher gibt es an der ein oder anderen Stelle auch Optimierungsbedarf. Ich habe den Code schon größtenteils in Inlineassembler geschrieben, welche bei dieser Konvertierung nur mit den Registern der CPU auskommt. Diese ist dann sogar schneller als die herkömmlichen Funktionen. Mich würde gerne der Rest interessieren, wo ich etwas einfacher oder/und schneller lösen könnte. Ich hoffe du könntest mich da Aufklären.

Jeder halbwegs vernünftige Compiler ersetzt das durch einen(!) entsprechenden ASM Befehl. Und log10 gehört zum C++ Standard, Bist da also nicht von irgendwas großartig "abhängig".
Die Lösung da oben hat allein schon wegen des ganzen if/else-Trees da verschieden lange Laufzeiten und unnötig viele Branches.

Das wc_data würde ich durch ein stack basiertes array ersetzen. Verringert die Laufzeit bei häufigen Aufrufen deutlich. Eine maximale Größe ist ja bekannt.
Könnte man auch static machen, aber dann bekommst du Probleme sobald Threads ins Spiel kommen.

Ansonsten kann ich spontan nur hieran "meckern": "if(number & 1)". NIE, NIE auf den simplen "ungleich 0" Vergleich in C/C++ verlassen. IMMER ne komplette Bedingung hinschreiben. Also "if((number & 1) != 0)"

EDIT: bezüglich inline assembler version: auf gar keinen Fall. Wenn du Register forcierst geht all die Optimierung flöten die der Compiler während der register allocation macht. Also so n 1-2 Zeilen inline asm...ok, wenns sein muss. Aber längerer Code? Damit schießt du dir am Ende mehr in den Fuß als du optimierst. (Und Typos korrigiert)

Integer können nur einen Zahlenraum von −2.147.483.648 bis 2.147.483.647 abdecken. Darüber hinaus entsteht ein Overflow, was eine undefinierte Zahl zur Folge hat. Um größere Zahlen darzustellen benötigt man einen Datentyp wie z.B long.
Bezüglich nochmal meines Codes: Ich danke erstmal für deine Vorschläge, trotzdem sollte man den eigentlichen Sinn dahinter verstehen. Es ist eine Funktion aus einer selbstgeschriebenen String Klasse welche ich in kurzer Zeit umgeschrieben habe und diese ist auf den Heap angewiesen, weil dort eben keine maximale Größe bekannt ist. Es kann eine einfache Zahl sein, es kann aber auch ein Text mit über 1000 Wörtern sein. Der Heap bietet dafür eine effektive Speicherverwaltung an. Ich habe auch überlegt einen Großen statischen Speicherbereich anzulegen und darauf zurückzugreifen.
Dann zum Ungleich Null: Es ist völlig gang und gebe eine solche Schreibweise zu haben, da dies zum Standard von C++ gehört. Es hält zudem den Code meiner Ansicht nach übersichtlich und verständlich.
Und zum Inline Assembler kann ich dir versichern, dass der Code um einiges Schneller ist, selbst mit Codeoptimierung. Ich nutze hierbei VS2012. Es erlaubt einen Strukturen zu bilden welche in C++ nicht existieren. Z.B kann ich einfach das Carry-Flag benutzen bei einer Verschiebung. Das der Code dabei um einiges unübersichtlicher wird ist mir schon klar. Der Code ist jetzt aber wirklich nicht groß. Das mit der register allocation ist, tut mir leid, völliger Unsinn. Dadurch, dass ich nicht auf den Hauptspeicher zugreife, würde er garnicht erst zum Einsatz kommen. Ok gut, ich greife einmal am Anfang darauf zu und dreimal am Ende. Daran kann man aber nichts mehr Optimieren. Dies würde ausgerechnet durchschnittlich auch nur eine Nanosekunde Zeit beanspruchen. Ich glaube das ist absolut vertretbar.
Ich entschuldige mich dafür, dass ich ein wenig Off-Topic werde.

Moment...das ERGEBNIS deiner int-to-string Methode kann ein Text mit über 1000 Wörtern sein? Dann ist da aber ganz gründlich was schiefgegangen.
Aber okay. Akzeptieren wir mal dass du uuuunbedingt den Heap benötigst. Warum dann kein std::vector als Container? Wenn du mir schon mit dem C++ Standard anreitest?
Bezüglich des ungleich Null Vergleichs: also...zum "Standard" gehört es eher nicht das so zu schreiben. Es ist erlaubt, aber zum "Standard" bzw. eher zu den guten Praktiken gehört das schon lange nicht mehr. Oder willst du mit sowas als Argument auch goto benutzen?

Du manipulierst/verlässt dich manuell aufs Carry-Flag? Are you serious?

Und das mit der register allocation ist, tut mir leid, kein Unsinn. Es ist dabei völlig egal ob du in deinem Code auf den RAM zugreifst oder nicht. Es geht dabei um die REGISTER, wie der Name schon sagt. Sobald du durch inline assembler, manuell feste Register vorgibst, dann zerschießt dir das jegliche Optimierung die der Compiler dir diesbezüglich hinwerfen könnte. Als Lektüre empfehle ich dazu z.B. die Thesis hier christianwimmer.at/Publications/Wimmer04a/Wimmer04a.pdf
Und ob der Code um einiges schneller ist bezweifle ich. Richtig benchmarken ist gerade bei inline asm kram und so kurzen Funktionen eher schwierig.

PS: deine Hauptspeicherzugriffe benötigen durchschnittlich eine Nanosekunde? Also DEN Speicher hätt ich gerne. Oder hast du nur 4MB Ram verbraucht und taufst ihn liebevoll L2? (Und selbst dann wäre das schnell)

Langsam wird es albern und ich frage mich ob du das extra überliest. Es ist eine Funktion aus einer String Klasse, welche einen eigenen Speicheralgorithmus hat. Die Funktion ist nur eine einfache Entnahme aus dieser Stringklasse und wurde funktionstüchtig geschrieben. Das dies so als einzige Funktion fungiert ist eher suboptimal, das ist mir schon klar. Beim Speicherzugriff war es zugegeben eine sehr grobe Berechnung. Deswegen nochmal die genaue: Ein Takt dauert bei mir 1/(4GHz) = 1/(4*10⁹Hz) = 0,25*10^-9s lang. Nun benötigt ein Speicherzugriff 8 Takte, das heißt es sind insgesamt 2*10^-9 Sekunden pro Speicherzugriff. Eine Nanosekunde entspricht nun 10^-9 Sekunden, was dann wiederum einer Zeit von 2ns enstpricht. Das ist trotzdem noch immer sehr schnell. Im Vergleich benötigt dann ein Registerzugriff nur 2 Takte und im L2 etc. Speicher 4 Takte. Nun wird hier ein Array benutzt um den Text abzuspeichern. Anstatt jetzt jedes Zeichen jedes Mal aus dem Speicher zu lesen greife ich auf drei Register mit der Größe von 32bit zu, da die Zahl wie du schon selbst gesagt hast, maximal 11 Zeichen Groß werden kann. Nun benutze ich anstatt wchar_t einfach nur char, da dies nur 8bit benötigt. Die Zahl benötig jetzt maximal 12 Chars mit dem Nullzeichen, also 96bit. Dies passt perfekt in die drei Register. Nun brauche ich nur noch die drei Register in mein Array zu laden, was jetzt nur noch 24 Takte benötigt. Ich führe also alle Berechnungen in den Registern aus, anstatt das sehr viele Speicherzugriffe auf das Array erfolgen. Um mit solchen Registern auch arbeiten zu können wird Assembler benötigt, eben weil ich keine Kontrolle habe wie der Compiler das Optimiert. Dieser braucht nur einmal eine Sicherheitsüberprüfung einzubauen und alles würde extrem Verlangsamt werden, weil z.B die Register dafür nicht mehr ausreichen. Das dies Risiken birgt ist mir bewusst, weswegen ich mal grob alle Zahlen vom Integer überflogen bin und überprüft habe ob keine Fehler auftreten. Es sind zum Glück keine Fehler aufgetreten. Und nein ich manipuliere nicht das Carry-Flag, ich benutze es nur. Folgendes Beispiel:
anstatt
Welches die gleiche Wirkung, größere Laufzeiten, mehr Speicherbedarf und weniger Kürze hat. Ich optimiere dort wo der Compiler nicht optimieren kann. Und wenn ich mal 4 festgelegte Register benutze ist das nicht schlimm. Notfalls läd der Compiler die 4 Register auf den Stack und holt sie sich später dann wieder. Das ist kein großer Akt, zudem es eh automatisch bei dem Aufruf der Funktion geschieht. Und keine Angst ich werde goto niemals in c++ benutzen. Wenn ich dann Assembler benutze, erstelle ich mir ein Flussdiagramm um den Überblick nicht zu verlieren. Auch brauchst du nicht immer so hysterisch zu werden. Was für mich zählt ist das Ergebniss und das habe ich gründlich überprüft, dafür gibt es so einige Möglichkeiten.

Eine hilfreiche Funktion für long ist _i64toa_s aus der stdlib.h. Als radix gibt man 10 für das normale Dezimalsystem an. Größere Variablen als long sind dann schwerer zu benutzen, aber ich glaube kaum, dass du Zahlen bis 9 Trillionen brauchst. Dann empfiehlt es sich Variablen mit einem Exponenten wie double zu benutzen.

Aha. Du hast also entweder "wchar_t *wc_data = new wchar_t[ui_len+1];" überladen oder machst in deiner "eigenen Speicherverwaltung" dennoch irgendwas dynamisches obwohl hier selbst ein statisches array ausreichen würde?



Au weia...hast du mal die Datenrate deines Bus ins Spiel gebracht? Oder so Dinge wie Cache Miss und noch schlimmer, Page Miss? Da kommen *deutlich* mehr Zyklen auf dich zu. Aber hey, ich mein ja nur. Hinzu kommt, dass RAM Zugriff nicht nur von den Clockcycles deiner CPU abhängig ist, sondern auch von deinem RAM. Heutzutage sind die üblichen RAS times ca. 30ns, und da ist die row precharge time nichtmal drin eingerechnet. DANN kommen noch deine CPU cycles hinzu. Gut, nehmen wir mal worst case Szenario. Erst ein L1 und dann ein L2 Cache Miss. Das sind dann nochmal 40 cycles für L1 und ca. 600 für L2. Dann kommt eigentlich noch der Page Miss, aber die ganzen Syscalls würden so endlos viele cycles verbrennen, das wäre nicht mehr feierlich. Wären wir also nur mit Cache Miss bei 8 + 40 + 600 = 648 cycles = 192ns. Plus die RAS time, sind wir bei 222ns. Gratuliere...stark anders als 2ns, hm?

Und das mit dem Register Allocator scheint nicht anzukommen. Du optimierst dich hier zu Tode an 3 Registern...pfeifst dann aber auf das pushen der Register auf den Stack das nötig ist weil du manuelle Register vorgibst.

Weiterhin noch folgendes: du wolltest ja nichtmal log10 benutzen weil du von nichts abhängig sein wolltest, machst dich dann aber von speziellen Registern abhängig, ohne zu wissen ob diese vom Compiler oder System gebraucht werden (je nach calling convention darfst du z.B: das ECX Register bloß nicht anpacken oder du landest im Nirvana). Wenn du dann noch EBX benutzt, forcierst du den Compiler im prolog UND epilog deiner Funktion, noch spezielles Stack-foo anzurichten. Aber eeeey...wir haben den Code mit 2 Zeilen inline assembly "optimiert" m(

Wenn das für dich kein Signal für Code Smell ist dann weiß ich auch nicht mehr.


Doch, brauche ich. Wenn jemand Optimierungen macht die schmarn sind und sie dann auch noch ohne das detaillierte Hintergrundwissen mit Pseudoargumenten "begründet"....dann verweise ich auf meinen Avatar.