Re: [boost] [asio] Tutorial 7 using strdup, new

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-02-06 16:51:34

Christopher Kohlhoff wrote:
> Hi Peter,
>
> --- Peter Dimov <pdimov_at_[hidden]> wrote:
>
>> Why is
>>
>>
> http://asio.sourceforge.net/boost-asio-proposal-0.3.6/libs/asio/doc/tutorial/tutdaytime7.html
>>
>> using raw pointers, strdup, new, free and delete? This is soo
>> 1996. Tutorials shoud teach.
>
> Yep, this already came up in a review and I'm planning to change
> it. IIRC, the motivation for doing it this way was:
>
> - to avoid introducing too many boost facilities at once
>
> - to illustrate the "exactly-once" callback invocation
>
> Since I want to keep the tutorial as simple as possible, I'm a
> bit undecided about what to put instead though. I want to ensure
> that whatever I use instead doesn't distract from the things
> that I am trying to teach.

But the C-style facilities used in the tutorial actually do serve as a 
distraction to me, not just a mere annoyance. I am now forced to think of 
the following:

- what happens if something along the way throws?

- does the author of the tutorial really endorse this programming style, and 
do I want to use a library designed with this use style in mind?

- if the tutorial doesn't show the recommended way to use asio, what _is_ 
the recommended way to use it?

> For example, one option I'm considering is to simply replace
> them with shared_ptr<socket>, shared_ptr<std::string> etc, but
> keep using free functions as callbacks. The "distraction" I see
> with std::string is that I probably need to explain how calling
> asio::buffer() on it uses the data() member function, and the
> conditions under which the pointer returned by data() is
> invalidated.

shared_ptr<socket> is the easy part, although this immediately leads me to 
ask the obvious question: why isn't a socket already a 
shared_ptr<socket_impl>?

For the string, my first thought was to just pass a std::string by value. 
This of course doesn't work because the string needs to stay alive until the 
operation is complete, so we need something like a shared_array<char>. I 
think that the library should provide one.

In summary, I think that eliminating the C-style facilities from the 
tutorial will improve both the tutorial and the library.