c++.rtl - how to use malloc
- Nicholas Jordan (35/35) Sep 25 2005 In the middle of trying to get a bunch of other stuff to work,
- Heinz Saathoff (15/34) Sep 26 2005 // assumeing
- Nicholas Jordan (24/58) Dec 18 2005 I figured this out, why I made that mistake and rushed in and
In the middle of trying to get a bunch of other stuff to work, the code: --------------------------------code size_t size_(sizeof(randomInts)/sizeof(randomInts[0]));// 5120 int's int* buffer_ = static_cast<int*>(::malloc(size_)); ::memcpy(static_cast<void*>(buffer_), static_cast<void*>(&randomInts[0x0000]), size_); if(sort(buffer_,mono_size)) { FILE* fp_ = ::fopen("B:\\Database.dat","w"); size_t count_written = ::fwrite(static_cast<void*>(buffer_),sizeof(int),5120,fp_); -------------------------------end code blows out on an access violation at the call to ::fwrite - I had the file write in sort(), but decided to take it out of there while I figure out why qsort() wouldn't work. Using the debugger, it may be accessing the array of int's as 16 bit ints. I thought all memeory models were 'flat 32 bit' if Win32 is selected as the project type on the prj::edit drop-down Groggy right now due to trip to hospital yesterday - really futile for me to try to penetrate this -> the assembly window showed an address at the point of blowout way below the base address where exe's get loaded....the call was working fine b4 moved it to main()....f8 falls into the fopen call, floppy lights up, debugger goes to next statement and there it blows out ...... When I tried to dig into this, just about everything had been enregistered and the memory model shows an unsorted area, looking just like the file written, with no changes occuring while the registers seemed to be responding to my crude sort and search attempts.... really would like some suggestions on this.... http://www.docdubya.com/belvedere/cpp/cppfaq.htm A dog will treat you like one of the family..... A cat will treat you like one of the staff. A hard drive head reading off the platter has been compared to a SR-71 on terrain following radar counting blades of grass
Sep 25 2005
Nicholas Jordan schrieb...In the middle of trying to get a bunch of other stuff to work, the code:--------------------------------code// assumeing int randomInts[5120];size_t size_(sizeof(randomInts)/sizeof(randomInts[0]));// 5120 int's// size_ is 5120 nowint* buffer_ = static_cast<int*>(::malloc(size_));// buffer_ is 5120 chars long, but only 5120/sizeof(int) ints // with sizeof(int)==4 in 32bit model buffer has space for // 1280 ints only! // you would probably allocate buffer as int *buffer_ = new int[size_]; // new takes care about object size!::memcpy(static_cast<void*>(buffer_), static_cast<void*>(&randomInts[0x0000]), size_);// only 1/4 of randomInts is copied to buffer_if(sort(buffer_,mono_size))// what is mono_size?{ FILE* fp_ = ::fopen("B:\\Database.dat","w"); size_t count_written = ::fwrite(static_cast<void*>(buffer_),sizeof(int),5120,fp_);// you try to write sizeof(int)*5120 bytes but buffer_ // has allocated space for 5120 bytes only!-------------------------------end code blows out on an access violation at the call to ::fwrite - I had the file write in sort(), but decided to take it out of there while I figure out why qsort() wouldn't work.Take care of object sizes and byte sizes! - Heinz
Sep 26 2005
In article <MPG.1da1be0251b8fc829896f3 news.digitalmars.com>, Heinz Saathoff says...Nicholas Jordan schrieb...I figured this out, why I made that mistake and rushed in and posted it, I don't know - I usually catch stuff like that before embarrasing myself.In the middle of trying to get a bunch of other stuff to work, the code:--------------------------------code// assumeing int randomInts[5120];size_t size_(sizeof(randomInts)/sizeof(randomInts[0]));// 5120 int's// size_ is 5120 nowint* buffer_ = static_cast<int*>(::malloc(size_));// buffer_ is 5120 chars long, but only 5120/sizeof(int) ints // with sizeof(int)==4 in 32bit model buffer has space for // 1280 ints only!// you would probably allocate buffer as int *buffer_ = new int[size_]; // new takes care about object size!I have been frustrated in the past by relying on language features I did not full understand: new can allocate basic types, just like it can some class I write and is not limited to allocation of a class ?I have this habit of naming things (vars and objects in my program) by names outside of cs to avoid collisions with stdlib and system calls. That coding style was developed after much hard dredging in unproductive hours wasted looking at the screen. I now have namespace the {} as a place holder in // L:\itc\methods.cpp - 33972 characters, 3817 words, 1007 lines awaiting the day when someone can tell me whether the 'semicolon expected' parse error (there is one other error, I do not have the out in front of me) is a significant error that could fail a shipped exe later after I have forgotten about that issue. Obviously, that would solve much of the issue, but for now .... the fingers are trained not to name many func()'s the obvious name so that I can rest assured that I won't try to name some func strlen or something. 'Mono' is trace of Monocerotids that was left in my mind when I was coding that. Monocerotids is an asteroid or meteor shower.::memcpy(static_cast<void*>(buffer_), static_cast<void*>(&randomInts[0x0000]), size_);// only 1/4 of randomInts is copied to buffer_if(sort(buffer_,mono_size))// what is mono_size?That was one of those working too fast mistakes. My apologies and thanx for your help.{ FILE* fp_ = ::fopen("B:\\Database.dat","w"); size_t count_written = ::fwrite(static_cast<void*>(buffer_),sizeof(int),5120,fp_);// you try to write sizeof(int)*5120 bytes but buffer_ // has allocated space for 5120 bytes only!-------------------------------end code blows out on an access violation at the call to ::fwrite - I had the file write in sort(), but decided to take it out of there while I figure out why qsort() wouldn't work.Take care of object sizes and byte sizes!- Heinz
Dec 18 2005