CSCall++ 0.37 is released
in [C++]
|
Prev: why are missing return statements from non-void functions not a compilation error
Next: value_type of an output iterator
From: wij on 29 Jul 2010 23:04 CSCall++ http://sourceforge.net/projects/cscall/ does not rely on C++ standard library but entirely wrap POSIX c functions. The most important, all functions are fully documented (this is essentially different from average C++ libraries). Questions and criticism are welcome. Features: .The error reporting mechanism, I believed, is one of the 'correct' one. .The class function member rule is tested (7 years) to be good practice. .Most low level function features are preserved. Wy::cin,Wy::cout,Wy::cerr directly talk to the standard file descriptor not only faster and simpler, but can be used in signal handler the same manner as POSIX signal-safe functions can. Beside, they can be reset to associate to not only regular file but also socket,fifo,character device. .WyThread wraps pthread functions, the only thread class I saw that supports thread cancellation and signal managements. .Comes with many reusable example programs that can initiate or be modified into real applications. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrew on 2 Aug 2010 03: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. I agree that wrapping POSIX functions is a good idea but maybe not for the same reason as CSCall. I wrap such functions in order to be portable. On POSIX-like platforms the code calls the underlying POSIX call, on Microsoft-Windows it calls the nearest equivalent, maybe even using the WIN32 API if there is no other way. I couldn't see any MS- Windows provision in the code, and no way to do a MS-Windows build. Hence, I don't quite understand why this library exists. Can you explain the motivation please? > The most important, all functions are fully documented (this is > essentially different from average C++ libraries). 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. Regards, Andrew Marlow -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nick Maclaren on 2 Aug 2010 22:18 In article <b403feec-24cb-4e25-971f-0042d30fe46c(a)v32g2000prd.googlegroups.com>, Andrew <marlow.andrew(a)googlemail.com> wrote: > 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. > > I agree that wrapping POSIX functions is a good idea but maybe not for > the same reason as CSCall. I wrap such functions in order to be > portable. On POSIX-like platforms the code calls the underlying POSIX > call, on Microsoft-Windows it calls the nearest equivalent, maybe even > using the WIN32 API if there is no other way. I couldn't see any MS- > Windows provision in the code, and no way to do a MS-Windows build. > Hence, I don't quite understand why this library exists. Can you > explain the motivation please? One motivation for wrapping 'standard' calls is to provide a hook for tracing calls or fixing up unsatisfactory implementations. Another is to put in the checks that the standard should require but doesn't, or to check extra constraints that you are imposing. Another is to allow for portability to other systems in the future. And so on - it's a very general and useful technique. >> The most important, all functions are fully documented (this is >> essentially different from average C++ libraries). > > 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. Er, no. They are not at all well documented if your target is high-RAS or highly portable code. The POSIX standard and almost all man pages are very short on the precise constraints, precise guarantees and (most of all) interactions with other features. The ghastly autoconfigure spaghetti used for most large, portable applications isn't solely relevant to the non-POSIX environments, or because the authors didn't know how to read the POSIX standard. Now, whether this library does better, I can't say (not having looked at it), but there are good reasons for providing a library that does. It is one of the oldest and best ways of increasing RAS and portability. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Miles Bader on 3 Aug 2010 13:34 nmm(a)gosset.csi.cam.ac.uk (Nick Maclaren) writes: > The POSIX standard and almost all man pages are very short on the > precise constraints, precise guarantees and (most of all) interactions > with other features. The ghastly autoconfigure spaghetti used for > most large, portable applications isn't solely relevant to the > non-POSIX environments, or because the authors didn't know how to read > the POSIX standard. Well to be fair, there's another reason for autoconfiguration: crappy implementations that don't actually do what the standard says. -miles -- On a bad day, I see brewers still talking as though all beer were consumed in the pub, by the pint -- by insatiably thirsty Yorkshire steelworkers who have in reality long ago sought work as striptease artists. [Michael Jackson] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: wij on 3 Aug 2010 18:18
On 8月3日, 上午2時44分, Andrew <marlow.and...(a)googlemail.com> wrote: > 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. > > I agree that wrapping POSIX functions is a good idea but maybe not for > the same reason as CSCall. I wrap such functions in order to be > portable. On POSIX-like platforms the code calls the underlying POSIX > call, on Microsoft-Windows it calls the nearest equivalent, maybe even > using the WIN32 API if there is no other way. I couldn't see any MS- > Windows provision in the code, and no way to do a MS-Windows build. > Hence, I don't quite understand why this library exists. Can you > explain the motivation please? > Frustration of using standard library in about 2003. At the beginning, I just know I was wrapping syscalls and some libc functions. Latter I found they are probably POSIX functions. Why not Microsoft-Windows? It is simply I know Linux only. And, at the moment, as it had been, the main issue is still the C++ API. Probably I should find help on this area. > > The most important, all functions are fully documented (this is > > essentially different from average C++ libraries). > > 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. > When using C++, the error reporting and thread cancellation problems appear everywhere. It is not that simple as it appear using lots of POSIX C functions directly in C++ program. Then, comes the idea of wrapper functions. Comparing to average C++ libraries, CSCall++ does not really invent new vague model for programmers to learn to use. Programmers' understanding of POSIX model is still reusable. But the C++ error reporting mechanism is reinvented. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |