This is not a question, just a hint. Recently I wrote a program which
extracts attachments from multipart mime mails stored as files. I did
this since there are often mails with many attachments (e.g., pictures),
and before all, they have unwanted filenames - windows-encoded, strange
characters,
Google's style guide is a popular reference for Go programmers. In it, they
list off a number of scenarios where one would use a value receiver vs a
pointer receiver. But, ultimately, they end the list with "when in doubt,
use a pointer receiver".
In my experience, I've noticed the majority of
> I'd be curious to hear thoughts on this topic.
There was a fun talk at GopherConAU just a few days ago: "What's
The Point? A Guide To Using Pointers Without Panicking" (talk
description at https://gophercon.com.au/) When the recordings are
all finalised I can reply to this thread with a link.
Any updates on ROC for golang? I think our services encountered some
scalability issues, similar to https://github.com/golang/go/issues/17969
On Tuesday, May 16, 2017 at 10:06:25 PM UTC+8 Ian Lance Taylor wrote:
> On Tue, May 16, 2017 at 2:01 AM, wrote:
> >
> > Generational and Compact gc have
That's a really good question, IMO.
I have been wondering for a while why the advice against mixing pointer and
value receivers, which GoLang so often flags me for doing.
Ideally I think that I would like to be able use value receivers most of
the time when I want the method to leave the
On Mon, 2023-11-13 at 19:38 -0800, Mike Schinkel wrote:
> I have been wondering for a while why the advice against mixing
> pointer and value receivers, which GoLang so often flags me for
> doing.
https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race
--
You received this message
To me this is a limitation of the compiler. If a passed argument is unused it
doesn’t even need to be created. Similarly if only a few fields are used in a
called function a sparse data object can be sent. It only becomes a race if the
data being copied is actually used - then the race is also
Similarly, even in a single threaded Java program objects are copied/moved
behind the scenes - these don’t generate race conditions as the runtime ensures
there isn’t one.
> On Nov 13, 2023, at 10:47 PM, Robert Engels wrote:
>
> To me this is a limitation of the compiler. If a passed
Lastly, the only reason that changing to a pointer receiver “solves” the race
is because the field in the object isn’t accessed - something the compiler
could detect in the other version as well.
> On Nov 13, 2023, at 10:50 PM, Robert Engels wrote:
>
> Similarly, even in a single threaded
I've always try to start with a value receiver,
change to pointer receiver (EVERYWHERE - do not mix pointer and value
receivers!),
when the method modifies the sruct's members (or just have a sync.Mutex
member),
or used as interface (i.e. error - for comparison to nil)
Oliver Lowe a következőt
> [..] when the method modifies the sruct's members (or just have a
sync.Mutex member)
>From my experience, these are the major points for defaulting to use the
pointer receiver "when in doubt". The difference between "func (t T) Foo"
and "func (t *T) Foo", is often too subtle to spot a bug in
Hi!
Not an expert at all, but it seems the format is
"package-qualified.identifier=value", with value being able to just contain
spaces out of the box, so running:
go run -ldflags="-X 'main.MyVar=this is a string'" main.go
works for me. Note that for parsing the whole thing correctly, the whole
Yep, works like a charm. thx!
On Mon, Nov 13, 2023 at 4:34 AM Michel Levieux
wrote:
> Hi!
>
> Not an expert at all, but it seems the format is
> "package-qualified.identifier=value", with value being able to just contain
> spaces out of the box, so running:
>
> go run -ldflags="-X
13 matches
Mail list logo
