- Boost - lists.boost.org

Re: [boost] Boost::Regex support with ICU for unicode characters.
by John Maddock 30 Apr '23

30 Apr '23

> We are working with boost::regex library to have unicode support. I want to > form a regex for validating unicode characters so I'm trying this with > boost library. > > I am facing an issue with a boost library with ICU support so > please suggest me how to proceed with the boost with ICU support. PFA for > this. > > > 1. *has_icu_builds* is used to enable icu support. > [image: image.png] > > 2. on *b2 install* no icu is there, please let me know the procedure of how > to enable icu. > [image: image.png] ICU is an external dependency, we don't install it: it should already be installed prior to building Boost. Further, if you are using one of the last couple of Boost releases, then Regex is a header only library, and there is no need to build and install anything. You will however, have to link to ICU when you build your program. With regard to not matching specific text, if you can post the actual test code, I'll look at it. John.

1 0

Re: [boost] Boost CI - a modest proposal
by Vinnie Falco 30 Apr '23

30 Apr '23

On Sun, Apr 30, 2023 at 8:44 AM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > I would suggest we throw the whole thing out No

1 0

std vs boost
by Robert Ramey 30 Apr '23

30 Apr '23

When I'm writing library or user code, I often reach for a library component. Often, the similar/equivalent component exists in both the standard library component and the comparable boost component. I'm never confident about which to choose. Ideally I'd like a simple rule like "if you can choose between two components - prefer the standard library one (or Boost one) because ...". Is it possible to craft such a rule? My main criteria is mainly stability - once I've got something working I hate to be surprised when some "upgrade" breaks my code. Or is no longer supported. In other words, I don't want (and cannot) baby sit the application/library forever. Anyone have thoughts on this? Robert Ramey

1 0

Boost CI - a modest proposal
by Robert Ramey 30 Apr '23

30 Apr '23

the implementation of Boost CI follows the normal pattern for the implementation of this functionality. This entails download the latest version of the library to be tested and it's dependencies (or maybe all of boost?) from the repo, Building everything from scratch, running all the tests and logging the output there of. This is done for each compiler / environment to be tested. Other than the raw console logs, there is no presentation of the tests results (e.g boost test matrix). This is extremely unsatisfactory. a) It's ridiculously resource intensive. Rebuilding everything all the time. b) takes forever unless one has many more servers than we have. c) builds/tests even with the most trivial check-in. like adding a period to a documentation page. I would suggest we throw the whole thing out and consider a different approach. This approach would be more along the lines of that used by CMake test server. Complete documentation of how CMake does it is described in the CMake documentation. Basically it works like this. I run my CMake tests locally. This means that tests are not run on a server, but on some users configuration. This spreads the load. This means I run a special CMake target which takes the latest results and posts them to a server. The results are not posted automatically - I have to ask for it so it only happens when I know that a change is not trivial. It also means that all configurations actually being used (and only those configurations) are tested and the results logged. The server can than be queried to produce a table of results by configuration, compiler, library, etc on demand. CMake people maintain a basic server where one can post his results. But it's query facility isn't really complete enough for boost needs. This facility would need to be upgraded to boost requirements. Actually we have several application which might serve as a starting point: my library_status app which I use to produce a table of results and the app which produces the boost library test matrix. All in all this would produce a system which would actually be useful. Robert Ramey

1 0

Re: [boost] library usage statistics
by Peter Dimov 30 Apr '23

30 Apr '23

Robert Ramey wrote: > The basic question that occurs to me is "is this library worth maintaining and > keeping in boost". If dropping the library would break a lot of users code, > then the answer is an easy yes. If dropping the library would result in breaking > no code - the answer is an easy no. > Otherwise it's a judgement call we can argue about. But in order to do this we > need to know the answer the question: "How much code would be broken if > not in Boost. Hopefully this sheds light on this. There's probably a way to answer the question "how many Debian (Ubuntu, Fedora...) packages would be broken if we remove library X from Boost", but I don't know what it is.

1 0

Re: [boost] CI Test time
by Robert Ramey 30 Apr '23

30 Apr '23

On 4/29/23 4:13 PM, Andrey Semashev via Boost wrote: > On 4/29/23 23:45, Robert Ramey via Boost wrote: >> Looks like the CI for the serialization library takes about 200 minutes >> to run (on a good day). When I run it on my local desktop for one >> compiler/configuration it takes 1-2 minutes. It seems to me that the >> way that CI works, it entails a huge waste resources and time. Has >> anyone thought about this? > > If you know where most overhead is coming from, you can work towards > reducing that overhead. For example, you can save time wasted on > environment setup and git checkout if you run tests for different > configurations in one CI job. > > If you want more specific comments then you probably have to provide > more details on your problem. Actually I have made very specific observations regarding the issue. I didn't receive any useful feedback. When I thinking about it's pretty easy to see why - the CI concept as implemented in boost is irretrievably broken. Robert Ramey

1 0

Re: [boost] library usage statistics
by Robert Ramey 30 Apr '23

30 Apr '23

On 4/29/23 3:23 PM, René Ferdinand Rivera Morell via Boost wrote: > On Sat, Apr 29, 2023 at 3:42 PM Robert Ramey via Boost > <boost(a)lists.boost.org> wrote: >> >> Looking at the discussion regarding multi-array, I'm thinking I'd like >> to know how many people/projects are using the current version. > > Define "using", as precisely as you can. Then, maybe, we can figure > out how to measure. > > Good question - I havn't really thought about it enough yet. This is mainly because I haven't figured out how to do it. The basic question that occurs to me is "is this library worth maintaining and keeping in boost". If dropping the library would break a lot of users code, then the answer is an easy yes. If dropping the library would result in breaking no code - the answer is an easy no. Otherwise it's a judgement call we can argue about. But in order to do this we need to know the answer the question: "How much code would be broken if not in Boost. Hopefully this sheds light on this. Robert Ramey

1 0

Re: [boost] Boost.Compat
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 15:18, Peter Dimov via Boost wrote: > Andrey Semashev wrote: >> On 4/30/23 02:18, Peter Dimov via Boost wrote: >>> Andrey Semashev wrote: >>>> And lastly. I realize that the proposed Boost.Compat is supposed to >>>> contain direct equivalents of the standard components. But what if we >>>> want to improve on that? Would this be not allowed simply because >>>> this would deviate from the standard? >>> >>> No, it wouldn't be allowed. Improving upon the standard makes it >>> impossible to later replace the compatibility header with a using >>> declaration. We have such a problem today with e.g. Boost.Ratio and >>> Boost.Chrono, where because of extensions we can't simply make them be >> <ratio> and <chrono>. >>> >>> It's fine to want to improve upon the standard, but Compat will not be >>> the place for that. That's what dedicated libraries are for. >> >> This would mean more code duplication, wouldn't it? > > It's a tradeoff as any other. You need <latch>. Since it's trivial to implement > over C++11, you add a private implementation to your library. This duplicates > the one in Boost.Thread. But you don't want to depend on Boost.Thread, > because if you don't need C++03 support or thread interruption, it duplicates > the standard library, and adds 50 dependencies. > > https://pdimov.github.io/boostdep-report/boost-1.82.0/module-weights.html#w… It doesn't really matter how many dependencies Boost.Thread adds. What matters is how expensive <boost/thread/latch.hpp> is. Personally, I would have no problem depending on it, if I really needed this component. > In addition, the code duplication in Compat will gradually disappear as its > minimum C++ standard level is raised. E.g. shared_mutex.hpp (assuming > we have it) will effectively disappear at 14. latch.hpp will disappear at 20. This will happen when? I don't imagine Boost is raising its minimum C++ version to C++14, let alone 20 any time soon. > We can't clean up Boost.Thread in this manner even if we impose a C++11 > requirement, since it has to provide its own primitives for everything > because of thread interruption. > > But you know this because that's what the Sync intro says. :-) Regarding thread interruption, we could simply deprecate it and remove over time. I think, that was one of the ideas behind Boost.Sync - e.g. boost::mutex from Boost.Thread would get deprecated in favor of boost::sync::mutex from Boost.Sync. It might not be too late to revive Boost.Sync and add a latch implementation there.

1 0

Re: [boost] Boost.Compat
by Peter Dimov 30 Apr '23

30 Apr '23

Andrey Semashev wrote: > On 4/30/23 02:18, Peter Dimov via Boost wrote: > > Andrey Semashev wrote: > >> And lastly. I realize that the proposed Boost.Compat is supposed to > >> contain direct equivalents of the standard components. But what if we > >> want to improve on that? Would this be not allowed simply because > >> this would deviate from the standard? > > > > No, it wouldn't be allowed. Improving upon the standard makes it > > impossible to later replace the compatibility header with a using > > declaration. We have such a problem today with e.g. Boost.Ratio and > > Boost.Chrono, where because of extensions we can't simply make them be > <ratio> and <chrono>. > > > > It's fine to want to improve upon the standard, but Compat will not be > > the place for that. That's what dedicated libraries are for. > > This would mean more code duplication, wouldn't it? It's a tradeoff as any other. You need <latch>. Since it's trivial to implement over C++11, you add a private implementation to your library. This duplicates the one in Boost.Thread. But you don't want to depend on Boost.Thread, because if you don't need C++03 support or thread interruption, it duplicates the standard library, and adds 50 dependencies. https://pdimov.github.io/boostdep-report/boost-1.82.0/module-weights.html#w… In addition, the code duplication in Compat will gradually disappear as its minimum C++ standard level is raised. E.g. shared_mutex.hpp (assuming we have it) will effectively disappear at 14. latch.hpp will disappear at 20. We can't clean up Boost.Thread in this manner even if we impose a C++11 requirement, since it has to provide its own primitives for everything because of thread interruption. But you know this because that's what the Sync intro says. :-)

1 0

Re: [boost] Boost.Compat
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 14:58, Peter Dimov via Boost wrote: > Andrey Semashev wrote: >> I didn't say anything against refactoring, in fact I'm arguing that we should >> maintain our existing libraries (which includes refactoring) rather than add >> new libraries with duplicate components. > > You did create the (stillborn) Sync though, which duplicates Thread. Why? It doesn't fully duplicate Boost.Thread. It added new synchronization primitives and added support for different timing libraries besides Boost.Chrono. There was another idea that Boost.Thread became too large and difficult to maintain. So the thread synchronization primitives were supposed to be extracted to a separate library, Boost.Sync, leaving only thread launching and high-level tools like future/promise, async and thread pool in Boost.Thread.

1 0