Topic: String class memory allocation
Author: Robin Rowe <robinsrowe@gmail.com>
Date: Wed, 24 Feb 2016 08:28:33 -0800
Raw View
What's in the standard to avoid heap allocation during string creation?
Is there a standard string class that doesn't use 'new', that works
something like this?
template <unsigned bufsize>
class FixedLengthString
{ char buffer[bufsize]
public:
... [ typical string interface ]
};
FixedLengthString<80> s("hello world");
Is there a standard memory pool class, something like this?
template <unsigned poolsize>
class MemoryPoolString
{ static MemoryPool memoryPool;//shared by all strings
char* buffer;
public:
MemoryPoolString()
{ if(!memoryPool)
{ memoryPool.Create(poolsize);
}
buffer=0;
}
...
};
My reason for caring is the cost of calling new on every string creation.
Robin
--
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/56CDDA31.5090706%40gmail.com.
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Wed, 24 Feb 2016 18:36:20 +0100
Raw View
Given that we already have `std::array` and almost certainly will have
`std::string_view` soon, I think that this isssue is solved.
Robin Rowe <robinsrowe@gmail.com> writes:
> What's in the standard to avoid heap allocation during string creation?
>
> Is there a standard string class that doesn't use 'new', that works something
> like this?
>
> template <unsigned bufsize>
> class FixedLengthString
> { char buffer[bufsize]
> public:
> ... [ typical string interface ]
> };
>
> FixedLengthString<80> s("hello world");
>
> Is there a standard memory pool class, something like this?
>
> template <unsigned poolsize>
> class MemoryPoolString
> { static MemoryPool memoryPool;//shared by all strings
> char* buffer;
> public:
> MemoryPoolString()
> { if(!memoryPool)
> { memoryPool.Create(poolsize);
> }
> buffer=0;
> }
> ...
> };
>
> My reason for caring is the cost of calling new on every string creation.
>
> Robin
--
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/87mvqqko2z.fsf%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 24 Feb 2016 09:54:23 -0800 (PST)
Raw View
------=_Part_4512_117612204.1456336463335
Content-Type: multipart/alternative;
boundary="----=_Part_4513_1191458557.1456336463335"
------=_Part_4513_1191458557.1456336463335
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 24, 2016 at 12:36:26 PM UTC-5, Moritz Klammler wrote:
>
> Given that we already have `std::array` and almost certainly will have
> `std::string_view` soon, I think that this isssue is solved.
>
`string_view` will not obviate the need for a fixed-length string class.
And `array<char>` is not a string; it's an array of char.
Either way however, that doesn't mean that the standard library needs to
supply such a class. I think that's rather out-of-bounds for
standardization. Allocators with std::string can at least handle the pool
case.
--
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/06e4f837-6358-4bb2-8cd4-516e4cabd82e%40isocpp.org.
------=_Part_4513_1191458557.1456336463335
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 24, 2016 at 12:36:26 PM UTC-5, Mori=
tz Klammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Given that w=
e already have `std::array` and almost certainly will have
<br>`std::string_view` soon, I think that this isssue is solved.
<br></blockquote><div><br>`string_view` will not obviate the need for a fix=
ed-length string class. And `array<char>` is not a string; it's a=
n array of char.<br><br>Either way however, that doesn't mean that the =
standard library needs to supply such a class. I think that's rather ou=
t-of-bounds for standardization. Allocators with std::string can at least h=
andle the pool case.<br></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/06e4f837-6358-4bb2-8cd4-516e4cabd82e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06e4f837-6358-4bb2-8cd4-516e4cabd82e=
%40isocpp.org</a>.<br />
------=_Part_4513_1191458557.1456336463335--
------=_Part_4512_117612204.1456336463335--
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Wed, 24 Feb 2016 20:18:28 +0100
Raw View
Nicol Bolas <jmckesson@gmail.com> writes:
> On Wednesday, February 24, 2016 at 12:36:26 PM UTC-5, Moritz Klammler wrote:
>>
>> Given that we already have `std::array` and almost certainly will
>> have `std::string_view` soon, I think that this isssue is solved.
>>
>
> `string_view` will not obviate the need for a fixed-length string
> class. And `array<char>` is not a string; it's an array of char.
In case this wasn't clear, my point is of course that you can use
`std::array` to *store* the data and *atop of that* a `std::string_view`
to *access* it through the "string interface" the OP requested. In the
same way, you could combine `std::vector` and `std::string_view` to get
a dynamically-sized string, if there wouldn't already be the superior
(thanks to SSO) `std::string`, of course.
--
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/87io1dlxx7.fsf%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 25 Feb 2016 07:32:45 -0800 (PST)
Raw View
------=_Part_867_1167178551.1456414365329
Content-Type: multipart/alternative;
boundary="----=_Part_868_564565729.1456414365330"
------=_Part_868_564565729.1456414365330
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 24, 2016 at 2:18:34 PM UTC-5, Moritz Klammler wrote:
>
> Nicol Bolas <jmck...@gmail.com <javascript:>> writes:
>
> > On Wednesday, February 24, 2016 at 12:36:26 PM UTC-5, Moritz Klammler
> wrote:
> >>
> >> Given that we already have `std::array` and almost certainly will
> >> have `std::string_view` soon, I think that this isssue is solved.
> >>
> >
> > `string_view` will not obviate the need for a fixed-length string
> > class. And `array<char>` is not a string; it's an array of char.
>
> In case this wasn't clear, my point is of course that you can use
> `std::array` to *store* the data and *atop of that* a `std::string_view`
> to *access* it through the "string interface" the OP requested.
Really? So naturally, this works, right?
array<char, 20> arr = "A String";
Oh wait, it doesn't. And neither does this:
array<char, 20> arr = {'N', 'U', 'L', 'L', '\0'};
string_view sv(arr);
It'll compile, but `sv` will get its size from `arr.size()`, which most
assuredly not the intended value of 4.
Obviously you could write wrapper functions and/or types that make all of
these work; nobody's arguing that it isn't possible to create such things.
But the whole point of the question was whether such things *already exist*
in the standard library, not whether the standard library has a bunch of
pieces that could be assembled into such things.
--
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/8ffac287-1ea1-4c04-9a9b-817610e013f1%40isocpp.org.
------=_Part_868_564565729.1456414365330
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 24, 2016 at 2:18:34 PM UTC-5, Morit=
z Klammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Nicol Bolas &=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"po8KG=
xBcAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">jm=
ck...@gmail.com</a>> writes:
<br>
<br>> On Wednesday, February 24, 2016 at 12:36:26 PM UTC-5, Moritz Klamm=
ler wrote:
<br>>>
<br>>> Given that we already have `std::array` and almost certainly w=
ill
<br>>> have `std::string_view` soon, I think that this isssue is solv=
ed.
<br>>>
<br>>
<br>> `string_view` will not obviate the need for a fixed-length string
<br>> class. =C2=A0And `array<char>` is not a string; it's an =
array of char.
<br>
<br>In case this wasn't clear, my point is of course that you can use
<br>`std::array` to *store* the data and *atop of that* a `std::string_view=
`
<br>to *access* it through the "string interface" the OP requeste=
d.</blockquote><div><br>Really? So naturally, this works, right?<br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">array</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">20</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> arr </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"A St=
ring"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span></div></code></div><br>Oh wait, it doesn't. And neither does th=
is:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">a=
rray</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">20</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> arr </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #080;" class=3D"styled-by-prettify">'=
N'</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #080;" class=3D"styled-by-prettify">'U'</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">'L'</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D=
"styled-by-prettify">'L'</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">'\0'</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>string_view sv</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a=
rr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div=
></code></div><br>It'll compile, but `sv` will get its size from `arr.s=
ize()`, which most assuredly not the intended value of 4.<br><br>Obviously =
you could write wrapper functions and/or types that make all of these work;=
nobody's arguing that it isn't possible to create such things. But=
the whole point of the question was whether such things <i>already exist</=
i> in the standard library, not whether the standard library has a bunch of=
pieces that could be assembled into such things.</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/8ffac287-1ea1-4c04-9a9b-817610e013f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8ffac287-1ea1-4c04-9a9b-817610e013f1=
%40isocpp.org</a>.<br />
------=_Part_868_564565729.1456414365330--
------=_Part_867_1167178551.1456414365329--
.