| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
fstring, and updated the copyright notice to extend to 2011
|
|
may be a few other things that should change too, we'll see.
Played with doxygen docs on List, we can actually use @cond to remove things
from the docs, either permenently or conditionally, and so I could trick it into
making all of the sharedcore classes inherit from the same SharedCore in the
docs instead of different ones. Or, just not inherit from SharedCore at all.
What to do...? :-P
I also got rid of ListHash, it wasn't working out yet anyway.
|
|
another object of the parent type has the same core, and another to clone the
parent object. That one is pretty cool, it means you can now get a real copy
when you want to, great for multi-threaded stuff.
Also, two more classes are now SharedCore: Hash and Heap!
|
|
|
|
The CsvWriter now writes csv. It understands both excel formatting and c-style,
which I made up myself (it's just c-style escape sequences).
Sha1 is converted to work with the CryptoHash API and it does indeed work.
|
|
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.
|
