- Boost - lists.preview.boost.org

Fwd: Boost.StaticString (formerly Boost.FixedString) is ready for release!
by degski 03 Mar '20

03 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Mon, 2 Mar 2020 at 23:14 Subject: Re: [boost] Boost.StaticString (formerly Boost.FixedString) is ready for release! To: Alexander Grund <alexander.grund(a)tu-dresden.de> On Mon, 2 Mar 2020 at 09:57, Alexander Grund <alexander.grund(a)tu-dresden.de> wrote: > Because if you use a signed type you have no compile-time guarantee that > the value is unsigned (using "type" and "value" to differentiate those 2). > You have indeed the guarantee that it is non-negative, compile-time, the problem is that, although you now know it is positive, you have lost (compile-time) any means of determining whether this value is correct (at run-time), while the guarantee at compile-time is just tautological. I don't understand really what you have against it, one can always use an int64_t, iff worried about int32_t overflow. Same as with a pointer: It can be NULL. > This value of null in itself is nothing special, it points at the top/bottom of the stack, there's nothing, so we hit UB. I don't think this is a good parallel. Pointers are not numbers, addition is meaningless. Adding up sizes is not meaningless, and we do it every day. Adding (or deducting) up a size and a pointer-difference is not meaningless either, that's why size needs to be signed. > If you want an interface where you want to guarantee at compile-time that > the value passed over an API is never NULL, you use e.g. a reference that > can never be NULL (or not_null<T>) > Herb's most recent post puts another angle on this: http://herbsutter.com/2020/02/23/references-simply/ . > > >> Didn't you argue in the mail before that there will never be anything of >> size 2^32 and hence even not anything like 2^64? How could you overflow >> that then? >> > > If you are manipulating (subtracting, adding differences) pointers, I > thought I wrote that. The pointers might be pointers into Virtual Memory > and can have any value [1, 2^56]. > > Not sure I understand that. Can we agree that a 64-bit unsigned type is > big enough to store any size of any container and hence no overflow is > possible? > Yes, certainly, what about a 63-bit value (the positive part of a signed 64-bit int), is that too small? ... signed type which may be an unsigned value. You'll have to check. > No, a signed value is never an unsigned value in disguise (that would result in overflow), the other way around, yes. I disagree. And as mentioned you can do things like `int difference = > int(obj.size()) - 1` anytime you want to do operations that are not fully > defined on unsigned types (as in: may result in values outside the range) > same as you can't to `int foo = sqrt(integer)` because you may get an > imaginary number (if sqrt could do that, but I think you get the gist). > C++ has questionable math's. How is that any different from `assert(a <= size); return size - a;`? > That's not what you wrote earlier. The you introduced a branch in release and made the function throw. > > all that because it upsets you that something that should not occur in > the first place in correct code can occur iff one is writing code that now > (as one observed it got negative) is known to have a bug. > > Again: How is that different to using a signed type for "size"? You have > exactly the same potential for bugs. You always have to make sure you stay > in your valid domain, and a negative size is outside of that valid domain. > Hence you got to check somewhere or use control flow to make sure this > doesn't happen. So no difference in signed vs unsigned size regarding that > The unsigned cannot overflow, that is not a bonus, that's a problem! > The use of unsigned is false security (actually no security) and serves > nothing. In the end, you still need to write correct code (so the signed > int's WON'T BE negative, there where they shouldn't be), but this practice > makes you're code less flexible, more verbose (the unavoidable casts add to > that) and probably slower than using signed. All that because of this > 'natural' way of looking at sizes. > > It serves as a contract on the API level: "This value is unsigned. > Period." > No, it says, if the value is out of the problem domain, don't worry, I'll cover it up (behind you're back so your app appears to be working, I make sure of that at compile-time). If the type was signed you'd need something else to enforce that the value > is unsigned. So yes you still need to write correct code and passing a > negative value to an API expecting an unsigned value is in any case a bug. > Of course, I never said, quite the opposite, that one not needs to write correct code. > Surely at runtime. How else could you guarantee that your value isn't > negative after you subtract something from it? It can be compile-time if > you only add something to it and ignore overflow but you already do that > when using signed values anyway. > > So, why does it need to be guaranteed positive at compile time? It just needs to be positive (size) at run-time, and as per above, you'll have to check. > But all this arguing doesn't solve much: What piece of code would actually > benefit from having a signed size? > I have already spelt out the reasons in an earlier post in this thread. > And not only the part where you request the size and use it, but also the > part where you give that size back to the object, so you'll need to ensure > an unsigned value. And yes `for(int i=0; i<int(obj.size())-1; i++)` is a > known example that would allow to get rid of the cast if the size was > signed. But again: That is due to operation used. `for(unsigned i=0; > i+1<obj.size(); i++)` is perfectly valid assuming no overflow > Thou shall not compare signed and unsigned values, my compilers insist and keep on telling me that. So now you need a cast to shut the thing up, and I would write: for ( int i = 0, back = static_cast<int> ( obj.size ( ) ) - 1; i < back; ++i ). I would like: for ( int i = 0, back = obj.size ( ) - 1; i < back; ++i ). This is my last post on the subject (bar new arguments). Thank you for the discussion. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

2 2

Boost.StaticString (formerly Boost.FixedString) is ready for release!
by Krystian Stasiowski 02 Mar '20

02 Mar '20

Hi all, After some post-review polishing, Boost.StaticString is good to go for release! I have been in touch with the review manager, and everything has been checked over. Repo: https://github.com/sdkrystian/static_string Docs: https://sdkrystian.github.io/doc/static_string Here are some things that have been changed post-review: - Library has been renamed from Boost.FixedString to Boost.StaticString. Class template fixed_string has been renamed to basic_static_string, and aliases have been added for common character types, similar to std::string. - constexpr support to the fullest extent supported by available compilers has been added. - Functions that will not throw have been marked noexcept. - Moved to a single header configuration. - std::hash and boost::hash_value support has been added. - It has been decided that functions will throw on capacity overflow. - A specialization for when the capacity is 0 has been added that has no member. Additionally, the type of the member used to store the size of the string is now statically chosen to be the smallest possible width unsigned standard integer type that can hold all the needed size values. - operator+ has been implemented. - Floating point conversion support has been added to to_static_string/to_static_wstring. - Lots of bugs fixed. More behind the scenes, a bunch of optimizations have been added, taking advantage of the fact that the capacity is part of the type and known at compile time. Again, thank you all who participated in the review, and thank you Joaquin for managing it! Regards, Krystian Stasiowski

7 16

Projects for GSoC 2020
by David Bellot 01 Mar '20

01 Mar '20

Hi Boost community, so far we received a few good contributions for projects for GSoC 2020. The proposals are from our usual mentors but I'm surprised we don't have more projects in data structures and algorithms. Most of what we have concern numerical problems. It's great but I wish to see more diversity in the type of projects we propose. We want to attract the best students around the world and push toward new C++ standards and improvements of what we already have. Being a mentor is a great experience and on top of it, without too much effort, you will get someone of quality working for you during all the summer. The wiki page for projects is here: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2020 Please come, edit and contribute. Cheers, David

2 2

What is the right way to close and clean boost::log
by JH 01 Mar '20

01 Mar '20

Hi, I built boost::log in my application library, it created boost::log::sinks::synchronous_sink<boost::log::sinks::text_file_backend> and close it by calling the boost::log::core::get()->remove_all_sinks() in destructor of the Log library, then one of my application link to my log library got Segmentation fault when it exited: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5fdd961 in boost::log::v2_mt_posix::core::remove_all_sinks() () from /usr/lib/x86_64-linux-gnu/libboost_log.so.1.65.1 If I add boost::log::core::get()->remove_all_sinks() in my application main before it return 0, the segmentation was gong, but it stuck. What is the proper right way to close and clean the boost::log? There is a blog suggested to run boost::log::core::get()->remove_all_sinks() when the main end, but that does not seem work. https://www.boost.org/doc/libs/1_62_0/libs/log/doc/html/log/rationale/why_c… Thank you. Kind regards, - jupiter

2 3

Cryptography for Boost.
by Mikhail Komarov 29 Feb '20

29 Feb '20

Hello! Cryptography for Boost. Again. It’s been some time since I’ve started developing so-called clean C++ cryptography implementation for my organization’s internal purposes. It was intended at first to be a cryptography framework fulfilling special cryptography schemes requirements, but eventually it has evolved into a full-featured suite, actively using and, sometimes, even based on Boost libraries. This turned out to be fine way to serve the Boost (and entire C++) community and to assemble a Boost version of a suite. So this letter is about wether there is still any interest in cryptography library for Boost and is there any sense to show the community what do I have for now? Sincerely yours, Mikhail Komarov nemo(a)nil.foundation

6 22

[gsoc] Encourage original ideas
by Mateusz Loskot 29 Feb '20

29 Feb '20

Hi, I noticed there may be confusion among students regarding project ideas. I sense, students (sometimes) fail to find the GSoC guides [1] ... So, based on the first paragraph of [1], I have updated our wiki [2] placing this note to students: "To any potential students, in addition to the list of project ideas, we don't discourage original ideas proposed by students. " If any mentors here disagree, please let me know and I will remove it (or move it to GIL, which I'm involved with as a mentor). [1] https://google.github.io/gsocguides/student/finding-the-right-project [2] https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2020 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Who's using Boost
by Adam Getchell 28 Feb '20

28 Feb '20

Name: CDT-plusplus [1] Company: University of California Davis CDT-plusplus generates ensembles of quantum spacetimes under the Causal Dynamical Triangulations program using the Metropolis-Hastings algorithm, with other algorithms planned. These ensembles allow calculations of quantities such as the spectral dimension and the overall transition amplitudes from the beginning until the end of time for a simulated universe of given dimension and volume. Many different research problems may be answered with these ensembles, including the existence of a Newtonian limit in CDT [2], renormalization group flow in CDT, [3] and spontaneous dimensional reduction in short distance quantum gravity. [4] Where Boost is used: 82 Boost libraries are used in conjunction with CGAL [5] in order to perform accurate geometric and combinatoric operations on 3 and 4-dimensional Delaunay triangulations. Boost.Optional and Boost.Outcome are used to assist in correctness guarantees for billions of moves permuting triangulations on simulations running for months on High Performance Compute clusters. [6] [1] https://github.com/acgetchell/CDT-plusplus <https://github.com/acgetchell/CDT-plusplus> [2] https://ui.adsabs.harvard.edu/abs/2015APS..APR.X7006G/abstract <https://ui.adsabs.harvard.edu/abs/2015APS..APR.X7006G/abstract> [3] https://arxiv.org/pdf/1405.4585.pdf <https://arxiv.org/pdf/1405.4585.pdf> [4] https://arxiv.org/pdf/0909.3329.pdf <https://arxiv.org/pdf/0909.3329.pdf> [5] https://www.cgal.org/ <https://www.cgal.org/> [6] https://www.hpc.ucdavis.edu/ <https://www.hpc.ucdavis.edu/> Let me know if further information is needed. -- Adam Getchell, M.S. https://adamgetchell.org <https://adamgetchell.org/>

1 0

GSoC, Boost C++ and Slack channel
by David Bellot 28 Feb '20

28 Feb '20

Hi Boost community, we have a dedicated channel on Slack for all the discussions regarding the Google Summer of Code. Please join us on cpplang.slack.com on the channell #boost-gsoc. Cheers, David

5 4

Re: [boost] Cryptography for Boost.
by Kenneth Porter 26 Feb '20

26 Feb '20

--On Friday, February 21, 2020 6:21 PM +0300 Mikhail Komarov via Boost <boost(a)lists.boost.org> wrote: > It's been some time since I've started developing so-called clean C++ > cryptography implementation for my organization's internal purposes. It > was intended at first to be a cryptography framework fulfilling special > cryptography schemes requirements, but eventually it has evolved into a > full-featured suite, actively using and, sometimes, even based on Boost > libraries. This turned out to be fine way to serve the Boost (and entire > C++) community and to assemble a Boost version of a suite. How does it fit in with openssl and SASL? I'd been contemplating dipping my toes into a Windows email client and openssl has a native Visual Studio port but I don't know of one for any SASL libraries. So the available open source email libraries tend to be *nix-oriented and have to be built with a ported *nix toolchain.

8 8

Start with Boost Multiprecision
by Tarun Lahrod 25 Feb '20

25 Feb '20

Hello, I am Tarun Lahrod. An engineering undergrad who's willing to contribute to Boost Multiprecision library in GSoC 2020. Please help me where to start from. Even in the code base from where should I start it. I am very much interested in taking Multiprecision as a project. Please help me start. Thank you. Tarun Lahrod Computer Science and Engineering (CSE) Bharati Vidyapeeth's College of Engineering, New Delhi Linked In: www.linkedin.com/in/tarun-lahrod GitHub: github.com/tarunlahrod

2 1