Followers 0

# Portfolio Review: Programmer (all comments welcome!)

## 33 posts in this topic

Dear internet, http://www.StephenTCooney.com/portfolio/ So this is my third pass, I'm finally fleshing out my portfolio with content. I still need to throw code up there I feel worthy of showing. I am in the progress of cleaning up the code for the fat simulation system so it's pretty to look at. I take all comments, good and bad. Please, if you've taken enough time to open up the website, just drop a comment and I'd appreciate it. Thanks, Stephen Timothy Cooney
0

##### Share on other sites
Full Disclosure
I am not a hiring manager, nor do I routinely vet candidates for positions. Everything I say here is my own opinion and has nothing to do with any of my employers past, present, or future. Also, if you misuse anything I say, I will kick a penguin.

I'm gonna be brutal. Get your flame-resistant gear on. This isn't intended to tear apart all your work; think of it more like tough love. But it'll probably sting [smile]

First impressions
• Web site design is decent, but the backdrop is a bit overwhelming. Maybe I'm just channeling a graphic artist here, but IMO there's room for improvement. But that's not too terribly important; you're not advertising your web design skills [wink]

• One of the first things I saw was the phrase "code and stuff!" - this strikes me as a little too casual. I'd suggest staying fairly formal in your portfolio work, much as you would in a resume/CV. I sincerely hope that nobody in a hiring position out there would dismiss you over such a tiny thing, but why give them any ammunition?

• I clicked on your Work page and was a little confused at the lack of detail. It took me a couple of minutes of poking around the site to realize that the sections can be expanded. I would suggest just keeping them expanded all the time, so nobody gets confused as to where the content is.

• What's "post-process programming"? I can think of several ways to interpret that phrase. A little more clarity there would go a long ways, I think.

• Again a few bits and pieces here and there could stand a proofreading pass and a little bit more formality. For instance, using a bulleted list on the points you've worked on would help a lot with making the page both attractive and accessible.

• Also, "I cover pretty much every base(codewise) in our production to create a game we know players will love." This sentence is just kind of unpleasantly sticky and has a faint aroma of rotting fruits. Be clear and specific about what exactly "every base codewise" really means. From one game to another there can be massive differences in what you actually work on.

• "Also, make sure to look at my 'work' page too!" If anyone is scouring your portfolio, they're probably going to click on every link they find that seems relevant. I don't see the purpose of corny little reminders like this.

• While I'm clicking around, the division of "Work/Games/Tech" seems really arbitrary and doesn't make much sense to me. Consider reorganizing things a bit. Once again, clarity and simplicity will take you far.

Code Review
I'll keep this brief (for both my sake and yours) and to the point. I randomly picked SHRPskeleton.h/.cpp from your code sample archive, and these are my impressions.

• Your commenting style is... not good. It's a massive waste of space, for one thing; it's also prone to get out of date and become inaccurate - and nothing is more evil than inaccurate commenting. Repeating information (file names, class names) is bad. Explicitly spelling out the purpose of every file and function is redundant; you should find that only a small subset of your code actually needs to be commented, and the rest should be self-explanatory. Tracking authorship and dates is pointless, as that information can be had from your version control software (you do use version control, right?) in the form of revision histories and "blame" tools.

• In the SHRPskeleton class, you have an extraneous access control specifiers, namely the private/protected pair on lines 36-37. This indicates to me that you don't routinely recheck your code for things that can be cleaned up.

• When working with function pointers, I highly recommend you use typedefs instead of spelling out the entire function signature everywhere it is used. This makes maintaining the code much simpler.

• Why is m_Skeleton public? Why are you using an m_ wart that apparently doesn't do what most people expect it to do, i.e. signal a private/protected member? Either this is a mistake (and should have been caught by a routine code review) or it needs to be documented. Also, warts are evil.

• FooFunction(void) is not preferred C++ syntax; just use FooFunction() instead. This is a bit of a stylistic debate, but most code standards I've seen lean towards not using (void) parameter lists.

• I don't like the habit of not providing parameter names in your function prototypes. I would like to be able to pop open your header file and read the interface, and know what a given function does, just by looking at the declaration. I don't want to have to pop open the .cpp file just to figure out what arguments a function expects from me.

• References are your friends. You should prefer references over pointers in just about every case where they are used in the code currently.

• Why do you define a destructor for the class, and then leave it empty? Unless you need a virtual destructor for a base class, just leave out the destructor entirely.

• Eww, const char* parameters! Please give me a good justification for not using std::string instead.

• C-style casts (such as (int)(foo) and so on) are very, very, very bad. Use C++ casts: static_cast, dynamic_cast, reinterpret_cast, and, if you are living life on the edge and doing something which is probably unwise, const_cast.

• void pointers are evilness incarnate. Unless you have an extremely good excuse, I would say that void pointers are a strong indicator that your code architecture is broken.

• Mixing class member functions and local functions is icky. Please keep them separate, preferably containing local functions in an anonymous namespace so as to avoid linkage issues.

• "I'm so cool/I blew my brains out thinking about how this works" - just... no. Maybe you can get away with funny comments once you've been established someplace for a while and people trust you; but if you're looking to make a good, professional impression, hold back on the humor - and the hubris.

