R
Roland Pibinger
If you understood the C philosophy you'd see that C needs no 'next
standard'.
If you understood the C philosophy you'd see that C needs no 'next
standard'.
J
jacob navia
Roland Pibinger a écrit :
This is wrong. Completely wrong.
Everything evolves. The only things that do not evolve
any more are corpses: dead things.
I am of the opposite view. C needs to evolve to be able to
offer a slimpler interface than now.
In the link provided there was the famous KISS principle in
the first page.
But simple for who?
Simple for the compiler writer or simple for the user?
We know now where the C++ way leads. But this doesn't mean
that everything in that way is bad. It is like milk.
If you dring 10 liters of milk in a few minutes you die.
Does this mean that mil is inherently dangerous?
It is a matter of measure.
I have tried to introduce in the lcc-win32 compiler system
some advances that would have far reaching consequences
without adding any complexity neither to the compiler
(500 lines) nor to the language in general. But they would
simplify enormously the usage of the language.
This extensions are:
o Operator overloading
o generic functions
And that was it. Nothing else.
This allows to write container libraries in a very simple way, and above
all to get rid of the zero terminated strings, one of the big BUGS in C.
This is wrong. Completely wrong.
Everything evolves. The only things that do not evolve
any more are corpses: dead things.
I am of the opposite view. C needs to evolve to be able to
offer a slimpler interface than now.
In the link provided there was the famous KISS principle in
the first page.
But simple for who?
Simple for the compiler writer or simple for the user?
We know now where the C++ way leads. But this doesn't mean
that everything in that way is bad. It is like milk.
If you dring 10 liters of milk in a few minutes you die.
Does this mean that mil is inherently dangerous?
It is a matter of measure.
I have tried to introduce in the lcc-win32 compiler system
some advances that would have far reaching consequences
without adding any complexity neither to the compiler
(500 lines) nor to the language in general. But they would
simplify enormously the usage of the language.
This extensions are:
o Operator overloading
o generic functions
And that was it. Nothing else.
This allows to write container libraries in a very simple way, and above
all to get rid of the zero terminated strings, one of the big BUGS in C.
I
Ian Collins
Roland said:
Don't forget the distinction between the language and the standard library.
R
Richard Heathfield
jacob navia said:
So you say. Whether or not that is so, it is certainly true that, of those
things that do evolve, some evolve in dead-end directions.
Wrong. Living things don't evolve. Species evolve. Species are not living
things. They are classes of living things.
It's already about as simple as it can get, isn't it?
Operator overloading would enormously complicate the usage of the language.
At the moment, + means + and - means - and that's an end of it. Operator
overloading (other than the very primitive form that is already built into
the arithmetic operators for handling integer, floating-point, and pointer
types) would make it much more difficult to read and maintain programs, as
C++ has demonstrated amply.
No matter how often you call null-terminated strings a bug, the fact remains
that they were a conscious design decision that has, at the very least, the
merit of simplicity.
So you say. Whether or not that is so, it is certainly true that, of those
things that do evolve, some evolve in dead-end directions.
Wrong. Living things don't evolve. Species evolve. Species are not living
things. They are classes of living things.
It's already about as simple as it can get, isn't it?
Operator overloading would enormously complicate the usage of the language.
At the moment, + means + and - means - and that's an end of it. Operator
overloading (other than the very primitive form that is already built into
the arithmetic operators for handling integer, floating-point, and pointer
types) would make it much more difficult to read and maintain programs, as
C++ has demonstrated amply.
No matter how often you call null-terminated strings a bug, the fact remains
that they were a conscious design decision that has, at the very least, the
merit of simplicity.
I
Ian Collins
jacob said:
How can a language without objects support operator overloading?
Which leads to function overloading and breaks compatibility with
standard C linkage.
If you want these features, use C++ which is way more portable.
J
jacob navia
Ian Collins a écrit :
Very easy:
typedef struct ComplexInteger { int re; int imag; } COMPLEX_INTEGER;
COMPLEX_INTEGER operator+(COMPLEX_INTEGER x, COMPLEX_INTEGER y)
{
COMPLEX_INTEGER result;
result.re = x.re+y.re;
result.im = x.im+y.imm;
return result;
}
Operator overloading has nothing to do with object oriented programming.
C is not object oriented, hence here things are much easier than in C++.
That could be avoided if there is a standard name mangling schema.
If you want milk you should drink immediately 10 liters
Very easy:
typedef struct ComplexInteger { int re; int imag; } COMPLEX_INTEGER;
COMPLEX_INTEGER operator+(COMPLEX_INTEGER x, COMPLEX_INTEGER y)
{
COMPLEX_INTEGER result;
result.re = x.re+y.re;
result.im = x.im+y.imm;
return result;
}
Operator overloading has nothing to do with object oriented programming.
C is not object oriented, hence here things are much easier than in C++.
That could be avoided if there is a standard name mangling schema.
If you want milk you should drink immediately 10 liters
J
jacob navia
Richard Heathfield a écrit :
Suppose you have a special numeric data type, say the decimal
data type.
Now, you have to write for
c = ( (a+b)*(d-5) )/(b*a);
c=divide(multiply(add(a,b),subtract(d,NewDecimal(5))),multiply(b,a)):
Of course the second form is easier to maintain.
Operator overloading makes defining new numeric data types
easy.
Besides it allows the construction of generric containers using the
array notation.
Suppose you have a special numeric data type, say the decimal
data type.
Now, you have to write for
c = ( (a+b)*(d-5) )/(b*a);
c=divide(multiply(add(a,b),subtract(d,NewDecimal(5))),multiply(b,a)):
Of course the second form is easier to maintain.
Operator overloading makes defining new numeric data types
easy.
Besides it allows the construction of generric containers using the
array notation.
I
Ian Collins
Fair enough for a simple example,but what happens when the sruct is morejacob said:
complex and or contains pointers? You are stuck with C's copy semantics
unless you introduce pass by reference. My main point is you are
starting down the same road C with classes did a couple of decades ago.
Which would have to be introduced before vendors started to define their
own.
Sip, don't gulp!
M
Mark McIntyre
For reference, what you've done here is create an object. A simple
one, but still an object.
Indeed. However Ian didn't say "without object oriented programming".
Its commonplace to confuse the two, I admit.
The point is that C does support the creation of objects (eg 6.2.4).
What it doesn't support is operator overloading, so what lcc-win32
does is extend the language by allowing you to define an operator for
an object. I have no problem with this, but of course its offtopic
here.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
J
jacob navia
Ian Collins a écrit :
Who cares? Pointers are pointers. What's wrong with that?
This is not absolutely necessary. It is slightly less
"efficient" but it works well for small structures.
There are operations that are defined for pointers.
For instance if you wanted to define:
COMPLEX_INTEGER operator+(COMPLEX_INTEGER *x, int y);
This will not work since addition of pointer + integer is
already defined. That is why is better to abstain from
using pointers in this context.
Yes. It is not C++. You can't do EVERYTHING.
When you drink one cup of milk this doesn't mean you
will not stop until you drink 10 liters and you die!
But yes, when you drink a cup of milk you are starting
a road that *could* lead you to drink 10 liters and die.
You have to know when to stop.
The basic error of C++ is that they did not see when it is
the time to STOP!
Who cares? Pointers are pointers. What's wrong with that?
This is not absolutely necessary. It is slightly less
"efficient" but it works well for small structures.
There are operations that are defined for pointers.
For instance if you wanted to define:
COMPLEX_INTEGER operator+(COMPLEX_INTEGER *x, int y);
This will not work since addition of pointer + integer is
already defined. That is why is better to abstain from
using pointers in this context.
Yes. It is not C++. You can't do EVERYTHING.
When you drink one cup of milk this doesn't mean you
will not stop until you drink 10 liters and you die!
But yes, when you drink a cup of milk you are starting
a road that *could* lead you to drink 10 liters and die.
You have to know when to stop.
The basic error of C++ is that they did not see when it is
the time to STOP!
J
jacob navia
Mark McIntyre a écrit :
Of course. But there are no classes, no inheritance, no complications.
This is an object in the C sense: transparent, without any added
constructors, destructors, whatever.
I think C must remain at this level. By introducing operator overloading
(something Fortran 90 supports also for instance) the language remains
simple as it is now, albeit with more expressivity (I hope this is
the right word )
Of course C has "objects" but I thought Ian spoke about
objects in the sense of class hierarchy, etc.
Of course. But there are no classes, no inheritance, no complications.
This is an object in the C sense: transparent, without any added
constructors, destructors, whatever.
I think C must remain at this level. By introducing operator overloading
(something Fortran 90 supports also for instance) the language remains
simple as it is now, albeit with more expressivity (I hope this is
the right word )
Of course C has "objects" but I thought Ian spoke about
objects in the sense of class hierarchy, etc.
I
Ian Collins
So you are restricting your operator to small structures?jacob said:
You continue to miss or ignore the point that one doesn't have to use
the entire 10 litres, one can dip in and used as much or as little as
one pleases.
I
Ian Collins
Interesting, so you advocate extending the language with something thatjacob said:
boils down to syntactic sugar while dismissing the one feature
(constructors and destructors) that enables C++ to what C can't (RAII).
C
Chris Dollin
Ian said:
Just because it doesn't have objects (and so, presumably, classes)
doesn't mean it hasn't got types.
I don't see why, for example, one couldn't add operator overloading
to (traditional) Pascal.
I can't remember off-hand whether Algol68 has (user-definable)
operator overloading, but it certainly has user-defined operators
and no classes.
Isn't this increasingly off-topic?
C
Chris Dollin
Mark said:
No: he's created a /type/. Instances of that type are the things
you want to call "objects".
Don't fall into the trap of conflating the notion of "object" as it
is found in those languages often termed "object-oriented" with the
notion of "object" used in C. The former is much richer, whether or
not, like mince pies and apple crumble, it is to your taste.
S
santosh
Roland said:
Boost is a collection of useful algorithms. Are you saying that C
doesn't need, or wouldn't find useful, a collection of useful
algorithms? That Boost is implemented in the form of C++ templates is
irrelevant to it's proposed C counterpart.
As far as I know, C, (and K&R), popularised structured programming. How
would a library of commonly used algorithms and data structures in C,
go against the spirit of simplicity and structured programming?
<snip>
It's called evolution. Just like biological organisms, many other human
artifacts tend to differentiate over time to fill various available
niches. And just like for biological species, differentiation leads
eventually to speceiation.
S
santosh
Roland said:
The C and UNIX philosophy don't discourage standardisation of common
practises, and even if they do, in the end, popular demand will tip the
scales.
The C90 standard was the result of a strongly felt need for
standardisation of the then existing common practises of C. Why do you
say that it shouldn't happen again?
J
jacob navia
Ian said:
Look, C is just syntactic sugar for assembly, as all other
computer languages.
Why constructors/destructors are unnecessary?
--------------------------------------------
Because a constructor can be called, when needed, by the
programmer at the initiliazation of the object being created.
int fn(void)
{
SomeType s = CreateSomeType("Name",10.7);
// use some type
DestroySomeType(s);
}
This means that the incredible inefficiency of having a function call
for each object creation can be avoided if you wish. It means that
the complexity in the compiler that needs to figure out if the
constructor is a "trivial" one and can be optimized away can be avoided
too.
You will immediately cry:
"But the freeing of the object is very error prone"
"You will end with a memory leak"
Within lcc-win32 I have developed a better solution: a GARBAGE
COLLECTOR, that frees you from all the destructor/freeing memory
woes.
Of course that is NOT the only solution, since in an embedded system it
is better to manually create and destroy objects when memory is scarce.
No GC there, because it is an optional solution, not one that the
language FORCES you down your throat if you want it or not!
One of the worst features of C++ is precisely the constructors /
destructors stuff. Since there is no GC, you have to have exception
handling to destroy the objects that are out of scope when throwing
an exception. None of this is needed in the schema proposed in
lcc-win32: the GC takes care of that without any extra overhead.
J
jacob navia
Chris said:
Exactly. Operations on types can be redefined by the user
using the operator notation. That is all. It is a convenient notation,
and doesn't make C any different since the core of the language concepts
remains the same.
The topic is C, and its possible extensions in libraries like "Boost".
In that context, we came as to how write those libraries in C, and
I started this sub-sub thread about overloading because I think it
simplifies the language.
jacob
R
Richard Heathfield
jacob navia said:
No, the topic is C, full stop. If you wish to discuss proposed changes to
the language, the place to do that is comp.std.c, and *not* comp.lang.c,
which deals with C as it is *now*.
C, as it is now, does not include garbage or operator overloading.
No, the topic is C, full stop. If you wish to discuss proposed changes to
the language, the place to do that is comp.std.c, and *not* comp.lang.c,
which deals with C as it is *now*.
C, as it is now, does not include garbage or operator overloading.