Prev: why are missing return statements from non-void functions not a compilation error
Next: value_type of an output iterator
From: Mathias Gaunard on 4 Aug 2010 04:18
On Jul 30, 3:04 pm, w...(a)seed.net.tw wrote:
> The most important, all
> functions
> are fully documented (this is essentially different from average C++
> libraries).

I find the documentation much worse than the average library.
All libraries have reference documentation... I don't find man
particularly usable.



> Features:
> .The error reporting mechanism, I believed, is one of the 'correct'
> one.

What error reporting mechanism are you talking about?


> .The class function member rule is tested (7 years) to be good
> practice.

What class function member rule?

> .WyThread wraps pthread functions, the only thread class I saw that
> supports
> thread cancellation and signal managements.

Boost thread supports thread cancellation, unless they removed it to
be like C++0x standard threads.
The only way to do thread cancellation right, in C++, is to *not use*
pthread cancellation though.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Vaclav Haisman on 4 Aug 2010 11:07
Andrew wrote, On 2.8.2010 20:44:
> On 30 July, 14:04, w...(a)seed.net.tw wrote:
>> CSCall++http://sourceforge.net/projects/cscall/does not rely on C++
>> standard library but entirely wrap POSIX c functions.
>
>[...]
> Hence, I don't quite understand why this library exists. Can you
> explain the motivation please?
>
>[...]
>
> It might be different from the average C++ library but POSIX routines
> are actually quite well documented. There are the man pages and the
> POSIX standard itself.
(I have not looked at the library.)

Unfortunately POSIX does not define semantics for C++. AFAIK, there is
ongoing effort to define the semantics of POSIX in C++ and to standardize
some C++ wrappers and/or interfaces that are not pure C as the existing one.
Libraries like this might be valuable as inspiration, good/bad examples,
basis for new POSIX-in-C++ standard.

--
VH

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Nick Maclaren on 4 Aug 2010 11:11
In article <d5950e37-4376-4b70-b22f-e66465675a7a(a)f42g2000yqn.googlegroups.com>,
Mathias Gaunard <loufoque(a)gmail.com> wrote:
>On Jul 30, 3:04 pm, w...(a)seed.net.tw wrote:
>
>> .WyThread wraps pthread functions, the only thread class I saw that
>> supports thread cancellation and signal managements.
>
>Boost thread supports thread cancellation, unless they removed it to
>be like C++0x standard threads.
>The only way to do thread cancellation right, in C++, is to *not use*
>pthread cancellation though.

Er, no. While using pthread cancellation is definitely wrong, there
is NO way to do it correctly in a language like C++ - that is the
fundamental problem.


Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: wij on 4 Aug 2010 18:14
On 8月5日, 上午3時18分, Mathias Gaunard <loufo...(a)gmail.com> wrote:
> On Jul 30, 3:04 pm, w...(a)seed.net.tw wrote:
>
>> The most important, all
>> functions
>> are fully documented (this is essentially different from average C++
>> libraries).
>
> I find the documentation much worse than the average library.
> All libraries have reference documentation... I don't find man
> particularly usable.
>
At this stage of development, only manpage is available.
There are .info .html.pdf ...., this could be just matters of taste,
if you're not talking about the contents.

>> Features:
>> .The error reporting mechanism, I believed, is one of the 'correct'
>> one.
>
> What error reporting mechanism are you talking about?
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/d92ec2a33f1751fb#
There is also a part in Rationale.txt of the library talked about
error handling.

>
>> .The class function member rule is tested (7 years) to be good
>> practice.
>
> What class function member rule?
>
Ripped from file README.TXT in CSCall++
....
-- Function request reply: (return and throw)

Functions report exit status either by returning WyRet or by
throwing
class of Reply family.

WyRet -- as return type

Use WY_RETURN(em) to return reply with SLI. or return(Ok)
to
indicate success.

