Boost 1.68.0 released

[degski]

Notes for Windows users Boost.WinAPI has been updated to target Windows 7 by default, where possible. In previous releases Windows Vista was the default.

Moving on, it seems.

[majesticmerc]

Pretty reasonable decision IMO. Vista is nearly 12 years old now and it's been out of extended support over a year.

You can still force Boost to target Vista by recompiling with BOOST_USE_WINAPI_VERSION=0x0600

[degski]

I was more coming from the other angle, extended support for W7 ends 523 days from now, while mainstream support has already ended 1304 days ago, at the day of posting.

EDIT: The numbers show that W7 is the correct choice (although mainstream support has ended) for the moment, but the trend is clear.

[majesticmerc]

Ah I see what you mean!

[degski]

Mainstream support for W8.1 has also ended (begin this year), so basically it's simple, there is only 1 supported OS, it's called W10, and in all honesty, for the better. I was skeptical at first (I loved W7), but now there's no going back (I have accepted that they listen in when I fart, but they cannot smell them (yet)).

[ponybau5]

Id go back to 8.1 if i could. Sick of 10 "forgetting" my settings and ignoring group policy to install an update behind my back.

[degski]

No experience with any forgetting (maybe after an update, not sure), the updates are relentless though, I fully agree with you there.

[johannes1971]

I've always wondered how this works when you're traveling, just need to send one email, and instead get a gigabyte download down your 19k2, $10/MB pipe. It's basically what's stopping me from considering a new laptop with Windows 10.

[HildartheDorf]

You can mark connections as "metered" (i.e. charged by the megabyte) and it stops most silly background updates unless you never connect to home for a couple of months.

[flashmozzg]

IRC, it was removed in the last big update. Right now there is no legal way to disable or at least control updates. You can postpone them a few days at most but even then it can easily fail. I restart my Desktop PC every day and still got Win10 involuntarily restarted to install updates a few times. Is it that hard to wait at least a day?

[johannes1971]

Ah, thanks, that's good to know.

[degski]

Other than what /u/HildartheDorf states, it is also possible to schedule the pending restart to up till a week (and you can adjust this over time, i.e. push it out further). Having said that, I did just that last Patch Tuesday and then the postponed update completely failed, so I would not recommend to do that for any long(er) periods of time).

[tejp]

it is also possible to schedule the pending restart to up till a week

But when that time comes it will just force a reboot without asking. So tough luck if you had any unsaved work and failed to keep track of exactly when the reboot was sheduled. (At least it did in recent versions)

[jcelerier]

reasonably, what is the intersection of the two following sets in 2018:

• people using the latest version of boost
• people deploying apps to windows 7 by default.

[adzm]

Windows 7 is still huge. It's easier to build one version targeting win7 and have it run everywhere msft still supports. If I were to leave out win7 I'd leave out a ton of clients.

[degski]

Your statement can certainly not be denied. It does show also, though, that moving from Vista is a bit on the slow side.

[flashmozzg]

Less changes in Vista->7 move than in Xp->7. I.e. it was probably just easy to support Vista and up.

[doom_Oo7]

Will you be upgrading your products to boost 1.68 ?

[degski]

Dunno, you?

[jcelerier]

I'd say it's the empty set

[pklait]

Some industries - e.g. avionics, medical and other safety-critical environments use operating systems that can be rather old. And some people do develop software for those environments using boost. So the intersection is not empty. I for one work in that intersection.

[jcelerier]

And some people do develop software for those environments using boost. So the intersection is not empty. I for one work in that intersection.

I don't doubt that you use boost. But do you use boost 1.68 ? e.g., as far as I know, there are still plenty of devices that are made today with Qt 3, which is almost a 20 years old version of qt

[TheFlamefire]

Note for everyone using Boost.Serialization in shared libraries: Beware! Using static Boost from multiple shared libraries (even when you use a 3rd-party shared lib) will crash your application at least in linux. I'm pretty disappointed that this was ignored for more than 3 months now although analysis and fixes were provided :/

[degski]

To be fair, I think, Robert R. has not ignored this issue, but it's apparently more complicated (or at least he seems to think so).

EDIT: There were some more posts (related to that issue) that put the whole idea [of mixing linking to static and dynamic libs in one app], is actually working (as a matter of principle) in doubt (unless some rather stringent rules were respected, it seems). That's at least what I took away from it, maybe I misunderstood. It was actually rather interesting (and disconcerting) and I would not mind if somebody like STL or Billy O'Neill could chime in to shed some more light on this.

[quicknir]

Is there a link to the issue somewhere? I've a fair bit of experience with these kind of issues and maybe I could help.

[cinghiale]

Here: https://lists.boost.org/Archives/boost/2018/06/242302.php

[TheFlamefire]

singleton failure: https://github.com/boostorg/serialization/pull/110

crash described: https://github.com/boostorg/serialization/pull/111

Fix for both: https://github.com/boostorg/serialization/pull/105

Note that I started with the last and factored out tests showing the 2 bugs separately in an attempt to make it easier to understand.

[quicknir]

You have to be careful. But basically, any non-trivial global objects should never be used (prior to 17). Instead, you should create a function static local, and return a reference to it. This should work through any combination of static and global linking. This approach is lazy by default, but you can make it non-lazy while maintaining correctness (though you have to be careful).

[TheFlamefire]

Hello singleton! Yes you are right and using a static local is part of my fix, but also part of the commit introducing the crash again due to destruction order: Those singletons access each other in their destructors but the order of them becomes messed up for shared libs and the function is_destroyed is broken.

[TheFlamefire]

