C++ "cstring" strlen (selfmade) | mit string?

[ActiveO2]

Hallihallo,

ich möchte gerne einen string einlesen und mir diesen dann auswerten lassen.

#include "stdafx.h"
#include <iostream>


using namespace System;
using namespace std;

int strlength(const char* c)
{
	int i = 0;

	while(c[i]!=0)
		i++;

	return (i);	
}


int main()
{
	string abc = "hallo";
	
	cout << strlength("CString") << endl;  //hier würde ich gerne den string reinpacken. Als was wird "Cstring"
                                                                     //denn hier anerkannt?
	

	system("PAUSE");
    return 0;
}

wäre nett wenn mir jemand helfen kann.


Grüße,
ActiveO2

 

[skeemo]

Naja deiner Funktion strlength übergibts du ja die Adresse des Chararrays "CString", dein Aufruf ist schon korrekt so.

Oder was möchtest du denn machen ?

 

[ActiveO2]

ich würde später gerne einen string einlesen und diesen dann benutzen

string test;

cin >> test;
cout << strlength(test) << endl;

aber:
error C2664: 'strlen': Konvertierung des Parameters 1 von 'std::string' in 'const char *' nicht möglich

 

[BlackMark]

Du kannst der Funktion strlength einfach einen C-String übergeben, mit c_str() kannst du das machen:

string test;

cin >> test;
cout << strlength(test.c_str()) << endl;

Gruß
BlackMark

 

[InfoStud84]

Deine Schleifenbedingung ist auch falsch.
Richtig wäre:

while(c[i] != '\0')

 

[Stefan_Sch]

Deine Schleifenbedingung ist auch falsch.
Richtig wäre:

while(c[i] != '\0')

Dumm nur das '\0' dasselbe ist, wie 0, lieber InfoStud84.

1. Semester, oder?

 

[Limit]

ist "\0" nicht eher (char)0? Also Typ char und nicht Typ int?

 

[Stefan_Sch]

ist "\0" nicht eher (char)0? Also Typ char und nicht Typ int?

Ein char ist dasselbe wie ein int, nämlich nichts anderes, als ein ganzzahliger Datentyp! Ein char ist lediglich ein anderer Datentyp, nämlich ein Datentyp mit der Größe 1 Byte. Er kann unter der Voraussetzung das ein Byte auf der Architektur 8-Bit entsprechen, daher Dezimalzahlen zwischen -128 bis 127 (vorzeichenbehaftet) bzw. 0 to 255 (vorzeichenlos) darstellen. Ein int umfasst dagegen in aller Regel 4 Byte (IA-32), kann also einen deutlich größeren Zahlenbereich darstellen.

http://www.cplusplus.com/doc/tutorial/variables/

'\0' ist ein Escape-Zeichen. Dieses Escape-Zeichen entspricht in seiner Dezimaldarstellung dem Wert 0. Es ist also für das Ergebnis nicht relevant ob ich

while(c[i] != '\0')

oder

while(c[i] != 0)

schreibe, wobei hier implizit die Regeln der arithmetischen Typumwandlung zum Tragen kommen, die sich nach der Hierarchie der Datentypen richten. Genauso irrelevant ist es ob ich

char c = 84;

oder

char c = 'T';

schreibe. Die Kodierung des Zahlenwertes richtet sich nach dem ASCII Code.

BTW: "\0" ist nicht dasselbe, wie '\0'. Das erste ist ein string, das zweite ein character!

 

[7H3 N4C3R]

@Stefan_Sch:
Dass ein char ein Byte groß ist, da bin ich ja noch einverstanden. Beim int ist es zwar auf x86 üblich mit den 4 Byte, aber das ist nicht festgelegt. Genausowenig muss ein char den Wertebereich -128 - 127 haben. Zum einen natürlich, weil der Standard nicht fest von 8 Bits pro Byte ausgeht ^^ - aber vor allem, weil char signed oder unsigned sein kann.

Selbstverständlich sind deine beiden Beispiele nicht das Gleiche und schon garnicht haargenau.

Bei den Vergleichen erzwingt der Vergleich mit int formal eine Erweiterung des chars auf die Größe von int gemäß den Usual Arithmetic Conversions. Das ist ein etwas subtiler Unterschied, der deshalb aber nicht völlig irrelevant ist.

Bei der Initialisierung des chars wird's dann noch etwas interessanter. Zum einen muss natürlich 84 als int erstmal formal in einen char umgewandelt werden - mit den üblichen Gefahren bzw. zumindest lästigen Compilerwarnungen, wenn man breitere Datentypen in schmalere überführt. Außerdem sugerieren deine Beispiele eine gewisse Austauschbarkeit von int und char. Spätestens bei Überladungsauflösung wird es haarig.

 

[Stefan_Sch]

@Stefan_Sch:
Dass ein char ein Byte groß ist, da bin ich ja noch einverstanden. Beim int ist es zwar auf x86 üblich mit den 4 Byte, aber das ist nicht festgelegt.

Der Datentyp int ist für gewöhnlich 4 Byte groß. Selbst auf einem 64-Bit System entspricht ein int in aller Regel 4 Byte. Es ist zwar richtig, das ein "integer" prinzipiell bestmöglich an den Rechner angepasst ist, genauer gesagt an die Länge des Maschinenregisters, aber das ist Haarspalterei und in diesem Zusammenhang nicht weiter von Belang. Ich nehme kaum an, das der Threadersteller auf einem 16-Bit-Rechner arbeitet, wo ein int die Größe eines short hätte.

