[C++]Dev C++ string to int

[xNopex]

Was hier wieder geredet wird :-/

Wenn du in C++ programmierst, solltest du auf die Vorteile von std::string nicht verzichten und dann nimmst du zum Konvertieren einen std::stringstream:

std::string to int

#include <sstream>

std::string alsString = "123";
int alsZahl;
stringstream sstr( alsString);
sstr >> alsZahl;

int to std::string

#include <sstream>

int alsZahl = 123;
stringstream sstr;
sstr << alsZahl;
std::string alsString = sstr.str();

[MrSm!th]

Danke, die Methode kannte ich noch nicht.

Ich will auch nichts dagegen sagen, aber man muss nicht immer ganz euphorisch nur den C++) Standard nutzen.
In vielen Situationen ist strtol auch gut/besser.

[xNopex]

Sobald das, was ich unter C++ zur Verfügung habe, für eine Situation nicht geeignet ist, verwende ich die Sprache nicht. So einfach ist es doch. Ich muss vorher abwägen, ob die Sprache für das Projekt geeignet ist, oder nicht. Verwendet man C++, so hat man sich auch davor Gedanken gemacht, WARUM man diese Sprache verwendet. Und wenn man sich dann dafür entschieden hat, verwendet man auch kein "Kuddel-Muddel" aus verschiedenen Sprachen.. Natürlich gibt es, wie du sagst, Ausnahmen, in denen es wirklich angebracht ist mal die eine oder andere C-Funktion zu verwenden, aber bei mir haben sich diese Situationen im Hobby-Bereich noch nicht gezeigt.

Anmerkung: Welcher Mensch, der nicht auf Schmerzen steht, programmiert btw heute noch freiwillig in C++ ?

[Bot_interesierter]

Mit boost sieht die C++ Welt gleich viel rosiger aus:

string str="123457";
int number=boost::lexical_cast<int>(str);

Das beantwortet auch deine Frage warum Menschen noch freiwillig mit C++ Programmieren, templates sind einfach genial und boost eh =).

Außerdem:
Ja C++ gib mir segfaults du geile Sau!

[MrSm!th]

Originally Posted by xNopex

Sobald das, was ich unter C++ zur Verfügung habe, für eine Situation nicht geeignet ist, verwende ich die Sprache nicht. So einfach ist es doch. Ich muss vorher abwägen, ob die Sprache für das Projekt geeignet ist, oder nicht. Verwendet man C++, so hat man sich auch davor Gedanken gemacht, WARUM man diese Sprache verwendet. Und wenn man sich dann dafür entschieden hat, verwendet man auch kein "Kuddel-Muddel" aus verschiedenen Sprachen.. Natürlich gibt es, wie du sagst, Ausnahmen, in denen es wirklich angebracht ist mal die eine oder andere C-Funktion zu verwenden, aber bei mir haben sich diese Situationen im Hobby-Bereich noch nicht gezeigt.

Anmerkung: Welcher Mensch, der nicht auf Schmerzen steht, programmiert btw heute noch freiwillig in C++ ?

Du willst also gleich ne andere Sprache nutzen oder eine Library aus ner anderen Sprache nutzen, weil eine C Variation besser als die C++ Variation wäre?
Es ist kein ganzes Problem, normalerweise ist ein Programm nicht dafür da, eine Zahl in nen String zu konvertieren.
Und C++ wurde nicht umsonst abwärtskompatible gemacht; wenn man aus Performancegründen an einer Stelle lieber strtol wählt, dann kann man das auch machen ohne gleich sagen zu müssen "Dann doch gleich das ganze Programm in C!!1".

Anmerkung:

Ziemlich viele, die von .NET nichts halten oder Programme brauchen, die hardwarenahe sind, aber in einem objektorientierten Model. Davon gibts viele.

[xNopex]

Natürlich gibt es, wie du sagst, Ausnahmen, in denen es wirklich angebracht ist mal die eine oder andere C-Funktion zu verwenden, aber bei mir haben sich diese Situationen im Hobby-Bereich noch nicht gezeigt.

Nun klärt sich doch einiges, oder?

Ziemlich viele, die von .NET nichts halten

>> Java

Programme brauchen, die hardwarenahe sind

>> C

aber in einem objektorientierten Model

>> ObjC / C++ (Ziemlicher Spezialfall, findest du nicht? :-/)


Welcher Mensch, der nicht auf Schmerzen steht, und nicht aufgrund der äußeren Umstände gezwungen ist, programmiert btw heute noch freiwillig in C++?

[lala66]

jaa

[MrSm!th]

Originally Posted by xNopex

Nun klärt sich doch einiges, oder?



>> Java


>> C


>> ObjC / C++ (Ziemlicher Spezialfall, findest du nicht? :-/)


Welcher Mensch, der nicht auf Schmerzen steht, und nicht aufgrund der äußeren Umstände gezwungen ist, programmiert btw heute noch freiwillig in C++?

Warum soll für Hardwarenähe bitte deiner Meinung nach C genutzt werden?
Das ist genau die allgemeingültige Meinung, die ich überhaupt nicht teile.
C++ verbindet Hardwarenähe mit OO. Warum nicht? Was ist daran schlimm?
Wenn man die nötigen Libraries wie boost und co. hat oder evtl. sogar C++ mit .NET hat (was ich allerdings nicht unterstütze^^) dann ist es genau so komfortabel wie C#.
Für mich ist C++ nunmal eine Native allround Sprache.
Und für kleinere Tasks nimmt man dann eben, je nachdem, wie man es braucht, Python oder ähnliche.


Zu deiner Frage: Ich zum Beispiel.
Und aufgrund deiner bisherigen Tutorials schätze ich mal, du auch.

(Ziemlicher Spezialfall, findest du nicht? :-/)

Nope.

[xNopex]

Wenn du gegen die landläufige, von den meisten Leuten, die beruflich damit zu tun haben, akzeptierte These bist, dass C die Sprache ist, die einfach am geeignetsten ist für Hardware-Nahe Programmierung, dann ist das so. Ich sehe, dass es keinen Sinn macht mit dir zu diskutieren.
ObjC verbindet ebenfalls Hardwarenähe mit OOP.

C++/CLI sollte von niemanden unterstützt werden. Wer ernsthafte Projekte damit programmieren will, hat glaub ich mal etwas verpasst. Die Sprache sollte imho nur für Integrationsprojekte verwendet werden.
Boost und co. sind ganz nett, da hast du recht

Genauso komfortabel, wie C# ist es deshalb noch lange nicht. Das Programmieren in C++ ist einfach zu Zeitintensiv, Fehlerbehaftet, als dass es für kommerzielle Projekte noch Sinn macht auf diese Sprache zu setzen. C++ ist zwar eine sehr schöne Sprache, weshalb ich auch gerne in ihr programmiere, dennoch kann man dort so viel falsch machen, wie in fast keiner anderen Sprache. Das ist einfach nicht rentabel. Für Anwendungssoftware sehe ich deshalb Java, C# im Vorteil. Echte Plattformunabhängigkeit bieten halt nur Interpreter-Sprachen, wie Java. C++ ist zwar im Prinzip, Plattformunabhängig, dennoch ist der kompilierte, native Code wiederum Plattformabhängig. Byte-Code bleibt Byte-Code. Egal auf welchem System er ausgeführt werden soll. Natürlich gibt es noch sehr viele Anwendungsbereiche, die (zu Recht) auf C++ setzen. Aber meiner Meinung nach hat die Sprache ihren Zenit vor ein paar Jahren überschritten und geht langsam aber Sicher in Richtung Abendrot.

Und aufgrund deiner bisherigen Tutorials schätze ich mal, du auch.

Nein, ich stehe einfach nur auf Schmerzen und die Sprache macht mir Spaß, eben weil man so viel falsch machen kann

[Bot_interesierter]

Für Gamehacking ist und bleibt C++ das nonplus ultra, zumal viele Spiele in C++ Programmiert sind und dann oft auf Virtuel Method Tables trifft und da praktisch alle neueren Spiele mit msvc++ programmiert sind kann man sich das zu nutzte machen um einfach mit den Objekten im Spiel umzugehen.

In anderen Sprachen wird es meistens komplizierter mit diesen Konzepten aus C++ umzugehen, also wenn man es mit Objekten zu tun hat die in C++ implementiert wurden, dann ist es einfach Aufwendiger in einer anderen Sprache damit umzugehen.
Und ja ich finde das C# mit pinvoke inprocess deutlich schmerzhafter ist als C++, zumal ich nie die Geduld hatte mich in diesen ganzen .NET kram einzuarbeiten.

Wenn man natürlich nur Outofprocess Cheats schreibt und vielleicht ein paar lustige nop/codecave cheats, dann ist C++ natürlich overkill, einfaches byte poking geht mit jeder beliebigen Sprache die Zugriff auf die OS API hat.

[MrSm!th]

Originally Posted by xNopex

Wenn du gegen die landläufige, von den meisten Leuten, die beruflich damit zu tun haben, akzeptierte These bist, dass C die Sprache ist, die einfach am geeignetsten ist für Hardware-Nahe Programmierung, dann ist das so. Ich sehe, dass es keinen Sinn macht mit dir zu diskutieren.
ObjC verbindet ebenfalls Hardwarenähe mit OOP.

