Variablen
-
Artchi schrieb:
ChrissB! Versau die C++ Neulinge bitte nicht mit C-Kram!
Ich versaue sie nicht, ich will es nur als Ergänzung an std::string anmerken, dass es noch andere Möglichkeiten gibt, eine Zeichenkette in einer Variable zu speichern. Es ist seine Entscheidung, was er schlussendlich einsetzt. Ich persönlich setzte in den meisten Fällen auch std::string ein. Ein paar Gründe faür habe ich ja oben schon gepostet. Wenn du aber zum Beispiel ein Programm auf eine C-Lib aufbausts (aufbauen musst), hast du oft das Problem, dass viele Funktionen ein char* erwarten.
-
std::string::c_str()
-
Michael E. schrieb:
std::string::c_str()
Willst du das const wegcasten mittels const_cast<T>(foo)?
Sonst kriegste nen Error: invalid conversion from `const char*' to `char*'
-
Wie Michael schon gepostet hat, gibt es auch hierfür keinen Grund char-Arrays einzusetzen. string kann locker auf Wunsch eines liefern.
Außerdem hat mich folgendes gestört:
ChrissiB schrieb:
ohne gleich ein std::string verwenden zu müssen
Das hört sich so an: "naja, std::string ist voll nervig und voll schlecht. Wenns nicht unbedingt sein muß, würd ich lieber kein std::string benutzen."
Und DAS geht nun wirklich auf keine Kuhhaut. Es gibt ABSOLUT KEINEN Grund nicht std::string zu benutzen. Man sollte nicht mal dran denken, wenn man einen C++ Compiler und std::string zur Verfügung hat, dieses nicht zu benutzen. Wenn doch, sollten wir alle aufhören in C++ zu programmieren und lieber zu C zurück kehren.
-
ChrissiB schrieb:
Michael E. schrieb:
std::string::c_str()
Willst du das const wegcasten mittels const_cast<T>(foo)?
Sonst kriegste nen Error: invalid conversion from `const char*' to `char*'
-
Michael E. schrieb:
ChrissiB schrieb:
Michael E. schrieb:
std::string::c_str()
Willst du das const wegcasten mittels const_cast<T>(foo)?
Sonst kriegste nen Error: invalid conversion from `const char*' to `char*'Verstehe ich nicht, was willst du mir damit sagen?
Ich weiß, dass c_str() ein const char* zurückliefert, damit der interne nicht von außerhalb verändert werden kann. Manche Funktionen aus C-Libs erwarten aber ein char*.
-
also.... ich meinte eigendlich das:
include <iostream> using namespace std; int main() { int isim; int o=Oguzhan; int oe=Ömer; int k=Kemal; cout << "Wer bist du?"; cin >> isim; if(isim==o) { cout << "Hey Oguzhan!!!" << endl; } if(isim==oe) { cout << "Hi Ömer!!!" << endl; } if(isim==k) { cout << "Moin Kemal!!!" << endl; } cin.get(); }
Aber ich kann die variablen in denen Texte gespeichert werden sollen (int ...) nicht benutzen, da sie nur Zahlen speichern. Was könnte ich da machen?
-
Artchi schrieb:
Wie Michael schon gepostet hat, gibt es auch hierfür keinen Grund char-Arrays einzusetzen. string kann locker auf Wunsch eines liefern.
Ist mir klar.
Artchi schrieb:
Außerdem hat mich folgendes gestört:
ChrissiB schrieb:
ohne gleich ein std::string verwenden zu müssen
Das hört sich so an: "naja, std::string ist voll nervig und voll schlecht. Wenns nicht unbedingt sein muß, würd ich lieber kein std::string benutzen."
Die Wortwahl ist vermutlich nicht gut getroffen, aber als ich den Satz schrieb, habe ich an den Overhead gedacht, den std::string mit sich bringt.
Wie ich bereits geschrieben habe, setze ich auch std::string ein und wollte hier nur eine Alternative zeigen, wie man es auch noch machen kann. Empfehlen tue ich selber auch std::string, weil es auch einfacher zu verwenden ist, als die Funktionen aus <cstring>.
Artchi schrieb:
Wenn doch, sollten wir alle aufhören in C++ zu programmieren und lieber zu C zurück kehren.
Soso. Heißt das, dass die einzige Erneuerung in C++ die string-Klasse ist?
-
ok ... alles klar... könnte jemand dann bitte sagen wie mein programm mit std::string wäre?
-
#include <iostream> #include <string> int main() { std::cout << "Wer bist du? "; std::string isim, o="Oguzhan", oe = "Ömer", k = "Kemal"; std::cin >> isim; if(isim == o) std::cout << "Hey Oguzhan!!!" << std::endl; else if(isim == oe) std::cout << "Hi Ömer!!!" << std::endl; else if(isim == k) std::cout << "Moin Kemal!!!" << std::endl; std::cin.get(); }
-
ChrissiB schrieb:
aber als ich den Satz schrieb, habe ich an den Overhead gedacht, den std::string mit sich bringt.
Sag mir doch bitte welchen Overhead std::string hat? Ich kann keinen nenneswerten Overhead finden. Was brauchen wir denn für einen String?
1. Ein char-Array
2. Eine Variable, die die Anzahl der Felder speichert.Ehm, also für mich macht das nur eine int-Variable mehr aus. Für den Komfort und vorallem die SICHERHEIT die mir String gegenüber einem C-String bietet, nehme ich doch seeeeehr gerne 32bit bzw. 4byte mehr Speicherverbrauch pro String in Kauf, oder? Performancemäßig macht das ganze sogar garkeinen Unterschied gegenüber alten C-Strings.
-
ChrissiB schrieb:
Michael E. schrieb:
ChrissiB schrieb:
Michael E. schrieb:
std::string::c_str()
Willst du das const wegcasten mittels const_cast<T>(foo)?
Sonst kriegste nen Error: invalid conversion from `const char*' to `char*'Verstehe ich nicht, was willst du mir damit sagen?
Ich weiß, dass c_str() ein const char* zurückliefert, damit der interne nicht von außerhalb verändert werden kann. Manche Funktionen aus C-Libs erwarten aber ein char*.Oh, flasch rum gelesen. Aber wie viele Libs wollen denn char*?
-
ChrissiB schrieb:
Soso. Heißt das, dass die einzige Erneuerung in C++ die string-Klasse ist?
Nein, aber es ist doch eine der meistbenutzen Typen in einem Programm. Ich kenne keine Software die nicht mit Strings hantieren muß, neben anderen Typen wie int. Und C-Strings sind vorallem sehr gefährlich zu handhaben. Ich meine nur, deshalb haben wir doch C++? Um bessere Programme zu schreiben.
-
VIELEN DANK AN ALLE!!!!!!!!!!!!!
DANGE DANGE DANGE DANGE!!!!!!!!!!!!!!!!
-
Artchi schrieb:
Was brauchen wir denn für einen String?
1. Ein char-Array
2. Eine Variable, die die Anzahl der Felder speichert.Bei meiner Implemention (g++) hat die Klasse allerdings noch mehr Members.
Er speichert u.a. auch noch die Kapazität (Typ: size_t) oder ebenfalls_Atomic_word _M_references;
, sowie auch noch
mutable _Alloc_hider _M_dataplus;
. Wobei ich mir nicht sicher bin, wozu er das braucht. Es wird also definitiv mehr gebraucht und somit ist der Overhead auch größer, jedoch auch nicht allzu groß., d.h. ein Overhead ist garantiert da bei std::string.
Artchi schrieb:
Ehm, also für mich macht das nur eine int-Variable mehr aus.
siehe oben
Artchi schrieb:
Für den Komfort und vorallem die SICHERHEIT die mir String gegenüber einem C-String bietet, nehme ich doch seeeeehr gerne 32bit bzw. 4byte mehr Speicherverbrauch pro String in Kauf, oder?
Wenn man viel mit String machen muss, ganz klar. Aber es reicht doch manchmal auch ein char* aus bei kleinern Programmen. Natürlich ist man bei großen Projekten mit std::string besser bedient, vor allem wenn man Zeichenketten oft braucht. Ich mache auch nie so was:
std::map<int, char*> map; // allerdings eher soetwas std::map<int, std::string> map;
Es kommt halt auf das zu lösende Problem an, was du nun einsetzten musst (was am Effektivtes ist).
Michael E. schrieb:
Oh, flasch rum gelesen. Aber wie viele Libs wollen denn char*?
Da gibt es doch einige. Z.B. die WinAPI.., genauer wird es da nen TCHAR afaik sein. Was machst du dann dort?? Doch casten? Oder eine umständliche Kopie des Stringes in ein char-Array? Oder gibt es da eine ideale Lösung?? Ich lasse mich gerne belehren.
(Wobei man natürlich den Einsatz von C-Libs meiden soll und notfalls, wenn es gar nicht mehr geht, eher ein C++ Wrapper nehmen soll. z.B. gtk -> gtkmm)
Artchi schrieb:
Nein, aber es ist doch eine der meistbenutzen Typen in einem Programm. Ich kenne keine Software die nicht mit Strings hantieren muß, neben anderen Typen wie int. Und C-Strings sind vorallem sehr gefährlich zu handhaben. Ich meine nur, deshalb haben wir doch C++? Um bessere Programme zu schreiben.
Habe ich eigentlich gesagt, dass ich char* in meinen Programmen einsetzte und diese an alle Anfänger weiterempfehle??
Ich glaube nicht. Mir sind durchaus die Gefahren bekannt bei der Zeiger-Variante. Darüber habe ich aber bereits ein paar Postings weiter oben gesagt. Es kommt wie gesagt darauf an, an was du gerade programmierst.
Ich will mich hier aber nicht rechtfertigen.
Dass man mit C++ bessere Programme schreiben kann, bezweifle ich. Jedes C-Programm oder in einer anderen Programmiersprache kann gut und hilfreich sein, wenn der Entwickler auch Ahnung bzw. Erfahrung in seiner Sprache hat. Eine Programmiersprache ist doch wie eine Menschensprache. Man kann mit den Vokabular (das ist Syntax) und mittels Gramatik (Denkweise) Sätze bilden, um mit anderen zu kommunizieren (die Kommunikation ist das Endprodukt daraus, also bei der Programmierung das Programm). Es gibt sehr viele Sprachen, die die Menschheit spricht, so wie es einige Programmiersprachen gibt. Doch in jeder dieser Sprachen kann man kommunizieren, es kommt schlussendlich auf das Selbe hinaus. Wer besser in seiner Sprache sprechen kann, kann auch sich besser ausdrücken gegenüber anderen. (das Programm kann ich jeder Programmiersprache gut sein) Jedoch kann es schwierig sein, neue Sprachen zu lernen, weil die Grammatik (die Denkweise bei den Programmiersprachen, z.B. OOP, funktionale Programmierung oder imperative Programmierung) oder das Vokabular (Syntax) zu schwer sind. So ist es auch bei Programmiersprachen, man drückt mit ihnen aus, wie man seine Programme schreiben will (bei Menschensprache ist es die Kommunikation mit anderen). Aber nun genug davon.
Man kann zwar durch die Erweiterungen (hauptsächlich OOP und generische Programmierung) bei C++ mehr machen. Doch auch bei diesen Freiheiten besteht noch immer die Gefahr (besonders für die mit wenig Erfahrungen), dass man schnell den Überblick dabei verlieren kann, was man denn nun einsetzten soll. Beispiel: Welcher Container ist der richtige für meine Programm?, häufige Frage im Forum. Das könnte heißen, dass auch durch mehr Freiheiten, die die Programmiersprache (C++) einem gibt, mehr Fehler entstehen könnten.
Erfahrene Entwickler wissen sich jedoch zurecht und können mit den Mitteln, die ihnen gegeben wird, besser programmieren. Ob sie dadurch bessere Programme schreiben, wie C-Programmierer, weiß ich nicht. Sie können es aber in kürzerer Zeit das Ziel erreichen.
So das wars erstmal.