Jump to content

  • Log In with Google      Sign In   
  • Create Account


gdunbar

Member Since 22 Feb 2006
Online Last Active Today, 05:50 AM

Posts I've Made

In Topic: How dangerous is returning a initialized pointer in C++?

22 July 2014 - 06:07 AM

All the discussion about smart pointers is great. However, it is possible to make the original code safe (or safer) without using smart pointers. You need to use a static function for Create, instead of a standard function. A static function is part of the class, but doesn't access any of the class members, and thus is safe to use even if you don't have an instantiated object. So, change:

EngineAPI *Create();

To:

static EngineAPI *Create();

And change:

gEngine = gEngine->Create();

To:

gEngine = EngineAPI::Create();

Again, all the smart pointer and ownership discussion is great, but static Create functions are a pattern you'll often see, and are perfectly valid.

 

Geoff


In Topic: Bitmap loader: Memory corruption and debugging

16 May 2014 - 09:29 AM

 

I'm not saying that it isn't the problem, but I have the feeling that I've written beyond one of the pointers I've manually allocated.  This error has manifested itself before, and I am quite sure that is where I am screwing up.  If my theory in response #4 is correct, I might end up just using .tga instead..

 

 

Seems most likely. Here are the steps I would take:

 

1) Get a consistent reproduction of the crash. Writing a simple test app that simply loads and unloads a bitmap over and over might be a good start. Keep adding stuff until you can repro, but the simpler the better.

2) Once you have that, see if you can figure out why it is breaking. If (as seems like a reasonable explanation), you are writing past allocated memory, try allocating the buffer slightly bigger, and then (right before you free it) see what got written past the expected end. Set a memory breakpoint on that location and figure out what code is going wrong. Etc.

 

If you can't get a consistent repro, things are a little harder. Again, get a test program that crashes every time, if not in the same place. Randomly loading bitmaps until boom. Then, start removing code until it stops crashing. The last thing you removed was your bad actor.

 

Good luck, memory corruption bugs can be very frustrating.

 

Geoff


In Topic: Temple of the Abyssal Winds

23 April 2014 - 01:15 PM

You say that it is possible to try the first chapter for free. I didn't find any link to download the game. I probably missed(misunderstood) something.

 

Is it available right now or only in the future.

 

 

Imlandris,

 

I'll be looking for beta testers very soon, and the first (and second) chapters should be available not too long after that. Stay tuned!

 

Thanks for your interest,

Geoff


In Topic: Removing Large number of objects from vector immediately.

18 March 2014 - 07:30 AM

Well, I tried out what the OP said, and I'll be damned if he wasn't correct. Calling delete 65000 times does indeed take about 5 seconds on my system. I'm actually somewhat surprised, but when reality differs from your thoughts, I find reality is usually correct.
 
However, calling delete[] on a 65000 long array is near instantaneous. Also, calling std::vector::resize( 0 ) on a vector of objects (not pointers!) is also super fast. So, for the OP, I would advise storing objects directly in a std::vector, rather than pointers. Only if that is impossible should you look into the more complicated allocation pooling solutions.

 

Well, today is my day for not believing people! Someone else said "run without debugging, and it will be much faster". Sounded like hogwash to me. But, when I did that exact experiment, it was correct! So, OP, you may not have a "real world" issue at all. And, Javier Meseguer de Paz, apologies for not believing you at first!

 

Geoff


In Topic: Removing Large number of objects from vector immediately.

18 March 2014 - 07:25 AM

Well, I tried out what the OP said, and I'll be damned if he wasn't correct. Calling delete 65000 times does indeed take about 5 seconds on my system. I'm actually somewhat surprised, but when reality differs from your thoughts, I find reality is usually correct.

 

However, calling delete[] on a 65000 long array is near instantaneous. Also, calling std::vector::resize( 0 ) on a vector of objects (not pointers!) is also super fast. So, for the OP, I would advise storing objects directly in a std::vector, rather than pointers. Only if that is impossible should you look into the more complicated allocation pooling solutions.

 

Geoff

 

Code:

 

// ConsoleApplication1.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <vector>

#define FOONUM 65000

static int iConstructor = 0;
static int iDestructor = 0;
class CFoo
{
public:
    CFoo() { iConstructor++; }
    ~CFoo() { iDestructor++; }

    char chFoo[ 256 ];
};

int _tmain(int argc, _TCHAR* argv[])
{
    CFoo *fooArray[ FOONUM ];

    int i;
    for( i = 0; i < FOONUM; i++ )
    {
        fooArray[ i ] = new CFoo;
    }

    for( i = 0; i < FOONUM; i++ )
    {
        delete fooArray[ i ];
    }

    CFoo *fooArray2;
    fooArray2 = new CFoo[ FOONUM ];

    delete[] fooArray2;

    std::vector< CFoo > fooArray3;
    fooArray3.resize( FOONUM );

    fooArray3.resize( 0 );

return 0;
}

 


PARTNERS