• if(!foo.size()) is potentially an expensive operation for some containers. Prefer the form if(foo.empty()) instead.

• I haven't confirmed it, but I'd suspect you have a couple memory leaks lurking in there.

If you really want I can probably find more stuff to complain about, but that should at least get you going [smile]
0

##### Share on other sites
I won't comment on the content, as I couldn't even be the judge of that. My experience does not lie within that area of expertise so anything I'd have to say would be irrelevant.

However, here are my 2 cents on presentation:
A lot of people will tell you to go straight-to-the-point, and you seem to do a good job at that. Everything seems in order for relatively quick to grab information, but there is clearly a lack of polish. Truth is, you're not mostly attempting to boast artistic skills here from what I understand, but it is my opinion that a bit of fleshing it up would add to the lot. As I've said, a lot of people want straight to the point with as little visual obstruction as possible. They consider it noise. But if you can expand on the visual without adding noise, then you're displaying personality, and to be bluntly honest, it is solely with personality that I got my first opportunity in the bizz. My cover letter was a disastrous poem but it turned out to bring out curiosity. I'll admit that was a LOT of noise, and a big risk to take, but there is such a thing as a middle ground.

If you can polish things up visually without altering the core, then I'd say that'd be a good improvement.

Then again, just my 2 cents.
0

##### Share on other sites
Ahhhh a lot of those comments I totally agree with.

Thank-you, I really forgot to take those links down. They are very old cold. Also, those commenting styles were required for grading, and I DO agree with you.

If you don't know what post-process programming in relation to graphics is then you don't know what it is. That's your own problem. It's like asking a network programmer what a packet is.

Quote:
 I clicked on your Work page and was a little confused at the lack of detail. It took me a couple of minutes of poking around the site to realize that the sections can be expanded. I would suggest just keeping them expanded all the time, so nobody gets confused as to where the content is.

Right, I've heard this before, except that's how I had it and all everyone complained about was there being too much stuff on the page.

Quote:
 What's "post-process programming"? I can think of several ways to interpret that phrase. A little more clarity there would go a long ways, I think.

Oops, I'll add the graphics tag after it.

Quote:
 Also, "I cover pretty much every base(codewise) in our production to create a game we know players will love." This sentence is just kind of unpleasantly sticky and has a faint aroma of rotting fruits. Be clear and specific about what exactly "every base codewise" really means. From one game to another there can be massive differences in what you actually work on.

*laughs* Indeed, it's PRish stuff. I'll make it a little more straight-forward. I literally mean everything, except for the core engine, which is of course Unity. If that sounds funny I'll clean it up.

Quote:
 Your commenting style is... not good. It's a massive waste of space, for one thing; it's also prone to get out of date and become inaccurate - and nothing is more evil than inaccurate commenting. Repeating information (file names, class names) is bad. Explicitly spelling out the purpose of every file and function is redundant; you should find that only a small subset of your code actually needs to be commented, and the rest should be self-explanatory. Tracking authorship and dates is pointless, as that information can be had from your version control software (you do use version control, right?) in the form of revision histories and "blame" tools.

One: Oops! You're talking about old code that I really need to take out!
Two: I agree but it was assignment requirements, they LOVED overcommenting.

Quote:
 In the SHRPskeleton class, you have an extraneous access control specifiers, namely the private/protected pair on lines 36-37. This indicates to me that you don't routinely recheck your code for things that can be cleaned up.

Old code, hate it myself. Taking it out.

Skipping down towards when your comments apply to new code or something in general.

Quote:
 Eww, const char* parameters! Please give me a good justification for not using std::string instead.

I do use standard libraries quite often, but only when I'm lazy and am just trying to prove a concept. The standard library is slow and chokes to death when compiled under debug. It's also not great when porting to different devices.

Quote:
 C-style casts (such as (int)(foo) and so on) are very, very, very bad. Use C++ casts: static_cast, dynamic_cast, reinterpret_cast, and, if you are living life on the edge and doing something which is probably unwise, const_cast.

Same kind of problem with the above. Yes it works and yes it's somewhat safe to do what you say. This is a matter of opinion.

Quote:
 void pointers are evilness incarnate. Unless you have an extremely good excuse, I would say that void pointers are a strong indicator that your code architecture is broken.

Oh yeah void * are totally evil. I mean, let's not mention that the standard libraries use them all the time.

I do however agree with the sentiments in most of your comments.

From here, I'm taking out those older chunks of code as I copied part of this from my old site. I am in the process of updating my current code sample and will repost when I've updated my site including that. It shouldn't take me too long.
0

##### Share on other sites
Oh a quick note while I'm updating this:

If you go to the tech python peer to peer sample, that's a little closer to the style of my code now. However, It is in python and not C++, which is what I'm uploading now.
0

##### Share on other sites
Quote:
 Original post by StephenTCIf you don't know what post-process programming in relation to graphics is then you don't know what it is. That's your own problem. It's like asking a network programmer what a packet is.

I know what you were referring to, because I could infer it from the contents of the rest of your site. I'm not the one to worry about - you need to worry about the HR guys who aren't tech-savvy who have to vet your application. You need to worry about keeping your best skills in the spotlight, in this case, your graphics programming. You need to worry about showing that you are capable of communicating clearly and succinctly to people outside your domain of expertise. These are important qualities for an employee; technical skills aren't everything.

