2017-05-27 1:20 GMT+02:00 Niall Douglas via Boost
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.
Ok.
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.
This probably deserves a separate thread. My understanding is that we have three expectations: 1. Boost developers do not want duplication in Boost. 2. Non-boost users of Outcome do not want a dependncy on Boost. 3. Niall does not want to maintain two nearly identical libraries.
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.
Hold on. This is the page you are referring to: https://ned14.github.io/boost.outcome/prerequisites.html It says:
Outcome is a header only C++ 14 library known to work on these compilers or better:
- clang 3.5 (LLVM) - clang 3.7 (with Microsoft Codegen) - GCC 5.4 - VS2015 Update 2 - Xcode 7.3
It does not mention explicitly that it does not support MinGW. Now, MinGW, according to my knowledge, is not a compiler but a platform on which a compiler works. On MinGW I am using compiler GCC 6.3.0, and this compiler is supported (Or not? -- you are ony mentioning GCC 5.4). This has been always my understanding of what MinGW is.
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.
Your decision to simply refuse to support some platform, well.., bothers me. I understand that you do not have access to different compier/platform versions, and that makes looking for bugs quite a burden. But it was my understanding that this is how library maintainance works in Boost. You have the test matrix, where people offer to test your library on compilers/platforms you have never thought of, and you get the required feedback. Can you be persuaded to a conditional agreement: if Outcome gets accepted into Boost, you extend the range of supported compilers.
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.
Macros other than #include ? Usually you need macros to do things in a different way based on platform, but the precompiled heder does not know what platform it will be used on, so I wonder what macros you mean.
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.
Ok.
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.
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 { ... } } }
This sounds like we are doing a formal review of a library in an unstable state.
So there is no boost::outcome::v1 namespace yet, but there will be one day. Hence the macro.
Will that day be before Outcome enters Boost? IOW, can I expect that in an official Boost version I will be able to just use: `boost::outcome::v1`?
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.
Maybe. On the other hand my bug is about using undeclared symbols ` _ui64toa_s
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/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost