Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #120652 > unrolled thread

"Safe C++ is A new Proposal to Make C++ Memory-Safe"

Back to article view | Back to comp.lang.c++

Contents

  "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-10-08 20:40 -0500
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-09 14:14 +0300
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-10-09 15:02 -0500
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-09 23:46 +0300
        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 08:34 +0000
          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 12:51 +0300
            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 10:20 +0000
              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 13:44 +0300
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 10:50 +0000
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 14:10 +0300
                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 13:11 +0000
                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 16:54 +0300
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-10 18:08 +0300
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-10-10 23:37 +0800
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-10 19:03 +0300
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 19:11 +0300
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" David Brown <david.brown@hesbynett.no> - 2024-10-10 20:01 +0200
            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-10 07:56 -0700
              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 18:56 +0300
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-10-20 10:13 -0700
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-10 12:13 -0400
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-10 18:29 +0200
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-20 12:37 +0100
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-20 14:46 +0300
        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-20 14:23 +0000
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-27 19:09 -0400
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-27 20:40 -0400
        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-10-28 09:22 +0800
          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:18 -0700
            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-28 12:25 -0400
              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:56 -0400
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-30 12:50 -0700
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-30 16:31 -0400
                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-04 12:47 -0800
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-07 07:02 -0500
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-11-07 20:14 -0600
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-08 09:40 -0500
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-08 14:48 +0000
                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-08 14:54 +0000
                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 12:40 -0800
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:39 -0800
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-11 09:56 +0000
                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-11 13:36 -0800
                                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-12 08:28 +0000
                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 13:56 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 13:59 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-12 16:20 -0800
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-10 13:02 -0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-10 13:05 -0800
                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 12:46 -0800
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 05:18 +0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 13:23 -0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 05:25 +0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 13:27 -0800
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:02 +0800
                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:09 -0800
                                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:35 +0800
                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:37 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:47 +0800
                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:58 -0800
                                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 07:09 +0800
                                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:35 -0800
                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-08 23:50 +0000
                                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 18:11 -0800
                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:39 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:58 +0800
                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:01 -0800
                                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 07:13 +0800
                                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:40 -0800
                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 08:19 +0800
                                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 18:15 -0800
                                                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-09 16:23 +0000
                                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:42 -0800
                                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-09 23:23 +0000
                                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-10 11:00 +0200
                                                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 16:56 -0800
                                                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 16:59 -0800
                                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 17:05 -0800
                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:50 -0800
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-04 06:59 -0800
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-30 10:03 -0500

Page 1 of 5  [1] 2 3 4 5  Next page →

#120652 — "Safe C++ is A new Proposal to Make C++ Memory-Safe"

"Safe C++ is A new Proposal to Make C++ Memory-Safe"
    https://www.infoq.com/news/2024/10/safe-cpp-proposal/

"The goal of the Safe C++ proposal is extending C++ by defining a 
superset of the language that can be used to write code with the strong 
safety guarantees similarly to code written in Rust. The key to its 
approach is introducing a new safe context where only a rigorously safe 
subset of C++ is allowed."

"The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, 
originates from the growing awareness that C++ memory unsafety lies at 
the root of a large part of vulnerabilities and memory exploits. The 
only existing safe language, say Baxter and Mazakas, is Rust, but their 
design differences limit interoperability, thus making it hard to 
migrate from one language to the other. For example, Rust lacks function 
overloading, templates, inheritance, and exceptions, while C++ lacks 
traits, relocation, and borrow checking."

Lynn

[toc] | [next] | [standalone]

#120664

On Tue, 8 Oct 2024 20:40:38 -0500
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> 
> "The goal of the Safe C++ proposal is extending C++ by defining a 
> superset of the language that can be used to write code with the
> strong safety guarantees similarly to code written in Rust. The key
> to its approach is introducing a new safe context where only a
> rigorously safe subset of C++ is allowed."
> 
> "The Safe C++ proposal, set forth by Sean Baxter and Christian
> Mazakas, originates from the growing awareness that C++ memory
> unsafety lies at the root of a large part of vulnerabilities and
> memory exploits. The only existing safe language, say Baxter and
> Mazakas, is Rust, 

Journalists are so journalists! Even when, like Sergio De Simone, they
claim that they are software engineers.

Of course, Baxter and Mazakas never said anything like that. Their
statement is much more reasonable: "There’s only one popular systems
level/non-garbage collected language that provides rigorous memory
safety. That’s the Rust language."
I am not sure that I agree with Baxter and Mazakas, but at least
their statement is not as obviously and blatantly wrong as it sound in
"translation" of De Simone.

> but their design differences limit
> interoperability, thus making it hard to migrate from one language to
> the other. For example, Rust lacks function overloading, templates,
> inheritance, and exceptions, while C++ lacks traits, relocation, and
> borrow checking."
> 
> Lynn
> 

[toc] | [prev] | [next] | [standalone]

#120668

On 10/8/2024 8:40 PM, Lynn McGuire wrote:
> "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> 
> "The goal of the Safe C++ proposal is extending C++ by defining a 
> superset of the language that can be used to write code with the strong 
> safety guarantees similarly to code written in Rust. The key to its 
> approach is introducing a new safe context where only a rigorously safe 
> subset of C++ is allowed."
> 
> "The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, 
> originates from the growing awareness that C++ memory unsafety lies at 
> the root of a large part of vulnerabilities and memory exploits. The 
> only existing safe language, say Baxter and Mazakas, is Rust, but their 
> design differences limit interoperability, thus making it hard to 
> migrate from one language to the other. For example, Rust lacks function 
> overloading, templates, inheritance, and exceptions, while C++ lacks 
> traits, relocation, and borrow checking."
> 
> Lynn

And what the heck is relocation, traits, and borrow checking ?

Lynn

[toc] | [prev] | [next] | [standalone]

#120669

On Wed, 9 Oct 2024 15:02:54 -0500
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> On 10/8/2024 8:40 PM, Lynn McGuire wrote:
> > "Safe C++ is A new Proposal to Make C++ Memory-Safe"
> >     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> > 
> > "The goal of the Safe C++ proposal is extending C++ by defining a 
> > superset of the language that can be used to write code with the
> > strong safety guarantees similarly to code written in Rust. The key
> > to its approach is introducing a new safe context where only a
> > rigorously safe subset of C++ is allowed."
> > 
> > "The Safe C++ proposal, set forth by Sean Baxter and Christian
> > Mazakas, originates from the growing awareness that C++ memory
> > unsafety lies at the root of a large part of vulnerabilities and
> > memory exploits. The only existing safe language, say Baxter and
> > Mazakas, is Rust, but their design differences limit
> > interoperability, thus making it hard to migrate from one language
> > to the other. For example, Rust lacks function overloading,
> > templates, inheritance, and exceptions, while C++ lacks traits,
> > relocation, and borrow checking."
> > 
> > Lynn  
> 
> And what the heck is relocation, traits, and borrow checking ?
> 
> Lynn
> 

Traits and borrow checking can't be explained in few words, nor in few
dozens of words.
Ownership model+borrow checker happens to be the main feature that
distinguishes the Rust from the Rest.

'Relocation' does not appear to be an established Rust term. 
It seems that Sean Baxter and Christian Mazakas use word 'relocation' 
to describe a mechanism use in Rust by default when object that
contains embedded pointers or is of variable size is assigned to
another object. Rust docs call it 'move'.

[toc] | [prev] | [next] | [standalone]

#120676

On Wed, 9 Oct 2024 23:46:05 +0300
Michael S <already5chosen@yahoo.com> boring babbled:
>On Wed, 9 Oct 2024 15:02:54 -0500
>Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>> And what the heck is relocation, traits, and borrow checking ?
>>=20
>> Lynn
>>=20
>
>Traits and borrow checking can't be explained in few words, nor in few
>dozens of words.

Borrow checking is just a fancy way of compile time checking a pointer/object 
will still be valid after being used previously. Eg: If C had borrow checking
the compiler would error at the printf().

void func(char **ptr)
{
	*ptr = NULL;
}


int main()
{
	char *ptr = "hello";
	func(&ptr);
	printf("%c\n",*ptr);
	return 0;
}
	

[toc] | [prev] | [next] | [standalone]

#120678

On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
Muttley@DastartdlyHQ.org wrote:

