Boost logo

Boost :

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-08-19 12:37:53


Niall Douglas wrote
> On 18 Aug 2014 at 9:54, Robert Ramey wrote:
>
>> OK - I'll try to figure out how to insert quoting.
>
> I'll let you get the quoting reply thing working before I reply on
> that site. You made some excellent very valid points I will fix
> immediately, but many of them were answered in the docs already.

The only thing that the quoting is going to do is copy the previous
post between <blockquote> tags. So I don't think this is a huge
obstacle to replying. On the other hand, you've already replied
here so there's no need at this point.

> Where we diverge the most strongly is in what we think "easier" to
> mean. But I won't bother rehashing all that again.

OK

> You are already very mistaken in the premise for a library such as
> AFIO.
> <snip...>

All I did was follow a plain reading of the documentation. The typical
C++ programmer should be able to get a more or less idea of what it
is and how it works from such a reading. If he can't do this, then the
library won't be widely used - if at all. If you want to avoid this, you'll
have to do something differently.

>> so I would say you're not thinking big enough. if AFIO is not simple
>> enough to be used within an hour of looking over the docs, it's
>> too complicated.
>>
>> Think bigger!!!!
>>
>> What would be an ideal interface ? is there a way to implement it?
>> For example:
>>
>> main(..){
>>
>> // example one
>> asyncio::istream ais("filename"); // works almost like a stream
>> int x;
>> ais >> x; // read an x
>> ....
>> ais.sync()
>
> Such a design would not make good use of hardware DMA such that ...

My view is that
a) the above interface would be easy to understand.
b) the above interface doesn't preclude any particular implementation
and/or optimization at a lower level. The above is really a facade
over some implementation.

Of course, since I haven't actually implemented this - I could well
be wrong that it would be doable. If it were doable, it would be
a very popular boost library.

> That rules out all serialisation usually :)

The serialization library depends on some stream or stream buffer
implementation to do the i/o. It's possible to craft a standard
stream buffer such that there would be no extraneous copies
as part of the serialization. Basically the process of turning
a data structure into a sequence of bytes is orthogonal to the
process of actually doing any i/o. I hadn't thought about it, but
a asyncio interface similar to the above would be a great
complement to the serialization library and would even more
popular for this reason.

Anyway, I just read (some of) the documentation and logged
my experience with it. I hope it can useful in some way.

Good luck with this.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Concepts-Definition-Was-GSoC-Boost-Hana-Formal-review-request-tp4666011p4666591.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk