------=_Part_10451_1297585853.1518998252931
Content-Type: multipart/alternative;
 boundary="----=_Part_10452_769302921.1518998252932"

------=_Part_10452_769302921.1518998252932
Content-Type: text/plain; charset="UTF-8"

Hi everyone

It's bad practice to put using namespace statements in header files.
But I see people trying to do that from time to time.

Why not extend using so that it can be restricted to file scope.

i.e. change this:

//test.h
#include <vector>
using namespace std;

//test.cpp
#include "test.h"
int main()
{
    vector<int> v; // OK
}

To this:

//test.h
#include <vector>
using restrict namespace std; // Don't let this using 'escape'.

//test.cpp
#include "test.h"
int main()
{
    vector<int> v; // ERROR std?
}

So the idea is that applying restrict (or some other keyword) to using will
prevent the using declaration leaving file scope.

With the advent of header only libraries, maybe this would help some code
bases.
Perhaps modules makes this feature redundant, I'm not sure.

I imagine this could be achieved other ways, such as unusing.

What do you think of the idea?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c5e64ff-b89b-4c02-9cd2-a443d65bf3fc%40isocpp.org.

------=_Part_10452_769302921.1518998252932
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi everyone</div><div><br></div><div>It&#39;s bad pra=
ctice to put using namespace statements in header files.</div><div>But I se=
e people trying to do that from time to time.</div><div><br></div><div>Why =
not extend using so that it can be restricted to file scope.</div><div><br>=
</div><div>i.e. change this:</div><div><br></div><div>//test.h</div><div>#i=
nclude &lt;vector&gt;<br>using namespace std;<br></div><div><br></div><div>=
//test.cpp</div><div>#include &quot;test.h&quot;</div><div>int main()<br>{<=
br>=C2=A0=C2=A0=C2=A0 vector&lt;int&gt; v; // OK<br>}</div><div><br></div><=
div>To this:</div><div><br></div><div><div>//test.h</div><div>#include &lt;=
vector&gt;<br>using restrict namespace std; // Don&#39;t let this using &#3=
9;escape&#39;.<br></div><div><br></div><div>//test.cpp</div><div>#include &=
quot;test.h&quot;</div><div>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 vector&lt=
;int&gt; v; // ERROR std?<br>}</div><div><br></div><div>So=C2=A0the idea is=
 that applying restrict (or some other keyword) to using will prevent the u=
sing declaration leaving file scope.</div><div><br></div><div>With the adve=
nt of header only libraries, maybe this would help some code bases.</div><d=
iv>Perhaps modules makes this feature redundant, I&#39;m not sure.</div><di=
v><br></div><div>I imagine this could be achieved other ways, such as unusi=
ng.</div><div><br></div><div>What do you think of the idea?<br></div></div>=
</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7c5e64ff-b89b-4c02-9cd2-a443d65bf3fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7c5e64ff-b89b-4c02-9cd2-a443d65bf3fc=
%40isocpp.org</a>.<br />

------=_Part_10452_769302921.1518998252932--

------=_Part_10451_1297585853.1518998252931--

.

On 19 February 2018 at 01:57,  <gmisocpp@gmail.com> wrote:
> Hi everyone
>
> It's bad practice to put using namespace statements in header files.
> But I see people trying to do that from time to time.
>
> Why not extend using so that it can be restricted to file scope.
>
> i.e. change this:
>
> //test.h
> #include <vector>
> using namespace std;
>
> //test.cpp
> #include "test.h"
> int main()
> {
>     vector<int> v; // OK
> }
>
> To this:
>
> //test.h
> #include <vector>
> using restrict namespace std; // Don't let this using 'escape'.
>
> //test.cpp
> #include "test.h"
> int main()
> {
>     vector<int> v; // ERROR std?
> }
>
> So the idea is that applying restrict (or some other keyword) to using will
> prevent the using declaration leaving file scope.
>
> With the advent of header only libraries, maybe this would help some code
> bases.
> Perhaps modules makes this feature redundant, I'm not sure.
>
> I imagine this could be achieved other ways, such as unusing.
>
> What do you think of the idea?


Do I need it if I have modules? The idea of 'not using namespace std;'
has popped up, recently. That doesn't necessarily
mean it'll become anything concrete.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb4FCruR-VLmt64vmebs88FdnAAdT44FPC20Ar4gR8iFQ%40mail.gmail.com.

.

On Sunday, 18 February 2018 15:57:32 PST gmisocpp@gmail.com wrote:
> Why not extend using so that it can be restricted to file scope.

What should this do in case you pass preprocessed sources to the compiler?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3492643.pGYcYKvI9B%40tjmaciei-mobl1.

.

------=_Part_5622_523503475.1519004345549
Content-Type: multipart/alternative;
 boundary="----=_Part_5623_1257169224.1519004345549"

------=_Part_5623_1257169224.1519004345549
Content-Type: text/plain; charset="UTF-8"

I'm not clear how  pre-processing effects my idea?
But if it does, as I'm not a compiler or tool vendor, maybe one of those
people can suggest something that would enable the idea to work.
They might need to see sufficient interest in the idea first before they
bother to suggest something though.
Does the idea interest you if issues like you mention can be solved in a
sufficiently simple manner?

