1. The current GitHub repository consists of sub-repos. Do you (Niall) plan to have it like this when the library is accepted? Is it relevant?
A lot of the opposition to git subrepos appears to stem from lack of awareness of how they and git work. Some are opposed to boost-lite substituting for Boost, but as I have mentioned a fair few times now, I am following precedent for C++ 14 mandatory libraries here which doesn't have a hard dependency on monolithic Boost, and whether the internal platform abstraction layer is in a subrepo or not isn't hugely important for the end user.
Out of curiosity, what precedent is it?
I believe Boost.Hana has no hard dependency on the rest of Boost. I have also received quite a bit of private email begging me to keep Outcome free of a hard Boost dependency if accepted. I have asked them to say this publicly here, but I would assume they cannot for some reason or other. Quite a few talked about how their multinational's processes would find a standalone Boost.Outcome much much easier to deal with than one with dependency on other Boost libraries. Some of those are household name multinationals, and what they report matches my experience at BlackBerry.
I mean, they just #include and go. If that works, does any of the rest of it matter?
As a matter of fact, my questions were motivated by the fact that I #included but it didn't work. But apparrently, I incorrectly attributed the problem to sub-modules.
Mingw is not a regularly tested platform, and hence is not advertised on the documented compiler support page. Last time I tested it was well before Christmas. It's working on develop branch for me with my mingw-w64, but it's not for you with your version. Problems like these are exactly why I don't support mingw. People ought to use MSVC or winclang on Windows, those work much more reliably. If people really need a POSIX-y environment, Windows can now run Linux binaries very well, even from Win32.
2. This macro BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE, it controls whether I use this "preprocessed" file versus if I use... what? Normal header files? What is gained by this preprocessed file? Not having to include more than one header, or something else? Can I get different results when compiling with and without this macro?
The partially preprocessed edition is auto generated per commit. It saves the compiler from doing all the recursive #includes per compiland. It reduces compile times for end users a lot, I measured about half a second per compiland. Say for a project of 200 compilands, that's 10 seconds.
Are you saying the gain stems form includingg 1 versus N files?
That's part of it. But avoiding all the recursive macro expansion certainly helps too.
Several other Boost libraries also pre-preprocess header files into the source tree and when you #include that library, you are including the pre-preprocessed edition, not the original source code. It's pretty conventional for libraries doing a lot preprocessor work to use this technique to reduce the compile time impact on end users.
Could you tell me which libraries?
Is it Boost.Geometry and Boost.Serialisation or something? Back in the day where we emulated variadic templates using preprocessor recursive includes, that's what I'm thinking of.
Also, if the contents are identical, what do I need the non-preprocessed version for?
Well, it's the source of the source as it were.
Ok, let me change your explanation a bit. Going back to your exable, I have two version namespaces:
``` namespace boost { namespace outcome { namespace v1 { ... } } } namespace boost { namespace outcome { inline namespace v2 { ... } } } ``` Now, if I want to use outcome from v1, I can type:
``` namespace outcome = boost::outcome::v1; ```
And I didn't use any macro. I guess my question is, why do you need a macro for it?
Whilst Outcome is in an unstable state, the actual namespace used is: namespace boost { namespace outcome { inline namespace v1_GITSHA { ... } } } So there is no boost::outcome::v1 namespace yet, but there will be one day. Hence the macro.
Yes, I get that. Ok, now I understand why I got confused. I think the fix simply did not remove all errors on my version of MinGW.
Yes, it's a mystery. I would assume that your mingw-w64 is older than mine. They may have since implemented the integer to string conversion routines the compile error is complaining about recently. If you can figure out a way of detecting mingw-w64 version, I can use the non-_s editions of those conversion functions. That would get you up and running on your version of mingw. It might be worth, to help you with your review, to try fixing your Outcome edition and send me a pull request to try out the bug reporting. You can either fix the partially preprocessed header, or dive in and fix the original boost-lite source if you compile your program with BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/