DOC: follow-up of removing boost::scoped_ptr

doc/technical/howto/UsingBoost.txt

@@ -164,16 +164,26 @@ libraries (those people know very well what they're doing...)
 
 some practical guidelines
 ~~~~~~~~~~~~~~~~~~~~~~~~~
-- `boost::format`, `boost::variant`, `boost::any`, `boost::lambda` and the more elaborate metaprogramming
-  stuff adds considerable weight. A good advice is to confine those features to the implementation level:
-  use them within individual translation units (`*.cpp`) where this makes sense, but don't cast
-  general interfaces in terms of those library constructs.
+Facilities like `boost::format`, `boost::variant`, `boost::any`, `boost::lambda` and the more elaborate
+metaprogramming stuff add considerable weight. A good advice is to confine those features to the implementation
+level: use them within individual translation units (`*.cpp`) where this makes sense, but don't express
+general interfaces in terms of those library constructs.
+
+Actually, for the most relevant of these, namely `boost::format` and `boost::variant`, we have either
+created a lightweight front-end or our own simplified implementation in the support library, leading
+to a significant reduction in overall code size.
+
+Beyond those somewhat problematic entities, there used to be several incredibly useful tools from the
+Boost library, which create only moderate overhead -- nothing to be really concerned about. Fortunately,
+mostly these have meanwhile been adapted into the official standard library, and can thus be used without
+creating a dependency on Boost.
+
 - the _functional_ tools (`function`, `bind` and friends), the _hash functions_, _lexical_cast_ and the
   _regular expressions_ create a moderate overhead. Probably fine in general purpose code, but you should
-  be aware that there is a price tag. About the same as with many STL features.
-- the `shared_ptr` `weak_ptr`, `intrusive_ptr` and `scoped_ptr` are really indispensable and can be used
-  liberally everywhere. Same for `enable_if` and the `boost::type_traits`. The impact of those features
-  on compilation times and  code size is negligible and the runtime overhead is zero, compared to _performing
+  be aware that there is a price tag. About the same as with many STL other features.
+- the `shared_ptr` `weak_ptr`, `intrusive_ptr` and `unique_ptr` are really indispensable and can be used
+  liberally everywhere. Same for `enable_if` and the `type_traits`. The impact of those features on
+  compilation times and  code size is negligible and the runtime overhead is zero, compared to _performing
   the same stuff manually_ (obviously a ref-counting pointer like `smart_ptr` has the size of two raw pointers
   and incurs an overhead on each creation, copy and disposal of a variable -- but that's besides the point I'm
   trying to make here, and generally unavoidable)

src/backend/real-clock.hpp

@@ -68,7 +68,6 @@ namespace backend {
 
 //using std::vector;
 //using std::shared_ptr;
-//using boost::scoped_ptr;
   
   
   /**

src/common/query/defs-manager-impl.hpp

@@ -71,8 +71,8 @@ namespace query  {
   
   
   
-  /** @internal causes boost::checked_delete from \c scoped_ptr<DefsRegistry>
-   *  to be placed here, where the declaration of DefsRegistry is available.*/
+  /** @internal causes std::default_delete from `unique_ptr<DefsRegistry>`
+   *  to be emitted here, where the declaration of DefsRegistry is available. */
   DefsManager::~DefsManager() {}
   
   

src/lib/scoped-holder-transfer.hpp

@@ -60,7 +60,7 @@ namespace lib {
    * - besides, the \em noncopyable type needs to provide an
    *   <tt>operator bool()</tt> yielding true iff currently
    *   containing an managed object. This is similar to
-   *   boost::scoped_ptr or even the behaviour of a plain
+   *   std::unique_ptr or even the behaviour of a plain
    *   old raw pointer, which is equivalent to \c true
    *   when the pointer isn'T \c NULL
    * 

src/lib/scoped-holder.hpp

@@ -29,9 +29,9 @@
  ** use of shared_ptr  or even a garbage collector. Sometimes circumstances
  ** rather call for a very simple or lightweight solution though.
  ** 
- ** ScopedPtrHolder is a simple extension to boost::scoped_ptr, enabling
+ ** ScopedPtrHolder is a simple extension to std::unique_ptr, enabling
  ** to use it within STL containers if we stick to a specific protocol.
- ** The idea is to permit copying as long as the scoped_ptr is empty.
+ ** The idea is to permit copying as long as the unique_ptr is empty.
  ** This can be used to allow for extension of the STL container on
  ** demand, i.e. to handle the typical situation of a registry which
  ** is initialised lazily, but only released in a controlled fashion.
@@ -69,7 +69,7 @@ namespace lib {
   
   
   /**
-   * Extension to boost::scoped_ptr, allowing copy operations
+   * Extension to std::unique_ptr, allowing copy operations
    * on empty pointers (i.e. contained pointer is null).
    * @throw error::Logic on attempt to copy otherwise
    */
@@ -128,7 +128,7 @@ namespace lib {
   
   
   /**
-   * Inline buffer holding and owning an object similar to scoped_ptr.
+   * Inline buffer holding and owning an object similar to unique_ptr.
    * Access to the contained object is similar to a smart-pointer,
    * but the object isn't heap allocated, rather placed into an
    * buffer within ScopedHolder. Initially, ScopedHolder is empty

src/lib/scoped-ptrvect.hpp

@@ -26,7 +26,7 @@
  ** For example, a service provider may need to maintain a number of individual
  ** process handles. The solution here is deliberately kept simple, it is
  ** similar to using a STL container with shared_ptr(s), but behaves rather
- ** like boost::scoped_ptr. It provides the same basic functionality as
+ ** like std::unique_ptr. It provides the same basic functionality as
  ** boost::ptr_vector, but doesn't require us to depend on boost-serialisation.
  ** 
  ** Some details to note:

src/proc/engine/engine-service-mock.cpp

@@ -35,7 +35,6 @@ namespace engine{
   
 //    using std::string;
 //    using lumiera::Subsys;
-//    using boost::scoped_ptr;
 //    using std::bind;
   
   

src/proc/engine/engine-service.cpp

@@ -35,7 +35,6 @@ namespace engine{
   
 //    using std::string;
 //    using lumiera::Subsys;
-//    using boost::scoped_ptr;
   using std::function;
   using std::bind;
   using std::ref;

src/proc/play/play-controller.cpp

@@ -208,7 +208,6 @@ namespace play{
   
 //    using std::string;
 //    using lumiera::Subsys;
-//    using boost::scoped_ptr;
 //    using std::bind;
     
     

src/proc/play/play-process.cpp

@@ -37,7 +37,6 @@ namespace play {
   
 //    using std::string;
 //    using lumiera::Subsys;
-//    using boost::scoped_ptr;
 //    using std::bind;
   using lib::transform;
   using lib::append_all;

src/proc/play/play-service.cpp

@@ -60,8 +60,6 @@ namespace play {
 
 //using std::string;
 //using lumiera::Subsys;
-//using std::auto_ptr;
-//using boost::scoped_ptr;
 //using std::bind;
   using lib::Sync;
   using lib::RecursiveLock_NoWait;

src/proc/play/render-configurator.cpp

@@ -40,7 +40,6 @@ namespace play {
   namespace error = lumiera::error;
 //    using std::string;
 //    using lumiera::Subsys;
-//    using boost::scoped_ptr;
   using std::shared_ptr;
   using std::bind;
   using std::placeholders::_1;

src/proc/play/timings.hpp

@@ -75,7 +75,6 @@ namespace play {
 
 //using std::vector;
 //using std::shared_ptr;
-//using boost::scoped_ptr;
   
   enum PlaybackUrgency {
     ASAP,

tests/core/proc/play/diagnostic-output-slot.hpp

@@ -71,7 +71,6 @@ namespace play {
 
 //using std::vector;
   using std::shared_ptr;
-//using boost::scoped_ptr;
   
   namespace { // diagnostics & internals....