|
Re: Your C++ Wish List (Editorial)
|
Posted: Oct 31, 2004 5:23 PM
|
|
(1) Consider making a statement about what kinds of memory models C++ will support.
Example: I have been involved a number of projects in which multiple processes had their own static spaces, but all had access to a shared arena. It seems the world is moving away from this, toward the multi-threaded model, in which every thread has the same static space.
I don't have a problem with this move. But consider: I could make an STL container accessible to all processes by putting it in the shared arena and giving it a shared-memory allocator. However, I cannot use the Boost shared_ptr in this context, since it does dynamic allocation, but does not allow me to specify an allocator.
I am not saying the Boost shared_ptr is "bad" (on the contrary, I think it is very much needed). I am saying that we need to think about things like this. Do we intend to support every memory model under the sun? If so, then any shared_ptr that gets added to the Standard Library needs to allow specification of an allocator. If not, then we should make a explicit statement about what memory models the Standard Library is intended to support.
(2) More generally, be careful about introducing possible system dependencies into the Standard Library.
The "C++0x Standard Library Wishlist" includes:
5. A threads library 6. A socket library 10. Some form of simple graphic/GUI library
All of these (and possibly some others on the list) will tend to make C++ favor certain kinds of systems above others. Again, I do not have a problem with this. I do have a problem with adding these things without careful consideration and explicit statements of intent.
(3) Include the Boost random number library.
Isn't everyone tired of cruddy pseudo-random number generators?
(4) Some thoughts on octonions and quaternions:
From the "C++0x Standard Library Wishlist":
21. Math/octonion & math/quaternions (used by game designers for 3d math)
Octonions are a mere curiosity, to be exhibited in the occasional advanced math class. No one uses them for anything practical. Certainly no game designer does anything with them.
Quaternions, on the other hand, certainly are useful, being a good basis for computations involving 3-D rotations and orientations.
However, the Boost quaternion package, while it is a top-notch implementation, is a mathematician's idea of a quaternion package, not a game designer's. The mathematician thinks the trig functions and the multipolar representation are great, but the game designer will never use them. The game designer wants quaternions that interact well with 3-D vectors. For example, it seems silly to have to write
quaternion<double>(0., v[0], v[1], v[2]);
when what I really want is something like
quaternion<double>(0., v.begin());
I suggest adding a constructor that, as above, takes a floating-point value and an input iterator. Similarly, add a version of quaternion<T>::unreal that takes an output iterator and sends its i, j, & k values to wherever the iterator points.
(5) Lastly, for goodness sake, specify std::sort to be O(n log n).
The committee knows that already, right?
|
|