| Age | Commit message (Collapse) | Author |
|---|
|
Unicode handling we'll need to implement a series of codecs and converters as
well as tables of codepages and lookups. It'll be interesting, I guess, but
it makes me care a lot less about proper encoding. Anyway, UtfString uses
shorts instead of chars, so it's a step in the right direction, but still not
enough to be able to handle proper UTF-16 encoding, maybe UCS-2 encoding, but...
...that's lame. Bu::FBasicString has been generalized a bit with optimizations
from libc for char based strings. It also, unfortunately, still uses char-only
functions in several places, those all rely on char casting strings at the
moment just to get the thing to compile. Basically, it's not a good UTF-16
solution yet, and it may never be and remain compatible with char based strings.
|
|
TcpSocket, fixed many other things, and finally removed ParamProc. Anything
that needs it will now have to switch to OptParser.
|
|
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!
|
|
remove function. memcpy can't do overlapping memory, changed it to use memmove.
|
|
|
|
|
|
|
|
|
|
way, way, way more problems than it solved. A number of libbu++ tests were
inacurate because of it, there were problems in several other programs, and
there may be more that have problems we haven't found yet because of this.
This will most likely cause complitaion errors, especially in places we didn't
expect, where strings were being stored into or passed as integers and the like.
In cases where you were just testing a string, just call the "isSet()" function,
which is functionally equivellent to the old bool cast operator.
|
|
|
|
copyright 2007-2008.
|
|
a shell, but I may finish it soon, and started work on NewLine, a filter that
converts newlines in text streams between the different OS standards.
Also added some more helper operators to fbasicstring.
|
|
|
|
char from the back of the string.
|
|
|
|
|
|
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.
|
|
change to the Taf system. Really all that's happened is I've broken out the
core taf data types into seperate files, and gone ahead and created a helpful
new header file ("taf.h") that will include the entire taf system, including
the reader and writer for you.
This means that a lot of programs will start complaining, but fortunately,
there's an easy solution, if it complains about taf, make sure to include taf.h
at the top, instead of other taf files and you'll be set.
The next set of changes will add lots of helpers to the taf system and change
the reader to read non-const structures, i.e. I'll actually add editing support
to created taf structures.
|
|
didn't hardcopy appropriately.
|
|
causing memory corruption, and fbasicstring is playing even nicer with shared
core now.
|
|
much anymore, for the fishtrax issues, maybe.
|
|
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.
|
|
Also added some awesome helpers to Bu::FString in the form of << operators to
convert a string to many common types. Handy.
|
|
|
|
|
|
parsing functions publicly accessible in Url, and added some more helpers.
|
|
functions for comparing with chr type.
|
|
|
|
the index operator is out of range...
|
|
isBlocking function was backward), and fastcgi is actually working now!
Also added comparison functions to FString.
|
|
adding some more helpers. Hopefully this won't affect anything, but if it
complains about any functions not working the way they used to, see if they're
returning an int or an iterator. I made several functions handle iterators
instead of ints, the int versions have an "Idx" suffix added now. I'm trying
to switch entirely to iterators to reduce flattening and increase performance
and stability.
Also...something must have changed in the cache code...
|
|
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.
|
|
1) i had to make iterator and const_iterator friends of each other so they could see each other's private constructors
2) apparently there is a bug in the name-lookup related to inline typedef structs and the friend keyword... had to move the typedef struct const_iterator to after the actual struct.
|
|
ProtocolTelnet. I'm going to have to do some reading and find out just where
ProtocolTelnet is...
|
|
indexing. It is now many times faster, and requires less overhead. Also,
more stuff iterator related in every class. More on that later.
|
|
files. This won't affect any programs at all anywhere. This will just make it
easier to maintain and extend later. You still want to include "bu/fstring.h"
and use Bu::FString in code.
The other is kinda fun. I created a special format for unit tests, they use the
extension .unit now and use the mkunit.sh script to convert them to c++ code.
There are some nice features here too, maintaining unit tests is much, much
easier, and we can have more features without making the code any harder to use.
Also, it will be easier to have the unit tests generate reports and be run from
a master program and the like.
|
