Mixing
Is storage for the same content string literals guaranteed to be the same?
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
Is the code below safe? It might be tempting to write code akin to this:
#include <map>
const std::map<const char*, int> m =
"text1", 1,
"text2", 2
;
int main ()
volatile const auto a = m.at("text1");
return 0;
The map is intended to be used with string literals only.
I think it's perfectly legal and seems to be working, however I never saw a guarantee that the pointer for the literal used in two different places to be the same. I couldn't manage to make compiler generate two separate pointers for literals with the same content, so I started to wonder how firm the assumption is.
I am only interested whether the literals with same content can have different pointers. Or more formally, can the code above except?
I know that there's a way to write code to be sure it works, and I think above approach is dangerous because compiler could decide to assign two different storages for the literal, especially if they are placed in different translation units. Am I right?
c++ storage language-lawyer string-literals
asked 1 hour ago
luk32
11.8k2241
add a comment |Â
up vote
6
down vote
favorite
Is the code below safe? It might be tempting to write code akin to this:
#include <map>
const std::map<const char*, int> m =
"text1", 1,
"text2", 2
;
int main ()
volatile const auto a = m.at("text1");
return 0;
The map is intended to be used with string literals only.
I think it's perfectly legal and seems to be working, however I never saw a guarantee that the pointer for the literal used in two different places to be the same. I couldn't manage to make compiler generate two separate pointers for literals with the same content, so I started to wonder how firm the assumption is.
I am only interested whether the literals with same content can have different pointers. Or more formally, can the code above except?
I know that there's a way to write code to be sure it works, and I think above approach is dangerous because compiler could decide to assign two different storages for the literal, especially if they are placed in different translation units. Am I right?
c++ storage language-lawyer string-literals
asked 1 hour ago
luk32
11.8k2241
1
"however I never saw a guarantee that the pointer for the literal used in two different places to be the same" - There's a very good reason for that
– StoryTeller
1 hour ago
1
Why not usestd::string?
– tkausl
1 hour ago
@tkausl Because that's beyond the scope of question as explicitly mentioned. I know how to write it properly. Also, becausestd::stringctor is notconstexpr.
– luk32
1 hour ago
@StoryTeller That is teasing. Please share!
– luk32
1 hour ago
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ for the ingenious way of posing the question.
– Bathsheba
1 hour ago
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
Is the code below safe? It might be tempting to write code akin to this:
#include <map>
const std::map<const char*, int> m =
"text1", 1,
"text2", 2
;
int main ()
volatile const auto a = m.at("text1");
return 0;
The map is intended to be used with string literals only.
I think it's perfectly legal and seems to be working, however I never saw a guarantee that the pointer for the literal used in two different places to be the same. I couldn't manage to make compiler generate two separate pointers for literals with the same content, so I started to wonder how firm the assumption is.
I am only interested whether the literals with same content can have different pointers. Or more formally, can the code above except?
I know that there's a way to write code to be sure it works, and I think above approach is dangerous because compiler could decide to assign two different storages for the literal, especially if they are placed in different translation units. Am I right?
c++ storage language-lawyer string-literals
asked 1 hour ago
luk32
11.8k2241
Is the code below safe? It might be tempting to write code akin to this:
#include <map>
const std::map<const char*, int> m =
"text1", 1,
"text2", 2
;
int main ()
volatile const auto a = m.at("text1");
return 0;
The map is intended to be used with string literals only.
I think it's perfectly legal and seems to be working, however I never saw a guarantee that the pointer for the literal used in two different places to be the same. I couldn't manage to make compiler generate two separate pointers for literals with the same content, so I started to wonder how firm the assumption is.
I am only interested whether the literals with same content can have different pointers. Or more formally, can the code above except?
I know that there's a way to write code to be sure it works, and I think above approach is dangerous because compiler could decide to assign two different storages for the literal, especially if they are placed in different translation units. Am I right?
c++ storage language-lawyer string-literals
c++ storage language-lawyer string-literals
asked 1 hour ago
luk32
11.8k2241
asked 1 hour ago
luk32
11.8k2241
edited 1 hour ago
asked 1 hour ago
luk32
11.8k2241
asked 1 hour ago
luk32
11.8k2241
asked 1 hour ago
luk32
11.8k2241
11.8k2241
1
"however I never saw a guarantee that the pointer for the literal used in two different places to be the same" - There's a very good reason for that
– StoryTeller
1 hour ago
1
Why not usestd::string?
– tkausl
1 hour ago
@tkausl Because that's beyond the scope of question as explicitly mentioned. I know how to write it properly. Also, becausestd::stringctor is notconstexpr.
– luk32
1 hour ago
@StoryTeller That is teasing. Please share!
– luk32
1 hour ago
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ for the ingenious way of posing the question.
– Bathsheba
1 hour ago
add a comment |Â
1
"however I never saw a guarantee that the pointer for the literal used in two different places to be the same" - There's a very good reason for that
– StoryTeller
1 hour ago
1
Why not usestd::string?
– tkausl
1 hour ago
@tkausl Because that's beyond the scope of question as explicitly mentioned. I know how to write it properly. Also, becausestd::stringctor is notconstexpr.
– luk32
1 hour ago
@StoryTeller That is teasing. Please share!
– luk32
1 hour ago
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ for the ingenious way of posing the question.
– Bathsheba
1 hour ago
1
1
"however I never saw a guarantee that the pointer for the literal used in two different places to be the same" - There's a very good reason for that
– StoryTeller
1 hour ago
"however I never saw a guarantee that the pointer for the literal used in two different places to be the same" - There's a very good reason for that
– StoryTeller
1 hour ago
1
1
Why not use
std::string?– tkausl
1 hour ago
Why not use
std::string?– tkausl
1 hour ago
@tkausl Because that's beyond the scope of question as explicitly mentioned. I know how to write it properly. Also, because
std::string ctor is not constexpr.– luk32
1 hour ago
@tkausl Because that's beyond the scope of question as explicitly mentioned. I know how to write it properly. Also, because
std::string ctor is not constexpr.– luk32
1 hour ago
@StoryTeller That is teasing. Please share!
– luk32
1 hour ago
@StoryTeller That is teasing. Please share!
– luk32
1 hour ago
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ for the ingenious way of posing the question.
– Bathsheba
1 hour ago
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ for the ingenious way of posing the question.
– Bathsheba
1 hour ago
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
7
down vote
Whether or not two string literals with the exact same content are the exact same object, is unspecified, and in my opinion best not relied upon. To quote the standard:
[lex.string]
16 Evaluating a string-literal results in a string literal object
with static storage duration, initialized from the given characters as
specified above. Whether all string literals are distinct (that is,
are stored in nonoverlapping objects) and whether successive
evaluations of a string-literal yield the same or a different object
is unspecified.
If you wish to avoid the overhead of std::string, you can write a simple view type (or use std::string_view in C++17) that is a reference type over a string literal. Use it to do intelligent comparisons instead of relying upon literal identity.
answered 1 hour ago
StoryTeller
83.4k12167232
1
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ
– Bathsheba
1 hour ago
In production I did use a custom wrapper type aroundconst char*and overloaded relevant operators. I wondered if I wrote superfluous code. In my particular case the string overhead is not much of a problem, it's aboutconstexprctor, also I am still restricted to c++14.
– luk32
18 mins ago
@luk32 - You can write a wrapper geared at string literals explicitly (taking achar*necessitates a length check). Consider this for example instead. It essentially gets rid of all the overhead, except for the comparison itself.
– StoryTeller
3 mins ago
add a comment |Â
up vote
3
down vote
The Standard does not guarantee the addresses of string literals with the same content will be the same. In fact, [lex.string]/16 says:
Whether all string literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified.
The second part even says you might not get the same address when a function containing a string literal is called a second time! Though I've never seen a compiler do that.
So using the same character array object when a string literal is repeated is an optional compiler optimization. With my installation of g++ and default compiler flags, I also find I get the same address for two identical string literals in the same translation unit. But as you guessed, I get different ones if the same string literal content appears in different translation units.
(A related interesting point: it's also permitted for different string literals to use overlapping arrays. That is, given
const char abcdef = "abcdef";
const char def = "def";
const char def0gh = "defgh";
it's possible you might find abcdef+3, def+0, and def0gh+0 are all the same pointer.)
answered 1 hour ago
aschepler
49.8k569122
1
I was just thinking how to cook up some pathological literal. A simplewill do, +1.
– StoryTeller
1 hour ago
add a comment |Â
up vote
3
down vote
No, the C++ standard makes no such guarantees.
That said, if the code is in the same translation unit then it would be difficult to find a counter example. If main() is in a different translation then a counter example might be easier to produce.
If the map is in a different dynamic linked library or shared object then it's almost certainly not the case.
The volatile qualifier is a red herring.
answered 1 hour ago
Bathsheba
168k26238353
I usedvolatilefor copy-paste friendliness with online compilers, to prevent complete removal of code. I think it does work this way and doesn't get in the way.
– luk32
22 mins ago
add a comment |Â
up vote
1
down vote
The C++ standard does not require an implementation to de-duplicate string literals.
When a string literal resides in another translation unit or another shared library that would require the linker (ld) or runtime-linker (ld.so) to do the string literal de-duplication. Which they don't.
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
Whether or not two string literals with the exact same content are the exact same object, is unspecified, and in my opinion best not relied upon. To quote the standard:
[lex.string]
16 Evaluating a string-literal results in a string literal object
with static storage duration, initialized from the given characters as
specified above. Whether all string literals are distinct (that is,
are stored in nonoverlapping objects) and whether successive
evaluations of a string-literal yield the same or a different object
is unspecified.
If you wish to avoid the overhead of std::string, you can write a simple view type (or use std::string_view in C++17) that is a reference type over a string literal. Use it to do intelligent comparisons instead of relying upon literal identity.
answered 1 hour ago
StoryTeller
83.4k12167232
1
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ
– Bathsheba
1 hour ago
In production I did use a custom wrapper type aroundconst char*and overloaded relevant operators. I wondered if I wrote superfluous code. In my particular case the string overhead is not much of a problem, it's aboutconstexprctor, also I am still restricted to c++14.
– luk32
18 mins ago
@luk32 - You can write a wrapper geared at string literals explicitly (taking achar*necessitates a length check). Consider this for example instead. It essentially gets rid of all the overhead, except for the comparison itself.
– StoryTeller
3 mins ago
add a comment |Â
up vote
7
down vote
Whether or not two string literals with the exact same content are the exact same object, is unspecified, and in my opinion best not relied upon. To quote the standard:
[lex.string]
16 Evaluating a string-literal results in a string literal object
with static storage duration, initialized from the given characters as
specified above. Whether all string literals are distinct (that is,
are stored in nonoverlapping objects) and whether successive
evaluations of a string-literal yield the same or a different object
is unspecified.
If you wish to avoid the overhead of std::string, you can write a simple view type (or use std::string_view in C++17) that is a reference type over a string literal. Use it to do intelligent comparisons instead of relying upon literal identity.
answered 1 hour ago
StoryTeller
83.4k12167232
1
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ
– Bathsheba
1 hour ago
In production I did use a custom wrapper type aroundconst char*and overloaded relevant operators. I wondered if I wrote superfluous code. In my particular case the string overhead is not much of a problem, it's aboutconstexprctor, also I am still restricted to c++14.
– luk32
18 mins ago
@luk32 - You can write a wrapper geared at string literals explicitly (taking achar*necessitates a length check). Consider this for example instead. It essentially gets rid of all the overhead, except for the comparison itself.
– StoryTeller
3 mins ago
add a comment |Â
up vote
7
down vote
up vote
7
down vote
Whether or not two string literals with the exact same content are the exact same object, is unspecified, and in my opinion best not relied upon. To quote the standard:
[lex.string]
16 Evaluating a string-literal results in a string literal object
with static storage duration, initialized from the given characters as
specified above. Whether all string literals are distinct (that is,
are stored in nonoverlapping objects) and whether successive
evaluations of a string-literal yield the same or a different object
is unspecified.
If you wish to avoid the overhead of std::string, you can write a simple view type (or use std::string_view in C++17) that is a reference type over a string literal. Use it to do intelligent comparisons instead of relying upon literal identity.
answered 1 hour ago
StoryTeller
83.4k12167232
Whether or not two string literals with the exact same content are the exact same object, is unspecified, and in my opinion best not relied upon. To quote the standard:
[lex.string]
16 Evaluating a string-literal results in a string literal object
with static storage duration, initialized from the given characters as
specified above. Whether all string literals are distinct (that is,
are stored in nonoverlapping objects) and whether successive
evaluations of a string-literal yield the same or a different object
is unspecified.
If you wish to avoid the overhead of std::string, you can write a simple view type (or use std::string_view in C++17) that is a reference type over a string literal. Use it to do intelligent comparisons instead of relying upon literal identity.
answered 1 hour ago
StoryTeller
83.4k12167232
edited 1 hour ago
answered 1 hour ago
StoryTeller
83.4k12167232
answered 1 hour ago
StoryTeller
83.4k12167232
answered 1 hour ago
StoryTeller
83.4k12167232
83.4k12167232
1
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ
– Bathsheba
1 hour ago
In production I did use a custom wrapper type aroundconst char*and overloaded relevant operators. I wondered if I wrote superfluous code. In my particular case the string overhead is not much of a problem, it's aboutconstexprctor, also I am still restricted to c++14.
– luk32
18 mins ago
@luk32 - You can write a wrapper geared at string literals explicitly (taking achar*necessitates a length check). Consider this for example instead. It essentially gets rid of all the overhead, except for the comparison itself.
– StoryTeller
3 mins ago
add a comment |Â
1
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ
– Bathsheba
1 hour ago
In production I did use a custom wrapper type aroundconst char*and overloaded relevant operators. I wondered if I wrote superfluous code. In my particular case the string overhead is not much of a problem, it's aboutconstexprctor, also I am still restricted to c++14.
– luk32
18 mins ago
@luk32 - You can write a wrapper geared at string literals explicitly (taking achar*necessitates a length check). Consider this for example instead. It essentially gets rid of all the overhead, except for the comparison itself.
– StoryTeller
3 mins ago
1
1
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ
– Bathsheba
1 hour ago
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ
– Bathsheba
1 hour ago
In production I did use a custom wrapper type around
const char* and overloaded relevant operators. I wondered if I wrote superfluous code. In my particular case the string overhead is not much of a problem, it's about constexpr ctor, also I am still restricted to c++14.– luk32
18 mins ago
In production I did use a custom wrapper type around
const char* and overloaded relevant operators. I wondered if I wrote superfluous code. In my particular case the string overhead is not much of a problem, it's about constexpr ctor, also I am still restricted to c++14.– luk32
18 mins ago
@luk32 - You can write a wrapper geared at string literals explicitly (taking a
char* necessitates a length check). Consider this for example instead. It essentially gets rid of all the overhead, except for the comparison itself.– StoryTeller
3 mins ago
@luk32 - You can write a wrapper geared at string literals explicitly (taking a
char* necessitates a length check). Consider this for example instead. It essentially gets rid of all the overhead, except for the comparison itself.– StoryTeller
3 mins ago
add a comment |Â
up vote
3
down vote
The Standard does not guarantee the addresses of string literals with the same content will be the same. In fact, [lex.string]/16 says:
Whether all string literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified.
The second part even says you might not get the same address when a function containing a string literal is called a second time! Though I've never seen a compiler do that.
So using the same character array object when a string literal is repeated is an optional compiler optimization. With my installation of g++ and default compiler flags, I also find I get the same address for two identical string literals in the same translation unit. But as you guessed, I get different ones if the same string literal content appears in different translation units.
(A related interesting point: it's also permitted for different string literals to use overlapping arrays. That is, given
const char abcdef = "abcdef";
const char def = "def";
const char def0gh = "defgh";
it's possible you might find abcdef+3, def+0, and def0gh+0 are all the same pointer.)
answered 1 hour ago
aschepler
49.8k569122
1
I was just thinking how to cook up some pathological literal. A simplewill do, +1.
– StoryTeller
1 hour ago
add a comment |Â
up vote
3
down vote
The Standard does not guarantee the addresses of string literals with the same content will be the same. In fact, [lex.string]/16 says:
Whether all string literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified.
The second part even says you might not get the same address when a function containing a string literal is called a second time! Though I've never seen a compiler do that.
So using the same character array object when a string literal is repeated is an optional compiler optimization. With my installation of g++ and default compiler flags, I also find I get the same address for two identical string literals in the same translation unit. But as you guessed, I get different ones if the same string literal content appears in different translation units.
(A related interesting point: it's also permitted for different string literals to use overlapping arrays. That is, given
const char abcdef = "abcdef";
const char def = "def";
const char def0gh = "defgh";
it's possible you might find abcdef+3, def+0, and def0gh+0 are all the same pointer.)
answered 1 hour ago
aschepler
49.8k569122
1
I was just thinking how to cook up some pathological literal. A simplewill do, +1.
– StoryTeller
1 hour ago
add a comment |Â
up vote
3
down vote
up vote
3
down vote
The Standard does not guarantee the addresses of string literals with the same content will be the same. In fact, [lex.string]/16 says:
Whether all string literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified.
The second part even says you might not get the same address when a function containing a string literal is called a second time! Though I've never seen a compiler do that.
So using the same character array object when a string literal is repeated is an optional compiler optimization. With my installation of g++ and default compiler flags, I also find I get the same address for two identical string literals in the same translation unit. But as you guessed, I get different ones if the same string literal content appears in different translation units.
(A related interesting point: it's also permitted for different string literals to use overlapping arrays. That is, given
const char abcdef = "abcdef";
const char def = "def";
const char def0gh = "defgh";
it's possible you might find abcdef+3, def+0, and def0gh+0 are all the same pointer.)
answered 1 hour ago
aschepler
49.8k569122
The Standard does not guarantee the addresses of string literals with the same content will be the same. In fact, [lex.string]/16 says:
Whether all string literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified.
The second part even says you might not get the same address when a function containing a string literal is called a second time! Though I've never seen a compiler do that.
So using the same character array object when a string literal is repeated is an optional compiler optimization. With my installation of g++ and default compiler flags, I also find I get the same address for two identical string literals in the same translation unit. But as you guessed, I get different ones if the same string literal content appears in different translation units.
(A related interesting point: it's also permitted for different string literals to use overlapping arrays. That is, given
const char abcdef = "abcdef";
const char def = "def";
const char def0gh = "defgh";
it's possible you might find abcdef+3, def+0, and def0gh+0 are all the same pointer.)
answered 1 hour ago
aschepler
49.8k569122
answered 1 hour ago
aschepler
49.8k569122
answered 1 hour ago
aschepler
49.8k569122
answered 1 hour ago
aschepler
49.8k569122
49.8k569122
1
I was just thinking how to cook up some pathological literal. A simplewill do, +1.
– StoryTeller
1 hour ago
add a comment |Â
1
I was just thinking how to cook up some pathological literal. A simplewill do, +1.
– StoryTeller
1 hour ago
1
1
I was just thinking how to cook up some pathological literal. A simple
– StoryTeller
1 hour ago
I was just thinking how to cook up some pathological literal. A simple
– StoryTeller
1 hour ago
add a comment |Â
up vote
3
down vote
No, the C++ standard makes no such guarantees.
That said, if the code is in the same translation unit then it would be difficult to find a counter example. If main() is in a different translation then a counter example might be easier to produce.
If the map is in a different dynamic linked library or shared object then it's almost certainly not the case.
The volatile qualifier is a red herring.
answered 1 hour ago
Bathsheba
168k26238353
I usedvolatilefor copy-paste friendliness with online compilers, to prevent complete removal of code. I think it does work this way and doesn't get in the way.
– luk32
22 mins ago
add a comment |Â
up vote
3
down vote
No, the C++ standard makes no such guarantees.
That said, if the code is in the same translation unit then it would be difficult to find a counter example. If main() is in a different translation then a counter example might be easier to produce.
If the map is in a different dynamic linked library or shared object then it's almost certainly not the case.
The volatile qualifier is a red herring.
answered 1 hour ago
Bathsheba
168k26238353
I usedvolatilefor copy-paste friendliness with online compilers, to prevent complete removal of code. I think it does work this way and doesn't get in the way.
– luk32
22 mins ago
add a comment |Â
up vote
3
down vote
up vote
3
down vote
No, the C++ standard makes no such guarantees.
That said, if the code is in the same translation unit then it would be difficult to find a counter example. If main() is in a different translation then a counter example might be easier to produce.
If the map is in a different dynamic linked library or shared object then it's almost certainly not the case.
The volatile qualifier is a red herring.
answered 1 hour ago
Bathsheba
168k26238353
No, the C++ standard makes no such guarantees.
That said, if the code is in the same translation unit then it would be difficult to find a counter example. If main() is in a different translation then a counter example might be easier to produce.
If the map is in a different dynamic linked library or shared object then it's almost certainly not the case.
The volatile qualifier is a red herring.
answered 1 hour ago
Bathsheba
168k26238353
edited 1 hour ago
answered 1 hour ago
Bathsheba
168k26238353
answered 1 hour ago
Bathsheba
168k26238353
answered 1 hour ago
Bathsheba
168k26238353
168k26238353
I usedvolatilefor copy-paste friendliness with online compilers, to prevent complete removal of code. I think it does work this way and doesn't get in the way.
– luk32
22 mins ago
add a comment |Â
I usedvolatilefor copy-paste friendliness with online compilers, to prevent complete removal of code. I think it does work this way and doesn't get in the way.
– luk32
22 mins ago
I used
volatile for copy-paste friendliness with online compilers, to prevent complete removal of code. I think it does work this way and doesn't get in the way.– luk32
22 mins ago
I used
volatile for copy-paste friendliness with online compilers, to prevent complete removal of code. I think it does work this way and doesn't get in the way.– luk32
22 mins ago
add a comment |Â
up vote
1
down vote
The C++ standard does not require an implementation to de-duplicate string literals.
When a string literal resides in another translation unit or another shared library that would require the linker (ld) or runtime-linker (ld.so) to do the string literal de-duplication. Which they don't.
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
add a comment |Â
up vote
1
down vote
The C++ standard does not require an implementation to de-duplicate string literals.
When a string literal resides in another translation unit or another shared library that would require the linker (ld) or runtime-linker (ld.so) to do the string literal de-duplication. Which they don't.
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
add a comment |Â
up vote
1
down vote
up vote
1
down vote
The C++ standard does not require an implementation to de-duplicate string literals.
When a string literal resides in another translation unit or another shared library that would require the linker (ld) or runtime-linker (ld.so) to do the string literal de-duplication. Which they don't.
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
The C++ standard does not require an implementation to de-duplicate string literals.
When a string literal resides in another translation unit or another shared library that would require the linker (ld) or runtime-linker (ld.so) to do the string literal de-duplication. Which they don't.
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
answered 1 hour ago
Maxim Egorushkin
80.1k1195174
80.1k1195174
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52423837%2fis-storage-for-the-same-content-string-literals-guaranteed-to-be-the-same%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
"however I never saw a guarantee that the pointer for the literal used in two different places to be the same" - There's a very good reason for that
– StoryTeller
1 hour ago
1
Why not use
std::string?– tkausl
1 hour ago
@tkausl Because that's beyond the scope of question as explicitly mentioned. I know how to write it properly. Also, because
std::stringctor is notconstexpr.– luk32
1 hour ago
@StoryTeller That is teasing. Please share!
– luk32
1 hour ago
ÃÂ+ÃÂ1ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ for the ingenious way of posing the question.
– Bathsheba
1 hour ago