------=_Part_396_1768110441.1444934531011
Content-Type: multipart/alternative;
 boundary="----=_Part_397_1151571664.1444934531012"

------=_Part_397_1151571664.1444934531012
Content-Type: text/plain; charset=UTF-8


I am looking for a standard way to handle code folding in my ide's. I think
its a great feature of the IDE, but unfortunately they all seem to
implement it differently.

Microsoft uses a #pragma region, netbeans uses // <editor-fold desc=Your
Section Name">.

I wish there was a way to have some STANDARD WAY to implement this, so my
code isn't a mess. I like the netbeans way, because its out of the picture
in a comment.

I know this isnt a c++ language specific, but would be nice to some how
make it available to force the ide of your choice to behave correctly.

I like to build my code on as many compilers as possible.

Just a thought!

--

---
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_397_1151571664.1444934531012
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>I am looking for a standard way to handle code folding=
 in my ide&#39;s. I think its a great feature of the IDE, but unfortunately=
 they all seem to implement it differently.<br><br>Microsoft uses a #pragma=
 region, netbeans uses // &lt;editor-fold desc=3DYour Section Name&quot;&gt=
;.<br><br>I wish there was a way to have some STANDARD WAY to implement thi=
s, so my code isn&#39;t a mess. I like the netbeans way, because its out of=
 the picture in a comment.<br><br>I know this isnt a c++ language specific,=
 but would be nice to some how make it available to force the ide of your c=
hoice to behave correctly.<br><br>I like to build my code on as many compil=
ers as possible. <br><br>Just a thought!<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&quot; 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_397_1151571664.1444934531012--
------=_Part_396_1768110441.1444934531011--

.

I don't think that this is something the language itself should be
concerned with.  Note that these features are only relevant if you want
to *edit* the code.  If you merely want to *compile* the code, they
should not be of any concern.  Different people have too different
requirements regarding their editors or IDEs.  This is a good thing and
enables competition between those tools without harming portability.
If you work on a project, you'll have to settle with your team on some
common coding standard.  How you group code into logical sections could
be one aspect (hopefully not the most important one) of such a standard.
Finally, it would be a fairly simple thing for IDE vendors to do to
teach their tool to recognize any number of grouping styles and let the
user choose one.  Maybe there isn't even one style that works best for
all of your coding?


fhemsing@gmail.com writes:

> I am looking for a standard way to handle code folding in my ide's. I
> think its a great feature of the IDE, but unfortunately they all seem
> to implement it differently.
>
> Microsoft uses a #pragma region, netbeans uses // <editor-fold
> desc=Your Section Name">.
>
> I wish there was a way to have some STANDARD WAY to implement this, so
> my code isn't a mess. I like the netbeans way, because its out of the
> picture in a comment.
>
> I know this isnt a c++ language specific, but would be nice to some
> how make it available to force the ide of your choice to behave
> correctly.
>
> I like to build my code on as many compilers as possible.
>
> Just a thought!
--
OpenPGP:

Public Key:   http://openpgp.klammler.eu
Fingerprint:  2732 DA32 C8D0 EEEC A081  BE9D CF6C 5166 F393 A9C0

--

---
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/.

.

On Thursday 15 October 2015 21:07:56 Moritz Klammler wrote:
> Finally, it would be a fairly simple thing for IDE vendors to do to
> teach their tool to recognize any number of grouping styles and let the
> user choose one.  Maybe there isn't even one style that works best for
> all of your coding?

Right.

The best way to do this is to file bug reports / suggestions to the multiple
tools so they begin to recognise the one-true-way of doing what you're asking.

That already exists for API documentation. Without help from the standard, the
/** */, /*! */ and /// comments are de-facto recognised as "this is API
Documentation".

--
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/.

.

On Thu, Oct 15, 2015 at 4:46 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Thursday 15 October 2015 21:07:56 Moritz Klammler wrote:
>> Finally, it would be a fairly simple thing for IDE vendors to do to
>> teach their tool to recognize any number of grouping styles and let the
>> user choose one.  Maybe there isn't even one style that works best for
>> all of your coding?
>
> Right.
>
> The best way to do this is to file bug reports / suggestions to the multi=
ple
> tools so they begin to recognise the one-true-way of doing what you're as=
king.
>
> That already exists for API documentation. Without help from the standard=
, the
> /** */, /*! */ and /// comments are de-facto recognised as "this is API
> Documentation".

But, maybe there's room for something interesting here.
If we assume for a moment that the code is usually more read than
written (and even compiled), then a mechanism to indirectly enable
this kind of features could be useful.
Such mechanism could be: (global namespace) and nesteable attributes.
For example, if we could allow

[[attribute1 { ]]

   [[attribute2 { ]]
   [[ } ]]

[[ } ]]

(sorry the horrible syntax, I'm in brainstorming mode)

then foldeable regions as the OP suggests could be implemented by
tools understanding nonstandard attributes, e.g. [[folding { ]].

This could even have more uses beyond IDEs, maybe denote regions for
off-load compilers.

  Daniel.

>
> --
> 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/.

.

On Friday 16 October 2015 20:36:44 dgutson . wrote:
> Such mechanism could be: (global namespace) and nesteable attributes.
> For example, if we could allow
>
> [[attribute1 { ]]
>
>    [[attribute2 { ]]
>    [[ } ]]
>
> [[ } ]]
>
> (sorry the horrible syntax, I'm in brainstorming mode)
>
> then foldeable regions as the OP suggests could be implemented by
> tools understanding nonstandard attributes, e.g. [[folding { ]].
>
> This could even have more uses beyond IDEs, maybe denote regions for
> off-load compilers.

I'd rather the compiler never have to see them, much less interpret.

All of those should be part of the comments and removed by the preprocessor
before anything else gets done.
--
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/.

.

On Fri, Oct 16, 2015 at 10:01 PM, Thiago Macieira <thiago@macieira.org> wro=
te:
> On Friday 16 October 2015 20:36:44 dgutson . wrote:
>> Such mechanism could be: (global namespace) and nesteable attributes.
>> For example, if we could allow
>>
>> [[attribute1 { ]]
>>
>>    [[attribute2 { ]]
>>    [[ } ]]
>>
>> [[ } ]]
>>
>> (sorry the horrible syntax, I'm in brainstorming mode)
>>
>> then foldeable regions as the OP suggests could be implemented by
>> tools understanding nonstandard attributes, e.g. [[folding { ]].
>>
>> This could even have more uses beyond IDEs, maybe denote regions for
>> off-load compilers.
>
> I'd rather the compiler never have to see them, much less interpret.
>
> All of those should be part of the comments and removed by the preprocess=
or
> before anything else gets done.

As I mentioned, this could be useful for cases where the compiler
matters. For those not familiar with offloading:
https://gcc.gnu.org/wiki/Offloading

> --
> 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/.

.

On Friday 16 October 2015 22:05:28 dgutson . wrote:
> > All of those should be part of the comments and removed by the
> > preprocessor
> > before anything else gets done.
>
> As I mentioned, this could be useful for cases where the compiler
> matters. For those not familiar with offloading:
> https://gcc.gnu.org/wiki/Offloading

I don't see how that is relevant to the topic at hand.
--
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/.

.

On Fri, Oct 16, 2015 at 11:08 PM, Thiago Macieira <thiago@macieira.org> wro=
te:
> On Friday 16 October 2015 22:05:28 dgutson . wrote:
>> > All of those should be part of the comments and removed by the
>> > preprocessor
>> > before anything else gets done.
>>
>> As I mentioned, this could be useful for cases where the compiler
>> matters. For those not familiar with offloading:
>> https://gcc.gnu.org/wiki/Offloading
>
> I don't see how that is relevant to the topic at hand.

I'm deliberately putting the cart before the horse, so I'm inventing.
Without having thinking too much, one could denote "regions" to
offload, or to be executed in different hardwares. There usually are
also linkage sections (gcc has the "section" attribute), so
programmers could group everything together in a region mapped to a
section; this is currently done per-symbol basis, but denoting regions
could help to get the code better organized and structured.
So organizing the code in (possibly overlapped and/or nested) regions
could have many uses, such as the one the OP asks for, and those I
comment.

> --
> 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/.

.

------=_Part_58_1964870888.1445055111887
Content-Type: multipart/alternative;
 boundary="----=_Part_59_173858471.1445055111887"

------=_Part_59_173858471.1445055111887
Content-Type: text/plain; charset=UTF-8



On Friday, October 16, 2015 at 11:24:10 PM UTC-4, dgutson wrote:
>
> On Fri, Oct 16, 2015 at 11:08 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
> > On Friday 16 October 2015 22:05:28 dgutson . wrote:
> >> > All of those should be part of the comments and removed by the
> >> > preprocessor
> >> > before anything else gets done.
> >>
> >> As I mentioned, this could be useful for cases where the compiler
> >> matters. For those not familiar with offloading:
> >> https://gcc.gnu.org/wiki/Offloading
> >
> > I don't see how that is relevant to the topic at hand.
>
> I'm deliberately putting the cart before the horse, so I'm inventing.
> Without having thinking too much, one could denote "regions" to
> offload, or to be executed in different hardwares. There usually are
> also linkage sections (gcc has the "section" attribute), so
> programmers could group everything together in a region mapped to a
> section; this is currently done per-symbol basis, but denoting regions
> could help to get the code better organized and structured.

So organizing the code in (possibly overlapped and/or nested) regions
> could have many uses, such as the one the OP asks for, and those I
> comment.
>

OK, so you have these tags which has no actual C++ behavior associated with
it. But compilers can decide to do different things with how code is
compiled and such.

Well... doesn't that make your code non-portable? Or at least, oddly
behaving? What happens if one compiler treats a region one way and another
compiler uses regions for something different? If there is no well-defined
C++ behavior attached, then compilers can choose to do anything.

So what good are the region tags?

Not to mention, what you're suggesting would better be done via modules.

--

---
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_59_173858471.1445055111887
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, October 16, 2015 at 11:24:10 PM UTC-4, dgutson wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Oct 16, 2015 at 11:08 PM,=
 Thiago Macieira &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"pE0hhzJgDwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">thi...@macieira.org</a>&gt; wrote:
<br>&gt; On Friday 16 October 2015 22:05:28 dgutson . wrote:
<br>&gt;&gt; &gt; All of those should be part of the comments and removed b=
y the
<br>&gt;&gt; &gt; preprocessor
<br>&gt;&gt; &gt; before anything else gets done.
<br>&gt;&gt;
<br>&gt;&gt; As I mentioned, this could be useful for cases where the compi=
ler
<br>&gt;&gt; matters. For those not familiar with offloading:
<br>&gt;&gt; <a href=3D"https://gcc.gnu.org/wiki/Offloading" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com=
/url?q\75https%3A%2F%2Fgcc.gnu.org%2Fwiki%2FOffloading\46sa\75D\46sntz\0751=
\46usg\75AFQjCNHMnGE9kiYQmKnt7kHg3RIufh_9kA&#39;;return true;" onclick=3D"t=
his.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgcc.gnu.org%2F=
wiki%2FOffloading\46sa\75D\46sntz\0751\46usg\75AFQjCNHMnGE9kiYQmKnt7kHg3RIu=
fh_9kA&#39;;return true;">https://gcc.gnu.org/wiki/<wbr>Offloading</a>
<br>&gt;
<br>&gt; I don&#39;t see how that is relevant to the topic at hand.
<br>
<br>I&#39;m deliberately putting the cart before the horse, so I&#39;m inve=
nting.
<br>Without having thinking too much, one could denote &quot;regions&quot; =
to
<br>offload, or to be executed in different hardwares. There usually are
<br>also linkage sections (gcc has the &quot;section&quot; attribute), so
<br>programmers could group everything together in a region mapped to a
<br>section; this is currently done per-symbol basis, but denoting regions
<br>could help to get the code better organized and structured.=C2=A0</bloc=
kquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So organizing the code =
in (possibly overlapped and/or nested) regions
<br>could have many uses, such as the one the OP asks for, and those I
<br>comment.
<br></blockquote><div><br>OK, so you have these tags which has no actual C+=
+ behavior associated with it. But compilers can decide to do different thi=
ngs with how code is compiled and such.<br><br>Well... doesn&#39;t that mak=
e your code non-portable? Or at least, oddly behaving? What happens if one =
compiler treats a region one way and another compiler uses regions for some=
thing different? If there is no well-defined C++ behavior attached, then co=
mpilers can choose to do anything.<br><br>So what good are the region tags?=
<br><br>Not to mention, what you&#39;re suggesting would better be done via=
 modules.<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&quot; 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_59_173858471.1445055111887--
------=_Part_58_1964870888.1445055111887--

.

On Sat, Oct 17, 2015 at 1:11 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Friday, October 16, 2015 at 11:24:10 PM UTC-4, dgutson wrote:
>>
>> On Fri, Oct 16, 2015 at 11:08 PM, Thiago Macieira <thi...@macieira.org>
>> wrote:
>> > On Friday 16 October 2015 22:05:28 dgutson . wrote:
>> >> > All of those should be part of the comments and removed by the
>> >> > preprocessor
>> >> > before anything else gets done.
>> >>
>> >> As I mentioned, this could be useful for cases where the compiler
>> >> matters. For those not familiar with offloading:
>> >> https://gcc.gnu.org/wiki/Offloading
>> >
>> > I don't see how that is relevant to the topic at hand.
>>
>> I'm deliberately putting the cart before the horse, so I'm inventing.
>> Without having thinking too much, one could denote "regions" to
>> offload, or to be executed in different hardwares. There usually are
>> also linkage sections (gcc has the "section" attribute), so
>> programmers could group everything together in a region mapped to a
>> section; this is currently done per-symbol basis, but denoting regions
>> could help to get the code better organized and structured.
>>
>> So organizing the code in (possibly overlapped and/or nested) regions
>> could have many uses, such as the one the OP asks for, and those I
>> comment.
>
>
> OK, so you have these tags which has no actual C++ behavior associated wi=
th
> it. But compilers can decide to do different things with how code is
> compiled and such.
>
> Well... doesn't that make your code non-portable? Or at least, oddly
> behaving? What happens if one compiler treats a region one way and anothe=
r
> compiler uses regions for something different? If there is no well-define=
d
> C++ behavior attached, then compilers can choose to do anything.

I gently disagree Nicol. I still think the tags *should be* safely
ignorable. Implementations should DTRT. At least these tags should be
defined (in the std) in such a way so behavior/semantic will not be
altered. Offloading currently preserve semantics. So these tags. It's
just a way to write things in a different way.

>
> So what good are the region tags?
>
> Not to mention, what you're suggesting would better be done via modules.

Hmmmmediumly granted. I think this has further possibilities. Modules
are organizative tools IIUC, whereas these tags may not only be useful
to organize code but to *help implementations* to organize the
generated code (or storage, or to command the linker).

>
> --
>
> ---
> 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/.

.

On Sat, Oct 17, 2015 at 1:18 AM, dgutson . <danielgutson@gmail.com> wrote:
> On Sat, Oct 17, 2015 at 1:11 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>
>> On Friday, October 16, 2015 at 11:24:10 PM UTC-4, dgutson wrote:
>>>
>>> On Fri, Oct 16, 2015 at 11:08 PM, Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>> > On Friday 16 October 2015 22:05:28 dgutson . wrote:
>>> >> > All of those should be part of the comments and removed by the
>>> >> > preprocessor
>>> >> > before anything else gets done.
>>> >>
>>> >> As I mentioned, this could be useful for cases where the compiler
>>> >> matters. For those not familiar with offloading:
>>> >> https://gcc.gnu.org/wiki/Offloading
>>> >
>>> > I don't see how that is relevant to the topic at hand.
>>>
>>> I'm deliberately putting the cart before the horse, so I'm inventing.
>>> Without having thinking too much, one could denote "regions" to
>>> offload, or to be executed in different hardwares. There usually are
>>> also linkage sections (gcc has the "section" attribute), so
>>> programmers could group everything together in a region mapped to a
>>> section; this is currently done per-symbol basis, but denoting regions
>>> could help to get the code better organized and structured.
>>>
>>> So organizing the code in (possibly overlapped and/or nested) regions
>>> could have many uses, such as the one the OP asks for, and those I
>>> comment.
>>
>>
>> OK, so you have these tags which has no actual C++ behavior associated w=
ith
>> it. But compilers can decide to do different things with how code is
>> compiled and such.
>>
>> Well... doesn't that make your code non-portable? Or at least, oddly
>> behaving? What happens if one compiler treats a region one way and anoth=
er
>> compiler uses regions for something different? If there is no well-defin=
ed
>> C++ behavior attached, then compilers can choose to do anything.
>
> I gently disagree Nicol. I still think the tags *should be* safely
> ignorable. Implementations should DTRT. At least these tags should be
> defined (in the std) in such a way so behavior/semantic will not be
> altered. Offloading currently preserve semantics. So these tags. It's
> just a way to write things in a different way.
>
>>
>> So what good are the region tags?
>>
>> Not to mention, what you're suggesting would better be done via modules.
>
> Hmmmmediumly granted. I think this has further possibilities. Modules
> are organizative tools IIUC, whereas these tags may not only be useful
> to organize code but to *help implementations* to organize the
> generated code (or storage, or to command the linker).

The same module could have regions inside it.
(I assume that module also can be hierarchical anyway).

>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>
>
>
> --
> 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
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/.

.

On Sat, Oct 17, 2015 at 1:19 AM, dgutson . <danielgutson@gmail.com> wrote:
> On Sat, Oct 17, 2015 at 1:18 AM, dgutson . <danielgutson@gmail.com> wrote=
:
>> On Sat, Oct 17, 2015 at 1:11 AM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>>>
>>>
>>> On Friday, October 16, 2015 at 11:24:10 PM UTC-4, dgutson wrote:
>>>>
>>>> On Fri, Oct 16, 2015 at 11:08 PM, Thiago Macieira <thi...@macieira.org=
>
>>>> wrote:
>>>> > On Friday 16 October 2015 22:05:28 dgutson . wrote:
>>>> >> > All of those should be part of the comments and removed by the
>>>> >> > preprocessor
>>>> >> > before anything else gets done.
>>>> >>
>>>> >> As I mentioned, this could be useful for cases where the compiler
>>>> >> matters. For those not familiar with offloading:
>>>> >> https://gcc.gnu.org/wiki/Offloading
>>>> >
>>>> > I don't see how that is relevant to the topic at hand.
>>>>
>>>> I'm deliberately putting the cart before the horse, so I'm inventing.
>>>> Without having thinking too much, one could denote "regions" to
>>>> offload, or to be executed in different hardwares. There usually are
>>>> also linkage sections (gcc has the "section" attribute), so
>>>> programmers could group everything together in a region mapped to a
>>>> section; this is currently done per-symbol basis, but denoting regions
>>>> could help to get the code better organized and structured.
>>>>
>>>> So organizing the code in (possibly overlapped and/or nested) regions
>>>> could have many uses, such as the one the OP asks for, and those I
>>>> comment.
>>>
>>>
>>> OK, so you have these tags which has no actual C++ behavior associated =
with
>>> it. But compilers can decide to do different things with how code is
>>> compiled and such.
>>>
>>> Well... doesn't that make your code non-portable? Or at least, oddly
>>> behaving? What happens if one compiler treats a region one way and anot=
her
>>> compiler uses regions for something different? If there is no well-defi=
ned
>>> C++ behavior attached, then compilers can choose to do anything.
>>
>> I gently disagree Nicol. I still think the tags *should be* safely
>> ignorable. Implementations should DTRT. At least these tags should be
>> defined (in the std) in such a way so behavior/semantic will not be
>> altered. Offloading currently preserve semantics. So these tags. It's
>> just a way to write things in a different way.
>>
>>>
>>> So what good are the region tags?
>>>
>>> Not to mention, what you're suggesting would better be done via modules=
..
>>
>> Hmmmmediumly granted. I think this has further possibilities. Modules
>> are organizative tools IIUC, whereas these tags may not only be useful
>> to organize code but to *help implementations* to organize the
>> generated code (or storage, or to command the linker).
>
> The same module could have regions inside it.
> (I assume that module also can be hierarchical anyway).

(sorry I self comment).
Modules is organization in one-dimension, whereas tags can overlap organiza=
tion:

[[region_for_reasonX { ]]
[[region_for_reaonsY { ]]
     [[ } region_for_reasonX ]]
     [[ } region_for_reasonY ]]



>
>>
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Grou=
ps
>>> "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/.
>>
>>
>>
>> --
>> 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?
>
>
>
> --
> 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
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/.

.