Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 23:20:09

>>> 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/