C++ int+ char = String !?

[clemgregor]

Hey ich wollte gerade eine eingabe einem Text und einer Zahl machen das er nacher wieder ausgegeben wird!

ich kenn bis jetzt
int für Zahlen
char für Buchstaben
string !?

[bloodx]

string kann beides enthalten, Char's Int's etc.

aber bitte verbessere nochmal deine Frage ich verstehe nicht was du möchtest oO

std::stringstream kannst du auch benutzen wenn du beides einließt.

[marykillsjane]

#include <iostream>
#include <string>

int main()
{
std::string string_variable;
std::cin >> string_variable ;
std::cout << string_variable;
return 0 ; 

}

In nem String kannst du soweit ich weiß jedes Zeichen welches der ASCII beinhaltet( du kannst also eigentlich alles außer evtl irgendwelche chinesischen schriftzeichen o.ä. darin einlesen ).
Zum rechnen solltest du aber weiterhin int ,float ,short,long u.a. verwenden ,da Strings für Text gedacht sind man kann glaube ich auch damit rechnen ,dadurch können aber viele Fehler entstehen.

[Shadow992]

Originally Posted by marykillsjane

#include <iostream>
#include <string>

int main()
{
std::string string_variable;
std::cin >> string_variable ;
std::cout << string_variable;
return 0 ; 

}

In nem String kannst du soweit ich weiß jedes Zeichen welches der ASCII beinhaltet( du kannst also eigentlich alles außer evtl irgendwelche chinesischen schriftzeichen o.ä. darin einlesen ).
Zum rechnen solltest du aber weiterhin int ,float ,short,long u.a. verwenden ,da Strings für Text gedacht sind man kann glaube ich auch damit rechnen ,dadurch können aber viele Fehler entstehen.

Mit Strings kann man rechnen?
Nicht in C/C++ was soll da auch bitte herauskommen?
Wenn man nämlich Sprachen mit nicht abstrakten Typen (wie Autoit oder PHP) hat, wird sehr penibel zwischen String und Zahl unterschiede, folgendes würde die Zahl 20 ausgeben:

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

um den Datentyp "string" benutzen zu können, muss wenn ich mich nicht irre
"string"includiert werden, also:

#include <string>

Zusätzlich sollte man als Anfänger lieber noch globale namespaces verwenden, wenn man sich nicht intensiv mit diesen Auseinander setzen will, im Hinterkopf sollte man jedoch behalten, dass die Methode globale namespaces zu setzen eher ein schlechter Stil ist (nennt man das globale Namespaces?):

using namespace std;

Edit:

Prinzipiell, wenn du char bereits kennst und nichts neues lernen möchtest, kannst du auch einfach ein Array an chars nehmen, ein String ist nichts anderes.

[Schlüsselbein]

Zusätzlich sollte man als Anfänger lieber noch globale namespaces verwenden

Warum?

Prinzipiell, wenn du char bereits kennst und nichts neues lernen möchtest, kannst du auch einfach ein Array an chars nehmen, ein String ist nichts anderes.

Blödsinn. Da er C++ verwendet, soll er auch std::string benutzen.

[Shadow992]

Originally Posted by Schlüsselbein

Warum?

Weil das nicht verwirrt, man muss sich nicht mit dem Thema namespaces außeinander setzen, man lernt einfach auswendig:

"using namespace std;"

kommt immer oben hin.
Dabei muss man sich vorerst keine Gedanken darüber machen, was genau diese Zeile Code jetzt macht und erreicht damit ein klein wenig mehr Lust weiter zu lernen. Beim Programmieren am Anfang bin ich nämlich immer noch der Meinung, dass je schneller die Erfolge, desto eher bleibt man beim Programmieren. Später wird man sich sowieso Gedanken über einen guten/lesbaren Stil machen, spätestens wenn man die ersten großen Projekte schreibt.

Man könnte zwar auch auswendig lernen:
Vor jedes cin, cout, string, usw. kommt ein std::, das kann man aber

1. sehr schnell vergessen und dann fragt man sich warum es nicht funktioniert und
2. ist es mehr auswendig zu lernen, als diese eine Zeile.

Originally Posted by Schlüsselbein

Blödsinn. Da er C++ verwendet, soll er auch std::string benutzen.

Man sollte beide Varianten einmal gesehen und benutzt haben, für den Anfang ist es also durchaus ok, sich auch mit nicht C++ spezifischen Elementen zu befassen.

Abgesehen davon ist ein char-Array um einiges schneller in der Verarbeitung als ein Objekt der string Klasse.

[.SkyneT.]

Originally Posted by Shadow992

Weil das nicht verwirrt, man muss sich nicht mit dem Thema namespaces außeinander setzen, man lernt einfach auswendig:

"using namespace std;"

kommt immer oben hin.
Dabei muss man sich vorerst keine Gedanken darüber machen, was genau diese Zeile Code jetzt macht und erreicht damit ein klein wenig mehr Lust weiter zu lernen. Beim Programmieren am Anfang bin ich nämlich immer noch der Meinung, dass je schneller die Erfolge, desto eher bleibt man beim Programmieren. Später wird man sich sowieso Gedanken über einen guten/lesbaren Stil machen, spätestens wenn man die ersten großen Projekte schreibt.

Man könnte zwar auch auswendig lernen:
Vor jedes cin, cout, string, usw. kommt ein std::, das kann man aber

1. sehr schnell vergessen und dann fragt man sich warum es nicht funktioniert und
2. ist es mehr auswendig zu lernen, als diese eine Zeile.

3. Man lernt die Sprache gleich richtig, anstatt sich hinerher zu plagen den
schlechten Stil wieder abzugewöhnen.

Originally Posted by Shadow992

Abgesehen davon ist ein char-Array um einiges schneller in der Verarbeitung als ein Objekt der string Klasse.

std::string hat vermutlich einen größeren Overhead, aber mehr schon nicht, und bei
normalen Rechnern ist das sicher kein merklicher Unterschied.

[Shadow992]

Originally Posted by .SkyneT.

3. Man lernt die Sprache gleich richtig, anstatt sich hinerher zu plagen den
schlechten Stil wieder abzugewöhnen.

Muss jeder für sich wissen, Fakt ist aber, dass am Anfang viele Leute an den extrem langsamen Erfolgen scheitern und ich deswegen immer Tipps gebe, wie man am ehesten ans Ziel kommt und nicht auf welchem Weg.
In einer Uni wird das sicher anders gelehrt, da wird alles sofort 100% genau und exakt gemacht, aber wenn man es Hobby mäßig macht, sollte man den Fokus auf Spaß legen.

Originally Posted by .SkyneT.

std::string hat vermutlich einen größeren Overhead, aber mehr schon nicht, und bei
normalen Rechnern ist das sicher kein merklicher Unterschied.

Solche Aussagen halte ich, wenn man den ersten Teil deiner Aussage ansieht, für total bescheuert.

Ich soll das Programmieren zwar "richtig" lernen, "richtig" wurde aber bei dir nie definiert. Heißt richtig jetzt möglichst wenig Code, geringe Ausführungszeiten oder Klassen, denen man versucht alles aufzudrängen.

Ich finde den Aspekt möglichst geringe Ausführungszeiten am wichtigsten und daran messe ich auch mein "richtig" oder "falsch". Solange der Code noch im lesbaren Rahmen bleibt. Ob ich jetzt C unc C++ mische, ist mir hingegen total egal, weil das im kompilierten Programm eh kein Schwein mehr interessiert.

Das einzige was man später noch merkt ist die Geschwindigjeit.

Wenn jeder mit dem Hintergedanken "Heutzutage sind die Ressourcen doch eh unbegrenzt" rangehen würde, dann wären Supercomputer genau so schnell wie ein Taschenrechner und Rechennetze genau so schnell wie ein moderner Homecomputer.

Richtigkeit sollte man also hauptsächlich an Geschwindigkeit und Speicherbedarf messen und nicht daran, ob man jetzt sprachspezifische Elemente verwendet hat oder nicht.

Natürlich sollte man, wann immer es geht, Sprachspezifische Elemente benutzen, aber es ist genau so richtig mit schnelleren nicht Sprachspezifischen Elementen zu arbeiten.

Und da er momentan nur chars kennt und keine Strings, warum soll er das nicht gleich nutzen um das Wissen über Strings auf der untersten Ebene zu vertiefen?

Es macht doch keinen Sinn alles oberflächlich anzuschneiden und nicht einmal im Entferntesten zu wissen, wie die String-Klasse eigentlich (zumindest theoretisch) aufgebaut ist.

[Schlüsselbein]

man muss sich nicht mit dem Thema namespaces außeinander setzen, man lernt einfach auswendig:

