Topic: Fixed Size Strings.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Thu, 7 Mar 2019 09:41:39 +0000
Raw View
--00000000000064203805837dea43
Content-Type: text/plain; charset="UTF-8"
Hi all,
I would like to propose a standardised fixed size string type,
fixed_string<N> as a thin wrapper of char[N+1].
The standard allows for implementations to store extra data in std::array,
so that is why char[N+1] makes more sense than std::array for this purpose
- the size should be exactly N+1 chars.
The name is debatable. Fixed has a number of meanings and I don't like the
idea of someone thinking the objective is to "fix" something broken with
std::string, but this name is common to many existing implementations. The
+1 is also debatable. Given the number of functions in the wild that assume
a null char termination, that extra char provides safety. Overwriting that
final char is then classed as UB. Having non-null chars after the first
null char is UB. Primary focus should be on providing intuitive interface
that makes it easier to stick to defined behaviour.
I have worked with many 3rd party libraries involving low latency
transport, and fixed size string implementations are to be found in the
majority of those. I use fixed size strings in my own libraries, and I have
also seen them in a variety of open source codebases. The benefits of it
are the same that std::array has over std::vector, or that char[N] has over
char*, in that its value is stack allocated and its length is encoded in
its type. The upside of standardisation is to eventually introduce
compatibility between such libraries, but the primary use for me is on
easier, type safe wrapping of C interfaces (e.g. sockets) without resorting
to explicit use of C string functions.
Main benefits:
- Easy and efficient to transmit/read. A struct containing them can be
reinterpret_casted to a char array and sent over a socket or written to a
file directly, assuming the struct is packed. This is quite common when
using UDP, for example, but through a char[N] interface (and with all the C
functions that come with it).
- Efficient to process. The string data is held within the body of any
struct holding it, so you benefit from cache locality and stack allocation. The
max size is known, so a lower bound search for the null char will suffice
in larger strings (hence non-null chars after the first null char being UB).
- Type safety. There is are many cases that runtime size checking is
unnecessary, such as conversion from smaller/larger fixed strings (via a
fixed size memcpy, rather than an strcpy, with conversion from larger
strings truncating the input). Concatenation of a fixed_string<N> and a
fixed_string<M> results in a fixed_string<N+M>, though this will require a
search for the null char in the left operand.
The interface should have much of the functionality we enjoy with
std::string. End iterators can come in two varieties: end() which is the
first null char, and fixed_end() which is begin() + N + 1, which can also
enjoy a view through the ranges interface.
I have an interface in mind, but I'm looking for criticism and further
ideas to the above before proposing the interface itself. I'm aware that
this idea is far from unique (that's actually the main reason I believe
standardisation is beneficial) and there are a variety of tried and tested
approaches.
Thanks,
Jake
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdNbqAActNASpZTneUA%40mail.gmail.com.
--00000000000064203805837dea43
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Hi all,<div dir=3D"auto"><br><div dir=3D"auto">I would li=
ke to propose a standardised fixed size string type, fixed_string<N> =
as a thin wrapper of char[N+1].</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The standard allows for implementations to store extra data in st=
d::array, so that is why char[N+1] makes more sense than std::array for thi=
s purpose - the size should be exactly N+1 chars.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">The name is debatable. Fixed has a number of mean=
ings and I don't like the idea of someone thinking the objective is to =
"fix" something broken with std::string, but this name is common =
to many existing implementations. The +1 is also debatable. Given the numbe=
r of functions in the wild that assume a null char termination, that extra =
char provides safety. Overwriting that final char is then classed as UB. Ha=
ving non-null chars after the first null char is UB. Primary focus should b=
e on providing intuitive interface that makes it easier to stick to defined=
behaviour.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I have worke=
d with many 3rd party libraries involving low latency transport, and fixed =
size string implementations are to be found in the majority of those. I use=
fixed size strings in my own libraries, and I have also seen them in a var=
iety of open source codebases. The benefits of it are the same that std::ar=
ray has over std::vector, or that char[N] has over char*, in that its value=
is stack allocated and its length is encoded in its type. The upside of st=
andardisation is to eventually introduce compatibility between such librari=
es, but the primary use for me is on easier, type safe wrapping of C interf=
aces (e.g. sockets) without resorting to explicit use of C string functions=
..</div><div dir=3D"auto"><br></div><div dir=3D"auto">Main benefits:</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">- Easy and efficient to transmi=
t/read. A struct containing them can be reinterpret_casted to a char array =
and sent over a socket or written to a file directly, assuming the struct i=
s packed. This is quite common when using UDP, for example, but through a c=
har[N] interface (and with all the C functions that come with it).=C2=A0</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">- Efficient to process. Th=
e string data is held within the body of any struct holding it, so you bene=
fit from cache locality and stack allocation.=C2=A0<span style=3D"font-fami=
ly:sans-serif">The max size is known, so a lower bound search for the null =
char will suffice in larger strings (hence non-null chars after the first n=
ull char being UB).</span></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">- Type safety. There is are many cases that runtime size checking is unn=
ecessary, such as conversion from smaller/larger fixed strings (via a fixed=
size memcpy, rather than an strcpy, with conversion from larger strings tr=
uncating the input). Concatenation of a fixed_string<N> and a fixed_s=
tring<M> results in a fixed_string<N+M>, though this will requi=
re a search for the null char in the left operand.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">The interface should have much of the functional=
ity we enjoy with std::string. End iterators can come in two varieties: end=
() which is the first null char, and fixed_end() which is begin() + N + 1, =
which can also enjoy a view through the ranges interface.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">I have an interface in mind, but I'm =
looking for criticism and further ideas to the above before proposing the i=
nterface itself. I'm aware that this idea is far from unique (that'=
s actually the main reason I believe standardisation is beneficial) and the=
re are a variety of tried and tested approaches.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Thanks,=C2=A0</div><div dir=3D"auto">Jake</div></d=
iv></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdN=
bqAActNASpZTneUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK=
_HO7UvWB67vBZRLZSKxBdNbqAActNASpZTneUA%40mail.gmail.com</a>.<br />
--00000000000064203805837dea43--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 7 Mar 2019 20:20:38 +1000
Raw View
--000000000000df503d05837e75c6
Content-Type: text/plain; charset="UTF-8"
Hi Jake,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0259r0.pdf
https://github.com/tomazos/fixed_string
I've put this on hold because I think we're going to get a constexpr
std::string in not too distant future. The main motivation was to have a
compile-time string (formally, a string class of literal type) for
reflection.
But if you want to pick it up I'd be happy to work with you.
Regards,
Andrew.
On Thu, Mar 7, 2019 at 7:41 PM Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:
> Hi all,
>
> I would like to propose a standardised fixed size string type,
> fixed_string<N> as a thin wrapper of char[N+1].
>
> The standard allows for implementations to store extra data in std::array,
> so that is why char[N+1] makes more sense than std::array for this purpose
> - the size should be exactly N+1 chars.
>
> The name is debatable. Fixed has a number of meanings and I don't like the
> idea of someone thinking the objective is to "fix" something broken with
> std::string, but this name is common to many existing implementations. The
> +1 is also debatable. Given the number of functions in the wild that assume
> a null char termination, that extra char provides safety. Overwriting that
> final char is then classed as UB. Having non-null chars after the first
> null char is UB. Primary focus should be on providing intuitive interface
> that makes it easier to stick to defined behaviour.
>
> I have worked with many 3rd party libraries involving low latency
> transport, and fixed size string implementations are to be found in the
> majority of those. I use fixed size strings in my own libraries, and I have
> also seen them in a variety of open source codebases. The benefits of it
> are the same that std::array has over std::vector, or that char[N] has over
> char*, in that its value is stack allocated and its length is encoded in
> its type. The upside of standardisation is to eventually introduce
> compatibility between such libraries, but the primary use for me is on
> easier, type safe wrapping of C interfaces (e.g. sockets) without resorting
> to explicit use of C string functions.
>
> Main benefits:
>
> - Easy and efficient to transmit/read. A struct containing them can be
> reinterpret_casted to a char array and sent over a socket or written to a
> file directly, assuming the struct is packed. This is quite common when
> using UDP, for example, but through a char[N] interface (and with all the C
> functions that come with it).
>
> - Efficient to process. The string data is held within the body of any
> struct holding it, so you benefit from cache locality and stack allocation. The
> max size is known, so a lower bound search for the null char will suffice
> in larger strings (hence non-null chars after the first null char being UB).
>
> - Type safety. There is are many cases that runtime size checking is
> unnecessary, such as conversion from smaller/larger fixed strings (via a
> fixed size memcpy, rather than an strcpy, with conversion from larger
> strings truncating the input). Concatenation of a fixed_string<N> and a
> fixed_string<M> results in a fixed_string<N+M>, though this will require a
> search for the null char in the left operand.
>
> The interface should have much of the functionality we enjoy with
> std::string. End iterators can come in two varieties: end() which is the
> first null char, and fixed_end() which is begin() + N + 1, which can also
> enjoy a view through the ranges interface.
>
> I have an interface in mind, but I'm looking for criticism and further
> ideas to the above before proposing the interface itself. I'm aware that
> this idea is far from unique (that's actually the main reason I believe
> standardisation is beneficial) and there are a variety of tried and tested
> approaches.
>
> Thanks,
> Jake
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdNbqAActNASpZTneUA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdNbqAActNASpZTneUA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BWVa%2BTE248Ncj0Cp1NFTUv3m68GwARjFgGuTWznXMN4Q%40mail.gmail.com.
--000000000000df503d05837e75c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Jake,</div><div>=
<br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2016/p0259r0.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0259r0.pdf</a><br></div><div><br></div><div><a href=3D"https://github.com=
/tomazos/fixed_string">https://github.com/tomazos/fixed_string</a><br></div=
><div><br></div><div>I've put this on hold because I think we're go=
ing to get a constexpr std::string in not too distant future.=C2=A0 The mai=
n motivation was to have a compile-time string (formally, a string class of=
literal type) for reflection.</div><div><br></div><div>But if you want to =
pick it up I'd be happy to work with you.</div><div><br></div><div>Rega=
rds,</div><div>Andrew.</div><div><br></div><div><br></div><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 7, 2019 at 7:41=
PM Jake Arkinstall <<a href=3D"mailto:jake.arkinstall@gmail.com">jake.a=
rkinstall@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"auto">Hi all,<div dir=3D"auto"><br><div dir=
=3D"auto">I would like to propose a standardised fixed size string type, fi=
xed_string<N> as a thin wrapper of char[N+1].</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">The standard allows for implementations to stor=
e extra data in std::array, so that is why char[N+1] makes more sense than =
std::array for this purpose - the size should be exactly N+1 chars.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">The name is debatable. Fixed ha=
s a number of meanings and I don't like the idea of someone thinking th=
e objective is to "fix" something broken with std::string, but th=
is name is common to many existing implementations. The +1 is also debatabl=
e. Given the number of functions in the wild that assume a null char termin=
ation, that extra char provides safety. Overwriting that final char is then=
classed as UB. Having non-null chars after the first null char is UB. Prim=
ary focus should be on providing intuitive interface that makes it easier t=
o stick to defined behaviour.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">I have worked with many 3rd party libraries involving low latency tra=
nsport, and fixed size string implementations are to be found in the majori=
ty of those. I use fixed size strings in my own libraries, and I have also =
seen them in a variety of open source codebases. The benefits of it are the=
same that std::array has over std::vector, or that char[N] has over char*,=
in that its value is stack allocated and its length is encoded in its type=
.. The upside of standardisation is to eventually introduce compatibility be=
tween such libraries, but the primary use for me is on easier, type safe wr=
apping of C interfaces (e.g. sockets) without resorting to explicit use of =
C string functions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Main=
benefits:</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Easy and ef=
ficient to transmit/read. A struct containing them can be reinterpret_caste=
d to a char array and sent over a socket or written to a file directly, ass=
uming the struct is packed. This is quite common when using UDP, for exampl=
e, but through a char[N] interface (and with all the C functions that come =
with it).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Effici=
ent to process. The string data is held within the body of any struct holdi=
ng it, so you benefit from cache locality and stack allocation.=C2=A0<span =
style=3D"font-family:sans-serif">The max size is known, so a lower bound se=
arch for the null char will suffice in larger strings (hence non-null chars=
after the first null char being UB).</span></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">- Type safety. There is are many cases that runtime si=
ze checking is unnecessary, such as conversion from smaller/larger fixed st=
rings (via a fixed size memcpy, rather than an strcpy, with conversion from=
larger strings truncating the input). Concatenation of a fixed_string<N=
> and a fixed_string<M> results in a fixed_string<N+M>, thou=
gh this will require a search for the null char in the left operand.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">The interface should have much=
of the functionality we enjoy with std::string. End iterators can come in =
two varieties: end() which is the first null char, and fixed_end() which is=
begin() + N + 1, which can also enjoy a view through the ranges interface.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">I have an interface in =
mind, but I'm looking for criticism and further ideas to the above befo=
re proposing the interface itself. I'm aware that this idea is far from=
unique (that's actually the main reason I believe standardisation is b=
eneficial) and there are a variety of tried and tested approaches.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Thanks,=C2=A0</div><div dir=3D"a=
uto">Jake</div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdN=
bqAActNASpZTneUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdNbqAActNASpZTneUA%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BWVa%2BTE248Ncj0Cp1NFTUv3m=
68GwARjFgGuTWznXMN4Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2=
BWVa%2BTE248Ncj0Cp1NFTUv3m68GwARjFgGuTWznXMN4Q%40mail.gmail.com</a>.<br />
--000000000000df503d05837e75c6--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Thu, 7 Mar 2019 10:53:00 +0000
Raw View
--00000000000094a6b905837ee9f2
Content-Type: text/plain; charset="UTF-8"
Hi Andrew,
Thanks for this, I wasn't aware of an existing proposal (and was shocked
when a Google search revealed a few stack overflow posts and a couple of
open source projects, but not much else).
The progress of constexpr functionality to dynamic allocation does take
away a few of the potential benefits of fixed size strings vs std::string,
though with the focus on fixed binary size and the benefits that come with
it in terms of I/O and cache locality, I think a revival might be
worthwhile. I'll give this a read and get back to you.
Thanks again,
Jake
On Thu, 7 Mar 2019, 10:20 Andrew Tomazos, <andrewtomazos@gmail.com> wrote:
> Hi Jake,
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0259r0.pdf
>
> https://github.com/tomazos/fixed_string
>
> I've put this on hold because I think we're going to get a constexpr
> std::string in not too distant future. The main motivation was to have a
> compile-time string (formally, a string class of literal type) for
> reflection.
>
> But if you want to pick it up I'd be happy to work with you.
>
> Regards,
> Andrew.
>
>
> On Thu, Mar 7, 2019 at 7:41 PM Jake Arkinstall <jake.arkinstall@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I would like to propose a standardised fixed size string type,
>> fixed_string<N> as a thin wrapper of char[N+1].
>>
>> The standard allows for implementations to store extra data in
>> std::array, so that is why char[N+1] makes more sense than std::array for
>> this purpose - the size should be exactly N+1 chars.
>>
>> The name is debatable. Fixed has a number of meanings and I don't like
>> the idea of someone thinking the objective is to "fix" something broken
>> with std::string, but this name is common to many existing implementations.
>> The +1 is also debatable. Given the number of functions in the wild that
>> assume a null char termination, that extra char provides safety.
>> Overwriting that final char is then classed as UB. Having non-null chars
>> after the first null char is UB. Primary focus should be on providing
>> intuitive interface that makes it easier to stick to defined behaviour.
>>
>> I have worked with many 3rd party libraries involving low latency
>> transport, and fixed size string implementations are to be found in the
>> majority of those. I use fixed size strings in my own libraries, and I have
>> also seen them in a variety of open source codebases. The benefits of it
>> are the same that std::array has over std::vector, or that char[N] has over
>> char*, in that its value is stack allocated and its length is encoded in
>> its type. The upside of standardisation is to eventually introduce
>> compatibility between such libraries, but the primary use for me is on
>> easier, type safe wrapping of C interfaces (e.g. sockets) without resorting
>> to explicit use of C string functions.
>>
>> Main benefits:
>>
>> - Easy and efficient to transmit/read. A struct containing them can be
>> reinterpret_casted to a char array and sent over a socket or written to a
>> file directly, assuming the struct is packed. This is quite common when
>> using UDP, for example, but through a char[N] interface (and with all the C
>> functions that come with it).
>>
>> - Efficient to process. The string data is held within the body of any
>> struct holding it, so you benefit from cache locality and stack allocation. The
>> max size is known, so a lower bound search for the null char will suffice
>> in larger strings (hence non-null chars after the first null char being UB).
>>
>> - Type safety. There is are many cases that runtime size checking is
>> unnecessary, such as conversion from smaller/larger fixed strings (via a
>> fixed size memcpy, rather than an strcpy, with conversion from larger
>> strings truncating the input). Concatenation of a fixed_string<N> and a
>> fixed_string<M> results in a fixed_string<N+M>, though this will require a
>> search for the null char in the left operand.
>>
>> The interface should have much of the functionality we enjoy with
>> std::string. End iterators can come in two varieties: end() which is the
>> first null char, and fixed_end() which is begin() + N + 1, which can also
>> enjoy a view through the ranges interface.
>>
>> I have an interface in mind, but I'm looking for criticism and further
>> ideas to the above before proposing the interface itself. I'm aware that
>> this idea is far from unique (that's actually the main reason I believe
>> standardisation is beneficial) and there are a variety of tried and tested
>> approaches.
>>
>> Thanks,
>> Jake
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdNbqAActNASpZTneUA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdNbqAActNASpZTneUA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPV9zS%3DqEHDDHmbw6vX1_c%2ByBxXsVuBtO_FBG8HQ-tNQg%40mail.gmail.com.
--00000000000094a6b905837ee9f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>Hi Andrew,<div dir=3D"auto"><br></div><div dir=3D"au=
to">Thanks for this, I wasn't aware of an existing proposal (and was sh=
ocked when a Google search revealed a few stack overflow posts and a couple=
of open source projects, but not much else).</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">The progress of constexpr functionality to dynamic al=
location does take away a few of the potential benefits of fixed size strin=
gs vs std::string, though with the focus on fixed binary size and the benef=
its that come with it in terms of I/O and cache locality, I think a revival=
might be worthwhile. I'll give this a read and get back to you.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Thanks again,</div><div dir=3D=
"auto">Jake</div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Thu, 7 Mar 2019, 10:20 Andrew Tomazos, <<a href=3D"ma=
ilto:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div>Hi Jake,</div><div><br></div><div><a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2016/p0259r0.pdf" target=3D"_blank" rel=
=3D"noreferrer">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p02=
59r0.pdf</a><br></div><div><br></div><div><a href=3D"https://github.com/tom=
azos/fixed_string" target=3D"_blank" rel=3D"noreferrer">https://github.com/=
tomazos/fixed_string</a><br></div><div><br></div><div>I've put this on =
hold because I think we're going to get a constexpr std::string in not =
too distant future.=C2=A0 The main motivation was to have a compile-time st=
ring (formally, a string class of literal type) for reflection.</div><div><=
br></div><div>But if you want to pick it up I'd be happy to work with y=
ou.</div><div><br></div><div>Regards,</div><div>Andrew.</div><div><br></div=
><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Thu, Mar 7, 2019 at 7:41 PM Jake Arkinstall <<a href=3D"mailto:=
jake.arkinstall@gmail.com" target=3D"_blank" rel=3D"noreferrer">jake.arkins=
tall@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"auto">Hi all,<div dir=3D"auto"><br><div dir=3D"au=
to">I would like to propose a standardised fixed size string type, fixed_st=
ring<N> as a thin wrapper of char[N+1].</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">The standard allows for implementations to store extr=
a data in std::array, so that is why char[N+1] makes more sense than std::a=
rray for this purpose - the size should be exactly N+1 chars.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">The name is debatable. Fixed has a nu=
mber of meanings and I don't like the idea of someone thinking the obje=
ctive is to "fix" something broken with std::string, but this nam=
e is common to many existing implementations. The +1 is also debatable. Giv=
en the number of functions in the wild that assume a null char termination,=
that extra char provides safety. Overwriting that final char is then class=
ed as UB. Having non-null chars after the first null char is UB. Primary fo=
cus should be on providing intuitive interface that makes it easier to stic=
k to defined behaviour.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
I have worked with many 3rd party libraries involving low latency transport=
, and fixed size string implementations are to be found in the majority of =
those. I use fixed size strings in my own libraries, and I have also seen t=
hem in a variety of open source codebases. The benefits of it are the same =
that std::array has over std::vector, or that char[N] has over char*, in th=
at its value is stack allocated and its length is encoded in its type. The =
upside of standardisation is to eventually introduce compatibility between =
such libraries, but the primary use for me is on easier, type safe wrapping=
of C interfaces (e.g. sockets) without resorting to explicit use of C stri=
ng functions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Main benef=
its:</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Easy and efficien=
t to transmit/read. A struct containing them can be reinterpret_casted to a=
char array and sent over a socket or written to a file directly, assuming =
the struct is packed. This is quite common when using UDP, for example, but=
through a char[N] interface (and with all the C functions that come with i=
t).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Efficient to=
process. The string data is held within the body of any struct holding it,=
so you benefit from cache locality and stack allocation.=C2=A0<span style=
=3D"font-family:sans-serif">The max size is known, so a lower bound search =
for the null char will suffice in larger strings (hence non-null chars afte=
r the first null char being UB).</span></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">- Type safety. There is are many cases that runtime size ch=
ecking is unnecessary, such as conversion from smaller/larger fixed strings=
(via a fixed size memcpy, rather than an strcpy, with conversion from larg=
er strings truncating the input). Concatenation of a fixed_string<N> =
and a fixed_string<M> results in a fixed_string<N+M>, though th=
is will require a search for the null char in the left operand.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">The interface should have much of t=
he functionality we enjoy with std::string. End iterators can come in two v=
arieties: end() which is the first null char, and fixed_end() which is begi=
n() + N + 1, which can also enjoy a view through the ranges interface.</div=
><div dir=3D"auto"><br></div><div dir=3D"auto">I have an interface in mind,=
but I'm looking for criticism and further ideas to the above before pr=
oposing the interface itself. I'm aware that this idea is far from uniq=
ue (that's actually the main reason I believe standardisation is benefi=
cial) and there are a variety of tried and tested approaches.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Thanks,=C2=A0</div><div dir=3D"auto">=
Jake</div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdN=
bqAActNASpZTneUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAC%2B0CCPasEHK_HO7UvWB67vBZRLZSKxBdNbqAActNASpZT=
neUA%40mail.gmail.com</a>.<br>
</blockquote></div></div></div></div>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPV9zS%3DqEHDDHmbw6vX1_c%2ByB=
xXsVuBtO_FBG8HQ-tNQg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPV=
9zS%3DqEHDDHmbw6vX1_c%2ByBxXsVuBtO_FBG8HQ-tNQg%40mail.gmail.com</a>.<br />
--00000000000094a6b905837ee9f2--
.