> On Wed, 9 Oct 2024 23:46:05 +0300
> Michael S <already5chosen@yahoo.com> boring babbled:
> >On Wed, 9 Oct 2024 15:02:54 -0500
> >Lynn McGuire <lynnmcguire5@gmail.com> wrote:  
> >> And what the heck is relocation, traits, and borrow checking ?
> >>=20
> >> Lynn
> >>=20  
> >
> >Traits and borrow checking can't be explained in few words, nor in
> >few dozens of words.  
> 
> Borrow checking is just a fancy way of compile time checking a
> pointer/object will still be valid after being used previously. Eg:
> If C had borrow checking the compiler would error at the printf().
> 
> void func(char **ptr)
> {
> 	*ptr = NULL;
> }
> 
> 
> int main()
> {
> 	char *ptr = "hello";
> 	func(&ptr);
> 	printf("%c\n",*ptr);
> 	return 0;
> }
> 	
> 

Do you think that your explanation is sufficient for Lynn McGuire?
Consider that he probably doesn't know what Rust people have in mind
when they talk about ownership. And you can be sure that he doesn't know
the rusty meaning of 'borrow'. 
Even I am not 100% sure that I understand the later, although it seem
to me that in their dialect 'borrow' means 'make a reference'.

[toc] | [prev] | [next] | [standalone]

#120679

On Thu, 10 Oct 2024 12:51:57 +0300
Michael S <already5chosen@yahoo.com> boring babbled:
>On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
>Muttley@DastartdlyHQ.org wrote:
>
>> On Wed, 9 Oct 2024 23:46:05 +0300
>> Michael S <already5chosen@yahoo.com> boring babbled:
>> >On Wed, 9 Oct 2024 15:02:54 -0500
>> >Lynn McGuire <lynnmcguire5@gmail.com> wrote:  
>> >> And what the heck is relocation, traits, and borrow checking ?
>> >>=20
>> >> Lynn
>> >>=20  
>> >
>> >Traits and borrow checking can't be explained in few words, nor in
>> >few dozens of words.  
>> 
>> Borrow checking is just a fancy way of compile time checking a
>> pointer/object will still be valid after being used previously. Eg:
>> If C had borrow checking the compiler would error at the printf().
>> 
>> void func(char **ptr)
>> {
>> 	*ptr = NULL;
>> }
>> 
>> 
>> int main()
>> {
>> 	char *ptr = "hello";
>> 	func(&ptr);
>> 	printf("%c\n",*ptr);
>> 	return 0;
>> }
>> 	
>> 
>
>Do you think that your explanation is sufficient for Lynn McGuire?

No idea. 

>Consider that he probably doesn't know what Rust people have in mind
>when they talk about ownership. And you can be sure that he doesn't know
>the rusty meaning of 'borrow'. 
>Even I am not 100% sure that I understand the later, although it seem
>to me that in their dialect 'borrow' means 'make a reference'.

I think its just their way of checking if something could have been altered
before use in a way that might crash the program or introduce bugs.

[toc] | [prev] | [next] | [standalone]

#120680

On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
Muttley@DastartdlyHQ.org wrote:

> On Thu, 10 Oct 2024 12:51:57 +0300
> Michael S <already5chosen@yahoo.com> boring babbled:
> >On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
> >Muttley@DastartdlyHQ.org wrote:
> >  
> >> On Wed, 9 Oct 2024 23:46:05 +0300
> >> Michael S <already5chosen@yahoo.com> boring babbled:  
> >> >On Wed, 9 Oct 2024 15:02:54 -0500
> >> >Lynn McGuire <lynnmcguire5@gmail.com> wrote:    
> >> >> And what the heck is relocation, traits, and borrow checking ?
> >> >>=20
> >> >> Lynn
> >> >>=20    
> >> >
> >> >Traits and borrow checking can't be explained in few words, nor in
> >> >few dozens of words.    
> >> 
> >> Borrow checking is just a fancy way of compile time checking a
> >> pointer/object will still be valid after being used previously. Eg:
> >> If C had borrow checking the compiler would error at the printf().
> >> 
> >> void func(char **ptr)
> >> {
> >> 	*ptr = NULL;
> >> }
> >> 
> >> 
> >> int main()
> >> {
> >> 	char *ptr = "hello";
> >> 	func(&ptr);
> >> 	printf("%c\n",*ptr);
> >> 	return 0;
> >> }
> >> 	
> >>   
> >
> >Do you think that your explanation is sufficient for Lynn McGuire?  
> 
> No idea. 
> 
> >Consider that he probably doesn't know what Rust people have in mind
> >when they talk about ownership. And you can be sure that he doesn't
> >know the rusty meaning of 'borrow'. 
> >Even I am not 100% sure that I understand the later, although it seem
> >to me that in their dialect 'borrow' means 'make a reference'.  
> 
> I think its just their way of checking if something could have been
> altered before use in a way that might crash the program or introduce
> bugs.
> 

