[CXX-113] C++ driver should not require any boost libs to use Created: 04/Sep/10  Updated: 12/Dec/22  Resolved: 07/Jan/15

Status: Closed
Project: C++ Driver
Component/s: Implementation
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Dwight Merriman Assignee: Unassigned
Resolution: Won't Fix Votes: 5
Labels: cxxmove, legacy-cxx
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Related

 Description   

Linking with the mongodb c++ driver one might see

boost::system::get_system_category

if boost libs are not included. I don't see why it is necessary to have anything beyond headers to use the MongoDB C++ driver in practice, so we should try to make that happen.



 Comments   
Comment by Adam Midvidy [ 07/Jan/15 ]

While we have reduced the boost dependencies in the driver as much as possible, it is not reasonable to reduce them entirely without requiring C++11.

Comment by Andrew Morrow (Inactive) [ 25/Apr/14 ]

Here is a collection of boost symbols used in the driver and notes on analogues in C++11.

boost symbol C++11 symbol notes
boost::bind std::bind Easy
boost::condition std::condition Easy
boost::date_time::winapi::file_time_to_microseconds ? ?
boost::disable_if_c std::enable_if Need to reverse sense
boost::enable_if_c std::enable_if  
boost::function std::function Easy
boost::gregorian::date std::chrono? Might be very hard to shim
boost::hash_combine ? Might be very hard to shim, but could write our own
boost::intrusive_ptr ? No analogue in C++ std::
boost::lexical_cast ?  
boost::make_shared std::make_shared
boost::mutex::scoped_lock std::mutex
boost::mutex std::mutex
boost::noncopyable ? Switch to using DISALLOW_EVIL_CONSTRUCTORS?
boost::posix_time::hours std::chrono?
boost::posix_time::ptime std::chrono?
boost::posix_time::second_clock::local_time std::chrono?
boost::posix_time::seconds std::chrono?
boost::posix_time std::chrono?
boost::ref std::ref
boost::scoped_array std::unique_ptr<T[]> hard to arrange shim
boost::scoped_ptr std::unique_ptr<T>
boost::shared_ptr std::shared_ptr Easy
boost::thread::sleep std::thread?  
boost::thread_specific_ptr ?  
boost::thread std::thread Easy
boost::unique_lock std::unique_lock
boost::xtime std::chrono?
Comment by Andrew Morrow (Inactive) [ 24/Apr/14 ]

We have actually already eliminated two of the four boost link dependencies on the legacy branch. We no longer depend on filesystem or program_options. We still do depend on boost::thread and boost::system, these are not so easily eliminated in C++03 without writing our own portability wrappers around system primitives for mutexes, threads, etc. That is a significant undertaking and probably not something that we are going to attempt in the legacy driver.

Most of our boost dependencies are, interestingly, obviated by C++11. It might be possible to organize things in the driver such that when built in C++11 mode we have no boost dependencies. We would need to audit the existing boost usages and ensure that each had an analogue in C++11.

Comment by Dwight Merriman [ 24/Apr/14 ]

i think there are a couple of possible levels of usage. firstly, today, suspect you need the libraries for linking, which is the high end of boost requirements. second, one might imagine using a few boost things that are fairly lightweight like smart pointers, but that's it, and it's all header-only stuff. even better but more effort perhaps would be to use nothing from boost at all.

avoiding the libraries for linking might be not too hard. and that would be good as boost lib building can occasionally be a pain on some platforms and it one more thing to deal with.

Comment by Andrew Morrow (Inactive) [ 10/Mar/14 ]

We can evaluate what we are requiring from boost once we have finished stripping the driver down in the new repository. If the dependencies are quite minimal it may be possible, especially if the majority of uses are smart pointer types which we may be able to obtain via tr1 or C++11, or just hand roll.

Generated at Wed Feb 07 21:58:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.