*headdesk* i so very much want to avoid a not written here attitude, and use system features when possible to ensure maximum portability, but... parts of the C++ STL are _so bad_ at what they do. Classes with (nearly) identical interfaces and behavior patterns dont share common base classes. This occurs all over the STL; the container types are an easy and common problem, but it is even true of the clocks in and the synchronization primatives in . There is no common base type between container types. The commonalities between a set, a list, a vector, etc. are huge, but I cant write a method that takes a generic collection and manipulates it, without resorting to templates. Using iterators doesnt work -- they get invalidated on container changes. Using templates breaks encapsulation and prevents polymorphism. I cant pass around a functor or lambda that takes a set or a list or a vector without jumping through a lot of hoops. While templates rely on very nearly the very weakest possible coupling, without capabilities or using a whole lot of enable_if template abuses, I cant guarantee behavior or extensibility. steady_clock and system_clock have literally identical APIs, but no common base class. As do mutex and recursive mutex. As do timed_mutex and recursive_timed_mutx (and those are a super set of mutex). This leads to insanity such as having to specialize a lock_guard or unique_lock (objects that auto-release a lock on destruction) to WHICH type of mutex they are holding. I literally dont care, and this means I have to not only have implementation details in my interface file, but make client code care, if i want to pass ownership to a caller. (the chrono standard also lacks boundary checking; with nanosecond accuracy, it can only account for +/-292 years. Overflow this, and the associated classes and methods are happy to chug along). And then there are just glaring problems that should have been obvious. While not having a read write lock implementation is surmountable, there are things in that are just unforgivable. If a thread is detached, or spawned by another thread, thread.get_id() is documented to return 0. What the...? And while detached threads can be destroyed, there is no external method to actually DO so short of explicitly calling the threads destructor. Which is pretty much guaranteed undefined behavior. This is truly basic behavior, not to mention relative priorities, thread quotas, pause and resume, and thread stack manipulation. (heck; the inability to take exclusive ownership of an unshared shared_ptr or the ability to tell a shared_ptr to surrender its pointer without destroying it (if not done at pointer construction) is driving me batty.)
Posted on: Tue, 22 Oct 2013 16:44:46 +0000
Trending Topics
Recently Viewed Topics
© 2015