2015-11-28 Murray Cumming 2.47.3 2015-11-28 Murray Cumming Threads: Add @deprecated to more API. 2015-11-28 Murray Cumming Threads::Private: Suggest use of thread_local. 2015-11-28 Kjell Ahlstedt Use std::unique_lock::unlock() instead of release() * glib/blibmm/main.cc: * gio/src/application.ccg: Glib::Threads::Mutex::Lock::release() should have been replaced by std::unique_lock::unlock(). std::unique_lock::release() does not unlock the mutex. Bug #757674. 2015-11-27 Murray Cumming Remove now-unnecessary includes of glibmm/threads.h. 2015-11-27 Murray Cumming Dispatcher: Use std::mutex instead of Glib::Threads::Mutex. 2015-11-26 Murray Cumming Deprecated Glib::ThreadPool. Because we should encourage the use of 2 different thread APIs at the same time. Maybe std::async() does what a thread pool would do? If so, we should improve the deprecation documentation. 2015-11-26 Murray Cumming Glib::Main: Use std::mutex instead of Glib::Threads::Mutex. And std::unique_lock instead of Glib::Threads::Mutex::Lock. 2015-11-26 Murray Cumming Gio::Application: Use std::mutex instead of Glib::Threads::Mutex. And std::unique_lock instead of Glib::Threads::Mutex::Lock. Some of these could probably be replaced by std::lock_guard, in a smaller scope, instead of using release(), but this is a simpler replacement. 2015-11-26 Murray Cumming ObjectBase: Change extra_object_base_data_mutex to a std::mutex. Instead of a (now deprecated) Glib::Threads::Mutex*. As discussed here: https://bugzilla.gnome.org/show_bug.cgi?id=757674#c12 2015-11-26 Murray Cumming Glib::MainContext: Deprecate wait(cond, mutex). Because it uses the deprecated Threads API in its API, and doesn't seem generally useful. As suggested here: https://bugzilla.gnome.org/show_bug.cgi?id=757674#c11 2015-11-26 Murray Cumming glibmm_mainloop test: Allocate a thread on the stack. As suggested by Kjell Ahlstedt: https://bugzilla.gnome.org/show_bug.cgi?id=757674#c10 2015-11-26 Murray Cumming examples/tests: Use simpler std::thread constructor. Instead of using a lambda. As suggested by Kjell Ahlstedt: https://bugzilla.gnome.org/show_bug.cgi?id=757674#c10 2015-11-26 Murray Cumming thread example: Use std::unique_ptr<> with std::thread. As suggested by Andrew Potter: https://bugzilla.gnome.org/show_bug.cgi?id=757674#c9 2015-11-26 Murray Cumming resolver example: Use std::mutex instead of G_LOCK_DEFINE_STATIC. As noticed by Kjell Ahlstedt: https://bugzilla.gnome.org/show_bug.cgi?id=757674#c10 2015-11-26 Murray Cumming tests/glibmm_mainloop: Use the std::thread API instead of Glib::Threads. 2015-11-26 Murray Cumming Network examples: Use std::thread instead of Glib::Threads::Thread. Bug #757674 2015-11-26 Murray Cumming examples: dispatcher: Use std::thread and friends. Instead of deprecated Glib::Threads::*. 2015-11-26 Murray Cumming thread example: Use std::thread, etc, instead of deprecated Glib::Threads::*. 2015-11-26 Murray Cumming threadpool example: Use std::mutex instead of Glib::Threads::Mutex. And std::lock_guard<> instead of Glib::Threads::Mutex::Lock. 2015-11-26 Murray Cumming Threads: Deprecate in favour of the C++11/C++14 concurrency API. Such as std::thread, std::mutex, std::lock_guard, std::condition_variable. 2015-11-23 Kjell Ahlstedt Tests: More nullptr instead of 0 2015-11-23 Kjell Ahlstedt Gio: More nullptr instead of 0 2015-11-23 Kjell Ahlstedt Glib: More nullptr instead of 0 2015-11-23 Murray Cumming Regenerate *_docs.xml files. 2015-11-23 Murray Cumming Regenerate Glib defs. 2015-11-23 Murray Cumming Regenerate GIO .defs. 2015-11-22 Kjell Ahlstedt gmmproc: Use nullptr instead of 0,NULL,zero in some comments * tools/pm/DocsParser.pm: Replace NULL by nullptr, when C comments are converted to C++ comments. In many cases "an empty string" would be a better replacement text, but it's difficult to automatically decide when "nullptr" is not correct. * tools/pm/Output.pm: Use nullptr where appropriate in comments. 2015-11-22 Kjell Ahlstedt gmmproc: Fix a test in Output.pm::get_ctor_properties() * tools/pm/Output.pm: A test whether a parameter is optional was messed up in such a way that it was always true. The test is just a precaution. In all normal cases the result of a correct test is also true. Probably the error has not affected the code generation from any correct .hg file.