• Pablo Aguilar (7/7) Apr 26 2004 Couldn't find this in the docs... or the header files...
• Matthew (31/38) Apr 26 2004 There are four main reasons:
• Pablo Aguilar (32/72) Apr 26 2004 Thanks!
• Matthew (12/29) Apr 26 2004 yes, I have such a thing, in Synesis code. It's just never been STLSoft-...
• Pablo Aguilar (22/45) Apr 26 2004 current
• Adi Shavit (11/11) Apr 28 2004 Hi Pablo,
• Pablo Aguilar (15/26) Apr 28 2004 Well, my complaint about Loki is that you have to write the WHOLE storag...
• Adi Shavit (13/41) Apr 28 2004 Yes, that's what I understood too.

"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...

"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...

"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

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...

"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.

"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


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...

"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

"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

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

"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

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