On Monday, February 19, 2018 at 1:45:07 PM UTC+13, Thiago Macieira wrote:

> On Sunday, 18 February 2018 15:57:32 PST gmis...@gmail.com <javascript:>
> wrote:
> > Why not extend using so that it can be restricted to file scope.
>
> What should this do in case you pass preprocessed sources to the compiler?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1a58e9d4-cd31-4f83-9b1b-9e9d223b486a%40isocpp.org.

------=_Part_5623_1257169224.1519004345549
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m not clear how =C2=A0pre-processing=C2=A0effec=
ts my idea?</div><div>But if it does,=C2=A0as I&#39;m not a compiler or too=
l vendor, maybe one of those people can suggest something that would enable=
 the idea to work.</div><div>They might need=C2=A0to see=C2=A0sufficient in=
terest in the idea first before they bother to suggest something though.</d=
iv><div>Does the=C2=A0idea interest you if=C2=A0issues like you mention can=
 be solved in a sufficiently simple manner?</div><div><br>On Monday, Februa=
ry 19, 2018 at 1:45:07 PM UTC+13, Thiago Macieira wrote:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;">On Sunday, 18 February 2018 15:57:32 PST <a onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;" href=3D"javascript:" target=3D"_blank" rel=
=3D"nofollow" gdf-obfuscated-mailto=3D"tTJIvXTQBwAJ">gmis...@gmail.com</a> =
wrote:
<br>&gt; Why not extend using so that it can be restricted to file scope.
<br>
<br>What should this do in case you pass preprocessed sources to the compil=
er?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1a58e9d4-cd31-4f83-9b1b-9e9d223b486a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1a58e9d4-cd31-4f83-9b1b-9e9d223b486a=
%40isocpp.org</a>.<br />

------=_Part_5623_1257169224.1519004345549--

------=_Part_5622_523503475.1519004345549--

.

------=_Part_10649_1546098051.1519005712871
Content-Type: multipart/alternative;
 boundary="----=_Part_10650_1759215893.1519005712871"

------=_Part_10650_1759215893.1519005712871
Content-Type: text/plain; charset="UTF-8"

If I am correct at the problem you might be getting at, it's typically the
compiler itself that creates (and ingests) the pre-processed output so
it can inject a not using namespace std; directive or whatever etc. (or
whatever) it likes to get the result expected in the resulting files.
I'm responding here though only to get a clear understanding of the
problem. I'm not really trying to propose a solution to whatever problem
you see. A compiler vendor would be better at proposing a solution than me
once it's clear what the problem statement is.

On Monday, February 19, 2018 at 1:45:07 PM UTC+13, Thiago Macieira wrote:

> On Sunday, 18 February 2018 15:57:32 PST gmis...@gmail.com <javascript:>
> wrote:
> > Why not extend using so that it can be restricted to file scope.
>
> What should this do in case you pass preprocessed sources to the compiler?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d1943e9-8388-4e37-b7f7-37ddaaa6708d%40isocpp.org.

------=_Part_10650_1759215893.1519005712871
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>If I am correct at the problem you might be getting a=
t, it&#39;s typically the compiler itself that creates (and ingests) the=C2=
=A0pre-processed output so it=C2=A0can inject a not using=C2=A0namespace st=
d;=C2=A0directive or whatever etc. (or whatever) it likes to get the result=
 expected in the resulting=C2=A0files.</div><div>I&#39;m responding=C2=A0he=
re though only to get a clear understanding of the problem. I&#39;m not rea=
lly trying to propose a solution to whatever problem you see. A compiler ve=
ndor would be better at proposing a solution=C2=A0than me once it&#39;s cle=
ar what the problem statement is.</div><div>=C2=A0<br>On Monday, February 1=
9, 2018 at 1:45:07 PM UTC+13, Thiago Macieira wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">On Sunday, 18 February 2018 15:57:32 PST <a onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"n=
ofollow" gdf-obfuscated-mailto=3D"tTJIvXTQBwAJ">gmis...@gmail.com</a> wrote=
:
<br>&gt; Why not extend using so that it can be restricted to file scope.
<br>
<br>What should this do in case you pass preprocessed sources to the compil=
er?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2d1943e9-8388-4e37-b7f7-37ddaaa6708d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2d1943e9-8388-4e37-b7f7-37ddaaa6708d=
%40isocpp.org</a>.<br />

------=_Part_10650_1759215893.1519005712871--

------=_Part_10649_1546098051.1519005712871--

.

On Sunday, 18 February 2018 17:39:05 PST gmisocpp@gmail.com wrote:
> I'm not clear how  pre-processing effects my idea?

And therein lies the problem. Please try it. Take a .cpp file that #includes a
header and run it with the compiler's -E option. You'll see the preprocessed
output.

> But if it does, as I'm not a compiler or tool vendor, maybe one of those
> people can suggest something that would enable the idea to work.

My suggestion is that you don't make it file-level, but make a scope.

using namespace std;

becomes:

using namespace std {
 // it's used here
}

> They might need to see sufficient interest in the idea first before they
> bother to suggest something though.
> Does the idea interest you if issues like you mention can be solved in a
> sufficiently simple manner?

