Couldn't find this in the docs... or the header files...
What's the advantage of using stlsoft's simple_string as opposed to
std::string?

I've got to store a list (map, whatever) of names, where I know all names
are very short (3 or 4 characters each) and using an std::string is overkill
(I mean, sizeof(std::string) already outsizes the strings I'm handling), so
I was wondering if using simple_string would be better...

There are four main reasons:

1. It is entirely independent of the iostreams, which means one can use it in contexts where the C++ runtime library are excluded, e.g. small dynamic libraries (http://shellext.com) and utilities (http://www.synesis.com.au/r_systools.html).

2. It does not use copy-on-write, which some implementations of the standard library do. This means there is a consistent performance characteristic irrespective of the compiler you're using. Please note that basic_simple_string performs less well than basic_string for some standard libraries and some applications. (Please further note, however, that it consequently experiences dramatic speed-up when used with the fast string concatenation technique discussed in the June 2004 CUJ.)

3. It's memory footprint is sizeof(void*), which means it's very lightweight when a significant proportion of the strings may be empty. e.g. when processing source files

4. It accepts null-pointers (NULL), as well as empty strings (""), which the
standard does not require. I personally find this advantageous, although I have
to be careful not to do such non-standard coding in libraries. ;)


Note that it is designed to be _simple_, so it does not contain all those everything-but-the-kitchen sink methods that basic_string does. If you want to search it, for example, you use the standard algorithms, rather than methods. Many would argue that that's the correct way to do it anyway. <G>

Note also that I'm thinking of working on a way of having the internal implementation strategy - ptr to buffer; length + capacity + ptr to char*; small-string optimisation; etc. - parameterisable via a policy type, but that's going to be awhile, as I'm a little busy at the moment. ;)

Hope that answers the question.

[Greg: you might add this to the FAQ...]

Cheers

Matthew

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:c6jn01$136g$1@digitaldaemon.com...
> Couldn't find this in the docs... or the header files...
> What's the advantage of using stlsoft's simple_string as opposed to
> std::string?
>
> I've got to store a list (map, whatever) of names, where I know all names
> are very short (3 or 4 characters each) and using an std::string is overkill
> (I mean, sizeof(std::string) already outsizes the strings I'm handling), so
> I was wondering if using simple_string would be better...
>
>

Thanks!

By the way, here's something else I've been looking for and can't find... (Of course I did this myself, but, like someone else said here a few weeks back, I'd rather use something better tested and possibly better written than what I could come up with...)

There's the typical auto release pointer... however, when specializing the
destruction of the pointer type, there's always scalar delete and vector
delete... hardcoded...
Now, there's many different things I'd like to auto-get rid off (my current
situation: p->close, p->dispose, DeleteDC, DeleteObject(HGDIOBJ), etc) and
like I said, no ready made smartptr let's me customize the deletion
strategy, and the one that does (Loki) requires writing a relatively large
class (just to change 'delete'!)

Anyway, I'd continue, but I think my point is clear...

Actually, I just now came up with a way to do it comfortably with Loki... but still, thought it might be a good thing to have...

> 1. It is entirely independent of the iostreams, which means one can use it
in
> contexts where the C++ runtime library are excluded, e.g. small dynamic
libraries
> (http://shellext.com) and utilities
(http://www.synesis.com.au/r_systools.html).
>
> 2. It does not use copy-on-write, which some implementations of the
standard
> library do. This means there is a consistent performance characteristic irrespective of the compiler you're using. Please note that
basic_simple_string
> performs less well than basic_string for some standard libraries and some applications. (Please further note, however, that it consequently
experiences
> dramatic speed-up when used with the fast string concatenation technique discussed in the June 2004 CUJ.)
>
> 3. It's memory footprint is sizeof(void*), which means it's very
lightweight when
> a significant proportion of the strings may be empty. e.g. when processing
source
> files
>
> 4. It accepts null-pointers (NULL), as well as empty strings (""), which
the
> standard does not require. I personally find this advantageous, although I
have
> to be careful not to do such non-standard coding in libraries. ;)
>
>
> Note that it is designed to be _simple_, so it does not contain all those everything-but-the-kitchen sink methods that basic_string does. If you
want to
> search it, for example, you use the standard algorithms, rather than
methods.
> Many would argue that that's the correct way to do it anyway. <G>
>
> Note also that I'm thinking of working on a way of having the internal implementation strategy - ptr to buffer; length + capacity + ptr to char*; small-string optimisation; etc. - parameterisable via a policy type, but
that's
> going to be awhile, as I'm a little busy at the moment. ;)
>
> Hope that answers the question.
>
> [Greg: you might add this to the FAQ...]
>
> Cheers
>
> Matthew
>
> "Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:c6jn01$136g$1@digitaldaemon.com...
> > Couldn't find this in the docs... or the header files...
> > What's the advantage of using stlsoft's simple_string as opposed to
> > std::string?
> >
> > I've got to store a list (map, whatever) of names, where I know all
names
> > are very short (3 or 4 characters each) and using an std::string is
overkill
> > (I mean, sizeof(std::string) already outsizes the strings I'm handling),
so
> > I was wondering if using simple_string would be better...
> >
> >
>
>

> Thanks!

Glad to be of help.

> By the way, here's something else I've been looking for and can't find... (Of course I did this myself, but, like someone else said here a few weeks back, I'd rather use something better tested and possibly better written than what I could come up with...)

He he.

> There's the typical auto release pointer... however, when specializing the
> destruction of the pointer type, there's always scalar delete and vector
> delete... hardcoded...
> Now, there's many different things I'd like to auto-get rid off (my current
> situation: p->close, p->dispose, DeleteDC, DeleteObject(HGDIOBJ), etc) and
> like I said, no ready made smartptr let's me customize the deletion
> strategy,

yes, I have such a thing, in Synesis code. It's just never been STLSoft-ified.

I can't do anything for a few days, as I've finally got the final review/update cycle of "Imperfect C++" to do this week - and I'm only rearranging the first 18 chapters! - and I *really* must work on some other stuff next week, and I *REALLY* must get 1.7.1 out soon.

Maybe it can be included in a later release.

> and the one that does (Loki) requires writing a relatively large
> class (just to change 'delete'!)

And yes, you can be sure mine will be lightweight and will work with most compilers. ;)

> Anyway, I'd continue, but I think my point is clear...
>
> Actually, I just now came up with a way to do it comfortably with Loki... but still, thought it might be a good thing to have...

It would, it is, it will.

Just remind me in a few weeks' time.

I promise, this is my last post for today!

> > There's the typical auto release pointer... however, when specializing
the
> > destruction of the pointer type, there's always scalar delete and vector
> > delete... hardcoded...
> > Now, there's many different things I'd like to auto-get rid off (my
current
> > situation: p->close, p->dispose, DeleteDC, DeleteObject(HGDIOBJ), etc)
and
> > like I said, no ready made smartptr let's me customize the deletion strategy,
>
> yes, I have such a thing, in Synesis code. It's just never been
STLSoft-ified.
>
> I can't do anything for a few days, as I've finally got the final
review/update
> cycle of "Imperfect C++" to do this week - and I'm only rearranging the
first 18
> chapters! - and I *really* must work on some other stuff next week, and I *REALLY* must get 1.7.1 out soon.
>
> Maybe it can be included in a later release.

No rush, it'd be good to have, but, like I said, I've got my 'home-grown'
version of it... and it's fine for now...
Good luck with your work; I promise I won't take up any more of your time...

> > and the one that does (Loki) requires writing a relatively large
> > class (just to change 'delete'!)
>
> And yes, you can be sure mine will be lightweight and will work with most compilers. ;)

