> On Feb 20, 2015, at 4:28 PM, Richard Smith <[email protected]> wrote:
> On 20 February 2015 at 15:51, John McCall <[email protected]
> <mailto:[email protected]>> wrote:
> > On Feb 19, 2015, at 11:44 PM, Dennis Handly <[email protected]
> > <mailto:[email protected]>> wrote:
> >> From: David Majnemer <[email protected]
> >> <mailto:[email protected]>>
> >> It seems that the ABI has no means to mangle the contents of string
> >> constants.
> >
> > Why is that needed?
> > The current scheme is to just number the constants in order.
> > And that handles both strings and wide strings.
> > And by the ODR rule the inlines must be the same.
>
> I think this is what David means by numbering like a reference temporary.
>
> To the extent that this is needed, I agree with you that that’s the right
> solution: string literals should be mangled in the same sequence as reference
> temporaries. (Which already applies to more than just reference temporaries
> anyway, since the same concept of lifetime extension applies to
> std::initializer_list temporaries.)
>
> I have some of the same concerns here as I do with guaranteeing the
> uniqueness of string literals within inline functions: I want to make sure
> the language isn’t accidentally promising something that grotesquely affects
> performance far out of proportion to its utility to the programmer. It would
> be very unfortunate if we, say, introduced thousands of new global weak
> symbols just to unique the strings used by assertions. We can take things
> like this back to the committee if necessary.
>
> But if we can restrict this guarantee to string literals that appear in
> reference-temporary-like positions in constexpr initializers, I think it’s
> reasonable enough.
>
> We can't. Consider:
>
> constexpr const char *f(const char *p) { return p; }
> constexpr const char *g() { return "foo"; }
> struct X {
> constexpr static const char *p = "foo", // ok
> *q = f("foo"), // not in a "reference-temporary-like" position
> *r = g(); // string literal is not even lexically within the initializer
> };
Yeah, I thought about this a bit too late. There are two ways to salvage the
idea: mark string literals by position as they appear in the actual constexpr
result, or just don’t promise anything in this case.
Another concern with widespread string-literal mangling that occurs to me is
whether it will completely defeat ordinary string-literal sharing. To do this
feature optimally, we would need… in ELF terms, what, a COMDAT alias (?) into
the string literal section? This might be pushing the boundaries of supported
linker behavior a lot. If we have to emit separate, unmergeable string literal
objects just because they were used in a constexpr, that would be a disaster.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
