Hallo!
Weiss nicht was ich falsch mache, aber schaut euch den folgenden Code an:
#include
#include
#include
#include
int main()
{
ifstream Data(„c:\test.txt“);
char * pbuf;
int iLen;
iLen = 10000;
pbuf = (char * ) malloc(iLen);
cout
Hmm… da treten wohl mehrere Probleme gleichzeitig auf:wink:
- strlen sucht so lange, bis die Funktion eine terminierende Null findet (’\0’). Sieht so aus, als würde der Speicher im release-Modus anders initialisiert sein. Grund dafür ist, daß du im debug-Modus einen größeren Stack- und Heapsize hast.
Soll heißen: du hast zwar deinen Speicher für die Zeichenkette allociiert, aber nicht initialisiert.
ein
for(int i=0;i
#include
#include
#include
int main(int argc, char* argv[])
{
ifstream Data(„c:\test.txt“);
char * pbuf;
int iLen;
int i;
iLen = 10000;
// allociieren
pbuf = (char * ) malloc(iLen*sizeof(char));
// initialisieren
if(pbuf)
{
for( i=0;i[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo !
for(int i=0;i
hmm … hehe
Hab ich zwar gemerkt, aber trotz Release-Übersetzung hat es funktioniert. Ich denke, der malloc() allociiert auf Wortgrenze (wie sonst) und gibt als Sicherheit noch einen drauf, um dort zu terminieren. Ach so … und zu vorher … im Releasefall stehen im Speicher 00 FF 00 FF-Kaskaden, im Debugfal CD CD CD CD. Dies erklärt dann auch die 1 für die Länge im Releasefall:wink:
Gruß Patrick
Hallo nochmal !
Hab ich zwar gemerkt, aber trotz Release-Übersetzung hat es
funktioniert. Ich denke, der malloc() allociiert auf
Wortgrenze (wie sonst) und gibt als Sicherheit noch einen
drauf, um dort zu terminieren.
Das Terminieren interessiert malloc mit Sicherheit nicht, da diese Funktion lediglich eine Anzahl von Bytes allociert. Der Datentyp usw ist dem malloc dabei voellig egal. Das man in char - Arrays auch Strings speichern kann, bei denen eine 0 am Ende steht, die der Programmierer nicht mit angiebt kann und tut malloc nicht erkennen und korregieren (im Gegensatz zu reinen String- Funktionen, die abschliessende 0 mit behandeln)
Das dass trotzdem auch im Release funktioniert ist wahrscheinlich nur dem Umstand zu verdanken, dass Du nicht in den Speicher anderer Programme gelangt hast-> Exception wegen hardwaremaessiger Speicherueberwachung ueber Descriptoren. Ob Du mit der 0 nicht doch irgend was anderes aus Deinem eigenen Programm ueberschrieben hast, kannst Du nur bei kleinen Programmen voellig ausschliessen. Vielleicht war natuerlich auch wegen der Speicherausrichtung auf diesem Byte keine andere Variable.
Ach so … und zu vorher … im
Releasefall stehen im Speicher 00 FF 00 FF-Kaskaden, im
Debugfal CD CD CD CD. Dies erklärt dann auch die 1 für die
Länge im Releasefall:wink:
Aha ! Ist dass mit dem 00 FF im Release- Fall immer so ? Bei VC hab ich’s noch nicht probiert, aber die meisten C++ Compiler haben den Heap nicht initialisiert.
Gruß Patrick
Gruss zurueck !
PS: noch ein Tip: solche Speichergeschichten und Pointerzugriffe ueber die Grenzen hinaus haben mich bei meinen eigenen Programmen schon oft ganze Tage und Naechte des Fehlersuchens gekostet. Wenn’s nicht’s ganz abnormes ist, versuche ich deshalb in letzter Zeit auf malloc, char * usw zu verzichten. Auch wenn Du mich jetzt „Weichei“ und „Warmduscher“ nennst, mit der C++ string- Klasse (nicht MS CString) und der STL kann man solche Sachen sauber substituieren. Ist erstmal uebersichtlicher und ausserdem kuemmern sich bei den Objekten Konstruktoren und Destruktoren um die Reservierung und Freigabe von Resourcen.
Andreas
Hallo Andreas,
mit deinem PS sprichst du mir aus der Seele - sicher gibt es, gerade für Zeichenkettenoperationen ausgezeichnete Klassen. Auch ich habe schon seit Jahrhunderten kein malloc und ähnliche Speichermanipulationen mehr benutzt, sondern liebe den Komfort lesbar und verständlich zu schreiben. Schlaue Leute haben sich da schon viele Gedanken gemacht und ich möchte jedem Leser nahelegen, die Klassen und Algorithmen der std-Library zu studieren, da diese ein Maximum an Komfort UND Portabilität bieten. Der Einstieg gestaltet sich zwar nicht ganz so einfach, aber sobald man das Prinzip der Std verstanden hat, bietet sich für den Anwender eine neue Welt - eine Vielzahl von Rädern müssen einfach nicht neu erfunden werden.
Nie würde ich einen ernsthaften Anwender von Klassenbibliotheken als Weichei bezeichnen, sondern nur diejenigen verunglimpfen, die permanent versuchen, Standart-Algorithmen immer wieder aufs neue zu implementieren in einem Stil, der einfach nicht mehr zeitgemäß sein kann. Aber trotz allem ist unter allen Entwickler diejenige Gruppe am stärksten vertreten, die sich in einem Stadium zwischen prozeduralem und objektorientierten Stil befinden, da dieser die schnellsten Ergebnisse verspricht mit dem Manko, daß die Wiederverwendbarkeit einfach nur teilweise gegeben ist, da dieser Designaspekt immer als erstes von der Liste gestrichen wird (schade aber auch!). Die Gruppe der reinen OO-Ler wächst zwar, aber ich denke es dauert noch 1-2 Programmiergenerationen (ca 4-6 Jahre), bis sich die feinen Konzepte der Objektorientierung ausreichend manifestiert haben. Designseitig ist OOD zwar mittlerweile stark im Vormarsch (dank den Amigos), aber der dann implementierte Code zeigt leider stets das teilweise Mißverständnis der Paradigmen wieder (oder wurde z.B. unter hohem Zeitdruck erstellt). Bestes Beispiel: die MFC (… hmm hat sich da jemand mal die Mühe gemach, sich die Quellen an zu schauen?). Aber jetzt genug zur Lage der Nation - Fakt ist halt, daß wir uns in einer Mischwelt bewegen. … tbc
Gruß Patrick
PS: Das mit der Speicherbelegung im Releasefall habe ich in einem früheren Projekt mal nachgeprüft, denke aber das man sich nicht darauf verlassen kann… Fakt ist aber, daß der debug_new den kompletten Speicher mit ‚CD‘ 's vollknallt (wohl um dem Entwickler stets zu zeigen … da ist was faul!)