Das ist als wolle man Autofahren lernen, sich aber nicht mit der Bremse auseinandersetzen.
Wer Programmieren (gerade C++) lernen will, soll es mMn dann auch richtig tun. Und wenn es C++ sein soll(oft auch einfach nur, weils einem Anfänger direkt als uber-h4x0r-mächtige-Sprache angedreht wird; aber andere Baustelle), soll man sich nicht davor scheuen, sich mit allen Teilbereichen zu befassen.
Und auswendig lernen ist sowieso falsch, wenns ums Sprache lernen geht.

Man sollte beide Varianten einmal gesehen und benutzt haben, für den Anfang ist es also durchaus ok, sich auch mit nicht C++ spezifischen Elementen zu befassen.

Natürlich soll er auch wissen, was ein Array ist. Aber ihm raten, es zu benutzen, ist doch wirklich unsinnig.

Abgesehen davon ist ein char-Array um einiges schneller in der Verarbeitung als ein Objekt der string Klasse.

1. "premature optimization is the root of all evil"
Und das trifft ganz besonders auf sowas wie char[] statt std::string oder ++i statt i++ zu.
2. Muss deine Aussage nicht unbedingt richtig sein. Es ist laut Standard afaik nicht vorgeschrieben, dass sich der interne buffer auf dem Heap befinden muss - von Implementationen, wo kurze Strings auf dem Stack erstellt werden, hab ich auch schon gehört. Demnach fällt dieser größte Teil des Overheads schonmal weg. Durch Optimierungen sollten String-Operationen dann kaum bis garnicht langsamer sein, wie die C-Funktionen, die auf char-Arrays angewendet werden. Wenns ideal verläuft, werden die Methoden von std::string, die dann ggf. auch nichts anderes als strlen, strcat usw. aufrufen, einfach inlined -> 0 Overhead.
Ausserdem sorgen unter C++11 die move semantics für noch mehr Neutralisation des Overheads.




Gruß


//EDIT:

Richtigkeit sollte man also hauptsächlich an Geschwindigkeit und Speicherbedarf messen und nicht daran, ob man jetzt sprachspezifische Elemente verwendet hat oder nicht.

Sowas ist aber kein ausschlaggebender Faktor für Geschwindigkeit. Und da du dich scheints selber nur Hobbymäßig mit dem Programmieren beschäftigst (keineswegs böse gemeint), solltest du mit wilden Aussagen vorsichtig sein.
Es gibt ja die pi-mal-Daumen-Regel, dass 10% des Codes 90% der Zeit laufen - und das ist sicherlich kein erstellen eines std::string-Objekts.
In der "richtigen" (für dich wahrscheinlich falschen), Entwicklung geht man so vor: Man schreibt die Software mit Hauptaugenmerk auf _sauberen Code_. Sollte es dann irgendwo ein Bottleneck geben, muss man genauer Untersuchen und ggf. n Profiler benutzen. Dort wird dann gezielt optimiert, falls was gefunden wird.
Die Aussage von dir ist schlichtweg falsch und die paar Takte die man damit vielleicht einsparen kann, stehen in keinem Verhältnis zur Lesbarkeit.

[Shadow992]

Originally Posted by Schlüsselbein

Das ist als wolle man Autofahren lernen, sich aber nicht mit der Bremse auseinandersetzen.
Wer Programmieren (gerade C++) lernen will, soll es mMn dann auch richtig tun. Und wenn es C++ sein soll(oft auch einfach nur, weils einem Anfänger direkt als uber-h4x0r-mächtige-Sprache angedreht wird; aber andere Baustelle), soll man sich nicht davor scheuen, sich mit allen Teilbereichen zu befassen.
Und auswendig lernen ist sowieso falsch, wenns ums Sprache lernen geht.
Natürlich soll er auch wissen, was ein Array ist. Aber ihm raten, es zu benutzen, ist doch wirklich unsinnig.

1. "premature optimization is the root of all evil"
Und das trifft ganz besonders auf sowas wie char[] statt std::string oder ++i statt i++ zu.
2. Muss deine Aussage nicht unbedingt richtig sein. Es ist laut Standard afaik nicht vorgeschrieben, dass sich der interne buffer auf dem Heap befinden muss - von Implementationen, wo kurze Strings auf dem Stack erstellt werden, hab ich auch schon gehört. Demnach fällt dieser größte Teil des Overheads schonmal weg. Durch Optimierungen sollten String-Operationen dann kaum bis garnicht langsamer sein, wie die C-Funktionen, die auf char-Arrays angewendet werden. Wenns ideal verläuft, werden die Methoden von std::string, die dann ggf. auch nichts anderes als strlen, strcat usw. aufrufen, einfach inlined -> 0 Overhead.
Ausserdem sorgen unter C++11 die move semantics für noch mehr Neutralisation des Overheads.




Gruß

@Bremsen
Nein das ist so als würde man auswendig lernen immer zu Bremsen, wenn Gefahr besteht, ohne zu wissen, was die Bremsen mit dem Auto machen.

@Char-Array
Das war doch keine Empfehlung, nur ein Aufzeigen von Alternativen.

@String
Kaum langsamer und kaum Overhead ist trotzdem noch größer 0.

[Delinquenz]

Wenn dein Programm so schnell wie möglich laufen soll, dann benutze gefälligst C. Falls du es nicht gemerkt hast, ist C++ insgesamt minimal (!) langsamer als C, dafür jedoch wesentlich, wirklich wesentlich, komfortabler.

Benutzt du auch lieber printf statt cout? Oh man..

Sorry, aber wer zu blöd ist, um wenigstens grob zu verstehen, was ein namespace ist, sollte C++ vorerst sein lassen.

Für Anfänger kann man halt sagen, dass alle Standard C++ Funktionen usw. im Namespace std sind, damit sich deine gleichnamigen Funktionen mit denen nicht überschneiden. Das sollte doch wohl jeder verstehen können.

Ich finde, auch als Anfänger sollte man alles hinterfragen usw.. da ist es dann einfacher, das zu verstehen, wenn man es direkt erklärt bekommt. Wer schnelle Erfolge will, soll halt nicht zu C++ greifen, so einfach.

€: 2 neue Posts, während ich meinen Post geschrieben hab, lol.

[Schlüsselbein]

@String
Kaum langsamer und kaum Overhead ist trotzdem noch größer 0.

Nochmal: Das ist premature optimization und einfach Scheiße. Les dir mein Edit vom Post davor durch, dann siehtst du warum.
Wenns dir auf jeden Takt ankommt, benutze Assembler.

[Shadow992]

Originally Posted by Delinquenz

Wenn dein Programm so schnell wie möglich laufen soll, dann benutze gefälligst C. Falls du es nicht gemerkt hast, ist C++ insgesamt minimal (!) langsamer als C, dafür jedoch wesentlich, wirklich wesentlich, komfortabler.

Benutzt du auch lieber printf statt cout? Oh man..

Ich zitiere:

"Each has its own overheads. Depending on what you print, either may be faster.

Here are two points that come to mind -

printf() has to parse the "format" string and act upon it, which adds a cost.
cout has a more complex inheritance hierarchy and passes around objects."

Also wenn sich printf in meinem konkreten Fall für schneller herausstellt, ja tue ich, ansonsten nein.

Achja, printf ist NICHT schneller als cout (zumindest nicht in dem Test):

Printing 150,000 "Hello, World!"s (without using endl) takes about -
90ms for printf(), 79ms for cout.

Printing 150,000 random doubles takes about -
3450ms for printf(), 3420ms for cout.

C und C++ sind in den Standardelementen genau gleich schnell!!!
In beiden ist die Ausführungszeit für folgendes z.b. gleich:

int i=10;
int a=200;
int b=a+i;

Also kann man gewiss nicht sagen, dass C++ langsamer als C ist. Das mag vielleicht ein paar Klassen betreffen, aber im Allgemeinen ist das eine falsche Aussage.

Originally Posted by Schlüsselbein

Nochmal: Das ist premature optimization und einfach Scheiße. Les dir mein Edit vom Post davor durch, dann siehtst du warum.
Wenns dir auf jeden Takt ankommt, benutze Assembler.

Nicht umsonst wird das bei vielen Spielen und Zeitkritischen Sachen auch gemacht.
Dafür geht halt der Abstraktionsgrad verloren und das ist wohl eine Einbuße, die das Schreiben von großen Programmer extrem erschwert.

[GuoTerra]

ASCII Tabelle lernen.

Alle Schleifen.

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

Nicht umsonst wird das bei vielen Spielen und Zeitkritischen Sachen auch gemacht.

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.