Thank You -- Thomas J. Gritzan

Discussion in 'C Programming' started by Tom, Sep 12, 2006.

  1. Tom

    Tom Guest

    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
    Tom, Sep 12, 2006
    #1
    1. Advertising

  2. Tom said:

    <snip>
    >
    > 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>

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Sep 12, 2006
    #2
    1. Advertising

  3. Tom

    Tom Guest

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

    >Tom said:
    >
    ><snip>
    >>
    >> 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>


    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)
    Tom, Sep 12, 2006
    #3
  4. Tom <> wrote:

    > 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.

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Sep 12, 2006
    #4
  5. Tom <> writes:
    > On Tue, 12 Sep 2006 08:54:16 +0000, Richard Heathfield
    > <> wrote:

    [...]
    >>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?


    Then you're doing something wrong. Either you don't have prototypes
    for malloc() and realloc() (the way to get those prototypes is
    "#include <stdlib.h>", or you're using a C++ compiler, or something
    else.

    > 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
    are declared in <stdlib.h>.

    > #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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Sep 12, 2006
    #5
  6. Tom

    CBFalconer Guest

    Tom wrote:
    >

    .... 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.

    --
    "I was born lazy. I am no lazier now than I was forty years
    ago, but that is because I reached the limit forty years ago.
    You can't go beyond possibility." -- Mark Twain



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Sep 12, 2006
    #6
  7. Tom

    Michael Mair Guest

    Tom schrieb:
    > On Tue, 12 Sep 2006 08:54:16 +0000, Richard Heathfield
    >>Tom said:
    >><snip>
    >>
    >>>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>

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


    Non-standard header, <stdlib.h> is sufficient.

    > #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.
    </OT>

    > 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
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Sep 12, 2006
    #7
  8. Tom wrote:
    > On Tue, 12 Sep 2006 08:54:16 +0000, Richard Heathfield
    > <> wrote:
    >
    >> Tom said:
    >>
    >> <snip>
    >>> 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>

    >
    > 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
    that in addition to <stdlib.h>, then you are not using a C compiler.
    > #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
    <cstdio> and <cstdlib>.
    > {
    > 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.]
    Martin Ambuhl, Sep 12, 2006
    #8
  9. CBFalconer said:

    <snip>

    > 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.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Sep 12, 2006
    #9
  10. Martin Ambuhl <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Sep 12, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Miguel Dias Moura
    Replies:
    1
    Views:
    387
    =?Utf-8?B?QmlsbCBCb3Jn?=
    Apr 1, 2004
  2. Miguel Dias Moura
    Replies:
    1
    Views:
    405
    Lars Netzel
    Jun 18, 2004
  3. Miguel Dias Moura
    Replies:
    2
    Views:
    330
    Martin
    Jun 22, 2004
  4. Shawn
    Replies:
    8
    Views:
    373
    Shawn
    Sep 21, 2006
  5. PETER WONG F H (+971 50 8320722)

    Please send you property detail to me,thank you !

    PETER WONG F H (+971 50 8320722), Mar 14, 2010, in forum: Python
    Replies:
    0
    Views:
    304
    PETER WONG F H (+971 50 8320722)
    Mar 14, 2010
Loading...

Share This Page