On Mon, Jan 18, 2016 at 10:37:11PM +0300, Antony Polukhin wrote:
> Hello,
>
> There's a bunch of problems with dynamic loading entities defined in C++
> shared libraries:
> 1) No portable way to define symbol as being imported/exported. All the C++
> libraries are forced to reinvent BOOST_SYMBOL_EXPORT and
> BOOST_SYMBOL_IMPORT like macro [1].
> 2) All modern binary formats store symbols in sections that are not
> currently controlled from C++, but provide a rich set of useful
> functionality. For example Linux kernel developers use sections to store
> pointers to specific entry points (macro __init
> http://lxr.free-electrons.com/source/include/linux/init.h), store data that
> must be changed at load (https://lwn.net/Articles/164121/) and so on.
>
>
> I'm proposing to add following attributes to C++ Standard:
> * [[import]] - for importing symbol (same as BOOST_SYMBOL_IMPORT)
> * [[export]] - for exporting symbol in default section with default C++
> mangling (same as BOOST_SYMBOL_EXPORT)
> * [[section "section name"]] - places the symbol into section with
> specified name, constructs section if it does not exist(close to
> BOOST_DLL_SECTION [2])

* How does this interact with modules?
* Do you intend to bring dlopen into the standard as well?
* What about binary formats that don't support some of these features,
  are all of them supposed to be optionally supported?
* What does importing actually mean? When using ELF there are four different
  modes a symbol could be imported in with different features and effects.

/MF

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-18 14:37, Antony Polukhin wrote:
> There's a bunch of problems with dynamic loading entities defined in C++
> shared libraries:
> 1) No portable way to define symbol as being imported/exported. All the C=
++
> libraries are forced to reinvent BOOST_SYMBOL_EXPORT and
> BOOST_SYMBOL_IMPORT like macro [1].

CMake=C2=B9 might beg to differ ;-).

> I'm proposing to add following attributes to C++ Standard:
> * [[import]] - for importing symbol (same as BOOST_SYMBOL_IMPORT)
> * [[export]] - for exporting symbol in default section with default C++
> mangling (same as BOOST_SYMBOL_EXPORT)

While I don't object to this as such, I think it's worth noting that it
doesn't solve the problem of needing to use macros to decorate symbols.
As long as platforms (Windows/PExx) define these differently, library
authors must use a macro so that it is defined differently when building
the library vs. someone else using the library.

This borders on being a build system issue, with which the C++ standard
usually does not get involved, and we already have many good solutions
for that problem (e.g. CMake).

(=C2=B9 https://cmake.org/cmake/help/v3.4/module/GenerateExportHeader.html)

--=20
Matthew

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

------=_Part_6332_1281824034.1453152207352
Content-Type: multipart/alternative;
 boundary="----=_Part_6333_1170050453.1453152207365"

------=_Part_6333_1170050453.1453152207365
Content-Type: text/plain; charset=UTF-8

On Monday, January 18, 2016 at 12:03:01 PM UTC-8, Matthew Woehlke wrote:
>
> On 2016-01-18 14:37, Antony Polukhin wrote:
> > I'm proposing to add following attributes to C++ Standard:
> > * [[import]] - for importing symbol (same as BOOST_SYMBOL_IMPORT)
> > * [[export]] - for exporting symbol in default section with default C++
> > mangling (same as BOOST_SYMBOL_EXPORT)
>
> While I don't object to this as such, I think it's worth noting that it
> doesn't solve the problem of needing to use macros to decorate symbols.
> As long as platforms (Windows/PExx) define these differently, library
> authors must use a macro so that it is defined differently when building
> the library vs. someone else using the library.
>

It has been publicly mentioned that with the modules feature, this is no
longer the case. Symbols need to merely be marked as being available for
DLL linkage (using __declspec(dllexport) only) and then the linker
automatically exports symbols in modules linked into the DLL and imports
symbols otherwise.

See Andrew Pardoe's response to Matthias in the comments
on http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx

I think that should be taken into account for this whole feature idea. :)


> --
> Matthew
>
>

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, January 18, 2016 at 12:03:01 PM UTC-8, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-18 14=
:37, Antony Polukhin wrote:
<br>&gt; I&#39;m proposing to add following attributes to C++ Standard:
<br>&gt; * [[import]] - for importing symbol (same as BOOST_SYMBOL_IMPORT)
<br>&gt; * [[export]] - for exporting symbol in default section with defaul=
t C++
<br>&gt; mangling (same as BOOST_SYMBOL_EXPORT)
<br>
<br>While I don&#39;t object to this as such, I think it&#39;s worth noting=
 that it
<br>doesn&#39;t solve the problem of needing to use macros to decorate symb=
ols.
<br>As long as platforms (Windows/PExx) define these differently, library
<br>authors must use a macro so that it is defined differently when buildin=
g
<br>the library vs. someone else using the library.
<br></blockquote><div><br></div><div>It has been publicly mentioned that wi=
th the modules feature, this is no longer the case. Symbols need to merely =
be marked as being available for DLL linkage (using __declspec(dllexport) o=
nly) and then the linker automatically exports symbols in modules linked in=
to the DLL and imports symbols otherwise.</div><div><br></div><div>See Andr=
ew Pardoe&#39;s response to Matthias in the comments on=C2=A0http://blogs.m=
sdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx</div=
><div><br></div><div>I think that should be taken into account for this who=
le feature idea. :)</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">
<br>--=20
<br>Matthew
<br>
<br></blockquote></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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6333_1170050453.1453152207365--
------=_Part_6332_1281824034.1453152207352--

.

On Monday 18 January 2016 20:50:10 Magnus Fromreide wrote:
> * What does importing actually mean? When using ELF there are four different
> modes a symbol could be imported in with different features and effects.

Off-topic, but this is a missed optimisation in ELF. I've been trying to get
the ABI folks to come up with a proper way to import. GCC 6's -fno-plt is
half-way there.

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a114d8e16596a7b0529c541e1
Content-Type: text/plain; charset=UTF-8

2016-01-18 22:50 GMT+03:00 Magnus Fromreide <magfr@lysator.liu.se>:

> * How does this interact with modules?
>

Both proposals use `import` as a keyword, however use cases are different
and must not bother each other.


> * Do you intend to bring dlopen into the standard as well?
>

Yes. But later, only after the Boost.DLL library will be tested by Boost
users. Probably in half a year.


> * What about binary formats that don't support some of these features,
>   are all of them supposed to be optionally supported?
>

Probably will just follow the existing GCC practice for unsupported
attributes: warn about them


> * What does importing actually mean? When using ELF there are four
> different
>   modes a symbol could be imported in with different features and effects.
>

In GCC case it would be visibility=default, nonweak symbol. Or did I
misunderstand the question/miss something?

--
Best regards,
Antony Polukhin

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a114d8e16596a7b0529c541e1
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">2016=
-01-18 22:50 GMT+03:00 Magnus Fromreide <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:magfr@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se</a>&gt;</=
span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">* How does this interact with modu=
les?<br></blockquote><div><br></div><div>Both proposals use `import` as a k=
eyword, however use cases are different and must not bother each other.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
* Do you intend to bring dlopen into the standard as well?<br></blockquote>=
<div><br></div><div>Yes. But later, only after the Boost.DLL library will b=
e tested by Boost users. Probably in half a year.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
* What about binary formats that don&#39;t support some of these features,<=
br>
=C2=A0 are all of them supposed to be optionally supported?<br></blockquote=
><div><br></div><div>Probably will just follow the existing GCC practice fo=
r unsupported attributes: warn about them=C2=A0</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
* What does importing actually mean? When using ELF there are four differen=
t<br>
=C2=A0 modes a symbol could be imported in with different features and effe=
cts.<br></blockquote><div><br></div><div>In GCC case it would be visibility=
=3Ddefault, nonweak symbol. Or did I misunderstand the question/miss someth=
ing?</div></div><div><br></div>-- <br><div class=3D"gmail_signature">Best r=
egards,<br>Antony Polukhin</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a114d8e16596a7b0529c541e1--

.

--94eb2c0bc760ae4c880529c5f0e2
Content-Type: text/plain; charset=UTF-8

2016-01-19 0:23 GMT+03:00 Sean Middleditch <sean.middleditch@gmail.com>:
>
> It has been publicly mentioned that with the modules feature, this is no
> longer the case. Symbols need to merely be marked as being available for
> DLL linkage (using __declspec(dllexport) only) and then the linker
> automatically exports symbols in modules linked into the DLL and imports
> symbols otherwise.
>
> See Andrew Pardoe's response to Matthias in the comments on
> http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx
>
> I think that should be taken into account for this whole feature idea. :)
>

Yes.

__declspec(dllexport) is a MSVC extension, that must be made part of the
Standard and must follow the existing [[attributes syntax]]. And that's
what the proposal is trying to achieve - make attributes for shared objects
parts of the Standard. "dll" prefix was dropped from [[import]] and
[[export]] to make proposal less platform specific, because on different
platforms shared objects have different names (dll/so/dynlib).

--
Best regards,
Antony Polukhin

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-01-19 0:23 GMT+03:00 Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D=
"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.middleditch@gmai=
l.com</a>&gt;</span>:<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>It has been pub=
licly mentioned that with the modules feature, this is no longer the case. =
Symbols need to merely be marked as being available for DLL linkage (using =
__declspec(dllexport) only) and then the linker automatically exports symbo=
ls in modules linked into the DLL and imports symbols otherwise.</div><div>=
<br></div><div>See Andrew Pardoe&#39;s response to Matthias in the comments=
 on=C2=A0<a href=3D"http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-mod=
ules-in-vs-2015-update-1.aspx" target=3D"_blank">http://blogs.msdn.com/b/vc=
blog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx</a></div><div><b=
r></div><div>I think that should be taken into account for this whole featu=
re idea. :)</div></div></blockquote></div><br>Yes.=C2=A0</div><div class=3D=
"gmail_extra"><span style=3D"font-size:12.8px"><br></span></div><div class=
=3D"gmail_extra"><span style=3D"font-size:12.8px">__declspec(dllexport)=C2=
=A0is a MSVC extension, that must be made part of the Standard and must fol=
low the existing [[attributes syntax]].=C2=A0</span><span style=3D"font-siz=
e:12.8px">And that&#39;s what the proposal is trying to=C2=A0achieve=C2=A0-=
 make attributes for shared objects parts of the Standard. &quot;dll&quot; =
prefix was dropped from=C2=A0</span><span style=3D"font-size:12.8px">[[impo=
rt]] and [[export]] to make proposal less platform specific, because on dif=
ferent platforms shared objects have different names (dll/so/dynlib).</span=
></div><div class=3D"gmail_extra"><div><br></div>-- <br><div class=3D"gmail=
_signature">Best regards,<br>Antony Polukhin</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--94eb2c0bc760ae4c880529c5f0e2--

.

On Wed, Jan 20, 2016 at 7:50 AM, Antony Polukhin <antoshkka@gmail.com> wrote:
>
> 2016-01-19 0:23 GMT+03:00 Sean Middleditch <sean.middleditch@gmail.com>:
>>
>> It has been publicly mentioned that with the modules feature, this is no
>> longer the case. Symbols need to merely be marked as being available for DLL
>> linkage (using __declspec(dllexport) only) and then the linker automatically
>> exports symbols in modules linked into the DLL and imports symbols
>> otherwise.
>>
>> See Andrew Pardoe's response to Matthias in the comments on
>> http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx
>>
>> I think that should be taken into account for this whole feature idea. :)
>
>
> Yes.
>
> __declspec(dllexport) is a MSVC extension, that must be made part of the
> Standard and must follow the existing [[attributes syntax]]. And that's what
> the proposal is trying to achieve - make attributes for shared objects parts
> of the Standard. "dll" prefix was dropped from [[import]] and [[export]] to
> make proposal less platform specific, because on different platforms shared
> objects have different names (dll/so/dynlib).

I'm quite aware.

What I was getting at is that with C++ modules we might not need
separate import and export attributes, at least on one major platform
that had forced us to explicitly import symbols and deal with separate
import/export macros. Your proposal should take that into account,
since modules will almost certainly be a part of C++ before your new
attributes ever would be.

>
> --
> Best regards,
> Antony Polukhin
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jzc7d_MQUZg/unsubscribe.
> To unsubscribe from this group and all its topics, 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.



--
Sean Middleditch
http://seanmiddleditch.com

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a114404864c09b80529c7e3ea
Content-Type: text/plain; charset=UTF-8

2016-01-20 19:55 GMT+03:00 Sean Middleditch <sean@middleditch.us>:

> On Wed, Jan 20, 2016 at 7:50 AM, Antony Polukhin <antoshkka@gmail.com>
> wrote:
> >
> > 2016-01-19 0:23 GMT+03:00 Sean Middleditch <sean.middleditch@gmail.com>:
> >>
> >> It has been publicly mentioned that with the modules feature, this is no
> >> longer the case. Symbols need to merely be marked as being available
> for DLL
> >> linkage (using __declspec(dllexport) only) and then the linker
> automatically
> >> exports symbols in modules linked into the DLL and imports symbols
> >> otherwise.
> >>
> >> See Andrew Pardoe's response to Matthias in the comments on
> >>
> http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx
> >>
> >> I think that should be taken into account for this whole feature idea.
> :)
> >
> >
> > Yes.
> >
> > __declspec(dllexport) is a MSVC extension, that must be made part of the
> > Standard and must follow the existing [[attributes syntax]]. And that's
> what
> > the proposal is trying to achieve - make attributes for shared objects
> parts
> > of the Standard. "dll" prefix was dropped from [[import]] and [[export]]
> to
> > make proposal less platform specific, because on different platforms
> shared
> > objects have different names (dll/so/dynlib).
>
> I'm quite aware.
>
> What I was getting at is that with C++ modules we might not need
> separate import and export attributes, at least on one major platform
> that had forced us to explicitly import symbols and deal with separate
> import/export macros. Your proposal should take that into account,
> since modules will almost certainly be a part of C++ before your new
> attributes ever would be.
>

Oh, I've finally get that one. You're 100% right, [[import]] and [[export]]
may become deprecated before even getting into the Standard.

How about following the GCC approach and using [[visible]] attribute? With
[[visible]] all the export/import macro will go away. Just use [[visible]]
if in binary that symbol must be available for dynamic load.

What do you and others think of it?

--
Best regards,
Antony Polukhin

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-01-20 19:55 GMT+03:00 Sean Middleditch <span dir=3D"ltr">&lt;<a href=
=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middleditch.us</a>&g=
t;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><span>On Wed, Jan 20, 2016 at 7:50 AM, Anton=
y Polukhin &lt;<a href=3D"mailto:antoshkka@gmail.com" target=3D"_blank">ant=
oshkka@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; 2016-01-19 0:23 GMT+03:00 Sean Middleditch &lt;<a href=3D"mailto:sean.=
middleditch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;=
:<br>
&gt;&gt;<br>
&gt;&gt; It has been publicly mentioned that with the modules feature, this=
 is no<br>
&gt;&gt; longer the case. Symbols need to merely be marked as being availab=
le for DLL<br>
&gt;&gt; linkage (using __declspec(dllexport) only) and then the linker aut=
omatically<br>
&gt;&gt; exports symbols in modules linked into the DLL and imports symbols=
<br>
&gt;&gt; otherwise.<br>
&gt;&gt;<br>
&gt;&gt; See Andrew Pardoe&#39;s response to Matthias in the comments on<br=
>
&gt;&gt; <a href=3D"http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-mod=
ules-in-vs-2015-update-1.aspx" rel=3D"noreferrer" target=3D"_blank">http://=
blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.as=
px</a><br>
&gt;&gt;<br>
&gt;&gt; I think that should be taken into account for this whole feature i=
dea. :)<br>
&gt;<br>
&gt;<br>
&gt; Yes.<br>
&gt;<br>
&gt; __declspec(dllexport) is a MSVC extension, that must be made part of t=
he<br>
&gt; Standard and must follow the existing [[attributes syntax]]. And that&=
#39;s what<br>
&gt; the proposal is trying to achieve - make attributes for shared objects=
 parts<br>
&gt; of the Standard. &quot;dll&quot; prefix was dropped from [[import]] an=
d [[export]] to<br>
&gt; make proposal less platform specific, because on different platforms s=
hared<br>
&gt; objects have different names (dll/so/dynlib).<br>
<br>
</span>I&#39;m quite aware.<br>
<br>
What I was getting at is that with C++ modules we might not need<br>
separate import and export attributes, at least on one major platform<br>
that had forced us to explicitly import symbols and deal with separate<br>
import/export macros. Your proposal should take that into account,<br>
since modules will almost certainly be a part of C++ before your new<br>
attributes ever would be.<br></blockquote><div><br></div><div>Oh, I&#39;ve =
finally get that one. You&#39;re 100% right, [[import]] and [[export]] may =
become deprecated before even getting into the Standard.</div></div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">How about followin=
g the GCC approach and using [[visible]] attribute? With [[visible]] all th=
e export/import macro will go away. Just use [[visible]] if in binary that =
symbol must be available for dynamic load.</div><div><br></div><div>What do=
 you and others think of it?</div><div><br></div><div></div>-- <br><div>Bes=
t regards,<br>Antony Polukhin</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a114404864c09b80529c7e3ea--

.

On 2016-01-20 13:09, Antony Polukhin wrote:
> Oh, I've finally get that one. You're 100% right, [[import]] and [[export]]
> may become deprecated before even getting into the Standard.
>
> How about following the GCC approach and using [[visible]] attribute? With
> [[visible]] all the export/import macro will go away. Just use [[visible]]
> if in binary that symbol must be available for dynamic load.
>
> What do you and others think of it?

....or [[exported]]? :-)

--
Matthew

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wed, Jan 20, 2016 at 11:11 AM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2016-01-20 13:09, Antony Polukhin wrote:
>> Oh, I've finally get that one. You're 100% right, [[import]] and [[export]]
>> may become deprecated before even getting into the Standard.
>>
>> How about following the GCC approach and using [[visible]] attribute? With
>> [[visible]] all the export/import macro will go away. Just use [[visible]]
>> if in binary that symbol must be available for dynamic load.
>>
>> What do you and others think of it?
>
> ...or [[exported]]? :-)

Honestly, I'd be a little hesitant to use anything remotely like
"import" or "export" just to avoid user confusion with modules.

>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jzc7d_MQUZg/unsubscribe.
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/a/isocpp.org/group/std-proposals/.



--
Sean Middleditch
http://seanmiddleditch.com

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2092_1857118966.1455362737398
Content-Type: multipart/alternative;
 boundary="----=_Part_2093_590904293.1455362737398"

------=_Part_2093_590904293.1455362737398
Content-Type: text/plain; charset=UTF-8

If you build a binary, why wouldn't export be possible instead of
[[visible]] ?

If it's exported in the module, it must be visible in the binary. And if
it's visible in the binary, why wouldn't it be exported in the module?

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">If you build a binary, why wouldn&#39;t export be possible=
 instead of [[visible]] ?=C2=A0<div><br></div><div>If it&#39;s exported in =
the module, it must be visible in the binary. And if it&#39;s visible in th=
e binary, why wouldn&#39;t it be exported in the module?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2093_590904293.1455362737398--
------=_Part_2092_1857118966.1455362737398--

.

--Apple-Mail=_0C8F46FE-5693-4100-BEBA-30BA76672B5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2016=E2=80=9302=E2=80=9313, at 7:25 PM, Klemens Morgenstern <klemens.m=
orgenstern@gmx.net> wrote:
>=20
> If you build a binary, why wouldn't export be possible instead of [[visib=
le]] ?=20
>=20
> If it's exported in the module, it must be visible in the binary. And if =
it's visible in the binary, why wouldn't it be exported in the module?

Module export is merely equivalent to presence in a header file. Under modu=
les, headers are replaced by .cpp files wherein everything is exported. (Mi=
crosoft may use module interface membership as a linker hint, but that=E2=
=80=99s tangential. Other platforms have long switched automatically betwee=
n importing and exporting.)

According to N4466 <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n44=
66.pdf>, =E2=80=9CExport declaration=E2=80=9D =C2=B62, export implies exter=
n. I wonder when you would need extern without export under modules. Maybe =
the keyword can actually be reclaimed, and then it would be free for specif=
ying dynamic library interfaces.

Attributes are not supposed to be semantic, and dynamic library linkage may=
 not be subtle enough to fit them. A static local declaration in a non-visi=
ble inline function may generate several variables, which is not conforming=
.. The implementation of a dynamic library may define an extern function wit=
h the same signature as another library=E2=80=99s internal-but-extern funct=
ion. Surely Microsoft=E2=80=99s latest compiler allows a DLL to use a modul=
e without exposing it to the world. This is because the ODR is at odds with=
 the dynamic library distribution model.

The standard needs to admit that another linkage level exists inside the cu=
rrent shared object file =E2=80=94 extern but multiply defined. Or equivale=
ntly, with modules, it will need to admit that a program can multiply conta=
in one module. Considering the push for modules as a simplification that wi=
ll make linkage obsolete, neither seems likely to add complexity anytime so=
on. (My 2=C2=A2.)

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--Apple-Mail=_0C8F46FE-5693-4100-BEBA-30BA76672B5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9302=
=E2=80=9313, at 7:25 PM, Klemens Morgenstern &lt;<a href=3D"mailto:klemens.=
morgenstern@gmx.net" class=3D"">klemens.morgenstern@gmx.net</a>&gt; wrote:<=
/div><br class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"lt=
r" class=3D"">If you build a binary, why wouldn't export be possible instea=
d of [[visible]] ?&nbsp;<div class=3D""><br class=3D""></div><div class=3D"=
">If it's exported in the module, it must be visible in the binary. And if =
it's visible in the binary, why wouldn't it be exported in the module?</div=
></div></div></blockquote><br class=3D""></div><div>Module <font face=3D"Co=
urier" class=3D"">export</font> is merely equivalent to presence in a heade=
r file. Under modules, headers are replaced by <font face=3D"Courier" class=
=3D"">.cpp</font> files wherein everything is exported. (Microsoft may use =
module interface membership as a linker hint, but that=E2=80=99s tangential=
.. Other platforms have long switched automatically between importing and ex=
porting.)</div><div><br class=3D""></div><div>According to&nbsp;<a href=3D"=
http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4466.pdf" class=3D"">N=
4466</a>, =E2=80=9CExport declaration=E2=80=9D =C2=B62,&nbsp;<font face=3D"=
Courier" class=3D"">export</font> implies&nbsp;<font face=3D"Courier" class=
=3D"">extern</font>. I wonder when you would need&nbsp;<span style=3D"font-=
family: Courier;" class=3D"">extern</span>&nbsp;without&nbsp;<span style=3D=
"font-family: Courier;" class=3D"">export</span>&nbsp;under modules. Maybe =
the keyword can actually be reclaimed, and then it would be free for specif=
ying dynamic library interfaces.</div><div><br class=3D""></div><div>Attrib=
utes are not supposed to be semantic, and dynamic library linkage may not b=
e subtle enough to fit them. A static local declaration in a non-visible in=
line function may generate several variables, which is not conforming. The =
implementation of a dynamic library may define an&nbsp;<font face=3D"Courie=
r" class=3D"">extern</font> function with the same signature as another lib=
rary=E2=80=99s internal-but-<font face=3D"Courier" class=3D"">extern</font>=
&nbsp;function. Surely Microsoft=E2=80=99s latest compiler allows a DLL to =
use a module without exposing it to the world. This is because the ODR is a=
t odds with the dynamic library distribution model.</div><div><br class=3D"=
"></div><div>The standard needs to admit that another linkage level exists =
inside the current shared object file =E2=80=94&nbsp;<span style=3D"font-fa=
mily: Courier;" class=3D"">extern</span>&nbsp;but multiply defined. Or equi=
valently, with modules, it will need to admit that a program can multiply c=
ontain one module. Considering the push for modules as a simplification tha=
t will make linkage obsolete, neither seems likely to add complexity anytim=
e soon. (My 2=C2=A2.)</div><div><br class=3D""></div></body></html>

<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--Apple-Mail=_0C8F46FE-5693-4100-BEBA-30BA76672B5B--

.

------=_Part_2293_655233798.1455384322631
Content-Type: multipart/alternative;
 boundary="----=_Part_2294_1567884655.1455384322631"

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


>
> Module export is merely equivalent to presence in a header file. Under=20
> modules, headers are replaced by .cpp files wherein everything is=20
> exported. (Microsoft may use module interface membership as a linker hint=
,=20
> but that=E2=80=99s tangential. Other platforms have long switched automat=
ically=20
> between importing and exporting.)
>

True, and I think the bigger issue is the visibility attribute, which you=
=20
do have on other platforms. And here's were I think, if it's declared=20
export, it's visible. So, wouldn't it be smarter so reuse export when=20
building a runtime-loaded shared libary?
=20

>
> According to N4466=20
> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4466.pdf>, =E2=80=
=9CExport=20
> declaration=E2=80=9D =C2=B62, export implies extern. I wonder when you wo=
uld need=20
> extern without export under modules. Maybe the keyword can actually be=20
> reclaimed, and then it would be free for specifying dynamic library=20
> interfaces.
>

That depends on the actual implementation. That is, if module A needs a=20
global variable from module B, but module B depends on A. Sloppy design for=
=20
sure, but we don't know yet if we can compile this then. I don't think so.
It could even happen, that extern thereby becomes a bit more used for=20
exactly those cases.=20

=20

> The standard needs to admit that another linkage level exists inside the=
=20
> current shared object file =E2=80=94 extern but multiply defined. Or=20
> equivalently, with modules, it will need to admit that a program can=20
> multiply contain one module. Considering the push for modules as a=20
> simplification that will make linkage obsolete, neither seems likely to a=
dd=20
> complexity anytime soon. (My 2=C2=A2.)
>

 Well afaik it doesn't consider loading libraries at runtime. However: once=
=20
we have a binary format for modules which contains a lot of information, If=
=20
there is then a need for dlls it maybe could be build atop modules, which=
=20
would allow an amazing amount of information about the data. But that is=20
mere speculation.
Currently, you don't even have the size of types in dlls.

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div>Module <font face=3D"Courier">export</font> is =
merely equivalent to presence in a header file. Under modules, headers are =
replaced by <font face=3D"Courier">.cpp</font> files wherein everything is =
exported. (Microsoft may use module interface membership as a linker hint, =
but that=E2=80=99s tangential. Other platforms have long switched automatic=
ally between importing and exporting.)<br></div></div></blockquote><div><br=
></div><div>True, and I think the bigger issue is the visibility attribute,=
 which you do have on other platforms. And here&#39;s were I think, if it&#=
39;s declared export, it&#39;s visible. So, wouldn&#39;t it be smarter so r=
euse export when building a runtime-loaded shared libary?</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><div></div><div><br></div><div>According to=C2=A0<a href=3D"http=
://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4466.pdf" target=3D"_blank=
" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/ur=
l?q\75http%3A%2F%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015=
%2Fn4466.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFDQvhMAZIKMrSF-drXOiJJqaYrb=
A&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?=
q\75http%3A%2F%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2=
Fn4466.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFDQvhMAZIKMrSF-drXOiJJqaYrbA&=
#39;;return true;">N4466</a>, =E2=80=9CExport declaration=E2=80=9D =C2=B62,=
=C2=A0<font face=3D"Courier">export</font> implies=C2=A0<font face=3D"Couri=
er">extern</font>. I wonder when you would need=C2=A0<span style=3D"font-fa=
mily:Courier">extern</span>=C2=A0without=C2=A0<span style=3D"font-family:Co=
urier">export</span>=C2=A0<wbr>under modules. Maybe the keyword can actuall=
y be reclaimed, and then it would be free for specifying dynamic library in=
terfaces.</div></div></blockquote><div><br></div><div>That depends on the a=
ctual implementation. That is, if module A needs a global variable from mod=
ule B, but module B depends on A. Sloppy design for sure, but we don&#39;t =
know yet if we can compile this then. I don&#39;t think so.</div><div>It co=
uld even happen, that extern thereby becomes a bit more used for exactly th=
ose cases.=C2=A0</div><div><br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div></div><div=
>The standard needs to admit that another linkage level exists inside the c=
urrent shared object file =E2=80=94=C2=A0<span style=3D"font-family:Courier=
">extern</span>=C2=A0but multiply defined. Or equivalently, with modules, i=
t will need to admit that a program can multiply contain one module. Consid=
ering the push for modules as a simplification that will make linkage obsol=
ete, neither seems likely to add complexity anytime soon. (My 2=C2=A2.)</di=
v></div></blockquote><div><br></div><div>=C2=A0Well afaik it doesn&#39;t co=
nsider loading libraries at runtime. However: once we have a binary format =
for modules which contains a lot of information, If there is then a need fo=
r dlls it maybe could be build atop modules, which would allow an amazing a=
mount of information about the data. But that is mere speculation.</div><di=
v>Currently, you don&#39;t even have the size of types in dlls.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2294_1567884655.1455384322631--
------=_Part_2293_655233798.1455384322631--

.

--001a11441dee2acdee052bac37b6
Content-Type: text/plain; charset=UTF-8

I've made a draft proposal for [[visible]] attribute
http://apolukhin.github.io/papers/D0276R0:%20Attribute%20[[visible]].html

I'd appreciate any comments and suggestions.

--
Best regards,
Antony Polukhin

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">I&#39;ve made a draft proposal =
for [[visible]] attribute=C2=A0<a href=3D"http://apolukhin.github.io/papers=
/D0276R0:%20Attribute%20[[visible]].html">http://apolukhin.github.io/papers=
/D0276R0:%20Attribute%20[[visible]].html</a></div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">I&#39;d appreciate any comments and =
suggestions.</div><div class=3D"gmail_extra">=C2=A0</div><div class=3D"gmai=
l_extra">-- <br><div class=3D"gmail_signature">Best regards,<br>Antony Polu=
khin</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11441dee2acdee052bac37b6--

.

On s=C3=A1bado, 13 de fevereiro de 2016 21:54:47 PST David Krauss wrote:
> Other platforms have long switched automatically between importing and
> exporting

I wish they wouldn't. The MS DLL model may be cumbersome, but it generates =
the=20
best code.

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

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

--001a113e781cfbfbfd052e2dde60
Content-Type: text/plain; charset=UTF-8

Big update of the proposal draft (2016-03-16).
https://apolukhin.github.io/papers/D0276R0:%20Attribute%20[[visible]].html

Changes:
* big rewrite of the wording
* more experiments to determinate existing practices
* clarify behavior of attribute on nested classes and namespaces
* clarify behavior on platforms that do not support shared libraries
* better code highlighting and formatting
* multiple minor fixes


--
Best regards,
Antony Polukhin

--
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/CAKqmYPbE-F-hNw6r5pX5esxoKyEGhNTFoWewQ1mvGDJCuBWbtw%40mail.gmail.com.

--001a113e781cfbfbfd052e2dde60
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"><div=
>Big update of the proposal draft (2016-03-16). <a href=3D"https://apolukhi=
n.github.io/papers/D0276R0:%20Attribute%20[[visible]].html">https://apolukh=
in.github.io/papers/D0276R0:%20Attribute%20[[visible]].html</a></div><div><=
br></div><div>Changes:</div><div>* big rewrite of the wording</div><div>* m=
ore experiments to determinate existing practices</div><div>* clarify behav=
ior of attribute on nested classes and namespaces</div><div>* clarify behav=
ior on platforms that do not support shared libraries</div><div>* better co=
de highlighting and formatting</div><div>* multiple minor fixes=C2=A0</div>=
</div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature=
">Best regards,<br>Antony Polukhin</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/CAKqmYPbE-F-hNw6r5pX5esxoKyEGhNTFoWew=
Q1mvGDJCuBWbtw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKqmYPbE-F-hNw6r=
5pX5esxoKyEGhNTFoWewQ1mvGDJCuBWbtw%40mail.gmail.com</a>.<br />

--001a113e781cfbfbfd052e2dde60--

.

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

2016-02-14 6:30 GMT+03:00 Thiago Macieira <thiago@macieira.org>:

> On s=C3=A1bado, 13 de fevereiro de 2016 21:54:47 PST David Krauss wrote:
> > Other platforms have long switched automatically between importing and
> > exporting
>
> I wish they wouldn't. The MS DLL model may be cumbersome, but it generate=
s
> the
> best code.


Could you explain in more details, how the MS DLL model allows to generate
a better code (comparing to a shared library compiled with
-fvisibility=3Dhidden on GCC or Clang)?

--=20
Best regards,
Antony Polukhin

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKqmYPamDpt7C9Af7t54ncTL5opKRF7%3DdCO9P5-kw-0mR=
qiyxg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-02-14 6:30 GMT+03:00 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"=
mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</=
span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><span class=3D"">On s=C3=A1bado, 13 de fevereiro=
 de 2016 21:54:47 PST David Krauss wrote:<br>
&gt; Other platforms have long switched automatically between importing and=
<br>
&gt; exporting<br>
<br>
</span>I wish they wouldn&#39;t. The MS DLL model may be cumbersome, but it=
 generates the<br>
best code.</blockquote></div><br>Could you explain in more details, how the=
=C2=A0MS DLL model allows to generate a better code (comparing to a shared =
library compiled with -fvisibility=3Dhidden on GCC or Clang)?<br clear=3D"a=
ll"><div><br></div>-- <br><div class=3D"gmail_signature">Best regards,<br>A=
ntony Polukhin</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/CAKqmYPamDpt7C9Af7t54ncTL5opKRF7%3DdC=
O9P5-kw-0mRqiyxg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKqmYPamDpt7C9=
Af7t54ncTL5opKRF7%3DdCO9P5-kw-0mRqiyxg%40mail.gmail.com</a>.<br />

--001a114d76f4280c26052e2de8bc--

.