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

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-27 12:42:43

2017-05-27 1:20 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

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