Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » char=ein buchstabe?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] [ 2 ] [ 3 ] > 4 < [ 5 ] [ 6 ]
030
26.07.2003, 02:23 Uhr
~Stefan
Gast


Mach es einfach so.
Funktioniert einwandfrei ohne Absturz.Der einzigste der hier vielleicht manchmal abstürzt scheint Oxdeadbeef zu sein.

int main()
{
char name[20];//max 20 Zeichen
cin >> name;
cout << name;
return 0;
}
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
031
26.07.2003, 10:28 Uhr
0xdeadbeef
Gott
(Operator)



Lies nochmal, und dann sag mir, dass ein Unterschied zwischen

C++:
char name[20];


und

C++:
char *p;


besteht. (Kleine Hilfe: Es hat was mit dem angeforderten Speicher zu tun)
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
032
26.07.2003, 13:18 Uhr
Spacelord
Hoffnungsloser Fall


@stefan:
char name[20];//max 20 Zeichen
19!!

MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
033
26.07.2003, 13:47 Uhr
Spacelord
Hoffnungsloser Fall



Zitat:
0xdeadbeef postete
...mal abgesehen von denen, die in der Zeit was Vernünftiges hätten hinkriegen sollen...

Und was ist wenn du mal die wunderbare Welt der Klassen verlassen musst und deinem Chef beichten musst:"Sorry,char* ist zwar ein ganz besonderer Grunddatentyp aber davon hab ich keine Ahnung.Wie String intern funktioniert ist ein Buch mit 7 Siegeln!"Das kommt bestimmt gut an und die nächste Gehaltserhöhung ist dir gewiss.
Und was Assembler angeht:
Mit ASM wird man schneller konfrontiert als einem lieb ist!Nicht am Anfang,aber der Zeitpunkt kommt.Der Horizont der wundersamen Hochsprachen ist nicht so weit wie man denkt!!
Sobald du was machen willst was das API des jeweiligen Systems nicht anbietet,kannst du dich auf Treiberniveau und Assembler einstellen.
Mehrere Sprachen(unterschiedlicher Abstraktionsebenen) sind ganz bestimmt kein Nachteil.
Ich kann nicht so ganz nachvollziehen wie du eine Aussage wie "Ach char*,nimm doch lieber string das ist idiotensicher" vertreten kannst?


MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
034
26.07.2003, 14:04 Uhr
0xdeadbeef
Gott
(Operator)


Dass man char* verstehen sollte, wenn man ernsthaft coden will, ist klar. Ob man sich aber, wenn man gerade anfängt, zu programmieren, gleich mit Zeigerarithmetik rumschlagen sollte, wage ich zu bezweifeln.
Dass man etwas verstehen sollte, heißt aber nicht, dass man es auch immer auf blöd anwenden sollte. Zu verstehen, wie eine Registermaschine funktioniert, ist eine sinnvolle Sache. Assembler zu schreiben macht dagegen nur sehr selten Sinn, weil moderne Compiler in aller Regel besser optimieren, als man es selbst von Hand hinbekäme. Dasselbe gilt für string vs. char*. Du solltest den char* verstehen, aber mit string arbeiten - und dabei das Wissen, was du über char* und Speichermanagement hast, anwenden. Nimm zum Beispiel folgendes Stück Code:

C++:
char s[21];
cout << "Gib 20 Zeichen ein: ";
cin >> s;


Wenn du einen DAU hast, der nicht zählen kann und dir 30 Zeichen eingibt, baut das Programm Mist. Nimm dagegen

C++:
string s;
cout << "Gib 20 Zeichen ein: ";
cin >> s;


Das ist sicher, und du kannst den Fehler abfangen. Allerdings ist es nicht performant, weil der string u.U. mehrmals neuen Speicher anfordern muss. Deswegen macht man es sinnigerweise so:

C++:
string s(20);
cout << "Gib 20 Zeichen ein: ";
cin >> s;


Denn so fordert der string zu Anfang schonmal 20 Zeichen an, und du hast trotzdem die Sicherheit, dass das Ding keinen Mist baut, wenn der User zu dumm ist.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 26.07.2003 um 14:05 Uhr von 0xdeadbeef editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
035
26.07.2003, 14:23 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat:
0xdeadbeef postete

[...]
Das ist sicher, und du kannst den Fehler abfangen. Allerdings ist es nicht performant, weil der string u.U. mehrmals neuen Speicher anfordern muss. Deswegen macht man es sinnigerweise so:

C++:
string s(20);
cout << "Gib 20 Zeichen ein: ";
cin >> s;


Denn so fordert der string zu Anfang schonmal 20 Zeichen an, und du hast trotzdem die Sicherheit, dass das Ding keinen Mist baut, wenn der User zu dumm ist.


Kommt mir nicht standardconform vor. Ein Ctor, der einen int als Parameter erwartet, gibt es nicht. Wenn ich das Richtig sehe, erwartest von einem solchen non-standard ctor, daß er die Stringlänge limitiert. Da kann ich nicht beurteilen, weil Du offenbar etwas nicht Standardkonformes verwendest, aber idR überschreibt der op>> von istream den Alten Inhalt ohne Rücksicht auf verluste.

C++:
string(größe, zeichen)


geht übrigens, zeitigt aber nicht den gewünschten Effekt.

Wer bei IO Operationen an solchen Stellen auf Performance achten muß (kann sich eigentlich nur um nicht Interaktive IO handeln, also aus Dateien oder anderen sachen ohne Benutzerinteraktion), wird eh ganz schnell auf den trichter kommen, nicht die Streamklassen zu verwenden, weil die schon recht viel hin und her kopieren und Belegen und freigeben und konstruieren und destruieren, daß das verlängern des Strings eigentlich nur noch das Tüpfelchen auf dem i ist.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)

Dieser Post wurde am 26.07.2003 um 14:24 Uhr von virtual editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
036
26.07.2003, 14:37 Uhr
0xdeadbeef
Gott
(Operator)


Ups, ich war irgendwie der Meinung, dass der Konstruktor, der (int, char) anfordert, einen default-Wert für den char annimmt, so dass einfach nur Speicher angefordert wird. Erst denken, dann schreiben. Also gut, dann macht mans so:

C++:
string s;
s.reserve(20);


Außerdem war das ganze sowieso mehr als Verdeutlichung gemeint, dass Standardkonstrukte und -algorithmen normalerweise den besten Mittelweg zwischen Performance und Sicherheit bieten, und es dementsprechend meistens mehr Sinn macht, sie zu verwenden, als den ganzen Mist nochmal neu zu schreiben.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 26.07.2003 um 14:39 Uhr von 0xdeadbeef editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
037
26.07.2003, 14:39 Uhr
Spacelord
Hoffnungsloser Fall


Das man in der Praxis string nutzen wird ist klar(da reden wir offensichtlich aneinander vorbei ) !
Die Funktion die ich gepostet hatte ist aber von ihrer Funktionalität her das was string intern macht(zumindest in gaaaanz groben Zügen).
Ob man nun erst string nutzen sollte um sich anschliessend damit zu beschäftigen was es mit char* auf sich hat,oder ob man sich mit C Zeichenketten beschäftigt und dann string als grosses Geschenk ansieht ist ist wohl eher eine didaktische Frage.
Ich fand die Funktion,in diesem Zusammenhang(char*),auf jeden Fall schöner als ein starres Array zu nutzen(das Beispiel von Stefan).
Wenn ich mir den Thread dann weiter anschaue,könnte es so manchen auch nicht schaden sich mal genau über Stack/Heap und virtuellen Speicher zu erkundigen.

Das moderne Compiler effizienteren Code erzeugen als "durchschnittlicher" Assemblercode halte ich für ein Gerücht.

MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
038
26.07.2003, 15:17 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat:
Spacelord postete
Das man in der Praxis string nutzen wird ist klar

Mir ist das nicht klar: wenn man wirklich nur 20 bzw. eine andere feste Anzahl von Zeichen einlesen will, dann ist der op>> genauso fehl am Platz wie die verwendung von std::string.

Beefys vorschlag mit dem reserve kann ich noch immer nicht nachvollziehen, mag zwar Standardkonform sein, aber dann hat man eben einen String, der Anfangs 20 Zeichen fassen kann; später aber muß trotzdem noch prüfen, ob man denn nun mehr als 20 zeichen hatte oder nicht und das Performance Argument: naja, kann ich da nur sagen.

Ich würde den ganzen kram mit einem ganz schnöden:

C++:
char buffer[20];
cin.get(buffer, sizeof(buffer),'\n');


abfackeln:
1. Kein nachfolgender Test notwendig, ob nun wirklich mehr las 20 Zeichen eingegeben wurden: das sind max. 20, fertig
2. Keine "PerformanceProbleme"
3. Direkte Umsetzung in string problemlos möglich. durch

C++:
....
string s(buffer);


--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
039
26.07.2003, 16:24 Uhr
Spacelord
Hoffnungsloser Fall


Naja,
es war nie die Rede davon dass nur 20 Zeichen eingelesen werden sollen!
Und was spricht in der Praxis dagegen string zu nutzen(vorausgesetzt man hat die Besonderheiten von C Zeichenketten verstanden)?
Erzähl mir jetzt bitte keinen von Performance,dann dürftest du ohnehin kein C++ programmieren!!
Und bevor jetzt die Frage kommt was denn sonst, C oder Turbo Pascal!
Beides,bei gleicher Funktionalität,definitiv schneller als C++!
Wir reden hier nicht über konzeptionelle Vorteile von C++!
Mach mal nen Performancetest,gib mal mit Turbo Pascal 1 Milliarde mal "hello World" aus und mach das gleiche mal mit C++. Das kannst du fein mit der Uhr erfassen.


MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] [ 2 ] [ 3 ] > 4 < [ 5 ] [ 6 ]     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: