- Boost - lists.preview.boost.org

using clang-cl with 1.74-rc2 forces auto-link to search for clangw10 libs instead of using existing microsoft-cl built libs
by Dennis Luehring 12 Aug '20

12 Aug '20

using latest VS2010 and llvm/clang 10.0.0 release (10.0.1 is a litte bit more recent but no windows builds available) compiler set to 2017 microsoft-cl in VS2017: libboost_serialization-vc141-mt-gd-x32-1_74.lib compiler set to clang-cl in VS2017: libboost_serialization-clangw10-mt-gd-x32-1_74.lib that behavior is new to 1.74 - older boosts versions 1.69..1.73 would use the vc141 libs what makes sense because clang-cl is the microsoft-cl compatible replacement normaly there is no need to switch any external libs when using clang-cl instead of microsoft-cl

1 0

[release] Boost 1.74.0 Release Candidate 2
by Marshall Clow 12 Aug '20

12 Aug '20

The second release candidates for the 1.74.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.74.0/source/> The SHA256 checksums are as follows: 903fd40074de8dc733d2f0b6b0642e43b714653eaeb79289b12161b9567fae97 boost_1_74_0_rc2.7z 83bfc1507731a0906e387fc28b7ef5417d591429e51e788417fe9ff025e116b1 boost_1_74_0_rc2.tar.bz2 afff36d392885120bcac079148c177d1f6f7730ec3d47233aa51b0afa4db94a5 boost_1_74_0_rc2.tar.gz a0e7ce67c52d816708fdeccdd8c9725626ba61254c13c18770498cacd514710a boost_1_74_0_rc2.zip Changes from RC1: * Fix a recently introduced bug in Boost.Asio where it would read from uninitialized memory. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

3 3

[release] Boost 1.74.0 beta 1 released
by Marshall Clow 09 Aug '20

09 Aug '20

Boost release 1.74.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.74.0.beta.1/source/> The SHA256 checksums are as follows: 577a6b575ff2c227e14cce1b929c73d969475e58f3d2ab2901ad234f773bbd12 boost_1_74_0_b1.7z ba09c72dc848e7c0904922967014d853897b5a634926c910cc3b1fd627c31605 boost_1_74_0_b1.tar.bz2 2ccdc39efa076822cf1b359f9449f9d07707f3e27a18b393297b25885a9ff45b boost_1_74_0_b1.tar.gz c267c450166e040a374eaddab5e583cef09f6c3fe96a4db826172d0315c38dd5 boost_1_74_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_74_0.html>. Please download the beta, give it a try, and report any problems you encounter. Issues that were found during the beta release process and will be fixed for the final 1.74.0 release: * The Boost.STLInterfaces documentation was left out of the beta. * Some of the Boost.Geometry documentation files have very long names; this could cause problems on platforms (like Windows) with shorter limits on path lengths. * There is a compile error in Boost.ASIO when compiling with 32-bit MSVC-14.2 with BOOST_BEAST_NO_TS_EXECUTORS. Thanks, -- The Boost Release Team

2 3

[release] Master branch now closed for 1.74.0 release
by Marshall Clow 06 Aug '20

06 Aug '20

1 0

Re: [boost] Hello everybody, I have something to share about the shared_ptr class
by 逸霖杨 04 Aug '20

04 Aug '20

Last post was sent directly to Rob, I forgot to cc list.bost.org. Thinking of the multiple calling of the detors, which is suggested by Rob and other members, I came up with some ideas. This IS about specification. If class A has a dispose method like class A { A(){} ~A(){} //Dispose method: !A(){} }; Where !A() can be called multiple times and ~A() can be called only one time. Everything rcgc_ptr delegates will be called its dispose in !A() and therefore multiple times to just decrease the reference count and finally call ~A() when real delete happens. And this can be done on the compiler level (!A() maybe not visible at all or just visible when you use like ~A()). Saying this algorithm is a part of the C++ language itself, then C++ has no need to manually manage pointers (at least the unwanted management). Idea is inspired by all of you especially Andrey Janson and Rob. Thank you all! Best Regards, Yilin

3 10

[release] 1.74.0 post-beta merges
by Marshall Clow 03 Aug '20

03 Aug '20

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on August 5th. -- The release managers

13 52

Hello everybody, I have something to share about the shared_ptr class
by 逸霖杨 02 Aug '20

02 Aug '20

Hello dear boost members, I’m quite honored to join this mail list for the first time! As I was told that the boost project is where the shared_ptr class originated, so I think it should be OK to talk about it here. Here I have some ideas and code on my version of shared_ptr class. The aim is to remove the usage of weak_ptr and fix the circular reference problem. Please check code on https://github.com/yyl-20020115/RCGC That’s the idea and primitive implementation. I don’t know exactly how to test it more widely among situations, please help me to find the very situations that this solution would fail, and I’ll try to fix it ASAP. READM.md is a good start and README_ZHCN.md is better if you can read Chinese. However, I don’t think I can illustrate the algorithm very well both in English and Chinese. Well the code speaks for itself, and please read the code and run the program. Please generate a makefile and build with CMakeLists.txt on *nix platforms if Visual Studio 2019 (where I code the project) is not available. All ideas and discussions and help from you are all very welcome! Best Regards, Yilin

6 18

[Release] Reminder: master branch closes 5-August for 1.74.0 release
by Marshall Clow 02 Aug '20

02 Aug '20

The calendar of events is up at: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

1 0

[release] Reminder about release notes
by Marshall Clow 02 Aug '20

02 Aug '20

Please submit pull requests against https://github.com/boostorg/website/blob/master/feed/history/boost_1_74_0.q… to be included in the release notes for 1.74.0 — Marshall

1 0

Re: [boost] About rcgc_shared_ptr
by 逸霖杨 31 Jul '20

31 Jul '20

A downgrade implementation can be like this (which is actually my former implementation during the experiments) We define an interface: struct IDIsposable { virtual void Dispose() = 0; }; And implement this interface with class A class A : public IDisposable { Public; A():disposed(false){} public: virtual void Dispose(){ if(!this->disposed){ this->_pb.Dispose();//this Dispose belongs to rcgc_shared_ptr this->_pc.Dispose(); //this Dispose belongs to rcgc_shared_ptr this->disposed = true; } } bool disposed; rcgc_shared_ptr<B> _pb; rcgc_shared_ptr<C> _pc; }; And we don’t care about ~A() and let the rcgc_shared_ptr call Dispose method of the IDisposable. This would avoid the dtors definition. However, this is not as elegant as the previous given solution in C++, having to write more code which we don’t like to do, although no difference in other languages or platforms. I’m sorry that I have to call it a day now and have to get some sleep (4:06am here) Waiting for your kindly response and suggestions. Best Regards, Yilin

1 0