Jump to content

  • Log In with Google      Sign In   
  • Create Account


Portfolio Review: Programmer (all comments welcome!)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
33 replies to this topic

#1 StephenTC   Members   -  Reputation: 100

Like
0Likes
Like

Posted 24 January 2010 - 09:21 AM

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

Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 14264

Like
0Likes
Like

Posted 25 January 2010 - 04:54 AM

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.


Advance Apologies
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]

#3 Orymus   Members   -  Reputation: 154

Like
0Likes
Like

Posted 25 January 2010 - 04:55 AM

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.

#4 StephenTC   Members   -  Reputation: 100

Like
0Likes
Like

Posted 25 January 2010 - 08:12 AM

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.

#5 StephenTC   Members   -  Reputation: 100

Like
0Likes
Like

Posted 25 January 2010 - 08:27 AM

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.

#6 ApochPiQ   Moderators   -  Reputation: 14264

Like
0Likes
Like

Posted 25 January 2010 - 10:01 AM

Quote:
Original post by StephenTC
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.


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.


So add a "show more details" link or something. It certainly isn't obvious enough as-is.

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]

#7 Xienen   Members   -  Reputation: 110

Like
0Likes
Like

Posted 25 January 2010 - 11:25 AM

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.

#8 Mike.Popoloski   Crossbones+   -  Reputation: 2851

Like
0Likes
Like

Posted 25 January 2010 - 11:39 AM

Quote:
Original post by Xienen
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.

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.
Mike Popoloski | Journal | SlimDX

#9 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 25 January 2010 - 11:45 AM

Quote:
Original post by Xienen
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.


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 __ ___ ____ __ __ ____.


#10 Zahlman   Moderators   -  Reputation: 1682

Like
0Likes
Like

Posted 25 January 2010 - 11:53 AM

I think you're missing an underscore. ;)

#11 StephenTC   Members   -  Reputation: 100

Like
0Likes
Like

Posted 25 January 2010 - 11:54 AM

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.

#12 Zahlman   Moderators   -  Reputation: 1682

Like
0Likes
Like

Posted 25 January 2010 - 11:56 AM

Quote:
Original post by Xienen
I 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.


#13 Xienen   Members   -  Reputation: 110

Like
0Likes
Like

Posted 25 January 2010 - 11:57 AM

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 Xienen
I 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.

#14 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 25 January 2010 - 12:03 PM

Quote:
Original post by Xienen
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).


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.


#15 StephenTC   Members   -  Reputation: 100

Like
0Likes
Like

Posted 25 January 2010 - 12:06 PM

Quote:
Original post by speciesUnknown
Quote:
Original post by Xienen
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).


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.

#16 m_switch   Members   -  Reputation: 234

Like
0Likes
Like

Posted 25 January 2010 - 12:18 PM

Quote:
Original post by StephenTC

Thankyou 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.


#17 Rycross   Members   -  Reputation: 576

Like
0Likes
Like

Posted 25 January 2010 - 12:19 PM

Quote:
Original post by StephenTC
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.


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 StephenTC
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.


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 StephenTC
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.


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 StephenTC
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.


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 StephenTC
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.


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.

#18 Josh Petrie   Moderators   -  Reputation: 2954

Like
0Likes
Like

Posted 25 January 2010 - 12:21 PM

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.

Watch your attitude.

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.

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#19 Josh Petrie   Moderators   -  Reputation: 2954

Like
0Likes
Like

Posted 25 January 2010 - 12:23 PM

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]

#20 Josh Petrie   Moderators   -  Reputation: 2954

Like
0Likes
Like

Posted 25 January 2010 - 12:26 PM

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.

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS