Timeline for STL for games, yea or nay?
Current License: CC BY-SA 2.5
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 12 at 19:32 | comment | added | Jonathan Wakely |
@CoffeDeveloper maybe you found it in the 8+ years since your comment, but if not, the equivalent with istreams is if (stream.peek() == '#') stream.ignore(std::numeric_limits<streamsize>::max(), '\n'); where the ignore call can easily be wrapped into a less ugly skipLine(stream) helper if you prefer that. ignore(n, c) extracts and discards up to n characters or until the first occurrence of c.
|
|
| Jul 1, 2021 at 23:01 | comment | added | Justin Meiners | @CoffeDeveloper STL typically doesn't refer to iostreams and other platform stuff, as that was written before, and separately. | |
| Jul 1, 2021 at 22:57 | comment | added | Justin Meiners | I don't understand how it was ever "too slow". I understand containers may not allocate memory in a game friendly way, but all the algorithms expand to code which is just about as good as you can hand write it. | |
| Mar 6, 2020 at 16:13 | comment | added | Tomáš Zato | I work in the same department as kevin42 and we have our own implementation/wrapper over stl for various reasons. | |
| Nov 16, 2015 at 12:54 | comment | added | CoffeDeveloper | correctness depends on clarity and code lenght also. | |
| Nov 15, 2015 at 17:24 | comment | added | Ed Ropple | @DarioOO I don't know that file format, but that's what stream adapters and filters are for. I wrote that comment five years ago, mind (and it occasionally keeps coming back!), but these days I write about anything that isn't super, super perf-critical in a functional, transform-based style and issues like the one you're describing fall out of the problem. I don't really care all that much about line count (and IMO nor should you), I care about correctness of implementation, then clarity, then performance, and then such things as code length. | |
| Nov 14, 2015 at 13:06 | comment | added | CoffeDeveloper |
@EdRopple try to implement a STL parser for PPM image files (less than 100 lines of code in total if only targeting P6 or P3). Half of the resulting code is just for skipping comment lines because STL does not provide something like if(stream.nextCharacter() == '#') stream.skipLine();
|
|
| Apr 21, 2014 at 4:22 | vote | accept | munificent | ||
| Dec 24, 2010 at 13:56 | comment | added | ggambetta | @Simon: with all due respect, the last example is a sign of extreme cluelessness, and has nothing to do with STL... that person would do the same in any other language with lists that can be sorted. It's his thinking that is broken. | |
| Aug 13, 2010 at 5:48 | comment | added | Simon | @Ed Ropple: I think that the issue is not that STL doesn't fit a given problem, the issue is that it fits too many problems which makes the code in it too complex. It is scary how people over-use STL and I think that is one of the cause why so many (including myself) refrain from using it at all. Like one example I saw not long ago where the question was how to get the largest out of 3 numbers, one of the answers was pushing them into an std::vector and then std:sort it. That's definetly forcing a solution that's unneccessary onto a very simple problem. | |
| Jul 17, 2010 at 22:01 | comment | added | Ed Ropple | This is pretty solid advice. The "STL is slow" meme hasn't been true for at least five years and probably well longer. It will continue to live on, much like the "Java is slow" and ".NET is slow" nonsense, until it becomes apparent to everyone that it's no longer the case. The STL helps you write better programs; I'd go so far as to say that not using it, in most cases (aside from that 0.1% somewhere), is irresponsible. (The claims that it doesn't fit a given problem domain are often more of an indictment of the way the problem was tackled, not the STL itself. Fix your code, folks.) | |
| Jul 15, 2010 at 1:39 | history | answered | kevin42 | CC BY-SA 2.5 |