Has thought been given given to a cleaned up C? Possibly called C+.

  • Thread starter Casey Hawthorne
  • Start date
C

Casey Hawthorne

Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
and I imagine others have pointed out some of C's idiosyncrasies.
Has thought been given given to a cleaned up C? Possibly called C+.
 
K

Kenny McCormack

Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
and I imagine others have pointed out some of C's idiosyncrasies.
Has thought been given given to a cleaned up C? Possibly called C+.

Even C++ is considered a "legacy language" these days.
 
W

Walter Banks

Casey said:
Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
and I imagine others have pointed out some of C's idiosyncrasies.
Has thought been given given to a cleaned up C? Possibly called C+.

Casey,

There have been many attempts to create a cleaned up C without the
idiosyncrasies. These attempts been bogged down in the sheer amount
of C code that would no longer be able to be compiled and the details
on what should be in such a language. Idiosyncrasies to one person
are essential features to someone else. The feature set of languages
tends to grow relatively easily but is difficult to shrink.

Having said that there have been several successful languages whose
roots were originally in C. The successful languages have been individual
works where the language details were resolved by a single individual
or a small group. The most successful in this group is probably Sun's java.
http://www.java.com/en/

It is probably too soon to predict the success or not of Google Go.
http://mashable.com/2009/11/10/go-google-language/



Regards

Walter..
 
J

jacob navia

Casey Hawthorne a écrit :
Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
and I imagine others have pointed out some of C's idiosyncrasies.
Has thought been given given to a cleaned up C? Possibly called C+.

The compiler system lcc-win has tried to do exactly that, i.e. to
develop a cleaner version of C.

It introduces as enhancements, compatible with standard C, the following
features:

o Operator overloading. This allows the user to define new types of
numbers, and allows easy access to counted string and arrays,
enhancing the security of user code.
Lcc-win features in its standard distribution 352 bit floating point
with 100+ digits precision. Bignums are also included. Complex numbers
are implemented using operator overloading.

o Generic functions: This allows a limited form of generic programming

o Default arguments

o A garbage collector that is included in the standard distribution.

o References. This are pointers that always point to the same object and
can never be NULL.


Using the above features lcc-win presents a string library for instance,
that uses counted strings. The whole C string library has been rewritten
this way. (strcat is Strcat, strcmp is Strcmp, etc). Source code is
distributed with the lcc-win distribution


This effort can be downloaded at no cost from

http://www.q-software-solutions.de

jacob
 
J

Julienne Walker

Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
and I imagine others have pointed out some of C's idiosyncrasies.
Has thought been given given to a cleaned up C?

The most recent attempt at taking what C is good at and removing what
it's bad at is called Go.
 
J

jacob navia

Casey Hawthorne a écrit :
> Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
> and I imagine others have pointed out some of C's idiosyncrasies.
> Has thought been given given to a cleaned up C? Possibly called C+.
> --
> Regards,
> Casey

The compiler system lcc-win has tried to do exactly that, i.e. to
develop a cleaner version of C.

It introduces as enhancements, compatible with standard C, the following
features:

o Operator overloading. This allows the user to define new types of
numbers, and allows easy access to counted string and arrays,
enhancing the security of user code.
Lcc-win features in its standard distribution 352 bit floating point
with 100+ digits precision. Bignums are also included. Complex numbers
are implemented using operator overloading.

o Generic functions: This allows a limited form of generic programming

o Default arguments

o A garbage collector that is included in the standard distribution.

o References. This are pointers that always point to the same object and
can never be NULL.


Using the above features lcc-win presents a string library for instance,
that uses counted strings. The whole C string library has been rewritten
this way. (strcat is Strcat, strcmp is Strcmp, etc). Source code is
distributed with the lcc-win distribution


This effort can be downloaded at no cost from

http://www.q-software-solutions.de

jacob
 
I

Ian Collins

jacob said:
Casey Hawthorne a écrit :

The compiler system lcc-win has tried to do exactly that, i.e. to
develop a cleaner version of C.

It introduces as enhancements, compatible with standard C, the following
features:

So it enhances rather than attempting to clean up the grubby corners of
the language. C++ suffers the same baggage - compatible with standard C.
 
J

jacob navia

Ian Collins a écrit :
So it enhances rather than attempting to clean up the grubby corners of
the language. C++ suffers the same baggage - compatible with standard C.

I have tried since ten years to get rid of many horrible constructs,
both in this group and in comp.lang.c.

The two strongest "campaigns" that I did were against
gets() and against the buffer overflow in asctime().

I do not know if the committee decided to get rid of gets() and fix
the overflow in asctime() because of my continuous complaints but I
am sure that I contributed to those small improvements.

The problem is that the view that C should be improved and should
evolve is not shared by the people in the ISO committee. Apparently
they do not want to change anything for the next edition of the
standard and leave the language as it is until 2020-2030.

jacob
 
S

Seebs

The problem is that the view that C should be improved and should
evolve is not shared by the people in the ISO committee.

Could you offer some kind of support for this? I've seen several committee
members advocating for various changes.

I would agree that many of them do not agree with you about WHICH changes
are good, but it seems pretty clear that most of the people who have been
involved with C standardizations have been very interested in seeing SOME
kind of changes.

Furthermore, I find it incomprehensible that you wouldn't know this, given
prior conversations in which multiple examples of this were given.

-s
 
R

Rob Kendrick

So it enhances rather than attempting to clean up the grubby corners
of the language. C++ suffers the same baggage - compatible with
standard C.

Of course, C++ isn't compatible with standard C. If you think it is,
try giving this to a C++ compiler:

int foo(void) { auto new = 0; return new; }

B.
 
K

Keith Thompson

jacob navia said:
I have tried since ten years to get rid of many horrible constructs,
both in this group and in comp.lang.c.

The two strongest "campaigns" that I did were against
gets() and against the buffer overflow in asctime().

I do not know if the committee decided to get rid of gets() and fix
the overflow in asctime() because of my continuous complaints but I
am sure that I contributed to those small improvements.

The committee didn't fix the overflow in asctime(), they merely
documented it; in fact, its behavior is undefined in some cases
where it's well defined in C99. (I have no problem with what they've
done, I just don't think it should be misrepresented.)
The problem is that the view that C should be improved and should
evolve is not shared by the people in the ISO committee. Apparently
they do not want to change anything for the next edition of the
standard and leave the language as it is until 2020-2030.

That's simply untrue. See
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1425.pdf>, the
latest (?) C201X draft. Adding threading and Unicode support to
the standard library is hardly an indication that they don't want to
change anything. And of course it's a work in progress; if a feature
doesn't appear in N1425, that doesn't mean it won't be in C201X.
 
C

Curtis Dyer

Ian Collins a écrit :

The problem is that the view that C should be improved and
should evolve is not shared by the people in the ISO committee.
Apparently they do not want to change anything for the next
edition of the standard and leave the language as it is until
2020-2030.

This doesn't seem to be at all the case. If you take a look at the
N1425 draft, you'll see there are many significant changes,
including the support for threading.
 
S

Stefan Ram

Casey Hawthorne said:
Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
and I imagine others have pointed out some of C's idiosyncrasies.
Has thought been given given to a cleaned up C? Possibly called C+.

One might say that C already is a cleaned-up C++.

But see also:

»Cyclone: A Type-Safe Dialect of C«

http://www.drdobbs.com/article/printableArticle.jhtml?articleID=184401896
http://www.cs.umd.edu/~mwh/papers/cyclone-cuj.pdf

»C formalised in HOL«

http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-453.pdf
 
J

jacob navia

Stefan Ram a écrit :
One might say that C already is a cleaned-up C++.

But see also:

»Cyclone: A Type-Safe Dialect of C«

http://www.drdobbs.com/article/printableArticle.jhtml?articleID=184401896
http://www.cs.umd.edu/~mwh/papers/cyclone-cuj.pdf

»C formalised in HOL«

http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-453.pdf

Yes cyclone has interesting features. For instance fat pointers
handling size information.

In lcc-win this can be done with the operator overloading feature.
For instance, in the rewrite of the C standard library, functions
that return a pointer like strstr return a structure with an index
(the position where the pointer points) and a pointer (thin of course)
to the original object where the accessor can lookup the information

Since pointer + integer yields a pointer in C, operator overloading
is used to accept those features and at the same time verify that
the pointer is not pushed beyond its limits.

The @notnull cyclone qualifier is realized with references, that can't
be NULL and can't point to anything else but the object they were
initialized to.

As cyclone, lcc-win supports exceptions (__try construct) and
generic functions.

Other features are of doubtful utility: name spaces are a failure in C++
ànd I do not see how this could be different in other languages.

Most programs in C++ start with

using namespace std;

nullifying the advantages of namespaces. I do not see what
REAL utility namespaces could bring, but maybe you can enlighten
me.

The problem of memory allocation and all errors that are
associated is solved with the garbage collector in lcc-win.

Well, "solved" is maybe not the right word. Other problems arise
when you use a gc,there is no free lunch...
 
J

jacob navia

Rob Kendrick a écrit :
Of course, C++ isn't compatible with standard C. If you think it is,
try giving this to a C++ compiler:

int foo(void) { auto new = 0; return new; }

B.

`Well, to deduce from this that C and C++ are "not compatible" is just
nonsense.

Yes, C++ has new (pun intended) keywords. If you avoid those
pitfalls they are compatible. Yes, there are other minor details
like that but I have never found a show stopper.
 
J

jacob navia

Curtis Dyer a écrit :
This doesn't seem to be at all the case. If you take a look at the
N1425 draft, you'll see there are many significant changes,
including the support for threading.

I posted an article about the threading proposal in comp.std.c.

It is basically the documentation of a threading library of
Plauger.

Yes, it is a good idea, but there are still thousands of things to do
first.

o The library is an unchanged copy of the C library of 1980. Using
the same software today after 30 years of development (and what a
development) in this field is plain nonsense. Many proposals have
been done to update the C library, specifically to correct the obvious
lack of security and error handling. Yes, the committee got rid of
gets() (could have been done in 1999) and acknowledged the buffer
overflow in the asctime() code, but still, there are a LOT of
functions in the standard library, specially the string handling
functions that are plainly WRONG...

How can we keep strtok and be multi-threading at the same time?

I did not see any update for multi-threading in the fopen/fclose
and all the functions of the standard library.

o There is no standard way of making a list/a tree/ a flexible array/
in C. Everything must be ported, recompiled, etc. I am working in
a proposalfor this, but apparently the committee will decide a
feature freeze next meeting, so I will have to wait till 2020
at least.

o I would like to know what is a "significant change" in the proposal.
I have seen a few detail changes but really nothing significant.
I could be wrong of course.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,754
Messages
2,569,521
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top