Glad to hear that...

> > Anyway, I'd continue, but I think my point is clear...
> >
> > Actually, I just now came up with a way to do it comfortably with
Loki...
> > but still, thought it might be a good thing to have...
>
> It would, it is, it will.
>
> Just remind me in a few weeks' time.

Sure... each time a write a piece of code I'd like to enhance with that I'm reminded of... so, don't worry, I won't forget...

Oh, one last thing... you wanted ideas on how to enhace the docs, here's a specific (though not quick) thing... it'd be really good to have some sort of rationale on some (or most?) of the items in the library... more specifically, for items which duplicate existing functionality (like simple_string, pair, for_all and others of it's kin)... this so one can better choose amongst existing options... right now, the docs say things that are just one step above from obvious, so they don't help much in that sense...

Hi Pablo,

  Maybe slightly off topic, but I just asked the same question on the Loki
discussion group and on comp.lang.c++.moderated (got ignored there :-( )
about custom de-allocators or there-lack-of.
  Actually, I just now came up with a way to do it comfortably with Loki...
  but still, thought it might be a good thing to have...
The answer I got on the Loki list was, indeed, to write my own storage
class.
I'd be interested to know what your solution is.

Thanks,
Adi

Well, my complaint about Loki is that you have to write the WHOLE storage class (with typedefs and other methods etc... when the only thing I really want is to change the de-allocator!).

So what I thought was, why not just override the methods (Destroy I think it is) of one of the pre-built storage classes... However, the pre-built storage don't have 'virtual' methods to override... so, basically what I thought of (didn't actually do it, sorrry if that dissapoints you) is to define a base storage class but with virtual methods, and then just override from there...

Otherwise, if you don't like the idea of using a virtual call, you could replace the above 'base class' with a couple of macros (BEGIN/END_STORAGE_POL) and then just add the custom Destroy method in between...

Hope it helps

> Hi Pablo,
>
>   Maybe slightly off topic, but I just asked the same question on the Loki
> discussion group and on comp.lang.c++.moderated (got ignored there :-( )
> about custom de-allocators or there-lack-of.
>   Actually, I just now came up with a way to do it comfortably with
Loki...
>   but still, thought it might be a good thing to have...
> The answer I got on the Loki list was, indeed, to write my own storage
> class.
> I'd be interested to know what your solution is.
>
> Thanks,
> Adi

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:c6p9dd$1hpv$1@digitaldaemon.com...
> Well, my complaint about Loki is that you have to write the WHOLE storage class (with typedefs and other methods etc... when the only thing I really want is to change the de-allocator!).

Yes, that's what I understood too.

>
> So what I thought was, why not just override the methods (Destroy I think
it
> is) of one of the pre-built storage classes... However, the pre-built storage don't have 'virtual' methods to override... so, basically what I thought of (didn't actually do it, sorrry if that dissapoints you) is to define a base storage class but with virtual methods, and then just
override
> from there...
>
> Otherwise, if you don't like the idea of using a virtual call, you could replace the above 'base class' with a couple of macros (BEGIN/END_STORAGE_POL) and then just add the custom Destroy method in between...

Thanks, actually, I just copied one of the storage classes and added another template parameter to it, which had a delete method (or was is a function ptr/functor). This way I could pass my deallocation routine in place ar construction time.

I was hoping you found a similar thing.
Thanks, anyway, at least I know I'm not the only one needing this.

Adi


>
> Hope it helps
>
> > Hi Pablo,
> >
> >   Maybe slightly off topic, but I just asked the same question on the
Loki
> > discussion group and on comp.lang.c++.moderated (got ignored there :-( )
> > about custom de-allocators or there-lack-of.
> >   Actually, I just now came up with a way to do it comfortably with
> Loki...
> >   but still, thought it might be a good thing to have...
> > The answer I got on the Loki list was, indeed, to write my own storage
> > class.
> > I'd be interested to know what your solution is.
> >
> > Thanks,
> > Adi
>
>