| 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.
|
|
getChildByPath (for groups) to the TafGroup class.
|
|
element to the list in the constructor.
|
|
it's easier when they're in list.
|
|
but I made the Formatter << operator for Lists use the List with the value as
the template parameter, and no others, so if you actually tune the list, you
can't format it anymore. This has been fixed.
|
|
there are a couple more fine points to touch on in Bu::Hash::iterator, I should
go through and review the whole thing at this point (iterator-wise).
|
|
much anymore, for the fishtrax issues, maybe.
|
|
a reference to the list, so you can chain appends and whatnot.
|
|
Bu:;SharedCore actually is in and works, it's well tested and there are no
known memory leaks or violations as of now. It's been applied to Bu::List and
Bu::FBasicString so far. This means that everything using Bu::List and
Bu::FBasicString will be much, much faster and use considerably less memory.
I still have plans to apply this to Hash and maybe a couple of other core
classes.
|
|
|
|
now works correctly, and they don't worry about which list they're assosiated
with. Better errors too.
|
|
isBlocking function was backward), and fastcgi is actually working now!
Also added comparison functions to FString.
|
|
|
|
operator and the left-hand-side FString was const. Also, added a formatter <<
operator for Bu::List. The other containers should get their own formatter <<
operators soon too.
|
|
indexing. It is now many times faster, and requires less overhead. Also,
more stuff iterator related in every class. More on that later.
|
|
append one list to another and the like.
Also, wow, I found a bug that's been around for ages, I guess we don't copy
hash tables often. The interesting thing is that it actually worked, it copied
but it would include any data that had been deleted in the old hash table but
not reclaimed yet and insert it as new data. Usually the key had been
completely destroyed (like with a string) so it came out as keyed to blank
string. So in cases like that, all deleted keys would collapse into one deleted
key in the new hash table.
|
|
properly formed iterator. That caused a few problems. I think it's all set
now though.
|
|
added some more tests and whatnot. A lot happened, but I can't remember
everything.
Also, Bu::File reports errors in more error cases.
|
|
ok, nids is still in flux, they'll be gone soon).
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
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.
|
|
right now. Unfortunately it doesn't compile right now, if you want to build
this version, just delete array.
On the other hand, Bu::List now has enqueue/dequeue functions.
|
|
including StopOnError and handling/reporting of external exceptions.
|
|
|
|
|
|
|
|
|
|
|
|
lThings.erase( lThings.begin() );
|
|
soon, check it out...later...
|
|
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++.
|
|
|
|
|
|
nodes, that part will be exciting. I also fixed some stuff and added some new
functions to List, it now has first() and last() which work just like std::list
front() and back(), I may add compatibility functions later...
|
|
with objects at the moment, still contemplating that one...
|
|
actually interacting with clients, and the Client class is almost there, except
that it doesn't really do anything yet.
|
|
should act, you can't change anything in there. I'm still debating changing
the const_iterator to a constIterator, or something else that's more Bu::worthy.
Heh, the namespaces are funny...ok...I'm really tired.
|
|
forgotten proper cleanup in the deconstructor, but besides that you can do
almost everything you need. I'll make a slist/stack next, probably with the
same basic code, just a different structure (not doubley-linked).
The xml system from old-libbu++ is almost completely converted, I was going to
re-write it, but this seemed easier at first, it may not have been, we'll see.
It almost parses everything again, and almost outputs again, and it does use
streams now.
The FString is partway to doing minimum chunk allocations, so that adding
single-characters will be really fast up to the minimum chunk size. I also
figured out how to add this optimization without any extra variables taking
up space, and it's optional in the template, which is cool. You can specify
the size of the blocks (default 256 bytes), if it's 0 then they'll be like the
old FString, 1 chunk per operation.
The next FString update should be allowing efficient removal from the begining
of the string by faking it, and simply moving a secondary base pointer ahead,
and then optimizing appends after that fact to simply move the existing data
around if you shouldn't have to re-allocate (alla FlexBuf). The final fun
addition that I'm planning is a simple switch in the template (boolean) that
will switch an FString into a thread-safe mode without changing the interface
or anything that you can do with them at all. It may increasing memory usage,
but they should still be better than std::strings, and totally thread-safe.
The best part of that is that if it's done with a boolean template parameter and
if statements that only test that parameter controlling flow, the code that you
don't want (threadsafe/non-threadsafe) won't be included at all
post-optimization.
|
|
into src as it's fixed and re-org'd. This includes tests, which, I may write a
unit test system into libbu++ just to make my life easier.
|
|
|
