Quote:Original post by the_edd
I guess I'm just saying it's unfair to criticise a platform-neutral standard for failing to standardise something platform specific. I'm not entirely sure that's what you were doing, though :)

I wouldn't call many of the listed points platform specific. And even if some of them were, I question the viability of a completely platform neutral standard library altogether, at least for C++. For EA, for myself and for many others, it's exactly this lack of platform specific adaptation that makes the STL unusable in practice.

What good are container classes when I can't pass them over a DLL boundary, especially in a modern plugin driven application that resides to 99% in DLLs ? How could I use a standard algorithm that isn't thread safe in a heavily multithreaded application, especially in the times of multicore CPUs ? How could I rely on non-specified, opaque, and often highly inefficient storage allocation schemes for objects that are created and destroyed many times a second, in performance critical code ?

On top of that, the STL has a lot of inherent design flaws. Yes, Boost corrects many of them, but it doesn't address the implementation issues mentioned above. Not mentioning the additional bloat coming with it.

If you look at STL related criticism from actual industry programmers (ie. not the academics sitting around and deriving standards, but the ones actually using them in real world projects), you tend to always stumble across the same issues over and over again. These issues can, and should be addressed in a standard.

Shared library and thread safety can be mandated without leaving platform neutrality. Memory allocation behaviour can be standarized, or better hooks for custom allocators can be provided. Debug support is harder, I agree. But at least non-cryptic symbols can be mandated, as well as banning void pointers in places where they don't belong.

And finally, standard library subsystems should be "reality checked" much harder before promoting them into the standard. iostreams anyone ?

I fully agree with Yann L. ... why do they still use STL? Next-gen consoles are so sensitive to some C++ constructs. Using STL is the perfect way to a trainwreck.
I guess some guys at EA have to much time here. Most companies I know did the same as Yann described it.

- Wolf

Quote:Original post by Yann L

Quote:Original post by the_edd
I guess I'm just saying it's unfair to criticise a platform-neutral standard for failing to standardise something platform specific. I'm not entirely sure that's what you were doing, though :)

I wouldn't call many of the listed points platform specific.

Sorry, here I was talking about the threading/DLL stuff in the post to which I replied, not the stuff brought up in the EA document as a whole, necessarily.

Quote:And even if some of them were, I question the viability of a completely platform neutral standard library altogether, at least for C++. For EA, for myself and for many others, it's exactly this lack of platform specific adaptation that makes the STL unusable in practice.

What good are container classes when I can't pass them over a DLL boundary, especially in a modern plugin driven application that resides to 99% in DLLs ?

I can't argue with this point. But it's unfair to criticise the STL for something it was not designed to do, nor can it be designed to do. Passing template classes over DLL boundaries is fraught with danger, whether the templates are from the STL or elsewhere. It's fine if the implementation of the templates classes are "ABI stable" (in the appropriate sense for the platform), but if they're not you can't have pluggable/upgradable libraries.

I'm interested to hear that you "question the viability of a completely platform neutral standard library altogether". What alternative approach is there for a language whose overriding goal is to be platform neutral? (serious question!)

Quote:How could I use a standard algorithm that isn't thread safe in a heavily multithreaded application, especially in the times of multicore CPUs ?

How can you use *any* algorithm or function in such a situation? The C++ standard simply has nothing to say on multi-threading yet. This issue isn't restricted to the STL. The whole standard lacks any notion of threads (until ~2009 IIRC). If you're using multi-threading now, you're on your own (or part of a wider community of people who are also on their own :)). You have to check what guarantees your specific compiler/processor(s)/caches/OS give you in *any* C++ code you write, whether it uses the standard library or not.

Quote:How could I rely on non-specified, opaque, and often highly inefficient storage allocation schemes for objects that are created and destroyed many times a second, in performance critical code ?

This is indeed one of the areas where I really agree with EA's proposal reflects what the "community" knows already; that the allocator specification is seriously flawed.

