| Age | Commit message (Collapse) | Author |
|---|
|
|
|
be corrected, they were using standard library features, that shouldn't be hard
to fix though.
|
|
|
|
whatever it'll be called later...
|
|
inconsistancies when archiving compared to their STL counterparts, they are now
compatible on every system I can imagine. Also, List now uses a long instead
of an int for sizing, and the other containers should as well. I'll check on
that later.
That means that the files will all be larger on a 64 bit system, but such is
life. The same thing happens when you use STL classes. There may be other
inconsistancies down the road, we'll see.
|
|
it's a bad idea to rely on the intNN_t typedefs. I enumerated all non-pointer
primitives in c++ (except void, you can't store things in a void), and it works
great. I also discovered C and C++ actually have unsigned char, signed char,
and char, which are all distinct types. It supports all three now.
In addition, I got rid of all of the specific && operators, the general one
covers it all. Also, the unit tests all pass for now. Now to try it on the
64bit system.
|
|
I wouldn't update to this just yet, if you have problems, back off a rev. I'm
trying to update the code to work on both 32bit, and 64bit systems, and
hopefully anything else that comes along.
Currently some of the archive code is broken, testing must be done on both
archetectures.
|
|
use.
|
|
logger...I guess.
|
|
|
|
version of gcc complained about them, none of these changes will break backward
compatibility, so I fixed them.
I added more docs too, it seems.
|
|
writer also knows about \\, but will not insert \t or \n for now. It just uses
a tab and newline for those.
|
|
time anyway. Recompile everything.
|
|
it yet, the name will change. I really, really, really want the name to change.
|
|
|
|
enabled, and the compiler/libc support it, then you just get backtraces, if not
you get a message about it not being supported. It probably shouldn't be
enabled in most production environments, since it does happen for every
exception, and could be memory and time consuming.
|
|
|
|
it's basically an uber-simple counter class that's thread-safe!
|
|
fact, I need to get in there and change all the comments and exceptions in Set
to refer to Set and not Hash). Util has the functors in it that are shared now,
and List actually uses those functors for it's insertSorted function, that thing
has come in so handy.
|
|
fixed, and the Bu::ItoHeap is working and tested. Note that when multiple items
have the same sort order, they will come out in random order.
|
|
allocators for all work, every data type used in a Bu::Heap must support the
equals operator and <= or >=, or you need to write your own comparison functor.
The heap works as both a min-heap and max-heap, just change out the functor used
for camparison, kinda' cool.
The print function I'll leave in for a little while, but not in the long run, it
just prints a dot graph to stdout.
Next up, the Ito version.
|
|
I'm thinking the heap should add one layer to the binary tree each time it
grows, which means double+1 each time. The Bu::ItoHeap will be implemented as
soon as the rest of Bu::Heap is done.
Also, I finally added bu/util.h which is mainly handy template functions like
Bu::swap, Bu::min, Bu::max, and Bu::mid. A few more may be added.
|
|
exceptions.
|
|
|
|
sever/client-link system.
|
|
|
|
done yet. The Client class now supports a function called getLink() which
returns a ClientLink object. This object may then be passed off to any other
class and called to send messages to that client object. It is threadsafe if
ItoServer is being used, and not for Server. Sending a message via a
ClientLink calls the onMessage function on the assosiated protocol.
Note that sending messages from within protocol event handlers or functions they
call, while safe, may be slow and it's reccomended that you avoid this.
|
|
that the client would disconnect so quickly that it would be cleaned up before
it was properly accounted for. I apparently added something to MiniMacro a
while ago...probably the end tags I think...
|
|
|
|
Bu::FString reference as a parameter. Unfortunately you need to remember to add
"using Stream::write;" to each child class so they can take advantage of it.
Strange, no?
Also, cleaned up a bunch of header files, I'm trying to move towards headers
only including other headers that they absolutely need, otherwise just creating
forward decleration sections at the top of each.
|
|
strings, which are no longer handed out in the Bu::FString, I think it's better
this way, but the Bu::ParamProc may need a little re-working to make it just
right (right now the default value of a string cannot be empty, doesn't sound
too bad...)
|
|
options...
|
|
It's backword compatible, and the new features are a lot of fun. Since it uses template functions you can add any new variable types to be formatted.
|
|
|
|
Also removed some debugging from Process, it needs a helper to clear a buffer,
or an option to ignore stderr.
|
|
installed. That was odd. Anyway, also set props on the bu, unit, and test
directories so that the contents won't be listed on svn status.
|
|
|
|
|
|
asked for the string, no null pointers anymore.
|
|
effort.
|
|
but it does everything I need it to at the moment.
|
|
not the last...
|
|
from the stream even when it should have known it was at the end, and then it
was reading an extra character after that anyway :-P It is now fixed, and the
stream is positioned at the character immediately after the closing } of the
root taf group, great for things like the svtools.
|
|
the pipes properly, resulting in the child process going defunct and not dying,
it also wasn't buffering properly, it now collects as much data as it can before
returning from a read operation.
|
|
|
|
|
|
|
|
coming up...it's just like popen only cool and managed, and streamey.
|
|
reading from standard output/input.
|
|
compile error I introduced last commit.
|
