On 11/28/23 2:14 PM, Corentin Jabot wrote:
My understanding is that the motivation for fixed_string is exclusively the need for a structural type (the name is deceptive).
See CTRE https://github.com/hanickadot/compile-time-regular-expressions/blob/029f1f13646cf65ec09780013418cb8f1c5d3a59/include/ctll/fixed_string.hpp#L217

Motivation also exists for scenarios where dynamic memory allocation is not allowed, but that is an orthogonal concern.

Thanks for the CTRE reference; I missed that one.


I'd be rather opposed to having more string types, especially if the goal is to yet again fix language deficiencies.
That was my motivation for trying to see if std::basic_string could be employed in defining such a type. That doesn't really avoid a new type of course; it just introduces it as a new family of class template specializations that don't necessarily interact well with other specializations.
Richard's excellent paper illustrates how we could make std::string structural in the future https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2484r0.html#variable-length-representation - I should hope that this future comes in time for this proposal to use it :)
IE, richard proposal alleviates the need for fixed_string, rather than allowing its implementation (which it would, sure, but it would remove the motivation)

Ohh, thank you for that reference! I wasn't aware of that paper and Richard didn't mention it when I recently asked him if there had ever been a formal proposal for operator template. Richard did note that P2308 (Template parameter initialization) is needed to unblock such a proposal though (P2308 was recently approved by CWG and should be coming soon to a plenary near you).

I agree that the best fixed_string would be std::string if we can get there.

Tom.


On Tue, Nov 28, 2023 at 7:36 PM Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

I spent a little time trying to see how far I could get in implementing a fixed_string type using std::basic_string with a custom fixed capacity allocator that uses a data member for storage. For anyone interested see https://godbolt.org/z/zE37E43fz. There are some non-trivial problems that would have to be addressed to make that work.

I think this exposed a bug in the libc++ implementation of std::basic_string. Its max_size() computation appears to be off and can be exceeded.

Tom.

On 11/28/23 1:29 PM, Tom Honermann via SG16 wrote:

SG16 will hold a telecon on Wednesday, November 29th, at 19:30 UTC (timezone conversion).

Since I am, once again, so late in sending this out, let this notice be your friendly reminder that this meeting is taking place tomorrow (in about 25 hours).

Please note that daylight savings time has ended in both North America and in Europe since we last met, so this meeting will start one hour earlier than the last one. Please check your calendars!

The agenda follows.

The first item we'll discuss is requirements for a fixed_string type; a type that would be suitable for use as a non-type template parameter (NTTP) and that is capable of holding a string (a sequence of code units, presumably with a null terminator) of up to a compile-time fixed length. The paper does not currently discuss its own requirements for such a type, but they appear to be minimal; see the named_unit examples in the "Extensibility" section. The standard currently requires a type to be a structural type ([temp.param]p7) to be used as a NTTP and that imposes imitations on how fancy such a type can be (see the literal type definition in [basic.types.general]p10). The proposal could go forward with a bespoke exposition-only type that satisfies just the needs of that proposal. The questions for SG16 to consider are:

  1. Should the proposal be blocked on the availability of a standard fixed_string type or should the authors feel free to proceed with a less general type (in which case it should not squat on a good name)?
  2. What properties should a general fixed_string type satisfy?
    1. Should it be read-only or read-write?
    2. Should it be resizeable within the limits of the fixed capacity?
    3. Should it provide all the relevant member functions from std::string and std::string_view?
    4. Should it support all of wchar_t, char8_t, char16_t, and char32_t?

The reference implementation currently uses a read-only implementation; see the first link in the list below. Examples uses can be seen in https://github.com/mpusz/mp-units/blob/master/src/systems/si/include/mp-units/systems/si/units.h. The reference implementation is available on godbolt.org as well.

The idea of a fixed_string type has been around for quite some time. P0259 (fixed_string: a compile time string) proposed a basic_fixed_string class template, but it was proposed as a constexpr version of std::string and not for use as a NTTP. That proposal has been made mostly obsolete by constexpr support for std::string. P0732 (Class Types in Non-Type Template Parameters) discussed a fixed_string type, but stopped short of proposing one. Richard Smith described and presented an operator template mechanism to allow a type that is not a structural type to provide its own method of encoding as a template parameter, but a formal proposal has not been submitted. If adopted, such a mechanism could be useful for the implementation of a fixed_string type.

There are numerous implementations of a fixed_string type available:

The proposal also discusses integration with std::format and iostreams, but is light on details at present. See the "Look and feel" section for examples. Though not shown in the paper, the reference implementation describes a grammar for a std::format formatter. That grammar includes a units-text-encoding production that allows the programmer to select between Unicode and ASCII symbols. Whether such manual selection is appropriate and how it interacts with encoding is clearly an SG16 concern. See the unit test examples in https://github.com/mpusz/mp-units/blob/master/test/unit_test/static/unit_symbol_test.cpp.

Finally, if time permits, we'll discuss wchar_t, char8_t, char16_t, and char32_t support. Since neither iostreams nor std::format support the charN_t types at present, there likely isn't much to discuss there. I might be mistaken, but the reference implementation does not appear to support wchar_t at present.

Tom.


--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16