Also, keep in mind that using that tone during an interview is likely going to bite you [smile]

Quote:
 Right, I've heard this before, except that's how I had it and all everyone complained about was there being too much stuff on the page.

Quote:
 *laughs* Indeed, it's PRish stuff. I'll make it a little more straight-forward. I literally mean everything, except for the core engine, which is of course Unity. If that sounds funny I'll clean it up.

List bullet points. People reading up on your skills love bullet points. Like I said before, "everything" can mean many different things depending on the type of game you're writing. Doing "everything" on a turn-based, hex-grid strategy game is a world apart from doing "everything" on a flight simulator with AI pilots. You need to be clear about what "everything" means to people who are not familiar with your project. More importantly, you need to be clear about what "everything" means to people who don't care about your project.

Quote:
 Old code, hate it myself. Taking it out.

Call me paranoid, but it's a major red flag to me that you've submitted a portfolio for critical review without first checking that you are happy with its contents. I certainly hope you don't have a similar habit for submitting code.

Quote:
 I do use standard libraries quite often, but only when I'm lazy and am just trying to prove a concept. The standard library is slow and chokes to death when compiled under debug. It's also not great when porting to different devices.

This attitude right here makes you an instant no-hire in my book.

The SC++L is there to make it easier to write safe, robust code. It's not merely a toy system that you can use for prototyping; it's a core feature of the C++ language itself. If you profess to having C++ skills, you had better know the standard library - and when I say you need to know it, I mean you need to really understand when and how to use the standard constructs.

We use SC++L code extensively in our projects, not because we are "lazy" or "just trying to prove a concept" - but because we know that using well-tested, standardized code is much safer than reinventing wheels all over the place.

As for your assertions about speed and debug builds... you'll have to cite some very convincing evidence to sway anyone on that topic. Suffice it to say that we've done heavy profiling and found the standard library to be a minimal overhead in a nontrivial game implementation. Yes, there are specific areas where it's best to use something lower-level, but those are very much the exception and not the norm.

Porting to "other" platforms is a specious argument at best. "Other" platforms are liable to have their own standard libraries, which can supplant the SC++L in many cases. The idea of utilizing any available code remains the same, even if you're talking about different libraries.

Quote:
 Same kind of problem with the above. Yes it works and yes it's somewhat safe to do what you say. This is a matter of opinion.

No, it has nothing to do with opinion.

struct Foo { int xorph; };struct Bar { float quux; };Foo* pfoo = new Foo;Bar* pbar = (Bar*)(pfoo);

Uh oh! We just did a very naughty cast using the C-style syntax.

Now if we replace the final line with Bar* pbar = static_cast<Bar*>(pfoo); we instantly trip a compiler error, noting that the two types are unrelated. We can use reinterpret_cast if we truly know that we want to do that conversion, but you risk wandering into the land of undefined behaviour. The C++ casts were specifically introduced to make casting safer and more robust; they are not "somewhat" safe - they are properly and completely safe, when used as directed by your favourite medical professional.

This wouldn't quite rate an instant no-hire from me, but it'd definitely be a major strike against you.

Quote:
 Oh yeah void * are totally evil. I mean, let's not mention that the standard libraries use them all the time.

Using void* internally, behind a robust, well-tested, and safe interface, is completely different from using void* all over your public interfaces. There are ways you could accomplish what you are doing much more neatly and powerfully than with void*s all over the place.

Anyways... not trying to be too harsh on you here or anything, but you did ask for criticism [wink]
0

##### Share on other sites
I don't want to start an opinionated argument, but given we've(Tripwire Interactive) just hired a graphics programmer, I feel I must chime in to not steer this guy in the wrong direction.

As a graphics programmer, it is absolutely essential to be able to write the fastest code possible. When we're looking at a graphics programmer candidate, we are generally opposed to them using STL strings and vectors in their work, but other container constructs, such stacks, queues, deques are acceptable. The reasoning is simple, a graphics programmer *must* be able to handle the data themselves, as efficiently as possible, and automatic-allocation constructs such as strings and vectors are simply inefficient(and we would, in fact, call a graphics programmer that uses either of these constructs lazy). Also, when an engine is intended to be used by clients outside of the office, it's also imperative to write code that can easily be debugged, which the STL makes very difficult. In that light, we prefer that a graphics/engine level programmer simply doesn't even use the STL, but if they do happen to use the efficient container constructs, we simply inform them, upon hire, that they are not to use them in our source.

As StephenTC has agreed, there are a number of problems with his portfolio, but I do not believe using a const char* is one of them.
0

##### Share on other sites
Quote:
 Original post by XienenWhen we're looking at a graphics programmer candidate, we are generally opposed to them using STL strings and vectors in their work, but other container constructs, such stacks, queues, deques are acceptable.

Dequeue automatically allocates in a manner similar to string and vector. Additionally, stack and queue are simple adapters for dequeue, meaning they share the same allocation characteristics. I have no idea what you thought you were saying in your statement, but it's apparent that you posses no idea of that which you speak.
0

##### Share on other sites
Quote:
 Original post by XienenI don't want to start an opinionated argument, but given we've(Tripwire Interactive) just hired a graphics programmer, I feel I must chime in to not steer this guy in the wrong direction.As a graphics programmer, it is absolutely essential to be able to write the fastest code possible. When we're looking at a graphics programmer candidate, we are generally opposed to them using STL strings and vectors in their work, but other container constructs, such stacks, queues, deques are acceptable. The reasoning is simple, a graphics programmer *must* be able to handle the data themselves, as efficiently as possible, and automatic-allocation constructs such as strings and vectors are simply inefficient(and we would, in fact, call a graphics programmer that uses either of these constructs lazy). Also, when an engine is intended to be used by clients outside of the office, it's also imperative to write code that can easily be debugged, which the STL makes very difficult. In that light, we prefer that a graphics/engine level programmer simply doesn't even use the STL, but if they do happen to use the efficient container constructs, we simply inform them, upon hire, that they are not to use them in our source.As StephenTC has agreed, there are a number of problems with his portfolio, but I do not believe using a const char* is one of them.

Knowing the performance tendencies of the STL containers is paramount, and blanket statements such as "automatic-allocation constructs such as strings and vectors are simply inefficient" are bad.

Each container is efficient for the purposes it was designed for; string has a slight overhead but this is a tradeoff you may wish to make for greater security and convenience (nonetheless, its good for candidates to know how to deal with old school char *) while vectors simply wrap an old school array and have a trivial memory overhead, well worth the extra convenience, *if you are not concerned about performance in that area*.

Decisions about how to store memory and access it is always about tradeoffs; sometimes, a particular piece of code is simply not performance critical, (dont go all draconian on me and claim that all code is performance critical). Perhaps it runs once at game startup; Perhaps the difference in speed is immeasurably small.

For the sake of saving 1 millisecond of startup time you have just released a buggy game that leaks memory like a sieve. Congratulations; thats 20% less favorable critical reception.

Finish the sentence: premature optimisation __ ___ ____ __ __ ____.
0

##### Share on other sites
I think you're missing an underscore. ;)
0

##### Share on other sites
I do have to say, there is only one AAA game company that I've heard of using the STL. Every other one I've ever encountered and heard say anything on the topic says not to use them.

STLs are great for business application implementations that don't have to worry about performance.

Overuse of STL only proves to me that someone is incapable of spending 5 minutes to either handle it themselves or write an efficient class. (Which for a string takes what... 2 hours?).

Quote:
 Foo* pfoo = new Foo;Bar* pbar = (Bar*)(pfoo);Uh oh! We just did a very naughty cast using the C-style syntax.

I'm sorry, if this happens a lot with you then you're not a good coder. Plus, that's technically how polymorphism works well AND in order to use the casts you said you need run-time-type-info enabled which is SO INCREDIBLY SLOW. If you're doing rtti casts which graphics/mesh/animation data then you've destroyed it.

Good code isn't about using other people's libraries well so that you don't have to think, it's about making your own.

Quote:
 Call me paranoid, but it's a major red flag to me that you've submitted a portfolio for critical review without first checking that you are happy with its contents. I certainly hope you don't have a similar habit for submitting code.

Don't talk about my tone young man. I POSTED here for the very purpose of catching that information. I don't very well expect or hope to get a job from posting on these forums. I posted it for the very purpose of you finding it.

Quote:
 As for your assertions about speed and debug builds... you'll have to cite some very convincing evidence to sway anyone on that topic.

No, I guarantee it's just you. Compiling under debug scenarios often causes most compilers to throw inline out of the window. Noting that the STL often connects several functions together to do something basic DESTROYS performance. Say, for example you have a vector representing vertices, you are processing the vertices or particles every frame, you can imagine that taking every access on those particles out of inline would slow it down. If you're NOT getting a slowdown then what you're doing IS trivial or you don't know what debug compiling is.

Quote:
 Porting to "other" platforms is a specious argument at best. "Other" platforms are liable to have their own standard libraries, which can supplant the SC++L in many cases. The idea of utilizing any available code remains the same, even if you're talking about different libraries.

Ok, I'm sure the Nintendo DS is ALL about string stls. I'm sure they expect the programmers who work on it to be incompetent. Also, the XBOX 360: Sure you can compile the stl and get it to work on there but it's just silly noting that you're trying to squeeze performance out of it.
0

##### Share on other sites
Quote:
 Original post by XienenI don't want to start an opinionated argument, but given my company recently performed a perfectly normal business task (hiring a graphics programmer), I feel I must chime in with my opinion which contradicts the established wisdom of everyone around here who actually knows what they're talking about and which is not based in any kind of actual empirical measurement.
0

##### Share on other sites
I stand corrected. I am obviously not as familiar with the STL as I once was, I thought deques, queues, and stacks use a linked-list style architecture, not an dealloc, realloc, and copy architecture. I will have to update our policy on data management if we are looking for another graphics/engine programmer in the future. Thank you Mike.

While I understand that it is generally considered to be a minimal trade off in game development, we believe that low level data management within an engine must be tight, precise, and all data must be constantly accounted for. If there is a memory leak at such a low level in the engine, then that's a problem with the programmer(s). At such a low level, we are unwavering in our desire for the most efficient code possible(especially in memory utilization when working on consoles).