Genausowenig muss ein char den Wertebereich -128 - 127 haben. Zum einen natürlich, weil der Standard nicht fest von 8 Bits pro Byte ausgeht ^^ - aber vor allem, weil char signed oder unsigned sein kann.

In meinem Beispiel spreche ich aber nicht von einem signed oder unsigned char, sondern eindeutig von einem char, der in diesem Fall implizit signed ist.

Ein char hat in C++ immer 1-Byte. Es ist richtig das der Standard nicht exakt auf die Größe eingeht, stattdessen heißt es dort das ein char eine adressierbare Einheit von Daten sein muss, die groß genug ist um jedes Zeichen des Grundzeichensatzes der Ausführungsumgebung halten zu können. Alle modernen Architekturen gehen bei aber einem Byte von 8-Bit aus, irgendwelche exotischen Embedded Systeme einmal ausgeschlossen. Insofern wird in allen Lehrbüchern auch bei einem Byte von 8-Bit, also einem Wertebereich zwischen -128 to 127 gesprochen. Siehe http://www.cplusplus.com/doc/tutorial/variables/.

Selbstverständlich sind deine beiden Beispiele nicht das Gleiche und schon garnicht haargenau.

Bei den Vergleichen erzwingt der Vergleich mit int formal eine Erweiterung des chars auf die Größe von int gemäß den Usual Arithmetic Conversions. Das ist ein etwas subtiler Unterschied, der deshalb aber nicht völlig irrelevant ist.

Bei der Initialisierung des chars wird's dann noch etwas interessanter. Zum einen muss natürlich 84 als int erstmal formal in einen char umgewandelt werden - mit den üblichen Gefahren bzw. zumindest lästigen Compilerwarnungen, wenn man breitere Datentypen in schmalere überführt. Außerdem sugerieren deine Beispiele eine gewisse Austauschbarkeit von int und char. Spätestens bei Überladungsauflösung wird es haarig.

Also immer schön langsam. Auch hier ist korrekt das eine arithmetische Standardkonvertierung stattfindet, die ist in meinem Beispiel aber zu 100 Prozent sicher, weil der Standard festlegt das ein int mindestens die Größe eines char aufweisen muss. Bei der Konvertierung von char in int, werden die oberen Bits automatisch mit 0 oder Vorzeichen aufgefüllt, was abhänging von der Voreinstellung für char ist.

Das vielleicht eine 1:1 Austauschbarkeit suggeriert wird, mag vielleicht bei Anfängern der Fall sein, aber ich kann in meinen Beitrag keinen Exkurs über Typkonvertierungen und Datentypen halten.

Ich gehe prinzipiell von dem Kontext und einem Normalfall aus. In diesem Kontext stand das generelle Verhalten an vorderster Stelle und die Erklärung warum 0 und '\0' zu demselben Resultat führen. Gleichzeitig gehe ich von einem Standard 32-Bit IBM PC aus, den der Threadersteller verwendet und nicht von einer PDP-10 Architektur.

 

[7H3 N4C3R]

In meinem Beispiel spreche ich aber nicht von einem signed oder unsigned char, sondern eindeutig von einem char, der in diesem Fall implizit signed ist.

Richtig, von dem bin ich auch ausgegangen. char ist nicht implizit signed.
Siehe ISO14882/3.9.1, 3. Satz und letzter Satz:

It is implementationdefined whether a char object can hold negative values.

In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined.

Zum ersten Part noch - es ging mir nur darum deutlich zu machen, dass ein int nicht 4 Byte haben muss. Deine Aussage war absolut und suggeriert jemandem, der es nicht weiß, dass ein int immer 4 Byte hat. Dass du es selber weißt, war offensichtlich, aber vieles was hier geschrieben wird nehmen sich andere vermutlich als Anleitung.

Beim letzten Fall mit der Konvertierung im Prinzip ähnlich - natürlich ist das beobachtbare Verhalten das Gleiche. Der Code selbst aber eben nicht.

 

[Stefan_Sch]

Zum ersten Part noch - es ging mir nur darum deutlich zu machen, dass ein int nicht 4 Byte haben muss. Deine Aussage war absolut und suggeriert jemandem, der es nicht weiß, dass ein int immer 4 Byte hat. Dass du es selber weißt, war offensichtlich, aber vieles was hier geschrieben wird nehmen sich andere vermutlich als Anleitung.

Also schön, du hast mich überzeugt.

Ich habe den betreffenden Beitrag nun präziser formuliert, um Mißverständnisse aus dem Weg zu räumen.

 

[ActiveO2]

Danke BlackMark:
hat funktioniert

@Stefan_Sch (und 7H3 N4C3R):
Immer wieder cool zu lesen, was für Wissen du in die Threads reinsteckst


Grüße
ActiveO2

 

[7H3 N4C3R]

Freut mich (und Stefan_Sch sicherlich auch), wenn unser Fachgesimpel nicht nur für die Katz ist, sondern auch anderen vielleicht noch die eine oder andere Sache beibringen kann.