- Boost - lists.boost.org

BinTray is going away....
by Marshall Clow 06 Feb '21

06 Feb '21

My Friday morning email: > Thank you for supporting JFrog through your use of Bintray. We are and continue to be a community-focused company, and in the spirit of transparency we’re giving you advance notice that as of May 2021, we will be sunsetting Bintray. Just a heads up for now. — Marshall

2 1

Wrong class export/visibility setting for shared libs in many Boost libs
by Alexander Grund 02 Feb '21

02 Feb '21

Hi Boost maintainers, TLDR: Check your classes if they use BOOST_*_DECL and change that to BOOST_SYMBOL_VISIBLE In Boost.ProgramOptions I discovered an issue as a user, where I was unable to catch an exception thrown from the shared Boost library in an executable when both are build with hidden visibility. It turns out the exception class was marked with BOOST_PROGRAM_OPTIONS_DECL which evaluates to "visible" when building the DLL but to nothing when using it. This makes the linker (in theory) mark the typeinfo as hidden which means that the class thrown by Boost and the one tried to catch are unrelated. See https://gcc.gnu.org/wiki/Visibility > Symbol visibility is "default" by default but if the linker encounters just one definition with it hidden - just one - that typeinfo symbol becomes permanently hidden (remember the C++ standard's ODR - one definition rule). This is pretty clear that the current approach done by some Boost libraries doesn't/shouldn't work and BOOST_SYMBOL_VISIBLE should be used instead (or BOOST_SYMBOL_IMPORT should expand to BOOST_SYMBOL_VISIBLE. This depends on how MSCV/Win32 platforms handle class visibility as on Win32 BOOST_SYMBOL_VISIBLE expands to nothing. Maybe someone can clarify here.) As another datapoint: https://github.com/boostorg/config/blob/5bcaa933b55dd58797775d87605a6cdef4a… documents BOOST_SYMBOL_VISIBLE as the macro to be used for this. Libraries which are (very likely) affected by this (quick grep) include: Chrono Container Context Contract Coroutine Fiber Filesystem IOStreams JSON Locale MPI ProgramOptions Python Regex Test Thread Timer Seemingly Linux platforms are less strict in actually enforcing this, due to reason unknown to me. See my SO question: https://stackoverflow.com/questions/65951466/why-can-a-thrown-exception-wit… Reason why this went undetected so far are the above (works on some Linux, fails on e.g. OSX) and that user programs may often not be build with hidden visibility AND rely on the exact same typeinfo from the Boost library (most prominent: exceptions, dynamic_cast) Regards, Alex

5 40

Re: [boost] Wrong class export/visibility setting for shared libs in many Boost libs
by Peter Dimov 02 Feb '21

02 Feb '21

E.g. https://godbolt.org/z/vM6Gxd -----Original Message----- From: Peter Dimov Sent: Tuesday, February 02, 2021 17:01 To: boost(a)lists.boost.org Subject: Re: [boost] Wrong class export/visibility setting for shared libs in many Boost libs Niall Douglas wrote: > I seem to be having difficulty communicating this to anyone here, so > here's a godbolt: > > https://godbolt.org/z/jv5Y75 But you've provided a definition for thirdpartylib_nothidden. This is not the case under discussion. The case under discussion is making BOOST_SYMBOL_IMPORT imply _VISIBLE, which translates to a default visibility attribute on the _declaration_ of thirdpartylib_nothidden.

1 0

Google Summer of Code
by Radu Cosma 30 Jan '21

30 Jan '21

Good afternoon, My name is Radu Cosma and I would like to be a contributor to the Boost C++ Libraries in the context of Google Summer of Code 2021 (as a start :) ). I understand that the topics have yet to be posted and that there is a competency test involved. Could you please tell me the relevant information regarding this and the application process? Thank you in advance! Kind regards, Radu Cosma

1 0

What's the reason Boost.Asio tss_ptr doesn't use __declspec(thread) on Windows?
by Groke, Paul 29 Jan '21

29 Jan '21

Hi, I've noticed that Boost.Asio's tss_ptr implementation doesn't use __declspec(thread) on Windows, except when compiling for WinRT. Instead it uses the win_tss_ptr implementation - which will cause a crash when there's no free TLS index. (There are static tss_ptr instances and loading a DLL where a ctor of a static variables throws a C++ exception seems to cause a crash -- no surprise there). AFAIK using implicit TLS via __declspec(thread) should fix this so that loading a DLL either works or fails gracefully. One problem that I know of with implicit TLS is that it fails catastrophically on Windows versions before Vista. Since WinRT wasn't available on pre-Vista versions, this might be a reason to restrict it to WinRT. But I don't know if there are/were other reasons to restrict use of implicit TLS to WinRT. So... is there another reason? If there's no other reason, that would be great, because we don't have to support pre-Vista versions. Meaning we could simply patch Boost.Asio to use implicit TLS for MSVC in general. Regards, Paul Groke

1 0

Have we become too Intel x64 centered?
by John Maddock 28 Jan '21

