------=_Part_16_18262730.1355852039438
Content-Type: text/plain; charset=ISO-8859-1

I read/watched Doug Gregor's update on modules with interested and read the
document at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1611.pdf.

In doing so mention is made of the transition period when we will probably
require both headers and modules. This led me to a question which I could
not find a clear answer to, I suspect I'm just missing it. Basically
can/will old headers and shared libraries/DLLs be able to generated from
modules? It seemed from the presentation that most of the focus was on
generating modules from existing headers not the other way round.

I ask as in our own internal library development we obviously don't want to
support both. The presentation docs states "Headers remain "the truth"",
this seems to suggest everyone living in the world of header writing and
only changing when the entire world has moved. How about the module is the
truth but you can generate headers from it. Then a library writer can shift
their internal development world over to modules straight away, and old
headers become a "build automation/packaging issue" that they mostly don't
care about.

Of course I assume this leads into problems about what goes into the
headers that are generated. I suspect some attribute magic may be needed.
Also I suspect that you would not be able to generate exactly the same
headers as hand crafted ones, possibly generated ones would be cleaner and
more regular! Anyway my view, and I know this is not shared by everyone, is
that as long as the generated headers are close enough that the upgrade
from a library version that has hand crafted headers to one that has
generated ones would be similar to a major library release. In this
situation as a user of a library, for instance we use Boost, I always
expect to make some changes in my code. Obviously you could have a release
or two where you provide both hand crafted and generated headers so that
development teams can schedule there transition more easily.

--




------=_Part_16_18262730.1355852039438
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I read/watched Doug Gregor's update on modules with interested and read the=
 document at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1611.pdf. <br=
><br>In doing so mention is made of the transition period when we will prob=
ably require both headers and modules. This led me to a question which I co=
uld not find a clear answer to, I suspect I'm just missing it. Basically ca=
n/will old headers and shared libraries/DLLs be able to generated from modu=
les? It seemed from the presentation that most of the focus was on generati=
ng modules from existing headers not the other way round.<br><br>I ask as i=
n our own internal library development we obviously don't want to support b=
oth. The presentation docs states "Headers remain "the truth"", this seems =
to suggest everyone living in the world of header writing and only changing=
 when the entire world has moved. How about the module is the truth but you=
 can generate headers from it. Then a library writer can shift their intern=
al development world over to modules straight away, and old headers become =
a "build automation/packaging issue" that they mostly don't care about. <br=
><br>Of course I assume this leads into problems about what goes into the h=
eaders that are generated. I suspect some attribute magic may be needed. Al=
so I suspect that you would not be able to generate exactly the same header=
s as hand crafted ones, possibly generated ones would be cleaner and more r=
egular! Anyway my view, and I know this is not shared by everyone, is that =
as long as the generated headers are close enough that the upgrade from a l=
ibrary version that has hand crafted headers to one that has generated ones=
 would be similar to a major library release. In this situation as a user o=
f a library, for instance we use Boost, I always expect to make some change=
s in my code. Obviously you could have a release or two where you provide b=
oth hand crafted and generated headers so that development teams can schedu=
le there transition more easily.<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_16_18262730.1355852039438--

.

--047d7b339bf57a8e1704d1256394
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In the last draft of the original proposal (which is not what Doug Gregor
was talking about, but he mention it) which is there:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf

In chapter 5.1 there is an example of what the "interface file" format
could be. I believe it's what you're looking for.
If something like that is implemented in the end, what I wonder is if there
would be a possibility to have special comment markup
to attach comments to declarations to be added to this file for
documentation.

Citation from this document:

For example, the module partition

export M:
  class B { virtual ~B(); };
  B::~B() {}
#define X 42
  class D: B {
    int f() { return X; }
  public:
    int f(int x) { return x; }
    double f(double x) { return x; }
    int g() { return f(); }
  };

might generate an interface =EF=AC=81le that looks as follows:

export M:
private:
  class [[class_layout(8, 8)]] #1 {
    ~#1();
  };
public:
  class [[class_layout(8, 8)]] D#1: #1 {
    int #2() { return 42; }
  public:
    int f#1(int x#1) { return x#1; }
    double f#2(double x#1) { return x#1; }
    int g#1() { return #2(); }
  };


Joel Lamotte

--=20




--047d7b339bf57a8e1704d1256394
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In the last draft of the original proposal (which is not w=
hat Doug Gregor was talking about, but he mention it) which is there:=C2=A0=
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pd=
f">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf</a><di=
v>
<br></div><div style>In chapter 5.1 there is an example of what the &quot;i=
nterface file&quot; format could be. I believe it&#39;s what you&#39;re loo=
king for.</div><div style>If something like that is implemented in the end,=
 what I wonder is if there would be a possibility to have special comment m=
arkup</div>
<div style>to attach comments to declarations to be added to this file for =
documentation.</div><div style><br>Citation from this document:</div><div s=
tyle><br></div><div style><div>For example, the module partition</div><div>
<br></div><div>export M:</div><div>=C2=A0 class B { virtual ~B(); };</div><=
div>=C2=A0 B::~B() {}</div><div>#define X 42=C2=A0</div><div>=C2=A0 class D=
: B {</div><div>=C2=A0 =C2=A0 int f() { return X; }</div><div>=C2=A0 public=
:</div><div>=C2=A0 =C2=A0 int f(int x) { return x; }</div>
<div>=C2=A0 =C2=A0 double f(double x) { return x; }</div><div>=C2=A0 =C2=A0=
 int g() { return f(); }</div><div>=C2=A0 };</div><div><br></div><div>might=
 generate an interface =EF=AC=81le that looks as follows:</div><div><br></d=
iv><div>export M:</div><div>private:</div>
<div>=C2=A0 class [[class_layout(8, 8)]] #1 {</div><div>=C2=A0 =C2=A0 ~#1()=
;</div><div>=C2=A0 };</div><div>public:</div><div>=C2=A0 class [[class_layo=
ut(8, 8)]] D#1: #1 {</div><div>=C2=A0 =C2=A0 int #2() { return 42; }</div><=
div>=C2=A0 public:</div><div>=C2=A0 =C2=A0 int f#1(int x#1) { return x#1; }=
</div>
<div>=C2=A0 =C2=A0 double f#2(double x#1) { return x#1; }</div><div>=C2=A0 =
=C2=A0 int g#1() { return #2(); }</div><div>=C2=A0 };</div><div><br></div><=
div><br></div><div style>Joel Lamotte</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--047d7b339bf57a8e1704d1256394--

.

------=_Part_720_14279299.1355940361601
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So I read the paper, I think when it refers to an "interface" file it means=
=20
a file that will later be imported by a user of the library.

I mean generating old style ".h" header files that can be #included by=20
users who either haven't migrated to using modules or are using compilers=
=20
that don't support it.

In essence Doug's talk seemed to focus on solving the transition period by=
=20
generating modules from ole style ".h" files. I am wondering if the reverse=
=20
approach of generating old ".h" style headers from modules might be an=20
easier transition.


On Tuesday, December 18, 2012 12:20:19 PM UTC-7, Klaim - Jo=C3=ABl Lamotte =
wrote:
>
> In the last draft of the original proposal (which is not what Doug Gregor=
=20
> was talking about, but he mention it) which is there:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf
>
> In chapter 5.1 there is an example of what the "interface file" format=20
> could be. I believe it's what you're looking for.
> If something like that is implemented in the end, what I wonder is if=20
> there would be a possibility to have special comment markup
> to attach comments to declarations to be added to this file for=20
> documentation.
>
> Citation from this document:
>
> For example, the module partition
>
> export M:
>   class B { virtual ~B(); };
>   B::~B() {}
> #define X 42=20
>   class D: B {
>     int f() { return X; }
>   public:
>     int f(int x) { return x; }
>     double f(double x) { return x; }
>     int g() { return f(); }
>   };
>
> might generate an interface =EF=AC=81le that looks as follows:
>
> export M:
> private:
>   class [[class_layout(8, 8)]] #1 {
>     ~#1();
>   };
> public:
>   class [[class_layout(8, 8)]] D#1: #1 {
>     int #2() { return 42; }
>   public:
>     int f#1(int x#1) { return x#1; }
>     double f#2(double x#1) { return x#1; }
>     int g#1() { return #2(); }
>   };
>
>
> Joel Lamotte
>

--=20




------=_Part_720_14279299.1355940361601
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So I read the paper, I think when it refers to an "interface" file it means=
 a file that will later be imported by a user of the library.<br><br>I mean=
 generating old style ".h" header files that can be #included by users who =
either haven't migrated to using modules or are using compilers that don't =
support it.<br><br>In essence Doug's talk seemed to focus on solving the tr=
ansition period by generating modules from ole style ".h" files. I am wonde=
ring if the reverse approach of generating old ".h" style headers from modu=
les might be an easier transition.<br><br><br>On Tuesday, December 18, 2012=
 12:20:19 PM UTC-7, Klaim - Jo=C3=ABl Lamotte wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr">In the last draft of the original pr=
oposal (which is not what Doug Gregor was talking about, but he mention it)=
 which is there:&nbsp;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2012/n3347.pdf" target=3D"_blank">http://www.open-std.<wbr>org/jtc=
1/sc22/wg21/docs/<wbr>papers/2012/n3347.pdf</a><div>
<br></div><div>In chapter 5.1 there is an example of what the "interface fi=
le" format could be. I believe it's what you're looking for.</div><div>If s=
omething like that is implemented in the end, what I wonder is if there wou=
ld be a possibility to have special comment markup</div>
<div>to attach comments to declarations to be added to this file for docume=
ntation.</div><div><br>Citation from this document:</div><div><br></div><di=
v><div>For example, the module partition</div><div>
<br></div><div>export M:</div><div>&nbsp; class B { virtual ~B(); };</div><=
div>&nbsp; B::~B() {}</div><div>#define X 42&nbsp;</div><div>&nbsp; class D=
: B {</div><div>&nbsp; &nbsp; int f() { return X; }</div><div>&nbsp; public=
:</div><div>&nbsp; &nbsp; int f(int x) { return x; }</div>
<div>&nbsp; &nbsp; double f(double x) { return x; }</div><div>&nbsp; &nbsp;=
 int g() { return f(); }</div><div>&nbsp; };</div><div><br></div><div>might=
 generate an interface =EF=AC=81le that looks as follows:</div><div><br></d=
iv><div>export M:</div><div>private:</div>
<div>&nbsp; class [[class_layout(8, 8)]] #1 {</div><div>&nbsp; &nbsp; ~#1()=
;</div><div>&nbsp; };</div><div>public:</div><div>&nbsp; class [[class_layo=
ut(8, 8)]] D#1: #1 {</div><div>&nbsp; &nbsp; int #2() { return 42; }</div><=
div>&nbsp; public:</div><div>&nbsp; &nbsp; int f#1(int x#1) { return x#1; }=
</div>
<div>&nbsp; &nbsp; double f#2(double x#1) { return x#1; }</div><div>&nbsp; =
&nbsp; int g#1() { return #2(); }</div><div>&nbsp; };</div><div><br></div><=
div><br></div><div>Joel Lamotte</div></div></div>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_720_14279299.1355940361601--

.