Hal Vaughan wrote:
> Jeff Schwab wrote:
>
>> Hal Vaughan wrote:
>>> Ian Collins wrote:
>>>
>>>> Hal Vaughan wrote:
>>>>> I've been researching threads and, since I'm coming from Perl, where
>>>>> fork()
>>>>> is used, that was my first thought. I've noticed, while searching,
>>>>> that
>>>>> there isn't as much on fork() in C++ as one would expect. Is there
a
>>>>> reason for this? Is fork() considered dangerous or a command to
avoid?
>>>>>
>>>> fork() is a library function, not a command.
>>>>
>>>> You won't see fork() discussed in a C++ context because it is not
part
>>>> of the language (or part of C), it is a POSIX standard function. So
you
>>>> will see it discussed extensively in UNIX texts or on
>>>> comp.unix.programmer.
>>> Which also explains why it's not mentioned in so many sites. But the
few
>>> that did referred to it like it's standard.
>> It is standard, just not part of the C or C++ standards. :) POSIX is a
>> very popular API for writing ****table programs, especially in C.
>
> So if I use fork() does that mean it won't work on Windows?
Sort of. There may be some quasi-native API to allow it. The Python
community decided that there was no reasonable way to do it; the Python
os.fork method does not work on Windows.
> It looks like there are implementations of POSIX libraries for Windows
> and non-Unix platforms.
You'll have to ask in a platform-specific group. I recall that Windows
NT nominally sup****ted POSIX in order to meet a DoD requirement, but
someone more familiar with that OS recently told me that using the POSIX
interface precluded using a lot of Windows-specific features,
particularly wrt the GUI. I know precious little about this topic,
though.
> I don't expect this program to be used on anything other than Linux, but
> it's always better to be open-ended about such things than not.
Maybe. If you're using OS-specific features like those accessible
through POSIX, then there are going to be platforms where your code just
won't work out of the box, no matter what library you use. Your best
bet is to encapsulate platform access behind a modular API, backed by
platform-specific implementations.
> In the meanwhile I'm finally looking into Boost and notice that their
> libraries are multi-platform, so I'll most likely use that, but it
always
> helps to know other possibilities as well.
AFAIK, POSIX and Boost are the best options. I have also seen Qt and
part of Apache (yes, as in httpd) used as ****table OS abstraction layers.
|
