May 2022 - Boost - lists.boost.org

Re: [boost] Review of Boost.MySql
by Ruben Perez 12 May '22

12 May '22

> Indeed. But even your imagined batch interface only works well for > queries/selects, > while for inserts (or updates), the client does not need to just send > a small textual > SQL query, but potentially a bunch of data for the rows too. A true > pipeline allows > sending the rows for a second insert while the first insert is being processed. It would work for inserts too, as values are either part of the query string or part of the statement execute packet. In both cases, part of the request. > Such a mode may be useful for schema creation OTOH. We have large schemas, > with hundreds of tables, indexes, triggers, etc... Done from C++ code > client-side, > not via a DBA manually executing on the server using SQL files and the > native CLI. > For that use-case, the ability to send many DDLs in a single batch > would definitely > save on the round-trips to the server. We try hard to minimize roundtrips! Thanks for sharing this use case, I definitely wasn't aware of it and seems a reason towards implementing multi-statement. > You don't need to necessarily use Google's protobufs library. > There's https://github.com/mapbox/protozero for example, and similarly, a > from-scratch implementation to just encode-decode a specific protocol > can also be written. I wasn't aware of this.Thanks. > > The server sends several resultsets after that. I haven't focused a lot on > > this because it sounded risky (in terms of security) for me. > > Not sure what's risky here. Maybe I'm missing something. I was just imagining users concatenating queries. May be a misconception, yours is a legitimate use case. > Note that PostgreSQL's COPY is not file-specific, and a first-class citizen > at the protocol level, depending on a pure binary format (with text mode too). > I use COPY with STDIN / STDOUT "files", i.e. I prepare memory buffers and > send them; and read memory buffers, and decode them. No files involved. Unfortunately, that does not seem to be the case for MySQL. You issue the LOAD DATA statement via a regular query packet, and the server returns you another packet with the file path it wants. You then read it in the client and send it to the server in another packet. I've made it work with CSV files, and I'd say it's the only format allowed, AFAIK. > Maybe our use-case of very large data (with large blobs), *and* very > numerous smaller data, > that's often loaded en-masse, by scientific desktop applications, and > increasingly mid-tier services > for web-apps, is different from the more common ecommerce web-app > use-case of many people. It is good to hear different use cases than the regular web server we all have in mind. It will help me during further development. > > When I evaluate DB performance, I tend to concentrate on "IO" performance, > in terms of throughput and latency, independent of the speed of the > SQL engine itself. > There's nothing I can do about the latter, while the way one uses the Client API > (or underlying protocol features) is under my control. So I do mostly > INSERTs and > SELECTs, with and without WHERE clauses (no complex JOINs, CTEs, etc...). > > Because we are in the scientific space, we care about both many small rows > (millions, of a few bytes to KBs each at most), and a few (hundreds / thousands) > much larger rows with blobs (with MBs to GBs sizes). The truly large > "blobs" (files) are > kept outside the DB, since mostly read only (in the GBs to TBs sizes each, that > can accumulate to 2.6 PB for all a client's data I heard just > yesterday for example). > > I'll also compare inserting rows 1-by-1, with and without prepared statements, > to inserting multi-rows per-statement (10, 100, 1000 at a time), to the "bulk" > interface (COPY for PostgreSQL, LOCAL for MySQL, Direct-Path load in OCI). > For example with SQLite: > https://sqlite.org/forum/forumpost/baf9c444d9a38ca6e59452c1c568044aaad50bba… > (SQLite as no "bulk" interface, doesn't need one, since "embedded" > thus "zero-latency") > > For PostgreSQL, we also compared text vs binary modes (for binds and > resultsets). > > For blobs, throughput of reading and writing large blobs, whole and in-part, > with different access patterns, like continuous ranges, or scattered inside). > > A very important use-case for us, for minimizing round-trips, is how > to load a subset of rows, > given a list of primary keys (typically a surrogate key, like an > integer or a uuid). For that, > we bind a single array-typed value for the WHERE clause's placeholder > to the query, > and read the resultset, selecting 1%, 5%, 10%, etc... of the rows from > the whole table. > (selecting each row individually, even with a prepared query, is terribly slow). Thanks for sharing. It will definitely help me during benchmarking. Regards, Ruben.

1 0

Mixing C++ language versions
by Kenneth Porter 12 May '22

12 May '22

