"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
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
On Wed, 9 Oct 2024 15:02:54 -0500
Lynn McGuire <[email protected]> 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.
On Wed, 9 Oct 2024 23:46:05 +0300
Michael S <[email protected]> boring babbled:
On Wed, 9 Oct 2024 15:02:54 -0500
Lynn McGuire <[email protected]> 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;
}
On Thu, 10 Oct 2024 12:51:57 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
[email protected] wrote:
On Wed, 9 Oct 2024 23:46:05 +0300
Michael S <[email protected]> boring babbled:
On Wed, 9 Oct 2024 15:02:54 -0500
Lynn McGuire <[email protected]> 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.
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
[email protected] 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'.
On Thu, 10 Oct 2024 08:34:55 -0000 (UTC)
[email protected] wrote:
On Wed, 9 Oct 2024 23:46:05 +0300
Michael S <[email protected]> boring babbled:
On Wed, 9 Oct 2024 15:02:54 -0500
Lynn McGuire <[email protected]> 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'.
On Thu, 10 Oct 2024 13:44:59 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
[email protected] 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.
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 13:44:59 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
[email protected] 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.
On Thu, 10 Oct 2024 14:10:47 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 13:44:59 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
[email protected] 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.
[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'.
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 14:10:47 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 13:44:59 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
[email protected] 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.
Lots of 'high level concept' invention are around the assembly "mov A,B" What's for?
Michael S <[email protected]> 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.
On 10.10.2024 16:54, Michael S wrote:
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 14:10:47 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 13:44:59 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
[email protected] 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.
"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
On Thu, 10 Oct 2024 18:08:48 +0300
Paavo Helde <[email protected]> wrote:
On 10.10.2024 16:54, Michael S wrote:
On Thu, 10 Oct 2024 13:11:24 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 14:10:47 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:50:05 -0000 (UTC)
[email protected] wrote:
On Thu, 10 Oct 2024 13:44:59 +0300
Michael S <[email protected]> boring babbled:
On Thu, 10 Oct 2024 10:20:07 -0000 (UTC)
[email protected] 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.
"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
a superset of the language
On 09/10/2024 02:40, 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."
LynnI hiccuped at this point:
a superset of the language
This means it has everything that C++ has, and some more stuff as
well. I'm pretty sure they mean a subset.
Andy
On Sun, 20 Oct 2024 12:37:45 +0100
Vir Campestris <[email protected]d> wrote:
On 09/10/2024 02:40, Lynn McGuire wrote:
"Safe C++ is A new Proposal to Make C++ Memory-Safe"I hiccuped at this point:
=A0=A0 https://www.infoq.com/news/2024/10/safe-cpp-proposal/
=20
"The goal of the Safe C++ proposal is extending C++ by defining a=20
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."
=20
"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."
=20
Lynn
=20
=20
a superset of the language =20=20
This means it has everything that C++ has, and some more stuff as
well. I'm pretty sure they mean a subset.
=20
Andy
Ignore clueless Sergio De Simone. His article couses nothing but >misunderstanding.
Go straight to the proposal. >https://safecpp.org/P3390R0.html#relocation-object-model
"The goal of this proposal is to advance a superset of C++ with a
rigorously safe subset."
"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
On 10/8/24 21:40, Lynn McGuire wrote:
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
...
p = p->next; // valid, inside while true block
}
On 10/27/2024 6:22 PM, wij wrote:
On Sun, 2024-10-27 at 20:40 -0400, jseigh wrote:
On 10/27/24 19:09, jseigh wrote:
On 10/8/24 21:40, Lynn McGuire wrote:
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
...
p = p->next; // valid, inside while true block
}
I should add, the p->next is also nullable so the
assignment to p makes it nullable again. The
goal is to make the code look like normal code
while ensuring null pointer safety.
C++ is an object oriented language.
In C++, programming in C concept makes little sense.
Well, sometimes for some exotic algorithms we can steal a bit and say
this is a null (the bit is set) even though its not equal to nullptr.
It's null but it still points to a node. This can be called a so-called
dummy node, sometimes. The logic with dummy nodes can be beneficial.
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
On 10/30/2024 9:56 AM, jseigh wrote:
On 10/28/24 12:25, jseigh wrote:
...
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.
Are you referring to DWCAS? There has to be a compiler out there that
can handle it wrt it being, always lock-free ala:
__________________
0 for the built-in atomic types that are never lock-free,
1 for the built-in atomic types that are sometimes lock-free,
2 for the built-in atomic types that are always lock-free.
__________________
Damn it! ;^/
You create a new nullable attribute for pointers. That
would make the pointer behave like void* instead of T*.
You could move, copy, and compare, but you could not
dereference them. If you wanted to dereference them
you would have to apply a special not_null unary predicate
to them. What makes it special is the boolean result
is only valid inside a conditional expression. It's
not copyable or referencable. You could have 1 or
more of these in a conditional expression along with
ordinary predicates with the restriction that the
expression has to be formed such that if any of the
not_null terms are false, the expression has to
evaluate as false.
The other thing that makes not_null is that inside
if the conditional statements true blocks, the
nullable pointer gets it T* properties back, so
you can dereference it, but again only in the
true blocks. So for example
nullable T* p = &something;
T p2 = *p; // invalid, compiler thinks you are trying
// do dereference void*
not_null(p); // invalid, not inside conditional expression
if (not_null(p)
p2 = *p; // valid
else
p2 = *p; // invalid
Traversing a linked list would look like
T* p = head;
while (not_null(p)) {
...
p = p->next; // valid, inside while true block
}
not_null would look like
__predicate_bool not_null(T *&)
It would make a const copy of T*, test that,
cast to T*, use it for the true block.
So no NPEs possible for pointer with this
attribute.
On 11/8/2024 3:13 PM, wij wrote:
I need examples to understand what you mean. I have not touched thread >issues for many years
, but hope I can help.
iirc, it was a base class that called its pure virtual thread entry
function _before_ its derived class had a chance to fully complete its
ctor. It's been a while since I have encountered this nasty scenario.
On 11/8/2024 4:19 PM, wij wrote:
class BaseThread {
public:
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
public:
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
On 11/9/2024 8:23 AM, Scott Lurndal wrote:
"Chris M. Thomasson" <[email protected]> writes:
On 11/8/2024 4:19 PM, wij wrote:
class BaseThread {
public:
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
public:
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread >>> is ready for it. I have had to debug horror shows with threads created
in ctors before...
It's really very simple. Use a two-phase approach. The run thread
is created and immediately waits on a condition variable. When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
"Chris M. Thomasson" <[email protected]> writes:
On 11/9/2024 8:23 AM, Scott Lurndal wrote:
"Chris M. Thomasson" <[email protected]> writes:
On 11/8/2024 4:19 PM, wij wrote:
class BaseThread {
public:
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
public:
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
You just have to make sure that the thread is created after class Thread >>>> is ready for it. I have had to debug horror shows with threads created >>>> in ctors before...
It's really very simple. Use a two-phase approach. The run thread
is created and immediately waits on a condition variable. When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
The idea is that your class inherits from the thread class ahead of
any other classes which encapsulates the thread creation in the
thread class constructor, which is the natural place to look for
it.
On 11/9/2024 4:01 AM, [email protected] wrote:
On Fri, 8 Nov 2024 12:40:36 -0800
"Chris M. Thomasson" <[email protected]> gabbled:
On 11/8/2024 6:54 AM, [email protected] wrote:
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some
edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race >conditions... :^)
Not sure what you mean here... It's all about minimizing slow-paths, and >maximizing fast-paths. :^)
On 10/28/24 12:25, jseigh wrote:
...
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.
On 10/30/2024 11:56 AM, jseigh wrote:
On 10/28/24 12:25, jseigh wrote:
...
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
Lynn McGuire <[email protected]> writes:
On 10/30/2024 11:56 AM, jseigh wrote:https://en.wikipedia.org/wiki/ABA_problem
On 10/28/24 12:25, jseigh wrote:
...
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
Lynn
On 10/30/2024 11:56 AM, jseigh wrote:
On 10/28/24 12:25, jseigh wrote:
...
The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.
The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.
At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.
I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance. I don't think will
solve all the issues they think it will. I can come up
with some pretty trivial examples that will break their
proposed solutions. I think they are unicorn hunting here.
One of the issues they brought up is the ABA problem. Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues. Kind of hard
to take the pointer provenance problem seriously.
Joe Seigh
What is the ABA problem ?
On 11/8/2024 3:09 PM, wij wrote:
The fun part about std::atomic and std::thread is that they are all in
one standard. POSIX requires a compliant compiler and system. Iirc, >std::atomic is not 100% guaranteed to work with PThreads. It does with >std::threads...
On 11/11/2024 1:56 AM, [email protected] wrote:
On Sat, 9 Nov 2024 12:39:19 -0800
"Chris M. Thomasson" <[email protected]> boring babbled:
On 11/9/2024 4:01 AM, [email protected] wrote:
On Fri, 8 Nov 2024 12:40:36 -0800
"Chris M. Thomasson" <[email protected]> gabbled:
On 11/8/2024 6:54 AM, [email protected] wrote:
https://en.wikipedia.org/wiki/ABA_problem
Why's it a problem? Its why mutexes exist.
What if one did not want to use a mutex?
Then put up with the faff of semaphores or atomics and risk creating some >>>> edge case race conditions.
Using lock/wait/obstruction-free algorithms is not about creating race
conditions... :^)
3 level locking generally solves most problems IME. C++ didn't have until >2017
when shared_mutex came along even though pthreads has had it forever and was >> a reason people kept using pthreads in C++.
Not sure what you mean by 3 level locking. Are you talking about
PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty
conditions that used recursive locks. Ouch.
Fast paths are no use if the thread doesn't have anything else to do anyway. >>
If a thread has nothing to do, it can wait, for something to do. ;^)
Think of an empty queue condition. A thread can just wait on it...
"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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 17:40:46 |
| Calls: | 12,103 |
| Calls today: | 3 |
| Files: | 15,004 |
| Messages: | 6,518,073 |