From b3eef5b0b82c20a9f11868ba376f6bb2d94faae4 Mon Sep 17 00:00:00 2001 From: Mike Buland Date: Wed, 3 Oct 2007 09:13:28 +0000 Subject: Nothing about function. I added a bunch of docs and re-arranged a bunch of the existing docs. Taking advantage of some of the cooler extra features of doxygen I've started writing extra how-to pages covering working with sections of the library. Also, I started grouping the classes by function so they show up on the Modules page together, very cute. --- Doxyfile | 2 +- src/array.h | 1 + src/atom.h | 1 + src/client.h | 3 +- src/doxy/archives.dox | 9 +++ src/doxy/groups.dox | 19 ++++++ src/doxy/main.dox | 21 +++++++ src/doxy/servers.dox | 11 ++++ src/doxy/streams.dox | 158 +++++++++++++++++++++++++++++++++++++++++++++++++ src/doxy/threading.dox | 15 +++++ src/hash.h | 1 + src/ito.h | 63 ++++++++++---------- src/itoatom.h | 1 + src/itocondition.h | 33 ++++++----- src/itomutex.h | 37 ++++++------ src/itoqueue.h | 61 ++++++++++--------- src/itoserver.h | 2 + src/list.h | 1 + src/main.dox | 14 ----- src/protocol.h | 3 +- src/ringbuffer.h | 3 + src/server.h | 2 + src/serversocket.h | 3 + src/set.h | 1 + src/socket.h | 3 +- src/sptr.h | 3 + src/tafnode.h | 13 ++++ src/tafreader.h | 1 + src/tafwriter.h | 1 + src/tests/size.cpp | 13 ++++ 30 files changed, 389 insertions(+), 110 deletions(-) create mode 100644 src/doxy/archives.dox create mode 100644 src/doxy/groups.dox create mode 100644 src/doxy/main.dox create mode 100644 src/doxy/servers.dox create mode 100644 src/doxy/streams.dox create mode 100644 src/doxy/threading.dox delete mode 100644 src/main.dox create mode 100644 src/tests/size.cpp diff --git a/Doxyfile b/Doxyfile index c3168fa..4e64a4c 100644 --- a/Doxyfile +++ b/Doxyfile @@ -80,7 +80,7 @@ WARN_LOGFILE = Doxywarn #--------------------------------------------------------------------------- # configuration options related to the input files #--------------------------------------------------------------------------- -INPUT = src +INPUT = src src/doxy FILE_PATTERNS = *.c \ *.cc \ *.cxx \ diff --git a/src/array.h b/src/array.h index 43892ee..75c5dd3 100644 --- a/src/array.h +++ b/src/array.h @@ -13,6 +13,7 @@ namespace Bu *@param value (typename) The type of data to store in your list *@param valuealloc (typename) Memory Allocator for your value type *@param linkalloc (typename) Memory Allocator for the list links. + *@ingroup Containers */ template > class Array diff --git a/src/atom.h b/src/atom.h index e950a96..1786cf3 100644 --- a/src/atom.h +++ b/src/atom.h @@ -9,6 +9,7 @@ namespace Bu { /** * + *@ingroup Containers */ template > class Atom diff --git a/src/client.h b/src/client.h index 2b7448c..4188a49 100644 --- a/src/client.h +++ b/src/client.h @@ -11,7 +11,8 @@ namespace Bu class Socket; /** - * + *@author Mike Buland + *@ingroup Serving */ class Client { diff --git a/src/doxy/archives.dox b/src/doxy/archives.dox new file mode 100644 index 0000000..3b96aa3 --- /dev/null +++ b/src/doxy/archives.dox @@ -0,0 +1,9 @@ +/** + *@page howto_archives Archiving Your Data a.k.a. Serialization + * + * Archives are a simple system for providing basic-level data-structure + * serialization in a fast and simple manner. They even provide a few more + * advanced capabilities for when you need them. + * + *@todo Finish this page. + */ diff --git a/src/doxy/groups.dox b/src/doxy/groups.dox new file mode 100644 index 0000000..7bff7a7 --- /dev/null +++ b/src/doxy/groups.dox @@ -0,0 +1,19 @@ +/** + *@defgroup Threading + * Threads are awesome. + */ + +/** + *@defgroup Serving + * Serving data is pretty cool too. + */ + +/** + *@defgroup Containers + * Containers for data. + */ + +/** + *@defgroup Taf + * Taf is the best! + */ diff --git a/src/doxy/main.dox b/src/doxy/main.dox new file mode 100644 index 0000000..7268890 --- /dev/null +++ b/src/doxy/main.dox @@ -0,0 +1,21 @@ +/** + *@mainpage libbu++ utility library + * + *@section secIntro Introduction + * + * Libbu++ is a C++ library of general utility classes and functions. They + * cover a wide range of topics from streams and sockets to data structures to + * data serialization and xml handling to threading. + * + * This documentation is expanding all the time, and should contain + * comprehensive guides and API reference, but doesn't yet. For now check out + * these sections: + * - @ref howto_streams + * - @ref howto_archives + * - @ref howto_threading + * - @ref howto_servers + */ + +/** + *@namespace Bu The core libbu++ namespace, to ensure things don't get muddied. + */ diff --git a/src/doxy/servers.dox b/src/doxy/servers.dox new file mode 100644 index 0000000..0ba4bb1 --- /dev/null +++ b/src/doxy/servers.dox @@ -0,0 +1,11 @@ +/** + *@page howto_servers Creating Internet Servers + * + * Libbu++ provides a comprehensive set of classes for creating any type of + * server that you would like. At the moment these are restricted to using + * the Bu::Socket subclass of Bu::Stream, and therefore the INET socket + * namespace. This isn't much of a restriction, but hopefully it will be + * lifted in the future. + * + *@todo Finish this page. + */ diff --git a/src/doxy/streams.dox b/src/doxy/streams.dox new file mode 100644 index 0000000..65f01d7 --- /dev/null +++ b/src/doxy/streams.dox @@ -0,0 +1,158 @@ +/** + *@page howto_streams Working With Streams + * + * Working with libbu++ streams is simple and very straight-forward, but there + * are a few things to understand when you pick them up for the first time. + * + *@section whatis What is a stream? + * A stream is a mechanism that allows data to be transported from one place to + * another without interruption and in order. Examples of this include data + * being written to a file or being read from a file, data being written to a + * network socket or read from a network socket, and so on. + * Every type of stream will support a different number of options, for example + * file streams are usually seekable, that is, you can select where in the file + * you are reading and writing, however network sockets are not seekable. All + * of these properties can be determined at runtime through the Stream class. + * + *@section filters Using filters with streams + * Libbu++ supports a special type of Stream that is known as a Filter. Filters + * are actually streams, except instead of reading or writing to or from a + * file they read or write to or from another stream. This provides a handy + * way of chaining any number of filters together along with end-point streams + * such as files. One example of this would be applying a BZip2 compression + * filter to a file stream to compress all data being written to it. + * Once a filter is applied the transformations that it applies to the data will + * happen automatically as you use the stream. + * + * One important thing to remember about streams is that they will commonly + * change the options that you have when it comes to interacting with the + * stream. This is not a bad thing, it is necesarry, but it is easy to tell + * when this is happening. To continue with the above example, you can seek in + * a File stream, but not in a BZip2 filtered File stream. This has to do with + * the way the compression algorithms work and restrict the operations that can + * be easily performed on the data. + * + * Not all changes that filters apply will be restrictive, filters such as the + * Buffer filter will add the ability to seek (to an extent) within the buffered + * data. + * + *@section difference How are libbu++ streams different form stl streams? + * While not globally true, many stl streams are designed for formatting the + * data that flows through the stream, that means that when you attempt to + * write a uint32_t into a standard stream it can be difficult to predict what + * the result will be, will it be the binary representation or a textual + * conversion? + * + * Libbu++ streams are very direct about how the data is handled. All end-point + * streams will always handle the data that you provide or request without any + * modification or formatting, very much like the way libc style file access + * works. + * + * The design of Libbu++ streams was, from the begining, to try to make it as + * easy as possible to write general code that was as easy as possible to + * extend, and as clear as possible. We have accomplished this by making + * streams simple, yet flexible, with a clear API and a flexible filter system + * that something geared towards more general formatting, conversion, and + * operator-only access can't touch. + * + *@section usage Using streams directly + * To create a stream depends on the type of stream that you're interested in, + * each type has it's own constructors designed to create the stream and get + * it ready for use. We'll use the Bu::File stream as an example here. + * + *@code + // The constructor and each function call to access the stream could throw + // an exception, it's important to catch these and handle them + // appropriately. + try + { + // sFileName is a Bu::FString object containing the name of the file to + // open, possibly with path elements. The second parameter works like + // the fopen mode parameter, and can be "w" for write, "r" for read, or + // "a" for append. This will likely be replaced with a bitfield later. + Bu::File f( sFileName, "w"); + + // At this point we know our file is open, lets write some data to it + // The first parameter is a pointer to the data to write, the second is + // how many bytes to write. + f.write( "Test data, boring old test data.\n", 33 ); + + // We don't actually need to close the file explicitly, the + // deconstructor will take care of that for us, we could if we wanted + // to, simply by calling the f.close() function, but it isn't necesarry. + } + catch( Bu::FileException &e ) + { + // Here we can report the error to the system, whatever it happened to + // be. + printf("Error: %s\n", e.what() ); + } + @endcode + * This is a most basic example, but it covers all the basics. You don't need + * much more than this to write just about any file i/o program, just use the + * Bu::Stream::read() and Bu::Stream::write() functions. + * + * Now lets look at how to add a stream to the mix, we'll BZip2 compress the + * above example. + *@code + // Again, we want to catch exceptions in the entire file handling block. + try + { + // We create the file just like before, nothing different about this. + Bu::File f( sFileName, "w"); + + // Here, however, we create our Bu::BZip2 object, and pass it a + // reference to the file. Now our data will go through Bu::BZip2, then + // into Bu::File and onto disk. Notice that you don't have to specify + // wether you want to read or write explicitly, the filter can usually + // determine this for itself by examining the underlying stream. + Bu::BZip2 bz2( f ); + + // This is done exactly as before, but this time we write into bz2, not + // f. We already know how to do this, because both BZip2 and File + // inherit from Bu::Stream, so they both have very similar (if not + // identicle) API. + bz2.write( "Test data, boring old test data.\n", 33 ); + + // Just like last time, we don't have to close either stream explicitly, + // they will be destroyed appropriately by the system, and in the + // correct order (bz2 first, then f). + } + catch( Bu::FileException &e ) + { + // Here we can report the error to the system, whatever it happened to + // be. + printf("Error: %s\n", e.what() ); + } + @endcode + * + * As you can tell in this example, using streams and filters is very easy to + * do, and even makes formerly very complex procedures take almost no time at + * all. + * + *@section usingmore Accepting strings in other classes and functions + * + * When writing a class or function that uses an already opened stream to read + * or write data from or to it's important to plan ahead, and probably accept + * an object reference of type Bu::Stream. This makes your code immediately + * much more portable, useful, and flexible. You don't have to change anything + * about the way you write your class or function, use the standard Bu::Stream + * functions like read and write just like before. + * + * For example, lets say you're creating a new image format, and need to be able + * to store images on disk and read them off again, so you write the approprate + * file fromat handlers. By using Bu::Stream instead of Bu::File you allow + * anyone using your image format to send that data anywhere they would like, + * including files, sockets, memory buffers, composite archives, and even + * through types of streams that don't exist yet. Not only that, but since + * every filter is a stream, anyone is now free to pass you a BZip2 filter or + * an encryption filter, or any other chain, so that your data can be + * compressed, and possibly encrypted, and sent over the network without any + * changes to your original code. + * + * Understandably you probably want to be sure of a few basics before you go + * writing image data to any old stream, such as ensuring the stream supports + * writing to begin with. This can be easily handled by taking advantage of + * the capability accessors in Bu::Stream, these begin with "can" and "is," see + * the documentation for more information. + */ diff --git a/src/doxy/threading.dox b/src/doxy/threading.dox new file mode 100644 index 0000000..0ae5325 --- /dev/null +++ b/src/doxy/threading.dox @@ -0,0 +1,15 @@ +/** + *@page howto_threading Making Applications Multi-threaded + * + * Libbu++ provides support for object oriented threading including full support + * for inter-thread communication and safety devices such as mutexes, + * conditions, and semaphores. It even provides some of the basic foundation + * classes in thread-safe versions that often add extra functionality and make + * writing thread-safe programs as easy as could be. + * + * Threads in libbu++ are currently based on the posix model, but will hopefully + * adopt other methods behind the scenes for compatability with other operating + * systems. + * + *@todo Finish this page. + */ diff --git a/src/hash.h b/src/hash.h index 4f508b2..62b19c9 100644 --- a/src/hash.h +++ b/src/hash.h @@ -165,6 +165,7 @@ namespace Bu *@param keyalloc (typename) Memory allocator for hashtable keys *@param valuealloc (typename) Memory allocator for hashtable values *@param challoc (typename) Byte allocator for bitflags + *@ingroup Containers */ template class Hash diff --git a/src/ito.h b/src/ito.h index c062052..4ed2c8b 100644 --- a/src/ito.h +++ b/src/ito.h @@ -6,11 +6,12 @@ namespace Bu { /** - * Simple thread class. This wraps the basic pthread (posix threads) system in - * an object oriented sort of way. It allows you to create a class with - * standard member variables and callable functions that can be run in it's own - * thread, one per class instance. + * Simple thread class. This wraps the basic pthread (posix threads) + * system in an object oriented sort of way. It allows you to create a + * class with standard member variables and callable functions that can be + * run in it's own thread, one per class instance. *@author Mike Buland + *@ingroup Threading */ class Ito { @@ -27,24 +28,26 @@ namespace Bu /** * Begin thread execution. This will call the overridden run function, - * which will simply execute in it's own thread until the function exits, - * the thread is killed, or the thread is cancelled (optionally). The - * thread started in this manner has access to all of it's class variables, - * but be sure to protect possible multiple-access with ItoMutex objects. - *@returns True if starting the thread was successful. False if something - * went wrong and the thread has not started. + * which will simply execute in it's own thread until the function + * exits, the thread is killed, or the thread is cancelled (optionally). + * The thread started in this manner has access to all of it's class + * variables, but be sure to protect possible multiple-access with + * ItoMutex objects. + * @returns True if starting the thread was successful. False if + * something went wrong and the thread has not started. */ bool start(); /** - * Forcibly kill a thread. This is not generally considered a good thing to - * do, but in those rare cases you need it, it's invaluable. The problem - * with stopping (or killing) a thread is that it stops it the moment you - * call stop, no matter what it's doing. The object oriented approach to - * this will help clean up any class variables that were used, but anything - * not managed as a member variable will probably create a memory leak type - * of situation. Instead of stop, consider using cancel, which can be - * handled by the running thread in a graceful manner. + * Forcibly kill a thread. This is not generally considered a good + * thing to do, but in those rare cases you need it, it's invaluable. + * The problem with stopping (or killing) a thread is that it stops it + * the moment you call stop, no matter what it's doing. The object + * oriented approach to this will help clean up any class variables + * that were used, but anything not managed as a member variable will + * probably create a memory leak type of situation. Instead of stop, + * consider using cancel, which can be handled by the running thread in + * a graceful manner. *@returns True if the thread was stopped, false otherwise. When this * function returns the thread may not have stopped, to ensure that the * thread has really stopped, call join. @@ -52,11 +55,11 @@ namespace Bu bool stop(); /** - * The workhorse of the Ito class. This is the function that will run in - * the thread, when this function exits the thread dies and is cleaned up - * by the system. Make sure to read up on ItoMutex, ItoCondition, and - * cancel to see how to control and protect everything you do in a safe way - * within this function. + * The workhorse of the Ito class. This is the function that will run + * in the thread, when this function exits the thread dies and is + * cleaned up by the system. Make sure to read up on ItoMutex, + * ItoCondition, and cancel to see how to control and protect + * everything you do in a safe way within this function. *@returns I'm not sure right now, but this is the posix standard form. */ virtual void *run()=0; @@ -64,13 +67,13 @@ namespace Bu /** * Join the thread in action. This function performs what is commonly * called a thread join. That is that it effectively makes the calling - * thread an the Ito thread contained in the called object one in the same, - * and pauses the calling thread until the called thread exits. That is, - * when called from, say, your main(), mythread.join() will not return until - * the thread mythread has exited. This is very handy at the end of - * programs to ensure all of your data was cleaned up. - *@returns True if the thread was joined, false if the thread couldn't be - * joined, usually because it isn't running to begin with. + * thread an the Ito thread contained in the called object one in the + * same, and pauses the calling thread until the called thread exits. + * That is, when called from, say, your main(), mythread.join() will + * not return until the thread mythread has exited. This is very handy + * at the end of programs to ensure all of your data was cleaned up. + *@returns True if the thread was joined, false if the thread couldn't + * be joined, usually because it isn't running to begin with. */ bool join(); diff --git a/src/itoatom.h b/src/itoatom.h index 7fc9090..2f8ac41 100644 --- a/src/itoatom.h +++ b/src/itoatom.h @@ -9,6 +9,7 @@ /** * A thread-safe wrapper class. *@author Mike Buland + *@ingroup Threading */ template class ItoAtom diff --git a/src/itocondition.h b/src/itocondition.h index 1793f81..517dd5f 100644 --- a/src/itocondition.h +++ b/src/itocondition.h @@ -10,9 +10,9 @@ namespace Bu /** * Ito condition. This is a fairly simple condition mechanism. As you may * notice this class inherits from the ItoMutex class, this is because all - * conditions must be within a locked block. The standard usage of a condition - * is to pause one thread, perhaps indefinately, until another thread signals - * that it is alright to procede. + * conditions must be within a locked block. The standard usage of a + * condition is to pause one thread, perhaps indefinately, until another + * thread signals that it is alright to procede. *
* Standard usage for the thread that wants to wait is as follows: * 
@@ -24,10 +24,11 @@ namespace Bu
 	 * ...  // Take care of what you have to.
 	 * cond.unlock();
 	 *
- * The usage for the triggering thread is much simpler, when it needs to tell - * the others that it's time to grab some data it calls either signal or - * broadcast. See both of those functions for the difference. + * The usage for the triggering thread is much simpler, when it needs to + * tell the others that it's time to grab some data it calls either signal + * or broadcast. See both of those functions for the difference. *@author Mike Buland + *@ingroup Threading */ class ItoCondition : public ItoMutex { @@ -43,9 +44,9 @@ namespace Bu ~ItoCondition(); /** - * Wait forever, or until signalled. This has to be called from within a - * locked section, i.e. before calling this this object's lock function - * should be called. + * Wait forever, or until signalled. This has to be called from within + * a locked section, i.e. before calling this this object's lock + * function should be called. */ int wait(); @@ -60,16 +61,18 @@ namespace Bu int wait( int nSec, int nUSec ); /** - * Notify the next thread waiting on this condition that they can go ahead. - * This only signals one thread, the next one in the condition queue, that - * it is safe to procede with whatever operation was being waited on. + * Notify the next thread waiting on this condition that they can go + * ahead. This only signals one thread, the next one in the condition + * queue, that it is safe to procede with whatever operation was being + * waited on. */ int signal(); /** - * Notify all threads waiting on this condition that they can go ahead now. - * This function is slower than signal, but more effective in certain - * situations where you may not know how many threads should be activated. + * Notify all threads waiting on this condition that they can go ahead + * now. This function is slower than signal, but more effective in + * certain situations where you may not know how many threads should be + * activated. */ int broadcast(); diff --git a/src/itomutex.h b/src/itomutex.h index 9c9d205..27ca125 100644 --- a/src/itomutex.h +++ b/src/itomutex.h @@ -7,10 +7,11 @@ namespace Bu { /** * Simple mutex wrapper. Currently this doesn't do anything extra for you - * except keep all of the functionality together in an OO sorta' way and keep - * you from having to worry about cleaning up your mutexes properly, or initing - * them. + * except keep all of the functionality together in an OO sorta' way and + * keep you from having to worry about cleaning up your mutexes properly, + * or initing them. *@author Mike Buland + *@ingroup Threading */ class ItoMutex { @@ -23,33 +24,33 @@ namespace Bu /** * Destroy a mutex. This can only be done when a mutex is unlocked. * Failure to unlock before destroying a mutex object could cause it to - * wait for the mutex to unlock, the odds of which are usually farily low - * at deconstruction time. + * wait for the mutex to unlock, the odds of which are usually farily + * low at deconstruction time. */ ~ItoMutex(); /** - * Lock the mutex. This causes all future calls to lock on this instance - * of mutex to block until the first thread that called mutex unlocks it. - * At that point the next thread that called lock will get a chance to go - * to work. Because of the nature of a mutex lock it is a very bad idea to - * do any kind of serious or rather time consuming computation within a - * locked section. This can cause thread-deadlock and your program may - * hang. + * Lock the mutex. This causes all future calls to lock on this + * instance of mutex to block until the first thread that called mutex + * unlocks it. At that point the next thread that called lock will get + * a chance to go to work. Because of the nature of a mutex lock it is + * a very bad idea to do any kind of serious or rather time consuming + * computation within a locked section. This can cause thread-deadlock + * and your program may hang. */ int lock(); /** - * Unlock the mutex. This allows the next thread that asked for a lock to - * lock the mutex and continue with execution. + * Unlock the mutex. This allows the next thread that asked for a lock + * to lock the mutex and continue with execution. */ int unlock(); /** - * Try to lock the mutex. This is the option to go with if you cannot avoid - * putting lengthy operations within a locked section. trylock will attempt - * to lock the mutex, if the mutex is already locked this function returns - * immediately with an error code. + * Try to lock the mutex. This is the option to go with if you cannot + * avoid putting lengthy operations within a locked section. trylock + * will attempt to lock the mutex, if the mutex is already locked this + * function returns immediately with an error code. */ int trylock(); diff --git a/src/itoqueue.h b/src/itoqueue.h index 5945344..1a4e0b6 100644 --- a/src/itoqueue.h +++ b/src/itoqueue.h @@ -16,6 +16,7 @@ namespace Bu * something is enqueued within the specified time limit, or NULL if the * time limit is exceded. *@author Mike Buland + *@ingroup Threading Containers */ template class ItoQueue @@ -59,11 +60,11 @@ namespace Bu } /** - * Enqueue a pieces of data. The new data will go at the end of the queue, - * and unless another piece of data is enqueued, will be the last piece of - * data to be dequeued. - *@param pData The data to enqueue. If this is not a primitive data type - * it's probably best to use a pointer type. + * Enqueue a pieces of data. The new data will go at the end of the + * queue, and unless another piece of data is enqueued, will be the + * last piece of data to be dequeued. + *@param pData The data to enqueue. If this is not a primitive data + * type it's probably best to use a pointer type. */ void enqueue( T pData ) { @@ -91,20 +92,22 @@ namespace Bu } /** - * Dequeue the first item from the queue. This function can operate in two - * different modes, blocking and non-blocking. In non-blocking mode it will - * return immediately weather there was data in the queue or not. If there - * was data it will remove it from the queue and return it to the caller. - * In blocking mode it will block forever wating for data to be enqueued. - * When data finally is enqueued this function will return immediately with - * the new data. The only way this function should ever return a null in - * blocking mode is if the calling thread was cancelled. It's probably a - * good idea to check for NULL return values even if you use blocking, just - * to be on the safe side. - *@param bBlock Set to true to enable blocking, leave as false to work in - * non-blocking mode. - *@returns The next piece of data in the queue, or NULL if no data was in - * the queue. + * Dequeue the first item from the queue. This function can operate in + * two different modes, blocking and non-blocking. In non-blocking + * mode it will return immediately weather there was data in the queue + * or not. If there was data it will remove it from the queue and + * return it to the caller. + * + * In blocking mode it will block forever wating for data to be + * enqueued. When data finally is enqueued this function will return + * immediately with the new data. The only way this function should + * ever return a null in blocking mode is if the calling thread was + * cancelled. It's probably a good idea to check for NULL return + * values even if you use blocking, just to be on the safe side. + *@param bBlock Set to true to enable blocking, leave as false to work + * in non-blocking mode. + *@returns The next piece of data in the queue, or NULL if no data was + * in the queue. */ T dequeue( bool bBlock=false ) { @@ -143,15 +146,15 @@ namespace Bu } /** - * Operates just like the other dequeue function in blocking mode with one - * twist. This function will block for at most nSec seconds and nUSec - * micro-seconds. If the timer is up and no data is available, this will - * just return NULL. If data is enqueued before the timeout expires, it - * will dequeue and exit immediately. + * Operates just like the other dequeue function in blocking mode with + * one twist. This function will block for at most nSec seconds and + * nUSec micro-seconds. If the timer is up and no data is available, + * this will just return NULL. If data is enqueued before the timeout + * expires, it will dequeue and exit immediately. *@param nSec The number of seconds to wait, max. *@param nUSec The number of micro-seconds to wait, max. - *@returns The next piece of data in the queue, or NULL if the timeout was - * exceeded. + *@returns The next piece of data in the queue, or NULL if the timeout + * was exceeded. */ T dequeue( int nSec, int nUSec ) { @@ -195,9 +198,9 @@ namespace Bu } /** - * Checks to see if the queue has data in it or not. Note that there is no - * function to determine the length of the queue. This data isn't kept - * track of. If you really need to know, fix this. + * Checks to see if the queue has data in it or not. Note that there + * is no function to determine the length of the queue. This data + * isn't kept track of. If you really need to know, fix this. *@returns True if the queue is empty, false if it has data in it. */ bool isEmpty() diff --git a/src/itoserver.h b/src/itoserver.h index 60b15b4..729ae7a 100644 --- a/src/itoserver.h +++ b/src/itoserver.h @@ -34,6 +34,8 @@ namespace Bu * In order to use a Server you must subclass it and implement the pure * virtual functions. These allow you to receive notification of events * happening within the server itself, and actually makes it useful. + *@author Mike Buland + *@ingroup Threading Serving */ class ItoServer : public Ito { diff --git a/src/list.h b/src/list.h index ec0c195..8152e6b 100644 --- a/src/list.h +++ b/src/list.h @@ -25,6 +25,7 @@ namespace Bu *@param value (typename) The type of data to store in your list *@param valuealloc (typename) Memory Allocator for your value type *@param linkalloc (typename) Memory Allocator for the list links. + *@ingroup Containers */ template, typename linkalloc=std::allocator > > class List diff --git a/src/main.dox b/src/main.dox deleted file mode 100644 index 668d2e3..0000000 --- a/src/main.dox +++ /dev/null @@ -1,14 +0,0 @@ -/** - *@mainpage libbu++ utility library - * - *@section secIntro Introduction - * - * Libbu++ is a C++ library of general utility classes and functions. They - * cover a wide range of topics from streams and sockets to data structures to - * data serialization and xml handling to threading. - * - */ - -/** - *@namespace Bu The core libbu++ namespace, to ensure things don't get muddied. - */ diff --git a/src/protocol.h b/src/protocol.h index bca337f..7b69553 100644 --- a/src/protocol.h +++ b/src/protocol.h @@ -8,7 +8,8 @@ namespace Bu class Client; /** - * + *@author Mike Buland + *@ingroup Serving */ class Protocol { diff --git a/src/ringbuffer.h b/src/ringbuffer.h index be80e2f..6a4eecf 100644 --- a/src/ringbuffer.h +++ b/src/ringbuffer.h @@ -6,6 +6,9 @@ namespace Bu { + /** + *@ingroup Containers + */ template > class RingBuffer { diff --git a/src/server.h b/src/server.h index 302b6e3..499bf26 100644 --- a/src/server.h +++ b/src/server.h @@ -30,6 +30,8 @@ namespace Bu * In order to use a Server you must subclass it and implement the pure * virtual functions. These allow you to receive notification of events * happening within the server itself, and actually makes it useful. + *@author Mike Buland + *@ingroup Serving */ class Server { diff --git a/src/serversocket.h b/src/serversocket.h index b4ee247..751768d 100644 --- a/src/serversocket.h +++ b/src/serversocket.h @@ -15,6 +15,9 @@ namespace Bu * * Although the accept function returns an integral file descriptor, it is * designed to be used with the Socket class. + * + *@author Mike Buland + *@ingroup Serving */ class ServerSocket { diff --git a/src/set.h b/src/set.h index ce2c10a..f35f1f0 100644 --- a/src/set.h +++ b/src/set.h @@ -33,6 +33,7 @@ namespace Bu *@param sizecalc (typename) Functor to compute new table size on rehash *@param keyalloc (typename) Memory allocator for hashtable keys *@param challoc (typename) Byte allocator for bitflags + *@ingroup Containers */ template class Set diff --git a/src/socket.h b/src/socket.h index d0949cc..95271f8 100644 --- a/src/socket.h +++ b/src/socket.h @@ -9,7 +9,8 @@ namespace Bu { /** - * + *@author Mike Buland + *@ingroup Serving Streams */ class Socket : public Stream { diff --git a/src/sptr.h b/src/sptr.h index bccf887..aac7f48 100644 --- a/src/sptr.h +++ b/src/sptr.h @@ -9,6 +9,9 @@ namespace Bu template class SPtr; template< typename Tb, typename Ta > SPtr SPtrCast( SPtr src ); + /** + *@ingroup Containers + */ template class SPtr { diff --git a/src/tafnode.h b/src/tafnode.h index 4940bee..585ba73 100644 --- a/src/tafnode.h +++ b/src/tafnode.h @@ -10,6 +10,7 @@ namespace Bu { /** * + *@ingroup Taf */ class TafNode { @@ -33,6 +34,10 @@ namespace Bu class TafProperty; class TafComment; + /** + * + *@ingroup Taf + */ class TafGroup : public TafNode { public: @@ -68,6 +73,10 @@ namespace Bu NodeList lChildren; }; + /** + * + *@ingroup Taf + */ class TafProperty : public TafNode { public: @@ -82,6 +91,10 @@ namespace Bu Bu::FString sValue; }; + /** + * + *@ingroup Taf + */ class TafComment : public TafNode { public: diff --git a/src/tafreader.h b/src/tafreader.h index eeaafb3..da285ab 100644 --- a/src/tafreader.h +++ b/src/tafreader.h @@ -10,6 +10,7 @@ namespace Bu { /** * + *@ingroup Taf */ class TafReader { diff --git a/src/tafwriter.h b/src/tafwriter.h index f34395e..3e578d8 100644 --- a/src/tafwriter.h +++ b/src/tafwriter.h @@ -10,6 +10,7 @@ namespace Bu { /** * + *@ingroup Taf */ class TafWriter { diff --git a/src/tests/size.cpp b/src/tests/size.cpp new file mode 100644 index 0000000..be13b69 --- /dev/null +++ b/src/tests/size.cpp @@ -0,0 +1,13 @@ +#include "bu/hash.h" +#include "bu/fstring.h" + +#define pSize( t ) printf("%15s: %db\n", #t, sizeof( t ) ); + +int main() +{ + typedef Bu::Hash charcharHash; + typedef Bu::Hash strstrHash; + pSize( Bu::FString ); + pSize( charcharHash ); + pSize( strstrHash ); +} -- cgit v1.2.3