Re: Please help with testing & improving a StringValue class
* Roland Pibinger:
On Sat, 08 Sep 2007 10:21:59 +0200, "Alf P. Steinbach" wrote:
I once suggested in [comp.std.c++] that SomeOne Else(TM) should propose
a string value class that accepted literals and char pointers and so on,
with possible custom deleter, and in case of literal strings just
carrying the original pointer.
In other words, for the simplest usage code:
* no overhead (just carrying a pointer or two), and
* no possibility of exceptions (for that case).
IOW, you created an assignable but otherwise immutable string class
that provides an optimization for string literals.
And also for the case of passing around a string with a custom delete
operation, e.g. as provided by many API functions such as Windows'
command line parsing.
When using std::string or std::wstring for this, the API function's
string must first be copied, where dynamic allocation is used, and then
freed (using its own delete operation). This is costly. Then, when
that string should be passed to an API function again, the std::string
must sometimes be copied to dynamically allocated memory using the API's
allocator. Which might happen many times for the same string. This is
costly. A string value class with custom deleter, such as StringValue,
solves that problem. No costly dynamic allocations, and no O(n) copy
operations, for the cases where such operations can be dispensed with by
keeping a delete function along with the string value.
Of course the last can also be accomplished using e.g.
boost::shared_ptr. But then different kinds of strings have to be
treated differently, with conversion among them. And it's awkward
anyway, so awkward that I don't think anybody's done exactly that.
[snip]
The code uses boost::intrusive_ptr from the Boost library, which
therefore is required to compile.
If you want your code to be widely used you should get rid of the
Boost dependency (which seems to be no problem in your case).
It think most C++ programmers have the Boost library installed.
But since that's a huge library, it would perhaps be an idea to bundle
the one or few Boost files that's actually used?
intrusive_ptr is just header file code, not separate compilation.
Strings with embedded zero characters
are not supported in the current code. I don't think the need is great.
Example usage code
StringValue foo()
{
return "No dynamic allocation, no possible exception, fast";
}
StringValue bar()
{
return std::string( "A dynamic" ) + " copy";
}
In general, the string literal optimization is a good idea. The design
of such a class (template) poses the real challenge. For various
reasons it should hold that sizeof StringValue == sizeof void*. You
need to find a way to distinguish a dynamically allocated array from a
string literal without additional information in the object (not even
an additional flag). One of the reasons for the above is the
requirement of thread safety for string assignment and copying.
Unfortunately there seems to be no way to implement a 'lightweight'
thread-safe assignment operator and/or copy constructor because
incrementing/decrementing the reference-counter and assignment of the
pointer are always two distinct operations. I experimented with my own
string class but could not reach a satisfactory result WRT thread
safety (i.e. when the object is accessed by multiple threads).
Uhm, that's a different problem. Essentially, if I understand you
correctly, the problem is what trade-off can you do so that in the case
of multi-threaded access to the same string, the total cost of safe
copying is less than with a mutex or whatever? And I think the best
answer is to /not/ accept the premise that multi-threaded access to the
same string without some external thread synchronization such as a
mutex, is something one should support: instead, avoid it!
I think it's in the same league as designing a language to support
arbitrary gotos. That would restrict the language severely (e.g., gotos
past object construction renders all construction guarantees void, so to
support arbitrary gotos, no object construction guarantees). And
instead of designing the language with the goal of supporting
unrestricted gotos, the sensible course is IMHO to restrict gotos.
Example exercising all currently defined constructors, where malloc and
free is used just to demonstrate that also that is possible:
<code>
#include <alfs/StringValueClass.hpp>
#include <iostream>
#include <cstdlib> // std::malloc, std::free
#include <cstring> // std::strcpy, std::strlen
char const* mallocStr( char const s[] )
{
using namespace std;
return strcpy( static_cast<char*>( malloc( strlen( s ) + 1 ) ), s );
}
void myDeleter( void const* p ) { std::free( const_cast<void*>( p ) ); }
int main()
{
// A StringValue can be freely copied and assigned, but the value
// can not be modified.
using namespace alfs;
char const* const dynValue = "dynamic copy";
char const* const ptrValue = "pointer to persistent buffer";
char const* const customValue = "custom delete";
char const sizedValue[] = { 's', 'i', 'z', 'e', 'd' };
StringValue literal( "literal" ); // No alloc.
StringValue pointer( ptrValue, NoDelete() ); // No alloc.
StringValue custom( mallocStr( customValue ), myDeleter );
StringValue sized( sizedValue, sizeof( sizedValue ) );
StringValue dynamic( dynValue );
StringValue stdval( std::string( "std::string" ) );
std::cout << literal << std::endl;
std::cout << pointer << std::endl;
std::cout << custom << std::endl;
std::cout << sized << std::endl;
std::cout << dynamic << std::endl;
std::cout << stdval << std::endl;
}
</code>
Code currently available (especially if you want to help testing and or
discussing functionality or coding, whatever) at
<url: home.no.net/alfps/cpp/lib/alfs_v00.zip> (lawyers, if any: note
that I retain copyright etc., although usage is of course permitted).
A lot of established Open Source licenses like MIT, new BSD
(http://www.opensource.org/licenses/alphabetical) or ISC
(http://en.wikipedia.org/wiki/ISC_license) are available.
Thank you.
I think I heard something about the Apache license, too.
Cheers, & thanks for your constructive feedback (much I hadn't thought
about!),
- ALf