On Tue, 15 Dec 2009, Jérémy Zurcher wrote:
That said, if you have any ideas on how to get (or make) some
RT-safe dynamic strings... please share. I'm interested in having
that for Composite as well... so that even when there's an error
we're RT-safe.
quick and dirty thoughts :
do something like errno perror does,
have a global or per class static index of error strings
send only the error code (and an instance reference maybe ) to the logger,
then let the well known logger thread fetch the string and output it.
Ah, but these wouldn't be /dynamic/ strings. These would be
fixed strings. :-)
One way to go is to look into the implementation of QString
and std::string and see if we can use the .reserve(N) method
to accomplish our goals. It's unlikely in both cases...
because I think they always allocate space on the heap.
Possibly this can be fixed by using a different allocator.
However, a string class could be created that meets the
requirement:
template <typename CharT, size_t Max>
class RtString
{
public:
typedef CharT value_type;
const size_t max_chars;
const size_t npos;
/* Formatting: "There are @ objects", where @
* will be replaced through one of the arg()
* functions.
*/
RtString(const CharT* msg);
~RtString() {}
RtString& arg(unsigned i);
// This should not be part of the final
// class...
CharT* ref() { return _data; }
operator CharT* () { return _data; }
size_t size() { return _size; }
protected:
// Search for next '@' sequence.
size_t insertion_location();
// Shift everything over, discarding the @
void make_room(size_t pos, size_t n);
private:
CharT _data[Max + 1];
size_t _size;
};
typedef RtString<char, 140> LogString;
Typical usage would be like this:
ERRORLOG( LogString("There were @ cats").arg(125) );
Which would spit out:
"There were 125 cats"
If you overflow your message buffer... we just truncate the
message.
I put together a full proof-of-concept, with a ringbuffered
logging thread, in here:
http://gitorious.org/composite/composite-labs/trees/94ecd61eee5ab05b6dd427df12a890ee773de16b/200912-rtstring
Comments are welcome!
(I love little puzzles like this... :-))
Peace,
Gabriel
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
