Re: Problem with freeing memory

Discussion in 'C++' started by Jonathan de Boyne Pollard, Feb 18, 2010.

  1. >
    >
    > Any suggestions/solutions would be appreciated!
    >

    This is the classic
    freeing-something-other-than-the-address-returned-by-malloc error,
    nothing more complex.
    Jonathan de Boyne Pollard, Feb 18, 2010
    #1
    1. Advertising

  2. On 02/17/10 10:11 pm, Jonathan de Boyne Pollard wrote:
    >>
    >>
    >> Any suggestions/solutions would be appreciated!
    >>

    > This is the classic
    > freeing-something-other-than-the-address-returned-by-malloc error,
    > nothing more complex.
    >

    Hi Jonathan. Thanks for the reply. I am not sure I follow what you are
    saying. I have allocated pBuf with malloc in the first few lines of the
    code. At the end, I am attempting to free pBuf that was allocated
    earlier. Am I missing something here?

    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 18, 2010
    #2
    1. Advertising

  3. Jonathan de Boyne Pollard

    Sjouke Burry Guest

    Galen Henderson wrote:
    > On 02/17/10 10:11 pm, Jonathan de Boyne Pollard wrote:
    >>>
    >>> Any suggestions/solutions would be appreciated!
    >>>

    >> This is the classic
    >> freeing-something-other-than-the-address-returned-by-malloc error,
    >> nothing more complex.
    >>

    > Hi Jonathan. Thanks for the reply. I am not sure I follow what you are
    > saying. I have allocated pBuf with malloc in the first few lines of the
    > code. At the end, I am attempting to free pBuf that was allocated
    > earlier. Am I missing something here?
    >


    Dont change pBuf if you intend to free it, change a copy of
    pBuf instead, then when finished with it, free pBuf.
    Sjouke Burry, Feb 18, 2010
    #3
  4. On 02/18/10 01:22 am, Sjouke Burry wrote:
    > Galen Henderson wrote:
    >> On 02/17/10 10:11 pm, Jonathan de Boyne Pollard wrote:
    >>>>
    >>>> Any suggestions/solutions would be appreciated!
    >>>>
    >>> This is the classic
    >>> freeing-something-other-than-the-address-returned-by-malloc error,
    >>> nothing more complex.
    >>>

    >> Hi Jonathan. Thanks for the reply. I am not sure I follow what you are
    >> saying. I have allocated pBuf with malloc in the first few lines of
    >> the code. At the end, I am attempting to free pBuf that was allocated
    >> earlier. Am I missing something here?
    >>

    >
    > Dont change pBuf if you intend to free it, change a copy of
    > pBuf instead, then when finished with it, free pBuf.


    Thanks Sjouke and Ruediger. I wasn't aware that changing the index
    pointer would actually modify the original pBuf. Guess I need to crack
    out that good old c book and do some catching up.

    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 18, 2010
    #4
  5. On 02/18/10 01:31 am, Galen Henderson wrote:
    > Sjouke and Ruediger

    Hi again. Now that I think about it makes perfect sense. pNdx points
    to pBuf so it will modify the buffer. Duh!

    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 18, 2010
    #5
  6. Galen Henderson wrote:
    >> Dont change pBuf if you intend to free it, change a copy of
    >> pBuf instead, then when finished with it, free pBuf.

    >
    > Thanks Sjouke and Ruediger. I wasn't aware that changing the index
    > pointer would actually modify the original pBuf. Guess I need to crack
    > out that good old c book and do some catching up.


    Since you use a C++ compiler anyway, I would strongly recommend to move
    to C++, too.

    When you consequently use smart pointers memory allocation and heap
    corruption errors are nearly gone. Avoid any pointers to non const
    objects whenever possible.

    In your example it would look like

    using namespace std;

    bool parseFile(const char* fileName)
    { ...
    auto_ptr<char> pBuf = new char[flen];
    ...
    // will no longer compile
    // char** pNdx = &pBuf;
    const char* pNdx = pBuf.get();
    ...
    char* stri = getString(&pNdx,fLen);
    ...
    ++pNdx;
    ...
    // delete ist automatically called.
    return true;
    }

    Now the critical aliasing of pBuf is detected by the compiler, because
    auto_ptr must be modified this way.
    And note that I used const char* to prevent unwanted heap corruption by
    modifying pBuf[] beyond its limits. Of course the getXXX methods still
    may move pNdx beyond the limits and furthermore access undefined
    locations, but at least it is less risky.

    For your purpose boost::scoped_ptr would even better fit your needs. So
    if it is an option to include the boost header files I would prefer this.

    To be really clean, you should use std::string and operate on it. This
    will prevent almost any access beyond the limits. Look around for
    solutions to read an entire file into a string using C++.


    Marcel
    Marcel Müller, Feb 18, 2010
    #6
  7. Am 18.02.2010 23:28, schrieb Marcel Müller:
    > Galen Henderson wrote:
    >>> Dont change pBuf if you intend to free it, change a copy of
    >>> pBuf instead, then when finished with it, free pBuf.

    >>
    >> Thanks Sjouke and Ruediger. I wasn't aware that changing the index
    >> pointer would actually modify the original pBuf. Guess I need to
    >> crack out that good old c book and do some catching up.

    >
    > Since you use a C++ compiler anyway, I would strongly recommend to move
    > to C++, too.
    >
    > When you consequently use smart pointers memory allocation and heap
    > corruption errors are nearly gone. Avoid any pointers to non const
    > objects whenever possible.


    Smart pointers are good, but containers should be preferred.

    > In your example it would look like
    >
    > using namespace std;
    >
    > bool parseFile(const char* fileName)
    > { ...
    > auto_ptr<char> pBuf = new char[flen];


    std::auto_ptr is for single objects only. It will call delete and not
    delete[] on the pointer. For arrays, use std::vector or another
    container. For strings, std::string would be a good fit.

    --
    Thomas
    Thomas J. Gritzan, Feb 18, 2010
    #7
  8. On 02/18/10 04:28 pm, Marcel Müller wrote:
    > Galen Henderson wrote:
    >>> Dont change pBuf if you intend to free it, change a copy of
    >>> pBuf instead, then when finished with it, free pBuf.

    >>
    >> Thanks Sjouke and Ruediger. I wasn't aware that changing the index
    >> pointer would actually modify the original pBuf. Guess I need to crack
    >> out that good old c book and do some catching up.

    >
    > Since you use a C++ compiler anyway, I would strongly recommend to move
    > to C++, too.
    >
    > When you consequently use smart pointers memory allocation and heap
    > corruption errors are nearly gone. Avoid any pointers to non const
    > objects whenever possible.
    >
    > In your example it would look like
    >
    > using namespace std;
    >
    > bool parseFile(const char* fileName)
    > { ...
    > auto_ptr<char> pBuf = new char[flen];
    > ...
    > // will no longer compile
    > // char** pNdx = &pBuf;
    > const char* pNdx = pBuf.get();
    > ...
    > char* stri = getString(&pNdx,fLen);
    > ...
    > ++pNdx;
    > ...
    > // delete ist automatically called.
    > return true;
    > }
    >
    > Now the critical aliasing of pBuf is detected by the compiler, because
    > auto_ptr must be modified this way.
    > And note that I used const char* to prevent unwanted heap corruption by
    > modifying pBuf[] beyond its limits. Of course the getXXX methods still
    > may move pNdx beyond the limits and furthermore access undefined
    > locations, but at least it is less risky.
    >
    > For your purpose boost::scoped_ptr would even better fit your needs. So
    > if it is an option to include the boost header files I would prefer this.
    >
    > To be really clean, you should use std::string and operate on it. This
    > will prevent almost any access beyond the limits. Look around for
    > solutions to read an entire file into a string using C++.
    >
    >
    > Marcel

    Thanks, Gentlemen. I will be brushing up my C++ skills. Since I posted
    my last one I came upon an issue. I have converted the code into a
    clase. I am using a list<std::string> and want it to be global to the
    class and the code that creates the clase. If I define it in the
    namespace scope of the class and declare it public in the header, it is
    indeed visible from the outside of the class but I get an access
    violation whenever I try to do a push_back within the class. If I
    declare the list as a static member, it is no longer visible outside the
    class but I am able to use the list from within the clase. Any guidance
    or suggestions here?


    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 19, 2010
    #8
  9. Jonathan de Boyne Pollard

    tonydee Guest

    On Feb 19, 11:52 am, Galen Henderson <>
    wrote:
    > Thanks, Gentlemen.  I will be brushing up my C++ skills.  Since I posted
    > my last one I came upon an issue.  I have converted the code into a
    > clase.  I am using a list<std::string> and want it to be global to the
    > class and the code that creates the clase.  If I define it in the
    > namespace scope of the class and declare it public in the header, it is
    > indeed visible from the outside of the class but I get an access
    > violation whenever I try to do a push_back within the class.  If I
    > declare the list as a static member, it is no longer visible outside the
    > class but I am able to use the list from within the clase.  Any guidance
    > or suggestions here?


    Might have been better to post this as a new question. Anyway, the
    devil's in the details: posting your exact code lets us give you
    answers, especially as some of your C++ terminology is a little
    shaky. A data member being static has no relationship to the public/
    private accessibility. Any class member can be access from member
    functions. So, it's probable that your issues are in the notation
    you're attempting to use.

    Cheers,
    Tony
    tonydee, Feb 19, 2010
    #9
  10. On 02/18/10 09:04 pm, tonydee wrote:
    > Might have been better to post this as a new question. Anyway, the
    > devil's in the details: posting your exact code lets us give you
    > answers, especially as some of your C++ terminology is a little
    > shaky. A data member being static has no relationship to the public/
    > private accessibility. Any class member can be access from member
    > functions. So, it's probable that your issues are in the notation
    > you're attempting to use.
    >
    > Cheers,
    > Tony


    Tony, thanks for the reply. Here is the code segment.

    #include <stdio.h>
    #include <cstring>
    #include <list>


    class torrent
    {
    public:
    torrent();
    ~torrent();
    bool bInitialized;
    bool parseFile(const char* fileName);
    void reset(void);
    char* pName;
    char* pAnnounce;
    long lTotalLength;

    static list<std::string> lTracker;
    static list<std::string> lFiles;

    private:
    void doSwitch(char** pNdx, unsigned long& fLen);
    int getInt(char** pData, unsigned long& fl);
    char* getString(char** pData, unsigned long& fl);

    unsigned long fLen;
    }

    Here is the code snippet that tries to push-back to the list (abbreviated):

    #include "bencode.hpp"

    ....

    void torrent::doSwitch(char** pNdx, unsigned long& fLen)
    {
    list<string> foob;
    switch (**pNdx)
    {
    case '0':
    case '1':
    case '2':
    case '3':
    case '4':
    case '5':
    case '6':
    case '7':
    case '8':
    case '9':
    {
    char* stri = getString(pNdx,fLen);

    if(stricmp(lastToken,"announce") == 0)
    {
    pAnnounce = (char*) malloc(strlen(stri));
    strcpy(pAnnounce, stri);

    }

    if(stricmp(lastToken,"name")==0)
    {
    pName = (char*) malloc(strlen(stri));
    strcpy(pName, stri);
    }


    if(stricmp(lastToken,"announce-list") == 0)
    {
    lTracker.push_back(stri); // here is where it
    crashes.

    }

    break;
    I've tried making lTracker a static member and in this case, the above
    code does not crash but lTracker is not visible to the code that
    instantiates the class even though I place it in the public part of the
    class definition in the header file.

    admittedly my c++ is a lil rusty. I've been maintaining a very big (and
    messy) app that originally started out as C and was converted to CPP but
    none of the CPP features was used... Thanks to guys like you I can get
    back up to speed on CPP.

    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 19, 2010
    #10
  11. On 02/19/10 12:13 am, Galen Henderson wrote:
    > On 02/18/10 09:04 pm, tonydee wrote:
    >> Might have been better to post this as a new question. Anyway, the
    >> devil's in the details: posting your exact code lets us give you
    >> answers, especially as some of your C++ terminology is a little
    >> shaky. A data member being static has no relationship to the public/
    >> private accessibility. Any class member can be access from member
    >> functions. So, it's probable that your issues are in the notation
    >> you're attempting to use.
    >>
    >> Cheers,
    >> Tony

    >
    > Tony, thanks for the reply. Here is the code segment.
    >
    > #include "bencode.hpp"
    >
    > ...
    >
    > void torrent::doSwitch(char** pNdx, unsigned long& fLen)
    > {
    > list<string> foob;
    > switch (**pNdx)
    > {


    I forgot to mention that I declared the list in the namespace of the
    file above (where the ... is) it is as follows:

    unsigned long fLen = 0;
    char* lastToken;
    char* lastString;
    char* pBuf;
    char mBuf[1000000];
    char* pName;
    char* pAnnounce;
    long lTotalLength;
    list<string> torrent::lTracker;
    list<string> torrent::lFiles;

    Also in the header I have the lists declared as static. In this case,
    the push_back works but I cannot access the lists from the instantiating
    class...

    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 19, 2010
    #11
  12. Jonathan de Boyne Pollard

    tonydee Guest

    On Feb 19, 3:13 pm, Galen Henderson <>
    wrote:
    > #include <stdio.h>
    > #include <cstring>
    > #include <list>
    >
    > class torrent
    > {
    >   public:
    >     torrent();
    >     ~torrent();
    >     bool bInitialized;
    >     bool parseFile(const char* fileName);
    >     void reset(void);
    >     char* pName;
    >     char* pAnnounce;
    >     long lTotalLength;
    >
    >     static list<std::string> lTracker;
    >     static list<std::string> lFiles;
    >
    >   private:
    >     void doSwitch(char** pNdx, unsigned long& fLen);
    >     int getInt(char** pData, unsigned long& fl);
    >     char* getString(char** pData, unsigned long& fl);
    >
    >     unsigned long fLen;
    > }
    >
    > Here is the code snippet that tries to push-back to the list (abbreviated):
    >
    > #include "bencode.hpp"
    >
    > ...
    >
    > void torrent::doSwitch(char** pNdx, unsigned long& fLen)
    > {
    >     list<string> foob;
    >     switch (**pNdx)
    >        {
    >           case '0':
    >           case '1':
    >           case '2':
    >           case '3':
    >           case '4':
    >           case '5':
    >           case '6':
    >           case '7':
    >           case '8':
    >           case '9':
    >              {
    >                 char* stri = getString(pNdx,fLen);
    >
    >                 if(stricmp(lastToken,"announce") == 0)
    >                    {
    >                       pAnnounce = (char*) malloc(strlen(stri));
    >                       strcpy(pAnnounce, stri);
    >
    >                    }
    >
    >                 if(stricmp(lastToken,"name")==0)
    >                    {
    >                       pName = (char*) malloc(strlen(stri));
    >                       strcpy(pName, stri);
    >                    }
    >
    >                 if(stricmp(lastToken,"announce-list") == 0)
    >                    {
    >                       lTracker.push_back(stri);  // here is where it
    > crashes.
    >
    >                    }
    >
    >                 break;
    > I've tried making lTracker a static member and in this case, the above
    > code does not crash but lTracker is not visible to the code that
    > instantiates the class even though I place it in the public part of the
    > class definition in the header file.


    It's most likely that the content of stri is invalid. Have you tried
    putting in some trace (i.e. cerr << stri << '\n')? Liberal use of
    trace statements, and/or a debugger, should resolve the issue.

    You might find it useful to consider the example below. Compile it
    with/without -DSTATIC to see it working. Notice in particular the
    notation for accessing static members through the class differs from
    accessing data members through an object.

    Cheers,
    Tony

    #include <iostream>
    #include <string>
    #include <list>

    class X
    {
    public:
    #ifdef STATIC
    static
    #endif
    std::list<std::string> l;

    void fn()
    {
    l.push_back("hello");
    }
    };

    #ifdef STATIC
    std::list<std::string> X::l;
    #endif

    int main()
    {
    X x;
    x.fn();
    #ifdef STATIC
    std::cout << *X::l.begin() << '\n';
    #else
    std::cout << *x.l.begin() << '\n';
    #endif
    }
    tonydee, Feb 19, 2010
    #12
  13. On 02/19/10 12:43 am, tonydee wrote:
    > On Feb 19, 3:13 pm, Galen Henderson<>
    > wrote:
    >> #include<stdio.h>
    >> #include<cstring>
    >> #include<list>
    >>
    >> class torrent
    >> {
    >> public:
    >> torrent();
    >> ~torrent();
    >> bool bInitialized;
    >> bool parseFile(const char* fileName);
    >> void reset(void);
    >> char* pName;
    >> char* pAnnounce;
    >> long lTotalLength;
    >>
    >> static list<std::string> lTracker;
    >> static list<std::string> lFiles;
    >>
    >> private:
    >> void doSwitch(char** pNdx, unsigned long& fLen);
    >> int getInt(char** pData, unsigned long& fl);
    >> char* getString(char** pData, unsigned long& fl);
    >>
    >> unsigned long fLen;
    >> }
    >>
    >> Here is the code snippet that tries to push-back to the list (abbreviated):
    >>
    >> #include "bencode.hpp"
    >>
    >> ...
    >>
    >> void torrent::doSwitch(char** pNdx, unsigned long& fLen)
    >> {
    >> list<string> foob;
    >> switch (**pNdx)
    >> {
    >> case '0':
    >> case '1':
    >> case '2':
    >> case '3':
    >> case '4':
    >> case '5':
    >> case '6':
    >> case '7':
    >> case '8':
    >> case '9':
    >> {
    >> char* stri = getString(pNdx,fLen);
    >>
    >> if(stricmp(lastToken,"announce") == 0)
    >> {
    >> pAnnounce = (char*) malloc(strlen(stri));
    >> strcpy(pAnnounce, stri);
    >>
    >> }
    >>
    >> if(stricmp(lastToken,"name")==0)
    >> {
    >> pName = (char*) malloc(strlen(stri));
    >> strcpy(pName, stri);
    >> }
    >>
    >> if(stricmp(lastToken,"announce-list") == 0)
    >> {
    >> lTracker.push_back(stri); // here is where it
    >> crashes.
    >>
    >> }
    >>
    >> break;
    >> I've tried making lTracker a static member and in this case, the above
    >> code does not crash but lTracker is not visible to the code that
    >> instantiates the class even though I place it in the public part of the
    >> class definition in the header file.

    >
    > It's most likely that the content of stri is invalid. Have you tried
    > putting in some trace (i.e. cerr<< stri<< '\n')? Liberal use of
    > trace statements, and/or a debugger, should resolve the issue.
    >
    > You might find it useful to consider the example below. Compile it
    > with/without -DSTATIC to see it working. Notice in particular the
    > notation for accessing static members through the class differs from
    > accessing data members through an object.
    >
    > Cheers,
    > Tony


    snip

    Tony, Thanks again for the info. I have stepped through the debugger
    and stri is always valid but it always bombs on the push_back.

    I did a workaround by declaring the list static and creating a public
    accessor function. This works but I would still like to figure out why
    it bombs the other way...

    Thanks Again.
    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 19, 2010
    #13
  14. Tony, thanks again for your help. I had forgotten how to call a static
    member from an outer function. Your example cleared this up for me and
    I have removed my accessor member functions . However, I now have a new
    problem. My lists are set up as they were in the last post (which
    matches the setup in your example). To rule out the stri pointer
    alltogether, I have the push_back statement adding a string constant.
    When I try to cout the first member of the list, it won't compile and I
    get this error:

    CPPC0218E:The call does not match any parameter list for "operator<<".

    here is the code.
    int main(int argc, const char* argv[])
    {

    bool bRet = false;

    torrent* pTor;
    bRet = pTor->parseFile(argv[1]);

    torrent::lTracker.push_back("FOOBAR!");


    std::cout << *torrent::lTracker.begin();
    cout << endl;

    return 0;


    }

    --
    Regards,
    Galen
    -----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 19, 2010
    #14
  15. Thomas J. Gritzan wrote:
    > std::auto_ptr is for single objects only. It will call delete and not
    > delete[] on the pointer.


    Oops, you are absolutely right! The code would have undefined behavior,
    although it often seem to work for POD types.
    (You see that I usually use my own smart pointers rather than auto_ptr.)

    boost::scoped_array will do the job.
    Although I dislike the boost array classes because they do not keep
    track of the array size.


    > For arrays, use std::vector or another
    > container.


    Yes. But unfortunately there is no defined and performant way to adapt
    to C style libraries, because you cannot use vector to reserve memory
    and get a non const pointer to the content to pass it to C functions
    that will fill in the content.
    Furthermore vector is resizable which is not always what you intend.
    Besides allowing accidental resizing it also occupies an additional word
    to store the allocation size separated from the number of elements.
    Because of this I usually use my own scoped array class that keeps track
    of the size like vector does but is not resizeable other than by
    discarding the old content and replacing it by a new array.


    Marcel
    Marcel Müller, Feb 19, 2010
    #15
  16. Thanks for the comment, paul. Firstly, please accept my invitation to
    kiss my flabby white ass. When you are done with that, a few other
    things for you to do come to mind but I won't post them here.



    Paul Ratcliffe wrote:
    > On Fri, 19 Feb 2010 00:13:34 -0600, Galen Henderson
    > <> wrote:
    >
    >> pAnnounce = (char*) malloc(strlen(stri));
    >> strcpy(pAnnounce, stri);

    >
    > Have you any idea why this is a bad idea?
    > This is pretty fundamental C stuff. Please let me know what you are writing
    > so that I can be sure to avoid it, as it will be bug-ridden.



    --
    Regards,
    Galen
    ----
    There are only 10 kinds of people in the world. Those who understand
    binary and those who don't.
    Galen Henderson, Feb 19, 2010
    #16
  17. Am 19.02.2010 15:27, schrieb Marcel Müller:
    > Thomas J. Gritzan wrote:
    >> std::auto_ptr is for single objects only. It will call delete and not
    >> delete[] on the pointer.

    >
    > Oops, you are absolutely right! The code would have undefined behavior,
    > although it often seem to work for POD types.


    Yes, it'll work as long as the class has a trivial destructor and the
    compiler don't do special checks.

    > (You see that I usually use my own smart pointers rather than auto_ptr.)


    Same here.
    http://draig.de/linked_ptr/

    > boost::scoped_array will do the job.
    > Although I dislike the boost array classes because they do not keep
    > track of the array size.
    >
    >
    >> For arrays, use std::vector or another
    >> container.

    >
    > Yes. But unfortunately there is no defined and performant way to adapt
    > to C style libraries, because you cannot use vector to reserve memory
    > and get a non const pointer to the content to pass it to C functions
    > that will fill in the content.


    Huh? What's wrong with this:
    std::vector<int> v(1024);
    c_style_foobar( &v[0], v.size() );

    > Furthermore vector is resizable which is not always what you intend.


    Ok. For C-style functions that need a raw memory buffer, a container's
    extra functionality won't often be needed, so a smart pointer guarded
    raw array is fine.

    --
    Thomas
    Thomas J. Gritzan, Feb 19, 2010
    #17
  18. > Paul Ratcliffe wrote:
    >> On Fri, 19 Feb 2010 00:13:34 -0600, Galen Henderson
    >> <> wrote:
    >>
    >>> pAnnounce = (char*) malloc(strlen(stri));
    >>> strcpy(pAnnounce, stri);

    >>
    >> Have you any idea why this is a bad idea?
    >> This is pretty fundamental C stuff. Please let me know what you are
    >> writing
    >> so that I can be sure to avoid it, as it will be bug-ridden.


    At 19.02.2010 18:17, Galen Henderson wrote:
    > Thanks for the comment, paul. Firstly, please accept my invitation to
    > kiss my flabby white ass. [...]


    But he is right. You forgot to allocate space for the terminating zero.

    Correct would be: malloc(strlen(stri) + 1);

    Better would be to use std::string.

    --
    Thomas
    Thomas J. Gritzan, Feb 19, 2010
    #18
  19. Jonathan de Boyne Pollard

    Kaz Kylheku Guest

    On 2010-02-19, Galen Henderson <> wrote:
    > Thanks for the comment, paul. Firstly, please accept my invitation to
    > kiss my flabby white ass.


    If we go to www.hendersonsoftware.com, can we find a bug
    submission system whose HTTP response is based around
    the above message?

    It seems you would be ideally suited to work for Synaptics, maintaining
    their Windows drivers for laptop touchpad devices.

    > When you are done with that, a few other
    > things for you to do come to mind but I won't post them here.


    Things like running a program which thinks that
    strlen(x) is enough bytes to hold a null terminated
    string of length x, and that malloc never returns null?
    Kaz Kylheku, Feb 19, 2010
    #19
  20. On Feb 19, 7:20 pm, "Thomas J. Gritzan" <>
    wrote:
    > Am 19.02.2010 15:27, schrieb Marcel Müller:
    > > Yes. But unfortunately there is no defined and performant way to adapt
    > > to C style libraries, because you cannot use vector to reserve memory
    > > and get a non const pointer to the content to pass it to C functions
    > > that will fill in the content.

    >
    > Huh? What's wrong with this:
    > std::vector<int> v(1024);
    > c_style_foobar( &v[0], v.size() );


    All elements in v will be default initialized. This can be a
    performance
    problem for large arrays of POD types that are initialized from a C
    function. For this reason, I made a dynamic_array template class that
    has mostly the same interface as vector but allocates using new T,
    without initialization. This has several advantages over scoped_array:

    - STL style container
    - value type semantics
    - it knows its size
    Gert-Jan de Vos, Feb 19, 2010
    #20
    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. Rajesh.Rapaka

    freeing memory

    Rajesh.Rapaka, Apr 20, 2005, in forum: Java
    Replies:
    17
    Views:
    2,839
    Eric Sosman
    Apr 21, 2005
  2. Harald Kirsch

    freeing memory

    Harald Kirsch, Apr 22, 2005, in forum: Java
    Replies:
    0
    Views:
    429
    Harald Kirsch
    Apr 22, 2005
  3. Hassan Iqbal
    Replies:
    3
    Views:
    490
    Al Bowers
    Sep 25, 2003
  4. Rodrigo Dominguez

    memory allocation and freeing memory

    Rodrigo Dominguez, Jun 13, 2005, in forum: C Programming
    Replies:
    11
    Views:
    598
    Jean-Claude Arbaut
    Jun 15, 2005
  5. szimek
    Replies:
    0
    Views:
    117
    szimek
    Jun 22, 2009
Loading...

Share This Page