Change default allocation of std::string

[Patrick Kowalzick]

Dear NG,

I would like to change the allocator of e.g. all std::strings, without
changing my code. Is there a portable solution to achieve this?

The only nice solution I can think of, would be a namespace and another
typedef to basic_string:

namespace my_string
{
typedef std::basic_str<...> string;
....
}

but in this case I'd have to replace all std::string's with
my_string::string what is not possible right now.

Any ideas?

Thanks, regards,
Patrick

[Jonathan Mcdougall]

> I would like to change the allocator of e.g. all std::strings, without

changing my code. Is there a portable solution to achieve this?
Depends on how you wrote your program. If you used fully qualified
names (std::string) everywhere, no, except by changing the header
files, which is illegal, non portable and bad for your health.
The only nice solution I can think of, would be a namespace and another
typedef to basic_string:

namespace my_string
{
typedef std::basic_str<...> string;
....

}

but in this case I'd have to replace all std::string's with
my_string::string what is not possible right now.

I'm afraid you're caught here. If your code is in a namespace and you
dumped the namespace std's content:

# include <string>

using namespace std;

namespace N
{
string s;
}

you may do

# include <string>

using namespace std;

namespace N
{
typedef std::basic_string<char, my_allocator> string;
string s;
}

which will solve your problem. Apart from this and a global
find/replace, I cannot find any more solutions.
Jonathan

[Patrick Kowalzick]

Hi Jonathan,

I'm afraid you're caught here. If your code is in a namespace and you
dumped the namespace std's content:
I thought so :(.
# include <string>

using namespace std;

namespace N
{
typedef std::basic_string<char, my_allocator> string;
string s;
}

which will solve your problem. Apart from this and a global
find/replace, I cannot find any more solutions.

Same for me. But this leads me to the following conclusion:

Using the abbreviations "string" or "wstring" for basic_string<...> is
somewhat "evil" (and then not good for my health, too), because it restricts
the functionality and features of basic_string to a smaller subset. Same for
all other default-templated fixed abbreviations inside the std namespace :(.

Using own typedef's (e.g. in another namespace) guard this flexibility,
whilst I am allowed to change the typedef's. But this is only valid for my
source and I have no possibilty to affect 3rd-party-code behaviour with
simple change (like overwriting new/delete).

This is somewhat unflexible, isn't it? How do you solve this?

Regards,
Patrick

[Jonathan Mcdougall]

>Using the abbreviations "string" or "wstring" for basic_string<...> is

somewhat "evil" (and then not good for my health, too), because it restricts
the functionality and features of basic_string to a smaller subset. Same for
all other default-templated fixed abbreviations inside the std namespace :(. Using own typedef's (e.g. in another namespace) guard this flexibility,
whilst I am allowed to change the typedef's. But this is only valid for my
source and I have no possibilty to affect 3rd-party-code behaviour with
simple change (like overwriting new/delete). This is somewhat unflexible, isn't it? How do you solve this?

Concerning your own code, you solve this by designing it first. What
may change you factor in a single place, such as a global string
typedef. Now I understand not everything may be designed beforehand,
but that's a programmer's life, unfortunately.

Concerning 3rd party libraries, well there's nothing you can do. If
they expect plain std::string's and you cannot use the standard
allocator, you're toasted. They obviously shouldn't be used on that
project.

If the project you are working on is using plain std::strings and it
was decided in the middle of production to change the strings allocator
and they are using libraries which expect plain std::strings, that
means there was a big fuckup during design time. I hope you're not in
charge of anything. If you are, I hear they are employing in your
nearest grocery store :)

Jonathan

[Shezan Baig]

Patrick Kowalzick wrote:

Using the abbreviations "string" or "wstring" for basic_string<...> is
somewhat "evil" (and then not good for my health, too), because it restricts
the functionality and features of basic_string to a smaller subset. Same for
all other default-templated fixed abbreviations inside the std namespace :(.

Using own typedef's (e.g. in another namespace) guard this flexibility,
whilst I am allowed to change the typedef's. But this is only valid for my
source and I have no possibilty to affect 3rd-party-code behaviour with
simple change (like overwriting new/delete).

This is somewhat unflexible, isn't it? How do you solve this?

Regards,
Patrick

Read Pablo Halpern's allocator proposal. It addresses this very issue.

http://home.earthlink.net/~phalpern/...orProposal.pdf

-shez-

[Patrick Kowalzick]

Hi Jonathan

Using the abbreviations "string" or "wstring" for basic_string<...> is
somewhat "evil" (and then not good for my health, too), because it
restricts
the functionality and features of basic_string to a smaller subset. Same
for
all other default-templated fixed abbreviations inside the std namespace
:(.

Using own typedef's (e.g. in another namespace) guard this flexibility,
whilst I am allowed to change the typedef's. But this is only valid for my
source and I have no possibilty to affect 3rd-party-code behaviour with
simple change (like overwriting new/delete).

This is somewhat unflexible, isn't it? How do you solve this?

Concerning your own code, you solve this by designing it first. What
may change you factor in a single place, such as a global string
typedef. Now I understand not everything may be designed beforehand,
but that's a programmer's life, unfortunately.

I do not agree here. When std::string came up many people were complaining
you it, but IMO there is a silent agreement for quite a long time that
std::string is not perfect but the best we can get for a long time. But now
it hits me quite hard :):

-I can not directly affect the std::string allocation.
-Even worse, if I could, I would not be able to interface 3rd party libs
with std:string. This would lead me back to write interfaces with C-Arrays?
Surely not!
Concerning 3rd party libraries, well there's nothing you can do. If
they expect plain std::string's and you cannot use the standard
allocator, you're toasted. They obviously shouldn't be used on that
project.
Toasting is not good for my health :).
If the project you are working on is using plain std::strings and it
was decided in the middle of production to change the strings allocator
and they are using libraries which expect plain std::strings, that
means there was a big fuckup during design time. I hope you're not in
charge of anything. If you are, I hear they are employing in your
nearest grocery store :)

Am I allowed to overload new/delete only for std::string? AFAIK this is not
possible, but this would work around my problem..... I have to read some
chapters in the standard.

Regards,
Patrick

[Patrick Kowalzick]

Hi Shezan,

thanks for the link. Very helpful to understand allocators.

Regards,
Patrick

[Jonathan Mcdougall]

>> Concerning your own code, you solve this by designing it first. What

may change you factor in a single place, such as a global string
typedef. Now I understand not everything may be designed beforehand,
but that's a programmer's life, unfortunately.

I do not agree here. When std::string came up many people were complaining
you it, but IMO there is a silent agreement for quite a long time that
std::string is not perfect but the best we can get for a long time. But now
That's not what I said. I personally always favor std::string over
anything else when I can. What I said is that elements that may change
during production should have been made easy to change. If it was
determined that the string's allocator may change, the code should have
used my_string everywhere instead of std::string directly. That would
have made the modification easy by changing only the typedef from

typedef std::string my_string;

to

typedef std::basic_string<char, my_allocator> my_string;

though that does not solve the problem of libraries.
it hits me quite hard :):
Sorry to hear that :)
-I can not directly affect the std::string allocation.
-Even worse, if I could, I would not be able to interface 3rd party libs
with std:string. This would lead me back to write interfaces with C-Arrays?
Surely not!
Well that would part of the problem but would create many others, such
as functions which modify their arguments. You're right, not a good
idea.
If the project you are working on is using plain std::strings and it
was decided in the middle of production to change the strings allocator
and they are using libraries which expect plain std::strings, that
means there was a big fuckup during design time. I hope you're not in
charge of anything. If you are, I hear they are employing in your
nearest grocery store :)

