Topic: POSIX binding (was "0o for Octal?")
Author: David Krauss <potswa@gmail.com>
Date: Sat, 27 Jun 2015 12:42:42 +0800
Raw View
--Apple-Mail=_443DB9F2-3453-4A33-98D3-38CDBB9A4ACC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9326, at 1:48 PM, Jens Maurer <Jens.Maurer@gmx.n=
et> wrote:
>=20
> There have been a few meetings of a small group trying to come up with st=
andardized
> mappings of C++ standard features to POSIX (e.g. mutexes), and vice versa=
(using
> namespace posix) some years ago, but the chair, Ulrich Drepper, seems to =
have vanished.
Google searches seem to confirm that, not just for GNU and standardization =
but in general.
> I'd call this dead for now.
>=20
> I'd say lack of general interest and lack of time of participants to actu=
ally
> create proposals have all contributed.
Does the responsibility devolve back to WG21?
It appears <http://udrepper.livejournal.com/9183.html> that Drepper formed =
the group to preempt an ISO/WG21 initiative. Given the attitude of that pos=
t, it=E2=80=99s not really surprising that nothing was accomplished.
> And then, there's the desire of C++ to actually create a higher-level int=
erface
> than a simple C++ mapping to POSIX facilities. For example, C++ networki=
ng
> turns out to be several layers above POSIX facilities, not at all mirrori=
ng
> the conceptual approach.
Yes. It=E2=80=99s better to maximize implementation freedom.
Personally, I don=E2=80=99t care about getting an OOP window on POSIX. It w=
ould just be nice to access it without so many macros and global-namespace =
entities.
Perhaps some compiler-level metaprogram could be designed to sanitize platf=
orm headers without actually touching them on disk. It could populate e.g. =
namespace posix and namespace platform. Just dreaming=E2=80=A6
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_443DB9F2-3453-4A33-98D3-38CDBB9A4ACC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
r class=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D""><di=
v class=3D"">On 2015=E2=80=9306=E2=80=9326, at 1:48 PM, Jens Maurer <<a =
href=3D"mailto:Jens.Maurer@gmx.net" class=3D"">Jens.Maurer@gmx.net</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D"">There h=
ave been a few meetings of a small group trying to come up with standardize=
d<br class=3D"">mappings of C++ standard features to POSIX (e.g. mutexes), =
and vice versa (using<br class=3D"">namespace posix) some years ago, but th=
e chair, Ulrich Drepper, seems to have vanished.<br class=3D""></div></bloc=
kquote><div><br class=3D""></div><div>Google searches seem to confirm that,=
not just for GNU and standardization but in general.</div><div><br class=
=3D""></div><blockquote type=3D"cite" class=3D"">I'd call this dead for now=
..<br class=3D""></blockquote><div><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></div><blockquote type=3D"cite" class=3D"">I'd say =
lack of general interest and lack of time of participants to actually<br cl=
ass=3D"">create proposals have all contributed.<br class=3D""></blockquote>=
<div><br class=3D""></div><div>Does the responsibility devolve back to WG21=
?</div><div><br class=3D""></div><div>It <a href=3D"http://udrepper.li=
vejournal.com/9183.html" class=3D"">appears</a> that Drepper formed th=
e group to <i class=3D"">preempt</i> an ISO/WG21 initiative. Give=
n the attitude of that post, it=E2=80=99s not really surprising that nothin=
g was accomplished.</div><br class=3D""><blockquote type=3D"cite" class=3D"=
">And then, there's the desire of C++ to actually create a higher-level int=
erface<br class=3D"">than a simple C++ mapping to POSIX facilities. F=
or example, C++ networking<br class=3D"">turns out to be several layers abo=
ve POSIX facilities, not at all mirroring<br class=3D"">the conceptual appr=
oach.<br class=3D""></blockquote><div><br class=3D""></div><div>Yes. It=E2=
=80=99s better to maximize implementation freedom.</div></div><div class=3D=
""><br class=3D""></div><div class=3D"">Personally, I don=E2=80=99t care ab=
out getting an OOP window on POSIX. It would just be nice to access it with=
out so many macros and global-namespace entities.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Perhaps some compiler-level metaprogram co=
uld be designed to sanitize platform headers without actually touching them=
on disk. It could populate e.g. <font face=3D"Courier" class=3D"">nam=
espace posix</font> and <font face=3D"Courier" class=3D"">namespace pl=
atform</font>. Just dreaming=E2=80=A6</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_443DB9F2-3453-4A33-98D3-38CDBB9A4ACC--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Sat, 27 Jun 2015 21:21:53 +0200
Raw View
On 06/27/2015 06:42 AM, David Krauss wrote:
>> On 2015=E2=80=9306=E2=80=9326, at 1:48 PM, Jens Maurer <Jens.Maurer@gmx.=
net <mailto:Jens.Maurer@gmx.net>> wrote:
>>
>> There have been a few meetings of a small group trying to come up with s=
tandardized
>> mappings of C++ standard features to POSIX (e.g. mutexes), and vice vers=
a (using
>> namespace posix) some years ago, but the chair, Ulrich Drepper, seems to=
have vanished.
>=20
> Google searches seem to confirm that, not just for GNU and standardizatio=
n but in general.
The German Wikipedia claims he's working for Goldman Sachs since 2010.
https://de.wikipedia.org/wiki/Ulrich_Drepper
>> I'd call this dead for now.
>>
>> I'd say lack of general interest and lack of time of participants to act=
ually
>> create proposals have all contributed.
>=20
> Does the responsibility devolve back to WG21?
"Responsibility" sounds a bit too strong. Remember, all committees
and organizations we're talking about are driven by volunteers.
That said, POSIX is an IEEE enterprise and WG21 relates to ISO/IEC.
If WG21 tries to define a POSIX binding for some feature, I'm not
sure we'll have enough POSIX expertise in the room to make it right.
> It appears <http://udrepper.livejournal.com/9183.html> that Drepper forme=
d the group to /preempt/ an ISO/WG21 initiative. Given the attitude of that=
post, it=E2=80=99s not really surprising that nothing was accomplished.
Sometimes, I feel the C++ people are far away from the operating system peo=
ple.
Whenever we come up with an interface in C++, it's essentially a requiremen=
t
that it be implementable on Unix, MacOS, and MS Windows. That's easy for
containers, but a bit harder for something like file systems. There's litt=
le
impetus to actually ask the operating system people to implement a new feat=
ure
that would be useful to C++ at large.
(One example that is substantially broader than Unix, MacOS, MS Windows is
the "traditional linker" issue: We essentially can't rely on more clever
linkers than 1980-style ones for C++.)
=20
>> And then, there's the desire of C++ to actually create a higher-level in=
terface
>> than a simple C++ mapping to POSIX facilities. For example, C++ network=
ing
>> turns out to be several layers above POSIX facilities, not at all mirror=
ing
>> the conceptual approach.
>=20
> Yes. It=E2=80=99s better to maximize implementation freedom.
That's for the C++ standard offering. Some people might feel there's
a useful layer in between. Is there an operating system feature
in POSIX that you want to use that is hard to implement on Windows,
too? If yes, maybe it's time for a POSIX layer. If no, why not
propose an interface to WG21 that can be implemented portably?
A lot more people would benefit. (Thinking about mmap, for example.)
However, on the WG21 level, it seems we've got too many people doing
the "clever" and "interesting" stuff, which "mmap" probably isn't.
And "mmap" isn't the full picture, what about async I/O on files etc.?
Certainly we want some kind of "open file" RAII abstraction that fits
easily into all of this... (Defining and limiting scope is important,
otherwise this gets nowhere.)
=20
> Personally, I don=E2=80=99t care about getting an OOP window on POSIX. It=
would just be nice to access it without so many macros and global-namespac=
e entities.
Yes. Plus decent error handling instead of global errno
creep, with which you have to deal very carefully.
> Perhaps some compiler-level metaprogram could be designed to sanitize pla=
tform headers without actually touching them on disk. It could populate e.g=
.. namespace posix and namespace platform. Just dreaming=E2=80=A6
Wake up, please.
Jens
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sat, 27 Jun 2015 15:53:28 -0700 (PDT)
Raw View
------=_Part_3371_1675659150.1435445608177
Content-Type: multipart/alternative;
boundary="----=_Part_3372_702787292.1435445608178"
------=_Part_3372_702787292.1435445608178
Content-Type: text/plain; charset=UTF-8
On Saturday, June 27, 2015 at 3:21:56 PM UTC-4, Jens Maurer wrote:
>
>
> (One example that is substantially broader than Unix, MacOS, MS Windows is
> the "traditional linker" issue: We essentially can't rely on more clever
> linkers than 1980-style ones for C++.)
>
Another example is asking OS interfaces to implement (char* b,char* e)
string interfaces to help deprecate null terminated strings and fully
support string_view.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3372_702787292.1435445608178
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, June 27, 2015 at 3:21:56 PM UTC-4, Je=
ns Maurer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>(One examp=
le that is substantially broader than Unix, MacOS, MS Windows is
<br>the "traditional linker" issue: We essentially can't rely on more cleve=
r
<br>linkers than 1980-style ones for C++.)
<br></blockquote><div><br></div><div>Another example is asking OS interface=
s to implement (char* b,char* e) string interfaces to help deprecate null t=
erminated strings and fully support string_view. </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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3372_702787292.1435445608178--
------=_Part_3371_1675659150.1435445608177--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 28 Jun 2015 22:21:53 +0800
Raw View
--Apple-Mail=_A92D4E84-0B6C-41A5-AEC2-571380D5B318
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9328, at 3:21 AM, Jens Maurer <Jens.Maurer@gmx.n=
et> wrote:
>=20
> "Responsibility" sounds a bit too strong. Remember, all committees
> and organizations we're talking about are driven by volunteers.
>=20
> That said, POSIX is an IEEE enterprise and WG21 relates to ISO/IEC.
> If WG21 tries to define a POSIX binding for some feature, I'm not
> sure we'll have enough POSIX expertise in the room to make it right.
Wikipedia says <https://en.wikipedia.org/wiki/Austin_Group> that POSIX is =
=E2=80=9Csimultaneously ISO/IEC/IEEE 9945 <http://www.iso.org/iso/home/stor=
e/catalogue_tc/catalogue_detail.htm?csnumber=3D50516>.=E2=80=9D Unix.org ha=
s webpages for SUSv4 as ISO <http://www.unix.org/version4/iso_std.html> and=
IEEE <http://www.unix.org/version4/ieee_std.html>, which is funny given th=
e =E2=80=9Csingle=E2=80=9D moniker. (Of course, they should differ only on =
the cover page.)
It seems that SC22 (one level above WG21) now endorses the Austin Group wor=
k, but this is a new development since 2009. Of course, the important thing=
is getting coverage of all areas of expertise. It might be easier now to g=
et Austin Group folks to go to an ISO C++ meeting. (Or, maybe not.)
>> It appears <http://udrepper.livejournal.com/9183.html> that Drepper form=
ed the group to /preempt/ an ISO/WG21 initiative. Given the attitude of tha=
t post, it=E2=80=99s not really surprising that nothing was accomplished.
>=20
> Sometimes, I feel the C++ people are far away from the operating system p=
eople.
Yes. But, it might not be fair to use Drepper as a representative of =E2=80=
=9Coperating system people.=E2=80=9D He was a very controversial character.
> Whenever we come up with an interface in C++, it's essentially a requirem=
ent
> that it be implementable on Unix, MacOS, and MS Windows. That's easy for
> containers, but a bit harder for something like file systems. There's li=
ttle
> impetus to actually ask the operating system people to implement a new fe=
ature
> that would be useful to C++ at large.
>=20
> (One example that is substantially broader than Unix, MacOS, MS Windows i=
s
> the "traditional linker" issue: We essentially can't rely on more clever
> linkers than 1980-style ones for C++.)
A language/OS dichotomy might be too simplistic. Most OSes have plug-in arc=
hitectures to attach new filesystems, and filesystem developers are always =
pushing adoption of their products into multiple OSes. Given a widely-adopt=
ed and extensible C++ filesystem binding, e.g. ZFS could extend it to their=
own cross-platform binding.
On the other hand, OS vendors seem to be moving away from POSIX and C in ge=
neral, for proprietary mobile and server platforms. I fear the Filesystem T=
S is too POSIX=E2=80=A6 it should support multiple independent filesystems,=
and there should be more abstraction on permissions.
Point is, standard C++ abstractions of OS services shouldn=E2=80=99t stop a=
t the lowest common denominator. There should be room to extend standard fa=
cilities up to native functionality levels. OS vendors currently prefer to =
design entire custom C-like languages for the sake of shipping better-than-=
C bindings, but that market-share can probably be won with the right strate=
gy.
> That's for the C++ standard offering. Some people might feel there's
> a useful layer in between. Is there an operating system feature
> in POSIX that you want to use that is hard to implement on Windows,
> too? If yes, maybe it's time for a POSIX layer. If no, why not
> propose an interface to WG21 that can be implemented portably?
> A lot more people would benefit. (Thinking about mmap, for example.)
>=20
> However, on the WG21 level, it seems we've got too many people doing
> the "clever" and "interesting" stuff, which "mmap" probably isn't.
> And "mmap" isn't the full picture, what about async I/O on files etc.?
> Certainly we want some kind of "open file" RAII abstraction that fits
> easily into all of this... (Defining and limiting scope is important,
> otherwise this gets nowhere.)
We have std::basic_streambuf. It=E2=80=99s not only files that are interest=
ing, but I/O resources and data streams in general. There should be one abs=
traction covering multithreaded work queues, pipes between processes, and n=
etwork sockets. The amount of cruft in streambuf is fairly low, so synchron=
ization and maybe even async I/O should perhaps be added to it. I think the=
bigger problem is that people aren=E2=80=99t using the higher level <iostr=
eam> library for heavy lifting. That part needs replacement.
Using mmap with data structures tends to lead to fancy pointers, which are =
still relatively uncharted territory. Things are so interconnected, that ev=
en a thin POSIX layer would make good progress toward solving =E2=80=9Cinte=
resting=E2=80=9D problems in the deeper concept=E2=80=A6 as long as no regr=
ettable mistakes or restrictions are pulled along with it.
>> Personally, I don=E2=80=99t care about getting an OOP window on POSIX. I=
t would just be nice to access it without so many macros and global-namespa=
ce entities.
>=20
> Yes. Plus decent error handling instead of global errno
> creep, with which you have to deal very carefully.
>=20
>> Perhaps some compiler-level metaprogram could be designed to sanitize pl=
atform headers without actually touching them on disk. It could populate e.=
g. namespace posix and namespace platform. Just dreaming=E2=80=A6
>=20
> Wake up, please.
Apparently Lisa Lippincott has pursued <https://www.youtube.com/watch?v=3D3=
ZO0V4Prefc> a similar idea, a library called Po7 (pronounced P-O-seven). It=
takes care of errno, and more.
The difference is that a real binding should be exclusive, and the underlyi=
ng layer would not be defined at all. The =E2=80=9Ccompiler-level metaprogr=
am=E2=80=9D would realize her mapping principles, taking the platform heade=
rs and an interface description capturing e.g. the information listed on sl=
ide 15 here <https://github.com/CppCon/CppCon2014/raw/master/Presentations/=
How%20to%20call%20C%20libraries%20from%20C++/How%20to%20call%20C%20librarie=
s%20from%20C++%20-%20Lisa%20Lippincott%20-%20CppCon%202014.pdf>. The interf=
ace description would embody the C++ POSIX binding, and platform-specific e=
xtensions could be added alongside. The metaprogram could perhaps be shoeho=
rned into something like SWIG.
I can=E2=80=99t find contact info for Lisa, perhaps someone can forward thi=
s? Kudos to Magnus Fromreide for the resource tip.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_A92D4E84-0B6C-41A5-AEC2-571380D5B318
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9328, at 3:21 AM, Jens Maurer <<a href=3D"mailto:Jens.Maurer@gmx.=
net" class=3D"">Jens.Maurer@gmx.net</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D"">"Responsibility" sounds a bit too stro=
ng. Remember, all committees<br class=3D"">and organizations we're ta=
lking about are driven by volunteers.<br class=3D""><br class=3D"">That sai=
d, POSIX is an IEEE enterprise and WG21 relates to ISO/IEC.<br class=3D"">I=
f WG21 tries to define a POSIX binding for some feature, I'm not<br class=
=3D"">sure we'll have enough POSIX expertise in the room to make it right.<=
br class=3D""></div></blockquote><div><br class=3D""></div><div>Wikipedia&n=
bsp;<a href=3D"https://en.wikipedia.org/wiki/Austin_Group" class=3D"">says<=
/a> that POSIX is =E2=80=9Csimultaneously <a href=3D"http://www.i=
so.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=3D50516" c=
lass=3D"">ISO/IEC/IEEE 9945</a>.=E2=80=9D <a href=3D"http://Unix.org" class=
=3D"">Unix.org</a> has webpages for SUSv4 as <a href=3D"http://www.uni=
x.org/version4/iso_std.html" class=3D"">ISO</a> and <a href=3D"ht=
tp://www.unix.org/version4/ieee_std.html" class=3D"">IEEE</a>, which is fun=
ny given the =E2=80=9Csingle=E2=80=9D moniker. (Of course, they should diff=
er only on the cover page.)</div><div><br class=3D""></div><div>It seems th=
at SC22 (one level above WG21) now endorses the Austin Group work, but this=
is a new development since 2009. Of course, the important thing is getting=
coverage of all areas of expertise. It might be easier now to get Austin G=
roup folks to go to an ISO C++ meeting. (Or, maybe not.)</div><br class=3D"=
"><blockquote type=3D"cite" class=3D""><div class=3D""><blockquote type=3D"=
cite" class=3D"">It appears <<a href=3D"http://udrepper.livejournal.com/=
9183.html" class=3D"">http://udrepper.livejournal.com/9183.html</a>> tha=
t Drepper formed the group to /preempt/ an ISO/WG21 initiative. Given the a=
ttitude of that post, it=E2=80=99s not really surprising that nothing was a=
ccomplished.<br class=3D""></blockquote><br class=3D"">Sometimes, I feel th=
e C++ people are far away from the operating system people.<br class=3D""><=
/div></blockquote><div><br class=3D""></div><div>Yes. But, it might not be =
fair to use Drepper as a representative of =E2=80=9Coperating system people=
..=E2=80=9D He was a very controversial character.</div><br class=3D""><bloc=
kquote type=3D"cite" class=3D""><div class=3D"">Whenever we come up with an=
interface in C++, it's essentially a requirement<br class=3D"">that it be =
implementable on Unix, MacOS, and MS Windows. That's easy for<br clas=
s=3D"">containers, but a bit harder for something like file systems. =
There's little<br class=3D"">impetus to actually ask the operating system p=
eople to implement a new feature<br class=3D"">that would be useful to C++ =
at large.<br class=3D""><br class=3D"">(One example that is substantially b=
roader than Unix, MacOS, MS Windows is<br class=3D"">the "traditional linke=
r" issue: We essentially can't rely on more clever<br class=3D"">linkers th=
an 1980-style ones for C++.)<br class=3D""></div></blockquote><div><br clas=
s=3D""></div><div>A language/OS dichotomy might be too simplistic. Most OSe=
s have plug-in architectures to attach new filesystems, and filesystem deve=
lopers are always pushing adoption of their products into multiple OSes. Gi=
ven a widely-adopted and extensible C++ filesystem binding, e.g. ZFS could =
extend it to their own cross-platform binding.</div><div><br class=3D""></d=
iv><div>On the other hand, OS vendors seem to be moving away from POSIX and=
C in general, for proprietary mobile and server platforms. I fear the File=
system TS is too POSIX=E2=80=A6 it should support multiple independent file=
systems, and there should be more abstraction on permissions.</div><div><br=
class=3D""></div><div>Point is, standard C++ abstractions of OS services s=
houldn=E2=80=99t stop at the lowest common denominator. There should be roo=
m to extend standard facilities up to native functionality levels. OS vendo=
rs currently prefer to design entire custom C-like languages for the sake o=
f shipping better-than-C bindings, but that market-share can probably be wo=
n with the right strategy.</div><div><br class=3D""></div><blockquote type=
=3D"cite" class=3D""><div class=3D"">That's for the C++ standard offering. =
Some people might feel there's<br class=3D"">a useful layer in betwee=
n. Is there an operating system feature<br class=3D"">in POSIX that y=
ou want to use that is hard to implement on Windows,<br class=3D"">too? &nb=
sp;If yes, maybe it's time for a POSIX layer. If no, why not<br class=
=3D"">propose an interface to WG21 that can be implemented portably?<br cla=
ss=3D"">A lot more people would benefit. (Thinking about mmap, for ex=
ample.)<br class=3D""><br class=3D"">However, on the WG21 level, it seems w=
e've got too many people doing<br class=3D"">the "clever" and "interesting"=
stuff, which "mmap" probably isn't.<br class=3D"">And "mmap" isn't the ful=
l picture, what about async I/O on files etc.?<br class=3D"">Certainly we w=
ant some kind of "open file" RAII abstraction that fits<br class=3D"">easil=
y into all of this... (Defining and limiting scope is important,<br c=
lass=3D"">otherwise this gets nowhere.)<br class=3D""></div></blockquote><d=
iv><br class=3D""></div><div>We have <font face=3D"Courier" class=3D"">std:=
:basic_streambuf</font>. It=E2=80=99s not only files that are interesting, =
but I/O resources and data streams in general. There should be one abstract=
ion covering multithreaded work queues, pipes between processes, and networ=
k sockets. The amount of cruft in <font face=3D"Courier" class=3D"">streamb=
uf</font> is fairly low, so synchronization and maybe even async I/O should=
perhaps be added to it. I think the bigger problem is that people aren=E2=
=80=99t using the higher level <font face=3D"Courier" class=3D""><i=
ostream></font> library for heavy lifting. That part needs replacem=
ent.</div><div><br class=3D""></div><div>Using <font face=3D"Courier" class=
=3D"">mmap</font> with data structures tends to lead to fancy pointers=
, which are still relatively uncharted territory. Things are so interconnec=
ted, that even a thin POSIX layer would make good progress toward solving =
=E2=80=9Cinteresting=E2=80=9D problems in the deeper concept=E2=80=A6 as lo=
ng as no regrettable mistakes or restrictions are pulled along with it.</di=
v><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><bloc=
kquote type=3D"cite" class=3D"">Personally, I don=E2=80=99t care about gett=
ing an OOP window on POSIX. It would just be nice to access it without so m=
any macros and global-namespace entities.<br class=3D""></blockquote><br cl=
ass=3D"">Yes. Plus decent error handling instead of global errno<br c=
lass=3D"">creep, with which you have to deal very carefully.<br class=3D"">=
<br class=3D""><blockquote type=3D"cite" class=3D"">Perhaps some compiler-l=
evel metaprogram could be designed to sanitize platform headers without act=
ually touching them on disk. It could populate e.g. namespace posix and nam=
espace platform. Just dreaming=E2=80=A6<br class=3D""></blockquote><br clas=
s=3D"">Wake up, please.<br class=3D""></div></blockquote></div><br class=3D=
""><div class=3D"">Apparently Lisa Lippincott has <a href=3D"https://w=
ww.youtube.com/watch?v=3D3ZO0V4Prefc" class=3D"">pursued</a> a similar=
idea, a library called Po7 (pronounced P-O-seven). It takes care of errno,=
and more.</div><div class=3D""><br class=3D""></div><div class=3D"">The di=
fference is that a real binding should be exclusive, and the underlying lay=
er would not be defined at all. The =E2=80=9Ccompiler-level metaprogram=E2=
=80=9D would realize her mapping principles, taking the platform headers an=
d an interface description capturing e.g. the information listed on slide 1=
5 <a href=3D"https://github.com/CppCon/CppCon2014/raw/master/Presentat=
ions/How%20to%20call%20C%20libraries%20from%20C++/How%20to%20call%20C%20lib=
raries%20from%20C++%20-%20Lisa%20Lippincott%20-%20CppCon%202014.pdf" class=
=3D"">here</a>. The interface description would embody the C++ POSIX bindin=
g, and platform-specific extensions could be added alongside. The metaprogr=
am could perhaps be shoehorned into something like SWIG.</div><div class=3D=
""><br class=3D""></div><div class=3D"">I can=E2=80=99t find contact info f=
or Lisa, perhaps someone can forward this? Kudos to Magnus Fromreide for th=
e resource tip.</div><div class=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A92D4E84-0B6C-41A5-AEC2-571380D5B318--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Sun, 28 Jun 2015 16:55:07 +0200
Raw View
On 06/28/2015 04:21 PM, David Krauss wrote:
>=20
>> On 2015=E2=80=9306=E2=80=9328, at 3:21 AM, Jens Maurer <Jens.Maurer@gmx.=
net
>> <mailto:Jens.Maurer@gmx.net>> wrote:
>>=20
>> "Responsibility" sounds a bit too strong. Remember, all
>> committees and organizations we're talking about are driven by
>> volunteers.
>>=20
>> That said, POSIX is an IEEE enterprise and WG21 relates to
>> ISO/IEC. If WG21 tries to define a POSIX binding for some feature,
>> I'm not sure we'll have enough POSIX expertise in the room to make
>> it right.
> It seems that SC22 (one level above WG21) now endorses the Austin
> Group work, but this is a new development since 2009. Of course, the
> important thing is getting coverage of all areas of expertise. It
> might be easier now to get Austin Group folks to go to an ISO C++
> meeting. (Or, maybe not.)
ISO is definitely getting better in rubber-stamping the work
of other groups (e.g. Unicode or POSIX). And that's good to
an extend, since it would be ridiculous to double that work
within ISO for no extra benefit. That still doesn't solve
the issue of cross-domain expertise, e.g. C++ and POSIX.
>> (One example that is substantially broader than Unix, MacOS, MS
>> Windows is the "traditional linker" issue: We essentially can't
>> rely on more clever linkers than 1980-style ones for C++.)
>=20
> A language/OS dichotomy might be too simplistic. Most OSes have
> plug-in architectures to attach new filesystems, and filesystem
> developers are always pushing adoption of their products into
> multiple OSes. Given a widely-adopted and extensible C++ filesystem
> binding, e.g. ZFS could extend it to their own cross-platform
> binding.
A filesystem probably lives in the kernel, and the C++ interface
lives in userspace. C++ hasn't done its homework regarding stable
and evolution-friendly ABIs, I'd say, so I'm not sure we can go
forward without an intermediate C layer at the OS kernel boundary.
> On the other hand, OS vendors seem to be moving away from POSIX and C
> in general, for proprietary mobile and server platforms. I fear the
> Filesystem TS is too POSIX=E2=80=A6 it should support multiple independen=
t
> filesystems, and there should be more abstraction on permissions.
The filesystem TS is defined via POSIX, because that's easiest,
but reportedly an implementation on Windows does work, and the boost
experience seems to indicate there's real benefit in the abstraction
for real programs.
>> However, on the WG21 level, it seems we've got too many people
>> doing the "clever" and "interesting" stuff, which "mmap" probably
>> isn't. And "mmap" isn't the full picture, what about async I/O on
>> files etc.? Certainly we want some kind of "open file" RAII
>> abstraction that fits easily into all of this... (Defining and
>> limiting scope is important, otherwise this gets nowhere.)
>=20
> We have std::basic_streambuf. It=E2=80=99s not only files that are
> interesting, but I/O resources and data streams in general. There
> should be one abstraction covering multithreaded work queues, pipes
> between processes, and network sockets. The amount of cruft in
> streambuf is fairly low, so synchronization and maybe even async I/O
> should perhaps be added to it. I think the bigger problem is that
> people aren=E2=80=99t using the higher level <iostream> library for heavy
> lifting. That part needs replacement.
streambuf supports locales (search for "imbue"). That's one
(expensive) feature too much for a low-level near-OS interface.
> Using mmap with data structures tends to lead to fancy pointers,
> which are still relatively uncharted territory. Things are so
> interconnected, that even a thin POSIX layer would make good progress
> toward solving =E2=80=9Cinteresting=E2=80=9D problems in the deeper conce=
pt=E2=80=A6 as long
> as no regrettable mistakes or restrictions are pulled along with it.
Who's got the expertise to point out the mistakes and restrictions?
>>> Personally, I don=E2=80=99t care about getting an OOP window on POSIX. =
It
>>> would just be nice to access it without so many macros and
>>> global-namespace entities.
>>=20
>> Yes. Plus decent error handling instead of global errno creep,
>> with which you have to deal very carefully.
>>=20
>>> Perhaps some compiler-level metaprogram could be designed to
>>> sanitize platform headers without actually touching them on disk.
>>> It could populate e.g. namespace posix and namespace platform.
>>> Just dreaming=E2=80=A6
>>=20
>> Wake up, please.
>=20
> Apparently Lisa Lippincott has pursued
> <https://www.youtube.com/watch?v=3D3ZO0V4Prefc> a similar idea, a
> library called Po7 (pronounced P-O-seven). It takes care of errno,
> and more.
>=20
> The difference is that a real binding should be exclusive, and the
> underlying layer would not be defined at all. The =E2=80=9Ccompiler-level
> metaprogram=E2=80=9D would realize her mapping principles, taking the
> platform headers and an interface description capturing e.g. the
> information listed on slide 15 here
> <https://github.com/CppCon/CppCon2014/raw/master/Presentations/How%20to%2=
0call%20C%20libraries%20from%20C++/How%20to%20call%20C%20libraries%20from%2=
0C++%20-%20Lisa%20Lippincott%20-%20CppCon%202014.pdf>.
> The interface description would embody the C++ POSIX binding, and
> platform-specific extensions could be added alongside. The
> metaprogram could perhaps be shoehorned into something like SWIG.
>=20
> I can=E2=80=99t find contact info for Lisa, perhaps someone can forward t=
his?
> Kudos to Magnus Fromreide for the resource tip.
Well, if you believe there is value in having a 1:1 mapping of
POSIX calls into "namespace posix", with macros replaced by
"constexpr"s and "errno" somehow abandoned, that's probably a
relatively mechanical tasks once you've come to agreement
about the translation. (Do you want exceptions instead of
errno errors? Or something like the filesystem TS does?
Or expected<>? Or something else?)
But then, does that deliver enough benefit for the effort?
However, I wouldn't like to have features that acquire resources
without an RAII wrapper class (e.g. open, mmap, etc.) And there,
the work / discussions begin.
Jens
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 29 Jun 2015 00:44:39 +0800
Raw View
--Apple-Mail=_EB79A7A5-0796-47D5-8FF3-8C7A84FF5EF7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9328, at 10:55 PM, Jens Maurer <Jens.Maurer@gmx.=
net> wrote:
>=20
>=20
> ISO is definitely getting better in rubber-stamping the work
> of other groups (e.g. Unicode or POSIX). And that's good to
> an extend, since it would be ridiculous to double that work
> within ISO for no extra benefit. That still doesn't solve
> the issue of cross-domain expertise, e.g. C++ and POSIX.
Yes.
> A filesystem probably lives in the kernel, and the C++ interface
> lives in userspace. C++ hasn't done its homework regarding stable
> and evolution-friendly ABIs, I'd say, so I'm not sure we can go
> forward without an intermediate C layer at the OS kernel boundary.
Yes, typically there would be a C layer. But, that=E2=80=99s an implementat=
ion detail. A C++ binding is merely a C++ library interface spec. It would =
be nice to give resources and motivation to projects like ZFS to maintain s=
uch a thing. (Digging around a little, ZFS seems to prefer Java and Python=
=E2=80=A6 they maintain kernel extensions and high-level libraries but the =
immediate C interfaces are unstable.)
>> On the other hand, OS vendors seem to be moving away from POSIX and C
>> in general, for proprietary mobile and server platforms. I fear the
>> Filesystem TS is too POSIX=E2=80=A6 it should support multiple independe=
nt
>> filesystems, and there should be more abstraction on permissions.
>=20
> The filesystem TS is defined via POSIX, because that's easiest,
> but reportedly an implementation on Windows does work, and the boost
> experience seems to indicate there's real benefit in the abstraction
> for real programs.
It=E2=80=99s nice that the TS is out and working, but it would still be nic=
e if the standardized version had hooks to better represent platform-specif=
ic concepts of users and permissions (or lack thereof). Or at least, hooks =
to add hooks :) .
> streambuf supports locales (search for "imbue"). =20
Yes. I made the last major revision to the libstdc++ filebuf implementation=
..
> That's one
> (expensive) feature too much for a low-level near-OS interface.
Locale overhead is essentially nil for a codecvt that declares it does no c=
onversion. A hook for encoding conversion does belong there, because it=E2=
=80=99s sometimes necessary, and it needs to happen between the application=
and the bitstream. Codecvt has flexibility and usability issues, but not p=
erformance issues. (Incidentally, marriage to the UNIX-derived type mbstate=
_t ranks high among its problems.)
>> Using mmap with data structures tends to lead to fancy pointers,
>> which are still relatively uncharted territory. Things are so
>> interconnected, that even a thin POSIX layer would make good progress
>> toward solving =E2=80=9Cinteresting=E2=80=9D problems in the deeper conc=
ept=E2=80=A6 as long
>> as no regrettable mistakes or restrictions are pulled along with it.
>=20
> Who's got the expertise to point out the mistakes and restrictions?
Well, at some point we just have to try.
The same thing applies to the filesystem TS. Limiting permissions to enum p=
erms is pretty obviously restrictive. If the pressure toward ratification o=
verrides such concerns, then expertise is moot.
Damage is limited just by being in namespace posix, though. If, say, the en=
tire filesystem TS were standardized into namespace posix, then namespace s=
td would still be free to define templates and ABCs having the posix class =
interfaces as specializations and implementations, respectively.
It=E2=80=99s much safer to make even a rough POSIX thin layer in namespace =
posix, than to put a thicker version of the same thing in namespace std.
> Well, if you believe there is value in having a 1:1 mapping of
> POSIX calls into "namespace posix", with macros replaced by
> "constexpr"s and "errno" somehow abandoned, that's probably a
> relatively mechanical tasks once you've come to agreement
> about the translation. (Do you want exceptions instead of
> errno errors? Or something like the filesystem TS does?
> Or expected<>? Or something else?)
>=20
> But then, does that deliver enough benefit for the effort?
Yes! Because the effort was minimized. I think the presentation demonstrate=
s pretty well that low-hanging fruit is plenty tasty.
expected is nice, but it can be added later. errno gets set infrequently en=
ough to be converted to an exception in the first draft. The present expect=
ation that expected will exist should make that an easier decision.
> However, I wouldn't like to have features that acquire resources
> without an RAII wrapper class (e.g. open, mmap, etc.) And there,
> the work / discussions begin.
So=E2=80=A6 close/munmap on destruction. Since it=E2=80=99s a thin wrapper,=
we=E2=80=99re done. And spell it unique_ptr just so the user can have no i=
llusions.
These are unbuffered, unsynchronized, raw handles to the kernel. It=E2=80=
=99s OK for ordinary users to have a healthy fear of namespace posix, but t=
he current state of affairs is masochism.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_EB79A7A5-0796-47D5-8FF3-8C7A84FF5EF7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9328, at 10:55 PM, Jens Maurer <<a href=3D"mailto:Jens.Maurer@gmx=
..net" class=3D"">Jens.Maurer@gmx.net</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><div class=3D""><br class=3D"">ISO is definitely gett=
ing better in rubber-stamping the work<br class=3D"">of other groups (e.g. =
Unicode or POSIX). And that's good to<br class=3D"">an extend, since =
it would be ridiculous to double that work<br class=3D"">within ISO for no =
extra benefit. That still doesn't solve<br class=3D"">the issue of cr=
oss-domain expertise, e.g. C++ and POSIX.<br class=3D""></div></blockquote>=
<div><br class=3D""></div>Yes.</div><div><br class=3D""><blockquote type=3D=
"cite" class=3D""><div class=3D"">A filesystem probably lives in the kernel=
, and the C++ interface<br class=3D"">lives in userspace. C++ hasn't =
done its homework regarding stable<br class=3D"">and evolution-friendly ABI=
s, I'd say, so I'm not sure we can go<br class=3D"">forward without an inte=
rmediate C layer at the OS kernel boundary.<br class=3D""></div></blockquot=
e><div><br class=3D""></div><div>Yes, typically there would be a C layer. B=
ut, that=E2=80=99s an implementation detail. A C++ binding is merely a C++ =
library interface spec. It would be nice to give resources and motivation t=
o projects like ZFS to maintain such a thing. (Digging around a little, ZFS=
seems to prefer Java and Python=E2=80=A6 they maintain kernel extensions a=
nd high-level libraries but the immediate C interfaces are unstable.)</div>=
<br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><blockq=
uote type=3D"cite" class=3D"">On the other hand, OS vendors seem to be movi=
ng away from POSIX and C<br class=3D"">in general, for proprietary mobile a=
nd server platforms. I fear the<br class=3D"">Filesystem TS is too POSIX=E2=
=80=A6 it should support multiple independent<br class=3D"">filesystems, an=
d there should be more abstraction on permissions.<br class=3D""></blockquo=
te><br class=3D"">The filesystem TS is defined via POSIX, because that's ea=
siest,<br class=3D"">but reportedly an implementation on Windows does work,=
and the boost<br class=3D"">experience seems to indicate there's real bene=
fit in the abstraction<br class=3D"">for real programs.<br class=3D""></div=
></blockquote><div><br class=3D""></div><div>It=E2=80=99s nice that the TS =
is out and working, but it would still be nice if the standardized version =
had hooks to better represent platform-specific concepts of users and permi=
ssions (or lack thereof). Or at least, hooks to add hooks :) .</div><br cla=
ss=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">streambuf supp=
orts locales (search for "imbue"). </div></blockquote><div><br class=
=3D""></div><div>Yes. I made the last major revision to the libstdc++ <font=
face=3D"Courier" class=3D"">filebuf</font> implementation.</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">That's one<br cl=
ass=3D"">(expensive) feature too much for a low-level near-OS interface.<br=
class=3D""></div></blockquote><div><br class=3D""></div><div>Locale overhe=
ad is essentially nil for a codecvt that declares it does no conversion. A =
hook for encoding conversion does belong there, because it=E2=80=99s someti=
mes necessary, and it needs to happen between the application and the bitst=
ream. Codecvt has flexibility and usability issues, but not performance iss=
ues. (Incidentally, marriage to the UNIX-derived type <font face=3D"Courier=
" class=3D"">mbstate_t</font> ranks high among its problems.)</div><div><br=
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><blo=
ckquote type=3D"cite" class=3D"">Using mmap with data structures tends to l=
ead to fancy pointers,<br class=3D"">which are still relatively uncharted t=
erritory. Things are so<br class=3D"">interconnected, that even a thin POSI=
X layer would make good progress<br class=3D"">toward solving =E2=80=9Cinte=
resting=E2=80=9D problems in the deeper concept=E2=80=A6 as long<br class=
=3D"">as no regrettable mistakes or restrictions are pulled along with it.<=
br class=3D""></blockquote><br class=3D"">Who's got the expertise to point =
out the mistakes and restrictions?<br class=3D""></div></blockquote><div><b=
r class=3D""></div><div>Well, at some point we just have to try.</div><div>=
<br class=3D""></div><div>The same thing applies to the filesystem TS. Limi=
ting permissions to <font face=3D"Courier" class=3D"">enum perms</font> is =
pretty obviously restrictive. If the pressure toward ratification overrides=
such concerns, then expertise is moot.</div><div><br class=3D""></div><div=
>Damage is limited just by being in <font face=3D"Courier" class=3D"">names=
pace posix</font>, though. If, say, the entire filesystem TS were standardi=
zed into <font face=3D"Courier" class=3D"">namespace posix</font>, then <fo=
nt face=3D"Courier" class=3D"">namespace std</font> would still be free to =
define templates and ABCs having the <font face=3D"Courier" class=3D"">posi=
x</font> class interfaces as specializations and implementations, respectiv=
ely.</div><div><br class=3D""></div><div>It=E2=80=99s much safer to make ev=
en a rough POSIX thin layer in <font face=3D"Courier" class=3D"">namespace =
posix</font>, than to put a thicker version of the same thing in <font face=
=3D"Courier" class=3D"">namespace std</font>.</div><br class=3D""><blockquo=
te type=3D"cite" class=3D""><div class=3D"">Well, if you believe there is v=
alue in having a 1:1 mapping of<br class=3D"">POSIX calls into "namespace p=
osix", with macros replaced by<br class=3D"">"constexpr"s and "errno" someh=
ow abandoned, that's probably a<br class=3D"">relatively mechanical tasks o=
nce you've come to agreement<br class=3D"">about the translation. (Do=
you want exceptions instead of<br class=3D"">errno errors? Or someth=
ing like the filesystem TS does?<br class=3D"">Or expected<>? O=
r something else?)<br class=3D""><br class=3D"">But then, does that deliver=
enough benefit for the effort?<br class=3D""></div></blockquote><div><br c=
lass=3D""></div><div>Yes! Because the effort was minimized. I think the pre=
sentation demonstrates pretty well that low-hanging fruit is plenty tasty.<=
/div><div><br class=3D""></div><div><font face=3D"Courier" class=3D"">expec=
ted</font> is nice, but it can be added later. <font face=3D"Courier" =
class=3D"">errno</font> gets set infrequently enough to be converted to an =
exception in the first draft. The present expectation that <font face=
=3D"Courier" class=3D"">expected</font> will exist should make that an=
easier decision.</div><br class=3D""><blockquote type=3D"cite" class=3D"">=
<div class=3D"">However, I wouldn't like to have features that acquire reso=
urces<br class=3D"">without an RAII wrapper class (e.g. open, mmap, etc.) &=
nbsp;And there,<br class=3D"">the work / discussions begin.<br class=3D""><=
/div></blockquote></div><br class=3D""><div class=3D"">So=E2=80=A6 <font fa=
ce=3D"Courier" class=3D"">close</font>/<font face=3D"Courier" class=3D"">mu=
nmap</font> on destruction. Since it=E2=80=99s a thin wrapper, we=E2=80=99r=
e done. And spell it <font face=3D"Courier" class=3D"">unique_ptr</font> ju=
st so the user can have no illusions.</div><div class=3D""><br class=3D""><=
/div><div class=3D"">These are unbuffered, unsynchronized, raw handles to t=
he kernel. It=E2=80=99s OK for ordinary users to have a healthy fear of <fo=
nt face=3D"Courier" class=3D"">namespace posix</font>, but the current stat=
e of affairs is masochism.</div><div class=3D""><br class=3D""></div></body=
></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_EB79A7A5-0796-47D5-8FF3-8C7A84FF5EF7--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Sun, 28 Jun 2015 19:38:04 +0200
Raw View
On 06/28/2015 06:44 PM, David Krauss wrote:
>>> On the other hand, OS vendors seem to be moving away from POSIX
>>> and C in general, for proprietary mobile and server platforms. I
>>> fear the Filesystem TS is too POSIX=E2=80=A6 it should support multiple
>>> independent filesystems, and there should be more abstraction on
>>> permissions.
>>=20
>> The filesystem TS is defined via POSIX, because that's easiest, but
>> reportedly an implementation on Windows does work, and the boost=20
>> experience seems to indicate there's real benefit in the
>> abstraction for real programs.
>=20
> It=E2=80=99s nice that the TS is out and working, but it would still be n=
ice=20
> if the standardized version had hooks to better represent=20
> platform-specific concepts of users and permissions (or lack=20
> thereof). Or at least, hooks to add hooks :) .
Even Unix has access control lists these days.
But, what are the hooks supposed to look like so that they're
flexible enough to support the variety of existing (and
future?) filesystems / permissions schemes? It seems this
needs a bit of research. And while we're at it, I'd love
to see openat() and friends mapped to the filesystem TS.
>> streambuf supports locales (search for "imbue").
>=20
> Yes. I made the last major revision to the libstdc++ filebuf
> implementation.
>=20
>> That's one (expensive) feature too much for a low-level near-OS
>> interface.
>=20
> Locale overhead is essentially nil for a codecvt that declares it=20
> does no conversion. A hook for encoding conversion does belong
> there, because it=E2=80=99s sometimes necessary, and it needs to happen
> between the application and the bitstream.
I disagree. I think a byte-stream is a fundamental abstraction that
the application should be able to access with no abstraction penalty.
(If you want to consider the byte-stream as text and do codecvt, be
my guest, but that's an optional add-on.)
> Codecvt has flexibility and usability issues, but not performance
> issues. (Incidentally, marriage to the UNIX-derived type mbstate_t
> ranks high among its problems.)
Hm... Don't you have to query the global locale if "imbue" is not
called, and that can be changed program-wide via setlocale() at any
time, so there's some thread synchronization involved? Maybe I'm
totally misguided here.
>>> Using mmap with data structures tends to lead to fancy pointers,=20
>>> which are still relatively uncharted territory. Things are so=20
>>> interconnected, that even a thin POSIX layer would make good
>>> progress toward solving =E2=80=9Cinteresting=E2=80=9D problems in the d=
eeper
>>> concept=E2=80=A6 as long as no regrettable mistakes or restrictions are
>>> pulled along with it.
>>=20
>> Who's got the expertise to point out the mistakes and
>> restrictions?
>=20
> Well, at some point we just have to try.
>=20
> The same thing applies to the filesystem TS. Limiting permissions to
> enum perms is pretty obviously restrictive. If the pressure toward
> ratification overrides such concerns, then expertise is moot.
Note that a TS is just that: a TS to gain experience. If you feel
the permissions interface doesn't help, write a paper explaining
that.
> Damage is limited just by being in namespace posix, though. If, say,
> the entire filesystem TS were standardized into namespace posix, then
> namespace std would still be free to define templates and ABCs having
> the posix class interfaces as specializations and implementations,
> respectively.
The benefit of the filesystem TS is that it provides portable access
to common tree-structured filesystems (directory iteration etc), and
that seems to be a pretty portable OS assumption.
> It=E2=80=99s much safer to make even a rough POSIX thin layer in namespac=
e
> posix, than to put a thicker version of the same thing in namespace
> std.
And less useful in terms of writing programs that are portable
across all/most C++ implementations.
>> Well, if you believe there is value in having a 1:1 mapping of=20
>> POSIX calls into "namespace posix", with macros replaced by=20
>> "constexpr"s and "errno" somehow abandoned, that's probably a=20
>> relatively mechanical tasks once you've come to agreement about the
>> translation. (Do you want exceptions instead of errno errors? Or
>> something like the filesystem TS does? Or expected<>? Or something
>> else?)
>>=20
>> But then, does that deliver enough benefit for the effort?
>=20
> Yes! Because the effort was minimized. I think the presentation
> demonstrates pretty well that low-hanging fruit is plenty tasty.
>=20
> expected is nice, but it can be added later. errno gets set
> infrequently enough to be converted to an exception in the first
> draft. The present expectation that expected will exist should make
> that an easier decision.
I disagree. The filesystem TS papers have sufficient rationale
that exceptions-on-error are not always suitable for everyone.
And throwing an exception carries a substantial performance cost.
>> However, I wouldn't like to have features that acquire resources=20
>> without an RAII wrapper class (e.g. open, mmap, etc.) And there,=20
>> the work / discussions begin.
>=20
> So=E2=80=A6 close/munmap on destruction. Since it=E2=80=99s a thin wrappe=
r, we=E2=80=99re
> done. And spell it unique_ptr just so the user can have no
> illusions.
Shouldn't all the calls that take an "int fd" in POSIX now take one
of those RAII things? unique_ptr sounds awfully disingenous for that
broad a usage.
> These are unbuffered, unsynchronized, raw handles to the kernel. It=E2=80=
=99s
> OK for ordinary users to have a healthy fear of namespace posix,
Agreed so far.
> but
> the current state of affairs is masochism.
Apparently, not enough people are hurt to invest time and effort
into proposing a change.
Jens
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 29 Jun 2015 18:26:27 +0800
Raw View
--Apple-Mail=_435FC9B6-1E11-4D02-8A8D-CD14CDCB5E8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9329, at 1:38 AM, Jens Maurer <Jens.Maurer@gmx.n=
et> wrote:
>=20
> Even Unix has access control lists these days.
>=20
> But, what are the hooks supposed to look like so that they're
> flexible enough to support the variety of existing (and
> future?) filesystems / permissions schemes? It seems this
> needs a bit of research. =20
The problem is more fundamental than file permissions. Standard abstraction=
s of OS services should always have room for platform-specific extensions. =
The right answer is probably pimpl, but there are plenty of alternatives.
I think there=E2=80=99s an easy answer for permissions, at least for now: o=
mit them completely.
> And while we're at it, I'd love
> to see openat() and friends mapped to the filesystem TS.
CWD manipulation can be framed as separate filesystem handles. A single roo=
t path for all named resources and a working directory are both UNIX/POSIX =
concepts that aren=E2=80=99t necessarily popular with other OSes, or releva=
nt in an era where URLs are taking over.
> I disagree. I think a byte-stream is a fundamental abstraction that
> the application should be able to access with no abstraction penalty.
> (If you want to consider the byte-stream as text and do codecvt, be
> my guest, but that's an optional add-on.)
>=20
> Hm... Don't you have to query the global locale if "imbue" is not
> called, and that can be changed program-wide via setlocale() at any
> time, so there's some thread synchronization involved? Maybe I'm
> totally misguided here.
The streambuf constructor does an imbue(locale()), leaving it oblivious to =
the underlying environment ([streambuf.cons] =C2=A727.6.3.1).
The abstraction penalty amounts to one saved locale* and one saved bool ind=
icating that no conversion needs to be done, which is only checked while fl=
ushing/reloading. (GNU caches a codecvt* too.) Moving conversion to the app=
lication would make it less efficient and less flexible. wfstream does conv=
ersion, wstringstream doesn=E2=80=99t, but they both go through the same AB=
C.
Before I got sidetracked by a job in 2010, I was experimenting with codecvt=
s implementing encryption and data compression. They have a lot of potentia=
l, which has gone unrealized due to the POSIX-related mbstate_t portability=
issue, poor implementation conformance, and incoherent specification.
By the way, you mentioned setlocale. That=E2=80=99s a C function which isn=
=E2=80=99t necessarily synchronized with C++ locales. Broken <locale> imple=
mentations abound, though, and sometimes setlocale is the only mechanism th=
at works. Again, because the C/POSIX interface is what OS implementers pay =
attention to, and it=E2=80=99s hard for a C++ stdlib to be cross-platform, =
even when the C layer is supposedly standardized. The C++ =E2=80=9Clocaliza=
tion library=E2=80=9D (a name which seems to greatly overstate the scope of=
its functionality) would pretty certainly have been better off with a thin=
wrapper, considering the users stuck with the C library as a proxy for mis=
sing C++ implementation.
Perhaps LWG would be interested in a case study of locale support, for the =
sake of insight into the cost of wrapper thickness.
>> The same thing applies to the filesystem TS. Limiting permissions to
>> enum perms is pretty obviously restrictive. If the pressure toward
>> ratification overrides such concerns, then expertise is moot.
>=20
> Note that a TS is just that: a TS to gain experience. If you feel
> the permissions interface doesn't help, write a paper explaining
> that.
Is unhelpfulness a provable hypothesis?
It would be nice to get feedback from an OS vendor employee who promotes up=
take of security features. I only know as much as the next guy: Classic UNI=
X permissions are deprecated on recent server platforms, and seldom were ev=
er used aside from server software and OS internals.
It=E2=80=99s particularly surprising that user (and group) IDs are absent f=
rom the TS. What=E2=80=99s the use of knowing that the file is writable by =
the group, if there=E2=80=99s no way to know which group. Again, this seems=
too obvious to write a paper. It looks like someone went halfway down the =
slippery slope of adopting POSIX, and I=E2=80=99d prefer to preempt that de=
bate than to wade into the middle of it.
>> Damage is limited just by being in namespace posix, though. If, say,
>> the entire filesystem TS were standardized into namespace posix, then
>> namespace std would still be free to define templates and ABCs having
>> the posix class interfaces as specializations and implementations,
>> respectively.
>=20
> The benefit of the filesystem TS is that it provides portable access
> to common tree-structured filesystems (directory iteration etc), and
> that seems to be a pretty portable OS assumption.
That sounds like a job for a more general template or ABC, not something wi=
th symlink support baked in. Its one-size-fits-all approach also falls shor=
t of POSIX <ftw.h> and standard-tracked <fts.h>.
A traversal utility in std should be safe, simple, and generic. You give it=
a path and it returns only paths which are properly under it and unsurpris=
ing. It should have well-specified behavior wrt interprocess race condition=
s, i.e. the spec should warn the user that such things can happen. There sh=
ould be no directory_options argument because all those options are platfor=
m-specific.
Anything more complicated, dealing with symlinks, mount points, permissions=
, directory locking, etc, should come from some interface other than the ba=
sic traversal utility. Maybe the full-featured version belongs in std with =
conditionally-supported status. Maybe the basic version is potentially a ty=
pedef to a special case of the full-featured version. Maybe the problem is =
solved by filesystem views, as I suggested for CWD manipulation. But uncond=
itionally hard-coding a subset of common, yet not universal options smacks =
of compromise.
>> It=E2=80=99s much safer to make even a rough POSIX thin layer in namespa=
ce
>> posix, than to put a thicker version of the same thing in namespace
>> std.
>=20
> And less useful in terms of writing programs that are portable
> across all/most C++ implementations.
Compared to making POSIX assumptions in namespace std? Is std::create_symli=
nk portable to systems with no symlinks, just because it=E2=80=99s required=
to build and fail at runtime?
namespace posix isn=E2=80=99t an all-or-nothing proposition. Platforms with=
a few POSIX features can populate it partially. Either way, programs needi=
ng POSIX functionality won=E2=80=99t work on systems without it, and std is=
the wrong place to add POSIX emulation.
>> Yes! Because the effort was minimized. I think the presentation
>> demonstrates pretty well that low-hanging fruit is plenty tasty.
>>=20
>> expected is nice, but it can be added later. errno gets set
>> infrequently enough to be converted to an exception in the first
>> draft. The present expectation that expected will exist should make
>> that an easier decision.
>=20
> I disagree. The filesystem TS papers have sufficient rationale
> that exceptions-on-error are not always suitable for everyone.
> And throwing an exception carries a substantial performance cost.
So, add error_code& overloads as necessary. They can be there initially or =
added later. No big deal.
>>> However, I wouldn't like to have features that acquire resources=20
>>> without an RAII wrapper class (e.g. open, mmap, etc.) And there,=20
>>> the work / discussions begin.
>>=20
>> So=E2=80=A6 close/munmap on destruction. Since it=E2=80=99s a thin wrapp=
er, we=E2=80=99re
>> done. And spell it unique_ptr just so the user can have no
>> illusions.
>=20
> Shouldn't all the calls that take an "int fd" in POSIX now take one
> of those RAII things? unique_ptr sounds awfully disingenous for that
> broad a usage.
There=E2=80=99s a proposal for unique_resource, which is like unique_ptr bu=
t doesn=E2=80=99t add a star to its type parameter. Anyway, it goes behind =
a typedef, so the user shouldn=E2=80=99t tell difference. (I lied that it=
=E2=80=99s literally spelled like that every time.)
>> These are unbuffered, unsynchronized, raw handles to the kernel. It=E2=
=80=99s
>> OK for ordinary users to have a healthy fear of namespace posix,
>=20
> Agreed so far.
>=20
>> but
>> the current state of affairs is masochism.
>=20
> Apparently, not enough people are hurt to invest time and effort
> into proposing a change.
There=E2=80=99s a first time for everything. You=E2=80=99re investing your =
brain cells into this debate, too ;) .
The masochism argument understates the motivation, though.
1. Put POSIX in its place so it stops getting sucked into std. And keep it =
there with a low-effort mapping policy.
2. Give std templates something to specialize on to gain POSIX awareness, a=
nd create a place for POSIX encapsulations derived from std ABCs.
3. Allow implementation freedom to remove the pollution of the POSIX C bind=
ing from the C++ environment. The C standard library, too.
4. Let POSIX usage be easier, safer, and less noisy as demonstrated by Lipp=
incott.
5. Establish principles to let the same apply to all C libraries.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_435FC9B6-1E11-4D02-8A8D-CD14CDCB5E8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9329, at 1:38 AM, Jens Maurer <<a href=3D"mailto:Jens.Maurer@gmx.=
net" class=3D"">Jens.Maurer@gmx.net</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><span style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;" class=3D"">Even Unix has access control lists t=
hese days.</span><br style=3D"font-family: Helvetica; font-size: 12px; font=
-style: normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; text-indent:=
0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family=
: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fon=
t-weight: normal; letter-spacing: normal; line-height: normal; orphans: aut=
o; text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" c=
lass=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; line-height: normal; orphans: auto; text-align: start; text-indent: 0px;=
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px=
; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"=
class=3D"">But, what are the hooks supposed to look like so that they're</=
span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: norm=
al; font-variant: normal; font-weight: normal; letter-spacing: normal; line=
-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-t=
ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk=
it-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetic=
a; font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-al=
ign: start; text-indent: 0px; text-transform: none; white-space: normal; wi=
dows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none;=
display: inline !important;" class=3D"">flexible enough to support the var=
iety of existing (and</span><br style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; float: none; display: inline !important;" class=3D"">future?) =
filesystems / permissions schemes? It seems this</span><br style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !i=
mportant;" class=3D"">needs a bit of research. </span></div></blockqu=
ote><div><br class=3D""></div><div>The problem is more fundamental than fil=
e permissions. Standard abstractions of OS services should always have room=
for platform-specific extensions. The right answer is probably pimpl, but =
there are plenty of alternatives.</div><div><br class=3D""></div><div>I thi=
nk there=E2=80=99s an easy answer for permissions, at least for now: omit t=
hem completely.</div><div><br class=3D""></div><blockquote type=3D"cite" cl=
ass=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inli=
ne !important;" class=3D"">And while we're at it, I'd love</span><br style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inli=
ne !important;" class=3D"">to see openat() and friends mapped to the filesy=
stem TS.</span><br style=3D"font-family: Helvetica; font-size: 12px; font-s=
tyle: normal; font-variant: normal; font-weight: normal; letter-spacing: no=
rmal; line-height: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote><div><b=
r class=3D""></div><div>CWD manipulation can be framed as separate filesyst=
em handles. A single root path for all named resources and a working direct=
ory are both UNIX/POSIX concepts that aren=E2=80=99t necessarily popular wi=
th other OSes, or relevant in an era where URLs are taking over.</div><br c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; float: none; display: inline !important;" class=3D"">I disagre=
e. I think a byte-stream is a fundamental abstraction that</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-=
variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:=
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display:=
inline !important;" class=3D"">the application should be able to access wi=
th no abstraction penalty.</span><br style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px; float: none; display: inline !important;" class=3D"">(If yo=
u want to consider the byte-stream as text and do codecvt, be</span><br sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: auto; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stro=
ke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant: normal; font-weight: normal; lett=
er-spacing: normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: in=
line !important;" class=3D"">my guest, but that's an optional add-on.)</spa=
n><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px;" class=3D""></div></blockquote><blockquote type=3D"=
cite" class=3D""><br class=3D""></blockquote><blockquote type=3D"cite" clas=
s=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline=
!important;" class=3D"">Hm... Don't you have to query the global locale if=
"imbue" is not</span><br style=3D"font-family: Helvetica; font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px; float: none; display: inline !important;" class=3D"">called, and that =
can be changed program-wide via setlocale() at any</span><br style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; fon=
t-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
normal; line-height: normal; orphans: auto; text-align: start; text-indent=
: 0px; text-transform: none; white-space: normal; widows: auto; word-spacin=
g: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !impor=
tant;" class=3D"">time, so there's some thread synchronization involved? &n=
bsp;Maybe I'm</span><br style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-f=
amily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; white-sp=
ace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0p=
x; float: none; display: inline !important;" class=3D"">totally misguided h=
ere.</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
-webkit-text-stroke-width: 0px;" class=3D""></div></blockquote><div><br cl=
ass=3D""></div><div>The <font face=3D"Courier" class=3D"">streambuf</font> =
constructor does an <font face=3D"Courier" class=3D"">imbue(locale())</font=
>, leaving it oblivious to the underlying environment ([streambuf.cons] =C2=
=A727.6.3.1).</div><div><br class=3D""></div><div>The abstraction penalty a=
mounts to one saved <font face=3D"Courier" class=3D"">locale*</font> and on=
e saved <font face=3D"Courier" class=3D"">bool</font> indicating that no co=
nversion needs to be done, which is only checked while flushing/reloading. =
(GNU caches a <font face=3D"Courier" class=3D"">codecvt*</font> too.) Movin=
g conversion to the application would make it less efficient and less flexi=
ble. <font face=3D"Courier" class=3D"">wfstream</font> does conversion=
, <font face=3D"Courier" class=3D"">wstringstream</font> doesn=E2=80=99t, b=
ut they both go through the same ABC.</div><div><br class=3D""></div><div>B=
efore I got sidetracked by a job in 2010, I was experimenting with codecvts=
implementing encryption and data compression. They have a lot of potential=
, which has gone unrealized due to the POSIX-related <font face=3D"Cou=
rier" class=3D"">mbstate_t</font> portability issue, poor implementati=
on conformance, and incoherent specification.</div><div><br class=3D""></di=
v><div>By the way, you mentioned <font face=3D"Courier" class=3D"">set=
locale</font>. That=E2=80=99s a C function which isn=E2=80=99t necessarily =
synchronized with C++ locales. Broken <font face=3D"Courier" class=3D""><=
;locale></font> implementations abound, though, and sometimes <font=
face=3D"Courier" class=3D"">setlocale</font> is the only mechanism that wo=
rks. Again, because the C/POSIX interface is what OS implementers pay atten=
tion to, and it=E2=80=99s hard for a C++ stdlib to be cross-platform, even =
when the C layer is supposedly standardized. The C++ =E2=80=9Clocalization =
library=E2=80=9D (a name which seems to greatly overstate the scope of its =
functionality) would pretty certainly have been better off with a thin wrap=
per, considering the users stuck with the C library as a proxy for missing =
C++ implementation.</div><div><br class=3D""></div><div>Perhaps LWG would b=
e interested in a case study of locale support, for the sake of insight int=
o the cost of wrapper thickness.</div><br class=3D""><blockquote type=3D"ci=
te" class=3D""><div class=3D""><blockquote type=3D"cite" style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"=
class=3D"">The same thing applies to the filesystem TS. Limiting permissio=
ns to<br class=3D"">enum perms is pretty obviously restrictive. If the pres=
sure toward<br class=3D"">ratification overrides such concerns, then expert=
ise is moot.<br class=3D""></blockquote><br style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><=
span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px; float: none; display: inline !important;" class=3D""=
>Note that a TS is just that: a TS to gain experience. If you feel</s=
pan><br style=3D"font-family: Helvetica; font-size: 12px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">the permissions interface doesn't h=
elp, write a paper explaining</span><br style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px; float: none; display: inline !important;" class=3D"">tha=
t.</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; te=
xt-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -=
webkit-text-stroke-width: 0px;" class=3D""></div></blockquote><div><br clas=
s=3D""></div><div>Is unhelpfulness a provable hypothesis?</div><div><br cla=
ss=3D""></div><div>It would be nice to get feedback from an OS vendor emplo=
yee who promotes uptake of security features. I only know as much as the ne=
xt guy: Classic UNIX permissions are deprecated on recent server platforms,=
and seldom were ever used aside from server software and OS internals.</di=
v><div><br class=3D""></div><div>It=E2=80=99s particularly surprising that =
user (and group) IDs are absent from the TS. What=E2=80=99s the use of know=
ing that the file is writable by the group, if there=E2=80=99s no way to kn=
ow which group. Again, this seems too obvious to write a paper. It looks li=
ke someone went halfway down the slippery slope of adopting POSIX, and I=E2=
=80=99d prefer to preempt that debate than to wade into the middle of it.</=
div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><bl=
ockquote type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Damage is limited just=
by being in namespace posix, though. If, say,<br class=3D"">the entire fil=
esystem TS were standardized into namespace posix, then<br class=3D"">names=
pace std would still be free to define templates and ABCs having<br class=
=3D"">the posix class interfaces as specializations and implementations,<br=
class=3D"">respectively.<br class=3D""></blockquote><br style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"=
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px; float: none; display: inline !important=
;" class=3D"">The benefit of the filesystem TS is that it provides portable=
access</span><br style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;" class=3D"">to common tree-structured=
filesystems (directory iteration etc), and</span><br style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cl=
ass=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
-webkit-text-stroke-width: 0px; float: none; display: inline !important;" =
class=3D"">that seems to be a pretty portable OS assumption.</span><br styl=
e=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-vari=
ant: normal; font-weight: normal; letter-spacing: normal; line-height: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px;" class=3D""></div></blockquote><div><br class=3D""></div><div=
>That sounds like a job for a more general template or ABC, not something w=
ith symlink support baked in. Its one-size-fits-all approach also falls sho=
rt of POSIX <font face=3D"Courier" class=3D""><ftw.h></font> and=
standard-tracked <font face=3D"Courier" class=3D""><fts.h></fon=
t>.</div><div><br class=3D""></div><div>A traversal utility in <font face=
=3D"Courier" class=3D"">std</font> should be safe, simple, and generic. You=
give it a path and it returns only paths which are properly under it and u=
nsurprising. It should have well-specified behavior wrt interprocess race c=
onditions, i.e. the spec should warn the user that such things can happen. =
There should be no <font face=3D"Courier" class=3D"">directory_options=
</font> argument because all those options are platform-specific.</div><div=
><br class=3D""></div><div>Anything more complicated, dealing with symlinks=
, mount points, permissions, directory locking, etc, should come from some =
interface other than the basic traversal utility. Maybe the full-featured v=
ersion belongs in <font face=3D"Courier" class=3D"">std</font> with conditi=
onally-supported status. Maybe the basic version is potentially a typedef t=
o a special case of the full-featured version. Maybe the problem is solved =
by filesystem views, as I suggested for CWD manipulation. But unconditional=
ly hard-coding a subset of common, yet not universal options smacks of comp=
romise.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">It=E2=80=99s =
much safer to make even a rough POSIX thin layer in namespace<br class=3D""=
>posix, than to put a thicker version of the same thing in namespace<br cla=
ss=3D"">std.<br class=3D""></blockquote><br style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><=
span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px; float: none; display: inline !important;" class=3D""=
>And less useful in terms of writing programs that are portable</span><br s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">across all/most C++ implementations.</span><=
br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;" class=3D""></div></blockquote><div><br class=3D""></d=
iv><div>Compared to making POSIX assumptions in namespace std? Is <font fac=
e=3D"Courier" class=3D"">std::create_symlink</font> portable to system=
s with no symlinks, just because it=E2=80=99s required to build and fail at=
runtime?</div><div><br class=3D""></div><div><font face=3D"Courier" class=
=3D"">namespace posix</font> isn=E2=80=99t an all-or-nothing proposition. P=
latforms with a few POSIX features can populate it partially. Either way, p=
rograms needing POSIX functionality won=E2=80=99t work on systems without i=
t, and <font face=3D"Courier" class=3D"">std</font> is the wrong place to a=
dd POSIX emulation.</div><br class=3D""><blockquote type=3D"cite" class=3D"=
"><div class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Y=
es! Because the effort was minimized. I think the presentation<br class=3D"=
">demonstrates pretty well that low-hanging fruit is plenty tasty.<br class=
=3D""><br class=3D"">expected is nice, but it can be added later. errno get=
s set<br class=3D"">infrequently enough to be converted to an exception in =
the first<br class=3D"">draft. The present expectation that expected will e=
xist should make<br class=3D"">that an easier decision.<br class=3D""></blo=
ckquote><br style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: no=
ne; display: inline !important;" class=3D"">I disagree. The filesyste=
m TS papers have sufficient rationale</span><br style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D=
""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: norm=
al; font-variant: normal; font-weight: normal; letter-spacing: normal; line=
-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-t=
ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk=
it-text-stroke-width: 0px; float: none; display: inline !important;" class=
=3D"">that exceptions-on-error are not always suitable for everyone.</span>=
<br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; disp=
lay: inline !important;" class=3D"">And throwing an exception carries a sub=
stantial performance cost.</span><br style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></=
blockquote><div><br class=3D""></div><div>So, add <font face=3D"Courier" cl=
ass=3D"">error_code&</font> overloads as necessary. They can be there i=
nitially or added later. No big deal.</div><br class=3D""><blockquote type=
=3D"cite" class=3D""><div class=3D""><blockquote type=3D"cite" style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph=
ans: auto; text-align: start; text-indent: 0px; text-transform: none; white=
-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width:=
0px;" class=3D""><blockquote type=3D"cite" class=3D"">However, I wouldn't =
like to have features that acquire resources<span class=3D"Apple-converted-=
space"> </span><br class=3D"">without an RAII wrapper class (e.g. open=
, mmap, etc.) And there,<span class=3D"Apple-converted-space"> <=
/span><br class=3D"">the work / discussions begin.<br class=3D""></blockquo=
te><br class=3D"">So=E2=80=A6 close/munmap on destruction. Since it=E2=80=
=99s a thin wrapper, we=E2=80=99re<br class=3D"">done. And spell it unique_=
ptr just so the user can have no<br class=3D"">illusions.<br class=3D""></b=
lockquote><br style=3D"font-family: Helvetica; font-size: 12px; font-style:=
normal; font-variant: normal; font-weight: normal; letter-spacing: normal;=
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Hel=
vetica; font-size: 12px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;" class=3D"">Shouldn't all the calls that =
take an "int fd" in POSIX now take one</span><br style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;" cla=
ss=3D"">of those RAII things? unique_ptr sounds awfully disingenous f=
or that</span><br style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;" class=3D"">broad a usage.</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-=
variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:=
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px;" class=3D""></div></blockquote><div><br class=3D""></div>=
<div>There=E2=80=99s a proposal for <font face=3D"Courier" class=3D"">uniqu=
e_resource</font>, which is like <font face=3D"Courier" class=3D"">unique_p=
tr</font> but doesn=E2=80=99t add a star to its type parameter. Anyway, it =
goes behind a typedef, so the user shouldn=E2=80=99t tell difference. (I li=
ed that it=E2=80=99s literally spelled like that every time.)</div><br clas=
s=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><blockquote typ=
e=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; li=
ne-height: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D"">These are unbuffered, unsynchroniz=
ed, raw handles to the kernel. It=E2=80=99s<br class=3D"">OK for ordinary u=
sers to have a healthy fear of namespace posix,<br class=3D""></blockquote>=
<br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; disp=
lay: inline !important;" class=3D"">Agreed so far.</span><br style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;" class=3D""><br style=3D"font-family: Helvetica; font-size: 12px; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
0px; -webkit-text-stroke-width: 0px;" class=3D""><blockquote type=3D"cite"=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px;" class=3D"">but<br class=3D"">the current state of affai=
rs is masochism.<br class=3D""></blockquote><br style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D=
""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: norm=
al; font-variant: normal; font-weight: normal; letter-spacing: normal; line=
-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-t=
ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk=
it-text-stroke-width: 0px; float: none; display: inline !important;" class=
=3D"">Apparently, not enough people are hurt to invest time and effort</spa=
n><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; di=
splay: inline !important;" class=3D"">into proposing a change.</span><br st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px;" class=3D""></div></blockquote></div><br class=3D""><div cl=
ass=3D"">There=E2=80=99s a first time for everything. You=E2=80=99re invest=
ing your brain cells into this debate, too ;) .</div><div class=3D""><br cl=
ass=3D""></div><div class=3D"">The masochism argument understates the motiv=
ation, though.</div><div class=3D""><br class=3D""></div><div class=3D"">1.=
Put POSIX in its place so it stops getting sucked into <font face=3D"Couri=
er" class=3D"">std</font>. And keep it there with a low-effort mapping poli=
cy.</div><div class=3D"">2. Give <font face=3D"Courier" class=3D"">std</fon=
t> templates something to specialize on to gain POSIX awareness, and c=
reate a place for POSIX encapsulations derived from <font face=3D"Courier" =
class=3D"">std</font> ABCs.</div><div class=3D"">3. Allow implementation fr=
eedom to remove the pollution of the POSIX C binding from the C++ environme=
nt. The C standard library, too.</div><div class=3D"">4. Let POSIX usage be=
easier, safer, and less noisy as demonstrated by Lippincott.</div><div cla=
ss=3D"">5. Establish principles to let the same apply to all C libraries.</=
div><div class=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_435FC9B6-1E11-4D02-8A8D-CD14CDCB5E8D--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 6 Jul 2015 13:20:22 -0700 (PDT)
Raw View
------=_Part_1237_885682765.1436214023081
Content-Type: multipart/alternative;
boundary="----=_Part_1238_1461073998.1436214023081"
------=_Part_1238_1461073998.1436214023081
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, June 29, 2015 at 3:26:41 AM UTC-7, David Krauss wrote:
>
>
> And while we're at it, I'd love
> to see openat() and friends mapped to the filesystem TS.
>
>
> CWD manipulation can be framed as separate filesystem handles. A single=
=20
> root path for all named resources and a working directory are both=20
> UNIX/POSIX concepts that aren=E2=80=99t necessarily popular with other OS=
es, or=20
> relevant in an era where URLs are taking over.
>
>
I'd like to chime in regarding this and Windows...
Windows NT actually predates Linux in its support for the equivalent of=20
openat(): its file API from day one (version 3.1) supported specifying a=20
file handle to an open directory from which paths should be interpreted. =
=20
This is still supported. In fact, the concept of "current working=20
directory" *doesn't exist* at the kernel level (*). ntdll.dll in user mode=
=20
simply keeps an open directory handle to what is considered the current=20
directory, and applies it to Win32 paths.
However, this support is officially undocumented. The Win32 API as=20
documented--CreateFileW(), CreateDirectoryExW(), etc.--does *not* support=
=20
specifying a root path to which paths are to be interpreted, and=20
automatically uses the current directory as needed. You have to use the=20
undocumented "native" NT API in order to get the openat()-like=20
functionality--with NtCreateFile(), for example. Many of the=20
"undocumented" NT APIs like NtCreateFile() are in fact documented for=20
kernel-mode driver developers, and are so widely used despite their=20
"undocumented" nature that it is unrealistic for Microsoft to change them,=
=20
but it is mostly irresponsible to use these APIs from production-quality=20
user-mode software.
In short, it's bad to assume that something like openat() always exists. =
=20
It's probably also bad to assume that the concept of a current directory=20
also exists.
(*) Until Windows Vista, when the kernel became aware of the current=20
directory handle as part of changes that were for DRM enforcement reasons. =
=20
No, I am not kidding about this.
Melissa
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1238_1461073998.1436214023081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<iframe style=3D"padding: 0px; position: absolute; top: 0px; left: 0px; wid=
th: 1125px; height: 188px; visibility: hidden;" frameborder=3D"0"></iframe>=
On Monday, June 29, 2015 at 3:26:41 AM UTC-7, David Krauss wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div><br><blockquote><div><span style=3D=
"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal=
;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
float:none;display:inline!important">And while we're at it, I'd love</span>=
<br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va=
riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px"><span style=3D"font-family:Helvetica;font-size:12px;font-style=
:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-h=
eight:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;float:none;display:inline!important">to see open=
at() and friends mapped to the filesystem TS.</span><br style=3D"font-famil=
y:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weigh=
t:normal;letter-spacing:normal;line-height:normal;text-align:start;text-ind=
ent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></bl=
ockquote><div><br></div><div>CWD manipulation can be framed as separate fil=
esystem handles. A single root path for all named resources and a working d=
irectory are both UNIX/POSIX concepts that aren=E2=80=99t necessarily popul=
ar with other OSes, or relevant in an era where URLs are taking over.</div>=
<br></div></blockquote><div><br>I'd like to chime in regarding this and Win=
dows...<br><br>Windows NT actually predates Linux in its support for the eq=
uivalent of <span style=3D"font-family: courier new,monospace;">openat()</s=
pan>: its file API from day one (version 3.1) supported specifying a file h=
andle to an open directory from which paths should be interpreted. Th=
is is still supported. In fact, the concept of "current working direc=
tory" <i>doesn't exist</i> at the kernel level (*). ntdll.dll in user=
mode simply keeps an open directory handle to what is considered the curre=
nt directory, and applies it to Win32 paths.<br><br>However, this support i=
s officially undocumented. The Win32 API as documented--<span style=
=3D"font-family: courier new,monospace;">CreateFileW()</span>, <span style=
=3D"font-family: courier new,monospace;">CreateDirectoryExW()</span>, etc.-=
-does <i>not</i> support specifying a root path to which paths are to be in=
terpreted, and automatically uses the current directory as needed. Yo=
u have to use the undocumented "native" NT API in order to get the <span st=
yle=3D"font-family: courier new,monospace;">openat()-</span>like functional=
ity--with <span style=3D"font-family: courier new,monospace;">NtCreateFile(=
)</span>, for example. Many of the "undocumented" NT APIs like <span =
style=3D"font-family: courier new,monospace;">NtCreateFile()</span> are in =
fact documented for kernel-mode driver developers, and are so widely used d=
espite their "undocumented" nature that it is unrealistic for Microsoft to =
change them, but it is mostly irresponsible to use these APIs from producti=
on-quality user-mode software.<br><br>In short, it's bad to assume that som=
ething like <span style=3D"font-family: courier new,monospace;">openat()</s=
pan> always exists. It's probably also bad to assume that the concept=
of a current directory also exists.<br><br>(*) Until Windows Vista, when t=
he kernel became aware of the current directory handle as=20
part of changes that were for DRM enforcement reasons. No, I am not=
=20
kidding about this.<br><br>Melissa<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1238_1461073998.1436214023081--
------=_Part_1237_885682765.1436214023081--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 9 Jul 2015 15:30:00 -0700 (PDT)
Raw View
------=_Part_1417_1478441118.1436481000205
Content-Type: multipart/alternative;
boundary="----=_Part_1418_2045776661.1436481000205"
------=_Part_1418_2045776661.1436481000205
Content-Type: text/plain; charset=UTF-8
Op zondag 28 juni 2015 19:38:07 UTC+2 schreef Jens Maurer:
>
> Shouldn't all the calls that take an "int fd" in POSIX now take one
> of those RAII things? unique_ptr sounds awfully disingenous for that
> broad a usage.
No, it should take the equivalent of a reference (or a raw pointer) if it's
not dealing with ownership.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1418_2045776661.1436481000205
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Op zondag 28 juni 2015 19:38:07 UTC+2 schreef Jens=
Maurer:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Shouldn't all the =
calls that take an "int fd" in POSIX now take one
<br>of those RAII things? =C2=A0unique_ptr sounds awfully disingenous for t=
hat
<br>broad a usage.
</blockquote><div><br></div><div>No, it should take the equivalent of a ref=
erence (or a raw pointer) if it's not dealing with ownership.</div></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1418_2045776661.1436481000205--
------=_Part_1417_1478441118.1436481000205--
.