docs/develop: Mass directory restructure.
Now vaguely follows the tree structure of "src", with the exception of directories that described subsystems spanning more than one "kit" or "server" (e.g. "media", "midi", "bluetooth") -- these have been left as their own top-level directory within docs/develop.
This commit is contained in:
Augustin Cavalier
@@ -0,0 +1,79 @@
|
||||
<HTML>
|
||||
<!-- $Id: BAutolockUseCases.html 10 2002-07-09 12:24:59Z ejakowatz $ -->
|
||||
<HEAD>
|
||||
<TITLE>BAutolock Use Cases and Implementation Details</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY BGCOLOR="white" LINK="#000067" VLINK="#000067" ALINK="#0000FF">
|
||||
|
||||
<FONT FACE="Verdana,Arial,Helvetica,sans-serif" SIZE="-1">
|
||||
|
||||
<H1>BAutolock Use Cases and Implementation Details:</H1>
|
||||
|
||||
<P>This document describes the BAutolock interface and some basics of how it is implemented.
|
||||
The document has the following sections:</P>
|
||||
|
||||
<OL>
|
||||
<LI><A HREF="#interface">BAutolock Interface</A></LI>
|
||||
<LI><A HREF="#usecases">BAutolock Use Cases</A></LI>
|
||||
<LI><A HREF="#implement">BAutolock Implementation</A></LI>
|
||||
</OL>
|
||||
|
||||
<A NAME="interface"></A><H2>BAutolock Interface:</H2>
|
||||
|
||||
<P>The BAutolock class is a simple class for handling synchronization between threads. The best
|
||||
source of information for the BAutolock interface can be found
|
||||
<A HREF="file:///boot/beos/documentation/Be%20Book/The%20Support%20Kit/Autolock.html">here in the Be Book</A>.
|
||||
</P>
|
||||
|
||||
<A NAME="usecases"></A><H2>BAutolock Use Cases:</H2>
|
||||
|
||||
<P>The following use cases cover the BAutolock functionality:</P>
|
||||
|
||||
<OL>
|
||||
<LI><P><B>Construction 1:</B> A BAutolock can be created by passing a pointer to a BLocker object.
|
||||
An attempt will be made to Lock() this BLocker during the construction of the BAutolock object.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Construction 2:</B> A BAutolock can be created by passing a reference to a BLocker object.
|
||||
An attempt will be made to Lock() this BLocker during the construction of the BAutolock object.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Construction 3:</B> A BAutolock can be created by passing a pointer to a BLooper object.
|
||||
An attempt will be made to Lock() this BLooper during the construction of the BAutolock object.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Is Locked:</B> When the BAutolock is constructed, a lock is attempted on the BLocker or
|
||||
BLooper passed in. The result of that lock attempt is returned by calling IsLocked() on the
|
||||
BAutolock. The result is a boolean. True is returned if the lock was successfully acquired.
|
||||
False is returned if the lock could not be acquired. See the docs for BLocker and BLooper to
|
||||
find out why the lock acquisition may fail.</P></LI>
|
||||
|
||||
<LI><P><B>Destruction 1:</B> If the lock acquisition on the BLocker or BLooper was successful at
|
||||
construction time, when the BAutolock is destructed, the lock will be released by calling Unlock()
|
||||
on the BLocker or BLooper.</P></LI>
|
||||
|
||||
<LI><P><B>Destruction 2:</B> If the lock acquisition on the BLocker or BLooper failed at
|
||||
construction time, when the BAutolock is destructed, nothing is done to the BLocker or the BLooper.
|
||||
An Unlock() is not attempted because the lock at construction time failed.</P></LI>
|
||||
|
||||
</OL>
|
||||
|
||||
<A NAME="implement"></A><H2>BAutolock Implementation:</H2>
|
||||
|
||||
<P>The entire BAutolock implementation is inline. Because BAutolock is implemented inline, there
|
||||
is no code for BAutolock in libbe.so. The code is all in Be's Autolock.h header file and compiled
|
||||
at build time directly into any object being built.</P>
|
||||
|
||||
<P>This has some interesting implications from a backwards compatibility perspective. Because
|
||||
there are no references from existing non-Be executables and libraries to libbe.so expecting
|
||||
to find the BAutolock class, the entire definition of BAutolock can be changed almost without risk
|
||||
of breaking compatibility. This gives anyone wishing to expand and build on the current BAutolock
|
||||
class a great deal of flexibility.</P>
|
||||
|
||||
<P>However, it may be worthwhile when changing BAutolock in the future to try and stay source
|
||||
compatible. That way, existing source code will continue to compile without having to update
|
||||
it.</P>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -0,0 +1,130 @@
|
||||
<HTML>
|
||||
<!-- $Id: BLockerUseCases.html 10 2002-07-09 12:24:59Z ejakowatz $ -->
|
||||
<HEAD>
|
||||
<TITLE>BLocker Use Cases and Implementation Details</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY BGCOLOR="white" LINK="#000067" VLINK="#000067" ALINK="#0000FF">
|
||||
|
||||
<FONT FACE="Verdana,Arial,Helvetica,sans-serif" SIZE="-1">
|
||||
|
||||
<H1>BLocker Use Cases and Implementation Details:</H1>
|
||||
|
||||
<P>This document describes the BLocker interface and some basics of how it is implemented.
|
||||
The document has the following sections:</P>
|
||||
|
||||
<OL>
|
||||
<LI><A HREF="#interface">BLocker Interface</A></LI>
|
||||
<LI><A HREF="#usecases">BLocker Use Cases</A></LI>
|
||||
<LI><A HREF="#implement">BLocker Implementation</A></LI>
|
||||
</OL>
|
||||
|
||||
<A NAME="interface"></A><H2>BLocker Interface:</H2>
|
||||
|
||||
<P>The BLocker class is a simple class for handling synchronization between threads. The best
|
||||
source of information for the BLocker interface can be found
|
||||
<A HREF="file:///boot/beos/documentation/Be%20Book/The%20Support%20Kit/Locker.html">here in the Be Book</A>.
|
||||
</P>
|
||||
|
||||
<A NAME="usecases"></A><H2>BLocker Use Cases:</H2>
|
||||
|
||||
<P>The following use cases cover the BLocker functionality:</P>
|
||||
|
||||
<OL>
|
||||
<LI><P><B>Construction 1:</B> A BLocker can be created by specifying a name for the semaphore used
|
||||
internally. If a name is specified during construction, then that name is given to the internal
|
||||
semaphore. If no name is given at construction, the semaphore is given the name "some BLocker".
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Construction 2:</B> A BLocker can use a semaphore or a "benaphore" internally depending
|
||||
on a flag passed when the BLocker is created. If the flag is false, the BLocker uses a semaphore
|
||||
to do synchronization. If the flag is true, the BLocker uses a benaphore internally to do
|
||||
synchronization. If no flag is specified, the BLocker uses a benaphore internally.</P></LI>
|
||||
|
||||
<LI><P><B>Destruction:</B> When a BLocker is destructed, any threads waiting for the lock are
|
||||
immediately unblocked. The threads are notified by the return code of the locking member function
|
||||
that the lock was not successfully acquired. Any threads blocked on Lock() will return with
|
||||
a false value. Any threads blocked on LockWithTimeout() will return with B_BAD_SEM_ID.</P></LI>
|
||||
|
||||
<LI><P><B>Locking 1:</B> When a thread acquires the BLocker using the Lock() or LockWithTimeout()
|
||||
member functions, no other thread can acquire the lock until this thread releases it.</P></LI>
|
||||
|
||||
<LI><P><B>Locking 2:</B> When a thread holds the BLocker and it calls Lock() or LockWithTimeout(),
|
||||
the member function returns immediately. The thread must call Unlock() the same number of times
|
||||
it calls Lock...() before the BLocker is released. At any time, the thread can call CountLocks()
|
||||
to get the number of times it must call Unlock() to release the BLocker.</P></LI>
|
||||
|
||||
<LI><P><B>Locking 3:</B> When a thread calls Lock(), the thread blocks until it can acquire the
|
||||
lock. Once the lock has been acquired or an unrecoverable error has occurred, the Lock() member
|
||||
function completes. If the lock has been acquired, Lock() returns true. If the lock has not
|
||||
been acquired, Lock() returns false.</P></LI>
|
||||
|
||||
<LI><P><B>Locking 4:</B> When a thread calls LockWithTimeout(), the thread blocks until it can
|
||||
acquire the lock, the time specified in microseconds expires, or an unrecoverable error occurs.
|
||||
If the timeout specified is B_INFINTE_TIMEOUT, there is no timeout and the member function will
|
||||
either acquire the lock or fail due to an unrecoverable error. If the lock is acquired, the
|
||||
member function returns B_OK. If the timeout is reached, B_TIMED_OUT is returned and the lock is
|
||||
not acquired. If a serious error occurs, a non B_OK code is returned.</P></LI>
|
||||
|
||||
<LI><P><B>Unlocking:</B> The Unlock() member function takes no arguments and returns no value.
|
||||
If the thread currently holds the lock, the lock count is reduced by the call to Unlock(). If
|
||||
the lock count reaches zero, then another thread may acquire the lock. If the thread does not
|
||||
hold the lock and it calls Unlock(), the call will have no affect at all on the BLocker.</P></LI>
|
||||
|
||||
<LI><P><B>Locking Thread:</B> The LockingThread() member function returns the thread_id of the
|
||||
thread that is holding the lock. If no thread holds the lock, then B_ERROR is returned.</P></LI>
|
||||
|
||||
<LI><P><B>Is Locked:</B> The IsLocked() member function returns true if the BLocker is currently
|
||||
held by the calling thread. If the BLocker is not acquired by any thread or it is acquired by a
|
||||
different thread, IsLocked() returns false.</P></LI>
|
||||
|
||||
<LI><P><B>Count Locks:</B> The CountLocks() member function returns the number of times the lock
|
||||
has been acquired by the thread which holds the lock. If no thread holds the lock, then 0 is
|
||||
returned. If the BLocker is held by any thread, including a thread which is not the thread
|
||||
making the CountLocks() request, the number of times the lock has been acquired by the thread which
|
||||
holds the lock is returned.</P></LI>
|
||||
|
||||
<LI><P><B>Count Lock Requests:</B> The CountLockRequests() member function returns the number of
|
||||
threads currently attempting to lock the BLocker. If no thread holds the lock and no thread is
|
||||
waiting for the lock, then 0 is returned. If one thread holds the lock and no other threads
|
||||
are waiting for the lock, then 1 is returned. If one thread holds the lock and x threads are
|
||||
waiting for the lock, then x+1 is returned. The call to CountLockRequests() can be made by any
|
||||
thread including threads which do not have the lock.</P>
|
||||
|
||||
<P><B>NOTE:</B> Reading the Be Book, that would seem like what is returned by this member
|
||||
function. In actuality, the value returned is just the "benaphore count" for the BLocker.
|
||||
If the BLocker is semaphore style, then the benaphore count is set to 1 at construction time
|
||||
to ensure that the semaphore is always tested when a lock is acquired. The return value is
|
||||
just this count. So, the return value for benaphore style is:</P>
|
||||
|
||||
<PRE>
|
||||
numThreadsWaitingForTheLock + numThreadsHoldingTheLock + numOfTimeoutsOccuredOnTheLock
|
||||
</PRE>
|
||||
|
||||
<P>The return value for a semaphore style is:</P>
|
||||
|
||||
<PRE>
|
||||
numThreadsWaitingForTheLock + numThreadsHoldingTheLock + numOfTimeoutsOccuredOnTheLock + 1
|
||||
</PRE>
|
||||
|
||||
<P>Again, this is what we are implementing but the above description is what appears in the
|
||||
BeBook as far as I understand it.</P>
|
||||
</LI>
|
||||
|
||||
<LI><P><B>Sem:</B> The Sem() member function returns the sem_id of the semaphore used by the
|
||||
BLocker. If the BLocker is a benaphore, then the sem_id returned is the semaphore used to
|
||||
implement the benaphore. If the BLocker is a not a benaphore, then the sem_id returned is the
|
||||
semaphore which the BLocker represents.</P></LI>
|
||||
</OL>
|
||||
|
||||
<A NAME="implement"></A><H2>BLocker Implementation:</H2>
|
||||
|
||||
<P>For more information about how to implement a benaphore, you can reference an implementation
|
||||
found on Be's website at
|
||||
|
||||
<A HREF="http://www-classic.be.com/aboutbe/benewsletter/Issue26.html">http://www-classic.be.com/aboutbe/benewsletter/Issue26.html</A>.</P>
|
||||
|
||||
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -0,0 +1,104 @@
|
||||
<!-- saved from url=(0022)http://internet.e-mail -->
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BMallocIO Use Cases and Implementation Details</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY BGCOLOR="white" LINK="#000067" VLINK="#000067" ALINK="#0000FF">
|
||||
|
||||
<FONT FACE="Verdana,Arial,Helvetica,sans-serif" SIZE="-1">
|
||||
|
||||
<H1>BMallocIO Use Cases and Implementation Details:</H1>
|
||||
|
||||
<P>This document describes the BMallocIO interface and some basics of how it is implemented.
|
||||
The document has the following sections:</P>
|
||||
|
||||
<OL>
|
||||
<LI><A HREF="#interface">BMallocIO Interface</A></LI>
|
||||
<LI><A HREF="#usecases">BMallocIO Use Cases</A></LI>
|
||||
<LI><A HREF="#implement">BMallocIO Implementation</A></LI>
|
||||
</OL>
|
||||
|
||||
<A NAME="interface"></A><H2>BMallocIO Interface:</H2>
|
||||
|
||||
<P>The BMallocIO class represent a buffer of dynamically allocated memory. The buffer is
|
||||
automatically allocated by multiplies of a blocksize you can specify, so it will always be
|
||||
big enough to contain the data. The best source of information for the BMallocIO interface
|
||||
can be found
|
||||
<A HREF="file:///boot/beos/documentation/Be%20Book/The%20Support%20Kit/MemoryIO.html">here in the Be Book</A>.
|
||||
</P>
|
||||
|
||||
<A NAME="usecases"></A><H2>BMallocIO Use Cases:</H2>
|
||||
|
||||
<P>The following use cases cover the BMallocIO functionality:</P>
|
||||
|
||||
<OL>
|
||||
|
||||
<LI><P><B>Construction 1:</B> The BMallocIO constructor set the blocksize to 256.</P></LI>
|
||||
|
||||
<LI><P><B>Destruction:</B> The BMallocIO destructor frees the allocated memory.</P></LI>
|
||||
|
||||
<LI><P><B>Reading 1:</B> When ReadAt() is called, the BMallocIO returns the number of bytes read from the specified
|
||||
position. ReadAt() takes three arguments: the position where to begin the read operation, the buffer where to put the read data,
|
||||
and the number of bytes to read. This function does not read outside of the buffer.
|
||||
If the specified position is invalid (i.e. outside bounds) this function returns 0. If the read operation
|
||||
begins at a valid position, but the sum of position and bytes to read is bigger than the size of the buffer, BMallocIO
|
||||
returns just the available data.</P></LI>
|
||||
|
||||
<LI><P><B>Reading 2.</B> BMallocIO inherits the Read() function from BPositionIO. This function read the specified amount
|
||||
of data from the current position, and put it into the specified buffer, then it moves the I/O index forward of the number of read bytes.
|
||||
This function behaves like the above. </P></LI>
|
||||
|
||||
<LI><P><B>Writing 1:</B> When WriteAt() is called, BMallocIO returns the number of bytes written to the specified position.
|
||||
WriteAt() takes three arguments: the position where to begin the write operation, the buffer from which to read the data to write, and the
|
||||
number of bytes to write.
|
||||
If the write position is beyond the buffer length, BMallocIO enlarges the buffer to accomodate the data. If enlarging fails, the function
|
||||
returns B_NO_MEMORY.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Writing 2.</B> BMallocIO inherits the Write() function from BPositionIO. This function write the specified amount
|
||||
of data to the current position of the BMallocIO object, reading from the specified buffer, then it moves the I/O index forward
|
||||
of the number of read bytes.
|
||||
This function behaves like the above. </P></LI>
|
||||
|
||||
<LI><P><B>Size Changes:</B> The SetSize() member function enlarges or shrink the amount of data which can be read/write.
|
||||
Shrinking the buffer is always possible, and the function returns B_OK. Zero frees the memory, while negative values are
|
||||
not allowed, and the function returns B_ERROR.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Seeking.</B> Seek() sets the position in the data buffer where the Read() and Write() functions (inherited from
|
||||
BPositionIO) begin reading and writing. How the position argument is understood depends on the mode flag. There are three possible modes:
|
||||
<UL>
|
||||
<LI><P>
|
||||
SEEK_SET. The position passed is an offset from the beginning of allocated memory; in other
|
||||
words, the current position is set to position. For this mode, position should be a positive
|
||||
value.
|
||||
</P></LI>
|
||||
<LI><P>
|
||||
SEEK_CUR. The position argument is an offset from the current position; the value of the
|
||||
argument is added to the current position. </P></LI>
|
||||
<LI><P>
|
||||
SEEK_END. The position argument is an offset from the end of the buffer for a BMallocIO
|
||||
object. Positive values seek beyond the end of the buffer or data; negative
|
||||
values seek backwards into the data. </P></LI>
|
||||
</UL>
|
||||
Seek() Always return the new position.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Position:</B> The Position() call always return the current position.</P></LI>
|
||||
|
||||
<LI><P><B>Setting the BlockSize:</B> The SetBlockSize() call let you specify
|
||||
the blocksize which BMallocIO uses to allocate memory.</P></LI>
|
||||
|
||||
<LI><P><B>Getting the Buffer:</B> The Buffer() call returns the buffer used internally
|
||||
by BMallocIO.</P></LI>
|
||||
|
||||
<LI><P><B>Getting the Buffer Lenght:</B> The BufferLength() call returns the length
|
||||
of the buffer.</P></LI>
|
||||
|
||||
</OL>
|
||||
|
||||
<A NAME="implement"></A><H2>BMallocIO Implementation:</H2>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -0,0 +1,106 @@
|
||||
<!-- saved from url=(0022)http://internet.e-mail -->
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BMemoryIO Use Cases and Implementation Details</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY BGCOLOR="white" LINK="#000067" VLINK="#000067" ALINK="#0000FF">
|
||||
|
||||
<FONT FACE="Verdana,Arial,Helvetica,sans-serif" SIZE="-1">
|
||||
|
||||
<H1>BMemoryIO Use Cases and Implementation Details:</H1>
|
||||
|
||||
<P>This document describes the BMemoryIO interface and some basics of how it is implemented.
|
||||
The document has the following sections:</P>
|
||||
|
||||
<OL>
|
||||
<LI><A HREF="#interface">BMemoryIO Interface</A></LI>
|
||||
<LI><A HREF="#usecases">BMemoryIO Use Cases</A></LI>
|
||||
<LI><A HREF="#implement">BMemoryIO Implementation</A></LI>
|
||||
</OL>
|
||||
|
||||
<A NAME="interface"></A><H2>BMemoryIO Interface:</H2>
|
||||
|
||||
<P>The BMemoryIO class represent a buffer of dynamically allocated memory. You assign the
|
||||
buffer to a BMemoryIO object on construction. The best source of information for the BMemoryIO interface
|
||||
can be found
|
||||
<A HREF="file:///boot/beos/documentation/Be%20Book/The%20Support%20Kit/MemoryIO.html">here in the Be Book</A>.
|
||||
</P>
|
||||
|
||||
<A NAME="usecases"></A><H2>BMemoryIO Use Cases:</H2>
|
||||
|
||||
<P>The following use cases cover the BMemoryIO functionality:</P>
|
||||
|
||||
<OL>
|
||||
|
||||
<LI><P><B>Construction 1:</B> A BMemoryIO can be created by specifying a void pointer
|
||||
and a ssize_t option. These options are used to determine the buffer to assign to the BMemoryIO object and its
|
||||
size. No check is done to determine if the buffer is valid or if it contains at least the number of byte specified.</P></LI>
|
||||
|
||||
<LI><P><B>Construction 2:</B> As the one above, but the buffer is specified with a const void pointer.
|
||||
The BMemoryIO object becomes read only, and every subsequent Write(), WriteAt() and SetSize() calls will
|
||||
return B_NOT_ALLOWED.</P></LI>
|
||||
|
||||
<LI><P><B>Destruction:</B> The BMemoryIO destructor does nothing. It's up to the caller the responsibility
|
||||
to free the buffer assigned on construction.</P></LI>
|
||||
|
||||
<LI><P><B>Reading 1:</B> When ReadAt() is called, the BMemoryIO returns the number of bytes read from the specified
|
||||
position. ReadAt() takes three arguments: the position where to begin the read operation, the buffer where to put the read data,
|
||||
and the number of bytes to read. This function does not read outside of the buffer.
|
||||
If the specified position is invalid (i.e. outside bounds) this function returns 0. If the read operation
|
||||
begins at a valid position, but the sum of position and bytes to read is bigger than the max size (specified on construction), BMemoryIO
|
||||
returns just the available data.</P></LI>
|
||||
|
||||
<LI><P><B>Reading 2.</B> BMemoryIO inherits the Read() function from BPositionIO. This function read the specified amount
|
||||
of data from the current position, and put it into the specified buffer, then it moves the I/O index forward of the number of read bytes.
|
||||
This function behaves like the above. </P></LI>
|
||||
|
||||
<LI><P><B>Writing 1:</B> When WriteAt() is called, BMemoryIO returns the number of bytes written to the specified position.
|
||||
WriteAt() takes three arguments: the position where to begin the write operation, the buffer from which to read the data to write, and the
|
||||
number of bytes to write. If the BMemoryIO object was constructed with the const constructor, this function returns B_NOT_ALLOWED.
|
||||
This function does not write outside of the buffer bounds. If the specified position is invalid (i.e. outside bounds) this function returns 0. If the write operation begins at a valid position, but the sum of position and bytes to write is bigger than the max size (specified on construction), BMemoryIO
|
||||
returns just the amount of data which can be written.
|
||||
If the BMemoryIO object has been shrunk (see the Size Change case), and the write operation is outside the current bounds (but inside the
|
||||
bounds specified on construction) this function re-enlarge it to accomodate the data.</P></LI>
|
||||
|
||||
<LI><P><B>Writing 2.</B> BMemoryIO inherits the Write() function from BPositionIO. This function write the specified amount
|
||||
of data to the current position of the BMemoryIO object, reading from the specified buffer, then it moves the I/O index forward
|
||||
of the number of read bytes.
|
||||
This function behaves like the above. </P></LI>
|
||||
|
||||
<LI><P><B>Size Changes:</B> The SetSize() member function enlarges or shrink the amount of data which can be read/write.
|
||||
If the BMemoryIO object was constructed with the const constructor, this function always returns B_NOT_ALLOWED.
|
||||
Any SetSize call with a size parameter bigger than the size specified on construction will fail and return B_ERROR. Shrinking the buffer
|
||||
is always possible, and the function returns B_OK. Negative values are not allowed, and the function returns B_ERROR.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Seeking.</B> Seek() sets the position in the data buffer where the Read() and Write() functions (inherited from
|
||||
BPositionIO) begin reading and writing. How the position argument is understood depends on the mode flag. There are three possible modes:
|
||||
<UL>
|
||||
<LI><P>
|
||||
SEEK_SET. The position passed is an offset from the beginning of allocated memory; in other
|
||||
words, the current position is set to position. For this mode, position should be a positive
|
||||
value.
|
||||
</P></LI>
|
||||
<LI><P>
|
||||
SEEK_CUR. The position argument is an offset from the current position; the value of the
|
||||
argument is added to the current position. </P></LI>
|
||||
<LI><P>
|
||||
SEEK_END. The position argument is an offset from the end of the buffer for a BMemoryIO
|
||||
object. Positive values seek beyond the end of the buffer or data; negative
|
||||
values seek backwards into the data. </P></LI>
|
||||
</UL>
|
||||
Seek() Always return the new position.
|
||||
</P></LI>
|
||||
|
||||
<LI><P><B>Position:</B> The Position() call always return the current position.</P></LI>
|
||||
|
||||
</OL>
|
||||
|
||||
<A NAME="implement"></A><H2>BMemoryIO Implementation:</H2>
|
||||
|
||||
<P>The implementation of the BMemoryIO is simple. It consist in implementing memory read/write on a buffer
|
||||
with an index.</P>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -0,0 +1,61 @@
|
||||
<!-- saved from url=(0022)http://internet.e-mail -->
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>BString Use Cases and Implementation Details</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<BODY BGCOLOR="white" LINK="#000067" VLINK="#000067" ALINK="#0000FF">
|
||||
|
||||
<FONT FACE="Verdana,Arial,Helvetica,sans-serif" SIZE="-1">
|
||||
|
||||
<H1>BString Use Cases and Implementation Details:</H1>
|
||||
|
||||
<P>This document describes the BString interface and some basics of how it is implemented.
|
||||
The document has the following sections:</P>
|
||||
|
||||
<OL>
|
||||
<LI><A HREF="#interface">BString Interface</A></LI>
|
||||
<LI><A HREF="#usecases">BString Use Cases</A></LI>
|
||||
<LI><A HREF="#implement">BString Implementation</A></LI>
|
||||
</OL>
|
||||
|
||||
<A NAME="interface"></A><H2>BString Interface:</H2>
|
||||
|
||||
<P>The BString is as string allocation and manipulation class. The object allocates and deallocates
|
||||
memory for you so the buffer will always be "big enough" to contain the data.
|
||||
BString provides a number of charachter search, comparison, and manipulation functions in
|
||||
a variety of flavors. The best source of information about the BString class can be found
|
||||
<A HREF="file:///boot/beos/documentation/Be%20Book/The%20Support%20Kit/String.html">here in the Be Book</A>.
|
||||
</P>
|
||||
|
||||
<A NAME="usecases"></A><H2>BString Use Cases:</H2>
|
||||
|
||||
<P>The following use cases cover the BString functionality:</P>
|
||||
|
||||
<OL>
|
||||
|
||||
<LI><P><B>Construction 1:</B> A BString can be created with an empty constructor.
|
||||
This way the created BString is empty.</P></LI>
|
||||
|
||||
<LI><P><B>Construction 2:</B> You can create a BString object with a const char pointer as
|
||||
parameter. After the construction, the BString object contains a copy of the string pointed
|
||||
by the const char pointer.</P></LI>
|
||||
|
||||
<LI><P><B>Construction 3:</B> BString can be created using a copy constructor.
|
||||
The parameter is another BString. After the construction, your BString will contain a
|
||||
copy of the other BString.</P></LI>
|
||||
|
||||
<LI><P><B>Construction 4:</B> You can create a BString object with a const char pointer as
|
||||
parameter and an int32 parameter, which specifies the maximum bytes BString will consider.
|
||||
After the construction, the BString object contains a maximum of bytes (specified by the int32
|
||||
parameter) of the string pointed by the pointer.</P></LI>
|
||||
|
||||
<LI><P><B>Destruction:</B> The BString destructor frees the allocated memory.</P></LI>
|
||||
|
||||
</OL>
|
||||
|
||||
<A NAME="implement"></A><H2>BString Implementation:</H2>
|
||||
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
Reference in New Issue
Block a user