| Age | Commit message (Collapse) | Author |
|---|
|
copyright 2007-2008.
|
|
as includes go. This required a little bit of reworking as far as archive goes,
but I've been planning on changing it aronud for a bit anyway.
The final result here is that you may need to add some more includes in your
own code, libbu++ doesn't include as many random things you didn't ask for
anymore, most of these seem to be bu/hash.h, unistd.h, and time.h.
Also, any Archive functions and operators should use ArchiveBase when they can
instead of Archive, archivebase.h is a much lighterweight include that will
be used everywhere in core that it can be, there are a few classes that actually
want a specific archiver to be used, they will use it (such as the nids storage
class).
So far, except for adding header files, nothing has changed in functionality,
and no other code changes should be required, although the above mentioned
archive changeover is reccomended.
|
|
double, or long double...now it does.
|
|
wrote it, it's pretty feature complete, index, append, iterators. You can't
delete anything yet, exactly, but that's tricky in an array anyway, basically
you just want to be able to remove elements from the end, and that's halfway
there.
Also, fixed some documentation and minor issues in Bu::Set, and made the
Bu::Archive include fewer other classes while still defining archive oprators
for them. I think I may yet move those into the headers for the classes that
are being stored instead, makes a little more sense.
I also would like to move the Exception classes out of the exceptions.h file
and into the appropriate class' files'. There still should probably be a
couple of general ones in there, or maybe just in exceptionbase.h, we'll see.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
a Bu::Hash due to the new return value of the unary (*) extraction operator in
the iterators.
|
|
conflicts from happening. And, from now on, other projects should do -Ilibbu++
not -Ilibbu++/src so we can get ready for an installed version of libbu++.
|
|
archive dependancies a little. I'll add docs for object tracking later...
|
|
not done. I need to decide how I want to do the buffering...
|
|
I guess I should write a test for it too...
I'm also thinking of removing the S from the front of the stream children.
|
|
work for the SSocket, that should be cool.
|
|
tweaks to archive. The && operator is now a template function, and as such
requires no special handling. It could be worth it to check this out for other
types, yet dangerous, since it would let you archive anything, even a class,
without writing the proper functions for it...we shall see what happens...
|
|
isn't done yet, I'm going to make it rely on streams, so those will be next,
then we can make it work all sortsa' well.
|
