Char erhöhen

Scheppertreiber

Das geht so eh nicht durch den Compiler

char *s = "A";
*s++;
printf( "\ndas kommt da raus: %s", s);

Dürfte ein B werden.

supertux

Scheppertreiber schrieb:

Das geht so eh nicht durch den Compiler

doch, Pointer Arithmetik.

Scheppertreiber schrieb:

char *s = "A";
*s++;
printf( "\ndas kommt da raus: %s", s);

Dürfte ein B werden.

auch nicht, "A" ist read-only. Das Programm wird mit höher W-keit mit segfault enden.

Scheppertreiber

Mein Compiler läßt solche Späße zu, das OS auch ...

Im Prinzip hast Du Recht, die Konstruktion an sich ist nicht sinnvoll.
Eigentlich wollte ich den OP mit der Nase draufstoßen daß ein String auch
nur aus einzelnen Bytes besteht.

mathias_80

*argumente[1]++;

funktioniert nicht.

int ascii = (int) argumente[1];
        ascii = ascii +1;
        argumente[1] = (char) ascii;

auch nicht. Compiler: "cast from pointer to integer of different size".

Ronny2

char argumente[4];
argumente[0] = 'A';
argumente[0]++;

Das funktioniert.

supertux

mathias_80 schrieb:

*argumente[1]++;
funktioniert nicht.

klar, das sagte ich bereits, "A" ist read-only.

mathias_80 schrieb:

int ascii = (int) argumente[1];
        ascii = ascii +1;
        argumente[1] = (char) ascii;
auch nicht. Compiler: "cast from pointer to integer of different size".

Ich wiederhole mich ungern, aber denk nach, was du da geschrieben hast. Was ist der Unterschied zwischen

argumente[1] = (char) ascii;

und

*argumente[1] = (char) ascii;

??? Einfach kurz überlegen und dann merkst du es sofort. Außerdem ist zeigt arguments[1] auf Read-Only Bereich, den du nicht überschreiben kannst.

Mein Compiler läßt solche Späße zu, das OS auch ...

welche Späße meinst du genau?

Scheppertreiber

Die Späße:

Mein Aztek-Compiler trennt nur zwischen Code- und Datensegment, da gehen solche
Sachen problemlos (kann man schön am Assembler-Output nachverfolgen).

Die moderneren Compiler legen ja bald für jeden String ein eigenes Segment an ...

Scheppertreiber schrieb:

Mein Compiler läßt solche Späße zu, das OS auch

der compiler müsste eigentlich stringkonstanten in ein read-only segment stecken. d.h. es gibt eigentlich nur 2 möglichkeiten: eine exception (vom os oder der cpu) beim schreibzugriff, oder es passiert einfach gar nichts. aber niemals sollte aus dem A ein B werden. also: schnell den compiler oder das os wechseln.

Scheppertreiber

In C gibt's noch ganz andere Späße

Ich bestimme was ein Programm macht - niemand anderes.
Sonst kann ich gleich Basic oder so einen Müll nehmen.

Scheppertreiber schrieb:

In C gibt's noch ganz andere Späße

erzähle...

Scheppertreiber schrieb:

Ich bestimme was ein Programm macht - niemand anderes.

das ist ja auch richtig so, aber an ein paar wenige regeln sollte man sich schon halten. was haben read-only segmente für einen sinn, wenn man sie doch beschreiben kann? wenn du schon code schreibst, der stringkonstanten manipuliert, dann mach wenigstens 'nen fetten kommentar drüber, etwa wie:

/**
 * BUGBUG: This only works with aztec and DOS 1.0!!!!
 **/

Scheppertreiber

So manchmal nehme ich den Aztek noch - er kann aber leider keine langen
Dateinamen (nicht so toll). Ansonsten klein, schnell, praktisch.

Wenn Du richtige Späße mit C willst, dann schau Dir das Windows-Api an.
Wenn das mal Open Source wird, gibt es OS nicht mher (die haben sich totgelacht).

*prost* (schaue gerade Otti :-))

mathias_80

kk

Scheppertreiber

kk ?

hm und was soll an der winapi so witzig sein? nenn doch mal ein konkretes beispiel bitte.

mathias_80

Huch. So geht es:

#include <stdio.h> 

int main(void) 
{ 
    char b[] = "A";
    char *string[4]; 

    string[1] = b;
    (*string[1])++; 

    printf("Nachher: %s\n", string[1]);

    return 0; 
}

supertux

genau, ich hoffe, du hast verstanden, warum.