Quote:If you look at STL related criticism from actual industry programmers (ie. not the academics sitting around and deriving standards, but the ones actually using them in real world projects), you tend to always stumble across the same issues over and over again. These issues can, and should be addressed in a standard.

The load has to be shared between the standardisation committee, compiler implementers and library implementers. A lot of the stuff the document mentions are issues found in a specific implementation.

A large number of the people on the committee are involved in real world development. But games programming is a particularly constrained/demanding programming niche and it's voice perhaps isn't heard as loudly as it could be.

Quote:Shared library and thread safety can be mandated without leaving platform neutrality.

I'm not sure any kind of standardisation in this area would be particularly beneficial. I say this because the common ground between shared library implementations across all the platforms that currently have C++ implementations (in real-world use) is so narrow that any attempt to standardise on this would yield wording lacking in specifics and we'd be in no better shape than we're in now, in this regard.

Quote:Memory allocation behaviour can be standarized, or better hooks for custom allocators can be provided.

Yes, I think fixing the allocator mechanism is the way forward. Memory allocation behaviour is too heavily tied to the OS (if there is one) in a number of cases to mandate specific behaviour in the general case.

Quote:Debug support is harder, I agree. But at least non-cryptic symbols can be mandated, as well as banning void pointers in places where they don't belong.

The void pointer thing is an implementation issue. If a particular vendor's library is made using void pointers in the node-like structures, then (IMVHO) it's a bad implementation and the vendor should be asked to fix it.

However, there may be very good reasons why the implementation has used void pointers (not that I can think of any, personally) and if there is reason to use void pointers in some cases, the standard should not mandate that void pointers are not to be used. That would be detrimental to a the library implementation on a given platform. Then you'd hear the argument from the opposite side of the fence to loosen up the restriction again. It *has* to be a QOI issue wrt to the library implementation. Bug reports should be filed against the library.

Quote:And finally, standard library subsystems should be "reality checked" much harder before promoting them into the standard. iostreams anyone ?

That's one of the reasons that boost exists, of course. I think the committee regards real-world experience as a very valuable asset after the whole "export" experience.

<semi-ot>
Incidentally, I'm interested in the problems with iostreams in respect to games programming. We use our own I/O subsystem at work, but it seems worse than using iostreams. No one there has ever been able to explain to me why we didn't just use iostreams in the first place.

Are there any URLs you could give me? Maybe a PM would be most appropriate?
</semi-ot>

Edd

Quote:It looks like about equal parts of actual, useful, obvious-in-retrospect fixes to the Standard--it's difficult to argue with a better allocator interface and passing predicates by reference--and special purpose fixes for console platforms. Most of the former category really deserves to be rolled into the next TR. That includes stuff like intrusive_list which I suspect will get a much chillier reception than if Boost had been offering it up.

It might not get as chilly a recpetion as you'd expect especially since intrusive containers where recently accepted into boost, although they werent in time for the 1.34.0 release.

Quote:Original post by the_edd
[...]<semi-ot>
Incidentally, I'm interested in the problems with iostreams in respect to games programming. We use our own I/O subsystem at work, but it seems worse than using iostreams. No one there has ever been able to explain to me why we didn't just use iostreams in the first place.

Are there any URLs you could give me? Maybe a PM would be most appropriate?
</semi-ot>

Edd

I recently had to make a custom file input class at work because the ifstream class (or one of it's ancestors etc) uses a signed 32-bit value to represent file position somewhere along it's call chain even though the actual input type to the set-position function could hold 232-1 (so much for compile-time asserts doing any good). Of course, this problem only shows up for very large files (over 2 GiB) and is entirely implementation dependant, but it was quite annoying. For the record, the problem occured with MSVC 7.1 and the library that comes with it.

Quote:Original post by Kylotan
No reason it couldn't, though. The only issue I think is that the non-deterministic nature of thread safety is that it incurs overhead in situations where you can guarantee not needing that overhead. I suppose this is where another trait or policy parameter could come in.

I agree. I use a Policy based Multithreading system in my code. You can very easily include any threading library or a single threaded version that will just optimize away the empty calls (assuming a good compiler).