Messages

76

General / Re: What about memory leaks?

« on: June 06, 2015, 06:19:28 pm »

Fully agreed, SpeCter.

I suspect some coders might be against it, solely because, in general, storing a raw pointer to another unique pointer creates a possible dangling pointer scenario.  Whereas it wouldn't if you used shared pointers. 

But yeah, there's no more "dangle danger" with the unique_ptr implementation than a pure raw pointer implementation.  And of course, part of the problem description is that these pointers would never go out of scope until game shutdown.

77

General / Re: What about memory leaks?

« on: June 06, 2015, 06:00:42 pm »

You could store an unique_ptr inside your map and return your raw pointer to whatever needs it.

That makes sense to me. 
I expected there would be more resistance to storing a secondary raw pointer to a unique pointer (edit - sounds like Jesper would be against this approach).  It's not really "unique" then.  But agree in this case it would work.

RAII to the rescue

I'm not totally sure how much in need of rescuing the pure raw pointer case needs.     You're basically trading a single destructor loop, for some more complicated pointer syntax.  But I appreciate your thoughts!  The unique_ptr implementation is completely reasonable to me.

78

General / Re: What about memory leaks?

« on: June 06, 2015, 05:21:17 pm »

Appreciate the post, SpeCter.

Most STL implementations are not very resource friendly and their memory allocation might not be a good fit for what you do.

Don't custom memory allocators get you around this problem?

I'm not saying you shouldn't use STL containers , to be honest I like them.
I'm also not saying you shouldn't use raw pointers(or that it's wrong), what I'm saying is that you make your life unnecessarily hard if you don't use the tools laid out before you.

That's a good argument.

There is no technical reason not to use unique_ptr.

As we discussed earlier, a technical case can be made for not using shared_ptr.  But I agree with you on unique_ptr.  I confess it didn't really occur to me to use the one (unique), but not the other (shared). 

That would give you no problems, performance wise.  Stylistically though, it might.  Now you've got a mixture of some pointers which are managed for you (unique_ptr), and some which are not (raw, for anything not suited to a unique_ptr). 

Actually, while I've got a forum filled with smart pointer folks, let me ask a question:

Let's say you've got some class like this:

// "skills" as in RPG-style skills, perhaps combat moves, or other abilities like crafting.
class SkillDirectory
{
public:
   // ... constructors, etc...
   const Skill* LookupSkill(const std::string& i_skillName) const;

private:
   // maps a skill name to a skill class.
   std::map<std::string, Skill*> m_mapSkill;
};
 

The SkillDirectory owns the Skill* memory.  However, it serves out pointers to this memory to other gamesystem code that uses it.  The list of available skills in the game will never change at runtime.  So it is possible for other classes to safely store a pointer to one for the duration of the game. 

So let's say that other classes in the game (perhaps some Entity component relating to known skills) will also want to hold Skill* pointers, rather than skill names or IDs which force a lookup every time you need to access the skill.  Maybe this is done for convenience or performance reasons.

Is there any way to avoid getting around the use of shared_ptr in this scenario?  (Provided you don't want to use raw pointers).

79

General / Re: What about memory leaks?

« on: June 06, 2015, 01:28:03 am »

I think that pretty much fits what I said

Not even remotely.

It's not an ego thing.  I don't think I'm "better than that" or "too good" to use smart pointers.  If you're interested in what I'm actually saying, just go back and read my posts a little more closely.

On a more meta-level, it's natural for coders to have strong opinions about what works best.  But I think a mistake many more "fanatical" coders make is the "my way is the best and only way" standpoint.

Let me give an example.  Here's a great video worth watching for anyone who programs games:



Now, there's some things I find brilliant about Mike's approach to coding games.  And other things I find insane.  You think it's crazy not to use smart pointers?  Mike's general policy on using any STL containers is "no".  (That's insane to me.)

But you know what?

What he's doing is working.  He finishes games.  They're stable.  They're polished.  They're fast.  They're successful.  Would I like to code in that environment?  No.  Do I personally agree with all his code policies?  No.  But I'm not going to say he's doing it wrong, just because he doesn't do things the same way I do. 

80

General / Re: What about memory leaks?

« on: June 05, 2015, 11:07:26 pm »

not using something which is meant to help you write better and safer code and saying you are better than that

re:  the bolded
Where did I say that?

81

General / Re: What about memory leaks?

« on: June 05, 2015, 09:47:25 pm »

(previous post deleted, thanks SpeCter!)

That exact same argument is used by people who think they don't make mistakes. This is like saying you don't need a safety belt because you can drive better without it.

Good point. 
But I think there's cases where using a "safety net" is good (e.g. seatbelt).  And cases where it's optional (e.g. memory garbage collection).  After all, if absolute safety was the sole and primary concern, shouldn't we all be using garbage collection?  It's still possible to write bad code with std::unique_ptr (e.g. by improperly storing the raw pointer returned from std::unique_ptr::get). 

There's always ways to hang yourself.  All I'm arguing is the choice of rope should be an individual decision by the programmer.  I almost always disagree with anyone who argues for a universal "right way" of doing things.

What exactly do you think "better" code is?

I actually find this a very interesting question. 

There's a lot of ways you could answer this.  But part of the answer, to me, is the clean expression in code of an elegant mental design.  A huge part of coding isn't the actual typing (of course!), but rather the process the coder must use to translate the mental design into code.

Everyone is going to do this a little differently.  We're all different people.  Coding is as much an art as it is a trade.  For me personally, a key part of that translation to code is to explicitly think about (and write!) the allocation and deallocation of memory. 

Using unique_ptr for single ownership makes your code more clear and you really have to think about what you do, not playing make believe.
Shared_ptr may have a big overhead in comparison but in reality you most often don't even need shared ownership.

In a sense we're agreeing here, on the importance of thinking about ownership.  Just disagreeing on the best way to do it.  Maybe you're right and unique_ptr is simply superior.  Or maybe I'm right, and the answer is relative to the coder - that they should use whatever method most works with their unique thought process behind coding.

82

General / Re: What about memory leaks?

« on: June 05, 2015, 09:23:56 pm »

A failed allocation is going to throw. The program don't care if you use error code, it's still going to throw if it fails. And you are supposed to be handling that case.

I do:

If something fundamental is malfunctioning like memory allocation, there's no point continuing on.  Having a bottom level try-catch block to log the error then abort is fine. 

(See my previous post for the full context of that quote.)

I know std::shared_ptr add overhead. I made a case of std::unique_ptr. But the trouble it removes from managing correctly my pointers is far better than the overhead it adds.

I get that.  If these are the tools you use to write your best code, great!  The way my brain works, I believe I write better code by manually handling my allocations and deletions. 

If C++12 came out and said, "we have a 100% perfect, 100% efficient garbage collector", I wouldn't use it.  Handling memory manually and explicitly is one of my primary reasons for sticking with C++ over C#, or other garbage collection languages.

Personnaly, I'd rather spend more time on my algorithm, the game play, the real issues

That exact same argument is used by people who advocate game engines like Unity over SFML.  I'm not saying it's wrong.  But I disagree it is universally the correct decision, either.

83

General / Re: What about memory leaks?

« on: June 05, 2015, 08:56:23 pm »

std::unique_ptr add exactly zero overhead. None.

True, but std::unique_ptr only covers one use-case of pointers.  std::shared_ptr does have non-trivial overhead.  If you fully embrace smart pointers, solely using std::unique_ptr ain't gonna cut it.

Here's a small example:

Since C++ is an exception language, you have a potential memory leak with this code:

int* p1 = new int(5);
int* p2 = new int(8);

delete p2;
delete p1;

I understand this is only meant to illustrate a point.  But it's a horribly contrived example.  What the hell are you doing newing ints here?  Any sane programmer who only wanted his objects to live for the length of a particular scope would not use the heap.  You'll have to do better than that to convince me.

Also, for what it's worth, I don't use any exceptions in my own code.  I dislike the non-linear nature of exception handling.  I return error codes from functions that require error handling.  The only place I write try/catch blocks is when an external lib forces them on me.

Whether to use exceptions is a whole different argument.  Of course it very much depends on how resilient you need to be for unexpected scenarios, like running out of memory, or bad file access.  For things like a video game, there's no reasonable way to handle scenarios like this.  If something fundamental is malfunctioning like memory allocation, there's no point continuing on.  Having a bottom level try-catch block to log the error then abort is fine. 

Sprinkling exceptions throughout your code which cause you to jump to a whole different frame in the call stack (the exception handler) will in most cases make your game either buggy or unplayable.  So I find spending excessive amounts of time writing exception handling routines to be a waste of time.  Better to focus on ensuring you can find out about the error and correct the code, and/or advise the user as to why the game is unplayable on her system.  You're not doing anybody any favors allowing your program to limp onwards in a malfunctioning state.  And doing so may have even worse consequences, like corrupting save files.

84

General / Re: AW: What about memory leaks?

« on: June 05, 2015, 07:03:00 pm »

At best you learn about RAII and smart pointers and stop worrying about memory leaks.

I've noticed a few SFML team members are huge advocates of smart pointers.  Enough so, that I've spent some time reevaluating my own decision to avoid their use in my current game project.  I wondered if maybe I was just entrenched in my ways, and resisting change for no good reason.  "I've always done it this way (raw pointers), and it works" kind of thing.  I even did some research on the performance of raw pointers over smart pointers, hoping to find some smoking gun which would justify my use of raw pointers, but that didn't stick.  There is some small performance gain, but certainly not enough to justify ignoring smart pointers altogether.

Here's what I've finally come up with.  Using raw pointers is certainly more dangerous.  But I find that danger forces me to think more carefully about memory management and ownership in my code.  I can feel some eyes rolling as I type that.  But here's an analogy which maybe you can get behind.  A big reason I choose something like SFML over Unity is that I am forced down an inefficient and more "dangerous" route in creating my game.  I'm working closer to the metal.  I'm intentionally taking the harder path in order to shape my code, and my game in a precise fashion. 

Let's say you wanted a model ship.  You could either build it yourself, at a ridiculous cost-benefit ratio, or buy one for cheap.  But there is value in the building of it, even if it crashes (heh) down on you 10 times before you get it right.  Once you do get it right, it is a thing of beauty; you know every timber, every nail, every knot of that model ship.

That's how I feel about using raw pointers.  I have the "luxury" of being the only coder on my project, so it's less likely some noob junior programmer is going to walk in and trash the place.  Because of reasons like that, I would never argue against using smart pointers.  It certainly makes your code more robust to bad programming habits and errors.  But I think there is a case to be made for avoiding them, too.  It's not like before the advent of c++11, boost, and smart pointers all software was buggy crap.  It just took a little more finesse and expertise to make it work.

I may change my tune on this in the future.  But I figured I'd share my thoughts on smart pointers as of today.

85

Window / Re: Problem with joystick axes

« on: June 03, 2015, 10:18:46 am »

There should only ever be deadzone in the center of the joystick.  Not at the far edges.  I think you likely have a broken joystick. 

86

General discussions / Re: Incredible performace of Lua (luajit) over C++

« on: May 26, 2015, 07:30:48 pm »

Weird.
Are you running the C++ version from VisualStudio (or CodeBlocks it looks like)?  Even in release, that can be significantly slower.  If so, try running by double-clicking the executable instead.

87

Window / Re: Problem with joystick axes

« on: May 26, 2015, 12:17:30 am »

The options seem to be:

• linux (driver) problem
• broken joystick
• problem in SFML

If you run windows, you could try reading the joystick axis under windows, using the same SFML program.  If it works under windows, then you know it's a linux-specific problem.  If it doesn't work under windows, then it's either a broken joystick, or general SFML problem. 

88

SFML projects / Re: Zloxx II - An action Jump'n'Run

« on: May 25, 2015, 07:55:04 pm »

I just had a quick go at Zloxx II - no issues to report.  (windows)
It seems quite polished and fun.  Nice work, Nexus!

Controls felt good.  I kinda got stuck at the first disappearing blocks section in 1-2, because I didn't realize you could change direction in the air.     But then again, I am far from a expert platformer. 

Music is great.  Sound effects are good for what's there, but maybe could use a few more, say for landing, hitting walls, or killing an enemy.

Thanks for sharing.

89

Graphics / Re: cannon and bullet

« on: May 23, 2015, 04:42:09 pm »

I've used singletons in several large production projects, and never run into a single problem with them.  Like any other code construct, it has to be properly designed, and properly used.  There are bad ways to use singletons.  There are also good ways.

The singleton class I use only has a static pointer to the singleton instance.  That pointer is allocated, assigned, and deleted in very precise fashion, on very precise lines of code.  There is no problem with the order of creation and destruction as has been discussed here.  This is a common singleton arrangement.

About the the criticism of global data.  In practice, this is an inconsequential critique.  Singletons should only be used for objects which exist for the lifetime of a game, from initialization to shutdown.  Whether that object lives in the stack, or is global has almost no practical consequence. 

Yes, a singleton can be accessed from anywhere, given you include the header and access functionality via the provided API.  This is exactly the convenience that Singletons provide.  If you used a non-singleton, this does not change where or when you will need to use that class' functionality.  Essentially, you end up doing the exact same thing, except the code to access that class might look a little different, and is often more cumbersome, and may require more layers of indirection.

I agree that, as much as possible, you should attempt to reduce coupling between systems.  But again, in practice, the systems in all but the simplest games will be interrelated to a large degree.  It is practically impossible to write code where your low level systems (graphics, sound, physics, etc) and higher-level gamesystems are not tightly coupled.  Most attempts to do so result in overly-complicated event-driven systems which don't change the interrelation, but just complicate it to the point that debugging and engineering is far more difficult. 

Most practical applications of threading I've seen in games involve easily split, repetitive tasks (e.g. processing updates on particle systems, or processing pathing data).  Using singletons does not make this any easier or any harder. 

Singletons are fine.  Just use a proper singleton class, and understand how and when to use them.

90

SFML projects / Re: Kronos - Action, RPG, Roguelike

« on: May 23, 2015, 03:58:35 pm »

Congrats!  That's quite an achievement - RPGs are lots of work.