Portability

[jacob navia]

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

In practice, portability means:

1) Use the least common denominator of all the supported
systems.
2) Between usability / good user experience and portability
always choose portability since this minimizes programming
effort

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

GUIS?

Non portable

Network?

Non portable.

This obsession with portability as the *only* way to measure software
has been carried out into this group by the "requirement" to the gcc
compiler:

gcc -Wall -ansic -pedantic

Obviously std=c99 is "not portable" as Mr Thompson never fails to
remind us when somebody recommends using standard C.

I take exception at this nonsense. Portability is fine if it doesn't
cost, or if its cost is minimal.

My priorities are different

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

 

[Ian Collins]

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

In practice, portability means:

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

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

That depends on your requirements. If everything has to run identical
code, you don't have a choice. Otherwise, you split the generic and
platform specific part of the code. This has been standard practice for
decades.

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

GUIS?

Non portable

Well that's pretty bloody obvious. There's plenty of environments that
don't have graphical displays. If an application requires graphical
display, that display will have a minimum requirement and a portable
layer can be produced or reused.

Network?

Non portable.

BSD socket are ubiquitous in networking. If a device supports IP, it
will have sockets.

This obsession with portability as the *only* way to measure software
has been carried out into this group by the "requirement" to the gcc
compiler:

gcc -Wall -ansic -pedantic

That simply bocks gcc's language extensions, just like the conforming
mode of any compiler. It does not prevent one from using platform
specific or portability wrapper libraries.

Obviously std=c99 is "not portable" as Mr Thompson never fails to
remind us when somebody recommends using standard C.

Well that's an unfortunate fact of life. While most if not all hosted
environments have C99 compilers, a large number of embedded ones do not.

I take exception at this nonsense. Portability is fine if it doesn't
cost, or if its cost is minimal.

Which nonsense? All I see is rhetoric, backed by misinterpretation of
some people's views.

My priorities are different

1) Correct software, few bugs

A good start.

2) Good user interface, good performance.

Orthogonal, many high performance applications don't have a UI.

3) Small software, avoiding bloat

Fine if you have simple requirements.

4) Portability

Fine if your end users don't require it.

 

[Flash Gordon]

jacob navia wrote, On 06/04/08 20:14:

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

In practice, portability means:

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

Or designing it so that it will make use of the greater abilities of
bigger systems. For example, if writing a calculator making use of the
constants provided so that one systems with higher precision or greater
range they are available but it will still work on whatever meets the
standard.

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

Or isolating the non-portable stuff so that it can easily be replaced.

You are ignoring the fact that people here often recommend going to
platform specific groups specifically *because* some problems are best
solved in a platform specific manner.

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

Not always, and anyway see comment above.

GUIS?

Non portable

Yes, they are non-portable so the code dealing with the GUI should be
isolated to ease porting and discussed in a group dealing with the
systems of interest. This is NOT saying you should not use a GUI.

Network?

Non portable.

True. This is why people are pointed at networking groups and system
specific groups. If the attitude was what you are suggesting such
redirections would not occur.

This obsession with portability as the *only* way to measure software

You are putting words in to peoples mouths again, words that contradict
what people have explicitly stated.

has been carried out into this group by the "requirement" to the gcc
compiler:

gcc -Wall -ansic -pedantic

Obviously std=c99 is "not portable" as Mr Thompson never fails to
remind us when somebody recommends using standard C.

It does not yet fully implement C99 and nor does your compiler. Are the
subsets of C99 that gcc and your compiler implement identical? If not
then that should show you the problem.

I take exception at this nonsense. Portability is fine if it doesn't
cost, or if its cost is minimal.

Yet you often recommend non-portable solutions to people even if there
is a portable solution.

My priorities are different

1) Correct software, few bugs

Easier to do if you know what actually *is* guaranteed by the standard.

2) Good user interface, good performance.

No one has said these are not important. Richard even recommended that
for performance you should use one of the optimised bignum libraries
rather than his portable one.

3) Small software, avoiding bloat

This does not in general contradict portability, and where it does you
can isolate the non-portable code.

 

[jacob navia]

You are still fighting the long-lost battle that C should be
competitive as a language for large scale applications with extensive
user interfaces in today's complex environments.

Yes, and the proof is lcc-win's source code. It uses the basic
interface of Windows (under windows) or X windows (under linux)

No it is not portable of course. It has been ported to many systems
that is all.

And this is not a lost fight, as the C++ people would like us to
believe. It is an alternative to language BLOAT, and to the
thousands of unnecessary features that C++ offers.

C was not designed or created for this purpose. It was designed as a
system programming language, for writing operating system kernels and
small utilities.

All GUIS support C. X windows and windows offered at the beginning
only a C binding.

I expect no more results from attempting to have a rational discussion
with you that have resulted in the past. Most likely I will killfile
you again soon.

