------=_Part_2090_462902255.1416144266011
Content-Type: text/plain; charset=UTF-8

Hi,

Would there be any interest in wrappers for native raw (file) IO and FILE*?

Sometimes one needs native handles or FILE* for interoperability or special
features like memory mapped IO, but standard C++ doesn't provide convenient
RAII friendly wrappers for these.
The idea seems trivial yet quite useful.
I've put a simple start for FILE* at
https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/cfile.h
What do you think?

Grtz,

Olaf

--

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

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>Would there be any inter=
est in wrappers for native raw (file) IO and FILE*?</div><div><br></div><di=
v>Sometimes one needs native handles or FILE* for interoperability or speci=
al features like memory mapped IO, but standard C++ doesn't provide conveni=
ent RAII friendly wrappers for these.</div><div>The idea seems trivial yet =
quite useful.</div><div>I've put a simple start for FILE* at https://code.g=
oogle.com/p/xbt/source/browse/trunk/xbt/misc/xbt/cfile.h</div><div>What do =
you think?</div><div><br></div><div>Grtz,</div><div><br></div><div>Olaf</di=
v></div>

<p></p>

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

------=_Part_2090_462902255.1416144266011--

.

Le 16/11/14 14:24, Olaf van der Spek a =C3=A9crit :
> Hi,
>
> Would there be any interest in wrappers for native raw (file) IO and=20
> FILE*?
>
> Sometimes one needs native handles or FILE* for interoperability or=20
> special features like memory mapped IO, but standard C++ doesn't=20
> provide convenient RAII friendly wrappers for these.
> The idea seems trivial yet quite useful.
> I've put a simple start for FILE* at=20
> https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/cfile.h
> What do you think?
>
Hi,

There is an on going proposal=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3949.pdf, in=20
case this is what you are looking for.

Vicente

--=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_3569_1226763846.1416268045252
Content-Type: text/plain; charset=UTF-8



On Sunday, November 16, 2014 3:11:03 PM UTC+1, Vicente J. Botet Escriba
wrote:
>
> There is an on going proposal
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3949.pdf, in
> case this is what you are looking for.
>
>
It's not really, but thx. It does take care of the RAII part but it doesn't
standardize a raw IO interface.

--

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

<div dir=3D"ltr"><br><br>On Sunday, November 16, 2014 3:11:03 PM UTC+1, Vic=
ente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Th=
ere is an on going proposal=20
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n394=
9.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2014%2Fn3949.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNF93WGcnZiZA1xQ_17Gq-y=
V3Wgh0g';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014=
%2Fn3949.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNF93WGcnZiZA1xQ_17Gq-yV3Wgh0=
g';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/20=
14/<wbr>n3949.pdf</a>, in=20
<br>case this is what you are looking for.
<br><br></blockquote><div><br></div><div>It's not really, but thx. It does =
take care of the RAII part but it doesn't standardize a raw IO interface.</=
div><div><br></div></div>

<p></p>

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

------=_Part_3569_1226763846.1416268045252--

.

--Apple-Mail=_9163F25E-EC9B-4217-93A7-DDD39B17A848
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9318, at 7:47 AM, Olaf van der Spek <olafvdspek@gm=
ail.com> wrote:

> It's not really, but thx. It does take care of the RAII part but it doesn=
't standardize a raw IO interface.

FILE is buffered, not raw I/O. std::filebuf is the replacement. I=E2=80=99m=
 not sure why there=E2=80=99s no sync_with_stdio and FILE access for buffer=
s besides the three standard streams, but surely it was considered back whe=
n <iostream> was standardized. Perhaps it would after all make sense to hav=
e a separate class stdiobuf, but such a feature sounds fatally unsexy. IIRC=
 you can find such a thing as a documented extra feature in the GNU library=
, and likely in others too. I don=E2=80=99t think it would make sense to pr=
ovide any other C++ interface to FILE.

Raw file descriptors have widely varying semantics so it=E2=80=99s hard to =
do anything really reliably without constraining an FD to a particular kind=
 of resource=E2=80=A6 including close(), which negates the value of using s=
coped_resource so generically.

--=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=_9163F25E-EC9B-4217-93A7-DDD39B17A848
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014=
=E2=80=9311=E2=80=9318, at 7:47 AM, Olaf van der Spek &lt;<a href=3D"mailto=
:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I=
t's not really, but thx. It does take care of the RAII part but it doesn't =
standardize a raw IO interface.</div></blockquote><br></div><div><font face=
=3D"Courier">FILE</font> is buffered, not raw I/O. <font face=3D"Courier">s=
td::filebuf</font>&nbsp;is the replacement. I=E2=80=99m not sure why there=
=E2=80=99s no <font face=3D"Courier">sync_with_stdio</font>&nbsp;and <font =
face=3D"Courier">FILE</font> access for buffers besides the three standard =
streams, but surely it was considered back when <font face=3D"Courier">&lt;=
iostream&gt;</font> was standardized. Perhaps it would after all make sense=
 to have a separate class <font face=3D"Courier">stdiobuf</font>, but such =
a feature sounds fatally unsexy. IIRC you can find such a thing as a docume=
nted extra feature in the GNU library, and likely in others too. I don=E2=
=80=99t think it would make sense to provide any other C++ interface to <fo=
nt face=3D"Courier">FILE</font>.</div><br><div>Raw file descriptors have wi=
dely varying semantics so it=E2=80=99s hard to do anything really reliably =
without constraining an FD to a particular kind of resource=E2=80=A6 includ=
ing <font face=3D"Courier">close()</font>, which negates the value of using=
 <font face=3D"Courier">scoped_resource</font> so generically.</div></body>=
</html>

<p></p>

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

--Apple-Mail=_9163F25E-EC9B-4217-93A7-DDD39B17A848--

.

On Tue, Nov 18, 2014 at 2:27 AM, David Krauss <potswa@gmail.com> wrote:
> FILE is buffered, not raw I/O.

I know, my idea is to offer two separate classes. One for native IO
and one for FILE.

> std::filebuf is the replacement. I=E2=80=99m not sure
> why there=E2=80=99s no sync_with_stdio and FILE access for buffers beside=
s the three
> standard streams, but surely it was considered back when <iostream> was
> standardized. Perhaps it would after all make sense to have a separate cl=
ass
> stdiobuf, but such a feature sounds fatally unsexy. IIRC you can find suc=
h a
> thing as a documented extra feature in the GNU library, and likely in oth=
ers
> too. I don=E2=80=99t think it would make sense to provide any other C++ i=
nterface to
> FILE.

Some C libs use FILE paramters. You can't get a FILE* from a
std::filebuf can you?

> Raw file descriptors have widely varying semantics so it=E2=80=99s hard t=
o do
> anything really reliably without constraining an FD to a particular kind =
of
> resource=E2=80=A6 including close(), which negates the value of using
> scoped_resource so generically.

My idea was to focus on files. What differences in semantics would be
showstoppers for such a wrapper?
Do you think standard unbuffered file IO does not make sense?

--=20
Olaf

--=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=_CA00E043-10C3-4B3E-9E06-C20F2E1F6A2D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9318, at 5:50 PM, Olaf van der Spek <olafvdspek@gm=
ail.com> wrote:

> Some C libs use FILE paramters. You can't get a FILE* from a
> std::filebuf can you?

That=E2=80=99s what I mean by =E2=80=9Cclass stdiobuf.=E2=80=9D It would be=
 compliant to implement filebuf like this, but likely poor QOI. The problem=
 is that streambuf exposes a raw memory interface, and the only way to let =
its internal pointers update stdio would be to write the C library around t=
he C++ library.

GNU stdio_filebuf is a thin wrapper providing direct access to a FILE*, but=
 it=E2=80=99s unsynchronized. On the other hand their stdio_sync_filebuf is=
 synchronized but that means bypassing the C++ buffering, and given a curso=
ry reading of the source, it doesn=E2=80=99t use the locale codecvt either.

From the user=E2=80=99s perspective, anyway, <stdio.h> and FILE do exactly =
the same sort of buffering as filebuf, so a new interface wouldn=E2=80=99t =
be justified.

>> Raw file descriptors have widely varying semantics so it=E2=80=99s hard =
to do
>> anything really reliably without constraining an FD to a particular kind=
 of
>> resource=E2=80=A6 including close(), which negates the value of using
>> scoped_resource so generically.
>=20
> My idea was to focus on files. What differences in semantics would be
> showstoppers for such a wrapper?
> Do you think standard unbuffered file IO does not make sense?

POSIX close has a lot of edge cases. Depending on the kind of resource, it =
might block or the file descriptor may not be freed for reuse immediately. =
It might even fail and require a retry, on some systems.

FDs cover raw devices, memory maps, network connections, etc. For unbuffere=
d files, we already have std::filebuf::pubsetbuf. Offering a FD wrapper sup=
porting only files would be misleading to the user.

--=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=_CA00E043-10C3-4B3E-9E06-C20F2E1F6A2D
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014=
=E2=80=9311=E2=80=9318, at 5:50 PM, Olaf van der Spek &lt;<a href=3D"mailto=
:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite">Some C libs use FI=
LE paramters. You can't get a FILE* from a<br>std::filebuf can you?<br></bl=
ockquote><div><br></div><div>That=E2=80=99s what I mean by =E2=80=9C<font f=
ace=3D"Courier">class stdiobuf</font>.=E2=80=9D It would be compliant to im=
plement <font face=3D"Courier">filebuf</font> like this, but likely poor QO=
I. The problem is that <font face=3D"Courier">streambuf</font> exposes a ra=
w memory interface, and the only way to let its internal pointers update <f=
ont face=3D"Courier">stdio</font> would be to write the C library around th=
e C++ library.</div><div><br></div><div>GNU <font face=3D"Courier">stdio_fi=
lebuf</font> is a thin wrapper providing direct access to a <font face=3D"C=
ourier">FILE*</font>, but it=E2=80=99s unsynchronized. On the other hand th=
eir <font face=3D"Courier">stdio_sync_filebuf</font>&nbsp;is synchronized b=
ut that means bypassing the C++ buffering, and given a cursory reading of t=
he source, it doesn=E2=80=99t use the locale codecvt either.</div><div><br>=
</div><div>From the user=E2=80=99s perspective, anyway,&nbsp;<font face=3D"=
Courier">&lt;stdio.h&gt;</font> and <font face=3D"Courier">FILE</font> do e=
xactly the same sort of buffering as <font face=3D"Courier">filebuf</font>,=
 so a new interface wouldn=E2=80=99t be justified.</div><br><blockquote typ=
e=3D"cite"><blockquote type=3D"cite">Raw file descriptors have widely varyi=
ng semantics so it=E2=80=99s hard to do<br>anything really reliably without=
 constraining an FD to a particular kind of<br>resource=E2=80=A6 including =
close(), which negates the value of using<br>scoped_resource so generically=
..<br></blockquote><br>My idea was to focus on files. What differences in se=
mantics would be<br>showstoppers for such a wrapper?<br>Do you think standa=
rd unbuffered file IO does not make sense?<br></blockquote><div><br></div><=
div>POSIX <font face=3D"Courier">close</font> has a lot of edge cases. Depe=
nding on the kind of resource, it might block or the file descriptor may no=
t be freed for reuse immediately. It might even fail and require a retry, o=
n some systems.</div><div><br></div></div>FDs cover raw devices, memory map=
s, network connections, etc. For unbuffered files, we already have <font fa=
ce=3D"Courier">std::filebuf::pubsetbuf</font>. Offering a FD wrapper suppor=
ting only files would be misleading to the user.</body></html>

<p></p>

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

--Apple-Mail=_CA00E043-10C3-4B3E-9E06-C20F2E1F6A2D--

.

On 11/16/2014 7:24 AM, Olaf van der Spek wrote:
> Hi,
>
> Would there be any interest in wrappers for native raw (file) IO and FILE*?

I'd be very interested in wrappers for native file handles (file
descriptors and Windows HANDLEs). I brought this up on the discussion
list here:
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/macDvhFDrjU>.
I haven't had the chance to write up a proposal yet, though.

- Jim


--

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

.

On Wed, Nov 19, 2014 at 12:13 AM, David Krauss <potswa@gmail.com> wrote:
> From the user=E2=80=99s perspective, anyway, <stdio.h> and FILE do exactl=
y the same
> sort of buffering as filebuf, so a new interface wouldn=E2=80=99t be just=
ified.

That doesn't solve the problem of interoperability with FILE* (in a
nice C++ way).

> POSIX close has a lot of edge cases. Depending on the kind of resource, i=
t
> might block or the file descriptor may not be freed for reuse immediately=
..

How's that a problem?
If it is a problem, hasn't it already been solved for FILE and fstream clos=
e()?


> It might even fail and require a retry, on some systems.

Are you sure?
Linux man says: "Note that the return value should only be used for
diagnostics.  In particular close() should not be retried after an
EINTR since this may cause a reused descriptor from another thread to
be closed."

> FDs cover raw devices, memory maps, network connections, etc. For unbuffe=
red
> files, we already have std::filebuf::pubsetbuf. Offering a FD wrapper
> supporting only files would be misleading to the user.

If it happens to support other stuff that'd be fine with me.


--=20
Olaf

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

.

On 2014=E2=80=9311=E2=80=9319, at 7:05 PM, Olaf van der Spek <olafvdspek@gm=
ail.com> wrote:

> That doesn't solve the problem of interoperability with FILE* (in a
> nice C++ way).

I think the GNU solutions are about as good as we can hope for. What else d=
o you intend to gain?

>> POSIX close has a lot of edge cases. Depending on the kind of resource, =
it
>> might block or the file descriptor may not be freed for reuse immediatel=
y.
>=20
> How's that a problem?
> If it is a problem, hasn't it already been solved for FILE and fstream cl=
ose()?

It=E2=80=99s a problem that the user can accidentally pass something beside=
s an ordinary file.

It=E2=80=99s not solved in the standard library for things that have pathna=
mes but shouldn=E2=80=99t be buffered (e.g. in /dev).

Creating an access interface that doesn=E2=80=99t require a pathname, and t=
herefore is specifically suited to things without names or that aren=E2=80=
=99t definitely owned by the C++ object, is pure danger.

>> It might even fail and require a retry, on some systems.
>=20
> Are you sure?
> Linux man says: "Note that the return value should only be used for
> diagnostics.  In particular close() should not be retried after an
> EINTR since this may cause a reused descriptor from another thread to
> be closed.=E2=80=9D

It says that to contrast with other operating systems. IIRC Solaris is an o=
ffender. There=E2=80=99s plenty of literature on the general topic, for exa=
mple http://stackoverflow.com/q/22603025/153285 .

>> Offering a FD wrapper
>> supporting only files would be misleading to the user.
>=20
> If it happens to support other stuff that'd be fine with me.

For other stuff the user would have the appearance of support but actual lu=
rking errors in buffering and portability.

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

.

On 19 November 2014 17:18, David Krauss <potswa@gmail.com> wrote:
>> How's that a problem?
>> If it is a problem, hasn't it already been solved for FILE and fstream c=
lose()?
> It=E2=80=99s a problem that the user can accidentally pass something besi=
des an ordinary file.
> It=E2=80=99s not solved in the standard library for things that have path=
names but shouldn=E2=80=99t be buffered (e.g. in /dev).

Well, if a user decides to create a buffered stream on top of such a
descriptor, why
should we prevent that? You can already do that in posix with fdopen and th=
ere's
no particular protection against that, and it's questionable whether
any protection
is necessary.

> Creating an access interface that doesn=E2=80=99t require a pathname, and=
 therefore is specifically suited to things without names or that aren=E2=
=80=99t definitely owned by the C++ object, is pure danger.

What danger?

>>> Offering a FD wrapper
>>> supporting only files would be misleading to the user.
>>
>> If it happens to support other stuff that'd be fine with me.
> For other stuff the user would have the appearance of support but actual =
lurking errors in buffering and portability.

Also, for other stuff, the user would gain the ability to use C++
iostreams on top of a wide
variety of things where it would work, and does work with existing
extensions just fine, like pipes.

--=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=_82B33690-CA14-4822-B166-6177CBF1C784
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9319, at 11:39 PM, Ville Voutilainen <ville.voutil=
ainen@gmail.com> wrote:

> On 19 November 2014 17:18, David Krauss <potswa@gmail.com> wrote:
>>> How's that a problem?
>>> If it is a problem, hasn't it already been solved for FILE and fstream =
close()?
>> It=E2=80=99s a problem that the user can accidentally pass something bes=
ides an ordinary file.
>> It=E2=80=99s not solved in the standard library for things that have pat=
hnames but shouldn=E2=80=99t be buffered (e.g. in /dev).
>=20
> Well, if a user decides to create a buffered stream on top of such a
> descriptor, why
> should we prevent that? You can already do that in posix with fdopen and =
there's
> no particular protection against that, and it's questionable whether
> any protection
> is necessary.

POSIX isn=E2=80=99t a role model for safety.

>> Creating an access interface that doesn=E2=80=99t require a pathname, an=
d therefore is specifically suited to things without names or that aren=E2=
=80=99t definitely owned by the C++ object, is pure danger.
>=20
> What danger?

Danger of continuing to use the FD or FILE despite the assumed ownership by=
 the C++ object, or after the C++ object is destroyed. The implicit close i=
s going to be surprising. =E2=80=9CYes, you can use your C resource with C+=
+, but then you can=E2=80=99t use it with C again without reopening it usin=
g the path/URL.=E2=80=9D

Danger of buffering something that shouldn=E2=80=99t be buffered, like a so=
cket or a pipe. basic_filebuf may assume end-of-file when a read operation =
fails to fill the entire buffer, but that doesn=E2=80=99t hold true for suc=
h resources. Actual behavior may be platform-specific.

> Also, for other stuff, the user would gain the ability to use C++
> iostreams on top of a wide
> variety of things where it would work, and does work with existing
> extensions just fine, like pipes.

An unbuffered and non-owning descriptor streambuf might be reasonable. Adop=
ting existing extensions is a better idea than adopting certain capabilitie=
s of existing extensions into existing facilities, or reinventing the wheel=
..

Raw I/O is often done asynchronously, though, so it might be better to exte=
nd Networking TS facilities to cover local devices and files than to start =
with a raw streambuf and try to lump FILE in the same extension. Boost.ASIO=
 isn=E2=80=99t specifically a network library, in the first place. I=E2=80=
=99ve not used ASIO nor reviewed the TS so I can=E2=80=99t really speak to =
that, though. I see that it does have a socket_streambuf interface to iostr=
eams, though.

--=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=_82B33690-CA14-4822-B166-6177CBF1C784
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014=
=E2=80=9311=E2=80=9319, at 11:39 PM, Ville Voutilainen &lt;<a href=3D"mailt=
o:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</=
div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 19=
 November 2014 17:18, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">=
potswa@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite">How's that a problem?<br>If it is a problem, hasn't it already =
been solved for FILE and fstream close()?<br></blockquote>It=E2=80=99s a pr=
oblem that the user can accidentally pass something besides an ordinary fil=
e.<br>It=E2=80=99s not solved in the standard library for things that have =
pathnames but shouldn=E2=80=99t be buffered (e.g. in /dev).<br></blockquote=
><br>Well, if a user decides to create a buffered stream on top of such a<b=
r>descriptor, why<br>should we prevent that? You can already do that in pos=
ix with fdopen and there's<br>no particular protection against that, and it=
's questionable whether<br>any protection<br>is necessary.<br></blockquote>=
<div><br></div><div>POSIX isn=E2=80=99t a role model for safety.</div><br><=
blockquote type=3D"cite"><blockquote type=3D"cite">Creating an access inter=
face that doesn=E2=80=99t require a pathname, and therefore is specifically=
 suited to things without names or that aren=E2=80=99t definitely owned by =
the C++ object, is pure danger.<br></blockquote><br>What danger?<br></block=
quote><div><br></div><div>Danger of continuing to use the FD or FILE despit=
e the assumed ownership by the C++ object, or after the C++ object is destr=
oyed. The implicit <font face=3D"Courier">close</font> is going to be surpr=
ising. =E2=80=9CYes, you can use your C resource with C++, but then you can=
=E2=80=99t use it with C again without reopening it using the path/URL.=E2=
=80=9D</div><div><br></div><div>Danger of buffering something that shouldn=
=E2=80=99t be buffered, like a socket or a pipe. <font face=3D"Courier">bas=
ic_filebuf</font> may assume end-of-file when a read operation fails to fil=
l the entire buffer, but that doesn=E2=80=99t hold true for such resources.=
 Actual behavior may be platform-specific.</div><br><blockquote type=3D"cit=
e">Also, for other stuff, the user would gain the ability to use C++<br>ios=
treams on top of a wide<br>variety of things where it would work, and does =
work with existing<br>extensions just fine, like pipes.<br></blockquote><di=
v><br></div><div>An unbuffered and non-owning descriptor&nbsp;<font face=3D=
"Courier">streambuf</font> might be reasonable. Adopting existing extension=
s is a better idea than adopting certain capabilities of existing extension=
s into existing facilities, or reinventing the wheel.</div><div><br></div><=
div>Raw I/O is often done asynchronously, though, so it might be better to =
extend Networking TS facilities to cover local devices and files than to st=
art with a raw&nbsp;<font face=3D"Courier">streambuf</font>&nbsp;and try to=
 lump FILE in the same extension. Boost.ASIO isn=E2=80=99t specifically a n=
etwork library, in the first place. I=E2=80=99ve not used ASIO nor reviewed=
 the TS so I can=E2=80=99t really speak to that, though. I see that it does=
 have a <font face=3D"Courier">socket_streambuf</font> interface to iostrea=
ms, though.</div></div></body></html>

<p></p>

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

--Apple-Mail=_82B33690-CA14-4822-B166-6177CBF1C784--

.

On 21 November 2014 06:11, David Krauss <potswa@gmail.com> wrote:
> It=E2=80=99s a problem that the user can accidentally pass something besi=
des an
> ordinary file.
> It=E2=80=99s not solved in the standard library for things that have path=
names but
> shouldn=E2=80=99t be buffered (e.g. in /dev).
>
>
> Well, if a user decides to create a buffered stream on top of such a
> descriptor, why
> should we prevent that? You can already do that in posix with fdopen and
> there's
> no particular protection against that, and it's questionable whether
> any protection
> is necessary.
>
>
> POSIX isn=E2=80=99t a role model for safety.

I didn't claim it was. I asked why we should prevent such opening of a stre=
am
on top of a descriptor.

> What danger?
>
>
> Danger of continuing to use the FD or FILE despite the assumed ownership =
by
> the C++ object, or after the C++ object is destroyed. The implicit close =
is

Which doesn't sound different from the "danger" of continuing to use a raw
pointer despite the assumed ownership by a unique_ptr.

> going to be surprising. =E2=80=9CYes, you can use your C resource with C+=
+, but then

The implicit close is going to be what people expect, if we're going to fli=
ng
out anecdotal guesses with regards to what will happen amongst random
users.

> Danger of buffering something that shouldn=E2=80=99t be buffered, like a =
socket or a
> pipe. basic_filebuf may assume end-of-file when a read operation fails to
> fill the entire buffer, but that doesn=E2=80=99t hold true for such resou=
rces.

I fail to see how the unlikely potential of incorrect implementation is a r=
eason
not to add the facility.

> Raw I/O is often done asynchronously, though, so it might be better to
> extend Networking TS facilities to cover local devices and files than to
> start with a raw streambuf and try to lump FILE in the same extension.

I don't quite recall anyone suggesting "starting with a raw streambuf
and lumping FILE in the same extension", so I don't quite grasp how
we got there.

--=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=_EA46CFEF-A41A-45C6-A69E-624F8BF7E107
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9321, at 12:37 PM, Ville Voutilainen <ville.voutil=
ainen@gmail.com> wrote:

> On 21 November 2014 06:11, David Krauss <potswa@gmail.com> wrote:
>> Danger of continuing to use the FD or FILE despite the assumed ownership=
 by
>> the C++ object, or after the C++ object is destroyed. The implicit close=
 is
>=20
> Which doesn't sound different from the "danger" of continuing to use a ra=
w
> pointer despite the assumed ownership by a unique_ptr.

The purpose of unique_ptr is to express and implement ownership. Filebuf an=
d iostreams provide buffering and parsing, and the motivation in this case =
is to glue together existing libraries in C and C++. Shared ownership would=
 be essential to usefulness, never mind what=E2=80=99s surprising.

>> Danger of buffering something that shouldn=E2=80=99t be buffered, like a=
 socket or a
>> pipe. basic_filebuf may assume end-of-file when a read operation fails t=
o
>> fill the entire buffer, but that doesn=E2=80=99t hold true for such reso=
urces.
>=20
> I fail to see how the unlikely potential of incorrect implementation is a=
 reason
> not to add the facility.

That=E2=80=99s not an incorrect implementation, it=E2=80=99s the current no=
rm.

Sockets are buffered by the OS socket library, not by any user-level class.=
 There=E2=80=99s no way to correctly buffer sockets by yourself or to put o=
ne inside a FILE.

>> Raw I/O is often done asynchronously, though, so it might be better to
>> extend Networking TS facilities to cover local devices and files than to
>> start with a raw streambuf and try to lump FILE in the same extension.
>=20
> I don't quite recall anyone suggesting "starting with a raw streambuf
> and lumping FILE in the same extension", so I don't quite grasp how
> we got there.

You mentioned that existing extensions exist to handle e.g. pipes, although=
 you didn=E2=80=99t mention any. GNU stdio_sync_streambuf is one. That gene=
ral avenue could be pursued, but I think Boost.ASIO could be more fertile g=
round.

--=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=_EA46CFEF-A41A-45C6-A69E-624F8BF7E107
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014=
=E2=80=9311=E2=80=9321, at 12:37 PM, Ville Voutilainen &lt;<a href=3D"mailt=
o:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</=
div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 21=
 November 2014 06:11, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">=
potswa@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite">Danger of cont=
inuing to use the FD or FILE despite the assumed ownership by</blockquote><=
blockquote type=3D"cite">the C++ object, or after the C++ object is destroy=
ed. The implicit close is<br></blockquote><br>Which doesn't sound different=
 from the "danger" of continuing to use a raw<br>pointer despite the assume=
d ownership by a unique_ptr.<br></blockquote><div><br></div><div>The purpos=
e of <font face=3D"Courier">unique_ptr</font> is to express and implement o=
wnership. Filebuf and iostreams provide buffering and parsing, and the moti=
vation in this case is to glue together existing libraries in C and C++. Sh=
ared ownership would be essential to usefulness, never mind what=E2=80=99s =
surprising.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite">Da=
nger of buffering something that shouldn=E2=80=99t be buffered, like a sock=
et or a<br>pipe. basic_filebuf may assume end-of-file when a read operation=
 fails to<br>fill the entire buffer, but that doesn=E2=80=99t hold true for=
 such resources.<br></blockquote><br>I fail to see how the unlikely potenti=
al of incorrect implementation is a reason<br>not to add the facility.<br><=
/blockquote><div><br></div><div>That=E2=80=99s not an incorrect implementat=
ion, it=E2=80=99s the current norm.</div><div><br></div><div>Sockets are bu=
ffered by the OS socket library, not by any user-level class. There=E2=80=
=99s no way to correctly buffer sockets by yourself or to put one inside a =
FILE.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite">Raw I/O =
is often done asynchronously, though, so it might be better to<br>extend Ne=
tworking TS facilities to cover local devices and files than to<br>start wi=
th a raw streambuf and try to lump FILE in the same extension.<br></blockqu=
ote><br>I don't quite recall anyone suggesting "starting with a raw streamb=
uf<br>and lumping FILE in the same extension", so I don't quite grasp how<b=
r>we got there.<br></blockquote><div><br></div></div>You mentioned that exi=
sting extensions exist to handle e.g. pipes, although you didn=E2=80=99t me=
ntion any.&nbsp;GNU&nbsp;<font face=3D"Courier">stdio_sync_streambuf</font>=
&nbsp;is one. That general avenue could be pursued, but I think Boost.ASIO =
could be more fertile ground.</body></html>

<p></p>

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

--Apple-Mail=_EA46CFEF-A41A-45C6-A69E-624F8BF7E107--

.

On 21 November 2014 07:10, David Krauss <potswa@gmail.com> wrote:
> Which doesn't sound different from the "danger" of continuing to use a ra=
w
> pointer despite the assumed ownership by a unique_ptr.
>
>
> The purpose of unique_ptr is to express and implement ownership. Filebuf =
and
> iostreams provide buffering and parsing, and the motivation in this case =
is

And they also implement resource ownership, and have done so since
before unique_ptr or even auto_ptr were introduced.

> to glue together existing libraries in C and C++. Shared ownership would =
be
> essential to usefulness, never mind what=E2=80=99s surprising.

Motivation in this case is to be able to open the underlying platform facil=
ity
and wrap it under an iostream, not the sharing of the descriptor with
platform-specific
code.

>
> Danger of buffering something that shouldn=E2=80=99t be buffered, like a =
socket or a
> pipe. basic_filebuf may assume end-of-file when a read operation fails to
> fill the entire buffer, but that doesn=E2=80=99t hold true for such resou=
rces.
>
>
> I fail to see how the unlikely potential of incorrect implementation is a
> reason
> not to add the facility.
>
>
> That=E2=80=99s not an incorrect implementation, it=E2=80=99s the current =
norm.

Funny how that current norm is not the current norm - if my fstream
over a networked
file system file fails to fill the entire buffer, it will block, not eof-cl=
ose.

> Sockets are buffered by the OS socket library, not by any user-level clas=
s.
> There=E2=80=99s no way to correctly buffer sockets by yourself or to put =
one inside
> a FILE.

I must say I have no idea what you're talking about here.

Do you have actual reasons why we shouldn't provide iostreams over native
descriptors?

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

.

On 2014=E2=80=9311=E2=80=9321, at 1:44 PM, Ville Voutilainen <ville.voutila=
inen@gmail.com> wrote:

> On 21 November 2014 07:10, David Krauss <potswa@gmail.com> wrote:
>=20
>> to glue together existing libraries in C and C++. Shared ownership would=
 be
>> essential to usefulness, never mind what=E2=80=99s surprising.
>=20
> Motivation in this case is to be able to open the underlying platform fac=
ility
> and wrap it under an iostream, not the sharing of the descriptor with
> platform-specific
> code.

Who said the other code is platform-specific? It could be anything, like an=
 XML library written in C.

>  if my fstream
> over a networked
> file system file fails to fill the entire buffer, it will block, not elf-=
close.

The networked filesystem will behave as any other filesystem. It will cause=
 read() to block.

Socket and pipe readers usually follow protocols that require response befo=
re some buffer of unknown size happens to fill. User-side buffering is a mi=
sfeature.

>> Sockets are buffered by the OS socket library, not by any user-level cla=
ss.
>> There=E2=80=99s no way to correctly buffer sockets by yourself or to put=
 one inside
>> a FILE.
>=20
> I must say I have no idea what you're talking about here.

Do you know how pipes and BSD sockets get buffered?

> Do you have actual reasons why we shouldn't provide iostreams over native
> descriptors?

I=E2=80=99ve said all I need to say. I=E2=80=99ve also mentioned various al=
ternatives and existing extensions, which doesn=E2=80=99t really jibe with =
the notion that =E2=80=9Cwe shouldn=E2=80=99t provide iostreams over native=
 descriptors.=E2=80=9D

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

.

On 21 November 2014 08:01, David Krauss <potswa@gmail.com> wrote:
>>> to glue together existing libraries in C and C++. Shared ownership woul=
d be
>>> essential to usefulness, never mind what=E2=80=99s surprising.
>>
>> Motivation in this case is to be able to open the underlying platform fa=
cility
>> and wrap it under an iostream, not the sharing of the descriptor with
>> platform-specific
>> code.
>
> Who said the other code is platform-specific? It could be anything, like =
an XML library written in C.

Well, if you want an additional facility where you can wrap an
iostream over a FILE* or
a native descriptor without the stream closing the underlying handle,
by all means. That
doesn't mean we shouldn't pursue an iostream wrapper over a handle for
the cases where
the stream closes the handle.

>> file system file fails to fill the entire buffer, it will block, not elf=
-close.
>
> The networked filesystem will behave as any other filesystem. It will cau=
se read() to block.

I fail to see how that's different from pipes.

> Socket and pipe readers usually follow protocols that require response be=
fore some buffer of unknown size happens to fill. User-side buffering is a =
misfeature.

I don't know what you're talking about here.

>>> Sockets are buffered by the OS socket library, not by any user-level cl=
ass.
>>> There=E2=80=99s no way to correctly buffer sockets by yourself or to pu=
t one inside
>>> a FILE.
>> I must say I have no idea what you're talking about here.
> Do you know how pipes and BSD sockets get buffered?

I think I do. And I still don't see why there's "no way" to buffer
them in userspace
on top of the system buffering.

>> Do you have actual reasons why we shouldn't provide iostreams over nativ=
e
>> descriptors?
>
> I=E2=80=99ve said all I need to say. I=E2=80=99ve also mentioned various =
alternatives and existing extensions, which doesn=E2=80=99t really jibe wit=
h the notion that =E2=80=9Cwe shouldn=E2=80=99t provide iostreams over nati=
ve descriptors.=E2=80=9D


Well, I have trouble following what you're trying to say. You
certainly seemed to be
against the idea of being able to wrap a closing-iostream on top of a
native handle,
and I have thus far failed to see your explaining sufficiently well
why that would be a
bad idea.

--=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=_0F5901DE-E27B-4D87-AF97-38B7EEC1BD24
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9321, at 2:14 PM, Ville Voutilainen <ville.voutila=
inen@gmail.com> wrote:

>>>> Sockets are buffered by the OS socket library, not by any user-level c=
lass.
>>>> There=E2=80=99s no way to correctly buffer sockets by yourself or to p=
ut one inside
>>>> a FILE.
>>> I must say I have no idea what you're talking about here.
>> Do you know how pipes and BSD sockets get buffered?
>=20
> I think I do. And I still don't see why there's "no way" to buffer
> them in userspace
> on top of the system buffering.

=E2=80=9COn top of system buffering=E2=80=9D is not =E2=80=9Cby yourself,=
=E2=80=9D and the buffering scheme is not the same as FILE and filebuf.

> Well, I have trouble following what you're trying to say.

It=E2=80=99s useful to put streambuf or iostreams atop more things, but tre=
ating all file descriptors alike is an overgeneralization. Treating them al=
l like normal local files doubly so.

So, the proposed facility might be split across more than one class, and/or=
 it might require the user to specify what kind of descriptor something is.=
 At the least, so there=E2=80=99s some kind of contract on whether closing =
it signifies a flush or an abort.

> You
> certainly seemed to be
> against the idea of being able to wrap a closing-iostream on top of a
> native handle,
> and I have thus far failed to see your explaining sufficiently well
> why that would be a
> bad idea.

Because the user might want to continue using the handle after destroying t=
he iostream, as they likely were before before creating it.

--=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=_0F5901DE-E27B-4D87-AF97-38B7EEC1BD24
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014=
=E2=80=9311=E2=80=9321, at 2:14 PM, Ville Voutilainen &lt;<a href=3D"mailto=
:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><div><br></div><div><div><blockquote type=3D"cite"><blockquote type=3D"c=
ite"><blockquote type=3D"cite"><blockquote type=3D"cite">Sockets are buffer=
ed by the OS socket library, not by any user-level class.<br>There=E2=80=99=
s no way to correctly buffer sockets by yourself or to put one inside<br>a =
FILE.<br></blockquote>I must say I have no idea what you're talking about h=
ere.<br></blockquote>Do you know how pipes and BSD sockets get buffered?<br=
></blockquote><br>I think I do. And I still don't see why there's "no way" =
to buffer<br>them in userspace<br>on top of the system buffering.<br></bloc=
kquote><div><br></div><div>=E2=80=9COn top of system buffering=E2=80=9D is =
not =E2=80=9Cby yourself,=E2=80=9D and the buffering scheme is not the same=
 as <font face=3D"Courier">FILE</font> and&nbsp;<font face=3D"Courier">file=
buf</font>.</div></div></div><br class=3D"Apple-interchange-newline"><block=
quote type=3D"cite"><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;">Well, I have trouble following what you're trying to say.</span>=
</blockquote><div><br></div><div>It=E2=80=99s useful to put streambuf or io=
streams atop more things, but treating all file descriptors alike is an ove=
rgeneralization. Treating them all like normal local files doubly so.</div>=
<div><br></div><div>So, the proposed facility might be split across more th=
an one class, and/or it might require the user to specify what kind of desc=
riptor something is. At the least, so there=E2=80=99s some kind of contract=
 on whether closing it signifies a flush or an abort.</div><br><blockquote =
type=3D"cite"><span 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; float: none; display: inline !importa=
nt;">You</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;"><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;">certainly seemed to be</span><br 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;"><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;">aga=
inst the idea of being able to wrap a closing-iostream on top of a</span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;"><span style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !=
important;">native handle,</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;"><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;">and I have thus far failed t=
o see your explaining sufficiently well</span><br 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;"><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-s=
troke-width: 0px; float: none; display: inline !important;">why that would =
be a</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;"><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;">bad idea.</span><br 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;"></blockquot=
e></div><br><div>Because the user might want to continue using the handle a=
fter destroying the iostream, as they likely were before before creating it=
..</div></body></html>

<p></p>

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

--Apple-Mail=_0F5901DE-E27B-4D87-AF97-38B7EEC1BD24--

.

On 21 November 2014 08:34, David Krauss <potswa@gmail.com> wrote:
> Do you know how pipes and BSD sockets get buffered?
>
>
> I think I do. And I still don't see why there's "no way" to buffer
> them in userspace
> on top of the system buffering.
>
>
> =E2=80=9COn top of system buffering=E2=80=9D is not =E2=80=9Cby yourself,=
=E2=80=9D and the buffering scheme
> is not the same as FILE and filebuf.

Well, I don't think anyone has suggested that these streams magically repla=
ce
the system buffering. I don't see anyone explaining why this on-top-of buff=
ering
is in any way incorrect, but I see claims stating that it is.

> Well, I have trouble following what you're trying to say.
>
>
> It=E2=80=99s useful to put streambuf or iostreams atop more things, but t=
reating all
> file descriptors alike is an overgeneralization. Treating them all like
> normal local files doubly so.

Nobody has suggested treating them like local files. With regards to
allowing the suggested wrapping of any file descriptor, I'm yet to see
an explanation why it shouldn't be done. All I see is vague statements
that don't seem to provide anything beyond unsubstantiated concerns.

> So, the proposed facility might be split across more than one class, and/=
or
> it might require the user to specify what kind of descriptor something is=
..
> At the least, so there=E2=80=99s some kind of contract on whether closing=
 it
> signifies a flush or an abort.

Sure, it's possible that the idea will evolve to cover multiple scenarios
and will lead to more than one class. Nobody has thus far suggested that
it will just magically happen inside the existing filebuf.

> You
> certainly seemed to be
> against the idea of being able to wrap a closing-iostream on top of a
> native handle,
> and I have thus far failed to see your explaining sufficiently well
> why that would be a
> bad idea.
>
>
> Because the user might want to continue using the handle after destroying
> the iostream, as they likely were before before creating it.

The closing-iostream (or a streambuf, rather) doesn't preclude having
a non-closing one,
so that's not a reason not to add a closing-iostream on top of a native han=
dle.

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

.

On Fri, Nov 21, 2014 at 1:14 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>>
>> The networked filesystem will behave as any other filesystem. It will cause read() to block.
>
> I fail to see how that's different from pipes.

Traditional pipes are half-duplex, while sockets are
full-duplex.

>
> Well, I have trouble following what you're trying to say. You
> certainly seemed to be
> against the idea of being able to wrap a closing-iostream on top of a
> native handle,
> and I have thus far failed to see your explaining sufficiently well
> why that would be a
> bad idea.
>

The idea works for some use cases, but a stream-like
interface is too constrained for exposing the usefulness
of these non-regular file resources, afaics.  I hope I can
see subprocess libraries, network libraries standardized
some day, but not quite interested in this.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

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

.

On 21 November 2014 09:14, Zhihao Yuan <zy@miator.net> wrote:
>>> The networked filesystem will behave as any other filesystem. It will cause read() to block.
>>
>> I fail to see how that's different from pipes.
>
> Traditional pipes are half-duplex, while sockets are
> full-duplex.

Gee, it's almost as if you're suggesting that the ends of the pipe are
ifstreams and
ofstreams and the socket ends are fstreams. That's no different from
opening a file
descriptor in read-only mode and trying to write to it. That's not
weird at all, the
errors are not exceptional, and users know how to deal with it.

>> Well, I have trouble following what you're trying to say. You
>> certainly seemed to be
>> against the idea of being able to wrap a closing-iostream on top of a
>> native handle,
>> and I have thus far failed to see your explaining sufficiently well
>> why that would be a
>> bad idea.
> The idea works for some use cases, but a stream-like
> interface is too constrained for exposing the usefulness
> of these non-regular file resources, afaics.  I hope I can
> see subprocess libraries, network libraries standardized
> some day, but not quite interested in this.


The idea seems to cover a vast swath of cases for which users have needed
to use platform-specific facilities for all of it, including the i/o
itself. Beyond
ioctls, there doesn't seem to be too many of these "useful facilities" that need
to be done after opening the descriptor.

Olaf, I encourage you to proceed with the proposal - regardless of what the
non-representative comments on this forum say, users have been requesting
the proposed facility for over a decade, and C++ has failed to deliver.

--

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

.

On 11/21/2014 2:06 AM, Ville Voutilainen wrote:
> Olaf, I encourage you to proceed with the proposal - regardless of what the
> non-representative comments on this forum say, users have been requesting
> the proposed facility for over a decade, and C++ has failed to deliver.

I plan to write up a proposal for an I/O streams type to work with
native file handles (mainly file descriptors, but also Windows HANDLEs),
but I certainly wouldn't say no to some help.

I'm not sure I find the FILE* case especially useful, but I suppose I
could be convinced otherwise if I saw some use cases.

- Jim


--

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

.

On 2014-11-21 01:14, Ville Voutilainen wrote:
> On 21 November 2014 08:01, David Krauss <potswa@gmail.com> wrote:
>> Do you know how pipes and BSD sockets get buffered?
>=20
> I think I do. And I still don't see why there's "no way" to buffer
> them in userspace on top of the system buffering.

I think the point here is that the userland buffer had better not block
trying to read more bytes than the user has explicitly requested, since
that is clearly undesired behavior. (It can even lead to deadlocks in
the case of a pipe that is waiting for some response before sending more
data.)

Lets say you have processes A and B connected by a pipe. A sends 52
bytes. B tries to read 48, then sends a reply to A that causes A to send
a bunch more. If B is buffering the pipe, that buffer had better not
decide that it reads 4096 byte chunks from the FD at a time and will not
return from any read request until either that 4096 byte buffer is full
or an EOF occurs. That may be okay for files on disk, but for pipes /
sockets, you just caused B to deadlock.

In other words, the buffer must both accept (without blocking) that it
may not be able to read as many bytes as it would like, AND must not
treat that condition as EOF (because it isn't). It's entirely plausible
that a na=C3=AFve implementation that was designed for handling local files
fails at one or both of those points.

--=20
Matthew

--=20

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

.