FAQ
I was perusing the current code reviews and noticed that a cloneBytes
function has been included in the linked CL. Can someone tell me why use
that rather than append([]byte(nil), b...) since as far as I can see it
has the same behaviour?

Is it because of the fast path where b == nil?

func cloneBytes(b []byte) []byte {
if b == nil {
return nil
} else {
c := make([]byte, len(b))
copy(c, b)
return c
}
}


https://codereview.appspot.com/7962044/

--
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

  • Carlos Castillo at Mar 26, 2013 at 5:28 am
    Append essentially does the following: http://play.golang.org/p/WFaGXhFvlc

    My guess is that there are three reasons to have cloneBytes:

    1. If you notice the created new slice in append has extra capacity (to
    be used on further appends), but it seems this use case is meant to copy a
    slice (no extra space needed)
    2. The comparison inside cloneBytes is simpler than in append (compare
    to 0), and may get optimized out after inlining (the calling code already
    checks for nil in some points)
    3. In the real append, the amount of extra space is not a constant
    number of additional elements or a constant scale, but is chosen based on
    slice size resulting in at least one extra branch in the code

    In the CL referenced it looks like the purpose of cloneBytes is to make a
    copy of the data that is not going to be appended to. Although #2 and #3
    may be able to go away in certain places with a good compiler, #1 will
    always be true, as append will always allocated some extra slots in case of
    future appends, to avoid the allocations and copies involved in appending
    to a full slice.
    On Monday, March 25, 2013 6:09:56 PM UTC-7, kortschak wrote:

    I was perusing the current code reviews and noticed that a cloneBytes
    function has been included in the linked CL. Can someone tell me why use
    that rather than append([]byte(nil), b...) since as far as I can see it
    has the same behaviour?

    Is it because of the fast path where b == nil?

    func cloneBytes(b []byte) []byte {
    if b == nil {
    return nil
    } else {
    c := make([]byte, len(b))
    copy(c, b)
    return c
    }
    }


    https://codereview.appspot.com/7962044/
    --
    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.
  • David DENG at Mar 26, 2013 at 6:54 am
    cloneBytes(b) can be replaced by(or implemented as) append([[]byte(nil),
    b...)

    David
    On Tuesday, March 26, 2013 1:28:30 PM UTC+8, Carlos Castillo wrote:

    Append essentially does the following: http://play.golang.org/p/WFaGXhFvlc

    My guess is that there are three reasons to have cloneBytes:

    1. If you notice the created new slice in append has extra capacity
    (to be used on further appends), but it seems this use case is meant to
    copy a slice (no extra space needed)
    2. The comparison inside cloneBytes is simpler than in append (compare
    to 0), and may get optimized out after inlining (the calling code already
    checks for nil in some points)
    3. In the real append, the amount of extra space is not a constant
    number of additional elements or a constant scale, but is chosen based on
    slice size resulting in at least one extra branch in the code

    In the CL referenced it looks like the purpose of cloneBytes is to make a
    copy of the data that is not going to be appended to. Although #2 and #3
    may be able to go away in certain places with a good compiler, #1 will
    always be true, as append will always allocated some extra slots in case of
    future appends, to avoid the allocations and copies involved in appending
    to a full slice.
    On Monday, March 25, 2013 6:09:56 PM UTC-7, kortschak wrote:

    I was perusing the current code reviews and noticed that a cloneBytes
    function has been included in the linked CL. Can someone tell me why use
    that rather than append([]byte(nil), b...) since as far as I can see it
    has the same behaviour?

    Is it because of the fast path where b == nil?

    func cloneBytes(b []byte) []byte {
    if b == nil {
    return nil
    } else {
    c := make([]byte, len(b))
    copy(c, b)
    return c
    }
    }


    https://codereview.appspot.com/7962044/
    --
    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 Mar 26, 2013 at 6:13 am
    It preserves the nil-ness.

    With append: http://play.golang.org/p/Kf27Wthe23
    On Mon, Mar 25, 2013 at 6:09 PM, Dan Kortschak wrote:

    I was perusing the current code reviews and noticed that a cloneBytes
    function has been included in the linked CL. Can someone tell me why use
    that rather than append([]byte(nil), b...) since as far as I can see it
    has the same behaviour?

    Is it because of the fast path where b == nil?

    func cloneBytes(b []byte) []byte {
    if b == nil {
    return nil
    } else {
    c := make([]byte, len(b))
    copy(c, b)
    return c
    }
    }


    https://codereview.appspot.com/7962044/

    --
    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.
  • Dan Kortschak at Mar 26, 2013 at 9:45 am
    Ahhhh, I only looked at t from the other direction. Thanks.
    On 26/03/2013, at 4:43 PM, "Brad Fitzpatrick" wrote:

    It preserves the nil-ness.
    --
    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.
  • John Arbash Meinel at Mar 26, 2013 at 11:25 am

    On 2013-03-26 10:13, Brad Fitzpatrick wrote:
    It preserves the nil-ness.

    With append: http://play.golang.org/p/Kf27Wthe23
    When I run that, it tells me "nil=true" for both code paths.

    So it would appear that append() also preserves nil as long as you are
    actually appending nothing.

    John
    =:->



    --
    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.
  • Dan Kortschak at Mar 26, 2013 at 11:51 am
    It preserves the state of nil-ness in the original slice. Try replacing the append with the cloneBytes func and see where they differ.
    On 26/03/2013, at 9:55 PM, "John Arbash Meinel" wrote:

    So it would appear that append() also preserves nil as long as you are
    actually appending nothing.
    --
    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
postedMar 26, '13 at 1:10a
activeMar 26, '13 at 11:51a
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase