December 2022 - Boost - lists.preview.boost.org

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

Re: [boost] Revitalization
by William Linkmeyer 07 Dec '22

07 Dec '22

For bringing up new talent, I agree with Niall. For Boost’s usage, I maintain that new libraries in the hardware space are useful — audio, visual, libraries. No great ones exist. For C++ as a whole, I’m not sure I would recommend this language to newcomers until we break ABI and more of the cppfront syntax & safety is introduced. Our hashing and regex performance is embarrassing. Our syntax is cluttered. We can and should solve those problems. WL > On Dec 6, 2022, at 6:44 PM, Gavin Lambert via Boost <boost(a)lists.boost.org> wrote: > > On 7/12/2022 10:42, Robert Ramey wrote: >> c) use the boost tool (I forget the name) to scan my code and list the required source modules >> d) include those source files in my b2 or CMake file. > > These steps are atypical. Most users will run b2 to build binaries (static or dynamic) and then link with these, or will use the prebuilt bintray or whatever binaries, or the prebuilt Linux distro binaries. > > While it's possible to import individual .cpp files, that's never the encouraged method to depend on any C++ libraries, Boost or otherwise. > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

boost::streambuf default size/capacity still set to 128 in spite of size provided in constructor.
by Aniket Pugaonkar 05 Dec '22

05 Dec '22

Hello, I was checking the implementation of boost streambuf and noticed that buffer_delta value is defaulted to 128, which results in the capacity of the container to 128 bytes by default, and based on that, there is no way to change it even if we provide max size as some custom number (say 1500 for receiving a packet on socket). The initial allocation (buffer_.resize is done with 128. But when we call *buf.prepare(1500)*, it again results in resize(n) operation (through reserve(n) function call. Is there any other way to change this other than modifying the constructor in our codebase to provide a user defined value of buffer_delta Not sure if this needs to be enhanced. the maximum_size argument seems to be of no use in this case... Kindly advise. Regards Aniket. /// Construct a basic_streambuf object. /** * Constructs a streambuf with the specified maximum size. The initial size * of the streambuf's input sequence is 0. */ explicit basic_streambuf( std::size_t maximum_size = (std::numeric_limits<std::size_t>::max)(), const Allocator& allocator = Allocator()) : max_size_(maximum_size), buffer_(allocator) { *std::size_t pend = (std::min<std::size_t>)(max_size_, buffer_delta);* *buffer_.resize((std::max<std::size_t>)(pend, 1));* setg(&buffer_[0], &buffer_[0], &buffer_[0]); setp(&buffer_[0], &buffer_[0] + pend); } -- Thanks and regards, Aniket Pugaonkar

1 0