Porting C software

[Keith Thompson]

jacob navia wrote:
[Compiler extensions]

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines
that these extensions can be useful. Not that they are needed. If
every compiler extension that was used and found useful made it into
the standard we'd have a language several times larger than C++ by
now.

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.

[...]

Operator overloading is never actually *needed*. It's syntactic
sugar; any program written to use operator overloading can be
equivalently written without it. In fact, a tool that parses source
code with overloaded operators (using some extension with well-defined
syntax and semantics) and translates it to standard C using function
calls would probably be much easier to write than a full compiler. I
mention that merely to demonstrate that operator overloading doesn't
add anything fundamental to the language.

It certainly can be convenient, and I've used it in languages that
support it.

Ok, you don't like C++ because it's too big and complex, and you don't
like C as it's currently defined because it lacks some features that
you think are important. That's fine. So why not invent a new
language? Your compiler already supports a language that's neither C
nor C++; just give it a name and don't claim that it's C. Of course
your compiler can still continue to support standard C; multi-language
compilers aren't a new idea. You can then stop worrying about whether
your extensions violate the C standard; they're not extensions,
they're language features. (As far as I can tell, the name "C+"
hasn't been used, but of course you can use any name you like.)

I don't believe this would have any effect on the likelihood of your
features being adopted in a future C standard, if that's still your
goal. C has borrowed existing features from other languages before
(e.g., prototypes from C++).

Just to be clear, this is a completely serious suggestion.

 

[jacob navia]

If you want extra numeric types what's wrong with having
functions add() , subtr() etc. to handle those types ? Why
overload the already existing operators ?

OK. You have a extended precision float and you want
to do:

qfloat a,b,c;

// ...
a = (a+b)/(5+sqrt(c)-b);

You get:

tmp1 = add(a,b);
tmp2 = subtr(Convert(5),b);
tmp3 = SQRT(c);
tmp4 = add(tmp2,tmp3);
a = divide(tmp1,tmp4);

You see now?

jacob

 

[jacob navia]

jacob navia wrote:
[Compiler extensions]
The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.
No, the fact that he did use them and found them useful underlines
that these extensions can be useful. Not that they are needed. If
every compiler extension that was used and found useful made it into
the standard we'd have a language several times larger than C++ by
now.

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.

[...]

Operator overloading is never actually *needed*. It's syntactic
sugar; any program written to use operator overloading can be
equivalently written without it. In fact, a tool that parses source
code with overloaded operators (using some extension with well-defined
syntax and semantics) and translates it to standard C using function
calls would probably be much easier to write than a full compiler. I
mention that merely to demonstrate that operator overloading doesn't
add anything fundamental to the language.

It certainly can be convenient, and I've used it in languages that
support it.

Yes, I agree with all that. It is not different than:
qfloat a,b,c;

// ...
a = (a+b)/(5+sqrt(c)-b); // Clear code

Instead you should write in current C:

tmp1 = add(a,b);
tmp2 = subtr(Convert(5),b);
tmp3 = SQRT(c); // No generic functions
tmp4 = add(tmp2,tmp3);
a = divide(tmp1,tmp4);

OR, even worst:

a = divide(add(a,b),add(subtr(Convert(5),b),SQRT(c));

Syntactic sugar is useful, as sugar itself is useful. I do take *some*
sugar with my coffee. But not like C++ where you take some
coffee with your sugar!

Ok, you don't like C++ because it's too big and complex, and you don't
like C as it's currently defined because it lacks some features that
you think are important. That's fine.

Thanks. At least you do not get so upset!

So why not invent a new language?

Because I am interested in the development of C. Not some other
language. That is why I try to propagate my ideas in this
forum and that is why I write a compiler for a version of C that
features some enhancements I consider useful!

> Your compiler already supports a language that's neither C
nor C++; just give it a name and don't claim that it's C.

I am not claiming that my enhancements are standard C.

Of course
your compiler can still continue to support standard C; multi-language
compilers aren't a new idea. You can then stop worrying about whether
your extensions violate the C standard; they're not extensions,
they're language features. (As far as I can tell, the name "C+"
hasn't been used, but of course you can use any name you like.)

I don't believe this would have any effect on the likelihood of your
features being adopted in a future C standard, if that's still your
goal. C has borrowed existing features from other languages before
(e.g., prototypes from C++).

Just to be clear, this is a completely serious suggestion.

I think that the difference between C and C++ at the semantic level is
object oriented programming.

C has no preconceived "frame of reference" like object oriented
programming in C++. I like this feature and want to keep it. There
is no need to invent another language. The extensions I am proposing
are useful, but clearly very minimal.

 

[Ian Collins]

Operator overloading is never actually *needed*. It's syntactic
sugar; any program written to use operator overloading can be
equivalently written without it. In fact, a tool that parses source
code with overloaded operators (using some extension with well-defined
syntax and semantics) and translates it to standard C using function
calls would probably be much easier to write than a full compiler. I
mention that merely to demonstrate that operator overloading doesn't
add anything fundamental to the language.

You describe an early cfront C++ compiler! Early C++ compilers
generated C source as an intermediate language. One of (if not the)
most respected C++ compilers currently available (Comeau) still does.

 

[Philip Potter]

I second this suggestion. If the language became popular enough to have more
than one compiler, I would seriously consider using it too.

I think that the difference between C and C++ at the semantic level is
object oriented programming.

C has no preconceived "frame of reference" like object oriented
programming in C++.

Bjarne Stroustrup seems to think C++ has no preconceived "frame of reference"
either:
http://www.research.att.com/~bs/bs_faq.html#Object-Oriented-language

I agree with him. There's no need to program in objects if your problem is an
algorithmic problem. I have done this in C++ before.

Phil

 

[Ian Collins]

I think that the difference between C and C++ at the semantic level is
object oriented programming.

Nonsense, C++ is designed as a multi-paradigm language.

C has no preconceived "frame of reference" like object oriented
programming in C++. I like this feature and want to keep it. There
is no need to invent another language. The extensions I am proposing
are useful, but clearly very minimal.

Tell me what C++ nasties this valid C++ code invokes?

struct X { int a,b; };

X operator+( X lhs, X rhs ) {
X tmp;
tmp.a = lhs.a+rhs.a;
tmp.b = lhs.b+rhs.b;
return tmp;
}

Is this how you propose to add operator overloading?

 

[jacob navia]

Nonsense, C++ is designed as a multi-paradigm language.

Yes, now Bjarne has changed his mind... but just a few years ago...

Tell me what C++ nasties this valid C++ code invokes?

struct X { int a,b; };

X operator+( X lhs, X rhs ) {
X tmp;
tmp.a = lhs.a+rhs.a;
tmp.b = lhs.b+rhs.b;
return tmp;
}

Is this how you propose to add operator overloading?

Exactly. That code would compile in lcc-win32.

The advantage of 20/20 hindsight is that some operators
can't be overloaded ("&&" or "||") what simplifies
everything since it is no longer necessary to explain
to beginners why overloading those is not a good idea.

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Yet another feature (this is planned only, I haven't implemented it
yet) is the operator [ ][ ] for two dimensional array access.

jacob

 

[Ian Collins]

Exactly. That code would compile in lcc-win32.

It also compiles with any C++ compiler. It can be made more efficient
in C++ by using pass by reference and (shock horror) more concise by
adding a constructor to X.

So there is little point compiling it as an extension to C.

I think people tend to forget that the "how do we extend C" argument in
one form or another happened 20 odd years ago, resulting a new language
called C++.

The most useful way to add such an extension is in the form of a
pre-compiler, generating standard C code. Then it is clear that you are
using something other than C.

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Also covered by C++.

You see what I'm saying? You are going down the path of those before
you who wanted a "cleaner" C++, bit by bit you end up adding most of the
features you set out to avoid, or pay a high price in efficiency by
leaving them out.

 

[Ed Jensen]

C++ is complex; but there is no problem with a programmer simply using
the subset of the language that he knows well and disregarding the rest.

Most developers work on a team comprised of many developers. It's
unlikely any two C++ developers will be comfortable with the same
subset. And, eventually, you end up having to maintain someone else's
code.

Using a subset of C++ is not a solution to C++'s incredibly radical
complexity.

 

[cr88192]

Bad idea. That immediately makes your code non-portable.

not desirable, but often required...

Another bad idea, again leading to non-portable code. Isolate
anything that really has to be non-portable in a separate file, so
as to limit the rework needed during a port.

works much of the time, but is a problem if something non-trivial is done,
which ends up making some large and non-trivial part of the codebase
non-portable.

the ideal is, that everything is portable everywhere.


the truth is: this doesn't scale well, and if the code is not going to be
very portable anyways, pick well, and exploit the system for what it is
worth...

so, one needs more and further reaching standards, and the hope that ones'
trradeoffs are worthwhile. one can hope for an ideal world, but just yet, it
does not exist...


for example, note that although I developon windows, and do some very
non-portable things, I still refrain from DirectX or the Win32 API (instead
choosing OpenGL and maintaining an overall minimalistic dependency on most
OS-dependent features).

I at least try for compatibility between the major OS's (that I use), namely
windows and linux, and the major architectures (that I also use), namely x86
and x86-64.

so, mac and ppc are not supported, nor arm or any of the other more esoteric
architectures, sad truth, but still truth.

apart from consoles and embedded, x86 is king.
apart from embedded, x86 and ppc are kings.

embedded is too constrained and diverse to really target in any general way,
and not for the kinds of code I write, there is, for the most part, no good
reason. most of my projects have almost no way to even hope of fitting in
the memory of most of these devices...


so, how big are ones projects?...

for a 300 kloc mostly 3D-tool beast (including an approx 70 kloc incremental
C compiler + assembler + linker), maintaining all that much portability is a
challenge...

for a 3 kloc command-line tool, it is a lot easier to be portable, but not
something 100x larger and inherently tied to non-portable technologies...

 

[jacob navia]

It also compiles with any C++ compiler. It can be made more efficient
in C++ by using pass by reference and (shock horror) more concise by
adding a constructor to X.

That adds nothing.

So there is little point compiling it as an extension to C.

I think people tend to forget that the "how do we extend C" argument in
one form or another happened 20 odd years ago, resulting a new language
called C++.

That is precisely the point. The extensions were piled up without
any consideration to the consequences. The end effect was that the
language has grown SO complex that there are 2 compilers that
compile ALL of it: Edison Design Group C++ front end, and Comeau.

ALL others have still a lot of missing features. There are features of
the language still not implemented by any compiler.

But still, each time that an extension is proposed for C, the same
argument rises: C++ has done it already. This makes C an obsolete
language, i.e. one where no new development is conceivable. And this
is precisely why I try tomake my extensions within the context of C!

Your attitude:
"It can be done more concisely by adding a constructor"
shows everything of the C++ mentality. The fact that you now
need an incredible complex machinery to do that, is just taken
for granted, doesn't matter, let's do it...

The most useful way to add such an extension is in the form of a
pre-compiler, generating standard C code. Then it is clear that you are
using something other than C.

I have no use for that. That would slow things down, and I do not see
why C can't be extended with some features that C++ has, without
adding unneeded complexity.

The whole thing is to know when to STOP!!

Constructors are an idea that looks great at first sight, but leads
to problems later.

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Also covered by C++.

This is just not true. C++ has now way within the [ ] operator
to know if its called for reading or for writing.

You see what I'm saying?

I see that you are emotionally attached to your language, and this is
not a good idea. Each argument is seen in the light of "my language
is the best". Actually you just say that C++ does it, what I am not
discussing at all. ANYTHING can be done in C++ and that is precisely
the problem!

You are going down the path of those before
you who wanted a "cleaner" C++, bit by bit you end up adding most of the
features you set out to avoid, or pay a high price in efficiency by
leaving them out.

No. Opetator overloading and generic functions are very small changes.
Constructors / destructors are a big change, that can be better solved
by a GC, as I have argued many times in this group.

Note that lcc-win32 has references too, since they are needed for
operator overloading.

 

[Ian Collins]

That adds nothing.

Well it changes the above to simply

X operator+( const X& lhs, const X& rhs ) {
return X( lhs.a+rhs.a, lhs.b+rhs.b);
}

No less or no more syntactic sugar that operator overloading offers.

That is precisely the point. The extensions were piled up without
any consideration to the consequences. The end effect was that the
language has grown SO complex that there are 2 compilers that
compile ALL of it: Edison Design Group C++ front end, and Comeau.

ALL others have still a lot of missing features. There are features of
the language still not implemented by any compiler.

You have just contradicted what you said in the previous paragraph.

Nearly all miss one feature only, which is more than can be said for C99
compilers and probably for the same reason.

Your attitude:
"It can be done more concisely by adding a constructor"
shows everything of the C++ mentality. The fact that you now
need an incredible complex machinery to do that, is just taken
for granted, doesn't matter, let's do it...

But you don't, a constructor is simply a user supplied function,
probably less complex that operator overloading.

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Also covered by C++.

This is just not true. C++ has now way within the [ ] operator
to know if its called for reading or for writing.

Oh yes it does, if you want to know how, ask on c.l.c++ or google for
proxy objects.

I see that you are emotionally attached to your language, and this is
not a good idea. Each argument is seen in the light of "my language
is the best". Actually you just say that C++ does it, what I am not
discussing at all. ANYTHING can be done in C++ and that is precisely
the problem!

Which one, C or C++? Probably both.

I can solve most hardware problems with my trusty 'scope, in the same
way as I can solve most software problems in C. But there a many
situations where a more specialised tool gets the job done quicker. I
could try an add more features to the 'scope, but then it looses its
main advantage: simplicity and portability.

 

[jacob navia]

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Also covered by C++.

This is just not true. C++ has now way within the [ ] operator
to know if its called for reading or for writing.

Oh yes it does, if you want to know how, ask on c.l.c++ or google for
proxy objects.

OK, google gives:
http://www.thescripts.com/forum/thread59882.html

<quote>
It is possible. You need some kind of proxy object that will
help to get to the element. Usually, N dimensions need N-1 proxy
objects. First [] will return proxy_1. The proxy_1 class should
have [] overloaded too, to return proxy_2, etc., until proxy_Nm1's
overloaded operator[] will return a reference.
<end quote>

This is pure C++. Complexity and complexity and complexity.

Still, how can the proxy objects know if they are in an assignment
situation or in a just read situation?

HINT: THEY CAN'T!!!

 

[Ian Collins]

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Also covered by C++.
This is just not true. C++ has now way within the [ ] operator
to know if its called for reading or for writing.

Oh yes it does, if you want to know how, ask on c.l.c++ or google for
proxy objects.

Still, how can the proxy objects know if they are in an assignment
situation or in a just read situation?

HINT: THEY CAN'T!!!

Hint - ask on c.l.c++, or find a copy of "More Effective C++" and read
Item 30.

 

[Richard Bos]

My objective is to improve the C language retaining its simplicity.

Since you have already introduced a secondary string type and a large
over-complication in the operator system, I'd say that, whatever anyone
may think about your first aim, you have already failed the second.

Richard

 

[jacob navia]

Since you have already introduced a secondary string type and a large
over-complication in the operator system, I'd say that, whatever anyone
may think about your first aim, you have already failed the second.

Richard

1) The string type uses operator overloading, and it is a demonstration
of what can be done just with operator overloading and generic
functions.

