| 1519 | | == 18. COUPLING/SOAPBOX: Essay about wisdom of defaulting to standalone capable (Boost) C++ 11/14 libraries with no external dependencies == |
| 1520 | | |
| 1521 | | If the last section was somewhat speculative due to the present uncertainties about the future developments in C++, these remaining two sections are almost entirely discussion pieces as they have no known good answers. Consider them therefore more as food for thought rather than recommendations. |
| 1522 | | |
| 1523 | | A very frequently heard request on boost-dev and boost-users is for Boost to become "modular", where modularity can mean quite a few different things depending on the claimant. Here are some of the more common meanings of "modularity": |
| 1524 | | |
| 1525 | | 1. I would like Boost (as a whole) to have fewer system requirements (minimum compiler versions, minimum OS support etc). This is usually really an argument in favour of better support for either legacy platforms and/or embedded or games systems, but do note the distinction for later. |
| 1526 | | |
| 1527 | | 2. I would like to use my favourite Boost libraries without needing the entire distribution to be available. |
| 1528 | | |
| 1529 | | 3. I would like to download my favourite Boost libraries and only their strict dependencies within Boost without having to download or even consider during build or configuration any unnecessary other Boost libraries (i.e. the package manager argument). |
| 1530 | | |
| 1531 | | 4. I would like to use my favourite Boost library using the Standard C++ Library facilities that come with C++ 11 instead of being forced into using Boost near equivalents (i.e. I get annoyed dealing with mixes of `std::future` and `boost::future`). |
| 1532 | | |
| 1533 | | 5. I would like to drop my favourite Boost library/libraries into my project as a single giant include file with no need to worry about Boost.Build or any build system or even dealing with a Boost source control system. |
| 1534 | | |
| | 1519 | == 18. COUPLING/SOAPBOX: Essay about wisdom of defaulting to standalone capable modular (Boost) C++ 11/14 libraries with no external dependencies == |
| | 1520 | |
| | 1521 | If the last section was somewhat speculative due to the present uncertainties about the future developments in C++, these remaining two sections are almost entirely discussion pieces as they have no known good answers. Consider them therefore more as food for thought rather than recommendations. I'll make the following discussion entirely Boost centric, but lots of corporations out there (Google is the most famous example) have truly enormous monolithic C++ codebases where this discussion equally applies if not far more so, so please consider find and replacing all mentions of Boost with ''<insert your large C++ code base here>''. |
| | 1522 | |
| | 1523 | A very frequently heard request on boost-dev and boost-users is for Boost to become "more modular", where modularity can mean quite a few different things depending on the claimant. Here are some of the more common meanings of "modularity": |
| | 1524 | |
| | 1525 | 1. I would like Boost (as a whole) to have fewer system requirements (minimum compiler versions, minimum OS support etc). This is usually really an argument in favour of better support for either legacy compilers OR embedded or games systems, but do note the substantial distinction for later. |
| | 1526 | |
| | 1527 | 2. I would like my favourite Boost libraries to have fewer requirements on their dependencies including other Boost libraries, especially exact version requirements (i.e. I want my favourite Boost library to detect and work with multiple versions of Boost). This is usually an argument from those who experience problems with things mildly breaking in different places in each Boost release, and they end up having to mash up their own Boost distro made up of newer and older individual Boost libraries to get the stability they need. |
| | 1528 | |
| | 1529 | 3. I would like my favourite Boost libraries to optionally not have the word "Boost" in their names as my employer's legal department have explicitly banned all Boost libraries now and forever in perpetuity. |
| | 1530 | |
| | 1531 | 4. I would like to download my favourite Boost libraries and only their strict dependencies within Boost without having to download or even consider during build or configuration any unnecessary other Boost libraries (i.e. the package manager argument). |
| | 1532 | |
| | 1533 | 5. I would like to use my favourite Boost library using the Standard C++ Library facilities that come with C++ 11 instead of being forced into using Boost near equivalents (i.e. I get annoyed dealing with mixes of `std::future` and `boost::future`). |
| | 1534 | |
| | 1535 | 6. I would like to drop my favourite Boost library/libraries into my project as a single giant include file with no need to worry about Boost.Build or any build system or even dealing with a Boost source control system. |
| | 1536 | |
| | 1537 | TODO |
