What I've noticed with modules (trying with MSVC) is that they are
ncredibly sensitive to compiler settings. I don't see MS (other
vendors too, for that matter) saying "these are the settings that will
be used, despite our tools offering much more". And I also have a
difficult time seeing modules losing that sensitivity, it would
basically require that the module contain the original
pre-preprocessed source. Or shipping an awkward - and growing - number
of module files.
For the time being I see modules as a nice idea that still needs lots
of work. Plus, there are things that can be done with includes that as
far as I'm aware modules simply don't support (Boost.Preprocessor's
iteration facility as an example).
Bjarne Stroustup’s comments were to the effect that we should write programs that
do not rely upon the pre-processor. Boost’s pre-processor iteration facility will have to
be rewritten or dropped. I assume that you are going to use modules eventually or be left
behind. If you choose not to use modules, then I will incorporate and rename Boost in my
own module.
Sent from Mail for Windows
From: boost-request@lists.boost.org
Sent: Saturday, 14 May 2022 6:58 PM
To: boost@lists.boost.org
Subject: Boost Digest, Vol 6705, Issue 1
Send Boost mailing list submissions to
boost@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@lists.boost.org
You can reach the person managing the list at
boost-owner@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: cstring_view (Marshall Clow)
2. Re: The Future of C++ and Boost - C++ Modules (Soronel Haetir)
3. The Future of C++ Modules (Benedict Bede McNamara)
4. Re: cstring_view (Klemens Morgenstern)
5. Re: cstring_view (Rainer Deyke)
6. Re: The Future of C++ and Boost - C++ Modules (Mike)
7. Re: cstring_view (Daniela Engert)
8. Re: cstring_view (Klemens Morgenstern)
9. Boost MySQL Review Is In Progress (Richard Hodges)
----------------------------------------------------------------------
Message: 1
Date: Fri, 13 May 2022 15:42:59 -0700
From: Marshall Clow
To: boost@lists.boost.org
Subject: Re: [boost] cstring_view
Message-ID:
Content-Type: text/plain; charset=utf-8
On May 13, 2022, at 3:19 PM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
wrote:
On 13.05.22 20:39, Marshall Clow via Boost wrote:
On May 13, 2022, at 11:18 AM, Peter Dimov via Boost
wrote:
In what scenarios will it not give you a null-terminated string?
char arr[6] = ?hello";
cstring_view csv(arr);
assert(strlen(csv.data())) == 5);
arr[5] = ?!?;
assert(strlen(csv.data())) == 5); // boom ? Marshall PS. It
promises to give you a null-terminated string, but has no way to actually
guarantee that.
That's an issue with views in general, not just cstring_view.
std::string s = "hello";
string_view sv = s;
assert(sv.size() == 5);
s += "!";
assert(sv.size() == 5); // boom
I don?t see the problem here (and when I run the code I get no error - after
adding the missing ?std::').
No assertion failure; no undefined behavior (unlike the cstring_view example)
Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates,
`sv` would be left dangling.
Agreed.
But even if the string *did* reallocate, the call "assert(sv.size() == 5)? is still valid and well defined.
In the cstring_view example I wrote, there are no allocations (it?s a static buffer), and the call exhibits undefined behavior (as well as the assertion failure).
The whole point of cstring_view is ?I have a sequence of N characters here, and I *swear* that then n+1st one is a NUL?
? Marshall
P. S. Std::string has the same behavior (which I really dislike), but at least it owns the storage, so it can enforce the presence of the NUL.
------------------------------
Message: 2
Date: Fri, 13 May 2022 12:43:31 -0800
From: Soronel Haetir
To: boost@lists.boost.org
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID:
Content-Type: text/plain; charset="UTF-8"
What I've noticed with modules (trying with MSVC) is that they are
incredibly sensitive to compiler settings. I don't see MS (other
vendors too, for that matter) saying "these are the settings that will
be used, despite our tools offering much more". And I also have a
difficult time seeing modules losing that sensitivity, it would
basically require that the module contain the original
pre-preprocessed source. Or shipping an awkward - and growing - number
of module files.
For the time being I see modules as a nice idea that still needs lots
of work. Plus, there are things that can be done with includes that as
far as I'm aware modules simply don't support (Boost.Preprocessor's
iteration facility as an example).
On 5/13/22, John Maddock via Boost wrote:
If they ever are.
Modules can work for leaf libraries, but for libraries used as
dependencies
by other libraries, you'll encounter a situation where the same
translation
unit imports boost.lib or "boost/lib.hpp" in one place and then includes
"boost/lib/something.hpp" in another, which is probably never going to
work correctly.
I suppose it might stand a chance if all the imports are done first, so
that
the include guard macros are defined. But I think that's not going to work
in practice either.
Basically, all Regex consumers also must respect the REGEX_AS_MODULE
macro and switch to `import boost.regex`. Repeat per every library.
Modules don't expose macros, so there is no way to signal "this must be
used as a module", so you have to find every usage of library X and make
sure they are either all modules or all includes.? Or at least that
anything included doesn't use import: the other way around is fine since
the include is hidden within the module.
John.
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
--
Soronel Haetir
soronel.haetir@gmail.com
------------------------------
Message: 3
Date: Sat, 14 May 2022 08:45:53 +1000
From: Benedict Bede McNamara
To: "boost@lists.boost.org"
Subject: [boost] The Future of C++ Modules
Message-ID: <1652481962361.5bcfb010425513a2@gigasopht.net>
Content-Type: text/plain; charset="utf-8"
On 5/13/22 5:24 AM, Peter Dimov via Boost wrote:
John Maddock wrote:
I'm afraid my conclusion is that modules are simply not yet ready for
prime time.
If they ever are.
Modules can work for leaf libraries, but for libraries used as dependencies
by other libraries, you'll encounter a situation where the same translation
unit imports boost.lib or "boost/lib.hpp" in one place and then includes
"boost/lib/something.hpp" in another, which is probably never going to
work correctly.
This is sounds like how I thought it had to work to be effective. If I
understand this correctly, the whole modules concept is in fundamental
conflict with the anything which uses the boost inclusion/dependency
model - which is every module includes what it uses and nothing else.
In my view the whole modules idea is misconceived. One more nail in
coffin of C++ xx standard libraries.
It's time for use to seriously start moving on.
Robert Ramey
You can?t be serious. I have used modules in I++ and they function perfectly. C++ was kind of dodgy with its
use of the pre-processor. Modules re-establish C++ as being the predominant language of its time.
It is C++ that ?has moved on? from where Boost is at present. Boost is running at least 2 years behind the standard and
It risks becoming irrelevant if it remains there for much longer.
Sent from Mail for Windows
From: boost-request@lists.boost.org
Sent: Saturday, 14 May 2022 8:19 AM
To: boost@lists.boost.org
Subject: Boost Digest, Vol 6704, Issue 5
Send Boost mailing list submissions to
boost@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@lists.boost.org
You can reach the person managing the list at
boost-owner@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: cstring_view (Peter Dimov)
2. Re: cstring_view (Marshall Clow)
3. Re: cstring_view (Peter Dimov)
4. Re: cstring_view (Marshall Clow)
5. Re: cstring_view (Peter Dimov)
6. Re: cstring_view (Rainer Deyke)
7. Re: cstring_view (David Bien)
8. Re: MySql review (Rainer Deyke)
9. Re: The Future of C++ and Boost - C++ Modules (Robert Ramey)
10. Re: The Future of C++ and Boost - C++ Modules (Peter Dimov)
11. Re: cstring_view (Marshall Clow)
12. Re: cstring_view (Peter Dimov)
----------------------------------------------------------------------
Message: 1
Date: Fri, 13 May 2022 21:09:47 +0300
From: "Peter Dimov"
To:
Subject: Re: [boost] cstring_view
Message-ID: <01d201d866f4$a330d710$e9928530$@gmail.com>
Content-Type: text/plain; charset="utf-8"
David Bien wrote:
I guess when I read the impl I think to myself: What this is missing is a _length
member. But then it just becomes boost::string_view.
What value added is there to this impl except that it is smaller than
boost::string_view due to lacking a _length member?
Please see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf
No idea why this particular implementation doesn't store the size. I would.
------------------------------
Message: 2
Date: Fri, 13 May 2022 11:14:13 -0700
From: Marshall Clow
To: Boost Developers List
Subject: Re: [boost] cstring_view
Message-ID:
Content-Type: text/plain; charset=utf-8
On May 13, 2022, at 10:42 AM, David Bien via Boost wrote:
I guess when I read the impl I think to myself: What this is missing is a _length member. But then it just becomes boost::string_view.
What value added is there to this impl except that it is smaller than boost::string_view due to lacking a _length member?
If you?re careful and don?t do much with it, it can hand you back a null terminated string.
? Marshall
PS. I note that P1402 (the paper proposing cstring_view for the standard) was was reviewed by LEWG in 2019, and the resolution of that group was "We will not pursue P1402R0 or this problem space?
------------------------------
Message: 3
Date: Fri, 13 May 2022 21:18:24 +0300
From: "Peter Dimov"
To:
Subject: Re: [boost] cstring_view
Message-ID: <01d301d866f5$d6cfe880$846fb980$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Marshall Clow wrote:
On May 13, 2022, at 10:42 AM, David Bien via Boost
wrote:
I guess when I read the impl I think to myself: What this is missing is a
_length member. But then it just becomes boost::string_view.
What value added is there to this impl except that it is smaller than
boost::string_view due to lacking a _length member?
If you?re careful and don?t do much with it, it can hand you back a null
terminated string.
???
In what scenarios will it not give you a null-terminated string?
------------------------------
Message: 4
Date: Fri, 13 May 2022 11:39:37 -0700
From: Marshall Clow
To: Peter Dimov
Cc: Boost Developers List
Subject: Re: [boost] cstring_view
Message-ID:
Content-Type: text/plain; charset=utf-8
On May 13, 2022, at 11:18 AM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
On May 13, 2022, at 10:42 AM, David Bien via Boost
wrote:
I guess when I read the impl I think to myself: What this is missing is a
_length member. But then it just becomes boost::string_view.
What value added is there to this impl except that it is smaller than
boost::string_view due to lacking a _length member?
If you?re careful and don?t do much with it, it can hand you back a null
terminated string.
???
In what scenarios will it not give you a null-terminated string?
char arr[6] = ?hello";
cstring_view csv(arr);
assert(strlen(csv.data())) == 5);
arr[5] = ?!?;
assert(strlen(csv.data())) == 5); // boom
? Marshall
PS. It promises to give you a null-terminated string, but has no way to actually guarantee that.
------------------------------
Message: 5
Date: Fri, 13 May 2022 21:57:39 +0300
From: "Peter Dimov"
To: "'Marshall Clow'"
Cc: "'Boost Developers List'"
Subject: Re: [boost] cstring_view
Message-ID: <01df01d866fb$52ff30f0$f8fd92d0$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Marshall Clow wrote:
If you?re careful and don?t do much with it, it can hand you back a
null terminated string.
???
In what scenarios will it not give you a null-terminated string?
char arr[6] = ?hello";
cstring_view csv(arr);
assert(strlen(csv.data())) == 5);
arr[5] = ?!?;
assert(strlen(csv.data())) == 5); // boom
The main use of cstring_view, like string_view, is as a parameter (and
return) type. So if you have a function
void f1( cstring_view csv );
it's true that if inside f1 you write to some random character this may
invalidate csv's promise to be null-terminated, but I see little salient
difference between this and
void f2( char const* csv ); // pre: csv is null-terminated char seq
where f2 writing to a carefully chosen char may also invalidate
the precondition.
Typing "cstring_view" is merely a different way of spelling out the
"pre" of f2.
Similarly,
cstring_view g1();
is an alternative way of spelling
char const* g2(); // post: the return value is a null-terminated char seq
------------------------------
Message: 6
Date: Fri, 13 May 2022 21:29:06 +0200
From: Rainer Deyke
To: boost@lists.boost.org
Subject: Re: [boost] cstring_view
Message-ID:
Content-Type: text/plain; charset=UTF-8; format=flowed
On 13.05.22 20:39, Marshall Clow via Boost wrote:
On May 13, 2022, at 11:18 AM, Peter Dimov via Boost wrote:
In what scenarios will it not give you a null-terminated string?
char arr[6] = ?hello";
cstring_view csv(arr);
assert(strlen(csv.data())) == 5);
arr[5] = ?!?;
assert(strlen(csv.data())) == 5); // boom
? Marshall
PS. It promises to give you a null-terminated string, but has no way to actually guarantee that.
That's an issue with views in general, not just cstring_view.
std::string s = "hello";
string_view sv = s;
assert(sv.size() == 5);
s += "!";
assert(sv.size() == 5); // boom
It is the responsibility of the creator of a view to ensure that the
object being viewed does not change in a way that breaks the invariants
of the view while the view is in use.
--
Rainer Deyke (rainerd@eldwood.com)
------------------------------
Message: 7
Date: Fri, 13 May 2022 18:20:40 +0000
From: David Bien
To: "boost@lists.boost.org"
Cc: Peter Dimov
Subject: Re: [boost] cstring_view
Message-ID:
Content-Type: text/plain; charset="Windows-1252"
Exactly. But then it should just be called cstring_wrapper ? calling it cstring_view seems to impart qualities to it that it doesn?t have ? like I would assume that I could get a cstring_view that is a subview of an existing cstring_view for instance.
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows
From: Peter Dimov via Boostmailto:boost@lists.boost.org
Sent: Friday, May 13, 2022 12:19 PM
To: boost@lists.boost.orgmailto:boost@lists.boost.org
Cc: Peter Dimovmailto:pdimov@gmail.com
Subject: Re: [boost] cstring_view
Marshall Clow wrote:
On May 13, 2022, at 10:42 AM, David Bien via Boost
wrote:
I guess when I read the impl I think to myself: What this is missing is a
_length member. But then it just becomes boost::string_view.
What value added is there to this impl except that it is smaller than
boost::string_view due to lacking a _length member?
If you?re careful and don?t do much with it, it can hand you back a null
terminated string.
???
In what scenarios will it not give you a null-terminated string?
_______________________________________________
Unsubscribe & other changes: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost...
------------------------------
Message: 8
Date: Fri, 13 May 2022 21:37:36 +0200
From: Rainer Deyke
To: boost@lists.boost.org
Subject: Re: [boost] MySql review
Message-ID:
Content-Type: text/plain; charset=UTF-8; format=flowed
On 13.05.22 17:23, Phil Endecott via Boost wrote:
The aim should be "secure by default". Users are lazy. The
particular danger in this case is that they do an initial test with
the password in the source, and then move it somewhere secure later,
but the password is still exposed in their revision control history.
At this point in history, there is no excuse to repeat the mistakes
that have lead to really very serious security problems in the past.
Make the default mechanism, and the first one that you describe in
the docs, the most secure one.
Looking for credentials in a file on disk may be more secure than
embedding the credentials in code, but it is most definitely the most
secure mechanism. The most secure mechanism is to always ask the user
at program start-up. Or better yet, ask each time a connection is
created, and then immediately wipe the credentials from RAM in order to
mitigate RAM scanning attacks.
--
Rainer Deyke (rainerd@eldwood.com)
------------------------------
Message: 9
Date: Fri, 13 May 2022 12:33:50 -0700
From: Robert Ramey
To: Peter Dimov via Boost
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID: <4134c080-20bb-16d2-ff81-0c6b6dc52d75@rrsd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 5/13/22 5:24 AM, Peter Dimov via Boost wrote:
John Maddock wrote:
I'm afraid my conclusion is that modules are simply not yet ready for
prime time.
If they ever are.
Modules can work for leaf libraries, but for libraries used as dependencies
by other libraries, you'll encounter a situation where the same translation
unit imports boost.lib or "boost/lib.hpp" in one place and then includes
"boost/lib/something.hpp" in another, which is probably never going to
work correctly.
This is sounds like how I thought it had to work to be effective. If I
understand this correctly, the whole modules concept is in fundamental
conflict with the anything which uses the boost inclusion/dependency
model - which is every module includes what it uses and nothing else.
In my view the whole modules idea is misconceived. One more nail in
coffin of C++ xx standard libraries.
It's time for use to seriously start moving on.
Robert Ramey
------------------------------
Message: 10
Date: Sat, 14 May 2022 00:16:26 +0300
From: "Peter Dimov"
To:
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID: <01f501d8670e$b57a64d0$206f2e70$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Robert Ramey wrote:
On 5/13/22 5:24 AM, Peter Dimov via Boost wrote:
John Maddock wrote:
I'm afraid my conclusion is that modules are simply not yet ready for
prime time.
If they ever are.
Modules can work for leaf libraries, but for libraries used as
dependencies by other libraries, you'll encounter a situation where
the same translation unit imports boost.lib or "boost/lib.hpp" in one
place and then includes "boost/lib/something.hpp" in another, which is
probably never going to work correctly.
This is sounds like how I thought it had to work to be effective. If I understand
this correctly, the whole modules concept is in fundamental conflict with the
anything which uses the boost inclusion/dependency model - which is every
module includes what it uses and nothing else.
In my view the whole modules idea is misconceived. One more nail in coffin of
C++ xx standard libraries.
It's time for use to seriously start moving on.
Looks like I was mistaken, though. At least with header units, i.e.
`import "boost/lib.hpp"`, it all seems to "just work" under MSVC. That is, the
compiler automatically merges the identical definitions from the sub-#includes.
------------------------------
Message: 11
Date: Fri, 13 May 2022 15:16:19 -0700
From: Marshall Clow
To: Boost Developers List
Cc: Rainer Deyke
Subject: Re: [boost] cstring_view
Message-ID: <3C70E2E0-DC7A-4263-9D93-FCD8220A39BE@gmail.com>
Content-Type: text/plain; charset=utf-8
On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost wrote:
On 13.05.22 20:39, Marshall Clow via Boost wrote:
On May 13, 2022, at 11:18 AM, Peter Dimov via Boost wrote:
In what scenarios will it not give you a null-terminated string?
char arr[6] = ?hello";
cstring_view csv(arr);
assert(strlen(csv.data())) == 5);
arr[5] = ?!?;
assert(strlen(csv.data())) == 5); // boom
? Marshall
PS. It promises to give you a null-terminated string, but has no way to actually guarantee that.
That's an issue with views in general, not just cstring_view.
std::string s = "hello";
string_view sv = s;
assert(sv.size() == 5);
s += "!";
assert(sv.size() == 5); // boom
I don?t see the problem here (and when I run the code I get no error - after adding the missing ?std::').
No assertion failure; no undefined behavior (unlike the cstring_view example)
? Marshall
------------------------------
Message: 12
Date: Sat, 14 May 2022 01:19:33 +0300
From: "Peter Dimov"
To:
Subject: Re: [boost] cstring_view
Message-ID: <01fc01d86717$873b2a60$95b17f20$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Marshall Clow wrote:
On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
wrote:
On 13.05.22 20:39, Marshall Clow via Boost wrote:
On May 13, 2022, at 11:18 AM, Peter Dimov via Boost
wrote:
In what scenarios will it not give you a null-terminated string?
char arr[6] = ?hello";
cstring_view csv(arr);
assert(strlen(csv.data())) == 5);
arr[5] = ?!?;
assert(strlen(csv.data())) == 5); // boom ? Marshall PS. It
promises to give you a null-terminated string, but has no way to actually
guarantee that.
That's an issue with views in general, not just cstring_view.
std::string s = "hello";
string_view sv = s;
assert(sv.size() == 5);
s += "!";
assert(sv.size() == 5); // boom
I don?t see the problem here (and when I run the code I get no error - after
adding the missing ?std::').
No assertion failure; no undefined behavior (unlike the cstring_view example)
Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates,
`sv` would be left dangling.
------------------------------
Subject: Digest Footer
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
End of Boost Digest, Vol 6704, Issue 5
**************************************
------------------------------
Message: 4
Date: Sat, 14 May 2022 10:43:09 +0800
From: Klemens Morgenstern
To: boost@lists.boost.org
Subject: Re: [boost] cstring_view
Message-ID: <7b7ece8b46b77ced2a9826a273c5df0ea36ca14a.camel@gmx.net>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2022-05-13 at 21:09 +0300, Peter Dimov via Boost wrote:
David Bien wrote:
I guess when I read the impl I think to myself: What this is
missing is a _length
member. But then it just becomes boost::string_view.
What value added is there to this impl except that it is smaller
than
boost::string_view due to lacking a _length member?
Please see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf
No idea why this particular implementation doesn't store the size. I
would.
I want to use it as a small wrapper around system-APIs, that can be
implicitly constructed from any matching string type, e.g.
boost::static_string as well as const char *. `strlen` would just be
unnecessary.
void set_env(cstring_view name, cstring_view value, error_code & ec)
{
auto e = ::setenv(name.c_str(), value.c_str());
if (!e)
ec = some_error;
}
Using strlen seems unnecessary to me. I also stripped out most of the
functions to just have a bare-bone view of a cstring in the PR I
submitted: https://github.com/boostorg/utility/pull/100
Basic idea being: provide whatever you can do on a null terminated
string, for anything more just use a string_view. I don't think there's
much utility to the cstring_view outside of interaction with C-APIs.
------------------------------
Message: 5
Date: Sat, 14 May 2022 09:45:23 +0200
From: Rainer Deyke
To: boost@lists.boost.org
Subject: Re: [boost] cstring_view
Message-ID:
Content-Type: text/plain; charset=UTF-8; format=flowed
On 14.05.22 00:42, Marshall Clow via Boost wrote:
On May 13, 2022, at 3:19 PM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
wrote:
That's an issue with views in general, not just cstring_view.
std::string s = "hello";
string_view sv = s;
assert(sv.size() == 5);
s += "!";
assert(sv.size() == 5); // boom
I don?t see the problem here (and when I run the code I get no error - after
adding the missing ?std::').
No assertion failure; no undefined behavior (unlike the cstring_view example)
Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates,
`sv` would be left dangling.
Agreed.
But even if the string *did* reallocate, the call "assert(sv.size() == 5)? is still valid and well defined.
No it's not. sv.size() works by subtracting pointers, and it's only
legal to subtract two pointers if they point into the same memory
region. Which sv.begin() and sv.end() no longer do if s reallocates.
It's subtle, but it's definitely undefined behavior.
--
Rainer Deyke (rainerd@eldwood.com)
------------------------------
Message: 6
Date: Sat, 14 May 2022 10:14:18 +0200
From: Mike
To: boost@lists.boost.org
Cc: mike.dev@gmx.de
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID:
Content-Type: text/plain; charset=UTF-8
Gesendet: Freitag, 13. Mai 2022 um 22:43 Uhr
Von: "Soronel Haetir via Boost"
What I've noticed with modules (trying with MSVC) is that they are
incredibly sensitive to compiler settings.
What do you mean by that?
Best
Mike
------------------------------
Message: 7
Date: Sat, 14 May 2022 10:31:20 +0200
From: Daniela Engert
To: boost@lists.boost.org
Subject: Re: [boost] cstring_view
Message-ID: <9bafc2cf-6bfe-ad96-7a5d-075e71e9aae3@ngrt.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 14.05.2022 um 09:45 schrieb Rainer Deyke via Boost:
On 14.05.22 00:42, Marshall Clow via Boost wrote:
On May 13, 2022, at 3:19 PM, Peter Dimov via Boost
wrote:
Marshall Clow wrote:
On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
wrote:
That's an issue with views in general, not just cstring_view.
std::string s = "hello";
string_view sv = s;
assert(sv.size() == 5);
s += "!";
assert(sv.size() == 5); // boom
I don?t see the problem here (and when I run the code I get no
error - after
adding the missing ?std::').
No assertion failure; no undefined behavior (unlike the
cstring_view example)
Only because "hello!" fits into the small buffer, I suspect. If `s`
reallocates,
`sv` would be left dangling.
Agreed.
But even if the string *did* reallocate, the call "assert(sv.size()
== 5)? is still valid and well defined.
No it's not.? sv.size() works by subtracting pointers, and it's only
legal to subtract two pointers if they point into the same memory
region.? Which sv.begin() and sv.end() no longer do if s reallocates.
It's subtle, but it's definitely undefined behavior.
Not really. The standard (in its current draft) is silent about the
invalidation of size() and talks only about iterators, references and
pointers with respect to the viewed object
[string.view.template.general]/2. On top of that, afaik all major
implementations have agreed on and settled on the same structure layout
as shown in the standard as exposition only. So technically, this is
unspecified.
Ciao
? Dani
--
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
------------------------------
Message: 8
Date: Sat, 14 May 2022 16:44:05 +0800
From: Klemens Morgenstern
To: boost@lists.boost.org
Subject: Re: [boost] cstring_view
Message-ID:
Content-Type: text/plain; charset="UTF-8"
On Fri, 2022-05-13 at 18:20 +0000, David Bien via Boost wrote:
Exactly. But then it should just be called cstring_wrapper ? calling
it cstring_view seems to impart qualities to it that it doesn?t have
? like I would assume that I could get a cstring_view that is a
subview of an existing cstring_view for instance.
That's a fair point, I was thinking about naming it cstring_ref
originally. The Paper reference by Peter made me reconsider.
With cstring_ref, someone else could write a cstring_view that also
contains the size.
Do however note that you can get that subview if the result is still a
cstring. Thus obly moving the start of the cstring works.
------------------------------
Message: 9
Date: Sat, 14 May 2022 10:58:29 +0200
From: Richard Hodges
To: "boost@lists.boost.org List" ,
boost-announce@lists.boost.org
Subject: [boost] Boost MySQL Review Is In Progress
Message-ID:
Content-Type: text/plain; charset="UTF-8"
Dear All,
We've had a good response for calls to review this much anticipated
library, and there is a lot of interest on Reddit:
https://www.reddit.com/r/cpp/comments/unik91/acceptance_review_for_boostmysq...
.
In general the public perception of utility libraries like this in Boost
seems popular, and Boost's emphasis on quality is often mentioned.
If you are able, I would be more than grateful if you could take a few
hours over this delightful weekend to offer a review. The more eyes on this
project the better, as if it is successful, it will no doubt prompt
submission of similar libraries targeting other popular database and
messaging systems.
The Boost formal review of the MySQL library started on May 10th, 2022 and
will conclude on May 19th, 2022 (inclusive) - In fact, I am able to accept
submissions up until the (GMT) morning of May 20th as I'll be traveling on
May19th.
The library is authored by Rub?n P?rez Hidalgo (@anarthal in the CppLang
slack).
Documentation: https://anarthal.github.io/mysql/index.html
Source: https://github.com/anarthal/mysql/
The library is built on the bedrock of Boost.Asio and provides both
synchronous and asynchronous client connectors for the MySQL database
system.
Boost.MySQL is written from the ground up, implementing the entire protocol
with no external dependencies beyond the Boost library.
It is compatible with MariaDB.
Connectivity options include TCP, SSL and Unix Sockets.
For async interfaces, examples in the documentation demonstrate full
compatibility with all Asio completion handler styles, including:
Callbacks:-
https://anarthal.github.io/mysql/mysql/examples/query_async_callbacks.html
Futures :-
https://anarthal.github.io/mysql/mysql/examples/query_async_futures.html
Boost.Coroutine :-
https://anarthal.github.io/mysql/mysql/examples/query_async_coroutines.html
C++20 Coroutines :-
https://anarthal.github.io/mysql/mysql/examples/query_async_coroutinescpp20....
Rub?n has also implemented the Asio protocols for deducing default
completion token types :-
https://anarthal.github.io/mysql/mysql/examples/default_completion_tokens.ht...
Reviewing a database connector in depth will require setting up an instance
of a MySQL database. Fortunately most (all?) Linux distributions carry a
MySQL and/or MariaDB package. MySQL community edition is available for
download on all platforms here:
https://dev.mysql.com/downloads/
Rub?n has spent quite some time in order to bring us this library
candidate. The development process has no doubt been a journey of discovery
into Asio, its concepts and inner workings. I am sure he has become a fount
of knowledge along the way.
From a personal perspective, I was very happy to be asked to manage this
review. I hope it will be the first of many more reviews of libraries that
tackle business connectivity problems without further dependencies beyond
Boost, arguably one of the most trusted foundation libraries available.
Please provide in your review information you think is valuable to
understand your choice to ACCEPT or REJECT including Describe as a
Boost library. Please be explicit about your decision (ACCEPT or REJECT).
Some other questions you might want to consider answering:
- Will the library bring additional out-of-the-box utility to Boost?
- What is your evaluation of the implementation?
- What is your evaluation of the documentation?
- Will the choice of API abstraction model ease the development of
software that must talk to a MySQL database?
- Are there any immediate improvements that could be made after
acceptance, if acceptance should happen?
- Did you try to use the library? With which compiler(s)? Did you
have any problems?
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
- Are you knowledgeable about the problem domain?
More information about the Boost Formal Review Process can be found
at: http://www.boost.org/community/reviews.html
The review is open to anyone who is prepared to put in the work of
evaluating and reviewing the library. Prior experience in
contributing to Boost reviews is not a requirement.
Thank you for your efforts in the Boost community. They are very much
appreciated.
Richard Hodges
- review manager of the proposed Boost.MySQL library
Rub?n is often available on CppLang Slack and of course by email should you
require any clarification not covered by the documentation, as am I.
--
Richard Hodges
hodges.r@gmail.com
office: +44 2032 898 513
home: +376 861 195
mobile: +376 380 212
------------------------------
Subject: Digest Footer
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
End of Boost Digest, Vol 6705, Issue 1
**************************************
Benedict Bede McNamara