Re: [boost] [outcome] some problems compiling

Subject: Re: [boost] [outcome] some problems compiling
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-24 01:23:46

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/