Portability

[Walter Roberson]

jacob navia wrote:

No, but I bet someone else can.

It is my -impression- (possibly incorrect) that the cell phone market
is heavily programmed in Java; I had gathered that C is not supported
on a lot of those systems. But I do not work in that field, so it
could be that C is merely not offered as a "public" interface and
that the Java itself is implemented in C? Could someone who works
with cell phones clarify/correct this issue?

 

[Flash Gordon]

jacob navia wrote, On 07/04/08 10:55:

Again, no arguments whatsoever. The fact that ALL windows systems
feature a C interface is answered with "maybe". Can you name a single
one that doesn't?

You asked for a single one that doesn't, so here is one for you. BeOS. I
suspect there are others, but this is the one that came to mind.

The "origins of C" are the same as the origins of C++ by the way.

Only if you take the "origins of C++" as being before it's creator had
even started thinking about creating it.

 

[Ian Collins]

But if you take one of the fundamental concepts of C++,
the concept of class, constructors, destructors, and
all what comes with that (copy constructors/destructors)
are surely not optional.

In this sense I mean that constructors and destructors are the
wrong solution because they overly complexify the language
without a real gain.

Constructors exist in C. Most people, *when they need to do it*
will write

mystruct *make_mystruct(args);

or "build_mystruct" or whatever. What is important is that in C
you *can* do it optionally, but you are not forced to. In C++
this is required.

You can do the same in C++, you just have the option of an automatic
constructor. This is more than mere syntactic sugar, with
initialisation lists constructors support better optimisation that
regular functions. When coupled with automatic destructors they enable
programming idioms that are impossible (or very messy) to code in C.

That's one reason why automatic constructors and destructors are built
into the language. Another is the very laudable design goal of user
defined types behaving as close to built in types as possible.

My thesis is that a much simpler language than C++ is possible, and
more, *required* to keep the language size within the limits
imposed by our own circuitry.

It did, but it evolved. Whether it evolved in to a monster or an
adventure playground is a matter of perspective.

I can buy a 4GB extension for my PC anywhere. I can't go to the
pharmacy however, and buy a brain extension. My capacity is limited
and there *is* a limit to the programming trivia I am ready
to swallow.

C++ has gone way beyond that limit.

I think you are speaking as an implementer rather than a user. Like
many things in the world of software, a user can stay within their
comfort zone. I know plenty of C++ programmers who seldom, if ever
write templates. They still produce good quality code.

True, I have been proposing *some* extensions that mimic C++,
but in a very limited way, without taking the whole enchilada into C!

P.S. I have repeated this since ages but this die hards just do not
get it...

It's not a matter of "getting it", it's more a case of understanding
what you are proposing and simply not agreeing.

 

[Ioannis Vranos]

In your above sentance, about there being "portable ones out there",
what do you mean by portable? Do you mean that there are pure
ISO standard C implementations of these things? Did you mean
that there are libraries available that have all the system-specific
knowledge built in already, making them usable on -every- system?
On every -hosted- system?

I meant portable APIs, which have not portable implementations necessarily.

 

[jacob navia]

You asked for a single one that doesn't, so here is one for you. BeOS. I
suspect there are others, but this is the one that came to mind.

Dead. Dead ones do not count please.

 

[Walter Roberson]

I meant portable APIs, which have not portable implementations necessarily.

I've designed a portable network API for networks with no latency
(instantaneous packet travel.) There are no implementations of it
at all, so it "have not portable implementations necessarily".
Should I release the API specifications so that "one can use them too" ?
I did, after all, design it to be portable.


Perhaps it would help if you re-tried explaining what you meant
by "portable".

 

[Ioannis Vranos]

I've designed a portable network API for networks with no latency
(instantaneous packet travel.) There are no implementations of it
at all, so it "have not portable implementations necessarily".
Should I release the API specifications so that "one can use them too" ?
I did, after all, design it to be portable.


Perhaps it would help if you re-tried explaining what you meant
by "portable".

Is this portable network API meant to be used by C code, so as to write
C networking programs?

 

[Flash Gordon]

jacob navia wrote, On 07/04/08 21:57:

Dead. Dead ones do not count please.

I'm sure you can still install it on current HW and you did not specify
current in any case.

However, there is the Cocoa API on the Apple MAC (specifically in MacOS
X) which is Objective-C if you want something more current. This is
rather more than just GUI which is what you were asking about. The X
server on recent MacOS X releases is an addition which has been bolted on.

 

[santosh]

It is my -impression- (possibly incorrect) that the cell phone market
is heavily programmed in Java; I had gathered that C is not supported
on a lot of those systems. But I do not work in that field, so it
could be that C is merely not offered as a "public" interface and
that the Java itself is implemented in C? Could someone who works
with cell phones clarify/correct this issue?

I gather that cell phone application software if implemented in Java for
the same reasons that many desktop applications are done so: you can
distribute the software over a network and clients need not posses a
compiler or compatible hardware to run them. The system software (like
the OS and the Java VM) are most often done in C with bits of
assembler.

 

[John Bode]

One of the holy cows here is this "portability" stuff.
snerk


In practice, portability means:

1) Use the least common denominator of all the supported
systems.

Real-world example: I worked on a system that had to run on Windows
3.1, Solaris, and Classic MacOS concurrently. I had this wonderful
idea to use enums to store a series of bit masks. Unfortunately,
these bitmasks were 32-bit, and while MPW supported 32-bit enums, MSVC
did not. So much for my great idea.

LCD is the minimum that the Standard mandates (in this particular
case, the minimum is 16-bit enums).

2) Between usability / good user experience and portability
always choose portability since this minimizes programming
effort

It *is* possible to deliver both usability *and* portability; I've
done it. That same project used a third-party library for GUI
development that mimicked the native look and feel for each platform.
People sitting on Windows thought they were using a regular Windows
app, people sitting in front of a Mac thought they were using a
regular Mac app (if you were willing to ignore a couple of minor
glitches), and people sitting on Solaris thought they were using a
regular OpenLook app. All used the same code base.

Absent such tools, it's possible to factor out the platform-specific
sections, and keep the core application code platform-agnostic.
Portability is *not* a binary condition; it's a matter of degree.

This leads to mediocre software that runs anywhere but that nobody uses
because it is just that: MEDIOCRE.

I will gladly put up anything I wrote in the '90s as an example of
code that was *not* mediocre.

GUIS?

Non portable

And often not relevant. The bulk of the code I've written in my
career had no GUI.

Network?

Non portable.

Ditto.

This obsession with portability as the *only* way to measure software
has been carried out into this group

*Nobody* in this group has claimed portability is the *only* way to
measure software; however, for many of us who've been doing this for a
living, it is a major concern. In almost 20 years, I've worked on 1,
count 'em, *1* system that did not have to support multiple platforms
concurrently. And I'm not talking about embedded systems, or exotic
platforms; I'm talking Windows, MacOS, *nix.

My priorities are different

1) Correct software, few bugs
2) Good user interface, good performance.
3) Small software, avoiding bloat
4) Portability

We *all* strive for correctness, performance, etc.