CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 18 of 18
  1. #16
    Join Date
    Mar 2011
    Posts
    16

    Re: dynamic array allocation

    i read that too..and i got uniform results under Win7, Ubuntu Intrepid and Lucid...but all under GCC/G++ and MinGW...plus it was a surprise as i never thought of it that way (see post #2..lot of ppl don't know)... so i posted here to know if people do really make use of this in practice..

    btw, Paul's comment on the need to over-allocate blocks was insightful too..

  2. #17
    Join Date
    Jan 2010
    Posts
    1,133

    Re: dynamic array allocation

    Hi. In addition to what others said, I'd just like to make a few points. In one of your posts, you were referring to Stroustrup's book. You've probably read this:
    To deallocate space allocated by new, delete and delete [] must be able to determine the size of the object allocated. This implies that an object allocated using the standard implementation of new will occupy slightly more space than a static object. Typically, one word is used to hold the object's size.

    [Emphasis by me.]
    Furthermore, in that article you've linked to:

    Here's how the Microsoft C++ compiler manages vector allocation. Note that this is internal implementation detail, so it's subject to change at any time, but knowing this may give a better insight into why mixing scalar and vector new/delete is a bad thing.

    The important thing to note is that when you do a scalar "delete p", you are telling the compiler, "p points to a single object." [...]

    When you do "delete[] p", you are saying, "p points to a bunch of objects, but I'm not telling you how many."

    [Emphasis by me.]
    So, these just reflect on how things work under the hood, but you should never rely on some specific implementation. And this recommendation goes beyond C++ syntax - when you write code that uses classes from a library, you shouldn't rely on the implementation details either, but on the public interface of the class instead. In a good design, the internal details will be hidden anyway.

  3. #18
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,675

    Exclamation Re: dynamic array allocation

    I just found something for those who use VC++ and, despite all the good advice above, still want to mess around with implementation details: the _heapwalk() CRT function.

    I rememberd having used that function back in the days of MS C 6.0 (without ++) under DOS and got curious whether it's still there. And although the MSDN documentation on that function is as of VC++ 6.0 it's actually still there in VC++ 2010.

    The following is a modified version of the MSDN sample code from the _heapwalk() page. The main intention behind the modifications was to have the program use new [] and delete [] instead of malloc() and free(), and to enable it to identify the test object created during the demo, but there are some more minor modifications.

    Code:
    /* heapwalk.cpp: This program "walks" the heap, starting
    * at the beginning (_pentry = NULL). It prints out each
    * heap entry's use, location, and size. It also prints
    * out information about the overall state of the heap as
    * soon as _heapwalk returns a value other than _HEAPOK.
    */
    
    #include <stdio.h>
    #include <malloc.h>
    #include <string.h>
    #include <new>
    
    void heapdump(int *tocheck);
    
    void main( void )
    {
      char *buffer;
    
      heapdump(NULL);
      if( (buffer = new(std::nothrow) char[59]) != NULL )
      {
        strcpy(buffer, "Test!");
        heapdump((int *)buffer);
        delete [] buffer;
      }
      heapdump(NULL);
    }
    
    void heapdump(int *tocheck)
    {
      _HEAPINFO hinfo;
      int heapstatus;
      int *lastentry = NULL;
      hinfo._pentry = NULL;
      while( ( heapstatus = _heapwalk( &hinfo ) ) == _HEAPOK )
      {
        if (lastentry && tocheck >= lastentry && tocheck < hinfo._pentry) {
          // Place breakpoint here to inspect our object's heap block pointed to by lastentry
          printf(" ***** Our object!");
        }
        printf( "\n&#37;6s block at %Fp of size %8.8X",
          ( hinfo._useflag == _USEDENTRY ? "USED" : "FREE" ),
          hinfo._pentry, hinfo._size );
        lastentry = hinfo._pentry;
      }
      printf("\n");
    
      switch( heapstatus )
      {
      case _HEAPEMPTY:
        printf( "OK - empty heap\n" );
        break;
      case _HEAPEND:
        printf( "OK - end of heap\n" );
        break;
      case _HEAPBADPTR:
        printf( "ERROR - bad pointer to heap\n" );
        break;
      case _HEAPBADBEGIN:
        printf( "ERROR - bad start of heap\n" );
        break;
      case _HEAPBADNODE:
        printf( "ERROR - bad node in heap\n" );
        break;
      }
    }
    I think this could be used to actually find out about the size of objects allocated on the heap, but iterating over (at average) half the entire heap just to find out the size of some object (what appears to be the goal of the OP) would be terrible inefficient. Better simply use std::vector in the first place, as already suggested by (at least) Russco as far back as post #3 which would not only be considerably more efficient but also not relying on implementation details.

    I think I should emphasize again that this CRT function is solely meant for diagnostic use.

    From post #16 it looks as if the OP isn't using VC++, but I still wanted to post the result of my research for curious minds (like myself ) in general.
    Last edited by Eri523; March 31st, 2011 at 05:33 PM. Reason: Minor code glitch
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured