On 11/29/2024 04:05, wij wrote:

My 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.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/29/24 16:34, Phillip Frabott wrote:
...

To me, Portability means that it is OS agnostic.

The OS is only o part of the problem. Two different implementations
targeting the same OS can be incompatible with each other, in ways that
require code to be carefully written to work as intended with both implementations.

Portability is not a yes/no characteristic. Every working program has a
set of implementations that can translate it and execute it as desired.
Almost every program has some implementations that cannot. A program is
more portable if it has a wider variety of platforms to which it can be
ported. You need to specify what set of platforms you want your code to
be portable to, before you can decide whether is is portable to them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29 Nov 2024 17:05:19 +0800, wij wrote:

My 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?

the portability is easy, one subset of one language is portable if
1) use the same laguage with same undefinite beaviours
2) use the same tipes
3) use the same functions or operations on types of 2 above

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 30 Nov 2024 17:11:46 +0100, Rosario19 wrote:

On Fri, 29 Nov 2024 17:05:19 +0800, wij wrote:

My 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?

the portability is easy, one subset of one language is portable if
1) use the same laguage with same undefinite beaviours
2) use the same tipes
3) use the same functions or operations on types of 2 above

same tipe = same set
same function or operation= the math definition of one function or
operation

f:A-->B g:C-->D are the same if and only if
C=A and
f(x)=g(x) for all x in A

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/30/2024 13:26, Paavo Helde wrote:

Configure+make is not so portable and not so easy for more complex
projects. Nowadays, a more portable and much easier solution is provided
by CMake.

This is one of the marketing lies of CMake. CMake is not more or less
portable then CMMI. CMMI and CMake are capable of building for all the
same platforms and architectures and one is not "better" then the other.
They just do things differently. Actually there are some very old
platforms that CMMI can build for that CMake cannot. I'm not able to
build a few projects for the 81066 processor which is used in a lot of
radio flyer models (Cessna and Bravo series model planes for example)
and a few modern drones. However, CMMI is more then capable of doing so.
While this is a niche use-case, it still drives home the fact that CMake
is not "better" more "more portable" then CMMI. In 95% of cases CMMI and
CMake can build the same things, and CMMI is slightly more capable for specialized cases which is the other 5%.

(Correction: CMake can build for the 81066-B processor but not the
original 81066 processor)

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29.11.2024 23:34, Phillip Frabott wrote:

On 11/29/2024 04:05, wij wrote:

My 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.

Configure+make is not so portable and not so easy for more complex
projects. Nowadays, a more portable and much easier solution is provided
by CMake. Nowadays I build also my Windows GUI programs with CMake, it generates better Visual Studio project files than I could do myself, and
it does it in seconds. Of course, it also generates way better makefiles
on Linux than I could do myself, and again it does it in seconds, not in
many minutes like a typical configure step.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.11.2024 21:09, Phillip Frabott wrote:

On 11/30/2024 13:26, Paavo Helde wrote:

Configure+make is not so portable and not so easy for more complex
projects. Nowadays, a more portable and much easier solution is
provided by CMake.

This is one of the marketing lies of CMake. CMake is not more or less portable then CMMI. CMMI and CMake are capable of building for all the
same platforms and architectures and one is not "better" then the other.
They just do things differently. Actually there are some very old
platforms that CMMI can build for that CMake cannot. I'm not able to
build a few projects for the 81066 processor which is used in a lot of
radio flyer models (Cessna and Bravo series model planes for example)
and a few modern drones. However, CMMI is more then capable of doing so. While this is a niche use-case, it still drives home the fact that CMake
is not "better" more "more portable" then CMMI. In 95% of cases CMMI and CMake can build the same things, and CMMI is slightly more capable for specialized cases which is the other 5%.

(Correction: CMake can build for the 81066-B processor but not the
original 81066 processor)

I guess by CMMI you mean configure+make. Yes, I agree these are lower
level tools which can work in more specialized niches. But they are not
able to create native Visual Studio projects which is 90% of what I work
with (NMAKE projects won't do), so I could not use configure+make in
Windows even if I wanted to. I guess one can argue over if this means
they are not portable enough or something else, I don't care.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 29.11.2024 um 10:05 schrieb wij:

My 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?

Portability is the emeny of performance. If you abstract OS-specific
APIs into a portable layer they usually become >= 100 times slower.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.12.2024 12:30, Wuns Haerst wrote:

Am 29.11.2024 um 10:05 schrieb wij:

My 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?

Portability is the emeny of performance. If you abstract OS-specific
APIs into a portable layer they usually become >= 100 times slower.

I'm sorry to hear you have had such a bad experience, try to work with
more competent programmers next time!

Seriously, I cannot imagine what OS call could be slowed down 100x by
wrapping it in something. Maybe getpid() (this is a one-liner in kernel)
if somebody decides it needs to be translated into a GUID in each call?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)