Topic: Some safety for C: add array_view overloads
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 Oct 2014 19:28:19 +0300
Raw View
On 2 October 2014 19:20, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> - Generic backend (fixed buffer, dynamic buffer, file, IPC, network
>> socket, etc..) implemented efficiently! (that is no returning copies of
>> std::string etc..)
> Have you looked at QIODevice? I believe it supports all of these (IPC is
> the only one I'm not sure if there is a concrete implementation; the
> others I know it supports). Really, what you want is a stream built on
> top of a buffer that implements virtual read() and write() and isn't
> *required* to support anything beyond those.
I expect a fair number of people to shout bloody murder if someone proposes
an i/o library that requires virtual functions to operate.
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 Oct 2014 20:53:46 +0300
Raw View
On 2 October 2014 19:57, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> I expect a fair number of people to shout bloody murder if someone proposes
>> an i/o library that requires virtual functions to operate.
> Well, that's too bloody bad; I guess they despise iostream for the same
> reason? (Surprise, surprise, iostream *already uses virtuals*, in
As far as I understand, yes, they do.
> There really is no way to provide an implementation that lets you pass a
> generic stream to an algorithm regardless of the underlying device (and
> I certainly hope we can all agree that this is a required feature!)
> except virtual functions...
>
> ...or templates. We could template the streams on the underlying device,
> giving us a combinatorial explosion of stream types, and then also
> template *every single algorithm that uses a stream* to take any
> stream-device combination.
>
> Yeah. Never going to happen. That's *so* atrocious I am literally at a
> loss for words.
>
> Anyone that thinks generic I/O is going to happen without virtual
> functions needs a strong dose of reality.
How many virtual functions does boost::asio use?
--
---
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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 2 Oct 2014 13:24:33 -0500
Raw View
--001a11c1b65ac93213050474bc2a
Content-Type: text/plain; charset=UTF-8
On 2 October 2014 13:17, Matthew Woehlke <mw_triad@users.sourceforge.net>
wrote:
> That said... it looks like it isn't possible to pass an asio buffer to a
> non-templated algorithm. That, as far as I am concerned, makes it nigh
> unusable as a basic I/O library. Also, "not generic".
>
My colleague, who is quite familiar with Asio and it's internals, says
"this is completely false".
Buffers have a concrete type, const_buffer and mutable_buffer, buffer
*Sequences* are taken by template parameters.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--001a11c1b65ac93213050474bc2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 2 October 2014 13:17, Matthew Woehlke <span dir=3D"ltr"><<a href=3D"m=
ailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users.sour=
ceforge.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=
=3D":7uw" class=3D"a3s" style=3D"overflow:hidden">That said... it looks lik=
e it isn't possible to pass an asio buffer to a<br>
non-templated algorithm. That, as far as I am concerned, makes it nigh<br>
unusable as a basic I/O library. Also, "not generic".</div></bloc=
kquote></div><div><br></div><div>My colleague, who is quite familiar with A=
sio and it's internals, says "this is completely false".</div=
><div><br></div><div>Buffers have a concrete type, const_buffer and mutable=
_buffer, buffer <i>Sequences</i> are taken by template parameters.=C2=A0</d=
iv><br clear=3D"all"><div><br></div>-- <br>=C2=A0Nevin ":-)" Libe=
r=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bla=
nk">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404
</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 />
--001a11c1b65ac93213050474bc2a--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Thu, 2 Oct 2014 11:26:57 -0700 (PDT)
Raw View
------=_Part_709_742206894.1412274417510
Content-Type: text/plain; charset=UTF-8
On Thursday, October 2, 2014 2:25:15 PM UTC-4, Nevin ":-)" Liber wrote:
>
>
> On 2 October 2014 13:17, Matthew Woehlke <mw_t...@users.sourceforge.net
> <javascript:>> wrote:
>
>> That said... it looks like it isn't possible to pass an asio buffer to a
>> non-templated algorithm. That, as far as I am concerned, makes it nigh
>> unusable as a basic I/O library. Also, "not generic".
>>
>
> My colleague, who is quite familiar with Asio and it's internals, says
> "this is completely false".
>
> Buffers have a concrete type, const_buffer and mutable_buffer, buffer
> *Sequences* are taken by template parameters.
>
>
Whether or not boost::asio or any other library uses virtual is irrelevant.
Nobody has answered why virtual is always bad and should never be used.
--
---
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_709_742206894.1412274417510
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 2:25:15 PM UTC-4, Nev=
in ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br><div class=3D"gmail_quote">On 2 October 2014 13:17, Matth=
ew Woehlke <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"hsoj5BLB7qIJ" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">mw_t.=
...@users.sourceforge.<wbr>net</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div style=3D"overflow:hidden">That said... it looks like it isn=
't possible to pass an asio buffer to a<br>
non-templated algorithm. That, as far as I am concerned, makes it nigh<br>
unusable as a basic I/O library. Also, "not generic".</div></blockquote></d=
iv><div><br></div><div>My colleague, who is quite familiar with Asio and it=
's internals, says "this is completely false".</div><div><br></div><div>Buf=
fers have a concrete type, const_buffer and mutable_buffer, buffer <i>Seque=
nces</i> are taken by template parameters. </div><br></div></div></blo=
ckquote><div><br>Whether or not boost::asio or any other library uses virtu=
al is irrelevant. Nobody has answered why virtual is always bad and should =
never be used. <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" 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_709_742206894.1412274417510--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 Oct 2014 21:45:08 +0300
Raw View
On 2 October 2014 21:26, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> Whether or not boost::asio or any other library uses virtual is irrelevant.
> Nobody has answered why virtual is always bad and should never be used.
I don't think anyone has made such a claim. The concern about virtual functions
is overhead, though.
--
---
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/.
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Thu, 02 Oct 2014 22:34:20 +0200
Raw View
FWIW basic_streambuf has both the single character and range overloads:
basic_streambuf::sputc(ch) (calls virtual overflow)
basic_streambuf::sputn(s, n) (calls virtual xsputn)
Last time I checked libc++ implements xsputc() in basic_stringbuf by
looping over sputc but that's a QoI issue, so technically
basic_streambuf has all the necessities to implement a type erased sink
device. It's just that the interface may be a bit ... cryptic. I believe
the biggest issue people have with streams is the overhead of
basic_ostream, not basic_streambuf.
Am 02.10.2014 um 20:32 schrieb Matthew Woehlke:
> On 2014-10-02 14:24, Nevin Liber wrote:
>> On 2 October 2014 13:17, Matthew Woehlke wrote:
>>> That said... it looks like it isn't possible to pass an asio buffer to a
>>> non-templated algorithm. That, as far as I am concerned, makes it nigh
>>> unusable as a basic I/O library. Also, "not generic".
>> My colleague, who is quite familiar with Asio and it's internals, says
>> "this is completely false".
>>
>> Buffers have a concrete type, const_buffer and mutable_buffer, buffer
>> *Sequences* are taken by template parameters.
> I may be using terminology poorly. See my comments about One True Buffer
> Type. It may work due to strong decoupling of the buffer and device
> where the device drives the buffer(?). (In order to have the buffer
> drive the device you'd need method pointers, which goes back to my "you
> say bound method, I say virtual method" point.)
>
> That only works for asynchronous I/O. There are all kinds of reasons why
> that shouldn't become the *only* option for doing I/O... which puts us
> back in the "we need (something that looks like) virtual methods" category.
>
--
---
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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 2 Oct 2014 16:27:01 -0500
Raw View
--001a11c25bda54d1d005047749e9
Content-Type: text/plain; charset=UTF-8
On 2 October 2014 13:32, Matthew Woehlke <mw_triad@users.sourceforge.net>
wrote:
> On 2014-10-02 14:24, Nevin Liber wrote:
> > On 2 October 2014 13:17, Matthew Woehlke wrote:
> >> That said... it looks like it isn't possible to pass an asio buffer to a
> >> non-templated algorithm. That, as far as I am concerned, makes it nigh
> >> unusable as a basic I/O library. Also, "not generic".
> >
> > My colleague, who is quite familiar with Asio and it's internals, says
> > "this is completely false".
> >
> > Buffers have a concrete type, const_buffer and mutable_buffer, buffer
> > *Sequences* are taken by template parameters.
>
> I may be using terminology poorly. See my comments about One True Buffer
> Type.
There is no One True Buffer Type in Boost.Asio.
A const_buffer is:
const_buffer
{
// ...
const void* data_;
std::size_t size_;
};
In other words, it is the moral equivalent of array_view, except that
array_view is not yet a vocabulary type in the standard, so this one got
invented for Asio.
Asio actually handles discontiguous memory by the use of sequences of
const_buffers and mutable_buffers.
Your entire argument against Asio is basically a straw man, as evidenced by
your statement "I'm not familiar with boost::asio". If you aren't familiar
with it, how can you argue for or against it's abstractions?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--001a11c25bda54d1d005047749e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 2 October 2014 13:32, Matthew Woehlke <span dir=3D"ltr"=
><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw=
_triad@users.sourceforge.net</a>></span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">On 2014-10-02 14:24, Nevi=
n Liber wrote:<br>
<span class=3D"">> On 2 October 2014 13:17, Matthew Woehlke wrote:<br>
>> That said... it looks like it isn't possible to pass an asio b=
uffer to a<br>
>> non-templated algorithm. That, as far as I am concerned, makes it =
nigh<br>
>> unusable as a basic I/O library. Also, "not generic".<br=
>
><br>
> My colleague, who is quite familiar with Asio and it's internals, =
says<br>
> "this is completely false".<br>
><br>
> Buffers have a concrete type, const_buffer and mutable_buffer, buffer<=
br>
</span>> *Sequences* are taken by template parameters.<br>
<br>
I may be using terminology poorly. See my comments about One True Buffer<br=
>
Type.</blockquote><div><br></div><div>There is no One True Buffer Type in B=
oost.Asio.</div><div><br></div><div>A const_buffer is:</div><div><br></div>=
<div><p style=3D"margin:0px;font-size:10px;font-family:'Source Code Pro=
';background-color:rgb(254,244,156)">const_buffer</p>
<p style=3D"margin:0px;font-size:10px;font-family:'Source Code Pro'=
;background-color:rgb(254,244,156)">{</p>
<p style=3D"margin:0px;font-size:10px;font-family:'Source Code Pro'=
;color:rgb(197,114,27);background-color:rgb(254,244,156)"><span style=3D"co=
lor:rgb(0,0,0)">=C2=A0=C2=A0</span><span style=3D"color:rgb(77,44,220)">// =
....</span><br></p>
<p style=3D"margin:0px;font-size:10px;font-family:'Source Code Pro'=
;background-color:rgb(254,244,156)"><br></p>
<p style=3D"margin:0px;font-size:10px;font-family:'Source Code Pro'=
;background-color:rgb(254,244,156)">=C2=A0 <span style=3D"color:rgb(39,180,=
28)">const</span> <span style=3D"color:rgb(39,180,28)">void</span>* data_;<=
/p>
<p style=3D"margin:0px;font-size:10px;font-family:'Source Code Pro'=
;background-color:rgb(254,244,156)">=C2=A0 std::<span style=3D"color:rgb(39=
,180,28)">size_t</span> size_;</p>
<p style=3D"margin:0px;font-size:10px;font-family:'Source Code Pro'=
;background-color:rgb(254,244,156);min-height:13px">};<br></p></div><div><b=
r></div><div>In other words, it is the moral equivalent of array_view, exce=
pt that array_view is not yet a vocabulary type in the standard, so this on=
e got invented for Asio.</div><div><br></div><div>Asio actually handles dis=
contiguous memory by the use of sequences of const_buffers and mutable_buff=
ers.</div><div><br></div><div>Your entire argument against Asio is basicall=
y a straw man, as evidenced by your statement "<span style=3D"font-fam=
ily:arial,sans-serif;font-size:13px">I'm not familiar with boost::asio&=
quot;.=C2=A0 If you aren't familiar with it, how can you argue for or a=
gainst it's abstractions?</span></div><div>--=C2=A0<br></div></div>=C2=
=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847)=
691-1404
</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 />
--001a11c25bda54d1d005047749e9--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 2 Oct 2014 23:36:25 +0200
Raw View
Can't the best of both worlds be provided? Dedicated stream types not
requiring virtuals but requiring and a type-erased stream with
virtuals?
--
---
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/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Thu, 2 Oct 2014 14:45:29 -0700 (PDT)
Raw View
------=_Part_5416_1183008341.1412286329296
Content-Type: text/plain; charset=UTF-8
On Thursday, October 2, 2014 5:36:26 PM UTC-4, Olaf van der Spek wrote:
>
> Can't the best of both worlds be provided? Dedicated stream types not
> requiring virtuals but requiring and a type-erased stream with
> virtuals?
>
Yes, with the final keyword we can provide this and ensure its efficent
when you have a pointer / reference to the actual stream / device type.
--
---
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_5416_1183008341.1412286329296
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 5:36:26 PM UTC-4, Ola=
f van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Can't the=
best of both worlds be provided? Dedicated stream types not
<br>requiring virtuals but requiring and a type-erased stream with
<br>virtuals?
<br></blockquote><div><br>Yes, with the final keyword we can provide this a=
nd ensure its efficent when you have a pointer / reference to the actual st=
ream / device type. <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" 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_5416_1183008341.1412286329296--
.