Now you're talking about meaning of 'borrow checker'. 
Before we go that far we have to dig up the meaning of 'borrow'.

[toc] | [prev] | [next] | [standalone]

#120681

On Thu, 10 Oct 2024 13:44:59 +0300
Michael S <already5chosen@yahoo.com> boring babbled:
>On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
>Muttley@DastartdlyHQ.org wrote:
>> I think its just their way of checking if something could have been
>> altered before use in a way that might crash the program or introduce
>> bugs.
>> 
>
>Now you're talking about meaning of 'borrow checker'. 
>Before we go that far we have to dig up the meaning of 'borrow'.

Since when do programming language keywords always mean the exact same as
the english equivalent? Last time I looked "for" didn't mean "loop" in english.

Frankly borrow-checking can mean whatever they want it to mean this week, but
in general its what I said above.

[toc] | [prev] | [next] | [standalone]

#120682

On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
Muttley@DastartdlyHQ.org wrote:

> On Thu, 10 Oct 2024 13:44:59 +0300
> Michael S <already5chosen@yahoo.com> boring babbled:
> >On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
> >Muttley@DastartdlyHQ.org wrote:  
> >> I think its just their way of checking if something could have been
> >> altered before use in a way that might crash the program or
> >> introduce bugs.
> >>   
> >
> >Now you're talking about meaning of 'borrow checker'. 
> >Before we go that far we have to dig up the meaning of 'borrow'.  
> 
> Since when do programming language keywords always mean the exact
> same as the english equivalent? Last time I looked "for" didn't mean
> "loop" in english.
> 

Well, I don't know how it feels for native English speakers, but for me
meaning of 'loop' in programming is not equivalent to its meaning in
the rest of English language.

> Frankly borrow-checking can mean whatever they want it to mean this
> week, but in general its what I said above.
> 

Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
abstract (more or less) concepts used in Rust manuals. And it seems
logical that it would be easier to explain the later if we explain the
former first.

[toc] | [prev] | [next] | [standalone]

#120684

On Thu, 10 Oct 2024 14:10:47 +0300
Michael S <already5chosen@yahoo.com> boring babbled:
>On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
>Muttley@DastartdlyHQ.org wrote:
>
>> On Thu, 10 Oct 2024 13:44:59 +0300
>> Michael S <already5chosen@yahoo.com> boring babbled:
>> >On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
>> >Muttley@DastartdlyHQ.org wrote:  
>> >> I think its just their way of checking if something could have been
>> >> altered before use in a way that might crash the program or
>> >> introduce bugs.
>> >>   
>> >
>> >Now you're talking about meaning of 'borrow checker'. 
>> >Before we go that far we have to dig up the meaning of 'borrow'.  
>> 
>> Since when do programming language keywords always mean the exact
>> same as the english equivalent? Last time I looked "for" didn't mean
>> "loop" in english.
>> 
>
>Well, I don't know how it feels for native English speakers, but for me
>meaning of 'loop' in programming is not equivalent to its meaning in
>the rest of English language.

Something thats circular(ish) or goes around in a circle. Its close enough.

>> Frankly borrow-checking can mean whatever they want it to mean this
>> week, but in general its what I said above.
>> 
>
>Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
>abstract (more or less) concepts used in Rust manuals. And it seems
>logical that it would be easier to explain the later if we explain the
>former first.

Presumably the borrow means something "borrowed" the pointer, and checker means
checking the pointer is still valid. Doesn't seem complicated to me.

[toc] | [prev] | [next] | [standalone]

#120685

On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
Muttley@DastartdlyHQ.org wrote:

