[boost] The Future of C++ Modules

13 May 2022

      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
**************************************

[boost] The Future of C++ Modules

Benedict Bede McNamara