const strings are still expected to free memory on destruction, so it would be tricky to have them point to const memory. Unless they could somehow piggyback on the SSO flag maybe.
But I don't think most implementations have a separate flag, they just check if the pointer is pointing inside the string?

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Matthew Woehlke via Std-Discussion
Sent: Monday, July 13, 2020 4:15 PM
To: Mandeep Sandhu
Reply To: std-discussion_at_[hidden]
Cc: Matthew Woehlke; std-discussion_at_[hidden]
Subject: Re: [std-discussion] extremely long compile time with large number of string literals

On 13/07/2020 12.52, Mandeep Sandhu wrote:
>> ...you *might* get similar benefits from a collection of `const string`
>> instead of `string`, but I'm not sure to what extent `string` can be
>> constexpr, especially if you're stuck on C++11.
>
> I don't know. I guess its best to benchmark and see how much
> performance difference I'd get.
>
>> In either case, I wonder if we'll get to (or are already at?) the point
>> that the compiler can more-or-less build the set at compile time such
>> that the run-time construction cost is near-zero...
>
> I wonder if const string objects can point to string literals kept in
> the .rodata section without having the need to allocate for it at
> runtime (or do they already do something similar currently?).

Possibly (but see Thiago's reply). I was thinking about that, but what I
really meant with the previous statement was that the *set*, not just
its values, would be constructed at compile time. IOW, the ctor for the
set is just 'hey, I have size X and my nodes are over there → RODATA'.
(Uh... this probably still needs pointer fix-ups, though, so I guess it
can't actually be in RODATA, but maybe in DATA. And you'd probably need
the elsewhere-mentioned constexpr allocator.)

-- 
Matthew
-- 
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion