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

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 now

> int* 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

In article <MPG.1da1be0251b8fc829896f3@news.digitalmars.com>, Heinz Saathoff says...
>
>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 now
>
>> int* 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!

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.

>// 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 ?

>> ::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?
>

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.

>> {
>> 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!
>
That was one of those working too fast mistakes. My apologies and thanx for your help.
>
>- Heinz