28 Jan '21

I have no solution for this, but I note that neither do we have CI, nor tests on https://www.boost.org/development/tests/develop/developer/summary.html that aren't Intel x86. The compiler list has shrunk to msvc/clang/gcc as well. I note that at least in theory, other platforms/architectures could be integrated into Drone CI (either the CppAlliance one, or our own), but someone would have to offer to host the clients running the tests. Any thoughts/solutions? Cheers, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

21 54

Introduction
by Aman Verma 28 Jan '21

28 Jan '21

Hello Boost C++ Community, I am Aman from Indian Institute of technology Kanpur and currently, I am pursuing my bachelor's in Electrical engineering. I have 3 years of experience in C++. I am extremely eager and excited about contributing to various projects of Boost C++. I am willing to participate in GSOC'21 with Boost C++. I have gone through the project proposals and I find myself interested in the following projects: 1. ublas 2. Multiprecision 3. Geometry I would great if I could connect with the respective mentors and move onto further steps. Regards Aman

2 1

boost.numpy functions are throwing unresolved extern symbol link errors
by Max Fetz 20 Jan '21

20 Jan '21

Hello Boost-Community I have asked the following question everywhere but nowhere has it been answered. I have now been advised to ask here. I really hope there is someone on this mail list who can help me. Unfortunately I don't have much time left and would be very grateful for an answer. With kind regards Max My Question: I'm using normal Boost.NumPy functions in C++ like ndarray::get_data(), and I get a "reference to unresolved external symbol" error. The .lib's are linked and I have no approach on how to solve the error. I am using Boost 1.74. Here is a Code example: #include<boost/python/numpy.hpp> using namespace boost; void func(python::object _obj) { python::numpy::ndarray my_ndarray = python::extract<boost::python::numpy::ndarray>(_obj.attr("Member_01")); char* data = my_ndarray.get_data(); } BOOST_PYTHON_MODULE(ogwa_acc) { python::def("func", func); } Thats the one of the unresolved symbols: ""__declspec(dllimport) public: char * __cdecl boost::python::numpy::ndarray::get_data(void)const " (_imp?get_data@ndarray@numpy@python@boost@@QEBAPEADXZ)" I am using the normal Visual Studio linker and this is my linker config: /OUT:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pyd" /MANIFEST /NXCOMPAT /PDB:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pdb" /DYNAMICBASE "boost_numpy38-vc142-mt-gd-x64-1_74.lib" "boost_numpy38-vc142-mt-x64-1_74.lib" "boost_python38-vc142-mt-gd-x64-1_74.lib" "boost_python38-vc142-mt-x64- 1_74.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.lib" /DEBUG /DLL /MACHINE:X64 /INCREMENTAL /PGD:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Debug\ogwa_acc.pyd.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\Python38\libs" /LIBPATH:"D:\OthelloGame_withAI\Third-Party\boost_1_74_0\finished_libs" /TLBID:1 D:\OthelloGame_withAI\Third-Party\boost_1_74_0\finished_libs is the location of: boost_numpy38-vc142-mt-gd-x64-1_74.lib; boost_python38-vc142-mt-gd-x64- 1_74.lib; boost_numpy38-vc142-mt-x64-1_74.lib; boost_python38-vc142-mt-x64-1_74.lib

4 4

[build] b2 headers broken?
by John Maddock 16 Jan '21

16 Jan '21

Currently all CI seems to be failing during b2 headers, but with no obvious error message, see for example: https://drone.cpp.al/boostorg/multiprecision/23/1/2 Only possible thing I can see is: project-config.jam:10: syntax error at keyword in Anyone any ideas? Many thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 5

Feedback desired for neural networks library
by Sergei Marchenko 11 Jan '21

11 Jan '21

Hi everyone, I have a template-based library with several common types of layers which can be assembled into various neural networks: https://github.com/svm-git/NeuralNet, and I would love to get community feedback on the overall design, any issues or missing features, and how interesting a library like that would be in general. I've been watching the trends and research reports in the AI/ML space, and I feel that the recent announcements of the successful models for image classification, computer vision or natural language processing, push the focus towards very complex and computationally intensive networks. However, I think that the idea behind multi-layer networks is very powerful, and is applicable in many domains, where even a small and lightweight model can be used successfully. I also think that if developers have an access to a library of building blocks that allows them to train and run NN anywhere a C++ code can run, it may encourage a lot of good applications. In the current state, the library is fairly small and should be easy to review. It was built with two main goals in mind: * Provide a collection of building blocks that share a common interface which allows plug'n'play construction of more complex NNs. * Compile-time verification of the internal consistency of the network. I.e. if a layer's output size does not match the next layer's input, it is caught at the very early stage. Once it seems like there is some consensus on the core design and usefulness of such library, I am willing to do the work necessary to make the library consistent with Boost requirements for naming convention, folder structure, unit tests etc. The library relies on the C++ 11 language features and has a dependency on just a few STL components, so I think it should be straightforward to merge into Boost. Best regards, Sergei Marchenko.

6 15