2) "Over complication of the operator system" is just an empty sentence
unless you fill it with some meaning. Care to explain what you
understand by that?

jacob

 

[¬a\\/b]

Constructors are an idea that looks great at first sight, but leads
to problems later.

Constructors are an idea that looks great at first sight, but is more
good later too

 

[Richard Bos]

1) The string type uses operator overloading, and it is a demonstration
of what can be done just with operator overloading and generic
functions.

So... yet more needless complication.

2) "Over complication of the operator system" is just an empty sentence
unless you fill it with some meaning.

No, if you don't mangle the grammar by removing the hyphen, it means
exactly what it says. Operator overloading makes the operator system
more complicated than it needs or should be. Hence, over-complication of
the operator system. That, in my book, is not simple.

Richard

 

[jacob navia]

So... yet more needless complication.

Unable to put any arguments, you just repeat yourself.

I said that it is needed because you can't create new types of numbers
in current C. See the other posts to see my arguments.

Question then:

How do you create and work with other types of numbers in C?
(extra precision, bignums, ratios, decimal representation, fixed point,
etc)

No, if you don't mangle the grammar by removing the hyphen, it means
exactly what it says. Operator overloading makes the operator system
more complicated than it needs or should be. Hence, over-complication of
the operator system. That, in my book, is not simple.

Richard

What is "more complicated" ?

Applications that do not use this feature are the same, and not
any more complicated.

Applications that DO use this feature overload the operators that they
wish to overload. The operator system remains the same. There are no new
complications, but the language is simplified, making possible to
use new kinds of numbers in C without any problems.

 

[Flash Gordon]

jacob navia wrote, On 29/08/07 16:22:

What is "more complicated" ?

Applications that do not use this feature are the same, and not
any more complicated.

Applications that DO use this feature overload the operators that they
wish to overload. The operator system remains the same. There are no new
complications, but the language is simplified, making possible to
use new kinds of numbers in C without any problems.

With you language, even if the program does not use operator overloading
you have to check the rest of the source file and all the headers it
includes to be sure that the + was actually arithmetic addition rather
than, for example, string concatenation or a set union operator (both of
which have been meanings of + in some situations). In C one knows that
the + is arithmetic addition, you just don't know the arithmetic types
involved. That is one reason why a number of people consider operator
overloading to be a complication.