Merry XMas everyone,

Are you try to propose... a flag that show if char array inside string view
is null terminated?

Then suppose one need to get null terminated char array, the flag will show
if he/she need to do a copy - in any prefer way, or use the value directly.

Is that all about?

if so, I like the idea in general.

Please confirm so others get the idea.

On Saturday, December 26, 2020, Tom Mason via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > You can't wallpaper over an ABI break with "well, there's a compiler
> switch, so it's fine to break ABIs." What happens if you want to link
> against a DLL compiled with a different switch?
>
> > you're talking about turning a type that's 16 bytes in size (64-bit
> compilation) into one that must be 24 bytes in size.
>
> I think there's some confusion here, as the various aspects of what I'm
> proposing have gotten split out over several posts now.
>
> The two core things are:
> - The type does not need to increase in size, as the flag is stored in the
> upper unused bit of the length field.
> - It can be implemented without breaking ABI, with a dummy implementation
> that always returns false / always does a copy. In this case there's no
> need to store an extra flag at all so the binary representation stays
> exactly the same.
>
> The dummy implementation means that whenever the library developers decide
> to break ABI, they can replace it with a real one. My reading up on ABI
> changes from the compiler vendors was not intended to dismiss the issue of
> ABI breaks in general, but to get a sense of how often they do them. If
> they break ABI only every 10 years then it would be a long time before this
> became useful. It seems to me that the current policies would allow a lot
> of people to get access to the full implementation quite soon, while not
> forcing an ABI break on anyone who wasn't already accepting one anyway.
>
> The choice of when to switch to the full implementation ultimately rests
> in the hands of the library developers, and nothing is forced on anyone. In
> the meantime, everything is set up so that the api is ready for the future.
>
> 26 Dec 2020 6:38:36 am Tony V E via Std-Proposals <
> std-proposals_at_[hidden]>:
>
> > An implementation can probably hide the ‎bool inside an unused bit of
> the pointer (or length), so it can still be 16 bytes.
> >
> > But you still have ABI problems. You could not pass a new string_view
> with the bit set into old code that was expecting a valid pointer, unless
> the old code was for some strange reason already masking out unused bits.
> Which is highly unlikely, to say the least.
> >
> >
> > Sent from my BlackBerry portable Babbage Device
> > Original Message
> > From: Jason McKesson via Std-Proposals
> > Sent: Friday, December 25, 2020 11:33 PM
> > To: std-proposals_at_[hidden]
> > Reply To: std-proposals_at_[hidden]
> > Cc: Jason McKesson
> > Subject: Re: [std-proposals] Avoid copies when using string_view with
> APIs expecting null terminated strings
> >
> > On Fri, Dec 25, 2020 at 8:26 PM Tom Mason via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >>
> >> On further reading of the GCC docs (yes, on christmas day, but everyone
> else has gone to bed already :p), it seems libstdc++ does have a mechanism
> similar to that of libc++. The -fabi-version flag (docs here
> https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html) can
> be used to specify an abi version, and modern versions of gcc defaults to 0
> (latest). So, the new ABI version could implement the termination flag, and
> the old ones could just default to not terminated. I'm sure there are gcc
> contributers on here, so sorry if this was all obvious, I just thought it
> was worth mentioning for clarity.
> >> I will probably do up a new, more proper writeup and example
> implementation in the next few days. As I'm new here, can anyone with
> experience comment on the likelihood of acceptance of this proposal? From
> my (optimistic) viewpoint, the main blocker would be ABI issues, as opposed
> to objections to the feature itself, and I think the workarounds are
> acceptable.
> >
> > You can't wallpaper over an ABI break with "well, there's a compiler
> > switch, so it's fine to break ABIs." What happens if you want to link
> > against a DLL compiled with a different switch? Do you have to have
> > two separate compilations of *every* library, just in case someone
> > wants to link against the other ABI?
> >
> > It took a long time for libstdc++ to upgrade its `std::string` type to
> > be C++11-compliant (ie: removing all the copy-on-write stuff). And
> > that was a change that likely improved performance across the board
> > for most applications. ABI breaks are not something one should do
> > lightly; they should only be done when the gain is greater than the
> > cost. And I don't feel your proposal is *nearly* good enough to
> > justify that cost compared to any of the non-ABI-breaking
> > alternatives.
> >
> > And you shouldn't ignore issues besides the ABI break. From a purely
> > practical perspective, you're talking about turning a type that's 16
> > bytes in size (64-bit compilation) into one that must be 24 bytes in
> > size. That's a fifty percent increase in the size of the type. That's
> > a cost *everyone* must pay, even those who don't need the feature. You
> > can only justify such a cost increase by having this solve a
> > *pervasive* problem. And I don't think the issues you've cited
> > constitute that.
> >
> > Remember: the use case you're talking about is an API which both
> > internally needs a NUL-terminated string and also does not want to
> > *force* the user to provide a NUL-terminated string view. That is, the
> > API is perfectly happy to do the copy; you'd just prefer not to if
> > that's OK. I don't believe this is particularly common. Certainly not
> > common enough to be worth making every string view 50% bigger.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>