You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there any reason why the compact function does not follow the Java's ByteBuffer's compact method?
Where currently it does:
Compacts this ByteBuffer to be backed by a ByteBuffer#buffer of its contents' length. Contents are the bytes between ByteBuffer#offset and ByteBuffer#limit. Will set offset = 0 and limit = capacity and adapt ByteBuffer#markedOffset to the same relative position if set.
While in Java it does:
The bytes between the buffer's current position and its limit, if any, are copied to the beginning of the buffer. That is, the byte at index p = position() is copied to index zero, the byte at index p + 1 is copied to index one, and so forth until the byte at index limit() - 1 is copied to index n = limit() - 1 - p. The buffer's position is then set to n+1 and its limit is set to its capacity. The mark, if defined, is discarded.
The buffer's position is set to the number of bytes copied, rather than to zero, so that an invocation of this method can be followed immediately by an invocation of another relative put method.
The text was updated successfully, but these errors were encountered:
There is no specific reason. The current implementation is simply what I needed, and I took the term "compact" for it. I see, however, that there is no easy alternative available currently. Could be added, of course, something like ByteBuffer#move(offset=0) (named after memmove).
Is there any reason why the compact function does not follow the Java's ByteBuffer's compact method?
Where currently it does:
While in Java it does:
The text was updated successfully, but these errors were encountered: