Jump to content

  • Log In with Google      Sign In   
  • Create Account

Pink Horror

Member Since 02 Jul 2013
Offline Last Active Aug 14 2016 02:31 PM

Posts I've Made

In Topic: Overall Strategy For Move-Semantics? [C++11]

27 July 2016 - 08:35 PM

 

Are people really in the habit of moving every single time they don't need a variable anymore? Unless you're in the habit of doing that, option 4 is totally opaque and you wouldn't know to take advantage of it without reading the implementation. I think that's kind of in line with what Kylotan was saying.


For me, using move semantics in the context of this is somewhat equivalent to using reserve on a collection class like vector. I just get some efficiency for a little bit of additional thinking/design overhead. So yes, whenever possible (in places where it can matter) I tend to move expensive temporaries (like string, vector, ...). However this mostly means that I adjusted my design. IE, where you would usually see something like this:
Foo foo;std::string& string = foo.GetString();string = "Test";string.append("whatever");
Or something along those lines, I would instead do:
std::string string = "Test";string.append("whatever");Foo foo(std::move(string));
I find the latter much cleaner, especially in non-fabriacted examples :D Obviously you could have done this before without the move-semantics, but it would have most likely invoked a copy operation for the content of the string.

EDIT: i think i misread your question. Anybody who is actively using C++11 surely has at least a basic understanding of how and when to use move-semantics. Anyone else wouldn't have that knowledge, so its probably a matter of who you target.

 

I know this isn't important to the example, but I feel obligated to point out that a 12-character string isn't really a compelling use of std::move, considering the popularity of small string optimization.


In Topic: Recent Graduate Looking For Advice

27 July 2016 - 08:04 PM

 

I guess an objective statement can work there, but is just saying "Seeking junior game programming role" enough?. Shouldn't it also address the position I am applying for though as well?

 

That is the role.  

 

You are not going to get an entry level job as a designer.  Game designer is a senior role, it is a person who is figuring out the core of a multi-million dollar project. You don't give multi-million dollar projects to entry level workers.

 

There were intern game designers at one company I used to work for. There's a lot of little stuff to design that the senior people don't want to have to do.


In Topic: Finding that balance between optimization and legibility.

19 July 2016 - 07:17 PM

 

Except when the calculations actually outweight the cost of a mispredicted branch... right? I'm not sure on the details, but shouldn't this misprediction cost be something like ~100 cycles on modern desktop CPUs? So if you can skip calculations that take significantly longer than that, a branch is the better choice.

 

Also on desktop, branches that are easy to predict have very little cost. Like something that checks for an memory allocation error that when thrown will terminate the program, the branch will always be false anyways so the only cost should be the branching operation itself. Thats different on consoles where there is no branch prediction (I don't think the current generation added it, did they?), but I didn't program on consoles myself so far so I can't say much about it.

 

They did add branch prediction.


In Topic: Overall Strategy For Move-Semantics? [C++11]

19 July 2016 - 06:56 PM

The company I was at up to 2010 did not use C++0x features. The company I contracted for back in 2013/2014 did not use C++11 (although we did, in our code). The company I work for now, again, doesn't use C++11 (but hey, we're replacing NULL with nullptr when we come across it). This is not new or strange. Go back 10 years and lots of gamedevs were still avoiding the standard library. Go back 15 years and plenty still viewed C++ with suspicion when C worked perfectly fine. Keeping on top of compiler changes and new language features is low priority relative to (a) successfully shipping games using tech that is already well understood, and (b) keeping up with new tech that can't be safely ignored, such as rendering tech, new input hardware, new consoles, etc. Discussions of new language features have to be made in that context.

 

I wonder what percentage of new C++ games are being made with exceptions and RTTI turned off.


In Topic: Getting Objects To Not Lose Scope?

17 July 2016 - 03:08 PM

I just want to point out, if you are debugging a problem and a raw pointer is NULL, that doesn't mean the object has been destroyed or has gone out of scope. A pointer to something keeps its value until you overwrite it. It isn't going to change just because the object it's pointing to isn't valid any more. It'll keep pointing to the same memory address.

So, if you're working on a problem and you see a NULL pointer, look for places in your code that modify the pointer itself, not the value it references.


PARTNERS