2017-05-24 3:23 GMT+02:00 Niall Douglas via Boost
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
, 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;