AnsiString - Segen oder Fluch?

int02h

Hallo,

wir arbeiten seit 2 Jahren mit XE2 und haben relativ viele Threads in denen u.a. AnsiStrings benutzt werden. Mittlerweile knallt es alle Paar Minuten bei AnsiContainsText() oder .UpperCase(). Bei allen möglichen AnsiString-Routinen.
Das war unter BCB6 nicht so. Wir versuchen derzeit zu ergründen woran das liegt. Unsere Projekte haben ein paar Threads hinzubekommen. Insgesamt reden wir hier vielleicht von 150 Quelldateien, davon 20 Formulare.
Kann XE2 keine "großen" Projekte handlen oder sind AnsiStrings nicht threadsafe? Woran liegt es? Das problem tritt auch erst seit ein paar Wochen auf. Ist da eine max. Grenze an CPPs überschritten? Was ist das Problem?

Der Debugger steigt immer mit ner Exception aus "Zu wenig Arbeitsspeicher".

Wir haben die Stack und die heap size erhöht. Ressourcen leaks gibts keine, der Code ist sauber.

Vielleicht weiß jemand was?

Viele Grüße int02h

Edit: ich glaube das hat was mit CodeGuard zu tun.

akari

Hallo

Ja AnsiString ist wie die allermeisten Klassen der VCL *nicht* threadsafe. So eine Instanz immer zusätzlich durch eine Critical Section abgesichert werden, wenn mehrere Threads drauf zugreifen.

bis bald
akari

audacia

AnsiString und UnicodeString sind keine VCL-Klassen. Sie gehören zu den "EMUVCL" genannten Supportklassen, die integrierte Delphi-Sprachfeatures in C++ emulieren. (Vollständige Liste hier: http://docwiki.embarcadero.com/RADStudio/XE3/en/Classes_that_Support_the_Object_Pascal_Language)

In Delphi sind Strings threadsicher: die Hilfsroutinen in der RTL, die sich um Stringzuweisungen kümmern, verwenden atomic operations wie XCHG und LOCK INC für das Schreiben von Stringvariablen, die Referenzzählung und Copy on write.

Referenzzählung und Copy on write sind auch in C++Builder threadsicher, und auch in C++ wird für die gewöhnliche Stringzuweisung die threadsichere Hilfsroutine aus der Delphi-RTL verwendet. Allerdings wird in dstring.cpp und ustring.cpp viel Code aus der Delphi-RTL dupliziert; es kann also sein, daß einzelne Szenarien mit AnsiString oder UnicodeString in C++ nicht threadsicher sind, wenn auf die Strings in komplizierter Weise zugegriffen wird. Das ist dann ein Bug in C++Builder. Aber beim kurzen Überfliegen von dstring.cpp fällt mir eigentlich nichts ins Auge...