hmm, suppose I have struct X that have 50 attributes that represent 50 cols
in db, struct Y 4 attributes, 4 cols
and I have :
func FindX() *X {}
func FindXs() []*X {}
func FindY() *Y {}
func FindYs() []*Y {}
I don't care about mutable, since this is only a getter func, or should I
care?
sinc
There is an open issue regarding this behaviour.
https://github.com/golang/go/issues/21922
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr..
If I need to mutate elements of an array of by-value structs, I'll
usually do this: https://play.golang.org/p/YUFsOkvKQ4
Then for most of the body of the loop, you can use i and t as if you'd
ranged over pointers
to elements of the slice (no need to explicitly assign to the element).
On 20 Octob
Which is a good thing: you have to alter the slice explicitly:
https://play.golang.org/p/KE2Davl06t
When you pass a pointer, you also pass the right to modify the pointee -
ownership.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscr
https://play.golang.org/p/xILWETuAii
I have started to use non pointer slices much more as of late.
Every time I bother measuring it is always faster and it is better for the
GC (usually, caveats apply).
It also, perhaps naively, feels safer... :)
fre 20 okt. 2017 kl 13:41 skrev Juliusz Chrobocz
>> What size of T affects is appending/inserting/deleting items to/from
>> the slice. If one passes around a value of type []T, those operations
>> are probably performed on the value.
> On the flip side, []*T will be less cache/TLB/GC friendly than
> []T, unless T is much larger than a ptr.
On t
On Fri, 20 Oct 2017 09:09:15 - Jan Mercl <0xj...@gmail.com> wrote:
Jan Mercl writes:
>
> On Fri, Oct 20, 2017 at 11:07 AM Bakul Shah wrote:
>
> > On the flip side, []*T will be less cache/TLB/GC friendly than
> > []T, unless T is much larger than a ptr. You are also
> > allocating an extra p
On Fri, Oct 20, 2017 at 11:07 AM Bakul Shah wrote:
> On the flip side, []*T will be less cache/TLB/GC friendly than
> []T, unless T is much larger than a ptr. You are also
> allocating an extra pointer per element. For small slices it
> probably doesn't matter much either way but when slices hold
On Fri, 20 Oct 2017 08:49:16 - Jan Mercl <0xj...@gmail.com> wrote:
Jan Mercl writes:
>
> On Fri, Oct 20, 2017 at 10:39 AM Ian Davis wrote:
>
> > How does that affect the size of []T or []*T ?
>
> No one said it does. What size of T affects is appending/inserting/deleting
> items to/from the
On Fri, Oct 20, 2017 at 10:39 AM Ian Davis wrote:
> How does that affect the size of []T or []*T ?
No one said it does. What size of T affects is appending/inserting/deleting
items to/from the slice. If one passes around a value of type []T, those
operations are probably performed on the value.
On Fri, 20 Oct 2017, at 06:34 AM, Jan Mercl wrote:
> On Fri, Oct 20, 2017 at 7:25 AM Feby Tanzil
> wrote:>
> > Which is better & preferable in Go?
>
> Depends on size of T.
How does that affect the size of []T or []*T ?
Ian
--
You received this message because you are subscribed to the Goog
Thanks for suggestion, I have change license to MIT
在 2017年10月20日星期五 UTC+8下午3:53:52，Dave Cheney写道：
>
> Thank you for sharing your package. Would you consider re-licencing it
> under a more permissive licence like MIT or BSD?
>
> On Friday, 20 October 2017 17:37:07 UTC+10, Ally Dale wrote:
>>
>> H
Thank you for sharing your package. Would you consider re-licencing it
under a more permissive licence like MIT or BSD?
On Friday, 20 October 2017 17:37:07 UTC+10, Ally Dale wrote:
>
> Hello, everyone,
> It's my pleasure to announce that I have just released a stable version of
> full-feature se
On Fri, Oct 20, 2017 at 9:37 AM Ally Dale wrote:
FTR: OP probably means encoding/binary where std.binary is written instead
for unknown reasons.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop re
That's a great way to think about it the 'cost' of copying vs passing the
address. Thank you.
On Friday, 20 October 2017 17:09:49 UTC+10, Feby Tanzil wrote:
>
> so if I have like 50 attributes then pointer is preferable then
> How big is big? I took from
> https://github.com/golang/go/wiki/CodeR
On 19 October 2017 at 16:01, wrote:
> I add this for others having problems with non capture groups when using
> regular expressions in google scripts:
>
> I struggled trying to debug why this simple regex would not work for me in
> google application script: /(?:SKU\: \*)(\d*)/ [in this case i
On 20 October 2017 at 05:15, Feby Tanzil wrote:
> Hi,
>
> I got vague answers in the internet over this.
> Which is better & preferable in Go?
>
> type T struct {
> // some attributes
> ...
> }
>
> func a() []T {
>
> }
>
> func b() []*T {
>
> }
Both are plausible. It depends what you're going t
Hello, everyone,
It's my pleasure to announce that I have just released a stable version of
full-feature serialization package to replace std.binary.
You can find the project here:
https://github.com/vipally/binary
My trouble is that when I want to transport a go data on network between
golang ap
so if I have like 50 attributes then pointer is preferable then
How big is big? I took
from https://github.com/golang/go/wiki/CodeReviewComments for receiver, is
this applicable for this too?
Assume it's equivalent to passing all its elements as arguments to the
> method. If that feels too larg
19 matches
Mail list logo
