2,491 reputation
2919
bio website arcsynthesis.org/gltut
location Los Angeles, CA
age 37
visits member for 3 years
seen Aug 23 '13 at 12:49

I am a game developer with a fairly broad knowledgebase in the fields of animation and graphics, with a touch of AI.

Projects:


Feb
6
comment Is C++11 Uniform Initialization a replacement for the old style syntax?
This might be a subject better discussed on Programmers.se. It seems to lean towards the Good Subjective side.
Feb
5
comment std::shared_ptr as a last resort?
let us continue this discussion in chat
Feb
4
comment Is there any reason why most programming languages don't have '!>' (not greater than) and '!<' (not less than) operators?
@hammar: True, but that's true of all arithmetic relations around NaNs. All of them stop behaving normally.
Feb
4
comment std::shared_ptr as a last resort?
I don't understand what you're talking about. The entity is "the class". Each entity is an object. How these are stored in some entity manager changes nothing about how they talk to and reference each other.
Feb
4
comment std::shared_ptr as a last resort?
Here's a very simple example. You have a game entity, which is an object. It needs to refer to another object, which is a target entity it needs to talk to. However, targets can change. Targets can die at various points. And the entity needs to be able to handle these circumstances. Your rigid no-pointers approach can't handle even something as simple as changing targets, let alone the target dying.
Feb
4
awarded  Critic
Feb
4
comment std::shared_ptr as a last resort?
"Passing ownership from factory to user code should be avoided." And what happens when that isn't possible? "Use of references instead of pointers or shared_ptrs." Um, no. Pointers can be reseated. References cannot. This forces construction-time restrictions on what is stored in a class. That's not practical for a lot of things. Your solution seems to be very rigid and inflexible to the needs of a more fluid interface and use pattern.
Feb
4
answered std::shared_ptr as a last resort?
Feb
4
comment std::shared_ptr as a last resort?
@BenVoigt: And what if it is simply returning a pointer rather than creating it? Furthermore, what if the guy getting that unique_ptr actually wanted a shared_ptr, because he needs to share ownership with others?
Feb
4
comment std::shared_ptr as a last resort?
@BenVoigt: I'm not talking about passing temporary pointer as a parameter during a function call. I'm talking about an object needing to store an object either temporarily or permanently (in a game scenario, imagine an AI that needs to retain a targeted entity over a period of time). Or a pointer returned from a function. There's no way to guarantee anything about either of those cases without some kind of managed structure like shared_ptr.
Feb
4
comment std::shared_ptr as a last resort?
This question would be better over on Programmers.se. It's more of the "good subjective" kind of thing, since there's no correct answer.
Feb
4
comment std::shared_ptr as a last resort?
@BenVoigt: Of course, the difficulty with passing around naked pointers is that you don't know the lifetime of objects. If some object holds onto a naked pointer and that object dies... oops. That's exactly the kind of thing shared_ptr and weak_ptr were designed to avoid. Bjarne tries to live in a world were everything has a nice, explicit lifetime, and everything's built around that. And if you can build that world, great. But that's not how it is in the real world. Objects need to ensure that the object lives through that object's life. Only shared_ptr can do that.
Feb
4
comment std::shared_ptr as a last resort?
Have you considered listening less to the advice presented and more to the argument behind that advice? He explains pretty well the kind of system in which this sort of advice would work.
Dec
28
comment Two HTML elements with same id attribute: How bad is it really?
@Andrea: The internet would not have grown as we know it. It would have grown more slowly. But it would also have had a more solid basis of what is and is not correct code. Fast-but-sloppy may work, but I much prefer slower-but-correct. Especially since it's not like we'd only be talking about a couple of years of growth or so.
Dec
21
comment Why is C++ known as 'premature optimizaton'?
[citation needed]
Dec
5
awarded  Nice Answer
Dec
5
answered Is `catch(…) { throw; }` a bad practice?
Sep
13
awarded  Nice Answer
Sep
12
answered Strictness in programming methods among Stack Overflow users
Sep
12
comment Why C++ cannot adopt D's approach for its concept implementation?
I agree with iammilind: it should be moved to Programmers. Though it would be nice if there was a bit less random boldface text needlessly emphasizing words that we don't need to have emphasized.