Boost logo

Boost :

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:

Mingw is not on the list of supported compilers at

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


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at