Quote:
Original post by Zahlman
Quote:
 Original post by XienenI don't want to start an opinionated argument, but given my company recently performed a perfectly normal business task (hiring a graphics programmer), I feel I must chime in with my opinion which contradicts the established wisdom of everyone around here who actually knows what they're talking about and which is not based in any kind of actual empirical measurement.

This is the kind of response that makes me wish that I just didn't say a word. I should have let you simply continue flaming people on your own forum. I'm glad our moderators have a little more respect for our community.
0

##### Share on other sites
Quote:
 Original post by XienenI stand corrected. I am obviously not as familiar with the STL as I once was, I thought deques, queues, and stacks use a linked-list style architecture, not an dealloc, realloc, and copy architecture. I will have to update our policy on data management if we are looking for another graphics/engine programmer in the future. Thank you Mike.While I understand that it is generally considered to be a minimal trade off in game development, we believe that low level data management within an engine must be tight, precise, and all data must be constantly accounted for. If there is a memory leak at such a low level in the engine, then that's a problem with the programmer(s). At such a low level, we are unwavering in our desire for the most efficient code possible(especially in memory utilization when working on consoles).

actually you are correct on the larger details; deque uses a linked list (IIRC it actually has a small array on each node) while vector block allocates.

The point of vector is that it replaces, feature for feature, the functionality of an array; you get contiguous memory which you can index as you would an array, but at the cost of slow resizing. Now, some data does not resize after initialisation, or you may wish it to expand only up to a certain point; this is where vector comes into its own with its tiny tiny overhead.

This is roughly the procedure I follow to choose a container;
If im not sure of my requirements yet, I typically use typedefs and any old container so I can defer the decision until later.
0

##### Share on other sites
Quote:
Original post by speciesUnknown
Quote:
 Original post by XienenI stand corrected. I am obviously not as familiar with the STL as I once was, I thought deques, queues, and stacks use a linked-list style architecture, not an dealloc, realloc, and copy architecture. I will have to update our policy on data management if we are looking for another graphics/engine programmer in the future. Thank you Mike.While I understand that it is generally considered to be a minimal trade off in game development, we believe that low level data management within an engine must be tight, precise, and all data must be constantly accounted for. If there is a memory leak at such a low level in the engine, then that's a problem with the programmer(s). At such a low level, we are unwavering in our desire for the most efficient code possible(especially in memory utilization when working on consoles).

actually you are correct on the larger details; deque uses a linked list (IIRC it actually has a small array on each node) while vector block allocates.

The point of vector is that it replaces, feature for feature, the functionality of an array; you get contiguous memory which you can index as you would an array, but at the cost of slow resizing. Now, some data does not resize after initialisation, or you may wish it to expand only up to a certain point; this is where vector comes into its own with its tiny tiny overhead.

This is roughly the procedure I follow to choose a container;
If im not sure of my requirements yet, I typically use typedefs and any old container so I can defer the decision until later.

Thankyou all for entirely derailing my post.
0

##### Share on other sites
Quote:
 Original post by StephenTCThankyou all for entirely derailing my post.

Heh, better hope that potential employers don't Google your name and find posts like this. Very clearly stating in the OP that you take all comments, good or bad and then becoming extremely defensive and sarcastic tells them far more than a portfolio or resume ever could.
0

##### Share on other sites
Quote:
 Original post by StephenTCI'm sorry, if this happens a lot with you then you're not a good coder. Plus, that's technically how polymorphism works well AND in order to use the casts you said you need run-time-type-info enabled which is SO INCREDIBLY SLOW. If you're doing rtti casts which graphics/mesh/animation data then you've destroyed it.

Wrong, wrong, wrong wrong wrong. RTTI is used by dynamic_cast. The static_cast and reinterpret_cast operators do not need it.

Quote:
 Original post by StephenTCGood code isn't about using other people's libraries well so that you don't have to think, it's about making your own.

Good code is about using other peoples' libraries when appropriate and writing your own when appropriate. Appropriateness being determined via design and/or empirical testing, not vague personal feelings. Telling me something like this in an interview would disqualify you.

Quote:
 Original post by StephenTCDon't talk about my tone young man. I POSTED here for the very purpose of catching that information. I don't very well expect or hope to get a job from posting on these forums. I posted it for the very purpose of you finding it.

Jesus, you came here asking for advice on your resume. He's telling you what problems he sees. If you're so much more knowledgeable, then why bother asking us for help?

Quote:
 Original post by StephenTCNo, I guarantee it's just you. Compiling under debug scenarios often causes most compilers to throw inline out of the window. Noting that the STL often connects several functions together to do something basic DESTROYS performance. Say, for example you have a vector representing vertices, you are processing the vertices or particles every frame, you can imagine that taking every access on those particles out of inline would slow it down. If you're NOT getting a slowdown then what you're doing IS trivial or you don't know what debug compiling is.

Granted, debug mode tends to remove inline (and inline is just a suggestion anyway), but is that really important in debug mode? Seriously? You are making periodic release builds, right? You also don't quantify your performance complaints, and instead hand-wavingly reference slowness.

