Eigenartiges Verhalten in String-Klasse

moin

Ein paar Sachen sind mir aufgefallen, ich weiss nciht ob es daran liegt aber es ist mir halt ausgefallen, und zwar:

1. Mal benutzt du "string", mal "String" und mal "CString", vielleicht solltest du dich für eins entscheiden.

2. "String" gehört laut MSDN zur ".NET Framework Class Library", während "string" und "CString" zur "Standard C++ Library" gehört.


mfg
umbrasaxum
 
Daß wir drei verschiedene String-Typen verwenden (genaugenommen sogar vier, wegen des Character Arrays), hat einzig und allein den Grund des Testens, weil wir halt alles versuchen wollten, daß es funktioniert. Aber nichts davon funktioniert wirklich. Und wir verstehen halt nicht, wieso.

String ist in unserem Fall, da wir kein .NET verwenden, eine von uns selbst entwickelte Klasse. Da lag unsere erste Vermutung, daß die nicht richtig funktioniert. Doch die Vermutung bestätigte sich nicht, als wir es erst mit CString, dann mit string und zuletzt mit char[] versuchten. Wir haben sogar ein char *buf = new char[256]; versucht. Nichtmal das führte zum erwünschten Erfolg. Genau so wenig, wie ein char *buf = (char*)malloc(256);.

Nichts funktioniert!

Achso, um das nochmal zu verdeutlichen: kompilieren und starten funktioniert. Auch die Aufrufe durchläuft er offenbar. Doch irgendwas läuft da im Hintergrund eindeutig schief. Und es gibt keine Mitteilung darüber, was schief läuft. Keine Fehlermeldung, gar nichts. Es geht einfach nur nicht.
 
Hi jccTeq,

gefunden hab ich bisher auch nichts weiter. Das einzige ist, das bei mir im Assembler Code Symbole verwendet werden für die const char.
Unter diesen Symbolen werden in der Segmentliste auch die entsprechenden Strings belegt.
Bei mir steht z.B.: (ich hab den string mit abcdefghjkl belegt, um ihn leichter zu finden)
push OFFSET FLAT:_C@_0N@PDDN@abcdefghijkl?$AA@ ; `string'
bei dir
push OFFSET FLAT:$SG92795
Schau mal nach , ob diese const char Strings (wie "HALLO") wirkich in der Segmentliste stehen.

Du hast wahrscheinlich nur einen anderen Compiler, der die Segmentbezeichnung anders wählt. Aber ein Fehler, wie du ihn beschreibst, dürfte so ja auch nicht auftreten. Also sollte man alle Möglichkeiten in Betracht ziehen.

Es könnte aber, wei revelation meint, auch ein Zugriffsproblem sein. Habt ihr euer Projekt schon mal im Release Mode erstellt? Dann treten solche Fehler eher auf, da im Debugmode die Speicherzuteilung grosszügiger erfolgt, um Debuginformationen mit abzulegen.

Gruss
Dora
 
Also weiter oben steht im Assembler-Code das da:
Code: 
$SG92795 DB	'HALLO', 00H
	ORG $+2

Das Symbol stimmt also.

Das mit der Release-Version müssen wir nochmal ausprobieren. Der Kollege ist heute aber leider schon im Wochenende. Die faule Socke... :D Naja. Schauen wir Montag mal. Danke erstmal für die Hinweise. Wer nochwas weiß oder vermutet, bitte fleißig posten! ;)

Schönes Wochenende, Leute!

Gruß, Hendrik
 
Was auch sein koennte:
Du verwendest den String "HALLO" auch noch irgendwo anders, aber ausversehen wird an der anderen Stelle in die Konstante geschrieben.

Also z.B. so:
Code: 
/* Abschnitt 1, der vor Abschnitt 2 ausgefuehrt wird */
char *bug = "HALLO";
bug[0] = 0;


/* Abschnitt 2: */
char *s = "HALLO";
printf("%s\n", s);
 
Das müssten aber zwei verschiedene Constanten sein, weil sie beide nur innerhalb ihrer Funktion gültig sind. Außerdem werden Constanten ja nicht durch ihren Inhalt definiert.
 
Wie meinst du das?
Zwei gleiche Konstanten teilen sich den gleichen Speicher, sprich ihre Adressen sind gleich.

Wenn nun zwei Pointern auf char die gleiche Konstante (= die gleiche Adresse) zugewiesen wird, ist der Wert der Pointer gleich, egal ob sie sich in unterschiedlichen Funktionen befinden oder nicht.

Folgendes Beispiel gibt zwei gleiche Adressen aus:
Code: 
char *addr[2];

void foo1(void)
{
    char *a = "HALLO";
    addr[0] = a;
}

void foo2(void)
{
    char *b = "HALLO";
    addr[1] = b;
}

int main(void)
{
    foo1();
    foo2();

    printf("ptr1: %p\n", addr[0]);
    printf("ptr2: %p\n", addr[1]);

    return 0;
}
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück