octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New function proposal


From: John W. Eaton
Subject: Re: New function proposal
Date: Wed, 14 Feb 2007 11:55:07 -0500

On 14-Feb-2007, Michael Goffioul wrote:

| John W. Eaton a écrit :
| > On 13-Feb-2007, address@hidden wrote:
| >
| > | Here's another variant, which moves popen2 into C++ and provides
| > | Win32 implementation. Note that the UNIX version is not tested *at all*
| > | (I don't even know if it compiles): I just tried to convert popen2.m in
| > | C++, but it probably needs fixing.
| >
| > I suppose having popen2 and pipe as built-in functions is OK.
| >
| > I don't like that we are scattering system dependent (non POSIX) code
| > all over Octave, so I think it would be better to collect all the
| > Windows-specific code like this that is large enough to be a separate
| > function and put it in a separate file.
| >   
| 
| That' why I used oct-syscalls.cc. How do see this then? Can you make it 
| clearer how you
| would like to see it? oct-syscalls-win32.cc, oct-syscalls-posix.cc...?

I think the system-depenent parts belong in liboctave/lo-sysdep.cc or
src/sysdep.cc.  Then the function in syscalls can simply call the
function defined in sysdep.  But it is not important for now.

| >   +   if (! CreatePipe (&childRead, &parentWrite, NULL, 0) ||
| >
| > Is NULL necessary?  Won't 0 work just as well in C++ code with proper
| > prototypes?
| >   
| 
| It's a pointer, so reinterpret_cast<LPSECURITY_ATTRIBUTES>(0) or
| (LPSECURITY_ATTRIBUTES)0 should be OK. I just found NULL easier
| to write. I forgot it had to avoided in C++.

I don't think you need a cast here.  Just using 0 should be fine.  If
it is not, then what error does it produce?

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]