> On Thu, 10 Oct 2024 14:10:47 +0300
> Michael S <already5chosen@yahoo.com> boring babbled:
> >On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
> >Muttley@DastartdlyHQ.org wrote:
> >  
> >> On Thu, 10 Oct 2024 13:44:59 +0300
> >> Michael S <already5chosen@yahoo.com> boring babbled:  
> >> >On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
> >> >Muttley@DastartdlyHQ.org wrote:    
> >> >> I think its just their way of checking if something could have
> >> >> been altered before use in a way that might crash the program or
> >> >> introduce bugs.
> >> >>     
> >> >
> >> >Now you're talking about meaning of 'borrow checker'. 
> >> >Before we go that far we have to dig up the meaning of 'borrow'.
> >> >  
> >> 
> >> Since when do programming language keywords always mean the exact
> >> same as the english equivalent? Last time I looked "for" didn't
> >> mean "loop" in english.
> >>   
> >
> >Well, I don't know how it feels for native English speakers, but for
> >me meaning of 'loop' in programming is not equivalent to its meaning
> >in the rest of English language.  
> 
> Something thats circular(ish) or goes around in a circle. Its close
> enough.
> 
> >> Frankly borrow-checking can mean whatever they want it to mean this
> >> week, but in general its what I said above.
> >>   
> >
> >Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
> >abstract (more or less) concepts used in Rust manuals. And it seems
> >logical that it would be easier to explain the later if we explain
> >the former first.  
> 
> Presumably the borrow means something "borrowed" the pointer, and
> checker means checking the pointer is still valid. Doesn't seem
> complicated to me.
> 

May be, for people that are used to smart pointers in C++, for people
that move their private parts from unique_ptr to shared_ptr to weak_ptr
forth, back and sideways, may be for these people Rust ownership and
borrowing business is not complicated. For me it is.

[toc] | [prev] | [next] | [standalone]

#120687

On 10.10.2024 16:54, Michael S wrote:
> On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
> Muttley@DastartdlyHQ.org wrote:
> 
>> On Thu, 10 Oct 2024 14:10:47 +0300
>> Michael S <already5chosen@yahoo.com> boring babbled:
>>> On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
>>> Muttley@DastartdlyHQ.org wrote:
>>>   
>>>> On Thu, 10 Oct 2024 13:44:59 +0300
>>>> Michael S <already5chosen@yahoo.com> boring babbled:
>>>>> On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
>>>>> Muttley@DastartdlyHQ.org wrote:
>>>>>> I think its just their way of checking if something could have
>>>>>> been altered before use in a way that might crash the program or
>>>>>> introduce bugs.
>>>>>>      
>>>>>
>>>>> Now you're talking about meaning of 'borrow checker'.
>>>>> Before we go that far we have to dig up the meaning of 'borrow'.
>>>>>   
>>>>
>>>> Since when do programming language keywords always mean the exact
>>>> same as the english equivalent? Last time I looked "for" didn't
>>>> mean "loop" in english.
>>>>    
>>>
>>> Well, I don't know how it feels for native English speakers, but for
>>> me meaning of 'loop' in programming is not equivalent to its meaning
>>> in the rest of English language.
>>
>> Something thats circular(ish) or goes around in a circle. Its close
>> enough.
>>
>>>> Frankly borrow-checking can mean whatever they want it to mean this
>>>> week, but in general its what I said above.
>>>>    
>>>
>>> Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
>>> abstract (more or less) concepts used in Rust manuals. And it seems
>>> logical that it would be easier to explain the later if we explain
>>> the former first.
>>
>> Presumably the borrow means something "borrowed" the pointer, and
>> checker means checking the pointer is still valid. Doesn't seem
>> complicated to me.
>>
> 
> May be, for people that are used to smart pointers in C++, for people
> that move their private parts from unique_ptr to shared_ptr to weak_ptr
> forth, back and sideways, may be for these people Rust ownership and
> borrowing business is not complicated. For me it is.
> 

 From what I have understood, Rust borrowing is more related to 
std::move() and rvalue references in C++. But yes, one thing which can 
be moved around this way is indeed std::unique_ptr.

[toc] | [prev] | [next] | [standalone]

#120688

On Thu, 2024-10-10 at 18:08 +0300, Paavo Helde wrote:
> On 10.10.2024 16:54, Michael S wrote:
> > On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
> > Muttley@DastartdlyHQ.org wrote:
> > 
> > > On Thu, 10 Oct 2024 14:10:47 +0300
> > > Michael S <already5chosen@yahoo.com> boring babbled:
> > > > On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
> > > > Muttley@DastartdlyHQ.org wrote:
> > > >   
> > > > > On Thu, 10 Oct 2024 13:44:59 +0300
> > > > > Michael S <already5chosen@yahoo.com> boring babbled:
> > > > > > On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
> > > > > > Muttley@DastartdlyHQ.org wrote:
> > > > > > > I think its just their way of checking if something could have
> > > > > > > been altered before use in a way that might crash the program or
> > > > > > > introduce bugs.
> > > > > > >      
> > > > > > 
> > > > > > Now you're talking about meaning of 'borrow checker'.
> > > > > > Before we go that far we have to dig up the meaning of 'borrow'.
> > > > > >   
> > > > > 
> > > > > Since when do programming language keywords always mean the exact
> > > > > same as the english equivalent? Last time I looked "for" didn't
> > > > > mean "loop" in english.
> > > > >    
> > > > 
> > > > Well, I don't know how it feels for native English speakers, but for
> > > > me meaning of 'loop' in programming is not equivalent to its meaning
> > > > in the rest of English language.
> > > 
> > > Something thats circular(ish) or goes around in a circle. Its close
> > > enough.
> > > 
> > > > > Frankly borrow-checking can mean whatever they want it to mean this
> > > > > week, but in general its what I said above.
> > > > >    
> > > > 
> > > > Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
> > > > abstract (more or less) concepts used in Rust manuals. And it seems
> > > > logical that it would be easier to explain the later if we explain
> > > > the former first.
> > > 
> > > Presumably the borrow means something "borrowed" the pointer, and
> > > checker means checking the pointer is still valid. Doesn't seem
> > > complicated to me.
> > > 
> > 
> > May be, for people that are used to smart pointers in C++, for people
> > that move their private parts from unique_ptr to shared_ptr to weak_ptr
> > forth, back and sideways, may be for these people Rust ownership and
> > borrowing business is not complicated. For me it is.
> > 
> 
>  From what I have understood, Rust borrowing is more related to 
> std::move() and rvalue references in C++. But yes, one thing which can 
> be moved around this way is indeed std::unique_ptr.
> 

Lots of 'high level concept' invention are around the assembly "mov A,B"
What's for? 
C++ is now  basically a macro language for various programming concepts,
and *standardized* while announced as multi-lingual (fake).

[toc] | [prev] | [next] | [standalone]

#120690

On 10.10.2024 18:37, wij wrote:
> Lots of 'high level concept' invention are around the assembly "mov A,B"
> What's for?

Assembler "mov" is a misnamed "copy". So, no relation.

[toc] | [prev] | [next] | [standalone]

#120691

On Thu, 10 Oct 2024 18:08:48 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:

> On 10.10.2024 16:54, Michael S wrote:
> > On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
> > Muttley@DastartdlyHQ.org wrote:
> >   
> >> On Thu, 10 Oct 2024 14:10:47 +0300
> >> Michael S <already5chosen@yahoo.com> boring babbled:  
> >>> On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
> >>> Muttley@DastartdlyHQ.org wrote:
> >>>     
> >>>> On Thu, 10 Oct 2024 13:44:59 +0300
> >>>> Michael S <already5chosen@yahoo.com> boring babbled:  
> >>>>> On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
> >>>>> Muttley@DastartdlyHQ.org wrote:  
> >>>>>> I think its just their way of checking if something could have
> >>>>>> been altered before use in a way that might crash the program
> >>>>>> or introduce bugs.
> >>>>>>        
> >>>>>
> >>>>> Now you're talking about meaning of 'borrow checker'.
> >>>>> Before we go that far we have to dig up the meaning of 'borrow'.
> >>>>>     
> >>>>
> >>>> Since when do programming language keywords always mean the exact
> >>>> same as the english equivalent? Last time I looked "for" didn't
> >>>> mean "loop" in english.
> >>>>      
> >>>
> >>> Well, I don't know how it feels for native English speakers, but
> >>> for me meaning of 'loop' in programming is not equivalent to its
> >>> meaning in the rest of English language.  
> >>
> >> Something thats circular(ish) or goes around in a circle. Its close
> >> enough.
> >>  
> >>>> Frankly borrow-checking can mean whatever they want it to mean
> >>>> this week, but in general its what I said above.
> >>>>      
> >>>
> >>> Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
> >>> abstract (more or less) concepts used in Rust manuals. And it
> >>> seems logical that it would be easier to explain the later if we
> >>> explain the former first.  
> >>
> >> Presumably the borrow means something "borrowed" the pointer, and
> >> checker means checking the pointer is still valid. Doesn't seem
> >> complicated to me.
> >>  
> > 
> > May be, for people that are used to smart pointers in C++, for
> > people that move their private parts from unique_ptr to shared_ptr
> > to weak_ptr forth, back and sideways, may be for these people Rust
> > ownership and borrowing business is not complicated. For me it is.
> >   
> 
>  From what I have understood, Rust borrowing is more related to 
> std::move() and rvalue references in C++. But yes, one thing which
> can be moved around this way is indeed std::unique_ptr.
> 

