www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - basic_simple_string

reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
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...
Apr 26 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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...

Apr 26 2004
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
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

 contexts where the C++ runtime library are excluded, e.g. small dynamic

 (http://shellext.com) and utilities

 2. It does not use copy-on-write, which some implementations of the

 library do. This means there is a consistent performance characteristic
 irrespective of the compiler you're using. Please note that

 performs less well than basic_string for some standard libraries and some
 applications. (Please further note, however, that it consequently

 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

 a significant proportion of the strings may be empty. e.g. when processing

 files

 4. It accepts null-pointers (NULL), as well as empty strings (""), which

 standard does not require. I personally find this advantageous, although I

 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

 search it, for example, you use the standard algorithms, rather than

 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

 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


 are very short (3 or 4 characters each) and using an std::string is


 (I mean, sizeof(std::string) already outsizes the strings I'm handling),


 I was wondering if using simple_string would be better...


Apr 26 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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.
Apr 26 2004
parent "Pablo Aguilar" <paguilarg hotmail.com> writes:
I promise, this is my last post for today!

 There's the typical auto release pointer... however, when specializing


 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


 situation: p->close, p->dispose, DeleteDC, DeleteObject(HGDIOBJ), etc)


 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

 I can't do anything for a few days, as I've finally got the final

 cycle of "Imperfect C++" to do this week - and I'm only rearranging the

 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


 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...
Apr 26 2004
prev sibling parent reply "Adi Shavit" <adish gentech.co.il> writes:
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
Apr 28 2004
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
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

   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

Apr 28 2004
parent "Adi Shavit" <adish gentech.co.il> writes:
"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

 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

 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


 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

   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


Apr 28 2004