Can one mix compilation units or libraries built with different versions of C++? If I build my DLL with C++20, can a customer use it with their C++11 app? How are compiler and library vendors dealing with this? Do/will they supply multiple binaries for each C++ version? (I'm already building for each architecture plus release/debug. Adding the compiler version explodes the number of binaries to build and test.)

3 3

Re: [boost] Mixing C++ language versions
by Glen Fernandes 12 May '22

12 May '22

On Thu, May 12, 2022 at 6:52 AM Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > > Do/will they supply multiple binaries for each C++ version? (I'm already building for > each architecture plus release/debug. Adding the compiler version explodes > the number of binaries to build and test.) The variants you have so far are: - Architecture - Release or Debug I've known library vendors to even have the following variants: - Architecture - Release or Debug - C++ standard version - Static or dynamic linking with the C++ runtime library - Single or multi threaded versions of the C++ runtime library (at one point in time) Shipping library sources to your users (instead of binaries) might be easier. Glen

1 0

[filesystem] create_directories fails on exFat formatted disk under Windows
by Chris Trueman 12 May '22

12 May '22

Using an exFat formatted disk with Windows. Start with a path: e:\tmp Call filesystem::create_directories("e:\\tmp\\boost") This should succeed, creating the boost folder in e:\tmp. It fails with boost 1.79.0. It tries to create e:\tmp which already exists. In boost 1.78.0 this works as expected. I believe the root cause is the change to status(...). It calls detail::symlink_status(...) which calls GetFileInformationByHandleEx which (at least for the params used in filesystem) doesn't work on exFat formatted disks. Chris.

2 2

SOCKS-Asio library
by Alan de Freitas 11 May '22

11 May '22

Hi, everyone! I've been writing this library for SOCKS4/5 based on Asio. The library is very embryonic but there's enough to connect to proxy servers and relay messages. I could really use some negative feedback. If anyone would like to give it a try, here are the links: Repo: https://github.com/alandefreitas/socks_proto Docs: https://develop.socks-proto.cpp.al/ #boost-socks on Slack Thanks! -- Alan Freitas https://github.com/alandefreitas

2 1

Re: [boost] Boost Digest, Vol 6699, Issue 1
by Benedict Bede McNamara 08 May '22

08 May '22

You need modules urgently. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Sunday, 8 May 2022 10:00 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6699, Issue 1 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Seth) 2. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Christopher Kormanyos) 3. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Bo Persson) ---------------------------------------------------------------------- Message: 1 Date: Sat, 07 May 2022 15:30:08 +0200 From: Seth <bugs(a)sehe.nl> To: "Boost List" <boost(a)lists.boost.org> Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <e76334c1-625a-4ee2-999f-75959822562b(a)www.fastmail.com> Content-Type: text/plain > Even though 14 has lotsof bug fixes, > the only real key advanced featureis relaxed constexpr constraints > anddigit separators. I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs) ------------------------------ Message: 2 Date: Sun, 8 May 2022 09:31:19 +0000 (UTC) From: Christopher Kormanyos <e_float(a)yahoo.com> To: Boost List <boost(a)lists.boost.org> Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <1679327021.415697.1652002279472(a)mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 >> Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. I apologize for my perhaps unwisely chosen(or even wrong) wording. > I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. ... And I do respect this comment. But I'm not quite ready to give upon eleven just yet... Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view. Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11. To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11. So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support? One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option. Kind regards, Chris On Saturday, May 7, 2022, 03:36:26 PM GMT+2, Seth via Boost <boost(a)lists.boost.org> wrote: > Even though 14 has lotsof bug fixes, > the only real key advanced featureis relaxed constexpr constraints > anddigit separators. I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ Message: 3 Date: Sun, 8 May 2022 12:37:00 +0200 From: Bo Persson <bo(a)bo-persson.se> To: boost(a)lists.boost.org Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <t586gu$cfq$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-05-08 at 11:31, Christopher Kormanyos via Boost wrote: > >> Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. > I apologize for my perhaps unwisely chosen(or even wrong) wording. > >> I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. > ... And I do respect this comment. > But I'm not quite ready to give upon eleven just yet... > > Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view. > Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11. > To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11. > So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support? It can also be argued that we might do some clients a disservice instead of a service. If the new features are *that* useful for the library authors, would they not be equally useful for the clients' code? By supporting old compilers and standards we let them procrastinate for another couple of years. Is that good? Or should we encourage them to move on? Perhaps a gentle push is all they need? "New and improved" is often used in product-marketing. Why not here? > One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option. > > Kind regards, Chris > > ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6699, Issue 1 **************************************

2 1

Copy_File Method Question
by Sean B 06 May '22

06 May '22

Good afternoon, Thank you for allowing me to join the group as I a newbie to the boost c++ libraries. My question I have to the development group is based on the copy_file method. Does the copy_file do a 'bit to bit' copy using (check sums and hash) or the original file? Thanks for any information on this.

2 1

C++ package managers
by Adam Getchell 06 May '22

06 May '22

For what it’s worth, having tried Biicode (Conan’s predecessor), Conan, Spack, Conda, and vcpkg, vcpkg is the only package manager for which I’ve been able to consistently (i.e. since I started using it a few years ago) build combinations of {macOS, Linux, Windows } x { gcc, clang, msvc}. As my research project includes CGAL which includes Boost, Eigen, and TBB, that ends up being 100+ libraries. Manifest mode just works, and vcpkg artifacts looks promising: https://devblogs.microsoft.com/cppblog/vcpkg-artifacts/ -- Adam Getchell acgetchell(a)ucdavis.edu https://adamgetchell.org

2 2