string indexing class proposal

[marlowa]

I think it would be useful for the Foundation set of classes to have a new member designed to provide strings in a more efficient way than std::string. These strings are for construction from a long-lived buffer. For example, when one reads a record from a file and does alot of string processing on it, it would be useful if the strings used during processing where constructed from the buffer and its length. Traditionally this has been done by simply creating a new std::string from it. However, a new class could just store the buffer address and the length.This class can provide methods to split and search the string where the return values are also variables of this type. Let us refer to this new type as a string index. This makes string operations that employ a long-lived string buffer very efficient. Lots of std::string creations and copies can be very expensive for small strings. This is wasteful when such copies are copies from a buffer that is going to hang around. These string indexes have to hold a length parameter as well as a buffer pointer, so string length functions operate much faster. I think this would be a useful addition to the Foundation set of classes.

I have in mind some implementation for this but I just wanted to float the idea past initially. It would also be good to get some suggestions for what this class might be called. I want to avoid the work 'reference', since it might make people think of reference counting. So far I have come up with StringIndex and/or StringDescriptor. StringIndex is more precise than StringDescriptor since it is to due to with storing an index into the original buffer, but descriptor sounds nicer.

Any thoughts?

Andrew Marlow

[peter]

How about ImmutableString?
cu
Peter

[marlowa]

> How about ImmutableString?
> cu
> Peter

Sure, fine, but that's not what I am proposing. A string index is basically the address of a char buffer and its operational length, along with some functions for doing common string operations such as compare, test for empty, return substring and return next token. It would probably have to be templated on the char type so you can have char, unsigned char, wide characters etc.

[guenter]

That's basically how strings in Java work. Java strings are immutable, hence the name: ImmutableString

[peter]

> > How about ImmutableString?
> > cu
> > Peter
>
> Sure, fine, but that's not what I am proposing. A string index is basically the address of a char buffer and its operational length, along with some functions for doing common string operations such as compare, test for empty, return substring and return next token. It would probably have to be templated on the char type so you can have char, unsigned char, wide characters etc.

Yep, that was clear but basically, string objects that use this buffer are immutable, so there are no append or other modifying operations on such objects.
I just like it better because the name StringIndex describes the implementation behind while ImmutableString describes a property of the String class but that's a matter of taste.
Just see it as one more name you can choose from :-)

[alex]

> > > How about ImmutableString?
> > > cu
> > > Peter
> >
> > Sure, fine, but that's not what I am proposing. A string index is basically the address of a char buffer and its operational length, along with some functions for doing common string operations such as compare, test for empty, return substring and return next token. It would probably have to be templated on the char type so you can have char, unsigned char, wide characters etc.
>
> Yep, that was clear but basically, string objects that use this buffer are immutable, so there are no append or other modifying operations on such objects.
> I just like it better because the name StringIndex describes the implementation behind while ImmutableString describes a property of the String class but that's a matter of taste.
> Just see it as one more name you can choose from :-)
>

I'm definitely no Java expert, even less a fan. I am a bigmouth however ;-) , hence allow me to try to summarize this. If I get it right, the following is being proposed:

Java StringBuffer => Poco std::string
Java String => Poco ImmutableString

I vote for name ImmutableString.

Naming indeed is partially a taste issue, neverteless an important one - class name should be pronouncable and clearly indicate what the object is (rather than what it does). So, Andrew your idea obviously is a legitimate one, but IMO your choice of name was not the best.

Another aspect to think about (not in this thread, though) is the size of Foundation. It has been noted that Foundation is already quite big and should not significantly grow in future. Some strategy/place for things like ImmutableString may be a valid topic for discussion.

Alex

[marlowa]

> > > > How about ImmutableString?
>
> Java StringBuffer => Poco std::string
> Java String => Poco ImmutableString
>
> I vote for name ImmutableString.

Ok, ImmutableString it is then. I am partway through the coding where I was using the name StringIndex but I will change things around. I am also working on the test harnesses but I am struggling to fit in with the poco way of doing this. I have some code that compiles but the test runner does not seem to pick it up. How about provding some kind of howto document for this? IMO it will make it easier for others to add tested stuff to poco.

-Andrew Marlow

[alex]

> Ok, ImmutableString it is then. I am partway through the coding where I was using the name StringIndex but I will change things around. I am also working on the test harnesses but I am struggling to fit in with the poco way of doing this. I have some code that compiles but the test runner does not seem to pick it up. How about provding some kind of howto document for this? IMO it will make it easier for others to add tested stuff to poco.

Andrew,

Given "Andrew" as your library name and "String" as your package name, you need to have following:

TestDriver => AndrewTestSuite => StringTestSuite => ImmutableStringTest

Obviously you'll have to propose these names as well as the SVN sandbox module where this stuff will reside prior to being accepted in Foundation (or wherever it will end up).

Here are the snippets of code (copy-paste-edited, so excuse any errors):

1) WinDriver.cpp
================
class TestDriver: public CppUnit::WinTestRunnerApp
{
void TestMain()
{
CppUnit::WinTestRunner runner;
runner.addTest(AndrewTestSuite::suite());
runner.run();
}
};

2) AndrewTestSuite.h
====================

#include "CppUnit/TestSuite.h"

class AndrewTestSuite
{
public:
static CppUnit::Test* suite();
};

3) AndrewTestSuite.cpp
======================
#include "StringTestSuite.h"

CppUnit::Test* AndrewTestSuite::suite()
{
CppUnit::TestSuite* pSuite = new CppUnit::TestSuite("AndrewTestSuite");
pSuite->addTest(StringTestSuite::suite());
return pSuite;
}

4) StringTestSuite.h
==================

class StringTestSuite
{
public:
static CppUnit::Test* suite();
};

5) StringTestSuite.cpp
====================

CppUnit::Test* StringTestSuite::suite()
{
CppUnit::TestSuite* pSuite = new CppUnit::TestSuite("StringTestSuite");
pSuite->addTest(ImmutableStringTest::suite());
return pSuite;
}

6) ImmutableStringTest.h
======================

class CoreTest: public CppUnit::TestCase
{
public:
CoreTest(const std::string& name);
~CoreTest();

void testSomething();

void setUp();
void tearDown();
static CppUnit::Test* suite();

private:
};

7) ImmutableStringTest.cpp
=========================

ImmutableStringTest::ImmutableStringTest(const std::string& name): CppUnit::TestCase(name)
{
}


ImmutableStringTest::~ImmutableStringTest()
{
}


void ImmutableStringTest::testSomething()
{
// your actual test here
}

void ImmutableStringTest::setUp()
{
}

void ImmutableStringTest::tearDown()
{
}