Re: [boost] [outcome] some problems compiling

Subject: Re: [boost] [outcome] some problems compiling
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-24 10:38:09

2017-05-24 3:23 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> On 23/05/2017 22:46, Andrzej Krzemienski via Boost wrote:
> > So, I am trying to run my first test program with Boost.Outcome. The
> > library fails to compile with GCC 6.3.0 on MinGW on Windows 7. I have
> filed
> > the issue: https://github.com/ned14/boost.outcome/issues/36
>
> Mingw is not on the list of supported compilers at
> https://ned14.github.io/boost.outcome/prerequisites.html
>
> I refuse to support Mingw, not worth the waste of my time. I will
> unofficially support Mingw-w64. Outcome had been tested on mingw-w64
> some time ago, but it had become minor broken since, it's now fixed on
> develop branch. Thanks for the bug report.
>
> A far better experience than Mingw is to use the Linux Subsystem for
> Windows 10. Full Ubuntu 16.04 LTS environment, but on Windows.
>
> > But also, I can see in file <boost/outcome/outcome_v1.0.hpp>, lines
> 1267 to
> > 1279
> >
> > ```
> > #ifdef __cplusplus
> > namespace
> > {
> > #endif
> >
> >   typedef struct _IMAGEHLP_LINE64
> >   {
> >     unsigned long SizeOfStruct;
> >     void *Key;
> >     unsigned long LineNumber;
> >     wchar_t *FileName;
> >     unsigned long long int Address;
> >   } IMAGEHLP_LINE64, *PIMAGEHLP_LINE64;
> > ```
> >
> > 1. Why do you check for __cplusplus? Is it a copy-and-paste of some
> Windows
> > headers?
>
> It's C source code from an all C sub-sub-library brought into the
> partially preprocessed edition. That particular all C sub-sub-library
> implements POSIX backtrace() and backtrace_symbols() for Windows.
>
> > 2. This class and subsequent functions are defined in anonymous
> namespace.
> > This means they are redefined and recompiled in each translation unit,
> and
> > remain a per TU definition. Is that intent?
>
> Yes. Because it's a C source file, you would get symbol collision errors
> otherwise.
>

Can't the same effect be achieved with declaring the functions inline? And
then you would only get one symbol.

Regards,
&rzej;