Doch, den Sinn macht es sehr wohl, ich bin nicht unbelehrbar.
Ich sagte nicht, dass C nicht die geeignetste sein soll und auch nicht, dass man da kein ObjC nehmen kann, ich fragte lediglich, was an C++ falsch sein soll.
Was ist an einem objektorientiertem Modell falsch? Microsoft plant schließlich auch, das Treiber Modell oo zu machen und ich persönlich würde auch mal ganz gern ein OS mit objektorientiertem Modell sehen.
Wenn die kritischen Teile mit C oder ASM geschrieben werden, ist das auch nicht zwingend langsamer als ein reines C OS.

C++/CLI sollte von niemanden unterstützt werden. Wer ernsthafte Projekte damit programmieren will, hat glaub ich mal etwas verpasst. Die Sprache sollte imho nur für Integrationsprojekte verwendet werden.
Boost und co. sind ganz nett, da hast du recht

Gut, da sind wir uns schonmal einig.

Genauso komfortabel, wie C# ist es deshalb noch lange nicht.

Gut, es war leicht übertrieben, aber ich finde es nicht richtig zu sagen, C# macht sich fast von allein und C++ ist für alles zu unkomfortabel.

Das Programmieren in C++ ist einfach zu Zeitintensiv, Fehlerbehaftet, als dass es für kommerzielle Projekte noch Sinn macht auf diese Sprache zu setzen.

Das mag sein, komischerweise wird sie trotzdem noch häufig verwendet.
Klar, .NET und Java sind im Kommen, trotzdem setzen noch viele auf Native.
Insbesondere Spiele, weshalb ich auch Bot_interessierters Post unterstütze, fürs Gamehacking bleibt C++ einfach ein Favourit.
Ach ja, ich habe hier mal die komische Aussage gelesen, C++ würde kaum noch Verwenung finden, weil für die meisten Anwendungen .NET und Java genutzt würde und da, wo C++ gebraucht werden könnte, bei zb. Spielen, nehme man C.
Das stimmt einfach nicht. Ich habe mittlerweile schon ein paar Spiele reversed, die ganz klar in C++ geschrieben wurden und 90% der Anwendungen, die ich reverse sind native.

C++ ist zwar eine sehr schöne Sprache, weshalb ich auch gerne in ihr programmiere, dennoch kann man dort so viel falsch machen, wie in fast keiner anderen Sprache.

Da sind wir wieder einer Meinung, durch guten Stil, lange Erfahrung und guten Dokumentationen der Libraries, die man nutzt, lassen sich Fehler aber weitestgehend vermeiden.

Das ist einfach nicht rentabel. Für Anwendungssoftware sehe ich deshalb Java, C# im Vorteil. Echte Plattformunabhängigkeit bieten halt nur Interpreter-Sprachen, wie Java. C++ ist zwar im Prinzip, Plattformunabhängig, dennoch ist der kompilierte, native Code wiederum Plattformabhängig. Byte-Code bleibt Byte-Code. Egal auf welchem System er ausgeführt werden soll. Natürlich gibt es noch sehr viele Anwendungsbereiche, die (zu Recht) auf C++ setzen. Aber meiner Meinung nach hat die Sprache ihren Zenit vor ein paar Jahren überschritten und geht langsam aber Sicher in Richtung Abendrot.

Das mit der Plattformunabhängigkeit stimmt, aber wie du selbst sagst, sehr sehr viele Anwendungen sind zurecht in C++ geschrieben.
Und da auch noch recht viele Unternehmen keinen Wert auf Plattformunabhängigkeit gegenüber zb. Linux legen, ist das noch nicht so ein großes Problem.
Dass sie sich langsam aber sicher in Richtung Abendrot geht, finde ich überhaupt nicht. Man wird immer Native Sprachen brauchen und wenn es nur für die Interpreter der anderen ist.
Und da mit der Zeit das objektorientierte Modell immer beliebter/wichtiger wird, wird wohl in Zukunft auch für Treiber, Betriebssysteme und die Interpreter lieber C++ als C genommen.
Man kann es ja auch verbinden.
Jedenfalls werden sie nicht abgelöst, solange es keine andere Native Sprache gibt, die sie unweigerlich toppt und dazu noch recht kompatibel mit ihnen ist, damit alte Anwendungen nicht neugeschrieben werden müssen!

Nein, ich stehe einfach nur auf Schmerzen und die Sprache macht mir Spaß, eben weil man so viel falsch machen kann

noch eine Gemeinsamkeit