Post by Phillip FrabottPost by wijMy answer is a provision of something that converts source code to compile in
different OS. It is about tool and souce program, not absolutely what the
standard the source conforming to.
For example, lots problems about 'text' and pure cstring.
If 'portability' is desired with this issue of text (esp. to/from MS-Window),
considerations like using Qt library may be more real than whatever c++std
provides.
And even within Window, portability between early version and later is a problem.
What is the real portability?
This type of question is going to be subjective I believe.
To me, Portability means that it is OS agnostic.
With the above stated...
source code portability means that I do not have to modify any code (as
the person compiling) in order to make it work. I should be able to
simply ./configure (or ./configure --OS=<OS Ident>) && ./make and it
will build for the correct OS.
binary portability means that I can take the binary executable and use
it on any OS without needing to be recompiled (this is very rare).
hardware portability means that I can take the source code and it will
compile on any type of hardware/CPU without me having to modify any
code. It should be a simple matter of ./configure (or ./configure
--arch=<Arch/CPU type>) && ./make and it will build for the correct
hardware/CPU architecture.
I want to point about again that this question is going to be
subjective. I don't think anyone will fully agree on a standardized
(real) definition of portability.
Well there's "thoroughly abstract" and "thoroughly concrete",
that a usual idea is to write to a layer, an abstraction layer
or portability layer, yet not to add layers un-necessarily
above the concrete, which are as of values, about "adopting
an adapter" and "abstracting an adapter", the "thoroughly
concrete" and "thoroughly abstract", where an adapter itself
is usually considered to embody an implementation of an abstraction
itself, about things like "four facilities: FS MQ DB WS".
Abstraction usually involves making for the built-in types,
what derived from word-width, for example as with regards
to what int, long int, and long long int, or long and long long,
are, as since the great "2^31" and size_t and ssize_t, with
regards to signed and unsigned, and for example float and double,
and long double, the machine word definitions.
Then there are most usual facilities like a process model
its standard I/O, and, file-system or FS, as examples, of
things that are mostly ubiquitous, while though usually
enough libraries should be defined to deal in abstractions
vis-a-vis the concrete, the things.
The autoconf and configure scripts are of course very usual,
a de facto sort of standard in terms of building with make,
the usual tool, then as with regards to compilers, assemblers,
loaders, and linkers, and symbols.
Many standard libraries already begin to hide portability
concerns, with regards to alignment and pointer arithmetic,
with regards to compiler back-ends, which generate assembler
from which is read out machine code, the binaries.
Portability then in terms of "API", and "ABI", those being
terms around looong before "API I mean a web-service WS call"
and "ABI what's that", is sometimes also called "logical"
and "physical", but usually "source" and "binary".
Portability usually enough means writing source code that's
un-modified to compile the abstraction to adopt the adapter
to concretely fulfill the system, yet it also may mean the
instrumenting, as it were, or adding the cases in the code,
that make it possible to compile for multiple "targets",
usually. (There are build "targets" the build stages,
build "targets" the build outputs, ....)
Sometimes also called "cross-platform".
Usually it's a matter that there result either hardware
systems, or protocols, or formats, implementations
abstractions of concrete adapters of those.
There's a usual idea that higher-level code is
"thoroughly abstract" yet _aligns_ well enough
to the hardware that it results "thoroughly concrete".
Often though you'll find code written to whatever
library pops up first, or these days often "convention-bound"
frameworks where there's a bit of the metaprogramming already
put into place and not usually writing much of the "logic"
at all. Yet, it still often results a pretty thorough
mish-mash of concrete and abstract, or adapter and user types,
domain types say, with regards to "logic" and "utils",
on "built-ins", almost always "library types", and built-ins.
It's a great thing to study "portability", meaning making
an abstraction of the facilities, that facility means
the system or protocol or format, an adapter on it.
An exercise of implementing "portability" is a great part
of not only "code understanding", "system understanding".
It's not even so different in "mathematical foundations"
itself.