C++: Länge eines Strings an einem char Pointer? - Seite 2

Seite 2 von 3 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/c_laenge_eines_strings_an_einem_char_pointer_99683/page_2 - zur Vollversion wechseln!

Jedi schrieb am 26.11.2003 um 17:37

wenn du den ASM code herzeigst, mach bitte ein Foto von der "Tussn"

mat schrieb am 26.11.2003 um 17:44

Code:

char* s1 = "wasweisich"

wtf?! sagt was..

FMFlash schrieb am 26.11.2003 um 18:41

Zitat von Ringding
Von dir oder abgeschrieben?

Schaut irgendwie aus, als käme es aus der MS CRT.

richtig erkannt, ist aus dem strlen.asm von vs6

Zitat von mat
Code:
char* s1 = "wasweisich"
wtf?! sagt was..

ich denke es wird allgemein angenommen das diese zeile nur pseudocode darstellt (ansonsten ... unbedingt ändern!)

Code:

char s1[] = "wasweisich\0"

würde schon genügen, wenn ein statisches char-array ausreicht.

Ringding schrieb am 26.11.2003 um 18:45

Zitat
richtig erkannt, ist aus dem strlen.asm von vs6

Funktioniert natürlich nur, wenn sie auf Intel Maschinen arbeiten und ist daher nicht wirklich empfehlenswert

Aber es ist wenigstens nicht Windows-abhängig.

Ringding schrieb am 26.11.2003 um 18:47

@mat & FMFlash:

Wo soll das Problem sein? Das ist eine absolut korrekte Schreibweise.

manalishi schrieb am 26.11.2003 um 19:05

Zitat von Ringding
Funktioniert natürlich nur, wenn sie auf Intel Maschinen arbeiten und ist daher nicht wirklich empfehlenswert
Aber es ist wenigstens nicht Windows-abhängig.

warum denn nicht? das soll der user beim compilieren einstellen. für motorola gehts etwa gleich einfach, so lange irgendein register incrementieren bis das gefetchte byte 0 also equal ist.. eine der schnellsten schleifen überhaupt

Ringding schrieb am 26.11.2003 um 19:08

Nur wenn du's so in Assembler schreibst, dann kannst es gleich in C schreiben. Genau das wird der Compiler nämlich ausspucken. Die gepostete Version ist doch recht gut geschwindigkeitsoptimiert, weil sie pro Iteration gleich 4 Bytes überprüft.

mat schrieb am 26.11.2003 um 19:28

wann hat sich das eingeschlichen? is ja furchtbar.. ich mein, es ist einfach inkonsistent. weil logischerweise weise ich so einem pointer eine adresse zu, ned den inhalt. na ja, c++ halt. ich bin da eher der oldschooltyp. ich liebe zwar oop, aber ich hasse string sowie cin und cout und etliche andere fehlgeburten

FMFlash schrieb am 26.11.2003 um 19:38

Zitat von Ringding
@mat & FMFlash:

Wo soll das Problem sein? Das ist eine absolut korrekte Schreibweise.

stimmt, kommt im endeffekt auf das gleiche wie die [] variante (allerdings fehlt der null-terminator?). ich persönlich verwende pointer für "strings" nur wenn es dynamisch sein soll, also immer in verbindung mit malloc/calloc/realloc/free - deshalb kam es mir auf den ersten blick falsch vor

Ringding schrieb am 26.11.2003 um 19:43

Der \0 Terminator wird automatisch erzeugt, wenn du doppelte Anführungszeichen verwendest.

@mat: Es wird ja eh die Adresse zugewiesen, nämlich die Adresse vom statisch allokierten String.

mat schrieb am 26.11.2003 um 20:46

das is IMO auch das problem! wenn ich einen kleinen lokalen buffer brauche dann verwende ich char szBuffer[255], wenn ich einen globale string brauche, dann nehm ich einen char *. die char* szFoo = "arg" methode ist extrem fehleranfällig, weil folgendes einen fehler ergibt:

Code:

void
foo(char *szBla)
{
    szBla = "idiot";
}

main:

char *szBla = "cool";
foo(szBla);

sicher is das idiotisch, aber das wäre ein typischer einsteigerfehler bzw. auch eine umsteigerfalle. zB in php wär das vollkommen korrekt.

ich würde sagen man sollte sich so und so eine eigene string klasse coden, verstrickt mit einer klasse die auf memory leaks achtet. damit verabschiedet man jegliche leaks in der "problematischen" richtung.

edit: shit, ich meinte das:

Code:

void
foo(char **szBla)
{
      *szBla = "idiot";
}

..das problem is: das geht! nur warum? "idiot" dürfte nur lokal alloziert werden.

Ringding schrieb am 26.11.2003 um 22:24

Strings werden immer statisch alloziert.

Richtig, das geht. Sollte es auch.

mat schrieb am 26.11.2003 um 22:47

aber denk mal nach: eigentlich ist das ned die beste methode. bei jedem string der so zugewiesen wird, erstellt der compiler einen statisch, globalen bereich. ich würde eher auf lokal plädieren, weil wenn ich einen globalen adressbereich haben will, dann sollte ich selber einen allozieren müssen, und zwar mit bedacht.

is nur so ein kleiner gedanke

Ringding schrieb am 26.11.2003 um 22:55

Magst jetzt das 30 Jahre alte C umkrempeln?

Ringding schrieb am 26.11.2003 um 22:58

Ich versteh außerdem nicht ganz, was du meinst.

Die eine Möglichkeit, "lokal" zu verstehen, heißt, dass es einfach im Object File keinen Namen kriegt, also das, was mit static Funktionen und Variablen passiert. Die liegen auch "global" im Datensegment, sind aber namenlos, daher von außen nicht zugreifbar (außer man reicht einen Pointer raus).

Die andere Möglichkeit wäre, dass man es als "am Stack liegend" auffasst. Das ist aber ziemlich sinnlos. Wie soll es denn dort hinkommen? Es müsste bei jedem Eintritt in die Funktion auf den Stack kopiert werden. Und damit's überhaupt kopiert werden kann, muss es erst recht wieder im Datensegment herumliegen. Also ein lose-lose