FAQ
Just curious why the buffer field of Part is a *bytes.Buffer. On line 92,
they have buffer: new(bytes.Buffer). I know there is probably a good reason
for that decision, but to me it seems that if they made it a bytes.Buffer
instead, they could have saved a heap allocation. As a bonus, the zero
bytes.Buffer object is ready to use, so the buffer field would not have to
be explicitly initialized that is.

bp := &Part{Header: make(map[string][]string), mr: mr}

would be enough. Of course, this would increase the size of the Part
struct, but since the relationship between Part struct and bytes.Buffer is
1:1, it seems that no memory footprint is saved making it a pointer. But
with Go type inference, its awfully easy to do something like this:

buffer bytes.Buffer

bufferReference := buffer // Oops, we want bufferReference to point to
buffer!
bufferReference.Read(...) // Oops this will not work as author intended.

So maybe Part.buffer was made a pointer for this reason?


Any thoughts on this?


--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Brad Fitzpatrick at Apr 10, 2013 at 12:06 am
    That was like the 1st code I ever wrote and I didn't know what I was doing.
    :-)

    https://code.google.com/p/go/source/detail?r=4ab63d961945#

    File a bug (now) or send a CL (after Go 1.1 is out) to change it.



    On Tue, Apr 9, 2013 at 4:04 PM, Travis Keep wrote:

    Just curious why the buffer field of Part is a *bytes.Buffer. On line 92,
    they have buffer: new(bytes.Buffer). I know there is probably a good reason
    for that decision, but to me it seems that if they made it a bytes.Buffer
    instead, they could have saved a heap allocation. As a bonus, the zero
    bytes.Buffer object is ready to use, so the buffer field would not have to
    be explicitly initialized that is.

    bp := &Part{Header: make(map[string][]string), mr: mr}

    would be enough. Of course, this would increase the size of the Part
    struct, but since the relationship between Part struct and bytes.Buffer is
    1:1, it seems that no memory footprint is saved making it a pointer. But
    with Go type inference, its awfully easy to do something like this:

    buffer bytes.Buffer

    bufferReference := buffer // Oops, we want bufferReference to point to
    buffer!
    bufferReference.Read(...) // Oops this will not work as author intended.

    So maybe Part.buffer was made a pointer for this reason?


    Any thoughts on this?


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brad Fitzpatrick at Apr 10, 2013 at 12:07 am
    (Go code...)


    On Tue, Apr 9, 2013 at 5:06 PM, Brad Fitzpatrick wrote:

    That was like the 1st code I ever wrote and I didn't know what I was
    doing. :-)

    https://code.google.com/p/go/source/detail?r=4ab63d961945#

    File a bug (now) or send a CL (after Go 1.1 is out) to change it.



    On Tue, Apr 9, 2013 at 4:04 PM, Travis Keep wrote:

    Just curious why the buffer field of Part is a *bytes.Buffer. On line 92,
    they have buffer: new(bytes.Buffer). I know there is probably a good reason
    for that decision, but to me it seems that if they made it a bytes.Buffer
    instead, they could have saved a heap allocation. As a bonus, the zero
    bytes.Buffer object is ready to use, so the buffer field would not have to
    be explicitly initialized that is.

    bp := &Part{Header: make(map[string][]string), mr: mr}

    would be enough. Of course, this would increase the size of the Part
    struct, but since the relationship between Part struct and bytes.Buffer is
    1:1, it seems that no memory footprint is saved making it a pointer. But
    with Go type inference, its awfully easy to do something like this:

    buffer bytes.Buffer

    bufferReference := buffer // Oops, we want bufferReference to point to
    buffer!
    bufferReference.Read(...) // Oops this will not work as author intended.

    So maybe Part.buffer was made a pointer for this reason?


    Any thoughts on this?


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at Apr 10, 2013 at 2:48 am

    On 10 April 2013 10:07, Brad Fitzpatrick wrote:

    (Go code...)

    I was going to say, you certainly hit the ground running. ;-)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 9, '13 at 11:04p
activeApr 10, '13 at 2:48a
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase