Thank You -- Thomas J. Gritzan

[Tom]

Thomas -- Your suggestion to malloc() out a block of memory was the
perfect solution. Thank you kindly for your guidance.

My program now runs in 28% of the time it previously required!! )
Almost 4 times faster!! That's a WOW in my book! Now my hard drive
only loads up data once instead of grinding away endlessly!

Below are some details of my memory issues ...

Years ago with c++ ver 1.51 I used the huge memory model and far
pointers to get beyond the 64k limits. Once I started using C++ ver
6.0 and C++ .Net the 64k limitations were no longer a factor and I
could simply use globally defined arrays of complex structures and did
not bother with malloc() because it seemed unnecessary.

As time went on I saw reference to malloc() in books discussing
objects that manage their own memory requirements ... but I thought
why bother with objects or malloc() when my program is functional?

Once I began trying to store larger and larger amounts of buffered
data to speed I/O operations by using increasingly larger arrays ...
the program would not compile. I did not understand why. The Thomas
Gritzan suggestion led me to revisit malloc() and understand that I
was exceeding the limitations of the newer C++ compilers.

I had been using the task manager to confirm the computer had reserve
memory. (I even upgraded the computer memory from 512 to 1 gig as an
attempt to solve the problem.) I knew the size of data I eventually
wanted to buffer could exceed the previously available memory ... but
I did not realize why I could not access the newer memory after I
installed it. Additionally, the compiler failure happened long before
my original 512 of memory was consumed. I was confused and simply did
not understand what the heck was going on.

As a work around solution I guessed a ram disk would solve the
problem. I had used ram disks back in the mid 80's. I posted a feel
out question in here and the off topic police were fast to type away
their frustrations in the form of telling me to go away. HAHAHA. They
would not tell me where to go ... just that I was in the wrong user
group. Some help that was not!! Why even bother telling someone they
are off topic? Just ignore the thread and go run a few miles if you
have too much frustration built up. Or better yet ... get a girl
friend instead of playing the role of off topic policeman. LMAO. If
your post is not part of the solution you are part of the pollution!
If the request seems off topic ... show off your expertise by steering
the topic towards a C based solution.

Then there is Thomas Gritzan. (The hero of this not so short story.)
He realized first what the real problem was and made the
recommendation that solved all my memory usage problems. Yeah, I was
lost and I admit it. So much so that I did not even properly define
the exact problem I had because I did not realize what it was! I was
grasping for a solution and searched the user group for a ram disk
discussion and found none. So I posted a very simple ram disk topic.

Now I am using malloc(), realloc() and free(). I am casting the
pointer output of malloc() and realloc() to match my data structure.
(The need for this casting is poorly described in the realloc() doco
in my opinion.) With new familiarity using these routines I will find
the continued transition to pure object usage much easier.

Thanks again >>> T. Gritzan <<<

======================================================================
Am I glad I posted a ram disk question in this group? Absolutely!! It
led the way to the best solution.

Am I working solely in a C/C++ environment? Yes. I use binary and text
files and the C/C++ environment exclusively and fail to see how
anything I attempt inside that box can be off topic.

Am I grateful to those who honestly attempted to help me with viable
code even when I initially failed even to define my operating system,
compiler, etc. Absolutely yes!! I learned Linux has some neat features
and I will consider using it sometime in the future.

Upon a revisit of my original posting do I find T.Gritzan to be the
absolutely first to use the "malloc" word. No. Another did so in a
reply to a reply of a reply. Rather deep into the thread. But their
first reply was an intentional joke and was intended to make fun of me
and not to be of any help what-so-ever. So by then I was so tuned out
that their usage of malloc and zero lack of explanation forced it into
the zero box of usefulness. Utterly ignored.

For other newbs to the group who get told they are off topic,
ridiculed, become the target of insider jokes, etc. Post away, repost,
disguise your question in a new post with a different title. Create
another user name and post again. Sooner or later a real jewel of
information might come along that is hugely beneficial. And your
persistence will frustrate the off topic police and give them a target
to vent their frustrations. If you get offended by the onslaught of
the self imposed police. Become a troll. Have some fun. Make the self
imposed want-to-be-furors scream in agony. HAHAHA. Perhaps troll under
another user name. Think about that mr. policeman, because it is
you who makes trolls! duh!! LOL

-- Tom

 

[Richard Heathfield]

Tom said:

Now I am using malloc(), realloc() and free(). I am casting the
pointer output of malloc() and realloc() to match my data structure.
Why?

(The need for this casting is poorly described in the realloc() doco
in my opinion.)

There is no such need. The cast is unnecessary and obfuscatory, and can
conceivably conceal the bug of failing to provide a prototype for *alloc,
which happens from time to time.

<snip>

 

[Tom]

Tom said:



There is no such need. The cast is unnecessary and obfuscatory, and can
conceivably conceal the bug of failing to provide a prototype for *alloc,
which happens from time to time.

<snip>

My compiler chokes without using the cast for malloc() or calloc().
When I don't match the realloc with the same cast ... the program
again fails to compile. Thus I am confused by your claim it is
unnecessary. Can you provide an short example without the cast that I
can test on my compiler?

The following is a MS example that FAILS to compile:

#include <stdio.h>
#include <malloc.h>
#include <stdlib.h>

void main( void )
{
long *buffer;
size_t size;

if( (buffer = (long *)malloc( 1000 * sizeof( long ) )) == NULL )
exit( 1 );

size = _msize( buffer );
printf( "Size of block after malloc of 1000 longs: %u\n", size );

/* Reallocate and show new size: */
if( (buffer = realloc( buffer, size + (1000 * sizeof( long )) ))
== NULL )
exit( 1 );
size = _msize( buffer );
printf( "Size of block after realloc of 1000 more longs: %u\n",
size );

free( buffer );
exit( 0 );
}
=============================
Here's the compiler error:

Compiling...
main.cpp
c:\stock programs\temp project tbd\main.cpp(40) : error C2440: '=' :
cannot convert from 'void *' to 'long *'
Conversion from 'void*' to pointer to non-'void' requires an
explicit cast
Error executing cl.exe.

temp project tbd.exe - 1 error(s), 0 warning(s)

=============================

Someone did not even take the effort to compile their own example!!

Add the cast and it works. >>

#include <stdio.h>
#include <malloc.h>
#include <stdlib.h>

void main( void )
{
long *buf;
size_t size;

if( (buf= (long *)malloc( 1000 * sizeof( long ) )) == NULL )
exit( 1 );

size = _msize( buf);
printf( "Size of block after malloc of 1000 longs: %u\n", size );

/* Fix Compile Problem By Adding Cast */
if((buf=(long *)realloc(buf,size+(1000*sizeof(long)))) == NULL )
exit( 1 );
size = _msize( buf);
printf( "Size of block after realloc of 1000 more longs: %u\n",
size );

free( buf);
exit( 0 );
}

==================================

Deleting intermediate files and output files for project 'temp project
tbd - Win32 Debug'.
---------Configuration: temp project tbd - Win32 Debug---------
Compiling...
main.cpp
Linking...

temp project tbd.exe - 0 error(s), 0 warning(s)

 

[Christopher Benson-Manica]

My compiler chokes without using the cast for malloc() or calloc().

It seems that you are invoking your compiler as a C++ compiler; the
cast is required in that language. See question 7.7c (and then 7.7
and 7.7b) of the C FAQ: http://c-faq.com/malloc/mallocnocast2.html.
Note that the details of how to invoke your Microsoft compiler as a
conforming C compiler (assuming it can be done) are best addressed on
a different newsgroup.

 

[Keith Thompson]

On Tue, 12 Sep 2006 08:54:16 +0000, Richard Heathfield


My compiler chokes without using the cast for malloc() or calloc().
When I don't match the realloc with the same cast ... the program
again fails to compile. Thus I am confused by your claim it is
unnecessary. Can you provide an short example without the cast that I
can test on my compiler?

Then you're doing something wrong. Either you don't have prototypes
for malloc() and realloc() (the way to get those prototypes is

The following is a MS example that FAILS to compile:

#include <stdio.h>
#include <malloc.h>

There is no standard <malloc.h> header (though some implementations
may provide it as an extension). The *alloc() and free() functions

#include <stdlib.h>

void main( void )

main() returns int, not void.

{
long *buffer;
size_t size;

if( (buffer = (long *)malloc( 1000 * sizeof( long ) )) == NULL )
exit( 1 );

The only portable values to be passed to exit() are 0, EXIT_SUCCESS,
and EXIT_FAILURE. exit(1) can indicate success on some systems,
failure on others.

size = _msize( buffer );

_msize() is non-standard.

printf( "Size of block after malloc of 1000 longs: %u\n", size );

/* Reallocate and show new size: */
if( (buffer = realloc( buffer, size + (1000 * sizeof( long )) ))
== NULL )
exit( 1 );

exit(1) again.

size = _msize( buffer );

_msize() again.

printf( "Size of block after realloc of 1000 more longs: %u\n",
size );

free( buffer );
exit( 0 );
}
=============================
Here's the compiler error:

Compiling...
main.cpp

The ".cpp" suffix is commonly used for C++ source files. If you want
to compile C, you probably need to use a ".c" suffix -- and you
*definitely* need to use a C compiler. (C allows implicit conversions
between void* and other pointer types; C++, in many cases, does not.)

Here's a version of your program that will work correctly *if* you
compile it as C. (It will fail if you compile it as C++.)

========================================================================
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
long *buffer;
long *temp_buffer;

#define SIZE1 1000
#define SIZE2 2000

printf("Attempting malloc(%lu)\n",
(unsigned long)(SIZE1 * sizeof *buffer));
buffer = malloc(SIZE1 * sizeof *buffer);
if (buffer == NULL) {
fprintf(stderr, "malloc() failed\n");
exit(EXIT_FAILURE);
}
printf("malloc() succeeded\n");

printf("Attempting realloc(buffer, %lu)\n",
(unsigned long)(SIZE2 * sizeof *buffer));
temp_buffer = realloc(buffer, SIZE2 * sizeof *buffer);
if (temp_buffer == NULL) {
printf("realloc() failed, but buffer is still valid\n");
}
else {
printf("realloc() succeeded, "
"setting buffer to point to result\n");
buffer = temp_buffer;
}

printf("free(buffer)\n");
free(buffer);
return 0;
}
========================================================================

Here's the output I got:
========================================
Attempting malloc(4000)
malloc() succeeded
Attempting realloc(buffer, 8000)
realloc() succeeded, setting buffer to point to result
free(buffer)
========================================

The output will vary if the malloc() or realloc() call fails.

 

[CBFalconer]

.... snip ...

The following is a MS example that FAILS to compile:

#include <stdio.h>
#include <malloc.h>
#include <stdlib.h>

void main( void )
{
long *buffer;
size_t size;

if( (buffer = (long *)malloc( 1000 * sizeof( long ) )) == NULL )
exit( 1 );

size = _msize( buffer );
printf( "Size of block after malloc of 1000 longs: %u\n", size );

/* Reallocate and show new size: */
if( (buffer = realloc( buffer, size + (1000 * sizeof( long )) ))
== NULL )
exit( 1 );
size = _msize( buffer );
printf( "Size of block after realloc of 1000 more longs: %u\n",
size );

free( buffer );
exit( 0 );
}
=============================
Here's the compiler error:

Compiling...
main.cpp
c:\stock programs\temp project tbd\main.cpp(40) : error C2440: '=' :
cannot convert from 'void *' to 'long *'
Conversion from 'void*' to pointer to non-'void' requires an
explicit cast
Error executing cl.exe.

temp project tbd.exe - 1 error(s), 0 warning(s)

=============================

Someone did not even take the effort to compile their own example!!

Add the cast and it works.

You are using a C++ compiler. Don't do that. I don't know just
how you control the MS monstrosity, but look to the IDE setup
and/or the source file naming. The file extension should be
lowercase .c, not .cpp.

 

[Michael Mair]

My compiler chokes without using the cast for malloc() or calloc().
When I don't match the realloc with the same cast ... the program
again fails to compile. Thus I am confused by your claim it is
unnecessary. Can you provide an short example without the cast that I
can test on my compiler?

The following is a MS example that FAILS to compile:

#include <stdio.h>
#include <malloc.h>

#include <stdlib.h>

void main( void )

Ouch. Which MS compiler are you using that it does not tell
you that this is wrong?
main() always returns int:
int main (void)

{
long *buffer;
size_t size;

if( (buffer = (long *)malloc( 1000 * sizeof( long ) )) == NULL )
exit( 1 );

C:
buffer = malloc(1000 * sizeof *buffer)
and
exit(EXIT_FAILURE);
If your compiler complains about the version without cast, you
probably are compiling C code as C++ code -- which may lead to
different behaviour than expected. The above certainly is not
C++ as you should write it.

size = _msize( buffer );

I do not know what _msize() does but it seems to be something
implementation specific.

printf( "Size of block after malloc of 1000 longs: %u\n", size );

/* Reallocate and show new size: */
if( (buffer = realloc( buffer, size + (1000 * sizeof( long )) ))
== NULL )
exit( 1 );

Comments as above.

size = _msize( buffer );
printf( "Size of block after realloc of 1000 more longs: %u\n",
size );

free( buffer );
exit( 0 );

This is portable (in contrast to 1 as argument); you also could
use
exit(EXIT_FAILURE);
or
return 0;

}
=============================
Here's the compiler error:

Compiling...
main.cpp

Note that by giving your C code a typical C++ suffix you are
essentially telling the compiler to assume C++ rather than C.
Either tell the compiler explicitly that you want C or try the
difference between "main.cpp" and "main.c".

c:\stock programs\temp project tbd\main.cpp(40) : error C2440: '=' :
cannot convert from 'void *' to 'long *'
Conversion from 'void*' to pointer to non-'void' requires an

C++ is a language different from C.
Do not expect that simple things like "sizeof 'a'", "int foo();",
"const bar = 1;", or a number of others mean the same in these two
languages.
<OT>
Note: If using C++, you typically do _not_ use malloc() and friends,
you do not use C casts but C++ casts to perform value conversion,
change of type qualifiers, or reinterpretation of representation,
respectively.

explicit cast
Error executing cl.exe.

temp project tbd.exe - 1 error(s), 0 warning(s)

=============================

Someone did not even take the effort to compile their own example!!

<snip>

You are either frequenting the wrong newsgroup or do not operate
your compiler correctly...


Cheers
Michael

 

[Martin Ambuhl]

My compiler chokes without using the cast for malloc() or calloc().

Then you are not invoking it as a C compiler. No doubt whatever
language you are writing your C-like code in has its own newsgroup.

When I don't match the realloc with the same cast ... the program
again fails to compile. Thus I am confused by your claim it is
unnecessary. Can you provide an short example without the cast that I
can test on my compiler?

The following is a MS example that FAILS to compile:

#include <stdio.h>
#include <malloc.h>

Why are you including the above non-standard header? If you need

#include <stdlib.h>

void main( void )

^^^^
This is not legal in a hosted environment in either C or C++, so I guess
that your compiler is not being used as either a C compiler or a C++
compiler. BTW the C++ names for the two standard headers above are

{
long *buffer;
size_t size;

if( (buffer = (long *)malloc( 1000 * sizeof( long ) )) == NULL )

Not only is the above an ugly and error-prone way of writing
if ( (buffer = malloc(1000 * sizeof *buffer)) == NULL)
or
if (!(buffer = malloc(1000 * sizeof *buffer)))
but

exit( 1 );

This is downright silly. The argument values for exit that have
portably defined meanings are 0, EXIT_SUCCESS, and EXIT_FAILURE. That
list does not include 1.

size = _msize( buffer );

And _msize is not a standard function.
[etc.]

 

[Richard Heathfield]

CBFalconer said:

You are using a C++ compiler. Don't do that. I don't know just
how you control the MS monstrosity, but look to the IDE setup
and/or the source file naming. The file extension should be
lowercase .c, not .cpp.

It's not difficult to do this, actually. When starting a new "Win32 console"
project in Visual Studio, I take the following steps to maximise my chances
of a portable program:

1) in Project/Settings, find the (cough) C/C++ tab, and use the pull-down
menu to gain access to three specific settings (each requires a different
dropdown menu selection, and I'm on Linux right now, as usual, so I can't
quite remember the selections' names):

(a) crank the warning level up to 4
(b) disable Microsoft extensions
(c) disable precompiled headers

2) whenever creating a new file, select "C++ source file" from the list of
file types (because "C source file" isn't listed!), but name it "foo.c"
rather than "foo.cpp". That's sufficient to ensure that the source will be
compiled under C rules.

 

[Keith Thompson]

Tom wrote: [...]

void main( void )

^^^^
This is not legal in a hosted environment in either C or C++, so I
guess that your compiler is not being used as either a C compiler or a
C++ compiler.

It depends on what you mean by "not legal".

An implementation may legally accept declarations for main other than
the two explicitly mentioned in the standard. In C99, implementations
are explicitly permitted to do this; in C90, it's covered by the
general permission to provide extensions.

If you use "void main(void)" on an implementation that doesn't provide
it as an extension (i.e., that doesn't document it), the behavior is
undefined. It's not a constraint violation, so no diagnostic is
required.

But there is really no good reason for a programmer to use
"void main(void)". The standard "int main(void)" is *guaranteed*
to work.