"Eugene Lazutkin" <[EMAIL PROTECTED]> wrote:
>Inline.
>
>"John Madsen" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>>
>> If you can convince most of the people on this list to provide an
>automatic
>> conversion, mor
Anthony Liguori <[EMAIL PROTECTED]> wrote:
>Being primarily a Unix developer, I think this library could have a
>great use in Unix as long as it can do a few things. Namely, it needs
>to be flexible enough to deal with C style inherent (i.e. it should
>allow for custom features for socket type
"Gennadiy Rozental" <[EMAIL PROTECTED]> wrote:
>> I read all of the previous discussion of this on the boost list and did
>not
>> find any good arguments against mine.
>
>> 1) Pointer specific features have been removed for smart_handle. Both
>> implicit and explicit type coercion features are go
"Eugene Lazutkin" <[EMAIL PROTECTED]> wrote:
>Inline.
>
>> already suggested that it would be worthwhile for FILE*s and file
>descriptors.
>
>I am not in position to judge their reasons --- I never had this need. Maybe
>I avoided their specific problems somehow. Or these problems are not
>frequent
"Gennadiy Rozental" <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I do not want to start this discussion all over again, but in the reasoning
>you presenting I did not find anything new to justify another "smart
>pointer" like component. It's only one simple case of PBSP and I do not see
>any reason not to us
"Eugene Lazutkin" <[EMAIL PROTECTED]> wrote:
>Inline,
>
>"John Madsen" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> I have little experience with X-Windows, so I can't comment on that.
>However,
>> there is a
;> { if (is_valid(h)) ::CloseHandle(h); }
>> static handle_type default_value()
>> { return INVALID_HANDLE_TYPE; }
>> static bool equal(handle_type lhs, handle_type rhs)
>> { return lhs==rhs; }
>> };
>>
>> (This example is taken from or
Gregory Colvin <[EMAIL PROTECTED]> wrote:
>
>On Friday, Jul 18, 2003, at 15:21 America/Denver, John Madsen wrote:
>
>> "Eugene Lazutkin" <[EMAIL PROTECTED]> wrote:
>>> I have a few comments in no particular order.
>>>
>>> 1) I
Larry Evans <[EMAIL PROTECTED]> wrote:
>
>wouldn't deadlock detection be another application? Taking the
>definition directly from my "long-ago" OS course memory, a deadlock
>occurs when one task or process holds a "handle" to a lock on a
>resource required by another task, which in turn, holds an
"Eugene Lazutkin" <[EMAIL PROTECTED]> wrote:
>I have a few comments in no particular order.
>
>1) I cannot imaging someone programming in C++ and using "FILE*s,and file
>descriptors" instead of iostream & Co. You've must be talking about
>incomplete systems like embedded systems, which don't have c
xercise all of the code.
I'd certainly love to hear ideas, criticism, etc. and ultimately see this
become part of boost.
Thanks,
John Madsen
john at illura dot com.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
11 matches
Mail list logo
