Boost :

benedict_at_[hidden]

-- 
Soronel Haetir
soronel.haetir_at_[hidden]
------------------------------
Message: 3
Date: Sat, 14 May 2022 08:45:53 +1000
From: Benedict Bede McNamara <benedict_at_[hidden]>
To: "boost_at_[hidden]" <boost_at_[hidden]>
Subject: [boost] The Future of C++ Modules
Message-ID: <1652481962361.5bcfb010425513a2_at_[hidden]>
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_at_[hidden]
Sent: Saturday, 14 May 2022 8:19 AM
To: boost_at_[hidden]
Subject: Boost Digest, Vol 6704, Issue 5
Send Boost mailing list submissions to
	boost_at_[hidden]
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_at_[hidden]
You can reach the person managing the list at
	boost-owner_at_[hidden]
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" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
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 <mclow.lists_at_[hidden]>
To: Boost Developers List <boost_at_[hidden]>
Subject: Re: [boost] cstring_view
Message-ID: <DFCD5BFF-F7CA-46CC-82DF-833CE68CB0F0_at_[hidden]>
Content-Type: text/plain;	charset=utf-8
On May 13, 2022, at 10:42 AM, David Bien via Boost <boost_at_[hidden]> 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" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
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 <boost_at_[hidden]>
> 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 <mclow.lists_at_[hidden]>
To: Peter Dimov <pdimov_at_[hidden]>
Cc: Boost Developers List <boost_at_[hidden]>
Subject: Re: [boost] cstring_view
Message-ID: <F5FB00FB-3576-47CF-8BEA-FFD90C2C74F0_at_[hidden]>
Content-Type: text/plain;	charset=utf-8
On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
> Marshall Clow wrote:
>> On May 13, 2022, at 10:42 AM, David Bien via Boost <boost_at_[hidden]>
>> 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" <pdimov_at_[hidden]>
To: "'Marshall Clow'" <mclow.lists_at_[hidden]>
Cc: "'Boost Developers List'" <boost_at_[hidden]>
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 <rdeyke_at_[hidden]>
To: boost_at_[hidden]
Subject: Re: [boost] cstring_view
Message-ID: <t5mbi2$42u$1_at_[hidden]>
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 <boost_at_[hidden]> 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_at_[hidden])
------------------------------
Message: 7
Date: Fri, 13 May 2022 18:20:40 +0000
From: David Bien <davidbien_at_[hidden]>
To: "boost_at_[hidden]" <boost_at_[hidden]>
Cc: Peter Dimov <pdimov_at_[hidden]>
Subject: Re: [boost] cstring_view
Message-ID:
	<MWHPR1801MB1934DE34D9E7AE1678101098B1CA9_at_MWHPR1801MB1934.namprd18.prod.outlo>
	
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 Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: Peter Dimov via Boost<mailto:boost_at_[hidden]>
Sent: Friday, May 13, 2022 12:19 PM
To: boost_at_[hidden]<mailto:boost_at_[hidden]>
Cc: Peter Dimov<mailto:pdimov_at_[hidden]>
Subject: Re: [boost] cstring_view
Marshall Clow wrote:
> On May 13, 2022, at 10:42 AM, David Bien via Boost <boost_at_[hidden]>
> 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.org%2Fmailman%2Flistinfo.cgi%2Fboost&amp;data=05%7C01%7C%7Cf61e2ab6e0b04fcd8a4508da350d0f78%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880627456487826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=itiI6gcF%2FXnNr41BGxmxrqbPRAq%2FqhjBYRVXXG3UbwM%3D&amp;reserved=0
------------------------------
Message: 8
Date: Fri, 13 May 2022 21:37:36 +0200
From: Rainer Deyke <rdeyke_at_[hidden]>
To: boost_at_[hidden]
Subject: Re: [boost] MySql review
Message-ID: <t5mc20$87r$1_at_[hidden]>
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_at_[hidden])
------------------------------
Message: 9
Date: Fri, 13 May 2022 12:33:50 -0700
From: Robert Ramey <ramey_at_[hidden]>
To: Peter Dimov via Boost <boost_at_[hidden]>
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID: <4134c080-20bb-16d2-ff81-0c6b6dc52d75_at_[hidden]>
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" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
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 <mclow.lists_at_[hidden]>
To: Boost Developers List <boost_at_[hidden]>
Cc: Rainer Deyke <rdeyke_at_[hidden]>
Subject: Re: [boost] cstring_view
Message-ID: <3C70E2E0-DC7A-4263-9D93-FCD8220A39BE_at_[hidden]>
Content-Type: text/plain;	charset=utf-8
On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost <boost_at_[hidden]> wrote:
> 
> On 13.05.22 20:39, Marshall Clow via Boost wrote:
>> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost_at_[hidden]> 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" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
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
> <boost_at_[hidden]> wrote:
> >
> > On 13.05.22 20:39, Marshall Clow via Boost wrote:
> >> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost
> <boost_at_[hidden]> 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 &amp; 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 <klemens.morgenstern_at_[hidden]>
To: boost_at_[hidden]
Subject: Re: [boost] cstring_view
Message-ID: <7b7ece8b46b77ced2a9826a273c5df0ea36ca14a.camel_at_[hidden]>
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 <rdeyke_at_[hidden]>
To: boost_at_[hidden]
Subject: Re: [boost] cstring_view
Message-ID: <t5nmmk$1266$1_at_[hidden]>
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 <boost_at_[hidden]> wrote:
>>
>> Marshall Clow wrote:
>>> On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
>>> <boost_at_[hidden]> 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_at_[hidden])
------------------------------
Message: 6
Date: Sat, 14 May 2022 10:14:18 +0200
From: Mike <mike.dev_at_[hidden]>
To: boost_at_[hidden]
Cc: mike.dev_at_[hidden]
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID:
	<trinity-12e97b7f-9414-4767-8bcc-af0db788a334-1652516058595_at_3c-app-gmx-bs70>
	
Content-Type: text/plain; charset=UTF-8
> Gesendet: Freitag, 13. Mai 2022 um 22:43 Uhr
> Von: "Soronel Haetir via Boost" <boost_at_[hidden]>
>
> 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 <dani_at_[hidden]>
To: boost_at_[hidden]
Subject: Re: [boost] cstring_view
Message-ID: <9bafc2cf-6bfe-ad96-7a5d-075e71e9aae3_at_[hidden]>
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 
>>> <boost_at_[hidden]> wrote:
>>>
>>> Marshall Clow wrote:
>>>> On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
>>>> <boost_at_[hidden]> 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 <klemens.morgenstern_at_[hidden]>
To: boost_at_[hidden]
Subject: Re: [boost] cstring_view
Message-ID: <e9645d5ed8a1a265816998bb521f74e0722369dc.camel_at_[hidden]>
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 <hodges.r_at_[hidden]>
To: "boost_at_[hidden] List" <boost_at_[hidden]>,
	boost-announce_at_[hidden]
Subject: [boost] Boost MySQL Review Is In Progress
Message-ID:
	<CALvx3hYe3DW8POaFb-k5smQpGzL6S6UNi5bMy8Gxfc5sW70C0w_at_[hidden]>
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_boostmysql_has_just_started/
.
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.html
Rub?n has also implemented the Asio protocols for deducing default
completion token types :-
https://anarthal.github.io/mysql/mysql/examples/default_completion_tokens.html
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_at_[hidden]
office: +44 2032 898 513
home: +376 861 195
mobile: +376 380 212
------------------------------
Subject: Digest Footer
_______________________________________________
Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
End of Boost Digest, Vol 6705, Issue 1
**************************************