I hope you do it as soon as possible.

Thanks in advance.

 

[Ian Collins]

And this is not a lost fight, as the C++ people would like us to
believe. It is an alternative to language BLOAT, and to the
thousands of unnecessary features that C++ offers.

Where you savaged by a rouge C++ program as a child? You do appear to
have been traumatised.

Maybe you should itemise those thousands of unnecessary features and
inform the C++ standard committee.

All GUIS support C. X windows and windows offered at the beginning
only a C binding.

Maybe, but that doesn't change the origins of C.

 

[jacob navia]

Where you savaged by a rouge C++ program as a child? You do appear to
have been traumatised.

This is typical of you. No arguments whatsoever.
Language BLOAT is produced by features that try to solve a problem
that can be solved in a simpler way.

Lcc-win doesn't have constructors or destructors, it has a garbage
collector, what makes C much more performant than the incredible
expensive solution offered by C++!

Lcc-win is trying to integrate compile time functions, what is much more
powerful than templates.

Maybe you should itemise those thousands of unnecessary features and
inform the C++ standard committee.

Constructors, copy constructors, destructors, and all the other stuff
should be optional at best.

Maybe, but that doesn't change the origins of C.

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?

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

 

[Ian Collins]

This is typical of you. No arguments whatsoever.

How does one argue with histrionics?

Language BLOAT is produced by features that try to solve a problem
that can be solved in a simpler way.

Like RAII?

Lcc-win doesn't have constructors or destructors, it has a garbage
collector, what makes C much more performant than the incredible
expensive solution offered by C++!

I've lost count of the number of times I've told you that constructors
and destructors are optional in C++. You continue to ignore this and
spew forth the same nonsense over and over. I've given examples, shown
you code and still you don't get it and then you accuse me of offering
no arguments.

Constructors, copy constructors, destructors, and all the other stuff
should be optional at best.

Then it's a good thing they are then, isn't it...

Again, no arguments whatsoever.

Argue with what? Jack said "[C] was designed as a system programming
language" and you replied with a spontaneous paragraph about GUIs.
There C was conceived long before what we know as GUIs.

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

No, but I bet someone else can. More to the point, why answer a
paragraph on the design of C with "All GUIS support C"? What have GUIs
to do with the origin of C?

 

[jacob navia]

Like RAII?

I've lost count of the number of times I've told you that constructors
and destructors are optional in C++.

Look, this is stupid. Of course they are optional since C++ accepts
(mostly) plain C. Then EVERYTHING in C++ is "optional".

Templates?

Optional. You can program in C without them.

Operator overloading?
Optional. You can program without them.

Classes?
Optional. If you do not define them they aren't there.

Name spaces?
Optional. If you do not use them they aren't there.

Division?

Optional. If you do not divide by a number it just isn't there!

Like all regulars, at the end you start with your word games.

You continue to ignore this and
spew forth the same nonsense over and over. I've given examples, shown
you code and still you don't get it and then you accuse me of offering
no arguments.

OK. No more discussions with you.

 

[Ian Collins]

I see you skipped this point, one idiomatic C++ technique that can't be
coded in C.

Look, this is stupid. Of course they are optional since C++ accepts
(mostly) plain C. Then EVERYTHING in C++ is "optional".

Good, so we agree.

OK. No more discussions with you.

This is typical of you. No arguments whatsoever.....

 

[Ioannis Vranos]

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

In practice, portability means:

1) Use the least common denominator of all the supported
systems.
2) Between usability / good user experience and portability
always choose portability since this minimizes programming
effort

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

GUIS?

Non portable

Network?

Non portable.

This obsession with portability as the *only* way to measure software
has been carried out into this group by the "requirement" to the gcc
compiler:

gcc -Wall -ansic -pedantic

Obviously std=c99 is "not portable" as Mr Thompson never fails to
remind us when somebody recommends using standard C.

I take exception at this nonsense. Portability is fine if it doesn't
cost, or if its cost is minimal.

My priorities are different

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

Jacob you are completely wrong on this. Or perhaps are you doing this
for advertisement reasons? If this is the case, you can advertise
yourself positively.

 

[jacob navia]

Jacob you are completely wrong on this.

Small detail. You forgot to explain why I am wrong.

Ahh of course, because its me. Yes, I see. That explains
everything

Or perhaps are you doing this
for advertisement reasons? If this is the case, you can advertise
yourself positively.

And you could advertise that your brain is able to do better than
this

 

[Richard]

Jacob you are completely wrong on this. Or perhaps are you doing this
for advertisement reasons? If this is the case, you can advertise
yourself positively.

You have been shown to be wrong, or unaware of many issues in C
recently. If you are to accuse someone of "being completely wrong" then
please justify this as you would expect people who correct you to do. Or
just join in the "Jacob bashing" as you have done - a core element here
enjoy that too :-;

 