Am I allowed to overload new/delete only for std::string? AFAIK this is not
possible, but this would work around my problem..... I have to read some
chapters in the standard.

No you cannot. It would require to change std::basic_string's class'
definition (illegal), which would modify all types based on that
template. Remember that std::string is a typedef for std::basic_string.
What's more, you shouldn't normally use std::strings on the heap: it's
a value type with no virtual functions.

Here's what I recommend.

If you have access to the whole code, replace all std::string by
my_string, which is a typedef for whatever you want. Unfortunately, you
cannot copy a string with a different allocator, so if your libraries
are using std::string, you'll have to interface them and that means
more modifications to your code, but you may have no choice. If you
must not use the standard allocator, you must change the libraries.

If you don't have access to the whole code, forget it.

You may receive other advices on this thread, so do not despair.

Jonathan

[shablool]

There is a trick that may help in some (desperate) cases. Some
compilers (e.g. GCC) give you the option to force include of
header-file at the beginning of every source-file (in GCC, with the
-include [filename]).

Now, try to do this. Create a header file like this:

/* header file which will be the first included header of every source
file */
#include <string>
#include <memory>

namespace std {
typedef char_traits<char> __my_straits;

/* Replace with your allocator: */
typedef allocator<char> __my_salloc;
typedef basic_string<char, __my_straits, __my_salloc> __my_string;
}

#define string __my_string
/* end of header */
This hack can do the work for you, but you must rebuild *all* source
files in your project with this header included. However, I would not
recommend such usage except for debug mode. Note also that if you need
to link your application against external libraries which uses
std::string, this will not work and you will get linkage errors.

I hope it helps.

shablool.