Just to clarify: From what I can tell, I am (in this revival of the thread)
the only one on the "mixing receiver kinds is sometimes necessary, so we
shouldn't caution against it" side of the table and indeed opened it. As
such, I'm already on the back foot. I tried to at least acknowledge the
argum
You are trying to prove something nobody actually doubted. Meanwhile, you
seem to be aggressively ignoring what I actually wrote. I find that pretty
rude.
On Tue, 8 Oct 2024 at 01:15, robert engels wrote:
> Here is a slightly easier version to see the race between the mutation and
> the copy for
Here’s an interesting post from an industry legend on exceptions
https://www.linkedin.com/posts/bjarnestroustrup_c-exceptions-for-smaller-firmware-khalil-activity-7243244721911865344-J7yy?utm_source=share&utm_medium=member_ios
If the linked in post isn’t readily accessible the underlying talk he
Here is a slightly easier version to see the race between the mutation and the
copy for the value method:
package main
import (
"log"
"sync"
)
type S struct {
lock *sync.Mutex
index int
values [128]int
}
func (s *S) mutate() {
s.lock.Lock();
defer s.lock.Unlock();
I wrote a simple test. Sure enough it fails, and it reports a data race.
package main
import (
"log"
"sync"
)
type S struct {
sync.Mutex
index int
values [128]int
}
func (s *S) mutate() {
s.Lock();
defer s.Unlock();
s.index++;
for i:=0; i< 128; i++ {
I am fairly certain if you mix pointer and receiver methods and the receiver methods mutate - even if you synchronize those you will get a data race calling the value methods. It must afaik as the runtime/compiler has no implicit synchronization when creating the copies. That is a data race. On Oct
My argument had nothing to do with synchronization.
FTR I find the synchronization argument also extremely dubious. By that
argument, you also can't pass the address to a local variable to another
function, when using it as a value elsewhere. It's a weird argument to
make. time.Time uses a mix of
I am pretty sure it is immaterial. If the object isn’t immutable any copy or mutation operation needs to be synchronized. But the problem afaik is that you can’t control synchronization when the object is copied for a value receiver - which means you cant properly synchronize when you have pointer
No offence, but I made an argument. You don't have to agree with the
argument and it might be wrong. But to convince me, at least, that argument
would need to actually be referenced.
I gave reasons why, in my opinion, *not* mixing value and pointer receivers
sometimes leads to incorrect code. So a
Many places and books I've read generally say: If a function needs to
update a variable, or if an argument is so large that we want to avoid
copying it, we should pass the pointer. Same for methods (pointer
receiver). (The Go programming language book).
About mixing "value receiver" and "pointe
With Hacktoberfest approaching I prepared a few repositories for people to
contribute to. It's mostly Go, but other no-code contributions are welcome
as well.
- https://github.com/plutov/formulosity
- https://github.com/plutov/ultrafocus
- https://github.com/plutov/paypal
- https://g
In some cases your application doesn’t need Redis, and internal in-memory
map with locks and expiration will suffice.
For example you already know the size of the map and you don’t need to
store a lot of data. Use cases could be IP rate limiting, or any other
short-lived data.
Here is how you
Mixing pointer and value receivers can be race-prone, because of the
copying involved in passing value receivers.
On Mon, Oct 7, 2024 at 12:03 PM 'Axel Wagner' via golang-nuts
wrote:
>
> To be honest, I always found this recommendation a little bit strange,
> personally.
>
> I'll note that the s
To be honest, I always found this recommendation a little bit strange,
personally.
I'll note that the standard library does not really keep to this either.
For example, time.Time.UnmarshalText (obviously) has a pointer-receiver,
while almost all other methods on time.Time have a value receiver.
An
On Mon, Oct 7, 2024 at 10:29 AM Ken Lee wrote:
>
> ---
> There is a consideration to make, though: historically it has been considered
> bad form in Go to give a type a mix of value and pointer receivers in methods
> without a very specific reason for doing so.
> ---
>
> Is this still the case n
---
There is a consideration to make, though: historically it has been
considered bad form in Go to give a type a mix of value and pointer
receivers in methods without a very specific reason for doing so.
---
Is this still the case now? As in 2024.
On Sunday 13 January 2013 at 7:03:29 am UTC+8
Thanks Jason, this is great feedback.
I've added a context argument in https://github.com/twpayne/go-heap/pull/6.
Regards,
Tom
On Sunday, October 6, 2024 at 9:58:43 PM UTC+2 Jason E. Aten wrote:
> Hi Tom,
>
> This is an interesting project.
>
> Per your request for feedback: on quick inspection
17 matches
Mail list logo