My understanding is an opposite. 
Borrowing is the case when the ownership is *not* moved by creation of
the reference. Something akin to shared_ptr in C++ and to
reference-counted object in Swift or may be even in Python. With the
major difference that in Rust references are counted by static analyzer
in compile time rather than by language runtime system (Swift) or by
the library (C++) in run time.

But then, not counting examples from tutorial, I wrote only one
full program in Rust and this program was rather simple. So it is
possible that I misunderstood.

[toc] | [prev] | [next] | [standalone]

#120694

On 10/10/2024 18:11, Michael S wrote:
> On Thu, 10 Oct 2024 18:08:48 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
> 
>> On 10.10.2024 16:54, Michael S wrote:
>>> On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
>>> Muttley@DastartdlyHQ.org wrote:
>>>    
>>>> On Thu, 10 Oct 2024 14:10:47 +0300
>>>> Michael S <already5chosen@yahoo.com> boring babbled:
>>>>> On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
>>>>> Muttley@DastartdlyHQ.org wrote:
>>>>>      
>>>>>> On Thu, 10 Oct 2024 13:44:59 +0300
>>>>>> Michael S <already5chosen@yahoo.com> boring babbled:
>>>>>>> On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
>>>>>>> Muttley@DastartdlyHQ.org wrote:
>>>>>>>> I think its just their way of checking if something could have
>>>>>>>> been altered before use in a way that might crash the program
>>>>>>>> or introduce bugs.
>>>>>>>>         
>>>>>>>
>>>>>>> Now you're talking about meaning of 'borrow checker'.
>>>>>>> Before we go that far we have to dig up the meaning of 'borrow'.
>>>>>>>      
>>>>>>
>>>>>> Since when do programming language keywords always mean the exact
>>>>>> same as the english equivalent? Last time I looked "for" didn't
>>>>>> mean "loop" in english.
>>>>>>       
>>>>>
>>>>> Well, I don't know how it feels for native English speakers, but
>>>>> for me meaning of 'loop' in programming is not equivalent to its
>>>>> meaning in the rest of English language.
>>>>
>>>> Something thats circular(ish) or goes around in a circle. Its close
>>>> enough.
>>>>   
>>>>>> Frankly borrow-checking can mean whatever they want it to mean
>>>>>> this week, but in general its what I said above.
>>>>>>       
>>>>>
>>>>> Neither 'borrow' nor 'borrow checker' are Rust keywords. They are
>>>>> abstract (more or less) concepts used in Rust manuals. And it
>>>>> seems logical that it would be easier to explain the later if we
>>>>> explain the former first.
>>>>
>>>> Presumably the borrow means something "borrowed" the pointer, and
>>>> checker means checking the pointer is still valid. Doesn't seem
>>>> complicated to me.
>>>>   
>>>
>>> May be, for people that are used to smart pointers in C++, for
>>> people that move their private parts from unique_ptr to shared_ptr
>>> to weak_ptr forth, back and sideways, may be for these people Rust
>>> ownership and borrowing business is not complicated. For me it is.
>>>    
>>
>>   From what I have understood, Rust borrowing is more related to
>> std::move() and rvalue references in C++. But yes, one thing which
>> can be moved around this way is indeed std::unique_ptr.
>>
> 
> My understanding is an opposite.
> Borrowing is the case when the ownership is *not* moved by creation of
> the reference. Something akin to shared_ptr in C++ and to
> reference-counted object in Swift or may be even in Python. With the
> major difference that in Rust references are counted by static analyzer
> in compile time rather than by language runtime system (Swift) or by
> the library (C++) in run time.
> 
> But then, not counting examples from tutorial, I wrote only one
> full program in Rust and this program was rather simple. So it is
> possible that I misunderstood.
> 

Without having used Rust myself, I think you are closer to the right 
concept.

But I wonder if it is better to think of it as a kind of "locking". 
Basically, if you have an object, then take a reference to the object or 
a sub-object (such as an item in a container), then that "locks" the 
object and makes it immutable until the reference is dead or out of scope.

Borrowing in Rust is only partially checked at unit compile time. 
AFAIUI you also need to use a "borrow checker" after compilation to make 
sure that cross-module borrows are safe.


(The concept of this kind of larger scale correctness analysis is not 
actually new.  If you have ever looked at the XMOS microcontrollers, 
they are often programmed in a language called "XC" that amongst other 
things has analysis to limit the access to data by different threads so 
that you know there are no race conditions.)

[toc] | [prev] | [next] | [standalone]

#120686

Michael S <already5chosen@yahoo.com> writes:

>> [suggested explanation of borrow checking]
>
> Do you think that your explanation is sufficient for Lynn McGuire?
> Consider that he probably doesn't know what Rust people have in mind
> when they talk about ownership.  And you can be sure that he doesn't
> know the rusty meaning of 'borrow'.
>
> Even I am not 100% sure that I understand the later, although it
> seem to me that in their dialect 'borrow' means 'make a reference'.

Just a minor note here..  the word latter is spelled with two t's.

(fwiw I too have been frustrated by the inadequacy of descriptions
of Rust's features and concepts.)

[toc] | [prev] | [next] | [standalone]

#120689

On Thu, 10 Oct 2024 07:56:39 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> >> [suggested explanation of borrow checking]  
> >
> > Do you think that your explanation is sufficient for Lynn McGuire?
> > Consider that he probably doesn't know what Rust people have in mind
> > when they talk about ownership.  And you can be sure that he doesn't
> > know the rusty meaning of 'borrow'.
> >
> > Even I am not 100% sure that I understand the later, although it
> > seem to me that in their dialect 'borrow' means 'make a reference'.
> >  
> 
> Just a minor note here..  the word latter is spelled with two t's.
>

Thank you. I would try to remember.

[toc] | [prev] | [next] | [standalone]

#120745

On 10/09/2024 01:02 PM, Lynn McGuire wrote:
> On 10/8/2024 8:40 PM, Lynn McGuire wrote:
>> "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>>     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
>>
>> "The goal of the Safe C++ proposal is extending C++ by defining a
>> superset of the language that can be used to write code with the
>> strong safety guarantees similarly to code written in Rust. The key to
>> its approach is introducing a new safe context where only a rigorously
>> safe subset of C++ is allowed."
>>
>> "The Safe C++ proposal, set forth by Sean Baxter and Christian
>> Mazakas, originates from the growing awareness that C++ memory
>> unsafety lies at the root of a large part of vulnerabilities and
>> memory exploits. The only existing safe language, say Baxter and
>> Mazakas, is Rust, but their design differences limit interoperability,
>> thus making it hard to migrate from one language to the other. For
>> example, Rust lacks function overloading, templates, inheritance, and
>> exceptions, while C++ lacks traits, relocation, and borrow checking."
>>
>> Lynn
>
> And what the heck is relocation, traits, and borrow checking ?
>
> Lynn
>

C++ has traits in templates, and move semantics, and
roll-your-own smart-pointers, ..., Rust is missing
exceptions and the corresponding defined behavior
according to initializer and constructor semantics,
and I'm not sure what it's got going on with static_cast,
which going outside the type system is of course entirely
prone error, vis-a-vis the theory of types.

A "safer" language would have less easy-to-write code
that entirely ignores ownership semantics of allocations.

I.e., that is to say, no "garbage collected" language
is quite "safe" in that sense.


You know they say "goto is dangerous or harmful" yet
at the same time it sort is the model of the instruction pointer,
and in effect _is_ implicit in every instruction?


Anyways managing allocations first-class would be safer
if you know how it is more error-prone because most
linear coders have lost the discipline and treat
everything like an owned singleton. Now, that's not
fair because there are all sorts who well manage all
sorts of allocator techniques that are correct, as
with regards to languages being "safe" and what that
means is being "correct", not being "stupid" and
"slightly less unlikely to make a double-free,
or orphan an allocated pointer, or especially,
to case data among types or make raw pointer
re-seating".


So, making allocation and ownership first-class in
the language, then making barriers of those first-class
in the language, then having type semantics strongly
in the language, and stack semantics for what exceptions
provide, that would be kind of safe and you can imagine
one of those as a subset of C++ (i.e., omitting static_cast)
then a library what hides accessors and discipline on objects,
about allocator patterns and pointer patterns and good-old
reference-counting.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web