| Age | Commit message (Collapse) | Author |
|---|
|
hell out of it. Good times, everyone. This is a major chunk for congo, and
the new optimizations should be good.
|
|
targets... added buildMinGW.conf file for targeting win32... undef-d cpy macro in fstring
|
|
expected operators now, like plus. It was annoying without them.
|
|
|
|
|
|
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.
|
|
It's backword compatible, and the new features are a lot of fun. Since it uses template functions you can add any new variable types to be formatted.
|
|
|
|
asked for the string, no null pointers anymore.
|
|
the pipes properly, resulting in the child process going defunct and not dying,
it also wasn't buffering properly, it now collects as much data as it can before
returning from a read operation.
|
|
|
|
|
|
|
|
coming up...it's just like popen only cool and managed, and streamey.
|
|
|
|
of which use printf style formatting and accept the same parameters as printf.
|
|
in const objects :-P
|
|
|
|
|
|
has been fixed, it now safely disconnects after emptying the Client's outgoing
buffer.
Added some more helpers to Bu::FString.
Added the beginings of ProtocolHttp using a new method for processing protocols
that's based more strongly on an NFA state machine, this makes sense, but I
never had the desire to actually try implementing it before. It's working
pretty well.
|
|
using system variables and special tokens, such as ~name and ~/...
I like this, and think that it's ample precedent for adding things like
format(), formatAppend(), and formatPrepend(), which would all rock.
|
|
Also added more tests to the FString unit tests and switched the ParamProc to
using FString instead of std::string, this will break a few programs in very
minor ways, a few seconds each to fix, I'd say.
|
|
|
|
|
|
compile under OSX. So far, no problems with anything else, it looks like build
and nango both build without problems, libbu++ is truly becoming a full cross-
platform toolkit.
|
|
|
|
the right way.
|
|
now, but some more testing needs to be done.
|
|
|
|
|
|
|
|
possible to make this much faster than I did, so I'll have to take another
crack at it later.
|
|
classes.
|
|
can't have that and an indexing operator. More research with other compilers
needs to be done if we want to try just having the cast operator. I would
rather be able to index than auto-cast.
|
|
working in optimal condition...
|
|
|
|
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++.
|
|
|
|
These allow you to see if there is anything set in the fstring.
|
|
a decent replacement for multilog now that we use runit.
|
|
|
|
|
|
still trying to use a pair internally. Also added more helpers to FString.
|
|
had anticipated, and much cleaner. I'll have to add some documentation to it,
because it's not really obvious how any of it fits together from the outset,
although I have to say that the bzip2 test program is the easiest general bzip2
compression program I've ever made...it just goes :)
Decompression in Bu::BZip2 isn't finished yet, but that's ok, it's coming soon.
|
|
the std::string copy by a rather large margin. This seems very odd, so I'm
going to do a few tests, the first one is stripping out the FString shared
pointer stuff and seeing if that makes an appreciable difference.
|
|
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.
|
|
const pointer version of the raw data.
|
|
be a few more add-ons to it, but it works just fine, and eventually it should
cover command line options and creating logs, and possibly even provide output
functionality so that output from tests can be logged and kept track of well.
|
|
work for the SSocket, that should be cool.
|
|
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.
|
