Topic: First working prototype for static
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 18 Aug 2015 15:31:13 -0300
Raw View
On Tue, Aug 18, 2015 at 2:51 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Is there also a `static_dealloc` to go along with that? Or is it not allo=
wed
> to create a std::string/vector/etc as a temporary?
Would a temporary object in ROM be useful? (I'm asking seriously, maybe I'm
missing something). Otherwise, since the main motivation of this
feature is to be able
to have containers in ROM, I don't find the need for a deallocation counter=
part.
Regarding a non-const object, I fail to see the need too.
Please note that (sorry I did not give further details yet) what
static_alloc does is to
create a (uniquely named) global array.
However, Richard Smith may have something else to say; I recall some
discussion with him
about this point but don't get the details now.
>
> Also, how do you detect when to use the `static_alloc` allocator and when
> not to? Generally speaking, as I understand it, there is no mechanism in =
C++
> (yet) that allows you to detect when the compiler is
> really-truly-honest-to-God executing your code at compile time and when i=
t
> isn't. After all, you can call those constexpr constructors at non-conste=
xpr
> times too.
We currently issue a compiler error when static_alloc is used in a
function that is called from non-constexpr contexts.
However, in my original idea, "new" was used: if in true constexpr
context, behaved as our current
static_alloc, and as regular "new" otherwise. It happens that due to
current needs (containers in ROM
for a real project), we need static_alloc to fail if the constexpr
context cannot be achieved.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 18 Aug 2015 12:05:17 -0700 (PDT)
Raw View
------=_Part_3433_585551992.1439924717422
Content-Type: multipart/alternative;
boundary="----=_Part_3434_517544600.1439924717422"
------=_Part_3434_517544600.1439924717422
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 18, 2015 at 2:31:15 PM UTC-4, dgutson wrote:
>
> On Tue, Aug 18, 2015 at 2:51 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > Is there also a `static_dealloc` to go along with that? Or is it not
> allowed
> > to create a std::string/vector/etc as a temporary?
>
> Would a temporary object in ROM be useful? (I'm asking seriously, maybe
> I'm
> missing something). Otherwise, since the main motivation of this
> feature is to be able
> to have containers in ROM, I don't find the need for a deallocation
> counterpart.
> Regarding a non-const object, I fail to see the need too.
> Please note that (sorry I did not give further details yet) what
> static_alloc does is to
> create a (uniquely named) global array.
> However, Richard Smith may have something else to say; I recall some
> discussion with him
> about this point but don't get the details now.
>
If the point of static_alloc is to allow the creation of std::string
objects at compile time, then you have to be willing to allow something
like this at compile time:
constexpr std::string foo(std::string str)
{
return str + "foo";
}
constexpr const std::string const_str = foo("bar");
This creates a std::string temporary as part of its action. So the
temporary's destructor will have to be called, and it will have to call
something on its memory pointer.
>
> > Also, how do you detect when to use the `static_alloc` allocator and
> when
> > not to? Generally speaking, as I understand it, there is no mechanism in
> C++
> > (yet) that allows you to detect when the compiler is
> > really-truly-honest-to-God executing your code at compile time and when
> it
> > isn't. After all, you can call those constexpr constructors at
> non-constexpr
> > times too.
>
> We currently issue a compiler error when static_alloc is used in a
> function that is called from non-constexpr contexts.
> However, in my original idea, "new" was used: if in true constexpr
> context, behaved as our current
> static_alloc, and as regular "new" otherwise. It happens that due to
> current needs (containers in ROM
> for a real project), we need static_alloc to fail if the constexpr
> context cannot be achieved.
>
So... how do you deal with that in terms of an interface? If std::string
can use static_alloc, and static_alloc cannot be used in non constexpr
contexts, how does the user deal with that? Do you provide a completely
separate "really-definiately-constexpr-only" constructor?
Also, this seems to violate one of the most important tenants of contexpr.
Namely, that its not required, that anything marked `constexpr` can be
called from any code, whether constant expressions are required or not.
This would seem to require a different markup, a constexpr-only designation.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3434_517544600.1439924717422
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 18, 2015 at 2:31:15 PM UTC-4, dgutson wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">On Tue, Aug 18, 2015 at 2:51 PM, Nicol Bol=
as <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"c=
g96X4jxAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
">jmck...@gmail.com</a>> wrote:
<br>> Is there also a `static_dealloc` to go along with that? Or is it n=
ot allowed
<br>> to create a std::string/vector/etc as a temporary?
<br>
<br>Would a temporary object in ROM be useful? (I'm asking seriously, m=
aybe I'm
<br>missing something). Otherwise, since the main motivation of this
<br>feature is to be able
<br>to have containers in ROM, I don't find the need for a deallocation=
counterpart.
<br>Regarding a non-const object, I fail to see the need too.
<br>Please note that (sorry I did not give further details yet) what
<br>static_alloc does is to
<br>create a (uniquely named) global array.
<br>However, Richard Smith may have something else to say; I recall some
<br>discussion with him
<br>about this point but don't get the details now.<br></blockquote><di=
v><br>If the point of static_alloc is to allow the creation of std::string =
objects at compile time, then you have to be willing to allow something lik=
e this at compile time:<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">constexpr</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">string</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> str</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> str </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"foo&q=
uot;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">string</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> const_str </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"=
bar"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span></div></code></div><br>This creates a std::string temporary as part=
of its action. So the temporary's destructor will have to be called, a=
nd it will have to call something on its memory pointer.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
>
<br>> Also, how do you detect when to use the `static_alloc` allocator a=
nd when
<br>> not to? Generally speaking, as I understand it, there is no mechan=
ism in C++
<br>> (yet) that allows you to detect when the compiler is
<br>> really-truly-honest-to-God executing your code at compile time and=
when it
<br>> isn't. After all, you can call those constexpr constructors at=
non-constexpr
<br>> times too.
<br>
<br>We currently issue a compiler error when static_alloc is used in a
<br>function that is called from non-constexpr contexts.
<br>However, in my original idea, "new" was used: if in true cons=
texpr
<br>context, behaved as our current
<br>static_alloc, and as regular "new" otherwise. It happens that=
due to
<br>current needs (containers in ROM
<br>for a real project), we need static_alloc to fail if the constexpr
<br>context cannot be achieved.
<br></blockquote><div><br>So... how do you deal with that in terms of an in=
terface? If std::string can use static_alloc, and static_alloc cannot be us=
ed in non constexpr contexts, how does the user deal with that? Do you prov=
ide a completely separate "really-definiately-constexpr-only" con=
structor?<br><br>Also, this seems to violate one of the most important tena=
nts of contexpr. Namely, that its not required, that anything marked `const=
expr` can be called from any code, whether constant expressions are require=
d or not.<br><br>This would seem to require a different markup, a constexpr=
-only designation.<br></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3434_517544600.1439924717422--
------=_Part_3433_585551992.1439924717422--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 18 Aug 2015 12:05:09 -0700
Raw View
On Tuesday 18 August 2015 15:31:13 dgutson . wrote:
> Regarding a non-const object, I fail to see the need too.
We're already missing a way to enforce an object be constructed by a constexpr
constructor at compile-time if the destructor isn't constexpr either.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 18 Aug 2015 16:56:41 -0300
Raw View
On Tue, Aug 18, 2015 at 4:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, August 18, 2015 at 2:31:15 PM UTC-4, dgutson wrote:
>>
>> On Tue, Aug 18, 2015 at 2:51 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > Is there also a `static_dealloc` to go along with that? Or is it not
>> > allowed
>> > to create a std::string/vector/etc as a temporary?
>>
>> Would a temporary object in ROM be useful? (I'm asking seriously, maybe
>> I'm
>> missing something). Otherwise, since the main motivation of this
>> feature is to be able
>> to have containers in ROM, I don't find the need for a deallocation
>> counterpart.
>> Regarding a non-const object, I fail to see the need too.
>> Please note that (sorry I did not give further details yet) what
>> static_alloc does is to
>> create a (uniquely named) global array.
>> However, Richard Smith may have something else to say; I recall some
>> discussion with him
>> about this point but don't get the details now.
>
>
> If the point of static_alloc is to allow the creation of std::string obje=
cts
> at compile time, then you have to be willing to allow something like this=
at
> compile time:
>
> constexpr std::string foo(std::string str)
> {
> return str + "foo";
> }
>
> constexpr const std::string const_str =3D foo("bar");
>
> This creates a std::string temporary as part of its action. So the
> temporary's destructor will have to be called, and it will have to call
> something on its memory pointer.
(Richard, your phone is ringing :) ).
That's the main reason I think these should be other classes rather to
extend existing ones:
std::static_string, std::static_etc, which dtor does nothing. Indeed
this is how we are implementing this.
These object don't provide copy ctor, move, etc. Please analyze
carefully what the use case is.
I presented it in Rapperswil.
>
>> >
>> > Also, how do you detect when to use the `static_alloc` allocator and
>> > when
>> > not to? Generally speaking, as I understand it, there is no mechanism =
in
>> > C++
>> > (yet) that allows you to detect when the compiler is
>> > really-truly-honest-to-God executing your code at compile time and whe=
n
>> > it
>> > isn't. After all, you can call those constexpr constructors at
>> > non-constexpr
>> > times too.
>>
>> We currently issue a compiler error when static_alloc is used in a
>> function that is called from non-constexpr contexts.
>> However, in my original idea, "new" was used: if in true constexpr
>> context, behaved as our current
>> static_alloc, and as regular "new" otherwise. It happens that due to
>> current needs (containers in ROM
>> for a real project), we need static_alloc to fail if the constexpr
>> context cannot be achieved.
>
>
> So... how do you deal with that in terms of an interface? If std::string =
can
> use static_alloc, and static_alloc cannot be used in non constexpr contex=
ts,
> how does the user deal with that? Do you provide a completely separate
> "really-definiately-constexpr-only" constructor?
You might want to help with this. I already mentioned two pieces of relevan=
t
information:
a) think of dedicated std::static_x classes with an trivial dtor
b) if constexpr-ness cannot be honored, then static_alloc COULD behave as '=
new'.
Nevertheless, forcing constexpr-ness would be useful, though that is a
different discussion.
This is definitively something to decide:
option 1: there is a way to enforce constexpr-ness, and static_alloc
can only be used in such context.
(so the discussion forks to the constexpr enforcement
in another thread, please)
option 2: static_alloc fails when called from non-constexpr context
(current and currently used behavior)
option 3: static_alloc suddenly behaves as "new" when called from
non-constexpr context
That being said, what do you think?
>
> Also, this seems to violate one of the most important tenants of contexpr=
..
> Namely, that its not required, that anything marked `constexpr` can be
> called from any code, whether constant expressions are required or not.
>
> This would seem to require a different markup, a constexpr-only designati=
on.
FWIW, we have a -Wconstexpr patch so gcc warns when constexpr cannot be hon=
ored;
I think that there should be a way to enforce constexpr, but as I
mentioned, is a different discussion.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 18 Aug 2015 16:58:42 -0300
Raw View
On Tue, Aug 18, 2015 at 4:05 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Tuesday 18 August 2015 15:31:13 dgutson . wrote:
>> Regarding a non-const object, I fail to see the need too.
>
> We're already missing a way to enforce an object be constructed by a cons=
texpr
> constructor at compile-time if the destructor isn't constexpr either.
Please see my reply to Nicol Bolas for a related comment; but what you
say is interesting:
we will require the dtor to be constexpr for this feature. That could
be part of the proposal.
Thanks.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 18 Aug 2015 14:14:13 -0700
Raw View
On Tuesday 18 August 2015 16:56:41 dgutson . wrote:
> That's the main reason I think these should be other classes rather to
> extend existing ones:
> std::static_string, std::static_etc, which dtor does nothing. Indeed
> this is how we are implementing this.
I disagree that making separate classes that are identical except for a
trivial destructor is a good idea. For one thing, if the class is misused and
instead used in a runtime environment, it will leak memory.
Second, it's a separate class. How can you pass it by ref (for example) to a
function that takes a regular std::string?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 18 Aug 2015 18:27:52 -0300
Raw View
On Tue, Aug 18, 2015 at 6:14 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Tuesday 18 August 2015 16:56:41 dgutson . wrote:
>> That's the main reason I think these should be other classes rather to
>> extend existing ones:
>> std::static_string, std::static_etc, which dtor does nothing. Indeed
>> this is how we are implementing this.
>
> I disagree that making separate classes that are identical except for a
> trivial destructor is a good idea. For one thing, if the class is misused=
and
> instead used in a runtime environment, it will leak memory.
In no way I expect the implementations to be identical. If it happens
that there is common code
that has to be reused, move it to a base class.
If we agree that static_alloc can only be used in constexpr contexts,
it won't be misused.
>
> Second, it's a separate class. How can you pass it by ref (for example) t=
o a
> function that takes a regular std::string?
Either by moving the common const methods to a base class, or making
the user code accept a template
argument (which type is either std::static_X or std::X). Concepts
would incidentally help.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 18 Aug 2015 14:32:32 -0700
Raw View
On Tuesday 18 August 2015 18:27:52 dgutson . wrote:
> > Second, it's a separate class. How can you pass it by ref (for example) to
> > a function that takes a regular std::string?
>
> Either by moving the common const methods to a base class, or making
> the user code accept a template
> argument (which type is either std::static_X or std::X). Concepts
> would incidentally help.
Assume it's third-party non-inline code I cannot change.
How do I pass a statically allocated string to a function taking "const
std::string&" ?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 18 Aug 2015 18:41:50 -0300
Raw View
On Tue, Aug 18, 2015 at 6:32 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Tuesday 18 August 2015 18:27:52 dgutson . wrote:
>> > Second, it's a separate class. How can you pass it by ref (for example=
) to
>> > a function that takes a regular std::string?
>>
>> Either by moving the common const methods to a base class, or making
>> the user code accept a template
>> argument (which type is either std::static_X or std::X). Concepts
>> would incidentally help.
>
> Assume it's third-party non-inline code I cannot change.
>
> How do I pass a statically allocated string to a function taking "const
> std::string&" ?
Do I have all the answers? :) I'm giving you a nice toy, you are much
more resourceful
than me. Play with it!
I can think of: std::string to be constructed with a static_string, or
playing with
string_view-like ideas; static_string could build a temporal string
with a to_string.
Why don't you join the effort and become a co-author with my team, so
you play with the prototype,
provide ideas, etc.? The same for all the readers.
Please keep this in mind: this addresses a very real life problem we
are currently solving. Specially for
embedded systems, and so-called IoT computers or other very small
hardware which RAM is really scarce,
and should not be wasted with things that could perfectly be stored in ROM.
(Jokes aside, I really appreciate your (all readers) questions because
they are pre-proposal feedback).
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 18 Aug 2015 14:47:53 -0700
Raw View
On Tuesday 18 August 2015 18:41:50 dgutson . wrote:
> Why don't you join the effort and become a co-author with my team, so
> you play with the prototype,
> provide ideas, etc.? The same for all the readers.
Because I thought the solutions had already been presented: static allocation
and static deallocation at compile time. I don't see the need to have separate
classes once those are present.
> Please keep this in mind: this addresses a very real life problem we
> are currently solving. Specially for
> embedded systems, and so-called IoT computers or other very small
> hardware which RAM is really scarce,
> and should not be wasted with things that could perfectly be stored in ROM.
We have that for QString already, but we haven't solved the problem of storing
an actual QString in ROM. We've managed to store the QString's internal data
in ROM, but not the actual object.
See the QStringLiteral macro. We worked around the limitation of having static
data inside a constexpr function by moving it inside a lambda and making the
function a macro instead. The solution is, simplified, something like:
#define QStringLiteral(str) []() { \
static const QStringData d = { u"" str }; \
return QString(d); }()
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 18 Aug 2015 18:59:35 -0300
Raw View
On Tue, Aug 18, 2015 at 6:47 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Tuesday 18 August 2015 18:41:50 dgutson . wrote:
>> Why don't you join the effort and become a co-author with my team, so
>> you play with the prototype,
>> provide ideas, etc.? The same for all the readers.
>
> Because I thought the solutions had already been presented: static alloca=
tion
> and static deallocation at compile time. I don't see the need to have sep=
arate
> classes once those are present.
Are you talking about the static_alloc function we developed and
presented in this thread?
If so, then I already mentioned I didn't go into thinking the details
regarding same classes and separate classes.
I'll be delighted if somebody could address the library part of this
(since the 'core' part already is a hell of work),
and work on how to make the existing STL classes be ROM-friendly.
I don't expect to get into the full library part yet, though I
understand it's important to set the details of the
non-library part since the latter has to provide the means for the
former. That's I'm posting this here,
to seek for help.
Meanwhile, and since I have a real project with a ticking time, I will
implement basic static_ versions of the classes I need,
which fortunatelly don't need to interact with existing 3rd-party code :=3D=
)
>
>> Please keep this in mind: this addresses a very real life problem we
>> are currently solving. Specially for
>> embedded systems, and so-called IoT computers or other very small
>> hardware which RAM is really scarce,
>> and should not be wasted with things that could perfectly be stored in R=
OM.
>
> We have that for QString already, but we haven't solved the problem of st=
oring
> an actual QString in ROM. We've managed to store the QString's internal d=
ata
> in ROM, but not the actual object.
>
> See the QStringLiteral macro. We worked around the limitation of having s=
tatic
> data inside a constexpr function by moving it inside a lambda and making =
the
> function a macro instead. The solution is, simplified, something like:
>
> #define QStringLiteral(str) []() { \
> static const QStringData d =3D { u"" str }; \
> return QString(d); }()
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Tue, 18 Aug 2015 19:06:08 -0300
Raw View
On Tue, Aug 18, 2015 at 6:47 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Tuesday 18 August 2015 18:41:50 dgutson . wrote:
>> Why don't you join the effort and become a co-author with my team, so
>> you play with the prototype,
>> provide ideas, etc.? The same for all the readers.
>
> Because I thought the solutions had already been presented: static alloca=
tion
> and static deallocation at compile time. I don't see the need to have sep=
arate
> classes once those are present.
>
>> Please keep this in mind: this addresses a very real life problem we
>> are currently solving. Specially for
>> embedded systems, and so-called IoT computers or other very small
>> hardware which RAM is really scarce,
>> and should not be wasted with things that could perfectly be stored in R=
OM.
>
> We have that for QString already, but we haven't solved the problem of st=
oring
> an actual QString in ROM. We've managed to store the QString's internal d=
ata
> in ROM, but not the actual object.
>
> See the QStringLiteral macro. We worked around the limitation of having s=
tatic
> data inside a constexpr function by moving it inside a lambda and making =
the
> function a macro instead. The solution is, simplified, something like:
>
> #define QStringLiteral(str) []() { \
> static const QStringData d =3D { u"" str }; \
> return QString(d); }()
BTW, I suggest to focus on associative or more complex containers
rather than strings.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 18 Aug 2015 15:35:36 -0700
Raw View
On Tuesday 18 August 2015 18:59:35 dgutson . wrote:
> On Tue, Aug 18, 2015 at 6:47 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> > On Tuesday 18 August 2015 18:41:50 dgutson . wrote:
> >> Why don't you join the effort and become a co-author with my team, so
> >> you play with the prototype,
> >> provide ideas, etc.? The same for all the readers.
> >
> > Because I thought the solutions had already been presented: static
> > allocation and static deallocation at compile time. I don't see the need
> > to have separate classes once those are present.
>
> Are you talking about the static_alloc function we developed and
> presented in this thread?
Yes, though I would have preferred operator new, so I didn't have to write new
code for it.
> BTW, I suggest to focus on associative or more complex containers
> rather than strings.
Indeed. Arrays are "easy" because they have a single block. An associative
container often involves multiple allocations.
For a hashing table, for example, we'd also incur the problem of determining
the hashing function at compile time, something that isn't currently done for
security and performance reasons (we use a random seed and use the CRC32 CPU
instruction when available).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Wed, 19 Aug 2015 00:27:06 -0300
Raw View
--001a1140ad72f45b37051da19be2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 18/8/2015 19:35, "Thiago Macieira" <thiago@macieira.org> escribi=C3=B3:
>
> On Tuesday 18 August 2015 18:59:35 dgutson . wrote:
> > On Tue, Aug 18, 2015 at 6:47 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
> > > On Tuesday 18 August 2015 18:41:50 dgutson . wrote:
> > >> Why don't you join the effort and become a co-author with my team, s=
o
> > >> you play with the prototype,
> > >> provide ideas, etc.? The same for all the readers.
> > >
> > > Because I thought the solutions had already been presented: static
> > > allocation and static deallocation at compile time. I don't see the
need
> > > to have separate classes once those are present.
> >
> > Are you talking about the static_alloc function we developed and
> > presented in this thread?
>
> Yes, though I would have preferred operator new, so I didn't have to
write new
> code for it.
Please see my earlier post in this thread (the initial theorical version
had "new" but then we implemented something named different so we could
make the program ill formed when the context was not constexpr; OTOH, "new"
is valid in both contexts; just a matter of self requirements). I consider
this a point of decision (but not central and maybe worth to postpone).
>
> > BTW, I suggest to focus on associative or more complex containers
> > rather than strings.
>
> Indeed. Arrays are "easy" because they have a single block. An associativ=
e
> container often involves multiple allocations.
>
> For a hashing table, for example, we'd also incur the problem of
determining
> the hashing function at compile time, something that isn't currently done
for
> security and performance reasons (we use a random seed and use the CRC32
CPU
> instruction when available).
Right.
And I thought a little about the option that would make happy to us all:
turn current containers static-alloc friendly. I think that in order for
them to develop this double personality (or the personality disorder),
methods should be able to be overloaded by ("strong") constexpr, including
ctors, dtor (yes, two destructors) and other methods with something like
"CVC-qualifiers" (meaning const, volatile, const volatile, and strong
constexpr) with the usual name hiding rules (e.g. a strong constexpr ctor
hides the implicit constructors unless explicited). I still have to think
more about this and talk to my team to see if we could add this ability to
the compiler prototype by defining some mean to annotate "strongness" for
the constructor.
However, please understand that this extension fells beyond the project
requirements (in which adding our static version of some containers is
acceptable). I will look for some extra resources but that will take time.
I will have an update tomorrow.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1140ad72f45b37051da19be2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 18/8/2015 19:35, "Thiago Macieira" <<a href=3D"mailto:thiag=
o@macieira.org">thiago@macieira.org</a>> escribi=C3=B3:<br>
><br>
> On Tuesday 18 August 2015 18:59:35 dgutson . wrote:<br>
> > On Tue, Aug 18, 2015 at 6:47 PM, Thiago Macieira <<a href=3D"m=
ailto:thiago@macieira.org">thiago@macieira.org</a>><br>
> wrote:<br>
> > > On Tuesday 18 August 2015 18:41:50 dgutson . wrote:<br>
> > >> Why don't you join the effort and become a co-author=
with my team, so<br>
> > >> you play with the prototype,<br>
> > >> provide ideas, etc.? The same for all the readers.<br>
> > ><br>
> > > Because I thought the solutions had already been presented: =
static<br>
> > > allocation and static deallocation at compile time. I don=
9;t see the need<br>
> > > to have separate classes once those are present.<br>
> ><br>
> > Are you talking about the static_alloc function we developed and<=
br>
> > presented in this thread?<br>
><br>
> Yes, though I would have preferred operator new, so I didn't have =
to write new<br>
> code for it.</p>
<p dir=3D"ltr">Please see my earlier post in this thread (the initial theor=
ical version had "new" but then we implemented something named di=
fferent so we could make the program ill formed when the context was not co=
nstexpr; OTOH, "new" is valid in both contexts; just a matter of =
self requirements). I consider this a point of decision (but not central an=
d maybe worth to postpone).</p>
<p dir=3D"ltr">><br>
> > BTW, I suggest to focus on associative or more complex containers=
<br>
> > rather than strings.<br>
><br>
> Indeed. Arrays are "easy" because they have a single block. =
An associative<br>
> container often involves multiple allocations.<br>
><br>
> For a hashing table, for example, we'd also incur the problem of d=
etermining<br>
> the hashing function at compile time, something that isn't current=
ly done for<br>
> security and performance reasons (we use a random seed and use the CRC=
32 CPU<br>
> instruction when available).</p>
<p dir=3D"ltr">Right.</p>
<p dir=3D"ltr">And I thought a little about the option that would make happ=
y to us all: turn current containers static-alloc friendly. I think that in=
order for them to develop this double personality (or the personality diso=
rder), methods should be able to be overloaded by ("strong") cons=
texpr, including ctors, dtor (yes, two destructors) and other methods with =
something like "CVC-qualifiers" (meaning const, volatile, const v=
olatile, and strong constexpr) with the usual name hiding rules (e.g. a str=
ong constexpr ctor hides the implicit constructors unless explicited). I st=
ill have to think more about this and talk to my team to see if we could ad=
d this ability to the compiler prototype by defining some mean to annotate =
"strongness" for the constructor.<br>
However, please understand that this extension fells beyond the project req=
uirements (in which adding our static version of some containers is accepta=
ble). I will look for some extra resources but that will take time.<br>
I will have an update tomorrow.<br>
><br>
> --<br>
> Thiago Macieira - thiago (AT)<a href=3D"http://macieira.info"> macieir=
a.info</a> - thiago (AT)<a href=3D"http://kde.org"> kde.org</a><br>
> =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
> =C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
> =C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF=
4 5358<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to<a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"> std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to<a href=3D"mailto:std-proposals@is=
ocpp.org"> std-proposals@isocpp.org</a>.<br>
> Visit this group at<a href=3D"http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/"> http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1140ad72f45b37051da19be2--
.
Author: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
Date: Tue, 18 Aug 2015 20:32:46 -0700
Raw View
--001a11490428373054051da1b036
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 18, 2015 at 8:27 PM, dgutson . <danielgutson@gmail.com> wrote:
Please see my earlier post in this thread (the initial theorical version
> had "new" but then we implemented something named different so we could
> make the program ill formed when the context was not constexpr; OTOH, "new"
> is valid in both contexts; just a matter of self requirements). I consider
> this a point of decision (but not central and maybe worth to postpone).
>
Would the usual constexpr annotation of the variable holding the result not
serve this purpose? On the other hand, without a special allocator it
might be hard for the compiler to ensure it ends up in a read-only data
segment.
> And I thought a little about the option that would make happy to us all:
> turn current containers static-alloc friendly. I think that in order for
> them to develop this double personality (or the personality disorder),
> methods should be able to be overloaded by ("strong") constexpr, including
> ctors, dtor (yes, two destructors) and other methods with something like
> "CVC-qualifiers" (meaning const, volatile, const volatile, and strong
> constexpr) with the usual name hiding rules (e.g. a strong constexpr ctor
> hides the implicit constructors unless explicited). I still have to think
> more about this and talk to my team to see if we could add this ability to
> the compiler prototype by defining some mean to annotate "strongness" for
> the constructor.
>
This seems very useful as a general matter, but is there anything specific
about the current containers that would require it?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11490428373054051da1b036
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 18, 2015 at 8:27 PM, dgutson . <span dir=3D"ltr"><<a href=3D"mai=
lto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>>=
;</span> wrote:<br><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">
Please see my earlier post in this thread (the initial theorical version ha=
d "new" but then we implemented something named different so we c=
ould make the program ill formed when the context was not constexpr; OTOH, =
"new" is valid in both contexts; just a matter of self requiremen=
ts). I consider this a point of decision (but not central and maybe worth t=
o postpone).</p></blockquote><div>Would the usual constexpr annotation of t=
he variable holding the result not serve this purpose?=C2=A0 On the other h=
and, without a special allocator it might be hard for the compiler to ensur=
e it ends up in a read-only data segment.<br></div><div>=C2=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><p dir=3D"ltr">And I thought a little about the=
option that would make happy to us all: turn current containers static-all=
oc friendly. I think that in order for them to develop this double personal=
ity (or the personality disorder), methods should be able to be overloaded =
by ("strong") constexpr, including ctors, dtor (yes, two destruct=
ors) and other methods with something like "CVC-qualifiers" (mean=
ing const, volatile, const volatile, and strong constexpr) with the usual n=
ame hiding rules (e.g. a strong constexpr ctor hides the implicit construct=
ors unless explicited). I still have to think more about this and talk to m=
y team to see if we could add this ability to the compiler prototype by def=
ining some mean to annotate "strongness" for the constructor.<br>=
</p></blockquote><div>This seems very useful as a general matter, but is th=
ere anything specific about the current containers that would require it?<b=
r></div><div>=C2=A0<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11490428373054051da1b036--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Wed, 19 Aug 2015 00:36:26 -0300
Raw View
--001a1140f16e48f14a051da1bd49
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 19/8/2015 0:32, "Jeremy Maitin-Shepard" <jeremy@jeremyms.com> escribi=C3=
=B3:
>
> On Tue, Aug 18, 2015 at 8:27 PM, dgutson . <danielgutson@gmail.com> wrote=
:
>
>> Please see my earlier post in this thread (the initial theorical version
had "new" but then we implemented something named different so we could
make the program ill formed when the context was not constexpr; OTOH, "new"
is valid in both contexts; just a matter of self requirements). I consider
this a point of decision (but not central and maybe worth to postpone).
>
> Would the usual constexpr annotation of the variable holding the result
not serve this purpose? On the other hand, without a special allocator it
might be hard for the compiler to ensure it ends up in a read-only data
segment.
>
>>
>> And I thought a little about the option that would make happy to us all:
turn current containers static-alloc friendly. I think that in order for
them to develop this double personality (or the personality disorder),
methods should be able to be overloaded by ("strong") constexpr, including
ctors, dtor (yes, two destructors) and other methods with something like
"CVC-qualifiers" (meaning const, volatile, const volatile, and strong
constexpr) with the usual name hiding rules (e.g. a strong constexpr ctor
hides the implicit constructors unless explicited). I still have to think
more about this and talk to my team to see if we could add this ability to
the compiler prototype by defining some mean to annotate "strongness" for
the constructor.
>
> This seems very useful as a general matter, but is there anything
specific about the current containers that would require it?
Random sleepy thoughts. Sorry, you are right, I'm addressing it wrongly. I
should take the allocators path. I better go to sleep :)
Thanks.
>
>
> --
>
> ---
> 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.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1140f16e48f14a051da1bd49
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 19/8/2015 0:32, "Jeremy Maitin-Shepard" <<a href=3D"mailto:=
jeremy@jeremyms.com">jeremy@jeremyms.com</a>> escribi=C3=B3:<br>
><br>
> On Tue, Aug 18, 2015 at 8:27 PM, dgutson . <<a href=3D"mailto:danie=
lgutson@gmail.com">danielgutson@gmail.com</a>> wrote:<br>
><br>
>> Please see my earlier post in this thread (the initial theorical v=
ersion had "new" but then we implemented something named differen=
t so we could make the program ill formed when the context was not constexp=
r; OTOH, "new" is valid in both contexts; just a matter of self r=
equirements). I consider this a point of decision (but not central and mayb=
e worth to postpone).<br>
><br>
> Would the usual constexpr annotation of the variable holding the resul=
t not serve this purpose?=C2=A0 On the other hand, without a special alloca=
tor it might be hard for the compiler to ensure it ends up in a read-only d=
ata segment.<br>
> =C2=A0<br>
>><br>
>> And I thought a little about the option that would make happy to u=
s all: turn current containers static-alloc friendly. I think that in order=
for them to develop this double personality (or the personality disorder),=
methods should be able to be overloaded by ("strong") constexpr,=
including ctors, dtor (yes, two destructors) and other methods with someth=
ing like "CVC-qualifiers" (meaning const, volatile, const volatil=
e, and strong constexpr) with the usual name hiding rules (e.g. a strong co=
nstexpr ctor hides the implicit constructors unless explicited). I still ha=
ve to think more about this and talk to my team to see if we could add this=
ability to the compiler prototype by defining some mean to annotate "=
strongness" for the constructor.<br>
><br>
> This seems very useful as a general matter, but is there anything spec=
ific about the current containers that would require it?</p>
<p dir=3D"ltr">Random sleepy thoughts. Sorry, you are right, I'm addres=
sing it wrongly. I should take the allocators path. I better go to sleep :)=
<br>
Thanks.</p>
<p dir=3D"ltr">> =C2=A0<br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1140f16e48f14a051da1bd49--
.