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.

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.

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.

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.

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.

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.

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]

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.