Not at all.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2513359.UccB5IGSa6%40tjmaciei-mobl1.

.

--=-Uzy1fMD8WzQEeQwa/SlT
Content-Type: text/plain; charset="UTF-8"

On Sun, 2018-02-18 at 15:57 -0800, gmisocpp@gmail.com wrote:
> Hi everyone
>
> It's bad practice to put using namespace statements in header files.
> But I see people trying to do that from time to time.
>
> Why not extend using so that it can be restricted to file scope.
>
> i.e. change this:
>
> //test.h
> #include <vector>
> using namespace std;
>
> //test.cpp
> #include "test.h"
> int main()
> {
>     vector<int> v; // OK
> }
>

So far, in my view, you are expressing a common problem for which it
would be nice to have a standardised solution.


> To this:
>
> //test.h
> #include <vector>
> using restrict namespace std; // Don't let this using 'escape'.
>
> //test.cpp
> #include "test.h"
> int main()
> {
>     vector<int> v; // ERROR std?
> }
>

The problem here is that as things stand, the compiler has no idea
whether code came from an included header file or not. In order to
implement this, there would need to be a degree of c++ syntax parsing
going on in the pre-processor. This is problematic because the
preprocessor is language-agnositc. Of course it's not impossible to
combine the preprocessor and compiler, but that's a massive change and
I suspect would break a great many projects.

> using namespace std {

That sounds like a very nice solution.

So far, the workaround I have settled on in my own code is something
like this:

mylib/config.hpp:
#include <cstddef>
namespace mylib
{
    using namespace std;
}

mylib/thing.hpp:
#include "config.hpp"
namespace mylib {
  // use mylib and std namespaces interchangeably here
}

mylib/thing.cpp:
#include <mylib/thing.hpp>

using namespace mylib;

// now have access to mylib and std namespaces

....

Caveats about the very concept of performing `using namespace std` of
course still apply...

R

> So the idea is that applying restrict (or some other keyword) to
> using will prevent the using declaration leaving file scope.
>
> With the advent of header only libraries, maybe this would help some
> code bases.
> Perhaps modules makes this feature redundant, I'm not sure.
>
> I imagine this could be achieved other ways, such as unusing.
>
> What do you think of the idea?
> --
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/7c5e64ff-b89b-4c02-9cd2-
> a443d65bf3fc%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1519028221.39017.12.camel%40gmail.com.

--=-Uzy1fMD8WzQEeQwa/SlT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE3RJb20ryY2ALx0Tw6HZ1IvK3CgsFAlqKh/0ACgkQ6HZ1IvK3
CgvjKBAApxrZqJJHygRANtSBswPaENqyaKnTVodesyPJKmGxRxtqmM74Ic4sm8hK
hYmBMht+Tht3JQYpQU3Kublty9Z7zkjEaHLydmEifM8xiiZENkzEjlVVL9wJxDjC
oyD9zx/f4SuLPwoNG0rk/17Kcjt5xmDjJfNem5+OMv0U/1wUAAMjytU8FJ45QBgu
07g6G1Rraa2JOjG2FDi9kVlt8AJi4EObJUpbOF6aKOwFvUVz+l/xN6Xig7Tyhowm
5HK+0kqR3MAc0qXES0U9HtdByUDFkO50quYxOD12AEXtjTu0GTvU8rfovPOerxfJ
Tb1yew1Wug0qtFK3+cbYjmUrG6CrYI/pSaYffkIK5V+CIgB3UKE6YT2LH/YE/KJ6
FIIYAyhTdgcpnDdYToVdV0pLRbjDaMLbdP5TK8EAUslWxZQ+LlsiGWqnYF3Zg3c3
wGvcNx9R5nIz6BXN16J/qLB09vZ70zsUZw6+g0v2wkpIrYjvmeRzyOQ57hchVRQi
VCWg/CgrBw8oZokQpdPVM48z3DLwzCl3vnu0vxU3xi06RVU5VbV9EYLsfhZJqu9R
MXilVO38GLsB2ijlMKwKdklqctcwx960lMtl/cRsUGLx6zgRLUwrmB66AEmyFy6f
TBfyfpMdCsw24vZ25IyOVovJnBktmU8iHv7bTX8Nnj+2HDredj8=
=jDEd
-----END PGP SIGNATURE-----

--=-Uzy1fMD8WzQEeQwa/SlT--


.

------=_Part_12229_1999397442.1519044122463
Content-Type: multipart/alternative;
 boundary="----=_Part_12230_533237654.1519044122463"

------=_Part_12230_533237654.1519044122463
Content-Type: text/plain; charset="UTF-8"


>
> So far, in my view, you are expressing a common problem for which it
> would be nice to have a standardised solution.
>

Thanks, glad you see it that way.


>
> The problem here is that as things stand, the compiler has no idea
> whether code came from an included header file or not. In order to
> implement this, there would need to be a degree of c++ syntax parsing
> going on in the pre-processor. This is problematic because the
> preprocessor is language-agnositc. Of course it's not impossible to
> combine the preprocessor and compiler, but that's a massive change and
> I suspect would break a great many projects.
>
>
I'm not sure what this problem is or if I am I'm not sure why my prior
answer to Thiago doesn't satisfy that concern.
He didn't address that part of my reply to him. And you didn't mention it
either.

What I said was that if the compiler creates the pre-processed output that
Thiago and yourself seem concerned about,.
I don't see why that compiler can't inject statements into that
pre-processed output that mark where the file scope ends.
The compiler already appears to mark this point anyway.
And then when it processes the pre-processed output which it created
earlier, it can undo the namespace at that appropriate point.

Perhaps Richard Smith or someone can offer an opinion on the solution to
the problem Thiago and yourself might be referring to if my solution
doesn't cut it.

But I'm glad you think this feature might be worth having subject to if it
can be implemented simply enough.

By the way, personally (I think) I prefer a using restrict X; over a using
namespace X { } scoped type construct.
Because in my version, with:
using restrict X;
#include "whatever"
"whatever" is not exposed to X. If "whatever" needs X, a regular using
would do that.
I'd rather not indent my code or have lots of closing braces and have to
match that all up which might happen, especially if there's a few using's
going on.
If X is needed in the file, let it be for the whole file even if that's
more than is technically needed.
But if people prefer using namespace X { } I'm ok with that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06cb59d7-7304-405a-8fbe-684a924281d5%40isocpp.org.

------=_Part_12230_533237654.1519044122463
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;">So far, in my view, you are e=
xpressing a common problem for which it
<br>would be nice to have a standardised solution.
<br></blockquote><div><br></div><div>Thanks, glad=C2=A0you see it that way.=
=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;">
<br>
<br>The problem here is that as things stand, the compiler has no idea
<br>whether code came from an included header file or not. In order to
<br>implement this, there would need to be a degree of c++ syntax parsing
<br>going on in the pre-processor. This is problematic because the
<br>preprocessor is language-agnositc. Of course it&#39;s not impossible to
<br>combine the preprocessor and compiler, but that&#39;s a massive change =
and
<br>I suspect would break a great many projects.
<br>
<br></blockquote><div><br></div><div>I&#39;m not sure=C2=A0what this proble=
m is or if I am I&#39;m not sure why my prior answer to Thiago doesn&#39;t =
satisfy that concern.</div><div>He didn&#39;t address that part of my reply=
 to him. And you didn&#39;t mention it either.</div><div><br></div><div>Wha=
t I said was that if the compiler creates the pre-processed output that Thi=
ago and yourself=C2=A0seem concerned about,.</div><div>I don&#39;t see why =
that compiler can&#39;t inject statements into that pre-processed output th=
at mark where the file scope ends.</div><div>The compiler already appears t=
o mark this point anyway.</div><div><div>And then when it=C2=A0processes th=
e=C2=A0pre-processed output which it created earlier, it can undo the names=
pace at that appropriate point.</div><div><br></div></div><div><div>Perhaps=
 Richard Smith or someone can offer an opinion on the solution to the probl=
em Thiago and yourself might be referring to if my solution doesn&#39;t cut=
 it.</div><div><br></div>But I&#39;m=C2=A0glad you think this feature might=
 be worth having subject to if it can be implemented simply enough.</div><d=
iv><br></div><div>By the way, personally (I think) I prefer=C2=A0a using re=
strict X; over a using namespace X { } scoped type construct.</div><div>Bec=
ause in my version, with:</div><div>using restrict X;</div><div>#include &q=
uot;whatever&quot;</div><div>&quot;whatever&quot;=C2=A0is not exposed to X.=
 If &quot;whatever&quot; needs X, a regular using would do that.</div><div>=
<div>I&#39;d rather not indent my code or have lots of=C2=A0closing braces =
and have to match that all up=C2=A0which might happen, especially=C2=A0if t=
here&#39;s a few using&#39;s going on.</div><div><div>If X is needed in the=
 file, let it be for the whole file even if that&#39;s more than is technic=
ally needed.</div>But if people prefer using namespace X { } I&#39;m ok wit=
h that.</div></div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/06cb59d7-7304-405a-8fbe-684a924281d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06cb59d7-7304-405a-8fbe-684a924281d5=
%40isocpp.org</a>.<br />

------=_Part_12230_533237654.1519044122463--

------=_Part_12229_1999397442.1519044122463--

.

--089e08200684eff6c605659168fc
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 19, 2018 at 9:17 AM, Richard Hodges <hodges.r@gmail.com> wrote:

> The problem here is that as things stand, the compiler has no idea
whether code came from an included header file or not.

Per the letter of the standard, that is. In practice compilers need to (and
do) know where code came from to issue understandable diagnostics.

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2ureXMWXp8u4gwWN39K-E7ka38gnwvarQMsoQH1Fqw%3DA%40mail.gmail.com.

--089e08200684eff6c605659168fc
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 M=
on, Feb 19, 2018 at 9:17 AM, Richard Hodges <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&gt;=
</span> wrote:<br><div><br></div><div>&gt; The problem here is that as thin=
gs stand, the compiler has no idea whether code came from an included heade=
r file or not.</div><div><br></div><div>Per the letter of the standard, tha=
t is. In practice compilers need to (and do) know where code came from to i=
ssue understandable diagnostics.</div><div><br></div><div>Cheers,</div><div=
>V.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2ureXMWXp8u4gwWN39K-E7ka38gnwv=
arQMsoQH1Fqw%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2ureXMWX=
p8u4gwWN39K-E7ka38gnwvarQMsoQH1Fqw%3DA%40mail.gmail.com</a>.<br />

--089e08200684eff6c605659168fc--

.

------=_Part_12844_545247208.1519056144909
Content-Type: multipart/alternative;
 boundary="----=_Part_12845_458053908.1519056144909"

------=_Part_12845_458053908.1519056144909
Content-Type: text/plain; charset="UTF-8"

On Monday, February 19, 2018 at 7:42:02 AM UTC-5, gmis...@gmail.com wrote:
>
> So far, in my view, you are expressing a common problem for which it
>> would be nice to have a standardised solution.
>>
>
> Thanks, glad you see it that way.
>
>
>>
>> The problem here is that as things stand, the compiler has no idea
>> whether code came from an included header file or not. In order to
>> implement this, there would need to be a degree of c++ syntax parsing
>> going on in the pre-processor. This is problematic because the
>> preprocessor is language-agnositc. Of course it's not impossible to
>> combine the preprocessor and compiler, but that's a massive change and
>> I suspect would break a great many projects.
>>
>>
> I'm not sure what this problem is or if I am I'm not sure why my prior
> answer to Thiago doesn't satisfy that concern.
> He didn't address that part of my reply to him. And you didn't mention it
> either.
>
> What I said was that if the compiler creates the pre-processed output that
> Thiago and yourself seem concerned about,.
> I don't see why that compiler can't inject statements into that
> pre-processed output that mark where the file scope ends.
> The compiler already appears to mark this point anyway.
> And then when it processes the pre-processed output which it created
> earlier, it can undo the namespace at that appropriate point.
>
> Perhaps Richard Smith or someone can offer an opinion on the solution to
> the problem Thiago and yourself might be referring to if my solution
> doesn't cut it.
>
> But I'm glad you think this feature might be worth having subject to if it
> can be implemented simply enough.
>
> By the way, personally (I think) I prefer a using restrict X; over a using
> namespace X { } scoped type construct.
> Because in my version, with:
> using restrict X;
> #include "whatever"
> "whatever" is not exposed to X. If "whatever" needs X, a regular using
> would do that.
>

At this point, it's clear that what you're asking for is *modules*. You
want to make #include work the way `import` does. Well... why do you think
we want `import` to begin with?

Just use the proper C++ solution, and you'll be fine.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/578aaedf-3e18-4a4e-a0a2-969555d0a9ba%40isocpp.org.

------=_Part_12845_458053908.1519056144909
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, February 19, 2018 at 7:42:02 AM UTC-5, gmis...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padd=
ing-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;borde=
r-left-style:solid">So far, in my view, you are expressing a common problem=
 for which it
<br>would be nice to have a standardised solution.
<br></blockquote><div><br></div><div>Thanks, glad=C2=A0you see it that way.=
=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bor=
der-left-width:1px;border-left-style:solid">
<br>
<br>The problem here is that as things stand, the compiler has no idea
<br>whether code came from an included header file or not. In order to
<br>implement this, there would need to be a degree of c++ syntax parsing
<br>going on in the pre-processor. This is problematic because the
<br>preprocessor is language-agnositc. Of course it&#39;s not impossible to
<br>combine the preprocessor and compiler, but that&#39;s a massive change =
and
<br>I suspect would break a great many projects.
<br>
<br></blockquote><div><br></div><div>I&#39;m not sure=C2=A0what this proble=
m is or if I am I&#39;m not sure why my prior answer to Thiago doesn&#39;t =
satisfy that concern.</div><div>He didn&#39;t address that part of my reply=
 to him. And you didn&#39;t mention it either.</div><div><br></div><div>Wha=
t I said was that if the compiler creates the pre-processed output that Thi=
ago and yourself=C2=A0seem concerned about,.</div><div>I don&#39;t see why =
that compiler can&#39;t inject statements into that pre-processed output th=
at mark where the file scope ends.</div><div>The compiler already appears t=
o mark this point anyway.</div><div><div>And then when it=C2=A0processes th=
e=C2=A0pre-processed output which it created earlier, it can undo the names=
pace at that appropriate point.</div><div><br></div></div><div><div>Perhaps=
 Richard Smith or someone can offer an opinion on the solution to the probl=
em Thiago and yourself might be referring to if my solution doesn&#39;t cut=
 it.</div><div><br></div>But I&#39;m=C2=A0glad you think this feature might=
 be worth having subject to if it can be implemented simply enough.</div><d=
iv><br></div><div>By the way, personally (I think) I prefer=C2=A0a using re=
strict X; over a using namespace X { } scoped type construct.</div><div>Bec=
ause in my version, with:</div><div>using restrict X;</div><div>#include &q=
uot;whatever&quot;</div><div>&quot;whatever&quot;=C2=A0is not exposed to X.=
 If &quot;whatever&quot; needs X, a regular using would do that.</div></div=
></blockquote><div><br>At this point, it&#39;s clear that what you&#39;re a=
sking for is <i>modules</i>. You want to make #include work the way `import=
` does. Well... why do you think we want `import` to begin with?<br><br>Jus=
t use the proper C++ solution, and you&#39;ll be fine.</div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/578aaedf-3e18-4a4e-a0a2-969555d0a9ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/578aaedf-3e18-4a4e-a0a2-969555d0a9ba=
%40isocpp.org</a>.<br />

------=_Part_12845_458053908.1519056144909--

------=_Part_12844_545247208.1519056144909--

.

--=-/oNzOPgEouPf9JWbOc66
Content-Type: text/plain; charset="UTF-8"

On Mon, 2018-02-19 at 04:42 -0800, gmisocpp@gmail.com wrote:
> > So far, in my view, you are expressing a common problem for which
> > it
> > would be nice to have a standardised solution.
>
> Thanks, glad you see it that way.
>
> >
> > The problem here is that as things stand, the compiler has no idea
> > whether code came from an included header file or not. In order to
> > implement this, there would need to be a degree of c++ syntax
> > parsing
> > going on in the pre-processor. This is problematic because the
> > preprocessor is language-agnositc. Of course it's not impossible
> > to
> > combine the preprocessor and compiler, but that's a massive change
> > and
> > I suspect would break a great many projects.
> >
>
> I'm not sure what this problem is or if I am I'm not sure why my
> prior answer to Thiago doesn't satisfy that concern.
> He didn't address that part of my reply to him. And you didn't
> mention it either.
>
> What I said was that if the compiler creates the pre-processed output
> that Thiago and yourself seem concerned about,.
> I don't see why that compiler can't inject statements into that pre-
> processed output that mark where the file scope ends.
> The compiler already appears to mark this point anyway.
> And then when it processes the pre-processed output which it created
> earlier, it can undo the namespace at that appropriate point.

The initial perception of there being a problem comes from the fact
that pre-processing is a separate (and indeed, un-necessary) step when
compiling.
In c++ there are no such things as "header files". There are merely
"compilation units", which themselves need not even be in a file.

In the c++ langauge there is no such thing as #include or #if. These
are pre-processor instructions, used to generate a compilation unit,
which is then passed to the compiler.

Note that often, "passed to the compiler" often does not involve a
file. It's quite common for the pre-processed compilation unit source
to be passed to the compiler through a pipe.

In order to implement what you suggest, there would first need to be a
requirement in the pre-processor that it generate markers in the pre-
processed source in order to tell the compiler where "header file
breaks" are. Then the compiler would need to be modified to notice
these markers and action your namespace proposal in response.

Remember that the pre-processor is the same one that is used for all
kinds of languages and utilities (inclusing but not limited to C and
objective-C).

This is starting to look like a can of worms.

And as Ville mentioned, we will (hopefully) soon have modules, which
obsoletes the entire enterprise.

R


>
> Perhaps Richard Smith or someone can offer an opinion on the solution
> to the problem Thiago and yourself might be referring to if my
> solution doesn't cut it.
>
> But I'm glad you think this feature might be worth having subject to
> if it can be implemented simply enough.
>
> By the way, personally (I think) I prefer a using restrict X; over a
> using namespace X { } scoped type construct.
> Because in my version, with:
> using restrict X;
> #include "whatever"
> "whatever" is not exposed to X. If "whatever" needs X, a regular
> using would do that.
> I'd rather not indent my code or have lots of closing braces and have
> to match that all up which might happen, especially if there's a few
> using's going on.
> If X is needed in the file, let it be for the whole file even if
> that's more than is technically needed.
> But if people prefer using namespace X { } I'm ok with that.
>
> --
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/06cb59d7-7304-405a-8fbe-
> 684a924281d5%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1519058532.58210.14.camel%40gmail.com.

--=-/oNzOPgEouPf9JWbOc66
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE3RJb20ryY2ALx0Tw6HZ1IvK3CgsFAlqK/mQACgkQ6HZ1IvK3
CgshOw//UdeebeuGPmj+d3JnhGBDjdoGC8OWrzQjVk+oNuVh2RQGMszFJPbwOAzf
KIdrz1b6lnXYns2NAkza4Sy/aFRhI4R5BN5T/o1mjVsAUGleRAVQU6Bpl4gMRbjB
ixh900vZYxMzukK2XbO6FgMKCM2dqh++Swgd8tmpTs5B+V/CUA3XCh73GBpZlmmO
Bmxt/OMEZxw+JZzhOMNfmXUjAHBuv24uM4e/Hnuouro9Ra21p7o7IeQ5yJ4GzVno
SPwX6FylZvLBvXALybSc52Ij/HHOOQ1nZpg3RXzYW6sIEO1TENdBKVSXTDLynjqe
HsxuoltQTxq/JtWMB2dLyqAn60CsD+TRQSu8Vi7TwMu2jNe77LqO+2mKepnt51Tf
QtkS/YPcN/u9Ab4f9HlKLPuS6vozFqFgI+udevQNtOnfZ4lyNfaEPRNifzxI89VC
a/XXXfle4X/FmCnMI/nDsUj1YKmGsSHwTsjibanemDVmMtAjCIg8F7cxZufva87E
Xn75lJZlePtSPWlXyJobK+7a6jSD231pW0/iKda5msf9v155Gv3OHLmIFH6OMNYo
DiPYej5Cs1JXAihMeAwElE5Wu5h/7xtjqecfoTp1zlP79kCZtG7e1mbOPk2IOzBe
Q5UtirhuOe8GL0G9KE8looToZNwbCZjQTyAP/IR/jKUFfcg6p8I=
=N+Xo
-----END PGP SIGNATURE-----

--=-/oNzOPgEouPf9JWbOc66--


.

------=_Part_13689_681734387.1519069334235
Content-Type: multipart/alternative;
 boundary="----=_Part_13690_987327586.1519069334236"

------=_Part_13690_987327586.1519069334236
Content-Type: text/plain; charset="UTF-8"


>
> >
> > What I said was that if the compiler creates the pre-processed output
> > that Thiago and yourself seem concerned about,.
> > I don't see why that compiler can't inject statements into that pre-
> > processed output that mark where the file scope ends.
> > The compiler already appears to mark this point anyway.
> > And then when it processes the pre-processed output which it created
> > earlier, it can undo the namespace at that appropriate point.
>
> The initial perception of there being a problem comes from the fact
> that pre-processing is a separate (and indeed, un-necessary) step when
> compiling.
> In c++ there are no such things as "header files". There are merely
> "compilation units", which themselves need not even be in a file.
>
> In the c++ langauge there is no such thing as #include or #if. These
> are pre-processor instructions, used to generate a compilation unit,
> which is then passed to the compiler.
>
> Note that often, "passed to the compiler" often does not involve a
> file. It's quite common for the pre-processed compilation unit source
> to be passed to the compiler through a pipe.
>
> In order to implement what you suggest, there would first need to be a
> requirement in the pre-processor that it generate markers in the pre-
> processed source in order to tell the compiler where "header file
> breaks" are. Then the compiler would need to be modified to notice
> these markers and action your namespace proposal in response.
>
> Remember that the pre-processor is the same one that is used for all
> kinds of languages and utilities (inclusing but not limited to C and
> objective-C).
>
> This is starting to look like a can of worms.
>
> And as Ville mentioned, we will (hopefully) soon have modules, which
> obsoletes the entire enterprise.
>
> R
>
>
Ok so "the problem" appears to be exactly what I thought Thiago was hinting
at in the first reply to this suggestion. And your solution appears to be
exactly the one I said in my first reply to him.  That doesn't look like 'a
can of worms' it looks just like it's solved exactly as we said.

If you use g++ to pre-process my example code it appears the compiler
does already put down the very markers where source files start/end that
you are talking about. But if it didn't it seems it could. So I don't see
any can of worms here. That's not to say there isn't one, but nobody has
pointed out clearly what it is.

I appreciate peoples responses here, but it seems it might be better if
commentators who aren't sure if this is implementable stick to commenting
on if they like the idea *assuming it can be implemented easily* and leave
getting all concerned about the possible implementation difficulties to
people who are more sure there's a difficulty.

Otherwise it creates a lot of noise that hides who likes the concept and
who doesn't and a lot of froth about how there might be a problem when
equally so what, there might not.

I mean, nothing I've read so far has said the solution I first mentioned
isn't THE solution. If anything your comment confirms it is and if it
is that doesn't look hard. But either way nobody is clear there is a
problem or there isn't a solution.

It seems to me modules would make this feature less useful, that's the main
issue I think.
So unless people care about pre module code, it's probably not going to get
interest regardless of how hard it is to implement. That seems to be the
main takeaway here. I don't think we need to over complicate the issue to
shoot it down.




--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/828660f0-58f1-4875-865e-02db3faf2db7%40isocpp.org.

------=_Part_13690_987327586.1519069334236
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">&gt;=20
<br>&gt; What I said was that if the compiler creates the pre-processed out=
put
<br>&gt; that Thiago and yourself seem concerned about,.
<br>&gt; I don&#39;t see why that compiler can&#39;t inject statements into=
 that pre-
<br>&gt; processed output that mark where the file scope ends.
<br>&gt; The compiler already appears to mark this point anyway.
<br>&gt; And then when it processes the pre-processed output which it creat=
ed
<br>&gt; earlier, it can undo the namespace at that appropriate point.
<br>
<br>The initial perception of there being a problem comes from the fact
<br>that pre-processing is a separate (and indeed, un-necessary) step when
<br>compiling.
<br>In c++ there are no such things as &quot;header files&quot;. There are =
merely
<br>&quot;compilation units&quot;, which themselves need not even be in a f=
ile.
<br>
<br>In the c++ langauge there is no such thing as #include or #if. These
<br>are pre-processor instructions, used to generate a compilation unit,
<br>which is then passed to the compiler.
<br>
<br>Note that often, &quot;passed to the compiler&quot; often does not invo=
lve a
<br>file. It&#39;s quite common for the pre-processed compilation unit sour=
ce
<br>to be passed to the compiler through a pipe.
<br>
<br>In order to implement what you suggest, there would first need to be a
<br>requirement in the pre-processor that it generate markers in the pre-
<br>processed source in order to tell the compiler where &quot;header file
<br>breaks&quot; are. Then the compiler would need to be modified to notice
<br>these markers and action your namespace proposal in response.
<br>
<br>Remember that the pre-processor is the same one that is used for all
<br>kinds of languages and utilities (inclusing but not limited to C and
<br>objective-C).
<br>
<br>This is starting to look like a can of worms.
<br>
<br>And as Ville mentioned, we will (hopefully) soon have modules, which
<br>obsoletes the entire enterprise.
<br>
<br>R
<br>
<br></blockquote><div><br></div><div>Ok so &quot;the problem&quot; appears =
to be=C2=A0exactly what I thought=C2=A0Thiago was hinting at=C2=A0in=C2=A0t=
he first reply to this suggestion. And=C2=A0your solution=C2=A0appears to b=
e exactly the one I said in my first reply to him.=C2=A0=C2=A0That doesn&#3=
9;t look like &#39;a can of worms&#39; it looks just like it&#39;s solved e=
xactly as we said.</div><div><br></div><div>If you use g++ to=C2=A0pre-proc=
ess=C2=A0my example code it appears the compiler does=C2=A0already put down=
 the very=C2=A0markers where source files start/end=C2=A0that you are talki=
ng about. But if it didn&#39;t it seems it could.=C2=A0So I don&#39;t see a=
ny can of worms here. That&#39;s not to say there isn&#39;t one, but nobody=
 has pointed=C2=A0out clearly what it is.</div><div><br></div><div>I apprec=
iate peoples responses here, but it seems it might be better if commentator=
s who aren&#39;t sure if this=C2=A0is implementable=C2=A0stick to commentin=
g on if they like the idea *assuming it can be implemented easily*=C2=A0and=
 leave getting all concerned about the possible implementation difficulties=
 to people who=C2=A0are more sure there&#39;s a difficulty.</div><div><br><=
/div><div>Otherwise=C2=A0it creates a lot of noise that hides who likes the=
 concept and who doesn&#39;t and a lot of froth about how there might be a =
problem=C2=A0when equally so what, there might not.</div><div><br></div><di=
v>I mean, nothing I&#39;ve read so far has said the solution I first mentio=
ned isn&#39;t THE solution. If anything your comment=C2=A0confirms it is an=
d if it is=C2=A0that doesn&#39;t look hard.=C2=A0But either way nobody is c=
lear there is a problem=C2=A0or=C2=A0there isn&#39;t a solution.</div><div>=
<br></div><div>It seems to me modules would make this feature less useful, =
that&#39;s the main issue I think.</div><div>So unless people care about pr=
e=C2=A0module code, it&#39;s probably not going to get interest regardless =
of how hard it is to implement. That seems to be the main takeaway here. I =
don&#39;t think we need to over complicate the issue to shoot it down.</div=
><div><br></div><div><br></div><div><br></div><div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/828660f0-58f1-4875-865e-02db3faf2db7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/828660f0-58f1-4875-865e-02db3faf2db7=
%40isocpp.org</a>.<br />

------=_Part_13690_987327586.1519069334236--

------=_Part_13689_681734387.1519069334235--

.

On 19 February 2018 at 21:42,  <gmisocpp@gmail.com> wrote:
> Ok so "the problem" appears to be exactly what I thought Thiago was hinting
> at in the first reply to this suggestion. And your solution appears to be
> exactly the one I said in my first reply to him.  That doesn't look like 'a
> can of worms' it looks just like it's solved exactly as we said.
>
> If you use g++ to pre-process my example code it appears the compiler does
> already put down the very markers where source files start/end that you are
> talking about. But if it didn't it seems it could. So I don't see any can of
> worms here. That's not to say there isn't one, but nobody has pointed out
> clearly what it is.

Those markers are implementation details that are not specified
anywhere, and they are comments.
Today, a perfectly conforming implementation can remove all comments
in the preprocessing phase.

If such markers are used, they need to be syntactic.

> It seems to me modules would make this feature less useful, that's the main
> issue I think.
> So unless people care about pre module code, it's probably not going to get
> interest regardless of how hard it is to implement. That seems to be the
> main takeaway here. I don't think we need to over complicate the issue to
> shoot it down.

If you have modules, such markers are completely unnecessary. So the
real question is whether
it's useful to improve pre-modules C++, or just use modules. I can't
tell how the committee would
receive an improvement to pre-modules C++ overall, but I guarantee
there will be many people who will
say "just use 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZYk1eFj8Nnh2yHKsGsNx3dME72L4kHc%2BA0UuJsjcJcYg%40mail.gmail.com.

.

On Monday, 19 February 2018 11:42:14 PST gmisocpp@gmail.com wrote:
> If you use g++ to pre-process my example code it appears the compiler
> does already put down the very markers where source files start/end that
> you are talking about. But if it didn't it seems it could. So I don't see
> any can of worms here. That's not to say there isn't one, but nobody has
> pointed out clearly what it is.

Please try using a tool like creduce then. One of the first things it does is
to remove all those unnecessary file markers, right after removing whitespace.

In your search for a proposal, assume that you can't change the preprocessor,
since it's shared with C. That means the #includes are resolved by that C
preprocessor before the C++ compiler sees anything. With that in mind, please
reformulate your proposal.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1888806.bG3H7pAlDa%40tjmaciei-mobl1.

.