Somepotato wrote:

Standards compliant doesn't mean that its a good implementation. The standard is often vague.

They're efficient implementations. Care to provide some benchmarks that back up your claim? I'm sure Microsoft and GNU's development teams would love to hear it.

What? Every STL implementation of RNG is different. That is bad, you want uniformity in games that can work across multiple platforms.

They each use the same algorithm that gives the RNG its name. You pick which one you want to use, and the compiler should be conformant to its algorithm. .-.

http://en.cppreference.com/w/cpp/numeric/random

Anyways, I thought the STL were the container classes, not RNG, and I can't find any reference claiming otherwise. Like I said, you should quit pretending to know what you're talking about.

You can't say I'm wrong here. Here it makes more sense to use STL because they can use the operating system facilities to optimize things further.

And how exactly does the operating system manage it outside of allocating and delocating its memory? .-.

They're a container aid that could be optimized by the compiler... How exactly does the operating system optimize it any differently than any other data types, huh?

Thats not what I mean-- the fact its abstracted well into classes means it can be updated without much issue.

Abstract doesn't mean that it can't be updated without any issue. e.e

If you're talking about new standard library additions affecting backwards compatibility, that's generally not how it works...

He specifically stated he was using an old regex library. But it will DEFINITELY be faster than the softcoded library (so in reality speed will likely not be much of a concern unless its just terrible). The security concerns are rather minuscule but for example if you look at the recent libpng overrun it shows that old libraries are still at prone to exploitation(fortunately libpng is still updated often)

That's why I said it should be updated to the latest stable build-- incase there's an exploit present.

Somepotato wrote:

If you're not going to read my post, then read http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/ n2271.html#Motivation

Considering I've picked apart everything you've said, it's evident that I've read your post.

That link you've posted dates back to 2007 and isn't relevant anymore. There have been many revisions since 8 years ago.

Oh, and the STL is in every case faster or equal to than coding the exact same thing.

The only exception is if you need a container that has special functionality not given by an STL container, then coding that to work around the special functionality can be faster in some cases.