[Ben Bacarisse]

Look, this is stupid. Of course they are optional since C++ accepts
(mostly) plain C. Then EVERYTHING in C++ is "optional".

Like all regulars, at the end you start with your word games.

It is not word games. How can anyone debate without agreeing on
terms? You said that certain things should be optional. This
surprised me and it obviously surprised Ian because he then explained
that these things already were by his understanding of the term.
What you need to do now (if you want to persuade anyone) is to say what
*you* mean by "optional" because it must be different to his (and to
mine, for that matter).

C (and C++) have an interesting technical meaning of this loose term
"optional" -- they have, as a design goal, that the programmer should
not pay a run-time penalty for features that he or she does not use.
This makes things like VLAs (and, say, operator overloading in C++)
optional in a deeper sense than the trivial one.

What do you mean when you say features should be optional if it is not
this meaning?

 

[Ioannis Vranos]

You have been shown to be wrong, or unaware of many issues in C
recently. If you are to accuse someone of "being completely wrong" then
please justify this as you would expect people who correct you to do. Or
just join in the "Jacob bashing" as you have done - a core element here
enjoy that too :-;

In summary, ISO C doesn't contain GUI APIs so far. So the argument of
not being portable using ISO C code and GUIs is void. Portable in ISO C,
means use as much ISO C code as possible, or better explained: Isolate
non-ISO C code in specific parts of your program.

Regarding non-portable GUIs , networks stuff etc, there are portable
ones out there, so one can use them too.


The whole argument that portability is not feasible because there are
GUIs etc do not make sense for a proven programmer like Jacob.

 

[jacob navia]

What do you mean when you say features should be optional if it is not
this meaning?

We have the following problem

The C++ language has tried to remain compatible with C.

As far as C++ goes, all C++ is optional. You can program almost
entirely in standard C and compile with a C++ compiler
(as many people do).

We can say then that C++ is an optional language



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.

The same with templates.

What we need is compile time functions and an opening up of the
compile time environment. Templates are the wrong solution since
they are inaccessible because it is the compiler that expands
the templates at compile time.

You can write templates in C by writing a special template
processor that will take a text file and produce another text
file with the expansion of the template for the given arguments.

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.

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.

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

jacob

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

P.P.S.S. With all due respect of course

 

[jacob navia]

jacob navia said:


Several others, however, have done so.

I do not think so, and even if that would be true,
it would have been better to say which argument
he was referring to. But that would have been too
much effort for his overworked brain I suppose.

Wrong. You're not wrong because you're you. You're wrong because you're not
right.

WOW that is a DEEP thought Mr Heathfield.

I am wrong because I am not right.



OK. Let's leave this at that then.

*WHY* I am wrong?

Becauzzzzzzzzeeeee... Because I am not right

DIXIT!!!

 

[Richard]

We have the following problem

The C++ language has tried to remain compatible with C.

As far as C++ goes, all C++ is optional. You can program almost
entirely in standard C and compile with a C++ compiler
(as many people do).

We can say then that C++ is an optional language



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);

Can you give a working example here please.

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.

I dont see how it is required. You can create an object without a
constructor. And then call myFunc(myClass & ref) or whatever. No
constructor per se.

The same with templates.

What we need is compile time functions and an opening up of the
compile time environment. Templates are the wrong solution since
they are inaccessible because it is the compiler that expands
the templates at compile time.

You can write templates in C by writing a special template
processor that will take a text file and produce another text
file with the expansion of the template for the given arguments.

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.

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.

So has java in terms of making you go dizzy.

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

jacob

Bottom line is that yo think C++ is too complicated. Frankly I
agree. And primarily because of the blowhards who maintain they can
fully understand and debug a program by reading 50,000 lines of code. I
defned their rights to do so even if I think it a silly way to do it
when a good quality debugger is at hand.

Did you ever try and read a C++ program which used any form of
inheritance and operator overloading? Nigh in impossible. At any one
time you might have anything in a base class member function and you
will have no idea which parent class member will be called at any one
time.

 

[Ben Bacarisse]

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

Well, we will have to agree to differ. While there was a connection
to the special way C defines "optional features" (zero cost when not
used) it was marginally on-topic, but there is no point in arguing a
C++ matter here. Post the above remark to comp.lang.c++ and I think
you will find you are mistaken (and if you are not, you will be
confirmed as being correct by real C++ experts -- its a win-win
situation).

 

[Ioannis Vranos]

Several people have already explained elsethread *why* you are not right. I
see no value in rehashing those arguments. Try reading them.

Has anyone checked for the possibility that he is not the real Jacob
Navia but some troll using his name?

 

[Walter Roberson]

Regarding non-portable GUIs , networks stuff etc, there are portable
ones out there, so one can use them too.

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?