Portability, where?

[fabio de francesco]

Hi,

I'm not a professional programmer, but I've been writing C/C++ and Ada
programs for a few years on GNU/Linux without ever concerning on
standards and portability to other OSs.

I've always noted that when I write code I must use lots of platform
specific system calls (POSIX and X/OPEN). Often I found myself using
threads and concurrent processes with some sort of IPC. Some time I
need some socket API. When I just want to open a file, making the
function fail if the file exist I have to use the low-level open()
with O_EXCL. Many more examples like these can be showed.

What I would like to ask is:

1) Is portability and adhesion to the standards a real concern for the
people in this group?

2) Is it possible to write real code without breaking portability and
adhesion to the standards?

3) What kind of choices do people that write code as a job take to
deal with these issues?

Ciao,

Fabio De Francesco

[Peter Jansson]

On Mon, 5 Jul 2004, fabio de francesco wrote:

1) Is portability and adhesion to the standards a real concern for the
people in this group?
Yes. This group is about *the* ISO/ANSI C++ Standard.
2) Is it possible to write real code without breaking portability and
adhesion to the standards?
I believe so. I have written a lot of code that follows the standard and
that code actually compiles fine for a lot of platforms. Further, this
have been *real* code, used in *reality*.
3) What kind of choices do people that write code as a job take to
deal with these issues?

I often design code to follow the C++ standard and use abstract base
classes for classes that later perhaps must be specialized due to some
platform specific issue.

Regards,
Peter Jansson
http://jansson.net/

[Julie]

Peter Jansson wrote:

On Mon, 5 Jul 2004, fabio de francesco wrote:

1) Is portability and adhesion to the standards a real concern for the
people in this group?

Yes. This group is about *the* ISO/ANSI C++ Standard.

<nitpick>

Actually, comp.lang.c++ is about the usage of the _language_ as defined by the
standard.

The group about the standard is comp.std.c++

</nitpick>

[Evan Carew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fabio de francesco wrote:

Hi,

I'm not a professional programmer, but I've been writing C/C++ and Ada
programs for a few years on GNU/Linux without ever concerning on
standards and portability to other OSs.

I've always noted that when I write code I must use lots of platform
specific system calls (POSIX and X/OPEN). Often I found myself using
threads and concurrent processes with some sort of IPC. Some time I
need some socket API. When I just want to open a file, making the
function fail if the file exist I have to use the low-level open()
with O_EXCL. Many more examples like these can be showed.

What I would like to ask is:

1) Is portability and adhesion to the standards a real concern for the
people in this group?

2) Is it possible to write real code without breaking portability and
adhesion to the standards? It looks like the portability issues you are looking at aren't related
to the language (yet), such as, thread initialization, signals,
sockets, and low level file IO operations.

While most of these can be partially addressed in add on libraries such
as Boost, they aren't yet part of the C++ standard. That said, since you
are already familliar with the Linux environment, if you are really
interested in portability, you might take a gander at GNU's
Autoconf/Automake/libtool utilities. These tools are designed with
portability in mind and make the tack of code distribution much easier.
3) What kind of choices do people that write code as a job take to
deal with these issues?

Ciao,

Fabio De Francesco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFA6coFoo/Prlj9GScRAh95AJ0Y6x4RQeTSm448eAphnfcBf9AFdQCfWi54
YoxtOIudDOzQvcVamlwNCE0=
=S/1k
-----END PGP SIGNATURE-----

[Cy Edmunds]

"fabio de francesco" <fm**@tiscali.it> wrote in message
news:ba**************************@posting.google.c om...

Hi,

I'm not a professional programmer, but I've been writing C/C++ and Ada
programs for a few years on GNU/Linux without ever concerning on
standards and portability to other OSs.

I've always noted that when I write code I must use lots of platform
specific system calls (POSIX and X/OPEN). Often I found myself using
threads and concurrent processes with some sort of IPC. Some time I
need some socket API. When I just want to open a file, making the
function fail if the file exist I have to use the low-level open()
with O_EXCL. Many more examples like these can be showed.

What I would like to ask is:

1) Is portability and adhesion to the standards a real concern for the
people in this group?
Yes.

2) Is it possible to write real code without breaking portability and
adhesion to the standards?
Well, I certainly try. For instance, I have some software which must load a
shared library by name. Of course this is operating system dependent, but I
was able to minimize the dependence by encapsulating the details using a
"pointer to implementation" pattern. Using this technique the software
(which has hundreds of files total) has only two or three small files which
include windows.h.

3) What kind of choices do people that write code as a job take to
deal with these issues?
Lately I've been porting my Windows C++ code to Unix even though I don't
particularly need the Unix version. I thought I was writing portable code
before but when I tried porting to Unix I found a lot of problems. Now my
Windows code is more portable and also conforms to the standard better.

The other thing I do is to use Python to write "glue" code. Python is slow
compared to C++ but has excellent portability and supports threads, sockets,
and a whole lot of other things. The fact that Python is ultimately based on
C shows that you can write a single interface that covers a lot of operating
system territory.

Ciao,

Fabio De Francesco

--
Cy
http://home.rochester.rr.com/cyhome/

[fabio de francesco]

"Cy Edmunds" <ce******@spamless.rochester.rr.com> wrote in message news:<K5****************@twister.nyroc.rr.com>...

...
Well, I certainly try. For instance, I have some software which must load a
shared library by name. Of course this is operating system dependent, but I
was able to minimize the dependence by encapsulating the details using a
"pointer to implementation" pattern. Using this technique the software
(which has hundreds of files total) has only two or three small files which
include windows.h.
...
The other thing I do is to use Python to write "glue" code. Python is slow
compared to C++ but has excellent portability and supports threads, sockets,
and a whole lot of other things. The fact that Python is ultimately based on
C shows that you can write a single interface that covers a lot of operating
system territory.
Peter Jansson <we*******@jansson.net> wrote in message news:<Pi*******************************@otaku.free shell.org>...
I often design code to follow the C++ standard and use abstract base
classes for classes that later perhaps must be specialized due to some
platform specific issue.

These examples have exactly the kind of informations I need. Please,
some more like them.

Regards,

Fabio De Francesco

[Peter Jansson]

On Tue, 6 Jul 2004, fabio de francesco wrote:

These examples have exactly the kind of informations I need. Please,
some more like them.

I could perhaps give you som more examples if you supply more intelligence
into what you are designing or hoping to desing in the future.

Regards,
Peter Jansson
http://jansson.net/

[E. Robert Tisdale]

fabio de francesco wrote:

I'm not a professional programmer,
but I've been writing C/C++ and Ada programs for a few years
on GNU/Linux without ever concerning on standards
and portability to other OSs.

I've always noted that, when I write code,
I must use lots of platform specific system calls (POSIX and X/OPEN).
Often, I found myself using threads and concurrent processes
with some sort of IPC. Some time I need some socket API.
When I just want to open a file, making the function fail
if the file exist I have to use the low-level open() with O_EXCL.
Many more examples like these can be showed.

What I would like to ask is:

1) Is portability and adhesion to the standards
a real concern for the people in this group?
Yes.
2) Is it possible to write real code
without breaking portability and adhesion to the standards?
No.
3) What kind of choices do people that write code as a job take
to deal with these issues?

Layering.

In a *layered* design,
platform dependent code is sequestered in libraries separate
from the common portable code. The common portable code
is said to be "built on top of" the underlying platform dependent code
because it invokes platform dependent behavior *only* through
function calls to the platform dependent library functions.
(platform = machine architecture + operating system + C++ compiler).

It is practically impossible
to write useful programs that port everywhere.
A GUI written for your Windows PC probably won't port to you cell phone.
Compliance with the ANSI/ISO C++ standards
has almost nothing to do with portability
and is your *least* important consideration.
The most importand determinant of portability is whether or not
the required *resources* are provided by the target platform.
You must identify all of the possible target platforms and, in practice,
you must build and test your program on each target platform
before you can claim that it will port to it.

The C and C++ computer programming languages are frequently used
instead of assembler to implement the platform dependent code
as well as the common portable code. This code may include
language extensions and invoke behavior which is not defined
by the ANSI/ISO C++ standard as long as the behavior is well defined
for the target platform. For example,
the implementation of the standard library that came with your compiler
will *not* generally port to any other platform. For example,
the device drivers that are used by your operating system
may have been written in C++ but are *not* guaranteed to port
to any other machine architecture.