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

Hello,

Here's a draft proposal to add classes and functions for Dynamic Library
Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html

Proposal is based on Boost.DLL library.

Any comments and suggestions are welcomed!

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

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

<div dir=3D"ltr">Hello,<div><br></div><div><div>Here&#39;s a draft proposal=
 to add classes and functions for Dynamic Library Load: <a href=3D"http://a=
polukhin.github.io/papers/D0275R0:%20DLL%20proposal.html">http://apolukhin.=
github.io/papers/D0275R0:%20DLL%20proposal.html</a></div><div><br></div><di=
v>Proposal is based on Boost.DLL library.</div><div><br></div><div>Any comm=
ents and suggestions are welcomed!</div><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 />

--94eb2c032e60ef10c7052bac555a--

.

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

On 13 February 2016 at 21:07, Antony Polukhin <antoshkka@gmail.com> wrote:

> Hello,
>
> Here's a draft proposal to add classes and functions for Dynamic Library
> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html
>
> Proposal is based on Boost.DLL library.
>
> Any comments and suggestions are welcomed!
>
>
Hi, I hope that such library will make it into the standard asap.

A few comments:

1. The shared_library::unload() and related functions seems to have a
potentially misleading name.
It basically does de-referencing, not unloading.
I understand that the C library have an unloading function that have the
same behaviour
but I think in the long term it could make a user believe that the library
is effectively unloaded
when only one reference to it is actually unloaded.
This is not a strong issue but maybe consider another name?

2. I think that more details (maybe a dedicated paragraph, maybe another
paper) about why name mangling features
are not worth it. You say that existing attempts "Existing attempts to load
mangled symbol by unmangled name result in significant complexity and
memory usage growth and overall slowdown of loading symbol from library"
but I don't remember any report showing this.
In the end of the paper you mention an implementation on which you relied
to inform your decision,
so I think it would be useful (and maybe convince people) to provide more
information from this experience.

3. Doesn't this proposal require that you provide some definition of what a
dynamically loaded library is in the wording?
Maybe not, I'm not a language lawyer so it might be a good idea to avoid
defining it, but it's the only name you didn't define.

--

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

--001a1147127c6f401f052bb0aaf3
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">=
On 13 February 2016 at 21:07, Antony Polukhin <span dir=3D"ltr">&lt;<a href=
=3D"mailto:antoshkka@gmail.com" target=3D"_blank">antoshkka@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></div>=
<div><div>Here&#39;s a draft proposal to add classes and functions for Dyna=
mic Library Load: <a href=3D"http://apolukhin.github.io/papers/D0275R0:%20D=
LL%20proposal.html" target=3D"_blank">http://apolukhin.github.io/papers/D02=
75R0:%20DLL%20proposal.html</a></div><div><br></div><div>Proposal is based =
on Boost.DLL library.</div><div><br></div><div>Any comments and suggestions=
 are welcomed!</div><span class=3D""><font color=3D"#888888"><div><br></div=
></font></span></div></div></blockquote><div><br></div><div>Hi, I hope that=
 such library will make it into the standard asap.</div><div><br></div><div=
>A few comments:</div><div><br></div><div>1. The shared_library::unload() a=
nd related functions seems to have a potentially misleading name.</div><div=
>It basically does de-referencing, not unloading.</div><div>I understand th=
at the C library have an unloading function that have the same behaviour</d=
iv><div>but I think in the long term it could make a user believe that the =
library is effectively unloaded</div><div>when only one reference to it is =
actually unloaded.</div><div>This is not a strong issue but maybe consider =
another name?</div><div><br></div><div>2. I think that more details (maybe =
a dedicated paragraph, maybe another paper) about why name mangling feature=
s</div><div>are not worth it. You say that existing attempts &quot;Existing=
 attempts to load mangled symbol by unmangled name result in significant co=
mplexity and memory usage growth and overall slowdown of loading symbol fro=
m library&quot;</div><div>but I don&#39;t remember any report showing this.=
</div><div>In the end of the paper you mention an implementation on which y=
ou relied to inform your decision,</div><div>so I think it would be useful =
(and maybe convince people) to provide more information from this experienc=
e.</div><div><br></div><div>3. Doesn&#39;t this proposal require that you p=
rovide some definition of what a dynamically loaded library is in the wordi=
ng?</div><div>Maybe not, I&#39;m not a language lawyer so it might be a goo=
d idea to avoid defining it, but it&#39;s the only name you didn&#39;t defi=
ne.</div><div><br></div></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 />

--001a1147127c6f401f052bb0aaf3--

.

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

El 13/2/2016 17:07, "Antony Polukhin" <antoshkka@gmail.com> escribi=C3=B3:
>
> Hello,
>
> Here's a draft proposal to add classes and functions for Dynamic Library
Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html

I like the idea. Please consider to turn this feature somewhat optional so
some freestanding implementations or hosted (but embedded systems) where
this feature is not applicable can still be compliant.

>
> Proposal is based on Boost.DLL library.
>
> Any comments and suggestions are welcomed!
>
> --
> 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/.

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

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

<p dir=3D"ltr"><br>
El 13/2/2016 17:07, &quot;Antony Polukhin&quot; &lt;<a href=3D"mailto:antos=
hkka@gmail.com">antoshkka@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; Hello,<br>
&gt;<br>
&gt; Here&#39;s a draft proposal to add classes and functions for Dynamic L=
ibrary Load: <a href=3D"http://apolukhin.github.io/papers/D0275R0:%20DLL%20=
proposal.html">http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.=
html</a></p>
<p dir=3D"ltr">I like the idea. Please consider to turn this feature somewh=
at optional so some freestanding implementations or hosted (but embedded sy=
stems) where this feature is not applicable can still be compliant.</p>
<p dir=3D"ltr">&gt;<br>
&gt; Proposal is based on Boost.DLL library.<br>
&gt;<br>
&gt; Any comments and suggestions are welcomed!<br>
&gt;<br>
&gt; -- <br>
&gt; Best regards,<br>
&gt; Antony Polukhin<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; 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-prop=
osals/</a>.<br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--089e0111be8c5d151f052bb13d8d--

.

On s=C3=A1bado, 13 de fevereiro de 2016 22:58:42 PST dgutson . wrote:
> El 13/2/2016 17:07, "Antony Polukhin" <antoshkka@gmail.com> escribi=C3=B3=
:
> > Hello,
> >=20
> > Here's a draft proposal to add classes and functions for Dynamic Librar=
y
>=20
> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html
>=20
> I like the idea. Please consider to turn this feature somewhat optional s=
o
> some freestanding implementations or hosted (but embedded systems) where
> this feature is not applicable can still be compliant.

It would be compliant to fail to load anything :-)

We've just been through that with Qt. What does QLibrary do when you compil=
e=20
everything statically (including libc)?

One side of the argument is that you should allow the API butcause it to fa=
il,=20
so that existing code will compile and, so long as it doesn't require loadi=
ng=20
anything, will also work.

The other side was that many applications do require the ability to=20
dynamically load modules and therefore should fail to compile if the=20
functionality is missing, so the developer is aware of the need to provide =
an=20
alternative mechanism.

https://codereview.qt-project.org/147582

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

.

On s=C3=A1bado, 13 de fevereiro de 2016 23:07:39 PST Antony Polukhin wrote:
> Hello,
>=20
> Here's a draft proposal to add classes and functions for Dynamic Library
> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html
>=20
> Proposal is based on Boost.DLL library.
>=20
> Any comments and suggestions are welcomed!

Please clarify whether dll_mode::search_system_folders will search system=
=20
folders *in* *addition* to what would have otherwise been searched, or whet=
her=20
it will *only* search system folders. The latter case is quite important on=
=20
some systems, especially Windows, since the underlying system API will look=
=20
for the libraries in the current directory, which may lead to attacks.

I'd also suggest a flag that forces the library never to be unloaded. On PO=
SIX=20
systems, that would set RTLD_NODELETE; where not possible, it would simply=
=20
never unload (leaking allowed). There are quite a few crashes we've faced i=
n=20
Qt due to pointers to unloaded data dangling after the unload.

> 31.3.3.3 shared_library assignment [dll.shared_library.assign]

> Effects: If this->is_loaded() then calls this->unload(), then assigns the
> state of lib to *this and sets lib to a default constructed state. Remark=
s:
> Does not invalidate existing symbols and functions loaded from lib.

Well, if you unload, then existing symbols and functions loaded from that l=
ib=20
will be affected. So the effects seem incorrect to me.


> template <typename SymbolT>
> decltype(auto) get(const char* symbol_name) const;
>=20
> template <typename SymbolT>
> decltype(auto) get(const string& symbol_name) const;
>=20
> Return type: SymbolT& if SymbolT is a type, function signature of functio=
n
> pointer; SymbolT if SymbolT is a member function pointer.

That's a really weird way of declaring the return type. The decltype(auto)=
=20
return type only makes sense with a trailing declaration or a function body=
,=20
neither of which are present in the document. The text is a little confusin=
g=20
and isn't visible when you're just reading the class declaration.

I'd advise you to expand it so we can actually see the types. If necessary,=
=20
use concepts.

Another thing: on at least one platform (Windows CE), the symbol name is=20
actually encoded in UTF-16, not 8-bit. You should probably write that=20
conversion, if any,  is implementation-defined and must be documented by th=
e=20
implementation.

> Throws: As specified in [dll.errors]

The overload with error_code is missing. This is true for a lot of the=20
members.

>      native_handle_t native() const noexcept;

I would call this function "handle", not "native". There are many things th=
at=20
could be native in shared libraries (like native file names), but there's=
=20
usually one handle.

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

.

On 2/13/2016 2:07 PM, Antony Polukhin wrote:
> Here's a draft proposal to add classes and functions for Dynamic Library
> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html
>
> Proposal is based on Boost.DLL library.

While I have no strong feelings on the proposal itself, I'm glad to see
there's work to provide access to more platform-specific things in the
C++ standard library. I've been meaning to write up a proposal to add an
iostream class to use native file descriptors (FDs on POSIX and HANDLEs
on Windows), but haven't had the time. It's one of a very small number
of things I still need Boost for.

- Jim


--

---
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_3935_287863535.1455453425606
Content-Type: multipart/alternative;
 boundary="----=_Part_3936_352752889.1455453425606"

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

Just as a side note: won't the function import cause problems? The already=
=20
Modules TS introduces the keyword import and probably not as a contextual=
=20
keyword. I would have to read the proposal again but I am fairy sure it=20
might cause some problems.

Le samedi 13 f=C3=A9vrier 2016 21:07:42 UTC+1, Antony Polukhin a =C3=A9crit=
 :
>
> Hello,
>
> Here's a draft proposal to add classes and functions for Dynamic Library=
=20
> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html
>
> Proposal is based on Boost.DLL library.
>
> Any comments and suggestions are welcomed!
>
> --=20
> Best regards,
> Antony Polukhin
>

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

<div dir=3D"ltr">Just as a side note: won&#39;t the function <span style=3D=
"font-family: courier new,monospace;">import</span> cause problems? The alr=
eady Modules TS introduces the keyword <span style=3D"font-family: courier =
new,monospace;">import</span> and probably not as a contextual keyword. I w=
ould have to read the proposal again but I am fairy sure it might cause som=
e problems.<br><br>Le samedi 13 f=C3=A9vrier 2016 21:07:42 UTC+1, Antony Po=
lukhin a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr">Hello,<div><br></div><div><div>Here&#39;s a draft proposal to =
add classes and functions for Dynamic Library Load: <a href=3D"http://apolu=
khin.github.io/papers/D0275R0:%20DLL%20proposal.html" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fapolukhin.github.io%2Fpapers%2FD0275R0%3A%2520DLL%2520proposa=
l.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHYHIelbkaiCmUvSQThq9kuT0N50g&#39;=
;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75ht=
tp%3A%2F%2Fapolukhin.github.io%2Fpapers%2FD0275R0%3A%2520DLL%2520proposal.h=
tml\46sa\75D\46sntz\0751\46usg\75AFQjCNHYHIelbkaiCmUvSQThq9kuT0N50g&#39;;re=
turn true;">http://apolukhin.github.io/<wbr>papers/D0275R0:%20DLL%<wbr>20pr=
oposal.html</a></div><div><br></div><div>Proposal is based on Boost.DLL lib=
rary.</div><div><br></div><div>Any comments and suggestions are welcomed!</=
div><div><br></div>-- <br><div>Best regards,<br>Antony Polukhin</div>
</div></div>
</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_3936_352752889.1455453425606--
------=_Part_3935_287863535.1455453425606--

.

On 2016-02-14 07:37, Morwenn wrote:
> Just as a side note: won't the function import cause problems? The already
> Modules TS introduces the keyword import and probably not as a contextual
> keyword.

I hope not; that's going to break quite a bit of code. (Just from some
casual searching of code I happen to have checked out, there are a fair
number of uses of "import" as a variable/parameter name, method name...)

One particularly notable example comes from boost/python/import.hpp.

--
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_1072_1280128039.1455563447770
Content-Type: multipart/alternative;
 boundary="----=_Part_1073_851992779.1455563447771"

------=_Part_1073_851992779.1455563447771
Content-Type: text/plain; charset=UTF-8

On Monday, February 15, 2016 at 11:12:47 AM UTC-5, Matthew Woehlke wrote:
>
> On 2016-02-14 07:37, Morwenn wrote:
> > Just as a side note: won't the function import cause problems? The
> already
> > Modules TS introduces the keyword import and probably not as a
> contextual
> > keyword.
>
> I hope not; that's going to break quite a bit of code. (Just from some
> casual searching of code I happen to have checked out, there are a fair
> number of uses of "import" as a variable/parameter name, method name...)
>

You could probably say the same thing about the word "module" too. Good
luck bikeshedding P0143...

--

---
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_1073_851992779.1455563447771
Content-Type: text/html; charset=UTF-8

<div dir="ltr">On Monday, February 15, 2016 at 11:12:47 AM UTC-5, Matthew Woehlke wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-02-14 07:37, Morwenn wrote:
<br>&gt; Just as a side note: won&#39;t the function import cause problems? The already
<br>&gt; Modules TS introduces the keyword import and probably not as a contextual
<br>&gt; keyword.
<br>
<br>I hope not; that&#39;s going to break quite a bit of code. (Just from some
<br>casual searching of code I happen to have checked out, there are a fair
<br>number of uses of &quot;import&quot; as a variable/parameter name, method name...)<br></blockquote><div><br>You could probably say the same thing about the word &quot;module&quot; too. Good luck bikeshedding P0143...<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="https://groups.google.com/a/isocpp.org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_1073_851992779.1455563447771--
------=_Part_1072_1280128039.1455563447770--

.

On 2016-02-15 14:10, Nicol Bolas wrote:
> On Monday, February 15, 2016 at 11:12:47 AM UTC-5, Matthew Woehlke wrote:
>> On 2016-02-14 07:37, Morwenn wrote:
>>> Just as a side note: won't the function import cause problems?
>>> The already Modules TS introduces the keyword import and probably
>>> not as a contextual keyword.
>>
>> I hope not; that's going to break quite a bit of code. (Just from some
>> casual searching of code I happen to have checked out, there are a fair
>> number of uses of "import" as a variable/parameter name, method name...)
>
> You could probably say the same thing about the word "module" too. Good
> luck bikeshedding P0143...

Does it need to be a *non-context-sensitive* keyword, though? Related to
modules, it is the first token in an expression (and must not be in a
scope), no? That seems like fairly straight forward context. It would
preclude using "import" as a type to declare a global variable, but I'm
confident those are the vast minority of existing uses of "import".

(Thinking of the recent post on attributes, if we wanted to be
absolutely certain of no conflicts, we could use '@import' :-).)

--
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_348_1745251431.1455594202974
Content-Type: multipart/alternative;
 boundary="----=_Part_349_659845379.1455594202974"

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

On Saturday, February 13, 2016 at 12:07:42 PM UTC-8, Antony Polukhin wrote:
>
> Hello,
>
> Here's a draft proposal to add classes and functions for Dynamic Library=
=20
> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html=20
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fapolukhin.github.io%2Fpapers%=
2FD0275R0%3A%2520DLL%2520proposal.html&sa=3DD&sntz=3D1&usg=3DAFQjCNHYHIelbk=
aiCmUvSQThq9kuT0N50g>
>

I've never used Boost.DLL, so take my comments with a grain of salt.

I was struck by the fact that you're calling the fundamental type here=20
shared_library, but by that you don't mean to imply "Linux-style *shared=20
object*"; what you mean is something like shared_ptr =E2=80=94 reference-co=
unted,=20
heap-allocated, etc. etc.
I think there's a more primitive abstraction here =E2=80=94 call it library=
 =E2=80=94 that=20
does RAII but not reference-counting. Then shared_library might be as=20
simple as a typedef for shared_ptr<library>.

Certainly shared_library::unload() should be spelled reset(); is_loaded()=
=20
should probably be spelled operator!=3D(nullptr_t); and by analogy with=20
std::map, get() should be spelled at(). (There's already a couple of get()s=
=20
in the STL, and neither of them behave like what you're describing. You're=
=20
describing basically a key-value store. That's the domain of member=20
function at().)

The functions this_line_location, program_location, etc., should be=20
harmonized with std::experimental::source_location=20
<http://en.cppreference.com/w/cpp/experimental/source_location> as much as=
=20
possible. I'm not sure what that means, exactly, but it probably means=20
something.

You need to specify the semantics of what it means to "load" a DLL. I=20
assume that the DLL's global objects get initialized. What happens if a=20
global object's initializer throws? Can the caller of=20
shared_library::shared_library(...) catch that exception? What are the=20
semantics of thread_local variables in a DLL? These *may* be solved=20
problems in the real world, but the Standard doesn't say anything about=20
them right now, and it needs to say something, if we're going to=20
standardize DLL loading.

When you say "Destructors throw nothing", do you mean that a failure inside=
=20
a destructor will go unreported? or that failure in a destructor will cause=
=20
program termination? or that all of the destructors in your proposal are=20
non-throwing by design? You should clarify that.

my $.02,
=E2=80=93Arthur

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

<div dir=3D"ltr">On Saturday, February 13, 2016 at 12:07:42 PM UTC-8, Anton=
y Polukhin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Hello,<div><br></div><div><div>Here&#39;s a draft proposal to add class=
es and functions for Dynamic Library Load: <a href=3D"http://www.google.com=
/url?q=3Dhttp%3A%2F%2Fapolukhin.github.io%2Fpapers%2FD0275R0%3A%2520DLL%252=
0proposal.html&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHYHIelbkaiCmUvSQThq9=
kuT0N50g" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\75http%3A%2F%2Fapolukhin.github.io%2Fpapers%2=
FD0275R0%3A%2520DLL%2520proposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHY=
HIelbkaiCmUvSQThq9kuT0N50g&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\75http%3A%2F%2Fapolukhin.github.io%2Fpapers%2FD0=
275R0%3A%2520DLL%2520proposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHYHIe=
lbkaiCmUvSQThq9kuT0N50g&#39;;return true;">http://apolukhin.github.io/<wbr>=
papers/D0275R0:%20DLL%<wbr>20proposal.html</a></div></div></div></blockquot=
e><div><br></div><div>I&#39;ve never used Boost.DLL, so take my comments wi=
th a grain of salt.</div><div><br></div><div>I was struck by the fact that =
you&#39;re calling the fundamental type here <font face=3D"courier new, mon=
ospace">shared_library</font>, but by that you don&#39;t mean to imply &quo=
t;Linux-style <i>shared object</i>&quot;; what you mean is something like=
=C2=A0<font face=3D"courier new, monospace">shared_ptr</font> =E2=80=94 ref=
erence-counted, heap-allocated, etc. etc.</div><div>I think there&#39;s a m=
ore primitive abstraction here =E2=80=94 call it <font face=3D"courier new,=
 monospace">library</font> =E2=80=94 that does RAII but not reference-count=
ing. Then <font face=3D"courier new, monospace">shared_library</font> might=
 be as simple as a typedef for <font face=3D"courier new, monospace">shared=
_ptr&lt;library&gt;</font>.</div><div><br></div><div>Certainly <font face=
=3D"courier new, monospace">shared_library::unload()</font> should be spell=
ed <font face=3D"courier new, monospace">reset()</font>; <font face=3D"cour=
ier new, monospace">is_loaded()</font> should probably be spelled <font fac=
e=3D"courier new, monospace">operator!=3D(nullptr_t)</font>; and by analogy=
 with <font face=3D"courier new, monospace">std::map</font>, <font face=3D"=
courier new, monospace">get()</font> should be spelled <font face=3D"courie=
r new, monospace">at()</font>. (There&#39;s already a couple of=C2=A0<font =
face=3D"courier new, monospace">get()</font>s in the STL, and neither of th=
em behave like what you&#39;re describing. You&#39;re describing basically =
a key-value store. That&#39;s the domain of member function <font face=3D"c=
ourier new, monospace">at()</font>.)</div><div><br></div><div>The functions=
 <font face=3D"courier new, monospace">this_line_location</font>, <font fac=
e=3D"courier new, monospace">program_location</font>, etc., should be harmo=
nized with <font face=3D"courier new, monospace"><a href=3D"http://en.cppre=
ference.com/w/cpp/experimental/source_location">std::experimental::source_l=
ocation</a></font> as much as possible. I&#39;m not sure what that means, e=
xactly, but it probably means something.</div><div><br></div><div>You need =
to specify the semantics of what it means to &quot;load&quot; a DLL. I assu=
me that the DLL&#39;s global objects get initialized. What happens if a glo=
bal object&#39;s initializer throws? Can the caller of <font face=3D"courie=
r new, monospace">shared_library::shared_library(...)</font> catch that exc=
eption? What are the semantics of <font face=3D"courier new, monospace">thr=
ead_local</font> variables in a DLL? These <i>may</i> be solved problems in=
 the real world, but the Standard doesn&#39;t say anything about them right=
 now, and it needs to say something, if we&#39;re going to standardize DLL =
loading.</div><div><br></div><div>When you say &quot;Destructors throw noth=
ing&quot;, do you mean that a failure inside a destructor will go unreporte=
d? or that failure in a destructor will cause program termination? or that =
all of the destructors in your proposal are non-throwing by design? You sho=
uld clarify that.</div><div><br></div><div>my $.02,</div><div>=E2=80=93Arth=
ur</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_349_659845379.1455594202974--
------=_Part_348_1745251431.1455594202974--

.

------=_Part_6354_851461956.1455600010259
Content-Type: multipart/alternative;
 boundary="----=_Part_6355_936093650.1455600010259"

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

On Monday, February 15, 2016 at 10:43:23 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Saturday, February 13, 2016 at 12:07:42 PM UTC-8, Antony Polukhin wrot=
e:
>>
>> Hello,
>>
>> Here's a draft proposal to add classes and functions for Dynamic Library=
=20
>> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html=
=20
>> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fapolukhin.github.io%2Fpapers=
%2FD0275R0%3A%2520DLL%2520proposal.html&sa=3DD&sntz=3D1&usg=3DAFQjCNHYHIelb=
kaiCmUvSQThq9kuT0N50g>
>>
>
> I've never used Boost.DLL, so take my comments with a grain of salt.
>
> I was struck by the fact that you're calling the fundamental type here=20
> shared_library, but by that you don't mean to imply "Linux-style *shared=
=20
> object*"; what you mean is something like shared_ptr =E2=80=94 reference-=
counted,=20
> heap-allocated, etc. etc.
> I think there's a more primitive abstraction here =E2=80=94 call it libra=
ry =E2=80=94=20
> that does RAII but not reference-counting. Then shared_library might be=
=20
> as simple as a typedef for shared_ptr<library>.
>
> Certainly shared_library::unload() should be spelled reset(); is_loaded()=
=20
> should probably be spelled operator!=3D(nullptr_t); and by analogy with=
=20
> std::map, get() should be spelled at(). (There's already a couple of get(=
)s=20
> in the STL, and neither of them behave like what you're describing. You'r=
e=20
> describing basically a key-value store. That's the domain of member=20
> function at().)
>

The issue here I think is that you can have two parts of the program that=
=20
both load the same library. And you don't want them to be talking about=20
different objects. You don't want to load the same DLL twice, and you don't=
=20
want to unload the DLL until all users of the shared library have released=
=20
it. So they are sharing access to the library.

With your way, you can't get that without those two parts of code coming=20
into contact with each other. Which means you now need to define what it=20
means for two pieces of code to load the same DLL. I don't know about=20
Linux, but I'm fairly sure in Windows, if you call "LoadLibrary" on=20
something that's already loaded, it just bumps the internal reference count=
=20
on the handle and returns it to you.

Also, there is the issue of loading a (using Windows terms) DLL which was=
=20
loaded because you statically linked to an import library. This is a=20
perfectly valid way to get at the DLL's handle. But you can't "unload" such=
=20
a library; you can only release your handle to it. It is *inherently*=20
shared.

So there is no effective way to have a pure "library" type that doesn't at=
=20
some level share ownership.

Now I agree that `shared_library` as a name does create some confusion. But=
=20
it does fit with other standard library types like `shared_lock` and=20
`shared_future`.

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

<div dir=3D"ltr">On Monday, February 15, 2016 at 10:43:23 PM UTC-5, Arthur =
O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Saturday, February 13, 2016 at 12:07:42 PM UTC-8, Antony Polukhin w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<div><b=
r></div><div><div>Here&#39;s a draft proposal to add classes and functions =
for Dynamic Library Load: <a href=3D"http://www.google.com/url?q=3Dhttp%3A%=
2F%2Fapolukhin.github.io%2Fpapers%2FD0275R0%3A%2520DLL%2520proposal.html&am=
p;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHYHIelbkaiCmUvSQThq9kuT0N50g" rel=3D"=
nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.goog=
le.com/url?q\75http%3A%2F%2Fapolukhin.github.io%2Fpapers%2FD0275R0%3A%2520D=
LL%2520proposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHYHIelbkaiCmUvSQThq=
9kuT0N50g&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.=
com/url?q\75http%3A%2F%2Fapolukhin.github.io%2Fpapers%2FD0275R0%3A%2520DLL%=
2520proposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHYHIelbkaiCmUvSQThq9ku=
T0N50g&#39;;return true;">http://apolukhin.github.io/<wbr>papers/D0275R0:%2=
0DLL%<wbr>20proposal.html</a></div></div></div></blockquote><div><br></div>=
<div>I&#39;ve never used Boost.DLL, so take my comments with a grain of sal=
t.</div><div><br></div><div>I was struck by the fact that you&#39;re callin=
g the fundamental type here <font face=3D"courier new, monospace">shared_li=
brary</font>, but by that you don&#39;t mean to imply &quot;Linux-style <i>=
shared object</i>&quot;; what you mean is something like=C2=A0<font face=3D=
"courier new, monospace">shared_ptr</font> =E2=80=94 reference-counted, hea=
p-allocated, etc. etc.</div><div>I think there&#39;s a more primitive abstr=
action here =E2=80=94 call it <font face=3D"courier new, monospace">library=
</font> =E2=80=94 that does RAII but not reference-counting. Then <font fac=
e=3D"courier new, monospace">shared_library</font> might be as simple as a =
typedef for <font face=3D"courier new, monospace">shared_ptr&lt;library&gt;=
</font>.</div><div><br></div><div>Certainly <font face=3D"courier new, mono=
space">shared_library::unload()</font> should be spelled <font face=3D"cour=
ier new, monospace">reset()</font>; <font face=3D"courier new, monospace">i=
s_loaded()</font> should probably be spelled <font face=3D"courier new, mon=
ospace">operator!=3D(nullptr_t)</font>; and by analogy with <font face=3D"c=
ourier new, monospace">std::map</font>, <font face=3D"courier new, monospac=
e">get()</font> should be spelled <font face=3D"courier new, monospace">at(=
)</font>. (There&#39;s already a couple of=C2=A0<font face=3D"courier new, =
monospace">get()</font>s in the STL, and neither of them behave like what y=
ou&#39;re describing. You&#39;re describing basically a key-value store. Th=
at&#39;s the domain of member function <font face=3D"courier new, monospace=
">at()</font>.)</div></div></blockquote><div><br>The issue here I think is =
that you can have two parts of the program that both load the same library.=
 And you don&#39;t want them to be talking about different objects. You don=
&#39;t want to load the same DLL twice, and you don&#39;t want to unload th=
e DLL until all users of the shared library have released it. So they are s=
haring access to the library.<br><br>With your way, you can&#39;t get that =
without those two parts of code coming into contact with each other. Which =
means you now need to define what it means for two pieces of code to load t=
he same DLL. I don&#39;t know about Linux, but I&#39;m fairly sure in Windo=
ws, if you call &quot;LoadLibrary&quot; on something that&#39;s already loa=
ded, it just bumps the internal reference count on the handle and returns i=
t to you.<br><br>Also, there is the issue of loading a (using Windows terms=
) DLL which was loaded because you statically linked to an import library. =
This is a perfectly valid way to get at the DLL&#39;s handle. But you can&#=
39;t &quot;unload&quot; such a library; you can only release your handle to=
 it. It is <i>inherently</i> shared.<br><br>So there is no effective way to=
 have a pure &quot;library&quot; type that doesn&#39;t at some level share =
ownership.<br><br>Now I agree that `shared_library` as a name does create s=
ome confusion. But it does fit with other standard library types like `shar=
ed_lock` and `shared_future`.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_6355_936093650.1455600010259--
------=_Part_6354_851461956.1455600010259--

.

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

Are there any plans to look at attributes like dllimport or dllexport?

While most compilers implement them in some form or other, the lack of
standardization has been a source of troubles.

There are many issues to be looked at regarding these. How they interact;
how they get propagated up or down from classes to members or from members
to classes etc.

Sunil Srivastava
Sony Computer Entertainment

On Mon, Feb 15, 2016 at 9:20 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, February 15, 2016 at 10:43:23 PM UTC-5, Arthur O'Dwyer wrote:
>>
>> On Saturday, February 13, 2016 at 12:07:42 PM UTC-8, Antony Polukhin
>> wrote:
>>>
>>> Hello,
>>>
>>> Here's a draft proposal to add classes and functions for Dynamic Librar=
y
>>> Load: http://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html
>>> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fapolukhin.github.io%2Fpaper=
s%2FD0275R0%3A%2520DLL%2520proposal.html&sa=3DD&sntz=3D1&usg=3DAFQjCNHYHIel=
bkaiCmUvSQThq9kuT0N50g>
>>>
>>
>> I've never used Boost.DLL, so take my comments with a grain of salt.
>>
>> I was struck by the fact that you're calling the fundamental type here
>> shared_library, but by that you don't mean to imply "Linux-style *shared
>> object*"; what you mean is something like shared_ptr =E2=80=94
>> reference-counted, heap-allocated, etc. etc.
>> I think there's a more primitive abstraction here =E2=80=94 call it libr=
ary =E2=80=94
>> that does RAII but not reference-counting. Then shared_library might be
>> as simple as a typedef for shared_ptr<library>.
>>
>> Certainly shared_library::unload() should be spelled reset(); is_loaded(=
)
>> should probably be spelled operator!=3D(nullptr_t); and by analogy with
>> std::map, get() should be spelled at(). (There's already a couple of
>> get()s in the STL, and neither of them behave like what you're
>> describing. You're describing basically a key-value store. That's the
>> domain of member function at().)
>>
>
> The issue here I think is that you can have two parts of the program that
> both load the same library. And you don't want them to be talking about
> different objects. You don't want to load the same DLL twice, and you don=
't
> want to unload the DLL until all users of the shared library have release=
d
> it. So they are sharing access to the library.
>
> With your way, you can't get that without those two parts of code coming
> into contact with each other. Which means you now need to define what it
> means for two pieces of code to load the same DLL. I don't know about
> Linux, but I'm fairly sure in Windows, if you call "LoadLibrary" on
> something that's already loaded, it just bumps the internal reference cou=
nt
> on the handle and returns it to you.
>
> Also, there is the issue of loading a (using Windows terms) DLL which was
> loaded because you statically linked to an import library. This is a
> perfectly valid way to get at the DLL's handle. But you can't "unload" su=
ch
> a library; you can only release your handle to it. It is *inherently*
> shared.
>
> So there is no effective way to have a pure "library" type that doesn't a=
t
> some level share ownership.
>
> Now I agree that `shared_library` as a name does create some confusion.
> But it does fit with other standard library types like `shared_lock` and
> `shared_future`.
>
> --
>
> ---
> 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/.
>

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

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

<div dir=3D"ltr">Are there any plans to look at attributes like dllimport o=
r dllexport?<div><br></div><div>While most compilers implement them in some=
 form or other, the lack of standardization has been a source of troubles.<=
/div><div><br></div><div>There are many issues to be looked at regarding th=
ese. How they interact; how they get propagated up or down from classes to =
members or from members to classes etc.</div><div><br></div><div>Sunil Sriv=
astava</div><div>Sony Computer Entertainment</div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Mon, Feb 15, 2016 at 9:20 PM, Nic=
ol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" targe=
t=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span class=3D"">On Monday, February 15, 201=
6 at 10:43:23 PM UTC-5, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Saturday, February 13, 2016 at 12:07:42 P=
M UTC-8, Antony Polukhin wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">Hello,<div><br></div><div><div>Here&#39;s a draft proposal to =
add classes and functions for Dynamic Library Load: <a href=3D"http://www.g=
oogle.com/url?q=3Dhttp%3A%2F%2Fapolukhin.github.io%2Fpapers%2FD0275R0%3A%25=
20DLL%2520proposal.html&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHYHIelbkaiC=
mUvSQThq9kuT0N50g" rel=3D"nofollow" target=3D"_blank">http://apolukhin.gith=
ub.io/papers/D0275R0:%20DLL%20proposal.html</a></div></div></div></blockquo=
te><div><br></div><div>I&#39;ve never used Boost.DLL, so take my comments w=
ith a grain of salt.</div><div><br></div><div>I was struck by the fact that=
 you&#39;re calling the fundamental type here <font face=3D"courier new, mo=
nospace">shared_library</font>, but by that you don&#39;t mean to imply &qu=
ot;Linux-style <i>shared object</i>&quot;; what you mean is something like=
=C2=A0<font face=3D"courier new, monospace">shared_ptr</font> =E2=80=94 ref=
erence-counted, heap-allocated, etc. etc.</div><div>I think there&#39;s a m=
ore primitive abstraction here =E2=80=94 call it <font face=3D"courier new,=
 monospace">library</font> =E2=80=94 that does RAII but not reference-count=
ing. Then <font face=3D"courier new, monospace">shared_library</font> might=
 be as simple as a typedef for <font face=3D"courier new, monospace">shared=
_ptr&lt;library&gt;</font>.</div><div><br></div><div>Certainly <font face=
=3D"courier new, monospace">shared_library::unload()</font> should be spell=
ed <font face=3D"courier new, monospace">reset()</font>; <font face=3D"cour=
ier new, monospace">is_loaded()</font> should probably be spelled <font fac=
e=3D"courier new, monospace">operator!=3D(nullptr_t)</font>; and by analogy=
 with <font face=3D"courier new, monospace">std::map</font>, <font face=3D"=
courier new, monospace">get()</font> should be spelled <font face=3D"courie=
r new, monospace">at()</font>. (There&#39;s already a couple of=C2=A0<font =
face=3D"courier new, monospace">get()</font>s in the STL, and neither of th=
em behave like what you&#39;re describing. You&#39;re describing basically =
a key-value store. That&#39;s the domain of member function <font face=3D"c=
ourier new, monospace">at()</font>.)</div></div></blockquote></span><div><b=
r>The issue here I think is that you can have two parts of the program that=
 both load the same library. And you don&#39;t want them to be talking abou=
t different objects. You don&#39;t want to load the same DLL twice, and you=
 don&#39;t want to unload the DLL until all users of the shared library hav=
e released it. So they are sharing access to the library.<br><br>With your =
way, you can&#39;t get that without those two parts of code coming into con=
tact with each other. Which means you now need to define what it means for =
two pieces of code to load the same DLL. I don&#39;t know about Linux, but =
I&#39;m fairly sure in Windows, if you call &quot;LoadLibrary&quot; on some=
thing that&#39;s already loaded, it just bumps the internal reference count=
 on the handle and returns it to you.<br><br>Also, there is the issue of lo=
ading a (using Windows terms) DLL which was loaded because you statically l=
inked to an import library. This is a perfectly valid way to get at the DLL=
&#39;s handle. But you can&#39;t &quot;unload&quot; such a library; you can=
 only release your handle to it. It is <i>inherently</i> shared.<br><br>So =
there is no effective way to have a pure &quot;library&quot; type that does=
n&#39;t at some level share ownership.<br><br>Now I agree that `shared_libr=
ary` as a name does create some confusion. But it does fit with other stand=
ard library types like `shared_lock` and `shared_future`.<br></div></div><d=
iv class=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11c2f6826389b8052bfb37cc--

.

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

Great thanks for all your comments!


Big update of the proposal draft (2016-02-17). Changes:
* cleaned up terminology:
    * clarified terms 'shared library', 'dynamic library load'
    * replaced (module, library, shared object, ...) -> shared library file
    * replaced (imported symbol, loaded symbol, ...) -> symbol obtained
from shared library file
    * replaced (executable, binary, ...) -> program
* renamed unload() to reset()
* renamed native() to handle()
* dropped is_loaded() function
* clarified the dll_mode::search_system_directories behavior
* added notes about the extensibility of dll_mode with user's types
* updated the "III. Design Decisions" with information on obtaining mangled
symbols by unmangled names
* better description for load() functions
* multiple other minor cleanups

TODO:
* fix the signature of shared_library::get<>() functions

If you'll find any other issues or wish to comment some parts of the
proposal draft, please do not hesitate!



Comments that were not addressed by changes:

> dgutson
> Please consider to turn this feature somewhat optional so some
freestanding implementations or hosted (but embedded systems) where this
feature is not applicable can still be compliant.

I've took a look into the std::thread and found nothing about making
threads optional (probably I've missed something). Just followed the
example of std::thread in draft proposal.

> Thiago Macieira
> Another thing: on at least one platform (Windows CE), the symbol name is
actually encoded in UTF-16, not 8-bit. You should probably write that
conversion, if any,  is implementation-defined and must be documented by th=
e
implementation.

Windows CE also has the GetProcAddressA
https://msdn.microsoft.com/ru-ru/library/ms885634.aspx
I'd rather not mention conversions at all as there's no restrictions on
implementations to do that.

> Morwenn
> Just as a side note: won't the function import cause problems? The
already Modules TS introduces the keyword import and probably not as a
contextual keyword. I would have to read the proposal again but I am fairy
sure it might cause some problems.

I really hope that this issue will be resolved in Modules proposal and all
the new keywords will be context-sensitive. Otherwise a lot of code will be
broken.

> Arthur O'Dwyer
> I've never used Boost.DLL, so take my comments with a grain of salt.

Actually, Boost.DLL will appear only in next release of Boost (version
1.61). This draft proposal won't be submitted to the Standard Committee
until I'll get some responses from field/Boost users.

> I was struck by the fact that you're calling the fundamental type here
shared_library, but by that you don't mean to imply "Linux-style shared
object"; what you mean is something like shared_ptr =E2=80=94 reference-cou=
nted,
heap-allocated, etc. etc.
> I think there's a more primitive abstraction here =E2=80=94 call it libra=
ry =E2=80=94
that does RAII but not reference-counting. Then shared_library might be as
simple as a typedef for shared_ptr<library>.

The problem is that the same shared library file "libmy_shared.so" could be
loaded multiple times:
    shared_library lib1("./libmy_shared.so");
    const int* i;
    {
        shared_library lib2("./libmy_shared.so");
        i =3D lib2.get<const int*>("integer");
        // lib2 is destroyed. OK to use `i`, while lib1 still references
the "./libmy_shared.so"
    }
    std::cerr << *i;

`shared_` could not be cut of from `shared_library`, because it is actually
shared.


> Certainly shared_library::unload() should be spelled reset(); is_loaded()
should probably be spelled operator!=3D(nullptr_t); and by analogy with
std::map, get() should be spelled at(). (There's already a couple of get()s
in the STL, and neither of them behave like what you're describing. You're
describing basically a key-value store. That's the domain of member
function at().)

All the at() functions in the current Standard are not templated, so
get<>() seems more right. Actually, it can be made a free function (just
like for tuple/array). But all the free standing get<>() accept only one
parameter, while we'll need two for shared_library (shared_library instance
and symbol_name).

I did not provided the constructors/comparisons/reset functions that
acccept nullptr_t because that may cause confusion: in POSIX dlopen() can
actually accept NULL and it is a valid parameter that will load the current
program. (added that note into the draft proposal)

> The functions this_line_location, program_location, etc., should be
harmonized with std::experimental::source_location as much as possible. I'm
not sure what that means, exactly, but it probably means something.

std::experimental::source_location returns source file name.
this_line_location() returns location of shared library file or program
that contains the line (for example "/usr/lib/libplugin.so").
Could you explain, what exactly must be clarified in proposal, to avoid
confusion with std::experimental::source_location?

> When you say "Destructors throw nothing", do you mean that a failure
inside a destructor will go unreported?

That the destructor newer throws and always succeeds. Just like all the
destructors in the Standard do, unless specified otherwise. Shall I use
some other words to clarify that in draft proposal?



--=20
Best regards,
Antony Polukhin

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

--94eb2c088338175ad2052bfc3daf
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=
>Great thanks for all your comments!</div><div><br></div><div><br></div><di=
v>Big update of the proposal draft (2016-02-17). Changes:</div><div>* clean=
ed up terminology:</div><div>=C2=A0 =C2=A0 * clarified terms &#39;shared li=
brary&#39;, &#39;dynamic library load&#39;</div><div>=C2=A0 =C2=A0 * replac=
ed (module, library, shared object, ...) -&gt; shared library file</div><di=
v>=C2=A0 =C2=A0 * replaced (imported symbol, loaded symbol, ...) -&gt; symb=
ol obtained from shared library file</div><div>=C2=A0 =C2=A0 * replaced (ex=
ecutable, binary, ...) -&gt; program</div><div>* renamed unload() to reset(=
)</div><div>* renamed native() to handle()</div><div>* dropped is_loaded() =
function</div><div>* clarified the dll_mode::search_system_directories beha=
vior</div><div>* added notes about the extensibility of dll_mode with user&=
#39;s types</div><div>* updated the &quot;III. Design Decisions&quot; with =
information on obtaining mangled symbols by unmangled names</div><div>* bet=
ter description for load() functions</div><div>* multiple other minor clean=
ups</div><div><br></div><div>TODO:</div><div>* fix the signature of shared_=
library::get&lt;&gt;() functions</div><div><br></div><div>If you&#39;ll fin=
d any other issues or wish to comment some parts of the proposal draft, ple=
ase do not hesitate!</div><div><br></div><div><br></div><div><br></div><div=
>Comments that were not addressed by changes:</div><div><br></div><div>&gt;=
 dgutson</div><div>&gt; Please consider to turn this feature somewhat optio=
nal so some freestanding implementations or hosted (but embedded systems) w=
here this feature is not applicable can still be compliant.</div><div><br><=
/div><div>I&#39;ve took a look into the std::thread and found nothing about=
 making threads optional (probably I&#39;ve missed something). Just followe=
d the example of std::thread in draft proposal.</div><div><br></div><div>&g=
t; Thiago Macieira</div><div>&gt; Another thing: on at least one platform (=
Windows CE), the symbol name is</div><div>actually encoded in UTF-16, not 8=
-bit. You should probably write that</div><div>conversion, if any, =C2=A0is=
 implementation-defined and must be documented by the</div><div>implementat=
ion.=C2=A0</div><div><br></div><div>Windows CE also has the GetProcAddressA=
 <a href=3D"https://msdn.microsoft.com/ru-ru/library/ms885634.aspx">https:/=
/msdn.microsoft.com/ru-ru/library/ms885634.aspx</a></div><div>I&#39;d rathe=
r not mention conversions at all as there&#39;s no restrictions on implemen=
tations to do that.</div><div><br></div><div>&gt; Morwenn</div><div>&gt; Ju=
st as a side note: won&#39;t the function import cause problems? The alread=
y Modules TS introduces the keyword import and probably not as a contextual=
 keyword. I would have to read the proposal again but I am fairy sure it mi=
ght cause some problems.</div><div><br></div><div>I really hope that this i=
ssue will be resolved in Modules proposal and all the new keywords will be =
context-sensitive. Otherwise a lot of code will be broken.</div><div><br></=
div><div>&gt; Arthur O&#39;Dwyer</div><div>&gt; I&#39;ve never used Boost.D=
LL, so take my comments with a grain of salt.</div><div><br></div><div>Actu=
ally, Boost.DLL will appear only in next release of Boost (version 1.61). T=
his draft proposal won&#39;t be submitted to the Standard Committee until I=
&#39;ll get some responses from field/Boost users.</div><div><br></div><div=
>&gt; I was struck by the fact that you&#39;re calling the fundamental type=
 here shared_library, but by that you don&#39;t mean to imply &quot;Linux-s=
tyle shared object&quot;; what you mean is something like shared_ptr =E2=80=
=94 reference-counted, heap-allocated, etc. etc.</div><div>&gt; I think the=
re&#39;s a more primitive abstraction here =E2=80=94 call it library =E2=80=
=94 that does RAII but not reference-counting. Then shared_library might be=
 as simple as a typedef for shared_ptr&lt;library&gt;.</div><div><br></div>=
<div>The problem is that the same shared library file &quot;libmy_shared.so=
&quot; could be loaded multiple times:</div><div>=C2=A0 =C2=A0 shared_libra=
ry lib1(&quot;./libmy_shared.so&quot;);</div><div>=C2=A0 =C2=A0 const int* =
i;</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 shared_l=
ibrary lib2(&quot;./libmy_shared.so&quot;);</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 i =3D lib2.get&lt;const int*&gt;(&quot;integer&quot;);</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // lib2 is destroyed. OK to use `i`, while lib1 st=
ill references the &quot;./libmy_shared.so&quot;</div><div>=C2=A0 =C2=A0 }<=
/div><div>=C2=A0 =C2=A0 std::cerr &lt;&lt; *i;</div><div><br></div><div>`sh=
ared_` could not be cut of from `shared_library`, because it is actually sh=
ared.</div><div><br></div><div><br></div><div>&gt; Certainly shared_library=
::unload() should be spelled reset(); is_loaded() should probably be spelle=
d operator!=3D(nullptr_t); and by analogy with std::map, get() should be sp=
elled at(). (There&#39;s already a couple of get()s in the STL, and neither=
 of them behave like what you&#39;re describing. You&#39;re describing basi=
cally a key-value store. That&#39;s the domain of member function at().)</d=
iv><div><br></div><div>All the at() functions in the current Standard are n=
ot templated, so get&lt;&gt;() seems more right. Actually, it can be made a=
 free function (just like for tuple/array). But all the free standing get&l=
t;&gt;() accept only one parameter, while we&#39;ll need two for shared_lib=
rary (shared_library instance and symbol_name).</div><div><br></div><div>I =
did not provided the constructors/comparisons/reset functions that acccept =
nullptr_t because that may cause confusion: in POSIX dlopen() can actually =
accept NULL and it is a valid parameter that will load the current program.=
 (added that note into the draft proposal)</div><div><br></div><div>&gt; Th=
e functions this_line_location, program_location, etc., should be harmonize=
d with std::experimental::source_location as much as possible. I&#39;m not =
sure what that means, exactly, but it probably means something.</div><div><=
br></div><div>std::experimental::source_location returns source file name. =
this_line_location() returns location of shared library file or program tha=
t contains the line (for example &quot;/usr/lib/libplugin.so&quot;).</div><=
div>Could you explain, what exactly must be clarified in proposal, to avoid=
 confusion with std::experimental::source_location?</div><div><br></div><di=
v>&gt; When you say &quot;Destructors throw nothing&quot;, do you mean that=
 a failure inside a destructor will go unreported?</div><div><br></div><div=
>That the destructor newer throws and always succeeds. Just like all the de=
structors in the Standard do, unless specified otherwise. Shall I use some =
other words to clarify that in draft proposal?</div><div>=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 />
<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 />

--94eb2c088338175ad2052bfc3daf--

.

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

2016-02-17 21:14 GMT+03:00 Sunil Srivastava <sunil149@gmail.com>:

> Are there any plans to look at attributes like dllimport or dllexport?
>
>>
Yes, It's being discussed in thread "[std-proposals] Attributes useful for
shared objects (import, export, symbol locations)"

But the draft wording in that thread requires multiple fixes (I'll try to
update the [[visible]] attribute draft in a week or two)

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2016-02-17 21:14 GMT+03:00 Sunil Srivastava <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:sunil149@gmail.com" target=3D"_blank">sunil149@gmail.com</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"><div dir=3D"ltr">Are there any plans to look=
 at attributes like dllimport or dllexport?</div><div><div><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=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"><div dir=3D"ltr"><sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"></div></blockquote></span></div></bloc=
kquote></div></div></div></div></blockquote></div><div class=3D"gmail_extra=
"><br></div>Yes, It&#39;s being discussed in thread &quot;[std-proposals] A=
ttributes useful for shared objects (import, export, symbol locations)&quot=
;<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
But the draft wording in that thread requires multiple fixes (I&#39;ll try =
to update the [[visible]] attribute draft in a week or two)</div><div class=
=3D"gmail_extra"><div><br></div>-- <br><div>Best regards,<br>Antony Polukhi=
n</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 />

--94eb2c032e60bf9519052bfc4b62--

.

On 2016-02-17 14:27, Antony Polukhin wrote:
>> I was struck by the fact that you're calling the fundamental type=20
>> here shared_library, but by that you don't mean to imply=20
>> "Linux-style shared object"; what you mean is something like=20
>> shared_ptr =E2=80=94 reference-counted, heap-allocated, etc. etc. I thin=
k=20
>> there's a more primitive abstraction here =E2=80=94 call it library =E2=
=80=94 that=20
>> does RAII but not reference-counting. Then shared_library might be
>> as simple as a typedef for shared_ptr<library>.
>=20
> The problem is that the same shared library file "libmy_shared.so" could =
be
> loaded multiple times:
> [snip example]

You could address that by making the ctor protected and returning a
shared_ptr<library> from a static method or other factory function. As
an advantage to this, said function could return an `expected` for folks
that can't use exceptions.

>> by analogy with std::map, get() should be spelled at(). (There's=20
>> already a couple of get()s in the STL, and neither of them behave
>> like what you're describing. You're describing basically a
>> key-value store. That's the domain of member function at().)
>=20
> All the at() functions in the current Standard are not templated, so
> get<>() seems more right.

But by that logic, the `get`s aren't templated on the return type,
either. I also think 'get' is not the best name, though I also think
'at' is not better. Maybe 'symbol' or 'address' or some such? Or even
'find'...

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

.

Am 17.02.2016 um 20:27 schrieb Antony Polukhin:
> Great thanks for all your comments!
>
>
> * renamed native() to handle()
std::thread calls it native_handle() so I think it'd be better to follow
the precedent.

--

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

.

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

On 17 February 2016 at 21:06, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> You could address that by making the ctor protected and returning a
> shared_ptr<library> from a static method or other factory function. As
> an advantage to this, said function could return an `expected` for folks
> that can't use exceptions.
>

It is more future-proof to have a specific type name instead of
shared_ptr<library>, even if it could be implemented as a typedef/using
declaration of such type.
I beliebe it's the reason shared_future is not shared_ptr<future> : you
don't want to know how it's shared, there might be resource-kind-specific
optimizations ongoing.
Also, in general it is rarely a good idea to expose shared_ptr or any kind
of generic smart pointer in an interface, even more so if it's a general
use library.
In my opinion, only owning-pointers legacy code that need a quick safety
upgrade are ok to use smart pointers in interfaces/functions signatures. I
think
it's better to hide this kind of implementation details otherwise.

Jo=C3=ABl Lamotte

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

--001a1148ef068cbc74052c0064aa
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">=
On 17 February 2016 at 21:06, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":27=
a" class=3D"a3s" style=3D"overflow:hidden">You could address that by making=
 the ctor protected and returning a<br>
shared_ptr&lt;library&gt; from a static method or other factory function. A=
s<br>
an advantage to this, said function could return an `expected` for folks<br=
>
that can&#39;t use exceptions.</div></blockquote></div><br>It is more futur=
e-proof to have a specific type name instead of shared_ptr&lt;library&gt;, =
even if it could be implemented as a typedef/using declaration of such type=
..</div><div class=3D"gmail_extra">I beliebe it&#39;s the reason shared_futu=
re is not shared_ptr&lt;future&gt; : you don&#39;t want to know how it&#39;=
s shared, there might be resource-kind-specific optimizations ongoing.</div=
><div class=3D"gmail_extra">Also, in general it is rarely a good idea to ex=
pose shared_ptr or any kind of generic smart pointer in an interface, even =
more so if it&#39;s a general use library.</div><div class=3D"gmail_extra">=
In my opinion, only owning-pointers legacy code that need a quick safety up=
grade are ok to use smart pointers in interfaces/functions signatures. I th=
ink</div><div class=3D"gmail_extra">it&#39;s better to hide this kind of im=
plementation details otherwise.=C2=A0</div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">Jo=C3=ABl Lamotte</div><div class=3D"gmail_=
extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a1148ef068cbc74052c0064aa--

.

On quarta-feira, 17 de fevereiro de 2016 15:06:53 PST Matthew Woehlke wrote:
> You could address that by making the ctor protected and returning a
> shared_ptr<library> from a static method or other factory function. As
> an advantage to this, said function could return an `expected` for folks
> that can't use exceptions.

You can't access dlopen's reference count, so don't try to do this. The system
does the reference counting for you and you cannot destroy it earlier.

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

.

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

On Wed, Feb 17, 2016 at 11:27 AM, Antony Polukhin <antoshkka@gmail.com>
wrote:
> > Arthur O'Dwyer
> > I was struck by the fact that you're calling the fundamental type here
> > shared_library, but by that you don't mean to imply "Linux-style shared
object";
> > what you mean is something like shared_ptr =E2=80=94 reference-counted,
heap-allocated,
> > etc. etc.
> > I think there's a more primitive abstraction here =E2=80=94 call it lib=
rary =E2=80=94
that does RAII
> > but not reference-counting. Then shared_library might be as simple as a
typedef
> > for shared_ptr<library>.
[...]
> `shared_` could not be cut of from `shared_library`, because it is
actually shared.

I did see all of that at the time I wrote my comment; I just thought
shared_ptr<library> would make it clearer, and allow the possibility of
dynamically loading code that you *don't* want to be shared with anyone
else in your program.

However, Thiago later commented that the reference-counting is done by
dlopen() itself and would be hard or impossible to separate from the
library-loading; and you make a good point that we already have
shared_mutex, shared_lock, shared_future,... So one more shared_foo class
isn't a bad thing. I do think that people *will* be confused at first,
because Linux programmers are already using the words "shared library" for
something that's not quite the same thing (they mean the code is
shared *between
processes*, not merely that one process can have multiple handles to the
code). But they'll figure it out eventually. It's not the worst name ever.

> > Certainly shared_library::unload() should be spelled reset();
is_loaded() should
> > probably be spelled operator!=3D(nullptr_t);

These suggestions were based on the idea that shared_library is basically a
shared_ptr. If it's not, then maybe even .unload() shouldn't be .reset().
However, someone else pointed out that in the usual case .unload() doesn't
literally unload anything; so .unload() was a bad name anyway.

> > and by analogy with std::map, get() should be spelled at(). (There's
already
> > a couple of get()s in the STL, and neither of them behave like what
you're
> > describing. You're describing basically a key-value store. That's the
domain
> > of member function at().)
>
> All the at() functions in the current Standard are not templated, so
get<>() seems
> more right. Actually, it can be made a free function (just like for
tuple/array). But
> all the free standing get<>() accept only one parameter, while we'll need
two for
> shared_library (shared_library instance and symbol_name).

Yeah, I wouldn't make it a free function; I'm not even sure it could be,
unless it were a friend. Another option would be to split the
responsibilities: just as we might write

    std::map<std::string, boost::any> params =3D ...;
    auto foo =3D boost::any_cast<int>(params.at("count"));
    auto bar =3D param::get<int>(params, "count");  // we can add this
syntactic sugar

we could write

    shared_library lib;
    auto *foo =3D shared_library::symbol_cast<int(int,int)>(lib.at("foo"));
    auto *bar =3D shared_library::symbol_get<int(int,int)>(lib, "foo");  //
we can add this syntactic sugar

where lib.at("...") returns an opaque "symbol" (a thinly disguised void*)
that can then be cast to the right type (via a thinly disguised
static_cast).  I'm not claiming "symbol" is the right name for the opaque
object.

Or is it necessary on some platforms to know whether the symbol you're
fetching is a function or a data object, in order to fetch it at all? If
that's true, or might be true in the future, then my suggested split isn't
possible.

> > The functions this_line_location, program_location, etc., should be
harmonized
> > with std::experimental::source_location as much as possible. I'm not
sure what
> > that means, exactly, but it probably means something.
>
> std::experimental::source_location returns source file name.
this_line_location()
> returns location of shared library file or program that contains the line
(for
> example "/usr/lib/libplugin.so").
> Could you explain, what exactly must be clarified in proposal, to avoid
confusion
> with std::experimental::source_location?

Well, two things.
(1) The use of the word "location" to mean something different from a
source_location seems confusion-prone.
(2) A source_location contains a filename, right? so would it make sense to
return a source_location instead of a filesystem::path? Maybe not, I guess,
because a source_location refers to an aspect of the *source*
(compile-time) and a filesystem::path refers to an aspect of the *runtime*
system.  In which case, why not e.g. rename this_line_location to
program_path? It doesn't have anything to do with the *line*, right?

> > When you say "Destructors throw nothing", do you mean that a failure
inside a destructor will go unreported?
>
> That the destructor newer throws and always succeeds. Just like all the
> destructors in the Standard do, unless specified otherwise. Shall I use
> some other words to clarify that in draft proposal?

The reason that sentence is confusing right now is that you say it in the
context of "how errors are reported." You don't say "our destructors never
encounter errors"; you just say "when our destructors encounter errors,
they don't throw." Okay, says the reader; they don't throw, but what DO
they do?

I would say something like "No class in this proposal has a destructor that
could possibly encounter an error."
And then I'd be worried that I might be wrong about that claim. :)
You could also just omit the sentence entirely and mark all your
destructors noexcept (which is to say, don't mark them at all, because
destructors default to noexcept), and that would probably suffice.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Wed, Feb 17, 2016 at 11:27 AM, Antony Polukhin &lt;<a h=
ref=3D"mailto:antoshkka@gmail.com">antoshkka@gmail.com</a>&gt; wrote:<br>&g=
t; &gt; Arthur O&#39;Dwyer<br>&gt; &gt; I was struck by the fact that you&#=
39;re calling the fundamental type here<div>&gt; &gt; shared_library, but b=
y that you don&#39;t mean to imply &quot;Linux-style shared object&quot;;</=
div><div>&gt; &gt; what you mean is something like shared_ptr =E2=80=94 ref=
erence-counted, heap-allocated,</div><div>&gt; &gt; etc. etc.<br>&gt; &gt; =
I think there&#39;s a more primitive abstraction here =E2=80=94 call it lib=
rary =E2=80=94 that does RAII</div><div>&gt; &gt; but not reference-countin=
g. Then shared_library might be as simple as a typedef</div><div>&gt; &gt; =
for shared_ptr&lt;library&gt;.<br>[...]<br>&gt; `shared_` could not be cut =
of from `shared_library`, because it is actually shared.<br><br>I did see a=
ll of that at the time I wrote my comment; I just thought shared_ptr&lt;lib=
rary&gt; would make it clearer, and allow the possibility of dynamically lo=
ading code that you *don&#39;t* want to be shared with anyone else in your =
program.</div><div><br></div><div>However, Thiago later commented that the =
reference-counting is done by dlopen() itself and would be hard or impossib=
le to separate from the library-loading; and you make a good point that we =
already have shared_mutex, shared_lock, shared_future,... So one more share=
d_foo class isn&#39;t a bad thing. I do think that people <i>will</i> be co=
nfused at first, because Linux programmers are already using the words &quo=
t;shared library&quot; for something that&#39;s not quite the same thing (t=
hey mean the code is shared <i>between processes</i>, not merely that one p=
rocess can have multiple handles to the code). But they&#39;ll figure it ou=
t eventually. It&#39;s not the worst name ever.<br><br>&gt; &gt; Certainly =
shared_library::unload() should be spelled reset(); is_loaded() should</div=
><div>&gt; &gt; probably be spelled operator!=3D(nullptr_t);</div><div><br>=
</div><div>These suggestions were based on the idea that shared_library is =
basically a shared_ptr. If it&#39;s not, then maybe even .unload() shouldn&=
#39;t be .reset(). However, someone else pointed out that in the usual case=
 .unload() doesn&#39;t literally unload anything; so .unload() was a bad na=
me anyway.</div><div><br></div><div>&gt; &gt; and by analogy with std::map,=
 get() should be spelled at(). (There&#39;s already</div><div>&gt; &gt; a c=
ouple of get()s in the STL, and neither of them behave like what you&#39;re=
=C2=A0</div><div>&gt; &gt; describing. You&#39;re describing basically a ke=
y-value store. That&#39;s the domain</div><div>&gt; &gt; of member function=
 at().)<br>&gt;<br>&gt; All the at() functions in the current Standard are =
not templated, so get&lt;&gt;() seems</div><div>&gt; more right. Actually, =
it can be made a free function (just like for tuple/array). But</div><div>&=
gt; all the free standing get&lt;&gt;() accept only one parameter, while we=
&#39;ll need two for</div><div>&gt; shared_library (shared_library instance=
 and symbol_name).</div><div><br></div><div>Yeah, I wouldn&#39;t make it a =
free function; I&#39;m not even sure it could be, unless it were a friend. =
Another option would be to split the responsibilities: just as we might wri=
te</div><div><br></div><div>=C2=A0 =C2=A0 std::map&lt;std::string, boost::a=
ny&gt; params =3D ...;</div><div>=C2=A0 =C2=A0 auto foo =3D boost::any_cast=
&lt;int&gt;(<a href=3D"http://params.at">params.at</a>(&quot;count&quot;));=
</div><div>=C2=A0 =C2=A0 auto bar =3D param::get&lt;int&gt;(params, &quot;c=
ount&quot;); =C2=A0// we can add this syntactic sugar</div><div><br></div><=
div>we could write</div><div><br></div><div>=C2=A0 =C2=A0 shared_library li=
b;</div><div>=C2=A0 =C2=A0 auto *foo =3D shared_library::symbol_cast&lt;int=
(int,int)&gt;(<a href=3D"http://lib.at">lib.at</a>(&quot;foo&quot;));</div>=
<div><div>=C2=A0 =C2=A0 auto *bar =3D shared_library::symbol_get&lt;int(int=
,int)&gt;(lib, &quot;foo&quot;); =C2=A0// we can add this syntactic sugar</=
div></div><div><br></div><div>where <a href=3D"http://lib.at">lib.at</a>(&q=
uot;...&quot;) returns an opaque &quot;symbol&quot; (a thinly disguised voi=
d*) that can then be cast to the right type (via a thinly disguised static_=
cast).=C2=A0 I&#39;m not claiming &quot;symbol&quot; is the right name for =
the opaque object.</div><div><br></div><div>Or is it necessary on some plat=
forms to know whether the symbol you&#39;re fetching is a function or a dat=
a object, in order to fetch it at all? If that&#39;s true, or might be true=
 in the future, then my suggested split isn&#39;t possible.</div><div><br><=
/div><div>&gt; &gt; The functions this_line_location, program_location, etc=
.., should be harmonized</div><div>&gt; &gt; with std::experimental::source_=
location as much as possible. I&#39;m not sure what</div><div>&gt; &gt; tha=
t means, exactly, but it probably means something.<br>&gt;<br>&gt; std::exp=
erimental::source_location returns source file name. this_line_location()</=
div><div>&gt; returns location of shared library file or program that conta=
ins the line (for</div><div>&gt; example &quot;/usr/lib/libplugin.so&quot;)=
..<br>&gt; Could you explain, what exactly must be clarified in proposal, to=
 avoid confusion</div><div>&gt; with std::experimental::source_location?<br=
><br>Well, two things.</div><div>(1) The use of the word &quot;location&quo=
t; to mean something different from a source_location seems confusion-prone=
..</div><div>(2) A source_location contains a filename, right? so would it m=
ake sense to return a source_location instead of a filesystem::path? Maybe =
not, I guess, because a source_location refers to an aspect of the <i>sourc=
e</i> (compile-time) and a filesystem::path refers to an aspect of the <i>r=
untime</i> system.=C2=A0 In which case, why not e.g. rename this_line_locat=
ion to program_path? It doesn&#39;t have anything to do with the=C2=A0<i>li=
ne</i>, right?</div><div><br>&gt; &gt; When you say &quot;Destructors throw=
 nothing&quot;, do you mean that a failure inside a destructor will go unre=
ported?<br>&gt;<br>&gt; That the destructor newer throws and always succeed=
s. Just like all the</div><div>&gt; destructors in the Standard do, unless =
specified otherwise. Shall I use</div><div>&gt; some other words to clarify=
 that in draft proposal?</div><div><br></div><div>The reason that sentence =
is confusing right now is that you say it in the context of &quot;how error=
s are reported.&quot; You don&#39;t say &quot;our destructors never encount=
er errors&quot;; you just say &quot;when our destructors encounter errors, =
they don&#39;t throw.&quot; Okay, says the reader; they don&#39;t throw, bu=
t what DO they do?<br></div><div><br></div><div>I would say something like =
&quot;No class in this proposal has a destructor that could possibly encoun=
ter an error.&quot;</div><div>And then I&#39;d be worried that I might be w=
rong about that claim. :)</div><div>You could also just omit the sentence e=
ntirely and mark all your destructors noexcept (which is to say, don&#39;t =
mark them at all, because destructors default to noexcept), and that would =
probably suffice.=C2=A0</div><div><br></div><div>=E2=80=93Arthur</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 />

--047d7ba982fe0f7b94052c017c22--

.

On quarta-feira, 17 de fevereiro de 2016 17:42:51 PST Arthur O'Dwyer wrote:
> where lib.at("...") returns an opaque "symbol" (a thinly disguised void*)

The problem is that you can't cleanly cast a void* to a function pointer. It
should be a void(*)() instead, which then is unsuitable for object pointers.
(5.2.10 [expr.reinterpret.cast] p8 "Converting a function pointer to an object
pointer type or vice versa is conditionally-supported.")

It's possible on some architectures pointers to functions have different sizes
than object pointers. The initial IA-64 psABI proposal had, in fact, just
that: pointers to functions would carry the entry 64-bit point and a 64-bit
global pointer (PMFs would add a third 64-bit value). Later, someone realised
how difficult this would make about porting code to IA-64 and decided that
function pointers wouldn't point to the entry point, but to .the pair.

https://mentorembedded.github.io/cxx-abi/abi.html#member-pointers

But the vtable still carries the pair, instead of being an indirection to the
pair:

https://mentorembedded.github.io/cxx-abi/abi.html#vtable

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

.

On 2016-02-17 20:42, Arthur O'Dwyer wrote:
> These suggestions were based on the idea that shared_library is basically a
> shared_ptr. If it's not, then maybe even .unload() shouldn't be .reset().
> However, someone else pointed out that in the usual case .unload() doesn't
> literally unload anything; so .unload() was a bad name anyway.

....in which case, I'd nominate `release()`, but that's bikeshedding...

> Or is it necessary on some platforms to know whether the symbol you're
> fetching is a function or a data object, in order to fetch it at all?

As I alluded to in my previous message, it would be nice if one could:

  auto pf1 = lib.function<int (int)>("foo");
  auto pf2 = lib.function<int (double)>("foo");
  // pf1 && pf2 && (pf1 != pf2)

....i.e. if it knew how to look up mangled C++ symbols from the unmangled
name, which requires of course that the look-up needs the signature as
well as the name.

--
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 quinta-feira, 18 de fevereiro de 2016 12:03:47 PST Matthew Woehlke wrote:
>   auto pf1 = lib.function<int (int)>("foo");
>   auto pf2 = lib.function<int (double)>("foo");
>   // pf1 && pf2 && (pf1 != pf2)

And how would you declare that you wanted the extern "C" symbol of those?
You'd need a typedef declared outside of the function and templates are not
allowed to distinguish on the extern C-ness of the type.

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

.

On 2016-02-19 02:40, Thiago Macieira wrote:
> On quinta-feira, 18 de fevereiro de 2016 12:03:47 PST Matthew Woehlke wrote:
>>   auto pf1 = lib.function<int (int)>("foo");
>>   auto pf2 = lib.function<int (double)>("foo");
>>   // pf1 && pf2 && (pf1 != pf2)
>
> And how would you declare that you wanted the extern "C" symbol of those?

By having separate methods? [c_]function and cpp_function? Maybe there
could be a no-template-arguments `function` that returns an object on
which you then call `as<signature>`, and one that takes

Note: I'm assuming you mean that you want (the ability to find) a C
flavor *when a C++ flavor also exists*. Otherwise, if there aren't
separate methods for C and C++ functions, I would expect that the
look-up would try the C++ flavor first, then the C flavor, before giving up.

Anyway, that's somewhat beside the point, which was, the only way to
conveniently look up C++ mangled functions is for the look-up method to
know the signature. (We were discussing `find(name).as<signature>()` vs.
`find<signature>(name)`.)

--
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 sexta-feira, 19 de fevereiro de 2016 10:48:17 PST Matthew Woehlke wrote:
> Note: I'm assuming you mean that you want (the ability to find) a C
> flavor *when a C++ flavor also exists*. Otherwise, if there aren't
> separate methods for C and C++ functions, I would expect that the
> look-up would try the C++ flavor first, then the C flavor, before giving up.

Yes, but no. I don't think the look up should fall back. It should report that
the C++ symbol does not exist.

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

.

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

El 17/2/2016 16:27, "Antony Polukhin" <antoshkka@gmail.com> escribi=C3=B3:
>
> Great thanks for all your comments!
>
>
> Big update of the proposal draft (2016-02-17). Changes:
> * cleaned up terminology:
>     * clarified terms 'shared library', 'dynamic library load'
>     * replaced (module, library, shared object, ...) -> shared library
file
>     * replaced (imported symbol, loaded symbol, ...) -> symbol obtained
from shared library file
>     * replaced (executable, binary, ...) -> program
> * renamed unload() to reset()
> * renamed native() to handle()
> * dropped is_loaded() function
> * clarified the dll_mode::search_system_directories behavior
> * added notes about the extensibility of dll_mode with user's types
> * updated the "III. Design Decisions" with information on obtaining
mangled symbols by unmangled names
> * better description for load() functions
> * multiple other minor cleanups
>
> TODO:
> * fix the signature of shared_library::get<>() functions
>
> If you'll find any other issues or wish to comment some parts of the
proposal draft, please do not hesitate!
>
>
>
> Comments that were not addressed by changes:
>
> > dgutson
> > Please consider to turn this feature somewhat optional so some
freestanding implementations or hosted (but embedded systems) where this
feature is not applicable can still be compliant.
>
> I've took a look into the std::thread and found nothing about making
threads optional (probably I've missed something). Just followed the
example of std::thread in draft proposal.

I don't think freestanding implies threads are optional.
Moreover, I see threads as more useful than dynamic libraries in an
embedded environment so I'd want that an implementation claiming to be
compliant should implement threads.

>
> > Thiago Macieira
> > Another thing: on at least one platform (Windows CE), the symbol name i=
s
> actually encoded in UTF-16, not 8-bit. You should probably write that
> conversion, if any,  is implementation-defined and must be documented by
the
> implementation.
>
> Windows CE also has the GetProcAddressA
https://msdn.microsoft.com/ru-ru/library/ms885634.aspx
> I'd rather not mention conversions at all as there's no restrictions on
implementations to do that.
>
> > Morwenn
> > Just as a side note: won't the function import cause problems? The
already Modules TS introduces the keyword import and probably not as a
contextual keyword. I would have to read the proposal again but I am fairy
sure it might cause some problems.
>
> I really hope that this issue will be resolved in Modules proposal and
all the new keywords will be context-sensitive. Otherwise a lot of code
will be broken.
>
> > Arthur O'Dwyer
> > I've never used Boost.DLL, so take my comments with a grain of salt.
>
> Actually, Boost.DLL will appear only in next release of Boost (version
1.61). This draft proposal won't be submitted to the Standard Committee
until I'll get some responses from field/Boost users.
>
> > I was struck by the fact that you're calling the fundamental type here
shared_library, but by that you don't mean to imply "Linux-style shared
object"; what you mean is something like shared_ptr =E2=80=94 reference-cou=
nted,
heap-allocated, etc. etc.
> > I think there's a more primitive abstraction here =E2=80=94 call it lib=
rary =E2=80=94
that does RAII but not reference-counting. Then shared_library might be as
simple as a typedef for shared_ptr<library>.
>
> The problem is that the same shared library file "libmy_shared.so" could
be loaded multiple times:
>     shared_library lib1("./libmy_shared.so");
>     const int* i;
>     {
>         shared_library lib2("./libmy_shared.so");
>         i =3D lib2.get<const int*>("integer");
>         // lib2 is destroyed. OK to use `i`, while lib1 still references
the "./libmy_shared.so"
>     }
>     std::cerr << *i;
>
> `shared_` could not be cut of from `shared_library`, because it is
actually shared.
>
>
> > Certainly shared_library::unload() should be spelled reset();
is_loaded() should probably be spelled operator!=3D(nullptr_t); and by
analogy with std::map, get() should be spelled at(). (There's already a
couple of get()s in the STL, and neither of them behave like what you're
describing. You're describing basically a key-value store. That's the
domain of member function at().)
>
> All the at() functions in the current Standard are not templated, so
get<>() seems more right. Actually, it can be made a free function (just
like for tuple/array). But all the free standing get<>() accept only one
parameter, while we'll need two for shared_library (shared_library instance
and symbol_name).
>
> I did not provided the constructors/comparisons/reset functions that
acccept nullptr_t because that may cause confusion: in POSIX dlopen() can
actually accept NULL and it is a valid parameter that will load the current
program. (added that note into the draft proposal)
>
> > The functions this_line_location, program_location, etc., should be
harmonized with std::experimental::source_location as much as possible. I'm
not sure what that means, exactly, but it probably means something.
>
> std::experimental::source_location returns source file name.
this_line_location() returns location of shared library file or program
that contains the line (for example "/usr/lib/libplugin.so").
> Could you explain, what exactly must be clarified in proposal, to avoid
confusion with std::experimental::source_location?
>
> > When you say "Destructors throw nothing", do you mean that a failure
inside a destructor will go unreported?
>
> That the destructor newer throws and always succeeds. Just like all the
destructors in the Standard do, unless specified otherwise. Shall I use
some other words to clarify that in draft proposal?
>
>
>
> --
> 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/.

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

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

<p dir=3D"ltr"><br>
El 17/2/2016 16:27, &quot;Antony Polukhin&quot; &lt;<a href=3D"mailto:antos=
hkka@gmail.com">antoshkka@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; Great thanks for all your comments!<br>
&gt;<br>
&gt;<br>
&gt; Big update of the proposal draft (2016-02-17). Changes:<br>
&gt; * cleaned up terminology:<br>
&gt; =C2=A0 =C2=A0 * clarified terms &#39;shared library&#39;, &#39;dynamic=
 library load&#39;<br>
&gt; =C2=A0 =C2=A0 * replaced (module, library, shared object, ...) -&gt; s=
hared library file<br>
&gt; =C2=A0 =C2=A0 * replaced (imported symbol, loaded symbol, ...) -&gt; s=
ymbol obtained from shared library file<br>
&gt; =C2=A0 =C2=A0 * replaced (executable, binary, ...) -&gt; program<br>
&gt; * renamed unload() to reset()<br>
&gt; * renamed native() to handle()<br>
&gt; * dropped is_loaded() function<br>
&gt; * clarified the dll_mode::search_system_directories behavior<br>
&gt; * added notes about the extensibility of dll_mode with user&#39;s type=
s<br>
&gt; * updated the &quot;III. Design Decisions&quot; with information on ob=
taining mangled symbols by unmangled names<br>
&gt; * better description for load() functions<br>
&gt; * multiple other minor cleanups<br>
&gt;<br>
&gt; TODO:<br>
&gt; * fix the signature of shared_library::get&lt;&gt;() functions<br>
&gt;<br>
&gt; If you&#39;ll find any other issues or wish to comment some parts of t=
he proposal draft, please do not hesitate!<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Comments that were not addressed by changes:<br>
&gt;<br>
&gt; &gt; dgutson<br>
&gt; &gt; Please consider to turn this feature somewhat optional so some fr=
eestanding implementations or hosted (but embedded systems) where this feat=
ure is not applicable can still be compliant.<br>
&gt;<br>
&gt; I&#39;ve took a look into the std::thread and found nothing about maki=
ng threads optional (probably I&#39;ve missed something). Just followed the=
 example of std::thread in draft proposal.<br></p>
<p dir=3D"ltr">I don&#39;t think freestanding implies threads are optional.=
<br>
Moreover, I see threads as more useful than dynamic libraries in an embedde=
d environment so I&#39;d want that an implementation claiming to be complia=
nt should implement threads.<br></p>
<p dir=3D"ltr">&gt;<br>
&gt; &gt; Thiago Macieira<br>
&gt; &gt; Another thing: on at least one platform (Windows CE), the symbol =
name is<br>
&gt; actually encoded in UTF-16, not 8-bit. You should probably write that<=
br>
&gt; conversion, if any, =C2=A0is implementation-defined and must be docume=
nted by the<br>
&gt; implementation.=C2=A0<br>
&gt;<br>
&gt; Windows CE also has the GetProcAddressA <a href=3D"https://msdn.micros=
oft.com/ru-ru/library/ms885634.aspx">https://msdn.microsoft.com/ru-ru/libra=
ry/ms885634.aspx</a><br>
&gt; I&#39;d rather not mention conversions at all as there&#39;s no restri=
ctions on implementations to do that.<br>
&gt;<br>
&gt; &gt; Morwenn<br>
&gt; &gt; Just as a side note: won&#39;t the function import cause problems=
? The already Modules TS introduces the keyword import and probably not as =
a contextual keyword. I would have to read the proposal again but I am fair=
y sure it might cause some problems.<br>
&gt;<br>
&gt; I really hope that this issue will be resolved in Modules proposal and=
 all the new keywords will be context-sensitive. Otherwise a lot of code wi=
ll be broken.<br>
&gt;<br>
&gt; &gt; Arthur O&#39;Dwyer<br>
&gt; &gt; I&#39;ve never used Boost.DLL, so take my comments with a grain o=
f salt.<br>
&gt;<br>
&gt; Actually, Boost.DLL will appear only in next release of Boost (version=
 1.61). This draft proposal won&#39;t be submitted to the Standard Committe=
e until I&#39;ll get some responses from field/Boost users.<br>
&gt;<br>
&gt; &gt; I was struck by the fact that you&#39;re calling the fundamental =
type here shared_library, but by that you don&#39;t mean to imply &quot;Lin=
ux-style shared object&quot;; what you mean is something like shared_ptr =
=E2=80=94 reference-counted, heap-allocated, etc. etc.<br>
&gt; &gt; I think there&#39;s a more primitive abstraction here =E2=80=94 c=
all it library =E2=80=94 that does RAII but not reference-counting. Then sh=
ared_library might be as simple as a typedef for shared_ptr&lt;library&gt;.=
<br>
&gt;<br>
&gt; The problem is that the same shared library file &quot;libmy_shared.so=
&quot; could be loaded multiple times:<br>
&gt; =C2=A0 =C2=A0 shared_library lib1(&quot;./libmy_shared.so&quot;);<br>
&gt; =C2=A0 =C2=A0 const int* i;<br>
&gt; =C2=A0 =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 shared_library lib2(&quot;./libmy_shared.s=
o&quot;);<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 i =3D lib2.get&lt;const int*&gt;(&quot;int=
eger&quot;);<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // lib2 is destroyed. OK to use `i`, while=
 lib1 still references the &quot;./libmy_shared.so&quot;<br>
&gt; =C2=A0 =C2=A0 }<br>
&gt; =C2=A0 =C2=A0 std::cerr &lt;&lt; *i;<br>
&gt;<br>
&gt; `shared_` could not be cut of from `shared_library`, because it is act=
ually shared.<br>
&gt;<br>
&gt;<br>
&gt; &gt; Certainly shared_library::unload() should be spelled reset(); is_=
loaded() should probably be spelled operator!=3D(nullptr_t); and by analogy=
 with std::map, get() should be spelled at(). (There&#39;s already a couple=
 of get()s in the STL, and neither of them behave like what you&#39;re desc=
ribing. You&#39;re describing basically a key-value store. That&#39;s the d=
omain of member function at().)<br>
&gt;<br>
&gt; All the at() functions in the current Standard are not templated, so g=
et&lt;&gt;() seems more right. Actually, it can be made a free function (ju=
st like for tuple/array). But all the free standing get&lt;&gt;() accept on=
ly one parameter, while we&#39;ll need two for shared_library (shared_libra=
ry instance and symbol_name).<br>
&gt;<br>
&gt; I did not provided the constructors/comparisons/reset functions that a=
cccept nullptr_t because that may cause confusion: in POSIX dlopen() can ac=
tually accept NULL and it is a valid parameter that will load the current p=
rogram. (added that note into the draft proposal)<br>
&gt;<br>
&gt; &gt; The functions this_line_location, program_location, etc., should =
be harmonized with std::experimental::source_location as much as possible. =
I&#39;m not sure what that means, exactly, but it probably means something.=
<br>
&gt;<br>
&gt; std::experimental::source_location returns source file name. this_line=
_location() returns location of shared library file or program that contain=
s the line (for example &quot;/usr/lib/libplugin.so&quot;).<br>
&gt; Could you explain, what exactly must be clarified in proposal, to avoi=
d confusion with std::experimental::source_location?<br>
&gt;<br>
&gt; &gt; When you say &quot;Destructors throw nothing&quot;, do you mean t=
hat a failure inside a destructor will go unreported?<br>
&gt;<br>
&gt; That the destructor newer throws and always succeeds. Just like all th=
e destructors in the Standard do, unless specified otherwise. Shall I use s=
ome other words to clarify that in draft proposal?<br>
&gt; =C2=A0<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; Best regards,<br>
&gt; Antony Polukhin<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; 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-prop=
osals/</a>.<br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a1134bdaab6cf01052c225d70--

.

On 2016-02-19 11:53, Thiago Macieira wrote:
> On sexta-feira, 19 de fevereiro de 2016 10:48:17 PST Matthew Woehlke wrote:
>> Note: I'm assuming you mean that you want (the ability to find) a C
>> flavor *when a C++ flavor also exists*. Otherwise, if there aren't
>> separate methods for C and C++ functions, I would expect that the
>> look-up would try the C++ flavor first, then the C flavor, before giving up.
>
> Yes, but no. I don't think the look up should fall back. It should report that
> the C++ symbol does not exist.

Sure. Having thought about it (thanks for making me do so), separate
functions are probably better. I'd only go with the above behavior if
there *aren't* separate functions, but probably there should be :-).

--
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 sexta-feira, 19 de fevereiro de 2016 12:04:41 PST Matthew Woehlke wrote:
> On 2016-02-19 11:53, Thiago Macieira wrote:
> > On sexta-feira, 19 de fevereiro de 2016 10:48:17 PST Matthew Woehlke
wrote:
> >> Note: I'm assuming you mean that you want (the ability to find) a C
> >> flavor *when a C++ flavor also exists*. Otherwise, if there aren't
> >> separate methods for C and C++ functions, I would expect that the
> >> look-up would try the C++ flavor first, then the C flavor, before giving
> >> up.>
> > Yes, but no. I don't think the look up should fall back. It should report
> > that the C++ symbol does not exist.
>
> Sure. Having thought about it (thanks for making me do so), separate
> functions are probably better. I'd only go with the above behavior if
> there *aren't* separate functions, but probably there should be :-).

Which is probably a reason not to do it, to avoid the complexity and confusion
generated by having two functions that do almost exactly the same thing -- and
in some cases, *would* do the same thing:

 lib.symbol_c<int>("index");
 lib.symbol_cpp<int>("index");

Would return the same address under the Portable IA-64 C++ ABI.

Another reason is that a template parameter is not enough to get one class of
C++ symbols: template instantiations. How would you extract this function:

template <typename T> T f();
template <> int f() { return 1; }

Portable mangling: _Z1fIiEvv

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

.

------=_Part_3491_492276684.1455913059097
Content-Type: text/plain; charset=UTF-8

On Friday, 19 February 2016 17:13:06 UTC, Thiago Macieira  wrote:
> On sexta-feira, 19 de fevereiro de 2016 12:04:41 PST Matthew Woehlke wrote:
> > On 2016-02-19 11:53, Thiago Macieira wrote:
> > > On sexta-feira, 19 de fevereiro de 2016 10:48:17 PST Matthew Woehlke
> wrote:
> > >> Note: I'm assuming you mean that you want (the ability to find) a C
> > >> flavor *when a C++ flavor also exists*. Otherwise, if there aren't
> > >> separate methods for C and C++ functions, I would expect that the
> > >> look-up would try the C++ flavor first, then the C flavor, before giving
> > >> up.>
> > > Yes, but no. I don't think the look up should fall back. It should report
> > > that the C++ symbol does not exist.
> >
> > Sure. Having thought about it (thanks for making me do so), separate
> > functions are probably better. I'd only go with the above behavior if
> > there *aren't* separate functions, but probably there should be :-).
>
> Which is probably a reason not to do it, to avoid the complexity and confusion
> generated by having two functions that do almost exactly the same thing -- and
> in some cases, *would* do the same thing:
>
>  lib.symbol_c<int>("index");
>  lib.symbol_cpp<int>("index");
>
> Would return the same address under the Portable IA-64 C++ ABI.
>
> Another reason is that a template parameter is not enough to get one class of
> C++ symbols: template instantiations. How would you extract this function:
>
> template <typename T> T f();
> template <> int f() { return 1; }
>
> Portable mangling: _Z1fIiEvv
>

There's also no way to access objects within namespaces, or static class members. (Writing lib.extract<int>("a::index") won't do; a could be a namespace or a class. A library could have both, if they are defined in different TUs.)

If I were designing this API, I'd separate the layers of fetching the mangled symbol from mangling a name and casting the low -level handle to the right type. So:

lib.extract("f", c_function<int()>{})
lib.extract("f", cpp_function<void(int)>{})

Namespaces, templates, etc. can be handled by additional arguments to the mangler.

--

---
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_3491_492276684.1455913059097--

.

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

Great thanks for all your comments!


Big update of the proposal draft (2016-03-16).
https://apolukhin.github.io/papers/D0275R0:%20DLL%20proposal.html

Changes:
* native() -> native_handle()
* native_handle_t -> native_handle_type
* added static constexpr bool platform_supports_dll() noexcept;
* added static constexpr bool platform_supports_dll_of_program() noexcept;
* described the return type of shared_library::get functions
* better code highlighting and formatting
* multiple minor fixes

If you'll find any other issues or wish to comment some parts of the
proposal draft, please do not hesitate!

Comments that were not addressed by changes:
* all the shared_library::get<>() related interface changes. All the
proposed soltuions have own drawbacks, so I'll stick to the status quo.
* all the mangled symbols loadings by unmangled names. There are big
performance issues with such loads; this feature requires a lot of
thinking, probably in other proposal. Motivation for not adding this
feature is in the paper.

* > Arthur O'Dwyer
> (1) The use of the word "location" to mean something different from a
source_location seems confusion-prone.

As I understand we are choosing between "location" and "path":
symbol_location     VS      symbol_path
this_line_location  VS      this_line_path
program_location    VS      program_path

program_path sounds good, but two others confuse me a lot. Also `path` in
Filesystem TS is related to a path without file name in methods like
current_path() or temp_directory_path().  I'd rather not change location to
path.

How about track?
symbol_location     VS      track_symbol
this_line_location  VS      track_this_line
program_location    VS      track_program

> (2) A source_location contains a filename, right? so would it make sense
to return a source_location instead of a filesystem::path? Maybe not, I
guess, because a source_location refers to an aspect of the source
(compile-time) and a filesystem::path refers to an aspect of the runtime
system.  In which case, why not e.g. rename this_line_location to
program_path? It doesn't have anything to do with the line, right?

Actually it refers to the line:
this_line_location() returns path to program or shared library in which it
is called. In other words this_line_location() != program_location() if
this_line_location() call is made inside of the shared library.


--
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/CAKqmYPaPYYHGKtALHYrVK5pt0w8wB%2BBBii2v04_%2BOmFL%2BKc-Fw%40mail.gmail.com.

--001a114d76f4e0d932052e2dedfe
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=
>Great thanks for all your comments!</div><div><br></div><div><br></div><di=
v>Big update of the proposal draft (2016-03-16). <a href=3D"https://apolukh=
in.github.io/papers/D0275R0:%20DLL%20proposal.html">https://apolukhin.githu=
b.io/papers/D0275R0:%20DLL%20proposal.html</a></div><div><br></div><div>Cha=
nges:</div><div>* native() -&gt; native_handle()</div><div>* native_handle_=
t -&gt; native_handle_type</div><div>* added static constexpr bool platform=
_supports_dll() noexcept;</div><div>* added static constexpr bool platform_=
supports_dll_of_program() noexcept;</div><div>* described the return type o=
f shared_library::get functions</div><div>* better code highlighting and fo=
rmatting</div><div>* multiple minor fixes</div><div><br></div><div>If you&#=
39;ll find any other issues or wish to comment some parts of the proposal d=
raft, please do not hesitate!</div><div><br></div><div>Comments that were n=
ot addressed by changes:</div><div>* all the shared_library::get&lt;&gt;() =
related interface changes. All the proposed soltuions have own drawbacks, s=
o I&#39;ll stick to the status quo.</div><div>* all the mangled symbols loa=
dings by unmangled names. There are big performance issues with such loads;=
 this feature requires a lot of thinking, probably in other proposal. Motiv=
ation for not adding this feature is in the paper.</div><div><br></div><div=
>* &gt; Arthur O&#39;Dwyer</div><div>&gt; (1) The use of the word &quot;loc=
ation&quot; to mean something different from a source_location seems confus=
ion-prone.</div><div><br></div><div>As I understand we are choosing between=
 &quot;location&quot; and &quot;path&quot;:</div><div>symbol_location =C2=
=A0 =C2=A0 VS =C2=A0 =C2=A0 =C2=A0symbol_path</div><div>this_line_location =
=C2=A0VS =C2=A0 =C2=A0 =C2=A0this_line_path</div><div>program_location =C2=
=A0 =C2=A0VS =C2=A0 =C2=A0 =C2=A0program_path</div><div><br></div><div>prog=
ram_path sounds good, but two others confuse me a lot. Also `path` in Files=
ystem TS is related to a path without file name in methods like current_pat=
h() or temp_directory_path().=C2=A0 I&#39;d rather not change location to p=
ath.</div><div><br></div><div>How about track?</div><div>symbol_location =
=C2=A0 =C2=A0 VS =C2=A0 =C2=A0 =C2=A0track_symbol</div><div>this_line_locat=
ion =C2=A0VS =C2=A0 =C2=A0 =C2=A0track_this_line</div><div>program_location=
 =C2=A0 =C2=A0VS =C2=A0 =C2=A0 =C2=A0track_program</div><div><br></div><div=
>&gt; (2) A source_location contains a filename, right? so would it make se=
nse to return a source_location instead of a filesystem::path? Maybe not, I=
 guess, because a source_location refers to an aspect of the source (compil=
e-time) and a filesystem::path refers to an aspect of the runtime system.=
=C2=A0 In which case, why not e.g. rename this_line_location to program_pat=
h? It doesn&#39;t have anything to do with the line, right?</div><div><br><=
/div><div>Actually it refers to the line:=C2=A0</div><div>this_line_locatio=
n() returns path to program or shared library in which it is called. In oth=
er words this_line_location() !=3D program_location() if this_line_location=
() call is made inside of the shared library.=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/CAKqmYPaPYYHGKtALHYrVK5pt0w8wB%2BBBii=
2v04_%2BOmFL%2BKc-Fw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKqmYPaPYY=
HGKtALHYrVK5pt0w8wB%2BBBii2v04_%2BOmFL%2BKc-Fw%40mail.gmail.com</a>.<br />

--001a114d76f4e0d932052e2dedfe--

.