Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121074 > unrolled thread

What is portability?

Back to article view | Back to comp.lang.c++

Contents

  What is portability? wij <wyniijj5@gmail.com> - 2024-11-29 17:05 +0800
    Re: What is portability? Phillip Frabott <nntp@fulltermprivacy.com> - 2024-11-29 16:34 -0500
      Re: What is portability? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-29 14:00 -0800
      Re: What is portability? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-29 18:51 -0500
      Re: What is portability? wij <wyniijj5@gmail.com> - 2024-11-30 20:14 +0800
      Re: What is portability? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-30 20:26 +0200
        Re: What is portability? Phillip Frabott <nntp@fulltermprivacy.com> - 2024-11-30 14:09 -0500
          Re: What is portability? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-30 22:37 +0200
    Re: What is portability? Rosario19 <Ros@invalid.invalid> - 2024-11-30 17:11 +0100
      Re: What is portability? Rosario19 <Ros@invalid.invalid> - 2024-11-30 17:24 +0100
    Re: What is portability? Wuns Haerst <Wuns.Haerst@wurstfabrik.at> - 2024-12-01 11:30 +0100
      Re: What is portability? Paavo Helde <eesnimi@osa.pri.ee> - 2024-12-01 18:30 +0200
    Re: What is portability? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 14:10 -0800
      Re: What is portability? wij <wyniijj5@gmail.com> - 2024-12-02 09:10 +0800
        Re: What is portability? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 20:15 -0800

#121074 — What is portability?

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?

[toc] | [next] | [standalone]

#121085

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

[toc] | [prev] | [next] | [standalone]

#121086

On 11/29/2024 01:34 PM, 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.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#121087

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.

[toc] | [prev] | [next] | [standalone]

#121092

On Fri, 2024-11-29 at 16:34 -0500, 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.
> 
> 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.
> 

I think what we really care is survivability/reusability of software from
environment changes (from platform to platform, or on the same platform)

E.g. even DOS executables (actually,any) can be 'ported' to Linux (there is dosbox).
Actually, all  DOS source programs are the same portable, if some one provides
the tool. This is the principle of Universal Turing Machine.

Portabilty is relative. 

[toc] | [prev] | [next] | [standalone]

#121098

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.

[toc] | [prev] | [next] | [standalone]

#121099

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

[toc] | [prev] | [next] | [standalone]

#121100

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.

[toc] | [prev] | [next] | [standalone]

#121096

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

[toc] | [prev] | [next] | [standalone]

#121097

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

[toc] | [prev] | [next] | [standalone]

#121101

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.

[toc] | [prev] | [next] | [standalone]

#121102

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?

[toc] | [prev] | [next] | [standalone]

#121110

On 11/29/2024 1:05 AM, 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?
> 

Pure portability? I personally think that is when I can compile my code 
for any system that has a compliant compiler. For instance, this older 
code of mine should be 100% portable to any C++11 compiler:

https://pastebin.com/raw/CYZ78gVj

[toc] | [prev] | [next] | [standalone]

#121114

On Sun, 2024-12-01 at 14:10 -0800, Chris M. Thomasson wrote:
> On 11/29/2024 1:05 AM, 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?
> > 
> 
> Pure portability? I personally think that is when I can compile my code 
> for any system that has a compliant compiler. For instance, this older 
> code of mine should be 100% portable to any C++11 compiler:
> 
> https://pastebin.com/raw/CYZ78gVj
> 

Yes, it compiles, but no time to see inside. From 'OO' theory, your
class lacks 'attrtbutes' members.

----
Booting threads...
Threads running...

Threads completed!

node_allocations = 92400000
node_deallocations = 92400000

dtor_collect = 10
release_collect = 159
quiesce_complete = 169
quiesce_begin = 169
quiesce_complete_nodes = 92400000


Test Completed!

[toc] | [prev] | [next] | [standalone]

#121116

On 12/1/2024 5:10 PM, wij wrote:
> On Sun, 2024-12-01 at 14:10 -0800, Chris M. Thomasson wrote:
>> On 11/29/2024 1:05 AM, 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?
>>>
>>
>> Pure portability? I personally think that is when I can compile my code
>> for any system that has a compliant compiler. For instance, this older
>> code of mine should be 100% portable to any C++11 compiler:
>>
>> https://pastebin.com/raw/CYZ78gVj
>>
> 
> Yes, it compiles, but no time to see inside.

thanks for giving it a go. :^)


> From 'OO' theory, your
> class lacks 'attrtbutes' members.

Humm... You mean get/set_* functions?


> 
> ----
> Booting threads...
> Threads running...
> 
> Threads completed!
> 
> node_allocations = 92400000
> node_deallocations = 92400000
> 
> dtor_collect = 10
> release_collect = 159
> quiesce_complete = 169
> quiesce_begin = 169
> quiesce_complete_nodes = 92400000
> 
> 
> Test Completed!
> 
> 

Interesting results to me! Thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web