They are invoked with the maximum size of the data to be added, and a
callable that generates that data, like this:
buffer.AppendData(10, [] (rtc::ArrayView<uint8_t> av) {
for (uint8_t i = 0; i != 5; ++i)
av[i] = i;
return 5;
});
The callable returns the number of bytes actually written, and the
final Buffer size will be adjusted accordingly. SetData and AppendData
both return the number of bytes added (i.e. the return value of the
callable).
These versions will be useful when converting AudioEncoder::Encode to use Buffer rather than raw pointers.
Also added a few tests for the new functionality.
Review URL: https://codereview.webrtc.org/1717273002
Cr-Commit-Position: refs/heads/master@{#11733}
Also added a test for Clear to ensure this invariant holds.
With this change, it is easy to empty a Buffer and reuse its storage. Further down the line, code filling data into a Buffer could be written to just append to it, with the caller determining if the Buffer should first be cleared or not.
There is currently only one use of Buffer::Clear (in AudioEncoderCopyRed::Reset()) and it should benefit from the change, by not requiring a reallocation after Reset.
Review URL: https://codereview.webrtc.org/1707693002
Cr-Commit-Position: refs/heads/master@{#11680}
We'd like to completely replace rtc::scoped_ptr with std::unique_ptr.
This is a first trial CL to see if using unique_ptr causes any
problems.
(As a side effect of removing the scoped_ptr.h include in buffer.h,
I had to fix broken includes in no less than three files.)
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1687833006
Cr-Commit-Position: refs/heads/master@{#11588}
There's no reason not to use std::move instead now that we can use the
C++11 standard library.
BUG=webrtc:5373
Review URL: https://codereview.webrtc.org/1531013003
Cr-Commit-Position: refs/heads/master@{#11225}
We can now use std::move instead!
This CL leaves the Pass methods in place; a follow-up CL will add deprecation annotations to them.
Review URL: https://codereview.webrtc.org/1460043002
Cr-Commit-Position: refs/heads/master@{#11064}
With it removed, you can now use it with scoped_refptr by wrapping it in
an rtc::RefCountedObject<rtc::Buffer>.
BUG=
Review URL: https://codereview.webrtc.org/1414053003
Cr-Commit-Position: refs/heads/master@{#10386}
This CL makes two changes to rtc::Buffer that have had to wait for
Chromium's use of it to be modernized:
1. Change default return type of rtc::Buffer::data() from char* to
uint8_t*. uint8_t is a more natural type for bytes, and won't
accidentally convert to a string. (Chromium previously expected
the default return type to be char, which is why
rtc::Buffer::data() initially got char as default return type in
9478437f, but that's been fixed now.)
2. Stop accepting void* inputs in constructors and methods. While
this is convenient, it's also dangerous since any pointer type
will implicitly convert to void*.
(This was previously committed (9e1a6d7c) but had to be reverted
(cbf09274) because Chromium on Android wasn't quite ready for it).
TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47109004
Cr-Commit-Position: refs/heads/master@{#9132}
This CL makes two changes to rtc::Buffer that have had to wait for
Chromium's use of it to be modernized:
1. Change default return type of rtc::Buffer::data() from char* to
uint8_t*. uint8_t is a more natural type for bytes, and won't
accidentally convert to a string. (Chromium previously expected
the default return type to be char, which is why
rtc::Buffer::data() initially got char as default return type in
9478437f, but that's been fixed now.)
2. Stop accepting void* inputs in constructors and methods. While
this is convenient, it's also dangerous since any pointer type
will implicitly convert to void*.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44269004
Cr-Commit-Position: refs/heads/master@{#9121}
We used to accept void* (until 9478437f), and we'll have to continue
to do so for a little while longer, until Chromium doesn't need it
anymore.
TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48179004
Cr-Commit-Position: refs/heads/master@{#9035}
1. Constructors, SetData(), and AppendData() now accept uint8_t*,
int8_t*, and char*. Previously, they accepted void*, meaning that
any kind of pointer was accepted. I think requiring an explicit
cast in cases where the input array isn't already of a byte-sized
type is a better compromise between convenience and safety.
2. data() can now return a uint8_t* instead of a char*, which seems
more appropriate for a byte array, and is harder to mix up with
zero-terminated C strings. data<int8_t>() is also available so
that callers that want that type instead won't have to cast, as
is data<char>() (which remains the default until all existing
callers have been fixed).
3. Constructors, SetData(), and AppendData() now accept arrays
natively, not just decayed to pointers. The advantage of this is
that callers don't have to pass the size separately.
4. There are new constructors that allow setting size and capacity
without initializing the array. Previously, this had to be done
separately after construction.
5. Instead of TransferTo(), Buffer now supports swap(), and move
construction and assignment, and has a Pass() method that works
just like std::move(). (The Pass method is modeled after
scoped_ptr::Pass().)
R=jmarusic@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42989004
Cr-Commit-Position: refs/heads/master@{#9033}
And add a constructor for creating an uninitialized Buffer of a
specified size.
(I intend to follow up with more Buffer changes, but since it's rather
widely used, the rename is quite noisy and works better as a separate
CL.)
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48579004
Cr-Commit-Position: refs/heads/master@{#8841}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8841 4adac7df-926f-26a2-2b94-8c16560cd09d
Mostly this consists of marking functions with override when
applicable, and moving function bodies from .h to .cc files.
Not inlining virtual functions with simple bodies such as
{ return false; }
strikes me as probably losing more in readability than we gain in
binary size and compilation time, but I guess it's just like any other
case where enabling a generally good warning forces us to write
slightly worse code in a couple of places.
BUG=163
R=kjellander@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47429004
Cr-Commit-Position: refs/heads/master@{#8656}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8656 4adac7df-926f-26a2-2b94-8c16560cd09d
