By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,920 Members | 1,660 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,920 IT Pros & Developers. It's quick & easy.

The Strinx Library

P: n/a
Hi all!

The Strinx library is an efficient and easy-to-use string library. It
is written in C++, using modern template approach. It uses a class
hierarchy to implement a set of string objects which the user may
easily extend. It also tries to solve few problems which exist in the
standard string and have been discussed during the recent years in the
various newsgroups.

The library may be downloaded freely from:
http://sourceforge.net/projects/strinx/

The library is platform-independent. However, due to its use of modern
template techniques, it requires a compiler that fully supports
standard C++. It is currently in its early stages but most of the code
is well tested and in stable state. Future versions of the library will
include pattern-matching engine as well as more comprehensive
documentations. For now, refer to the README.txt file and source-code
documentations found in the package.

The library is distributed in the hope that it will be useful, under
the terms of the MIT (X11) license, which is an approved open-source
license. However, it is distributed WITHOUT ANY WARRANTY; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If anyone finds this library suitable for his needs he is encouraged to
use it.

Thank you all,
SS.

Jul 22 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
shablool wrote:
Hi all!

The Strinx library is an efficient and easy-to-use string library. It
is written in C++, using modern template approach. It uses a class
hierarchy to implement a set of string objects which the user may
easily extend. It also tries to solve few problems which exist in the
standard string and have been discussed during the recent years in the
various newsgroups.
Can you give us a summary of the differences?
The library may be downloaded freely from:
http://sourceforge.net/projects/strinx/

--
Ron House ho***@usq.edu.au
http://www.sci.usq.edu.au/staff/house
Jul 22 '05 #2

P: n/a

Ron House wrote:
shablool wrote:
Hi all!

The Strinx library is an efficient and easy-to-use string library. It is written in C++, using modern template approach. It uses a class
hierarchy to implement a set of string objects which the user may
easily extend. It also tries to solve few problems which exist in the standard string and have been discussed during the recent years in the various newsgroups.


Can you give us a summary of the differences?
The library may be downloaded freely from:
http://sourceforge.net/projects/strinx/

--
Ron House ho***@usq.edu.au
http://www.sci.usq.edu.au/staff/house

I will try to discuss some of the problems that exist with the standard
string,
and which the Strinx library tries to solve.

1. The standard string is a monolithic object with a relatively large
number of public member functions, some of which are redundant (see:
http://www.gotw.ca/gotw/084.htm). In Strinx, various string
functionalities are
separated into different objects within a class hierarchy, or into
non-member-functions.

2. The standard string was not designed to be an extended object. The
user cannot implement a derived object that extends or improve
functionality (or at least he is not encouraged to do so). In
particular, he cannot control memory allocations strategy. With Strinx
he may do so (thou there is a penalty for usage of virtual functions).

3. The standard string does not support policy-based techniques for
error handling. The default behavior for fatal errors (such as
out-of-range or bad-alloc) is to throw an exception (in some
implementations, with an enigmatic error-message). In Strinx, string
objects have template parameter that lets the user define the
object's behavior.

4. The standard string uses reference counting in order to enable
different string-objects share the same memory (COW). This technique
can be costly and prone to errors in a multi-threaded environment (see:
http://www.gotw.ca/gotw/043.htm). Strinx does not use such technique.

5. The standard string forces usage of dynamic memory allocations, even
for short strings, which may cause memory fragmentation. In Strinx you
can easily parse and manipulate strings "on-the-stack". As a matter of
fact, you can treat every arbitrary sequence of characters as a string.
All of the above and more led to the development of the Strinx library.
Future versions of the library will come with a comprehensive
documentation.

SS.

Jul 22 '05 #3

P: n/a
"shablool" <sh******@users.sf.net> wrote in news:1105554814.264143.57700
@z14g2000cwz.googlegroups.com:
I will try to discuss some of the problems that exist with the standard
string,
and which the Strinx library tries to solve.

1. The standard string is a monolithic object with a relatively large
number of public member functions, some of which are redundant (see:
http://www.gotw.ca/gotw/084.htm). In Strinx, various string
functionalities are
separated into different objects within a class hierarchy, or into
non-member-functions.

2. The standard string was not designed to be an extended object. The
user cannot implement a derived object that extends or improve
functionality (or at least he is not encouraged to do so). In
particular, he cannot control memory allocations strategy. With Strinx
he may do so (thou there is a penalty for usage of virtual functions).
Isn't that what char_traits are for?
3. The standard string does not support policy-based techniques for
error handling. The default behavior for fatal errors (such as
out-of-range or bad-alloc) is to throw an exception (in some
implementations, with an enigmatic error-message). In Strinx, string
objects have template parameter that lets the user define the
object's behavior.
If the error is fatal, what's wrong with an exception?
4. The standard string uses reference counting in order to enable
different string-objects share the same memory (COW). This technique
can be costly and prone to errors in a multi-threaded environment (see:
http://www.gotw.ca/gotw/043.htm). Strinx does not use such technique.
The Standard does not mandate a COW implementation. It merely allows for
one.
5. The standard string forces usage of dynamic memory allocations, even
for short strings, which may cause memory fragmentation. In Strinx you
can easily parse and manipulate strings "on-the-stack". As a matter of
fact, you can treat every arbitrary sequence of characters as a string.
The Standard does not mandate that the memory must be dynamically
allocated for short strings.
All of the above and more led to the development of the Strinx library.
Future versions of the library will come with a comprehensive
documentation.

Jul 22 '05 #4

P: n/a

Andre Kostur wrote:
"shablool" <sh******@users.sf.net> wrote in news:1105554814.264143.57700 @z14g2000cwz.googlegroups.com:
I will try to discuss some of the problems that exist with the standard string,
and which the Strinx library tries to solve.

1. The standard string is a monolithic object with a relatively large number of public member functions, some of which are redundant (see: http://www.gotw.ca/gotw/084.htm). In Strinx, various string
functionalities are
separated into different objects within a class hierarchy, or into
non-member-functions.

2. The standard string was not designed to be an extended object. The user cannot implement a derived object that extends or improve
functionality (or at least he is not encouraged to do so). In
particular, he cannot control memory allocations strategy. With Strinx he may do so (thou there is a penalty for usage of virtual functions).

Isn't that what char_traits are for?
No! char_traits defines a minimal set of attributes associated with a
character. It is state-less, and therefore it can't relate to a
specific string object.
Think of the following example: suppose you want to define your own
string object, which prints a warning message whenever it's size
excides a certain length. It would be very difficult to do it with
standard string.

3. The standard string does not support policy-based techniques for
error handling. The default behavior for fatal errors (such as
out-of-range or bad-alloc) is to throw an exception (in some
implementations, with an enigmatic error-message). In Strinx,
string objects have template parameter that lets the user define the
object's behavior.


If the error is fatal, what's wrong with an exception?


Nothing is wrong, but this is not necessarily the behavior you want. If
you are running in debug more, you may want to stop the thread of
execution, and attach with a debugger. You may want to print error
message to log file, flush it and exit. If your compiler supports it,
you may choose not to use exceptions at all (e.g. -fno-exceptions in
GCC). The Strinx philosophy is that a library should not enforce a
specific behavior, unless it has to. It should define a default
behavior, but also leave the user an option to custom its own.
4. The standard string uses reference counting in order to enable
different string-objects share the same memory (COW). This technique can be costly and prone to errors in a multi-threaded environment (see: http://www.gotw.ca/gotw/043.htm). Strinx does not use such technique.

The Standard does not mandate a COW implementation. It merely allows for one.
Many major distributions I know use this technique, but not all. The
fact that some use it and some don't can be very problematic if you
try to write OS-independent multithreaded code. This can even be tricky
if you change compiler version. I think MS abandoned this technique
when they switched from VC6 to VC7, but how many programmers are aware
of it? How many changed their code?
5. The standard string forces usage of dynamic memory allocations, even for short strings, which may cause memory fragmentation. In Strinx you can easily parse and manipulate strings "on-the-stack". As a matter of fact, you can treat every arbitrary sequence of characters as a string.
The Standard does not mandate that the memory must be dynamically
allocated for short strings.


There are cases where you want to manipulate a string (as an object)
on-the-stack (C's char array). There are other cases where you want
to parse or analyze a characters sequence (const char*) without doing
an extra memory allocation and copy. If you are using standard string,
you are likely to end up with dynamic-allocation somewhere (and
C-string functions are annoying and prone to errors).
The point is that a lot of memory allocation is done "behind the
scenes", and eventually causes fragmentations. This is not necessarily
the case, but often is.
All of the above and more led to the development of the Strinx library. Future versions of the library will come with a comprehensive
documentation.


Jul 22 '05 #5

P: n/a
"shablool" <sh******@users.sf.net> wrote in news:1105614164.808482.120660
@c13g2000cwb.googlegroups.com:
> 3. The standard string does not support policy-based techniques for
> error handling. The default behavior for fatal errors (such as
> out-of-range or bad-alloc) is to throw an exception (in some
> implementations, with an enigmatic error-message). In Strinx, string > objects have template parameter that lets the user define the
> object's behavior.


If the error is fatal, what's wrong with an exception?


Nothing is wrong, but this is not necessarily the behavior you want. If
you are running in debug more, you may want to stop the thread of
execution, and attach with a debugger. You may want to print error
message to log file, flush it and exit. If your compiler supports it,
you may choose not to use exceptions at all (e.g. -fno-exceptions in
GCC). The Strinx philosophy is that a library should not enforce a
specific behavior, unless it has to. It should define a default
behavior, but also leave the user an option to custom its own.


Which is all completely possible within an exception handler. (And
disabling exceptions is non-standard....)
> 4. The standard string uses reference counting in order to enable
> different string-objects share the same memory (COW). This technique > can be costly and prone to errors in a multi-threaded environment (see: > http://www.gotw.ca/gotw/043.htm). Strinx does not use such technique.

The Standard does not mandate a COW implementation. It merely allows

for
one.

Many major distributions I know use this technique, but not all. The
fact that some use it and some don't can be very problematic if you
try to write OS-independent multithreaded code. This can even be tricky
if you change compiler version. I think MS abandoned this technique
when they switched from VC6 to VC7, but how many programmers are aware
of it? How many changed their code?


Multithreading is beyond the scope of this newsgroup. And if you are in
a single-threaded environment, COW could result in quite a bit of
improvement. And unless the programmer was doing platform/implementation
specific coding, then they shouldn't have had to change any code to swich
from one implementation of std::string to another. We didn't.
> 5. The standard string forces usage of dynamic memory allocations, even > for short strings, which may cause memory fragmentation. In Strinx you > can easily parse and manipulate strings "on-the-stack". As a matter of > fact, you can treat every arbitrary sequence of characters as a string.

The Standard does not mandate that the memory must be dynamically
allocated for short strings.


There are cases where you want to manipulate a string (as an object)
on-the-stack (C's char array). There are other cases where you want
to parse or analyze a characters sequence (const char*) without doing
an extra memory allocation and copy. If you are using standard string,
you are likely to end up with dynamic-allocation somewhere (and
C-string functions are annoying and prone to errors).
The point is that a lot of memory allocation is done "behind the
scenes", and eventually causes fragmentations. This is not necessarily
the case, but often is.


That's a QoI issue, not a failing of std::string.
> All of the above and more led to the development of the Strinx library. > Future versions of the library will come with a comprehensive
> documentation.


Note that I'm not saying that Strinx is an inherently bad idea or
implementation (I haven't looked). However, I'm just pointing out that
many of your justifications (hmm.. not quite the right word, may imply
that you're making "excuses"... lets use "encouragements" instead) aren't
failings of std::string itself, only particular implementation of it, and
possibly only in particular environments.
Jul 22 '05 #6

P: n/a
Andre Kostur wrote:
"shablool" <sh******@users.sf.net> wrote in news:1105614164.808482.120660 @c13g2000cwb.googlegroups.com:
> 3. The standard string does not support policy-based techniques for > error handling. The default behavior for fatal errors (such as
> out-of-range or bad-alloc) is to throw an exception (in some
> implementations, with an enigmatic error-message). In Strinx, string
> objects have template parameter that lets the user define the
> object's behavior.

If the error is fatal, what's wrong with an exception?


Nothing is wrong, but this is not necessarily the behavior you want. If
you are running in debug more, you may want to stop the thread of
execution, and attach with a debugger. You may want to print error
message to log file, flush it and exit. If your compiler supports it, you may choose not to use exceptions at all (e.g. -fno-exceptions in GCC). The Strinx philosophy is that a library should not enforce a
specific behavior, unless it has to. It should define a default
behavior, but also leave the user an option to custom its own.


Which is all completely possible within an exception handler. (And
disabling exceptions is non-standard....)
4. The standard string uses reference counting in order to enable > different string-objects share the same memory (COW). This

technique
> can be costly and prone to errors in a multi-threaded
environment
(see:
> http://www.gotw.ca/gotw/043.htm). Strinx does not use such

technique.

The Standard does not mandate a COW implementation. It merely
allows for
one.

Many major distributions I know use this technique, but not all. The fact that some use it and some don't can be very problematic if you
try to write OS-independent multithreaded code. This can even be tricky if you change compiler version. I think MS abandoned this technique
when they switched from VC6 to VC7, but how many programmers are aware of it? How many changed their code?


Multithreading is beyond the scope of this newsgroup. And if you are

in a single-threaded environment, COW could result in quite a bit of
improvement. And unless the programmer was doing platform/implementation specific coding, then they shouldn't have had to change any code to swich from one implementation of std::string to another. We didn't.
5. The standard string forces usage of dynamic memory
allocations,
even
> for short strings, which may cause memory fragmentation. In
Strinx you
> can easily parse and manipulate strings "on-the-stack". As a
matter of
> fact, you can treat every arbitrary sequence of characters as a string.

The Standard does not mandate that the memory must be dynamically
allocated for short strings.


There are cases where you want to manipulate a string (as an object) on-the-stack (C's char array). There are other cases where you want
to parse or analyze a characters sequence (const char*) without doing an extra memory allocation and copy. If you are using standard string, you are likely to end up with dynamic-allocation somewhere (and
C-string functions are annoying and prone to errors).
The point is that a lot of memory allocation is done "behind the
scenes", and eventually causes fragmentations. This is not necessarily the case, but often is.


That's a QoI issue, not a failing of std::string.
All of the above and more led to the development of the Strinx

library.
> Future versions of the library will come with a comprehensive
> documentation.


Note that I'm not saying that Strinx is an inherently bad idea or
implementation (I haven't looked). However, I'm just pointing out

that many of your justifications (hmm.. not quite the right word, may imply that you're making "excuses"... lets use "encouragements" instead) aren't failings of std::string itself, only particular implementation of it, and possibly only in particular environments.

Here is a small program that uses Strinx for token parsing. It does not
use memory allocations what so ever:

#include <iostream>
#include <strinx.h>

int main(void)
{
// Parse line into tokens, delimeted by ':',';' or '/'.
const char line[] = "/Ant:::Bee;:Cat:Dog;Eel/Frog:/Giraffe///";
const char seps[] = ":;/";

using namespace strinx;
SubString ss = line;
SubString tok = find_token(ss, seps);
while (!tok.is_empty())
{
std::cout << tok << std::endl;
tok = find_token(ss.next_substr(tok), seps);
}

return 0;
}

Now, try to rewrite this code without Strinx (remember: no memory
allocations, no assumptions about the parsed line or separators). It is
obviously you can, but would it be so simple and elegant? Would it be
easy to maintain?

Personally, I think that one of the most beautiful things about
Open-Source Software is its freedom. You like it? Use it. You don't
like it? Don't use it. Eventually, in the evolution process the good
pieces of code will survive, the bad one will disappear... :-)

Jul 22 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.