| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