WyRet -- as base class of the throw type
Function not appropriate to return WyRet should throw Reply
(inherited from WyRet, adding no data member). For example
constructor/destructor and operator overloads... Class
Reply is
defined not to cross the function call, which need
programming
supports.
('Exception' is a system-wise consideration. see C++
PROGRAMMING
LANGUAGE, BJARNE STROUSTRUP, 3rd, p383)

Any function detects inconsistent data should not return
nor
throw without considering how other functions will react
to the condition (recover procedure could be entered),
otherwise
go to std::terminate(). (Information can not be proved
'broken', and
the propagation can not be free from 'noise')

The exact class WyRet to throw is reserved to mean 'stack
unwinding
to exit'. Throwing mechanism of C++ language is regarded
merely part
of the function control flow, intent is much less relevant
in this
respect. (See [THE ANNOTATED C++ REFERENCE MANUAL,
ELLIS,STROUSTRUP,
15.1, p353-p355] [The Design and Evolution of C++, BJARNE
STROUSTRUP
, 16.6, p390] [C++ Standard 15.3.9])


Use WY_THROW(...) to throw class with SLI
WY_RETURN(...) to return WyRet with SLI
WY_HERE(...) to set SLI at the location this macro appeared

................
-- Class member rules

Let T denote a given class of this library. The following member
names
and associated functionalities are defined.

T() Default constructor. The object thus construted is
referred
to as in default state and so the default object.

Postcondition of throw: object does not exist.

Note: If object can mean 'no real contents', or be
unbound state
etc., the default object is better thus designed,
at least
to be safely destructable.

reset(...)
Reconstruct the object to the state as constructed.
If reset(..) defined, there exists the argument
corresponding
constructor (reset() usually exists)

For reset() (no argument), object return state (and
Reply) is
always default.

~T Destruct and discard object

Postcondition: object does not exist

.......................
swap(..)
Exchange object state of *this and the argument indicated
object.

Take 'a.swap(b)' (commutative) for instance, the state of
a is set
to the state of b. The previous state of a becomes the
state of b.
The same applies for b

Note: No construct and destruct semantics involved

Reply
Class specific throw class inherited from WyRet.
...........
-- No room should be left for lower-level implement (design).
(This rule is borrowed from "The Design and Evolution of C++"
[BJARNE STROUSTRUP, 4.5, p120])

-----------------------------------------------------------------------
The reset rule could be applied to vast amount of classes, reducing
analytic effort and complexity between class members.

>> .WyThread wraps pthread functions, the only thread class I saw that
>> supports
>> thread cancellation and signal managements.
>
> Boost thread supports thread cancellation, unless they removed it to
> be like C++0x standard threads.
Yes. I noticed thread::interrupt() which does the same thing.

> The only way to do thread cancellation right, in C++, is to *not use*
> pthread cancellation though.
>
Rationale?



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: wij on 4 Aug 2010 19:18
On 8月5日, 上午10時07分, Vaclav Haisman <v.hais...(a)sh.cvut.cz> wrote:
> Andrew wrote, On 2.8.2010 20:44:> On 30 July, 14:04, w...(a)seed.net.tw wrote:
>>> CSCall++http://sourceforge.net/projects/cscall/doesnot rely on C++
>>> standard library but entirely wrap POSIX c functions.
>
>> [...]
>> Hence, I don't quite understand why this library exists. Can you
>> explain the motivation please?
>
>> [...]
>
>> It might be different from the average C++ library but POSIX routines
>> are actually quite well documented. There are the man pages and the
>> POSIX standard itself.
>
> (I have not looked at the library.)
>
> Unfortunately POSIX does not define semantics for C++. AFAIK, there is
> ongoing effort to define the semantics of POSIX in C++ and to standardize
> some C++ wrappers and/or interfaces that are not pure C as the existing one.
> Libraries like this might be valuable as inspiration, good/bad examples,
> basis for new POSIX-in-C++ standard.
>
> --
> VH
>
Good news, but I am worried if it would throw errors blindly.

C++ program can use C routine as well as written in other languages.
That POSIX does not address anything about C++ should not invalidate
such wrapper libraries.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: why are missing return statements from non-void functions not a compilation error
Next: value_type of an output iterator