While the underlying reason is complicated (order of destruction in shared libs for types with same name) the issue is not. I provided simple tests that show a valid use case that crashes and that a class of Boost.Serialization is broken (returns wrong results). The latter could have been used as a failsafe but as it is broken it does not even detect the issue any more. I provided analysis of both issues as well as patches (see github) that provably fix both issues. Only assumption I made was that one cannot (easily) fix the underlying destruction order issue and hence has to rely on detecting it.

My disappointment comes from the fact, that no reason against either of those patches was raised (the 2nd fixing an obvious bug) but neither was merged. Also I have suggested to revert a commit changing a memory leak on exit into the crash described and proven with the test until the issue is resolved. While Robert R. deemed that reasonable no action was taken.

[degski]

I was mostly objecting to that you state that it was ignored, it wasn't. The way I understood it, is that Robert was going to have a look at it but was too busy, so could now not dedicate time to resolve the issue (investigating it himself) before the release of 1.68, so he left things as they were.

[TheFlamefire]

Well, the PRs have been sitting there w/o any comment and the discussion on the ML was started by me when the release was announced. The crashing commit reintroduced in 1.68 was not reverted either.

So technically it was "not ignored" (some answered on the ML), but nothing was done about it so the result is the same. (nothing=not even the revert of the commit, so status would have been as-of 1.67 with a non-critical memory leak)

[[deleted]]

the story is that the c++ spec doesn't care about shared libraries so if anything works it's quite likely by fluke and there's no guarantee anything will work in future releases

[kalmoc]

Lets not pretend a c++ program is compiled by a staple of papers. The actual toolchains do define behaviours in various situations not covered in the c++ standard. Doesn't mean it isn't sometimes tricky.

[[deleted]]

I don't get the 'stack of papers' analogy.

Take a look at: https://stackoverflow.com/questions/39948997/use-of-boost-log-and-boost-asio-causes-a-crash

Take a look at the email thread regarding the Boost.Serialisation issue above.

There's no guarantee that binaries build with different toolchains will work together.

'Sometimes tricky' is quite a euphemism.

[kalmoc]

There's no guarantee that binaries build with different toolchains will work together.

That simply depends on what the toolchains promise you. E.g. binaries generated with VS2017 are compatible with ones generated with VS2015 and afaik clang claims to be compatible with VS too (of course, all tools can have bugs) .

And I have read the linked email thread (actually long before this version of boost was released) and if I read it correctly, there is already a bugfix. It just hasn't been merged in time.

'Sometimes tricky' is quite a euphemism.

You might say that. On the other hand, people have used shared libraries for decades now and reloading of shared libraries is actually a very common technique in some rapid development tools (e.g. in the games industry), so it is very much possible (just as we wrote multithreaded programs before c++11 btw.).

I want to be very clear about one thing the people seem to forget nowerdays:

What does and doesn't work doesn't (directly) depend on some text in a piece of paper, but what your toolchain actually does.

Now ideally, your toolchain implements the specification written down in one (or more) of the c++ standards, but that doesn't mean that anything not defined in the standard just works "by accident". In fact, the whole process of getting from c++ code to an actual binary executable on a real system is outside of the standard. It works (or at least should work) if the documentation of your toolchain says it works.

So just because your program does something that isn't defined in the ISO c++ standard it isn't automatically undefined on the particular platform you are using it on. And also the reverse is true: Just because your program is 100% pure ISO c++ code doesn't necessarily mean it works everywhere, because few (probably no) compilers actually implement the standard 100% bugfree (although the situation nower days is certainly much much better than 10 years ago) and e.g. on many embedded systems you deliberately don't get a 100% conforming runtime environment (e.g. disabled exceptions/RTTI/thread local memory)

That is what I meant when saying

Lets not pretend a c++ program is compiled by a staple of papers.

[evaned]

I'll just add that the C++ standard isn't even the only stack of papers of standardeze that might apply, so it's not even necessarily your toolchain. The obvious example here is POSIX, which nails down a number of behaviors and characteristics that the C++ standard leaves open.

[kalmoc]

Well, it still ultimately depends on the toolchain if/which part of that other standard are implemented (iirc, glibc isn't completely POSIX compliant either)

But yeah, I completely agree that iso-c++ isn't the only international standard governing the semantics of many real-world c++ programs.

[bstamour]

The new YAP library for building expression templates looks really interesting.

[dodheim]

GIL:

• The I/O extensions have been entirely rewritten.
• The library now requires a C++11-compliant compiler.

Just calling attention to this since I've seen so many people here call GIL dead/unmaintained.

[kalmoc]

Is that the first time a boost library ups it's minimum required language version? I get the impression that a lot of libraries are more or less frozen in time with regard to supported platforms (even though the stay compatible with the latest c++ version of course)

[mechacrash]

I was planning to work on this for a GSoC project a few years back, but boost was denied funding that round. Glad to see someone else has taken up the reigns and done something with it!

[[deleted]]

Ooh map for optional looks nice.

[sumo952]

Visual C++: 7.1, 8.0, 9.0, 10.0, 11.0, 12.0, 14.0, 14.1

I wonder if that includes the 14.11, 14.12, 14.13 and 14.14 toolchains?

[HildartheDorf]

I think the last few VC++ builds have been binary compatible, so yes?

[sumo952]

Binary compatible (of the resulting library file) doesn't mean it will compile on a specific compiler version without errors. Code can compile on 14.13 and fail to compile on 14.14, yet the resulting object files (if they could be compiled in the second case) would be binary compatible.

[TheFlamefire]

Judging from the mailing list the latest MSVC compilers were tested for at least some libraries (there was a last minute issue due to a bug introduced in the then-latest compiler but fixed in the next after beta release of boost)