We've had long discussions about STL performance including people much, much, much more experienced than you. Maybe you're a programming god and are doing work that's pushing the limits of your machine, but likely STL wouldn't be a bottleneck in your code (unless you're doing it wrong).

Quote:
 Original post by StephenTCOk, I'm sure the Nintendo DS is ALL about string stls. I'm sure they expect the programmers who work on it to be incompetent. Also, the XBOX 360: Sure you can compile the stl and get it to work on there but it's just silly noting that you're trying to squeeze performance out of it.

I highly doubt you've worked on either the XBox 360 nor the DS, nor profiled STL code on either of them, which makes your comments here uninformed.

Edit:
PS. Last time I applied for a game dev job, I was grilled pretty heavily on the STL, making your "Game developers don't use the STL" comment just-plain-wrong.
0

##### Share on other sites
Quote:
 I do have to say, there is only one AAA game company that I've heard of using the STL. Every other one I've ever encountered and heard say anything on the topic says not to use them.

Irrelevant, for many reasons. First, the "STL" (technically the term you want is the SC++L, and that's what I'll be using from here on out, to avoid confusion) is part of the language itself, and as such "understanding the language" perforce includes "understanding the SC++L," its standard library. That isn't to say that you cannot use the language functionally without it -- you can. But you're not using the language fully.

Second, the reasons that many studios have for avoiding the SC++L -- and there exist multiple good reasons -- are varied and likely very different from what you expect. I'll touch on this later when I address Xienen's points.

Quote:
 STLs are great for business application implementations that don't have to worry about performance.

They're also great for games. The SC++L is not slow, it is an extremely well-written, extensively-tested, vetted standard library with exceptional general purpose performance characteristics on most platforms. Yes, there are platforms where it is poorly implemented (many, especially older, consoles for example). Yes, if you know the specific domain very well you can sometimes outperform it for specific scenarios. That doesn't make a blanket statement like the one I quoted correct or reasonable.

Quote:
 I'm sorry, if this happens a lot with you then you're not a good coder. Plus, that's technically how polymorphism works well AND in order to use the casts you said you need run-time-type-info enabled which is SO INCREDIBLY SLOW. If you're doing rtti casts which graphics/mesh/animation data then you've destroyed it.

You're right; good programmers will use the tools at hand to avoid having to write such error prone code. Those tools include the SC++L. It's irrelevant that that's "how polymorphism works," (regardless of the questionable accuracy of that overly general statement), because that is handled for you automatically by the toolchain. Much like how the SC++L allows the library to automatically handle things for you. But you're not advocating for manual polymorphism are you? Finally, RTTI is not appreciably slow. It's cost is in the extra memory usage, which can translate into more subtle performance issues like cache coherency, but it's not a massive speed sink on its own. dynamic_cast, however, is slower than other casts because (as you correctly try to point out) it requires RTTI and does checks at runtime. That is the nature of the operation, however. Fortunately the need for dynamic_cast can usually be avoided with better designs.

Quote:
 Good code isn't about using other people's libraries well so that you don't have to think, it's about making your own.

That's insane. There are merits to both using existing code and libraries and rolling your own, and it's rarely so cut and dried. The capability to make the decision to buy or build is vastly more important than the ability do either. Middleware and libraries play a very important role in getting software developed on time and under budget. Discount that at your peril.

Quote:
 Don't talk about my tone young man.

Quote:
 No, I guarantee it's just you. Compiling under debug scenarios often causes most compilers to throw inline out of the window. Noting that the STL often connects several functions together to do something basic DESTROYS performance. Say, for example you have a vector representing vertices, you are processing the vertices or particles every frame, you can imagine that taking every access on those particles out of inline would slow it down. If you're NOT getting a slowdown then what you're doing IS trivial or you don't know what debug compiling is.

You made the claim, the onus is on you to provide the benchmarks that back it up. Do so, or drop this line of argument. It will only turn into a bickerfest and I will lock the thread and issue judgement on all parties concerned in that case. That goes for everybody: this subject is taboo until we get real metrics.

Quote:
 Ok, I'm sure the Nintendo DS is ALL about string stls. I'm sure they expect the programmers who work on it to be incompetent. Also, the XBOX 360: Sure you can compile the stl and get it to work on there but it's just silly noting that you're trying to squeeze performance out of it.

This is a bogus argument.

Quote:
 I stand corrected. I am obviously not as familiar with the STL as I once was, I thought deques, queues, and stacks use a linked-list style architecture, not an dealloc, realloc, and copy architecture. I will have to update our policy on data management if we are looking for another graphics/engine programmer in the future. Thank you Mike.

deque, vector and string (which is, unfortunately, technically a container) are generally the most efficient general purpose containers in the SC++L.

Quote:
 While I understand that it is generally considered to be a minimal trade off in game development, we believe that low level data management within an engine must be tight, precise, and all data must be constantly accounted for. If there is a memory leak at such a low level in the engine, then that's a problem with the programmer(s). At such a low level, we are unwavering in our desire for the most efficient code possible(especially in memory utilization when working on consoles).

And that is understandable, but blanket statements like "SC++ IS TEH EVIL" (yes, I am hyperbolizing, I know) aren't helpful to anybody.

That said, I mentioned there are reasons to avoid the SC++L, and that's true. I suspect the majority of studios avoid the SC++L due to an ingrained distrust, such as Xienan has/had, that comes about from the days when it was less viable for general purpose performance -- back in the days when compilers really, really sucked at templates, et cetera. But things have improved a lot since then. There are other reasons, more valid: most studios work off a large corpus of existing legacy code, code that was written when the SC++L wasn't a good option, or whatever. That code typically has a bunch of hand-rolled containers, etc already in place, and for that code those libraries fill the role of the SC++L. Tested, general purpose, fast. Refactoring that code to use the SC++L is probably pointless.

But when those studios go to make new projects, they use that existing code, they don't rewrite their array classes. And contrary to what StephenTC thinks, it does not take two hours to develop container/string/utility classes on par with the quality of the SC++L or those analogous internal libraries that have had man-years of maintained.

In fact, that statement is one of the most telling about your opinion on the craft, StephenTC, and one of the things I would strive to rectify the most about yourself. A good programmer, a good software developer, should seek to improve his or herself in all ways, at all times, through the pursuit of new and updated knowledge. Those are the kind of people I want to hire, not people who subscribe to zealous dogma without admitting to the possibility that things will change and there is rarely such a thing as a true blanket statement.
0

##### Share on other sites
Quote:
 Thankyou all for entirely derailing my post.

It's not your thread, it's the community's. It will go where it pleases, and it's not for you to decide if that's inappropriate, it's the job of the moderators (generally, the ones not actively participating in the thread). I feel that the topics we've branched into are reasonable and valid in a discussion about improving one's hirability/portfolio quality/general attitude towards software development.

Ultimately, however, it will be up to another moderator (probably Tom Sloper, who is in charge of this forum) whether or not this thread remains open.

[Edited by - jpetrie on January 25, 2010 6:23:27 PM]
0

##### Share on other sites
Quote:
 This is the kind of response that makes me wish that I just didn't say a word. I should have let you simply continue flaming people on your own forum. I'm glad our moderators have a little more respect for our community.

While I agree, Xienen, that the response was a little harsh, at the same time I don't think it entirely out of hand. I personally really dislike it when people post, as you did, "I don't want to [start a flame war], but... [insert inflammatory thing here]." I think that's all he's trying to comment on, albeit in a... mean sort of way.

Let's try not to let this devolve into personal attacks from here on out. This can still be a useful thread containing educational and interesting discussion if everybody tries to keep it civil.
0

##### Share on other sites
My current gig is to review code targetted at the Xbox 360 for things like security, performance and code quality. It ranges from Xbox Live Arcade titles, to Dashboard applications, to huge AAA games, both first and third-party.

Everyone I've encountered so far uses the C++ Standard Library throughout their game and core engine. Some have been fast-paced (ie - racing titles) and many of the AAA titles have been on what would be concidered the bleeding edge of graphics and technology.

Not so coincidentally, the ones that make reasoned, extensive and consistent use of C++SL features are the one's which get more audit itterations (because each pass goes more quickly) and invariably produce less feedback from our team to theirs.

Yes, you do not want to allocate memory wontonly and sporadically, but that's why the standard containers take an allocator as a template arguement. It's not uncommon for the titles we review to have completely supplanted new/delete with their own custom memory manager -- which they use with the STL quite nicely.
0

##### Share on other sites
Full Disclosure
I am frequently in charge of managing the hiring of new employees in various positions, including those relating to software development, network management, and software architectural positions. Because of this I tend to have to review a lot of profiles, like yours.
Impressions
An initial examination of your site gives me two minor irritations. The first is that the background doesn’t fit with the foreground. The two don’t mesh properly. If you want to go that route, you need to ensure that the foreground meshes with the background properly As an example, a rounded border on the foreground elements would help to “embed” them into the background. Making the transition more seamless.
Secondly, the main page of your website is 200K, that’s a lot of wasted space for many things that I may never view. If you want to do what you’re doing, you might consider using jQuery to pull down the various pages as required (or in the background). This may not seem like a big issue to you, but on a busy corporate network, if I have to wait for your page to load up just to see your initial portfolio… it doesn’t look good. In comparison, the GameDev.net front page (which has significantly more content than you do) is only 109K.
Code
I popped open your sample code for your Cuburxia, and opened up CuburxiaGridAI.cs at random.

• The first class visible in the file is not the CuburxiaGridAI class, but an abstract class dealing with the matching. This is an abstract class why? It should be an interface, as that most accurately reflects the behavior it exemplifies. Abstract classes contain partial (or full) implementations of functionality, except in that they have the ability to defer some decisions to the inheritor. Interfaces do not have an implementation and specify a contract that must be implemented by the client (the inheritor). Since yours is specifying a contract, it should be an interface, not an abstract class.
• Usage of XML commenting is good. However, your viewpoint is one of the person perspective. You should try and keep your documentation comments non-personal, for instance by using a third person objective writing style. An example: “I take in a standard ai grid state and should look at it to determine if it has any matches.” Becomes: “Takes in a standard CuburxiaGridAIState. Returns null if there are no matches, otherwise a list containing the matches.”
• The usage of null as a return type, instead of an empty list, is not exactly a great idea. Prefer using the empty list instead, as you can simply have a singular code path instead of multiple. That is, you eliminate a check for null in favor of treating both matches and non-matches the same.
• The second class in the file is ALSO not the main class of the file, but is the actual matcher. Your comments in this section get worse. You have unnecessary comments that detail what you’re doing just before you do it. Don’t do that. They are a waste of time, and also a waste of the readers time.
• Prefer using an enumeration for your dimension instead of a random integer. This makes your code much more readable, and eliminates the necessity for the aforementioned comments.
• After all of this, we’re pretty much thinking that this file is in relation to the matcher, and not the grid AI…and then we hit the grid AI class. So, you should really break this out into a separate file, or perhaps two separate files. The matcher interface and the matcher its self can both go in the same file, or you can prefer to have two separate files for each. Alternatively you can keep them all into this file, however… if you do so, make sure that the implementation of the matcher comes AFTER that of the main class.
• At this point things go straight to hell. You’re using threads and you’re aborting and recreating the thread every time you want to refresh your “brain,” instead of reusing the thread. Your thread is using no synchronization at all, and you’re recreating various objects that exist in the parent on the fly. The only form of Synchronization you have is in the “IsWorking” thread that simply tests if the created thread is “non-null” and “IsAlive” both of which are not reliable measures. You should be using some manner of synchronization here.
• Your comments go even further awry here, with some indicating return values on functions that don’t even have a return type (aka, are void). You also have members scattered throughout the class in no particular order, and with dissimilar protections. Some are internal, some are private. Be consistent, and group properly.
• You also have several areas of nearly identical code that could be refactored out to methods which would significantly improve code readability.
• Again you’re using integers instead of enumerations to indicate axis. This decreases code readability. The comments only add a slight improvement to that.
• You also have a random inner class that appears to hold nothing but a reference to an array. Either just pass in the array, or use a value type class (struct). No need for the extra heap allocation.
• Finally we get to the end of the file where we find another TWO classes (albeit tiny ones), one of which could be a value type class.
Quote: Old code, hate it myself. Taking it out.

Whatever you have on your portfolio page should reflect the best of what you have to offer. Nothing less. This is YOUR portfolio, it is there to show prospective employers what you can do. Every sample should be perfect.

Quote:
 I do use standard libraries quite often, but only when I'm lazy and am just trying to prove a concept. The standard library is slow and chokes to death when compiled under debug. It's also not great when porting to different devices.

Really? That's funny I use the standard library all the time, and in production code too. I notice you had no trouble using the List type in your C# code, that's got the same allocation mechanism (roughly) behind it as the standard library does (there are minor differences, but they are of the kind you wouldn't notice for the most part). I prefer using containers that have been well tested by hundreds of thousands of programmers for years... rather than something that I whipped together to show that I know how to write a dynamically resizable array.

Furthermore, the standard library is no slower than the user. Proper usage of the standard library will produce fast code on most platforms that you'll use. There are exceptions, and for those you will find that eastl (modeled after the standard library) more than suffices. Most of that "debug" slowness is simply the standard library being intelligent and performing extra tracking and debugging of the usage, to prevent stupid things like indexing out of bounds.
0

##### Share on other sites
Quote:
 Original post by StephenTCI do have to say, there is only one AAA game company that I've heard of using the STL.

1. Ogre3D uses the SC++L extensively (there's even talk of including boost in new versions).

2. Ogre3D is used in many successful commercial games.

3. Therefore it follows that AAA game companies use the SC++L (STL as you refer to it as).

Quote:
 (Which for a string takes what... 2 hours?).

2 hours to write a self-proclaimed (probably buggy and slow) string class.

vs.

2 seconds to type out std::string which has been written over the course of many years by professionals. For example, does your 2 hour string implementation optimize for short strings?
0

##### Share on other sites

Quote:

Yes I do realize this. However that function fires once every... 4 or 5 seconds. It's not really a penalty to create one or two threads occasionally. Under the implementation it's unnecessary.

Quote:

You are right, however in this implementation there is no reason to use real Lock objects. The app doesn't do anything with the relevant data while it's searching so it's really equivalent to using Locks. It only uses that time to render.

Quote:
 Whatever you have on your portfolio page should reflect the best of what you have to offer. Nothing less. This is YOUR portfolio, it is there to show prospective employers what you can do. Every sample should be perfect.

Yes

Quote:
 notice you had no trouble using the List type in your C# code

Yes, I'd like to take this moment to clarify something.

I use HIGH-LEVEL languages all the time, such as C# and Python and I use all of the data structures involved there. However, I believe that if one is going to go through all the troubles that C++ has, they might as well become pedantic low-level coders. Sometimes I enjoy straight C coding as well (which has NO stl).

I agree that the STL is applicable. If you look at my physics code on my physics section you'll note them there(I'm currently recommenting and reformatting this so spare the reviews just yet). However, I prefer not to use it when I don't have to. Simple things, like strings and arrays do not require that much management. If I scared a recruiter off because I do my own memory management then I'm totally fine with that.

All in all, thank you everyone. I've gotten some good feedback.
0

##### Share on other sites
Quote:
 2 hours to write a self-proclaimed (probably buggy and slow) string class.

Just curious, have you ever opened up the stl string and looked at it's construction.
0

## Create an account

Register a new account