Can someone explain something to me about smart pointers and/or garbage collection?

[Raptisoft]

Hi all.

Can someone explain something to me?

You will have to explain as if talking to a child, because I've tried to understand this several times, and can't wrap my head around it. I suspect I'm just missing some core way of thinking that my aging programmer brain can't change to adopt.

In C++, if you want to do auto garbage collection-- to stop using the "delete" keyword at all... what do you do?

For instance:

int *anInt=new int;
delete anInt;

What do you do to make this do the same thing?

int *anInt=new int;
anInt=NULL; // Magically deletes it!  Wow

Wait, though... I *think* I can just, only just, understand how to do the above with a smart pointer. Which seems like a crappy solution because I'd have to use the smart pointer variable type for everything... But what about this:

Object *anObject=new Object;
ObjectList+=anObject;
AnotherObjectList+=anObject;

//
// Do stuff
//


ObjectList-=anObject;  
AnotherObjectList-=anObject; // No longer in any lists!  anObject Magically deleted!

Since all the rest of the world's lazy programmers are no longer using "delete," and since virtually all new languages don't use it... I want to understand it, but in C++ so I understand what's happening in the core of things. Or, rather, I should say, I want to continue to write in C++ for the time being, but get into the "groove" with auto garbage collection so that when the time comes that C++ games are no published (such as with XBox, thanks Microsoft... for turning into the company Apple used to be), I can adapt, and port my existing code.

Thanks a million!
--John

[Applewood]

Understanding something new is never a bad thing, but I'd try to get over this inferior feeling you have for not using "right on" programming methods. I assign most of them under the "emperors new clothes" category.

The use of any higher level C++ stuff, including STL and especially boost is outlawed in my firm. This stuff saves a bit of time and maybe nails a couple of trivial bugs here and there, right up until something goes wrong. And then it goes badly, badly wrong.

[InfiniteStateMachine]

The use of any higher level C++ stuff, including STL and especially boost is outlawed in my firm. This stuff saves a bit of time and maybe nails a couple of trivial bugs here and there, right up until something goes wrong. And then it goes badly, badly wrong.

That's a really interesting perspective. I've had some teachers tell me to use STL and Boost all the time but when I started looking at stuff like the Valve source engine, I noticed many things they needed from STL were completely re-implemented.

Do you guys use your own custom containers as replacements for stl::vector etc?

[zoombapup]

GRRRAWWWL!!!

Really, what the hell is the point in an indie reimplementing STL? For what specific purpose do you feel the need to do that?

Seriously. I'm dealing with this attitude right now so its touching a bit of a raw nerve.

If you MUST be arsy about it, at least think of using EASTL before you go doing your own. I understand that you think you have a bigger pair of balls if you can code your own version, but honest how productive is it?

I had a perfectly good plan to use a library based on STL. Only I was told I had to use an STL replacement, which wasnt very STL like. So I not only had to use the replacement, I couldnt use the library either. So we ended up copying the functionality of the library as well as the STL.

I mean where does it end? write your own compiler because you dont trust microsoft? why not go for the OS too? Thats what they used to do for the amiga/st!!

Fucking throwbacks. Get over it. I can ALMOST see the point for console centric devs like you Paul. But for the rest of us, its completely and utterly fucking pointless doing all that. Write games. Ship games. Dont write pointless bullshit code libraries because thats what real men do! GAH!

Ok. calming down now.

[zoombapup]

Oh, and I hear boost is a bit of a pig, so I havent gone there. Seems like a lot of stuff kind of depends on it. But I've never needed it. But STL has worked for me in shipped games so I'm happy to use it. Although I use EASTL now to help with mem problems.

[Applewood]

Pretty much yeah, but it's damned light. There's nothing you could point to as an "STL replacement" as such.

If you learn not to depend on it, you'd be amazed how little of it you really need day to day, which is the basis of my emperors new clothes statement.

The only times we've ever had genuine throw toys out the pram "what the fuck do I do now" bugs has always, without fail, been when we're porting a client's code and it's riddled with that shit, by a programmer who would call me a luddite.

Once, we replaced a pointless stl::map useage with a simple 2D array look up and test for null, and got a key routine to five assembler instructions instead of the (quite literally) several pages worth the stl version generated.

[Applewood]

I mean where does it end?

From my perspective, it's that I never let it start. KISS.

Write games. Ship games. Dont write pointless bullshit code libraries

Yeah, and don't depend on any already existing ones either.

[Adrian Lopez]

Back on topic:

In C++, if you want to do auto garbage collection-- to stop using the "delete" keyword at all... what do you do?

A C++ smart pointer uses its constructor, copy constructor, assignment operator and destructor to keep track of the pointee's lifetime. A reference-counting smart pointer, for example, keeps track of the pointee's lifetime by incrementing the smart pointer's reference count whenever a copy of the smart pointer is created (the reference count being shared by all such copies), and by decrementing the reference count whenever a copy of the smart pointer is destroyed. Should the reference count be 0 when the smart pointer is destroyed, the smart pointer would then call delete on the pointee and also delete the object containing the shared reference count.

[Bad Sector]

Really, what the hell is the point in an indie reimplementing STL? For what specific purpose do you feel the need to do that?

You don't reimplement STL, you only implement (without the "re" part :-P) the very specific functionality you need at the time in a straightforward manner.

[zoombapup]

I've seen multiple cases of people implementing the exact same functionality that STL has. In many cases actually implementing the STL interfaces.

When I say reimplementing, I mean literally that.

[chanon]

To answer Raptisoft,

For smart pointers look up boost::shared_ptr. Probably easiest to use. You can use it with boost::weak_ptr to avoid circular reference leaks.

I myself use boost::intrusive_ptr in our C++ code since it (theoretically at least) gives better performance. (And I use normal pointers for the 'weak' pointers.) Make a base 'Object' class for your framework and then you can easily have all your game objects handled by smart pointers.

Boost smart pointers are only header files, so they don't cause any problems for compiling. Works on every platform I've tried building C++ on (including iOS).

For the second question about using += and -= to add/remove from a list, you'd need to overload the += and -= operators for the list class. I don't think overloading operators like this is a good idea though, since it may make the code harder to understand for others.

[vjvj]

If I were desktop PC/Mac-focused, I would do what chanon suggested and find some combo of either shared_ptr/weak_ptr or intrusive_ptr/naked pointer. I don't think the specifics really matter so much as long as you establish clear ownership for each object; the "owner" gets the shared/intrusive pointer, while non-owners get weak/naked pointers. I personally would avoid having shared_ptrs everywhere and letting things magically delete themselves behind the scenes... But that's just me.

All that said, I'm also in the console-centric group and prefer to avoid introducing performance variables. With that in mind, I switched over to a handle system and don't have plans of going back anytime soon. Aside from being drop-dead simple to implement (and basically doing everything smart pointers do), handles also offer additional benefits such as inherent support for memory relocation. Our handle system is based on the approaches presented in these books:

Game Engine Architecture (Jason Gregory)

C++ for Game Programmers (Noel Llopis)

If you really want to completely avoid memory management altogether, I say forget smart pointers and just switch to Java or some other managed language

[Raptisoft]

Well, not exactly the news I'd hoped for. I was hoping there was some transparent way to implement it. I suppose I'll just have to write some sort of define for delete that can be turned blank.

[Applewood]

Nope, there really is a large body of people out there who feel that "int" is dangerous and "void*" introduces 10 bugs a day and really really complex template code is safe and adds no bugs at all.

(But from my experience on gd.net (and here to a 1% strength) don't be the guy advocating binning alll the complex shit as you'll get flamed to death. Even as you slip yet another product out the door whilst the purists argue over how shit you must be)

[Raptisoft]

Well-- what my main goal in doing this was to write C++ code that could be easily moved to C# and flash (using a core set of custom functions from my own library).

The main issue is that I want to write in C++... and have the code behave the same way in .net and flash.

I often do some work in my destructors-- for instance, in the destructor of a skeleton character, I would decrement the global count of skeletons currently live.

I was going to get past this by scrapping constructors, and having a Destroy() function in all my objects. Then I'd just make a simple delete macro that in C++ would be {x->Destroy();delete x;} and in C#/Flash would just be {x->Destroy();}

Where I start to run into trouble would be with this:

int *aX=new int;
MyDelete(aX);    // Hey!  Int doesn't define Destroy()!  Error!

or

struct JustSomeJunk
{
     int mNumberOfChicksKissed;
     bool mEnjoyedIt;

     Destroy() {} // Waaah!  I don't want to include a blank Destroy function!
}

One solution I could do would be to have two delete calls-- one for things that have a Destroy, and one for things that don't, but... yeeeeccchhhh.

This whole thing is precipitated by my recent annoying discovery that to be an Indie on XBox, thou shalt not use C++, thou shalt only use C#.

[voodooshaman]

If you MUST be arsy about it, at least think of using EASTL before you go doing your own. I understand that you think you have a bigger pair of balls if you can code your own version, but honest how productive is it?

The only reason I could think of re-implementing STL is to implement something like EASTL. Up until I read your post I wasn't aware of any widely-available STL implementation that was fixed-storage and didn't use the heap (so thanks for that!).

[Mattias Gustavsson]

Nope, there really is a large body of people out there who feel that "int" is dangerous and "void*" introduces 10 bugs a day and really really complex template code is safe and adds no bugs at all.

(But from my experience on gd.net (and here to a 1% strength) don't be the guy advocating binning alll the complex shit as you'll get flamed to death. Even as you slip yet another product out the door whilst the purists argue over how shit you must be)

Yeah, that's my experience as well. And personally, I've found that the longer I do this whole coding thing, the simpler my code is getting. Nowadays, I use a mostly C style approach, with most of the data stored in C-style global arrays. It works surprisingly well, and I don't miss templates, design patterns or object oriented stuff - I just write my code and get things done

[vjvj]

The main issue is that I want to write in C++... and have the code behave the same way in .net and flash.

Why not use something like managed C++ then? I admit that I've never used it though, so this may be an absurd suggestion...

... and "void*" introduces 10 bugs a day and really really complex template code is safe and adds no bugs at all.

LOL, it's funny you say this because we have void handles in our handle system It's all about balancing the right tools for the job.