FAQ
a wired question : about this function

func (b *Reader) Buffered() int

normally this function return the size of the buffer

And look now to this code :

file, err := os.Open("fuck.text")
  bufferedReader := bufio.NewReader(file)
  fmt.Println(bufferedReader.Buffered())

normally the size of the buffer most be the defaukt size 4096 bytes but i
Buffered function return me 0 .


--
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/d/optout.

Search Discussions

  • Jesse McNelis at Sep 3, 2015 at 12:27 pm

    On Thu, Sep 3, 2015 at 10:21 PM, WALID BELRHALMIA wrote:
    a wired question : about this function

    func (b *Reader) Buffered() int

    normally this function return the size of the buffer
    It's not that size of the buffer, it's the number of bytes currently
    in the buffer.
    And look now to this code :

    file, err := os.Open("fuck.text")
    bufferedReader := bufio.NewReader(file)
    fmt.Println(bufferedReader.Buffered())

    normally the size of the buffer most be the defaukt size 4096 bytes but i
    Buffered function return me 0 .
    It's zero because you haven't read any bytes yet. So no bytes from the
    file have yet been read in to the buffer.

    --
    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/d/optout.
  • WALID BELRHALMIA at Sep 3, 2015 at 12:30 pm
    @Jesse ah as i had understand when we do
    bufferedReader := bufio.NewReader(file)


    we read from the disk into the buffer ,

    so when we call the read function cpu use buffer to read and print the
    result

    --
    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/d/optout.
  • WALID BELRHALMIA at Sep 3, 2015 at 12:37 pm
    @jesse you wont to tell me that when we call read function on a
    Bufio.Reader we put the byte from the file into the buffer , and when all
    the buffer size is plenty we read from the buffer into the p slice


    >

    --
    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/d/optout.
  • Konstantin Khomoutov at Sep 3, 2015 at 12:58 pm

    On Thu, 3 Sep 2015 05:37:14 -0700 (PDT) WALID BELRHALMIA wrote:

    @jesse you wont to tell me that when we call read function on a
    Bufio.Reader we put the byte from the file into the buffer , and when
    all the buffer size is plenty we read from the buffer into the p
    slice
    Calm down and try to absorb the idea that buffering works (almost)
    completely transparently.

    The whole point of buffering is to provide faster access to a resource
    which has high cost of being accessed in terms of performance.
    Say, you need to read a file on the file system one byte at a time.
    If you weren't using buffering, reading each byte would actually reach
    for the kernel asking it to reach for the file system layer and so on.
    Now you add buffering. Then reading the first byte in the sequence
    will -- transparently for you -- ask the kernel for more data, say,
    4096 bytes; these bytes will be saved into the buffer, and the read
    operation will return the first byte -- just what you asked for.
    But the difference becomes obvious when you try reading the next byte:
    it will be served right from the buffer, and this means no kernel is
    involved at all -- the access will be super fast. When the buffer is
    drained, an attempt to read the data past what's buffered will trigger
    real access to the kernel, its filesystem layer and so on, but again
    more data than you've requested will be asked for, acquired and
    buffered, and the process repeats.

    What this means for you, is that you almost never want to know how many
    bytes are not yet read among those buffered. Right now I even fail to
    fancy what that would be really useful for, to be honest.

    So possibly you just should stop worrying about these details and just
    use buffering to read data in chunks of whatever size is convenient for
    you.

    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 3, '15 at 12:22p
activeSep 3, '15 at 12:58p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase