Has thought been given given to a cleaned up C? Possibly called C+.
Casey Hawthorne
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
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Richard Heathfield
> 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+.
According to Stroustrup [TC++PL, intro], the name "C+" has already been
taken, by a language unrelated to either C or C++.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Kenny McCormack
Casey Hawthorne <caseyhHA...@istar.ca> wrote:
>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.
Walter Banks
> 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..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
jacob navia
> 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
Julienne Walker
wrote:
> 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.
jacob navia
> 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
Ian Collins
> 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:
So it enhances rather than attempting to clean up the grubby corners of
the language. C++ suffers the same baggage - compatible with standard C.
--
Ian Collins
Richard Harter
<happy...@hotmail.com> wrote:
>On Mar 5, 12:56=A0pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca>
>wrote:
>> 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.
Unfortunately it has serious flaws along with the virtues.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.
jacob navia
> jacob navia wrote:
>> 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:
>
> 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
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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Rob Kendrick
Ian Collins <ian-...@hotmail.com> wrote:
> 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.
Julienne Walker
> On Fri, 5 Mar 2010 15:32:23 -0600 (CST), Julienne Walker
>
> >On Mar 5, 12:56=A0pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca>
> >wrote:
> >> 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.
>
> Unfortunately it has serious flaws along with the virtues.
That's how it usually turns out.
Keith Thompson
[...]
> 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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Curtis Dyer
> Ian Collins a �crit :
>> jacob navia wrote:
>>> Casey Hawthorne a �crit :
<snip>
> 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.
--
"Don't worry about efficiency until you've attained correctness."
- Eric Sosman, clc
jacob navia
> Casey Hawthorne <caseyhHA...@istar.ca> writes:
>> 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+.
>
>
> 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...
Marco
> On Fri, 5 Mar 2010 15:32:23 -0600 (CST), Julienne Walker
> >The most recent attempt at taking what C is good at and removing what
> >it's bad at is called Go.
>
> Unfortunately it has serious flaws along with the virtues.
Could you expound upon those flaws - better to use comp.lang.misc
for that topic
Marco
wrote:
> 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+.
a cleaned up C++ called D is of interest:
jacob navia
> On Fri, 5 Mar 2010 15:32:23 -0600 (CST), Julienne Walker
> <happy...@hotmail.com> wrote:
>
>> On Mar 5, 12:56=A0pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca>
>> wrote:
>>> 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.
>
> Unfortunately it has serious flaws along with the virtues.
>
>
Care to explain?
Which virtues?
Which flaws?
Thanks
jacob navia
> On Fri, 5 Mar 2010 15:52:17 -0600 (CST)
> Ian Collins <ian-...@hotmail.com> wrote:
>
>> 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.
`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.
jacob navia
>>> jacob navia wrote:
>>>> Casey Hawthorne a écrit :
>
> <snip>
>
>> 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.
>
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.
Thomas Richter
>> 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.
The actual function calls in the library are probably the most harmless
part of threading support.
> 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.
Given the amount of existing code that builds on the existing C library,
replacing it is actually 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...
I don't think they're wrong. They require care, care some people forgot.
As for example checking for the proper buffer size. A "strcpy" can be
absolutely correct if you have control on the size of the input string,
and it can be completely fatal if not. If you want to avoid the hassle,
go for C++, or use the limiting functions. "strncpy" is, however, indeed
broken, but it is too late to fix it. There is "strncpy_s" to address this.
> How can we keep strtok and be multi-threading at the same time?
You can't. You use strtok_s for that. Breaking *existing* code is *not*
an option.
> I did not see any update for multi-threading in the fopen/fclose
> and all the functions of the standard library.
Why has fopen() a multithreading issue? It only has if the
implementation is broken???
> 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.
Why should there? C is a very small language, and I really don't see the
need for such simple data structures in the standard. If you need
library support for that, and a richer structure that helps you with
such containers, use C++ and the STL. This is what it has been designed for.
So long,
Thomas
Richard Bos
> On 2010-03-06, jacob navia <ja...@jacob.remcomp.fr> wrote:
> > 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/incom/re/, and s/n't/ pretend not to/, IYAM.
Richard
jacob navia
> jacob navia wrote:
>> 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.
>
> Given the amount of existing code that builds on the existing C library,
> replacing it is actually plain nonsense.
>
Nobody is proposing that. This is an old trick in this discussions. Any
improvement to C is impossible because the old code. That is plainly not
true. The old code and the associated functions can be kept, but C
should be able to use BUFFERS of KNOWN length, avoiding the most common
cause of buffer overflows. Let's be explicit:
typedef struct {size_t length; char data[];} Buffer;
memset can be done as "Memset", for instance like this
bool Memset(Buffer *dest, int char_val);
where:
The result is zero if buffer is NULL, 1 if buffer is not null.
This is an easy example. Strcpy is just as trivial, but with a character
buffer.
Giving a similar but different name easies the porting and is compatible
with old code.
Why argument with flawed arguments? I DID tell jun my message that I
renamed the string functions Strcpy for instance. Why arguing that I
`want to "replace" strcpy"? Of course I want to replace the
functionality, making it less error prone, but not the function.
>> 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...
>
> I don't think they're wrong. They require care, care some people forgot.
This has been discussed and discussed, and the essential point is that
if somebody makes a mistaken once, it is his/her fault. Ifvthousands of
programmers make always the same errors it is the tool's fault. In this
group, r Heathfield, an experienced C programmer had to acknowledge
that his published code had a BUG in his code handling string data.
And Mr Heathfield has been somebody that ALWAYS sys exactly the same as
you now. "You have to be careful" etc. But he himself was proved wrong.
I am sure you can be proved wrong too.
> As for example checking for the proper buffer size. A "strcpy" can be
> absolutely correct if you have control on the size of the input string,
> and it can be completely fatal if not.
Exactly. A better version would use COUNTED buffers!
> If you want to avoid the hassle,
> go for C++, or use the limiting functions.
Here we have it again. Any development of C is always answered with
"Go to C++" even by committee members. C should remain full of warts
so that C++ can be seen as the only alternative. There should be NO
simpler language than C++, all development of C as a language should
STOP.
You are confirming what I say about committee members.
{snip}
>
>> 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.
>
> Why should there? C is a very small language, and I really don't see the
> need for such simple data structures in the standard.
Then, each C programmer needs to port a library that does lists,
flexible arrays, or find and debug one and port it, etc.
> If you need
> library support for that, and a richer structure that helps you with
> such containers, use C++ and the STL.
OF COURSE that is the solution. Yu are (again) confirming what I said:
All development in C should stop and we should swallow C++ if we want to
do the simplest tasks!
If we want to use (portably) a list, we are forced to use C++ and
their STL...
> This is what it has been designed
> for.
>
C is still being used, and many important projects are based on it. My
thesis is that a simple language is necessary and useful. Adding
a general and extensible container interface for C doesn't change at all
the language but gives C programmer the advantages of not having to
program the same data structures over and over.
The proliferation of libraries that do the same thing WITHOUT a standard
in C means that each big project in C has several versions of the same
data structure because library XYZ uses lists with the "Next" field
in the fiorst position and library"XXX" uses a list with Next in the
second position. Besides all APIs are different, etc.
This is SO OBVIOUS that doesn't even need to be discussed. But C should
be kept in its present state so taht the only alternative is to swallow
C++
Well, you confirm everything that I said.
Nick Keighley
> Rob Kendrick a écrit :
>
> > On Fri, 5 Mar 2010 15:52:17 -0600 (CST)
> > Ian Collins <ian-n...@hotmail.com> wrote:
>
> >> 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; }
>
> 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.
quite correct. This harping on about keywords is just silly. You can
write code that compiles with both and a C compiler and a C++
compiler. And it isn't that hard.
bartc
news:clcm-2010...@plethora.net...
> Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
> and I imagine others have pointed out some of C's idiosyncrasies.
That's exactly what I was thinking, when I first looked at using C around
'92**. Surely someone would have got round to tidying up the language by
then?
But people who use C seem to love it exactly the way it is.
And I'd imagine any replacement language created now, especially by
committee. would have it's own difficulties.
(** As it happened, I chose to develop my own language instead (it was
easier...). Creating a language that does pretty much what C does, is not
that difficult, more of a student exercise. However you then have to work
with something that is not mainstream and not compatible with anything else.
And that needs maintaining.)
--
Bartc
Richard Harter
<prenom...@yahoo.com> wrote:
>On Mar 5, 5:00=A0pm, c...@tiac.net (Richard Harter) wrote:
>> On Fri, 5 Mar 2010 15:32:23 -0600 (CST), Julienne Walker
>
>> >The most recent attempt at taking what C is good at and removing what
>> >it's bad at is called Go.
>>
>> Unfortunately it has serious flaws along with the virtues.
>
> Could you expound upon those flaws - better to use comp.lang.misc
>for that topic
I can and will, but it may be a few days. My major complaint
would be with their approach to concurrency.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.
Ian Collins
>
> C is still being used, and many important projects are based on it. My
> thesis is that a simple language is necessary and useful. Adding
> a general and extensible container interface for C doesn't change at all
> the language but gives C programmer the advantages of not having to
> program the same data structures over and over.
>
> The proliferation of libraries that do the same thing WITHOUT a standard
> in C means that each big project in C has several versions of the same
> data structure because library XYZ uses lists with the "Next" field
> in the fiorst position and library"XXX" uses a list with Next in the
> second position. Besides all APIs are different, etc.
One interesting question is why, after over 30 years of use, there
hasn't appeared a widely accepted a general and extensible container
interface for C?
The C++ STL appeared fairly early on in that language's evolution and
was rapidly and widely accepted by C++ developers. The widespread use
resulted in it being incorporated into the standard library in first
language standard.
Why hasn't the same thing happened with C?
--
Ian Collins
Thomas Richter
> Thomas Richter a �crit :
>> jacob navia wrote:
>>> 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.
>>
>> Given the amount of existing code that builds on the existing C
>> library, replacing it is actually plain nonsense.
>>
>
> Nobody is proposing that. This is an old trick in this discussions. Any
> improvement to C is impossible because the old code. That is plainly not
> true. The old code and the associated functions can be kept, but C
> should be able to use BUFFERS of KNOWN length, avoiding the most common
> cause of buffer overflows. Let's be explicit:
>
> typedef struct {size_t length; char data[];} Buffer;
>
> memset can be done as "Memset", for instance like this
> bool Memset(Buffer *dest, int char_val);
memset already takes a byte count argument, why do I need another
function? In fact, memset is as safe as it gets.
> This is an easy example. Strcpy is just as trivial, but with a character
> buffer.
There is already a secure version of strcpy, see below.
>> I don't think they're wrong. They require care, care some people forgot.
>
> This has been discussed and discussed, and the essential point is that
> if somebody makes a mistaken once, it is his/her fault. Ifvthousands of
> programmers make always the same errors it is the tool's fault.
Then C is not the right tool for the job. As said below, there are other
languages that can help. If you want to use C, there are also secured
functions with buffer sizes that help. But even they won't prevent you
from shooting yourself into the foot. C has no means to prevent bad
pointers being dereferences, to give another example. If you want a
child-proof C, use Java - it does have all the features you seem to
miss. (And no, I've absolutely nothing against Java, no irony here.)
> I am sure you can be proved wrong too.
Of course I make mistakes, who wouldn't? And your point is? Again, if
"avoiding errors" is your concern, use another tool and make other
errors. Just that languages like java or C++ are neither the right tool
for *some* jobs.
>> As for example checking for the proper buffer size. A "strcpy" can be
>> absolutely correct if you have control on the size of the input
>> string, and it can be completely fatal if not.
>
> Exactly. A better version would use COUNTED buffers!
There is a version, so use it. I don't understand your complaint. If I
use strcpy, then under controlled conditions where I do have control on
the input and the output buffer, as in allocating the output buffer from
the size of the input.
The problem is not strcpy, the problem is that C "string handling" is
considerably broken - for security aspects, but also for all kind of
string handling. It is just too low level. I don't have a problem with
that - if I do need to do massive string handling, I use other languages.
>> If you want to avoid the hassle, go for C++, or use the limiting
>> functions.
>
> Here we have it again. Any development of C is always answered with
> "Go to C++" even by committee members. C should remain full of warts
> so that C++ can be seen as the only alternative. There should be NO
> simpler language than C++, all development of C as a language should
> STOP.
If you want ultimate security, *DO NOT USE C*. It is not the language
for that job. It is a low-level language. Buffer overruns are just *one*
of the problems of C. Pointers are another. Should we ban pointers from
C just because they can be used for dangerous tasks?
> You are confirming what I say about committee members.
You don't understand the most basic rule: Use the right tool for the job.
>> Why should there? C is a very small language, and I really don't see
>> the need for such simple data structures in the standard.
>
> Then, each C programmer needs to port a library that does lists,
> flexible arrays, or find and debug one and port it, etc.
No, the programmer would rather need to look for a better tool for the
job. Writing pograms in C just to use C is a bad idea. Use a language
that offers such functionalities if you need them. Or use readily
available libraries if you want to - I'm sure you'd find plenty.
>> If you need library support for that, and a richer structure that
>> helps you with such containers, use C++ and the STL.
>
> OF COURSE that is the solution.
Then where is the damn problem?
> Yu are (again) confirming what I said:
> All development in C should stop and we should swallow C++ if we want to
> do the simplest tasks!
And why is that a problem?
> If we want to use (portably) a list, we are forced to use C++ and
> their STL...
Or any other language that offers that. Java, python, ....
I still don't see the problem.
> C is still being used, and many important projects are based on it. My
> thesis is that a simple language is necessary and useful.
Then keep it simple. If writing a list or a tree is not simple for you,
you are in the wrong field for applying C for that task. Or look for a
library that helps you. C is a small language; why whould that stuff be
required in the language core - it would often not fit into the
application because C doesn't have all the mechanisms of higher
languages to hide the implementation behind the design.
> This is SO OBVIOUS that doesn't even need to be discussed. But C should
> be kept in its present state so taht the only alternative is to swallow
> C++
It's obvious that you want to use C just for the means of it. Get over
it, C is not the "saves all my problems" language. It is good in some
cases, and bad in others. String manipulation and generic container
support are not the strong parts of C, so why force it? If you want to
make C another language, I again ask why. There *are* already other
languages in first place you can use.
Greetings,
Thomas
jacob navia
> Then C is not the right tool for the job. As said below, there are other
> languages that can help.
[snip]
> Again, if
> "avoiding errors" is your concern, use another tool and make other
> errors.
[snip]
> The problem is not strcpy, the problem is that C "string handling" is
> considerably broken - for security aspects, but also for all kind of
> string handling. It is just too low level. I don't have a problem with
> that - if I do need to do massive string handling, I use other languages.
>
[snip]
>
> If you want ultimate security, *DO NOT USE C*. It is not the language
> for that job. such simple data structures in the standard.
>>
>> Then, each C programmer needs to port a library that does lists,
>> flexible arrays, or find and debug one and port it, etc.
>
> No, the programmer would rather need to look for a better tool for the
> job. Writing pograms in C just to use C is a bad idea. Use a language
> that offers such functionalities if you need them.
>>> If you need library support for that, and a richer structure that
>>> helps you with such containers, use C++ and the STL.
>>
>> OF COURSE that is the solution.
>
> Then where is the damn problem?
>
>> Yu are (again) confirming what I said:
>> All development in C should stop and we should swallow C++ if we want to
>> do the simplest tasks!
>
> And why is that a problem?
>
[snip]
>
> I still don't see the problem.
>
>
>> This is SO OBVIOUS that doesn't even need to be discussed. But C should
>> be kept in its present state so taht the only alternative is to swallow
>> C++
>
> It's obvious that you want to use C just for the means of it. Get over
> it, C is not the "saves all my problems" language. It is good in some
> cases, and bad in others. String manipulation and generic container
> support are not the strong parts of C, so why force it? If you want to
> make C another language, I again ask why. There *are* already other
> languages in first place you can use.
>
There is no point in discussing with you
Let's agree that we disagree, and go on using your pet language,
whatever that is.
My opinion is that C should be developed further, exactly BECAUSE is
a simple language. Adding a container library to C doesn't make the
language any bigger or more complicated but makes programs COMPATIBLE
because it is possible to interchange data with standard API/containers.
There is no way in C to return a list of the files in a directory. Nor
there is a standard way to return a flexible array, or similar
containers.
I have been developing a library like that, that is extensible and
patterned after the STL.The only difference is that is way faster and
smaller than the STL. I see that the C++ people will start crying that
that is an heresy of course.
You (and the other C++ avocates here) seem to believe that complexity is
better in sofwtare construction. My thesisis the opposite. I believe
that a simple language is better than a completely bloated like C++.
jacob navia
> jacob navia wrote:
>
> One interesting question is why, after over 30 years of use, there
> hasn't appeared a widely accepted a general and extensible container
> interface for C?
>
> The C++ STL appeared fairly early on in that language's evolution and
> was rapidly and widely accepted by C++ developers. The widespread use
> resulted in it being incorporated into the standard library in first
> language standard.
>
> Why hasn't the same thing happened with C?
>
Because the C standards committee has always decided NOT to add such
an improvement to the language. The C++ standard committee decided that
such an improvement WAS NECESSARY, and they develop one.
I have written most of the STL clone (AVL trees, RB trees, bitstrings,
flexible arrays, lists (double/single linked) and the whole library
is extremely fast and compact. It is just less than 100K when you use
all of it. If you use just the lists module it is less than 5K.
But apparently all this work is a waste of time. The committee decided
a feature freeze already, and I will not be ready to present this to
the next meeting in April.
Ian Collins
> Ian Collins a �crit :
>>
>> One interesting question is why, after over 30 years of use, there
>> hasn't appeared a widely accepted a general and extensible container
>> interface for C?
>>
>> The C++ STL appeared fairly early on in that language's evolution and
>> was rapidly and widely accepted by C++ developers. The widespread use
>> resulted in it being incorporated into the standard library in first
>> language standard.
>>
>> Why hasn't the same thing happened with C?
>>
>
> Because the C standards committee has always decided NOT to add such
> an improvement to the language. The C++ standard committee decided that
> such an improvement WAS NECESSARY, and they develop one.
Not quite, the STL component of the C++ standard library (people often
overlook the fact that the STL is a component of and not the entire C++
standard library) was around before the standardisation effort.
> I have written most of the STL clone (AVL trees, RB trees, bitstrings,
> flexible arrays, lists (double/single linked) and the whole library
> is extremely fast and compact. It is just less than 100K when you use
> all of it. If you use just the lists module it is less than 5K.
> the next meeting in April.
Make it publicly available and see how well it's used. You never know,
it might become popular enough for the new round of standardisation.
--
Ian Collins
Ian Collins
>
> My opinion is that C should be developed further, exactly BECAUSE is
> a simple language. Adding a container library to C doesn't make the
> language any bigger or more complicated but makes programs COMPATIBLE
> because it is possible to interchange data with standard API/containers.
>
of their libraries these days.
> There is no way in C to return a list of the files in a directory. Nor
> there is a standard way to return a flexible array, or similar
> containers.
Well there is, you just have to write one.
> I have been developing a library like that, that is extensible and
> patterned after the STL.The only difference is that is way faster and
> smaller than the STL. I see that the C++ people will start crying that
> that is an heresy of course.
Will they? I very much doubt it. They will probably ask to see some
examples and benchmarks. Your solution my well be faster, but you will
have had to make some trade-offs to gain the speed.
> You (and the other C++ avocates here) seem to believe that complexity is
> better in sofwtare construction. My thesisis the opposite. I believe
> that a simple language is better than a completely bloated like C++.
Not really, but there are people here who are happy to use other
languages for tasks that better match their features.
--
Ian Collins
Branimir Maksimovic
Ian Collins <ian-...@hotmail.com> wrote:
>
> The C++ STL appeared fairly early on in that language's evolution and
> was rapidly and widely accepted by C++ developers. The widespread
> use resulted in it being incorporated into the standard library in
> first language standard.
I don;t think so. Widespread usage of STL was only after compilers
implemented templates to some workable extent,which is around year 2000.
Greets
Sometimes online sometimes not
Branimir Maksimovic
jacob navia <ja...@spamsink.net> wrote:
>
> I have written most of the STL clone (AVL trees, RB trees, bitstrings,
> flexible arrays, lists (double/single linked) and the whole library
> is extremely fast and compact. It is just less than 100K when you use
> all of it. If you use just the lists module it is less than 5K.
>
> But apparently all this work is a waste of time. The committee decided
> a feature freeze already, and I will not be ready to present this to
> the next meeting in April.
Why don;t you take path which boost library used for C++? It wasn;t
standard, but people started to use it and it's now de facto standard.
Greets
Sometimes online sometimes not
Ian Collins
> On Sun, 7 Mar 2010 16:13:40 -0600 (CST)
> Ian Collins <ian-...@hotmail.com> wrote:
>> The C++ STL appeared fairly early on in that language's evolution and
>> was rapidly and widely accepted by C++ developers. The widespread
>> use resulted in it being incorporated into the standard library in
>> first language standard.
>
> I don;t think so. Widespread usage of STL was only after compilers
> implemented templates to some workable extent,which is around year 2000.
Which was "fairly early" in C++ terms, well before the language was
standardised.
--
Ian Collins
Keith Thompson
> Branimir Maksimovic wrote:
>> On Sun, 7 Mar 2010 16:13:40 -0600 (CST)
>> Ian Collins <ian-...@hotmail.com> wrote:
>>> The C++ STL appeared fairly early on in that language's evolution
>>> and was rapidly and widely accepted by C++ developers. The
>>> widespread
>>> use resulted in it being incorporated into the standard library in
>>> first language standard.
>>
>> I don;t think so. Widespread usage of STL was only after compilers
>> implemented templates to some workable extent,which is around year 2000.
>
> Which was "fairly early" in C++ terms, well before the language was
> standardised.
No, the first ISO C++ standard was published in 1998.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Michael Foukarakis
> 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+.
My apologies, but I'm unable to recall whole passages of text, and I'm
sure others are too. Could you be more specific? Which idiosyncrasies?
Are they syntactic, semantic? What are some good reasons to remove
them?
Thomas Richter
>
>
> There is no point in discussing with you
Thus, "I'm running out of arguments", right? (-;
> Let's agree that we disagree, and go on using your pet language,
> whatever that is.
No, you completely miss the point. I don't *have* a pet language, unlike
you.
> My opinion is that C should be developed further, exactly BECAUSE is
> a simple language. Adding a container library to C doesn't make the
> language any bigger or more complicated but makes programs COMPATIBLE
> because it is possible to interchange data with standard API/containers.
>
> There is no way in C to return a list of the files in a directory. Nor
> there is a standard way to return a flexible array, or similar
> containers.
Not in C, but in POSIX, which is implemented by most C compilers. This
is basically because the execution environment of some C compilers do
not have the notion of a directory. Actually, there are no means to do
the same in C++, and for the same reason.
If you need a container for a flexible array, write one - where's the
problem?
> I have been developing a library like that, that is extensible and
> patterned after the STL.The only difference is that is way faster and
> smaller than the STL. I see that the C++ people will start crying that
> that is an heresy of course.
Then you made other design tradeoffs; it depends on the problem whether
your solution fits the problem or not. Nobody will be crying either,
they'd probably ask you for the design tradeoffs you took. Nobody will
be arguing that the STL is the optimal solution for every problem, it
surely isn't. I'm not a big fan of the STL either, it is overweight, too
complex, and often doesn't do what I need, but that's a different topic
that has nothing to do with C.
> You (and the other C++ avocates here) seem to believe that complexity is
> better in sofwtare construction. My thesisis the opposite. I believe
> that a simple language is better than a completely bloated like C++.
You still don't get it, don't you? I'm not a "C++ advocate". I'm a "use
the right tool for the job" advocate. That might be C, C++, java,
pyhton, bash, or whatever else is out in the field. For complex
algorithms on a desktop system, I wouldn't use C. Neither would I use
C++ for a GUI-intensive problem, java is much better suited for that,
nor would I write scripts in java, that's what I use python for.
Greetings,
Thomas
bartc
> On Mar 5, 7:56 pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca> wrote:
>> 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+.
>
> My apologies, but I'm unable to recall whole passages of text, and I'm
> sure others are too. Could you be more specific? Which idiosyncrasies?
> Are they syntactic, semantic? What are some good reasons to remove
> them?
"Chaper 3. Unscrambling Declarations in C". A language shouldn't need
complicated algorithms just for making sense of type specifications.
There is also the business of having separate typedef names and struct
names:
struct point {int x,y;};
typedef struct point point;
struct point p;
point q;
And the typedef statement itself, which instead of having the type-spec on
one side, and the alias for it on the other, is all mixed up:
typedef int tenvector[10];
the typedef name is in the middle of the type-spec!
This is one area I've always had (and always will have) problems with. I'm
sure the OP and the book had many others in mind too.
--
Bartc
Lorenzo Villari
Thomas Richter <th...@math.tu-berlin.de> wrote:
>
> You still don't get it, don't you? I'm not a "C++ advocate". I'm a
> "use the right tool for the job" advocate. That might be C, C++,
> java, pyhton, bash, or whatever else is out in the field. For complex
> algorithms on a desktop system, I wouldn't use C. Neither would I use
> C++ for a GUI-intensive problem, java is much better suited for that,
> nor would I write scripts in java, that's what I use python for.
>
What does it means "GUI-intensive" and why should java be better at
solving these kinds of problems? Excluding subjective aesthetic
consideration on the resulting GUIs, I think some operations
"could" (but I'm unaware of recent changes so I could be wrong) be a bit
slower than an analogous C or C++ counterpart. Of course if maximum
speed is not required that's ok. A slow menu is not that cool btw...
Eric Sosman
> Michael Foukarakis wrote:
>> On Mar 5, 7:56 pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca> wrote:
>>> 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+.
>>
>> My apologies, but I'm unable to recall whole passages of text, and I'm
>> sure others are too. Could you be more specific? Which idiosyncrasies?
>> Are they syntactic, semantic? What are some good reasons to remove
>> them?
>
> "Chaper 3. Unscrambling Declarations in C". A language shouldn't need
> complicated algorithms just for making sense of type specifications.
(Shrug.) Nonetheless, the power to derive new types from
the built-in types is desirable. What's your suggestion for a
simplification that retains the same expressive power? Show us
the declaration of, say, signal() in your simplified scheme.
> There is also the business of having separate typedef names and struct
> names:
>
> struct point {int x,y;};
> typedef struct point point;
>
> struct point p;
> point q;
This is, at most, a minor point (sorry), and IMHO not worth
addressing. Indeed, the cure might be worse than the disease:
struct point { int x, y; };
struct point point(int x, int y) {
struct point p;
p.x = x;
p.y = y;
return p;
}
A rule that automatically made a struct tag a first-class type
name (and perhaps similarly with union and enum tags, too) would
forbid this style of naming con-struct-ors.
> And the typedef statement itself, which instead of having the type-spec
> on one side, and the alias for it on the other, is all mixed up:
>
> typedef int tenvector[10];
>
> the typedef name is in the middle of the type-spec!
Er, um, yes. What's your point?
> This is one area I've always had (and always will have) problems with.
Yes, we can see that. Be patient: Facility comes with
familiarity, and familiarity with practice.
> I'm sure the OP and the book had many others in mind too.
... which takes us all the way back to Michael Foukarakis'
question: What, specifically, are the idiosyncracies that bother
you? (Beyond your difficulties in understanding declarations,
which will, as I said, smooth themselves out with practice.)
--
Eric Sosman
eso...@ieee-dot-org.invalid
bartc
news:hn2ub2$b7q$1...@news.eternal-september.org...
> On 3/8/2010 6:06 AM, bartc wrote:
>> Michael Foukarakis wrote:
>>> On Mar 5, 7:56 pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca> wrote:
>>>> 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+.
>>>
>>> My apologies, but I'm unable to recall whole passages of text, and I'm
>>> sure others are too. Could you be more specific? Which idiosyncrasies?
>>> Are they syntactic, semantic? What are some good reasons to remove
>>> them?
>>
>> "Chaper 3. Unscrambling Declarations in C". A language shouldn't need
>> complicated algorithms just for making sense of type specifications.
>
> (Shrug.) Nonetheless, the power to derive new types from
> the built-in types is desirable. What's your suggestion for a
> simplification that retains the same expressive power? Show us
> the declaration of, say, signal() in your simplified scheme.
I proposed a simplified scheme for C here a couple of years back. I haven't
got a message ID, but a similar one, adapted from another language might be:
T Type T
[N] T N-element Array of T
* T Pointer to T
function (A,B,C)T Function taking params A,B,C and returning T
I don't know the spec of signal(), but an array of pointers to a function
taking two ints and returning a pointer to a double, might be:
[]*function(int,int)*double
Notice the 1:1 correspondence with the English.
>> There is also the business of having separate typedef names and struct
>> names:
...
> This is, at most, a minor point (sorry), and IMHO not worth
> addressing. Indeed, the cure might be worse than the disease:
>
> struct point { int x, y; };
> struct point point(int x, int y) {
> struct point p;
> p.x = x;
> p.y = y;
> return p;
> }
>
> A rule that automatically made a struct tag a first-class type
> name (and perhaps similarly with union and enum tags, too) would
> forbid this style of naming con-struct-ors.
I'm not sure about your point: are you saying being able to write the above
is good or bad?
>
>> And the typedef statement itself, which instead of having the type-spec
>> on one side, and the alias for it on the other, is all mixed up:
>>
>> typedef int tenvector[10];
>>
>> the typedef name is in the middle of the type-spec!
>
> Er, um, yes. What's your point?
It's, um, untidy. I have chosen one of the 3 type-declarations I do know
(ie. simple type, pointer, and array), in a more complicated one you have to
search for the name of the typedef!
(Elsewhere I might write the above as:
type tenvector = [10]int
Note the name always goes in the same place and does not have to be
extricated.)
>
>> This is one area I've always had (and always will have) problems with.
>
> Yes, we can see that. Be patient: Facility comes with
> familiarity, and familiarity with practice.
>
>> I'm sure the OP and the book had many others in mind too.
>
> ... which takes us all the way back to Michael Foukarakis'
> question: What, specifically, are the idiosyncracies that bother
> you? (Beyond your difficulties in understanding declarations,
> which will, as I said, smooth themselves out with practice.)
A bit like learning Chinese symbols. On the other hand, it might be a lot
easier to start with pin-yin.
The very existence of that chapter, and programs such as CDECL, show I'm not
alone in my difficulties.
--
Bartc
jacob navia
For an example of a full C only program using advanced GUI features
see the lcc-win debugger.
The debugger+IDE+Project management+Editor+grep+diff+reformater+etc
is just 800K (windows 32 bit).
Only C allows you the speed AND power of direct GUI access with access
to the low level debugging API.
ImpalerCore
> "Eric Sosman" <esos...@ieee-dot-org.invalid> wrote in message
You have a huge amount of inertia present in the C language and
syntax, and I believe that these syntax arguments are pretty much
pointless most of the time. Preferences I think you can argue over,
but with no compiler support for these syntax changes, it's not like I
can try out your version and see if I think it's better.
Contrast this with something like 'const char*' versus 'char const*';
that's something that I can at least try out.
Best regards,
John D.
> --
> Bartc
bartc
news:op7ln.48407$Ym4....@text.news.virginmedia.com...
> "Eric Sosman" <eso...@ieee-dot-org.invalid> wrote in message
> news:hn2ub2$b7q$1...@news.eternal-september.org...
>> (Shrug.) Nonetheless, the power to derive new types from
>> the built-in types is desirable. What's your suggestion for a
>> simplification that retains the same expressive power? Show us
>> the declaration of, say, signal() in your simplified scheme.
> I don't know the spec of signal(), but an array of pointers to a function
> taking two ints and returning a pointer to a double, might be:
I found this:
void ( * signal(int, void (*)(int)))(int)
which with the help of cdecl (which was itself a job and a half to track
down a working copy) told me this:
"declare signal as function (int, pointer to function (int) returning void)
returning pointer to function (int) returning void"
In the suggested syntax it can be written as:
function (int, *function(int)void ) *function(int)void
The name "signal" can either go after the first "function" (to be in line
with how ordinary functions are defined) or at the end (the same as how
variables might be defined); either way, it's at one end or the other, not
buried in the middle:
function signal(int, *function(int)void ) *function(int)void {...}
function (int, *function(int)void ) *function(int)void signal;
If that's still too cryptic then * can also be optionally written as
"pointer to", and "returning" can be optionally added after the ")", so that
it looks like:
function (int, pointer to function(int) returning void ) returning pointer
to function(int) returning void
It is now identical to the main part of the cdecl output.
--
Bartc
Richard
> "bartc" <ba...@freeuk.com> wrote in message
> news:op7ln.48407$Ym4....@text.news.virginmedia.com...
>> "Eric Sosman" <eso...@ieee-dot-org.invalid> wrote in message
>> news:hn2ub2$b7q$1...@news.eternal-september.org...
>
>>> (Shrug.) Nonetheless, the power to derive new types from
>>> the built-in types is desirable. What's your suggestion for a
>>> simplification that retains the same expressive power? Show us
>>> the declaration of, say, signal() in your simplified scheme.
>
>> I don't know the spec of signal(), but an array of pointers to a function
>> taking two ints and returning a pointer to a double, might be:
>
> I found this:
>
> void ( * signal(int, void (*)(int)))(int)
>
> which with the help of cdecl (which was itself a job and a half to track
> down a working copy) told me this:
The wonders of Linux
sudo aptitude install cdecl
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Richard Heathfield
<other points, already addressed by others, snipped>
> And the typedef statement itself, which instead of having the type-spec
> on one side, and the alias for it on the other, is all mixed up:
>
> typedef int tenvector[10];
>
> the typedef name is in the middle of the type-spec!
That's actually irrelevant - the typedef is remarkably easy to use. To
define a synonym for an existing type, all you have to do is pretend
you're defining an object of that type, and stick typedef on the front.
Let's say you want a synonym for an array of ten pointers to function
taking const char * and returning int. Start simple:
int func(const char *);
That isn't actually what we want, but it's the first step. Now let's
turn it into a type synonym definition:
s/int/typedef int/
gives us
typedef int func(const char *);
func is now a type synonym. We use this in the next stage:
func arr[10];
Again, not quite what we want, so we:
s/func/typedef func/
to give
typedef func arr[10];
arr is now a synonym for "array of ten pointers to function taking const
char * and returning int".
It's hard to see how this could be made much simpler.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
bartc
> bartc wrote:
>
> <other points, already addressed by others, snipped>
>
>> And the typedef statement itself, which instead of having the
>> type-spec on one side, and the alias for it on the other, is all
>> mixed up: typedef int tenvector[10];
>>
>> the typedef name is in the middle of the type-spec!
>
> That's actually irrelevant - the typedef is remarkably easy to use. To
> define a synonym for an existing type, all you have to do is pretend
> you're defining an object of that type, and stick typedef on the
> front.
This is a method I /have/ to use in order to write typedefs, because I do
not find them intuitive.
As well as decomposing complex type-specs into a hierarchy of typedefs.
These are just ways around the difficulties of the type system.
> Let's say you want a synonym for an array of ten pointers to
> function taking const char * and returning int.
You're assuming I know what const char * means (and so did I). Cdecl tells
me it's actually a pointer to const char (not const pointer to char).
...
> typedef int func(const char *);
>
> func is now a type synonym. We use this in the next stage:
...
> typedef func arr[10];
>
> arr is now a synonym for "array of ten pointers to function taking
> const char * and returning int".
>
> It's hard to see how this could be made much simpler.
To summarise, to declare a variable x with such a type:
typedef int func(const char *);
typedef func arr[10];
arr x;
Which is an alternative to writing (with some help from cdecl):
int (*x[10])(const char *);
The typedefs at least turn it from impossible to possible, although in my
scheme, it would just be:
[10]*function(* const char)int x;
It doesn't *look* that different, but I managed to write it in a few seconds
from your description above, and anyone can understand it by reading from
left to right.
(And applied also to the typedefs, they might look like this, if they are
still written like variable declarations:
typedef function(* const char)int func;
typedef [10]func arr;
The name being defined is now always on the right.)
--
Bartc
Ian Collins
> Ian Collins <ian-...@hotmail.com> writes:
>> Branimir Maksimovic wrote:
>>> On Sun, 7 Mar 2010 16:13:40 -0600 (CST)
>>> Ian Collins <ian-...@hotmail.com> wrote:
>>>> The C++ STL appeared fairly early on in that language's evolution
>>>> and was rapidly and widely accepted by C++ developers. The
>>>> widespread
>>>> use resulted in it being incorporated into the standard library in
>>>> first language standard.
>>> I don;t think so. Widespread usage of STL was only after compilers
>>> implemented templates to some workable extent,which is around year 2000.
>> Which was "fairly early" in C++ terms, well before the language was
>> standardised.
>
> No, the first ISO C++ standard was published in 1998.
Oops, must be getting old and getting my decades muddled up!
Even so, the STL was in widespread used before C++ was standardised.
--
Ian Collins
jacob navia
> jacob navia schrieb:
>>
>>
>> There is no point in discussing with you
>
> Thus, "I'm running out of arguments", right? (-;
>
No. It is just that it loops:
jacob: We can improve C by adding A and B
thomas: No, C can't be improved. It is a bad language because
it lacks A and B. Use C++ instead.
jacob: But it is precisely my argument that we should A and B
to the language.
thomas: C is low level and nothing should be improved. It is low level
because it lacks A and B. Use C++ that has A and B.
etc.
Dag-Erling Smørgrav
> Because the C standards committee has always decided NOT to add such
> an improvement to the language. The C++ standard committee decided that
> such an improvement WAS NECESSARY, and they develop one.
No they didn't. They adopted and standardized an existing interface.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> Why don't you take path which boost library used for C++? It wasn't
> standard, but people started to use it and it's now de facto standard.
It's also (mostly) crap.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> quite correct. This harping on about keywords is just silly. You can
> write code that compiles with both and a C compiler and a C++
> compiler. And it isn't that hard.
From scratch, yes. Most existing C code will need modifications, such
as casts for malloc() and renaming variables or functions called new and
delete (which are the most common conflicts). The implicit "struct" /
"class" will get you in trouble if you're in the habit of typedefing
structs. You will also have to wrap headers for external C libraries in
extern "C" { } if they aren't already. Older code may contain K&R-style
function declarations and definitions (!prototypes), which won't work.
Malcolm McLean
>
> You still don't get it, don't you? I'm not a "C++ advocate". I'm a "use
> the right tool for the job" advocate. That might be C, C++, java,
> pyhton, bash, or whatever else is out in the field.
>
The problem comes when the costs to using the tools are significant.
Imagine a carpenter who has to walk from village to village picking up
odd jobs. He'll take a hammer and a saw. A lathe and a drill would
also be handy, but take too much and he's got to hire an assistant to
carry the toolbag, which means that he'll have to bump up his charges
considerably. Using a nail where ideally you'd put a screw might be
the best solution.
Similarly the costs of having some code in C, some in C++, some in
Java, some in Python are very considerable.
Lorenzo Villari
Thomas Richter <th...@math.tu-berlin.de> wrote:
>
> You still don't get it, don't you? I'm not a "C++ advocate". I'm a
> "use the right tool for the job" advocate. That might be C, C++,
> java, pyhton, bash, or whatever else is out in the field. For complex
> algorithms on a desktop system, I wouldn't use C. Neither would I use
> C++ for a GUI-intensive problem, java is much better suited for that,
> nor would I write scripts in java, that's what I use python for.
>
What does it means "GUI-intensive" and why should java be better at
solving these kinds of problems? Excluding subjective aesthetic
consideration on the resulting GUIs, I think some operations
"could" (but I'm unaware of recent changes so I could be wrong) be a bit
slower than an analogous C or C++ counterpart. Of course if maximum
speed is not required that's ok. A slow menu is not that cool btw...
Richard Harter
<th...@math.tu-berlin.de> wrote:
>jacob navia schrieb:
>
>> My opinion is that C should be developed further, exactly BECAUSE is
>> a simple language. Adding a container library to C doesn't make the
>> language any bigger or more complicated but makes programs COMPATIBLE
>> because it is possible to interchange data with standard API/containers.
>>
>> There is no way in C to return a list of the files in a directory. Nor
>> there is a standard way to return a flexible array, or similar
>> containers.
>
>Not in C, but in POSIX, which is implemented by most C compilers. This
>is basically because the execution environment of some C compilers do
>not have the notion of a directory. Actually, there are no means to do
>the same in C++, and for the same reason.
The answer to this is that the standard could have environment
dependent sections. Thus the standard could say that IF the
environment supports a directory based file system then the
implementation provides the corresponding POSIX library.
Having a container library is a different kind of issue because
it isn't environment dependent. The standard could specify a
container library. The sticking point is what should it look
like.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.
ImpalerCore
> jacob navia wrote:
>
> > C is still being used, and many important projects are based on it. My
> > thesis is that a simple language is necessary and useful. Adding
> > a general and extensible container interface for C doesn't change at all
> > the language but gives C programmer the advantages of not having to
> > program the same data structures over and over.
>
> > The proliferation of libraries that do the same thing WITHOUT a standard
> > in C means that each big project in C has several versions of the same
> > data structure because library XYZ uses lists with the "Next" field
> > in the fiorst position and library"XXX" uses a list with Next in the
> > second position. Besides all APIs are different, etc.
>
> One interesting question is why, after over 30 years of use, there
> hasn't appeared a widely accepted a general and extensible container
> interface for C?
>
> The C++ STL appeared fairly early on in that language's evolution and
> was rapidly and widely accepted by C++ developers. The widespread use
> resulted in it being incorporated into the standard library in first
> language standard.
>
That is a very good question. I think that you may have hinted at the
problem already, "C++ STL appeared fairly early on".
I imagine that the Stepanov and other people pursuing generic
containers didn't think C could provide the right support. The fact
that C++ standardization was fluid while he was working on his ideas
certainly made for easier acceptance by that language. C++ at that
time had much less inertia compared to C, and better language support
for his ideas. The longer a feature (the two big ones are a standard
container library, and concurrency) is not available in the
development of a language's toolset, the more likely that the
implementation of that feature will be fragmented across the
architectures and the people who need it. I believe the fact that the
STL came together in C++'s infancy led to more general acceptance as a
whole. Delay the STL enough, maybe a couple of years, and I believe
that C++ would have had the same problem, maybe.
I may be completely off, but those are my current thoughts on the
question.
Best regards,
John D.
> --
> Ian Collins
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
ImpalerCore
> Ian Collins a écrit :
>
> > jacob navia wrote:
>
> > One interesting question is why, after over 30 years of use, there
> > hasn't appeared a widely accepted a general and extensible container
> > interface for C?
>
> > The C++ STL appeared fairly early on in that language's evolution and
> > was rapidly and widely accepted by C++ developers. The widespread use
> > resulted in it being incorporated into the standard library in first
> > language standard.
>
> > Why hasn't the same thing happened with C?
>
> an improvement to the language. The C++ standard committee decided that
> such an improvement WAS NECESSARY, and they develop one.
>
> flexible arrays, lists (double/single linked) and the whole library
> is extremely fast and compact. It is just less than 100K when you use
> all of it. If you use just the lists module it is less than 5K.
>
> But apparently all this work is a waste of time. The committee decided
> a feature freeze already, and I will not be ready to present this to
> the next meeting in April.
And C has been waiting for a standard generic container library for
what, like 30 years? I don't think there's any hurry on this, and I
don't know if the committee is even looking for a container library.
I believe that the C++ committee reached out to Stepanov, or it's
likely that his work wouldn't have come to fruition in C++ the way it
did. I would think that a container library having 'de-facto'
standardization similar to boost would be a prerequisite to even think
about C standardization. Why should they invest a lot of time and
energy debating the rules and semantics when the result may not be
accepted by the compiler or C community at large? Having a de-facto
library that has garnered support from the C community would give your
argument a bit more weight.
I don't know if it's even possible to get a de-facto container
standard these days. Many people have their own pet library that they
use and it may be difficult if not impossible to motivate them away
from it. I believe that your pursuit of a generic standardized
container library in C would be an endurance race, not a sprint.
I don't believe the work is ever a waste of time. Even if the C
standard committee rejects your proposal doesn't invalidate the
attempt. If you make standard committee acceptance or rejection your
definition of whether the effort is worth it, then I believe you are
doing it for the wrong reasons. If you are doing it because you love
doing it, then the work *is* worth it no matter the outcome. In the
end, you have to realize that the only person who you have control of
is yourself.
Best regards,
John D.
> --
Jasen Betts
> jacob navia wrote:
>>
>> C is still being used, and many important projects are based on it. My
>> thesis is that a simple language is necessary and useful. Adding
>> a general and extensible container interface for C doesn't change at all
>> the language but gives C programmer the advantages of not having to
>> program the same data structures over and over.
> >
>> The proliferation of libraries that do the same thing WITHOUT a standard
>> in C means that each big project in C has several versions of the same
>> data structure because library XYZ uses lists with the "Next" field
>> in the fiorst position and library"XXX" uses a list with Next in the
>> second position. Besides all APIs are different, etc.
>
> hasn't appeared a widely accepted a general and extensible container
> interface for C?
>
> The C++ STL appeared fairly early on in that language's evolution and
> was rapidly and widely accepted by C++ developers. The widespread use
> resulted in it being incorporated into the standard library in first
> language standard.
>
> Why hasn't the same thing happened with C?
too much work for too little gain.
C does not have templates, only macros, and using macros template
functiuons longer than 5 lines are hard to maintain, and longer than
50 are impossible.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Seebs
> No. It is just that it loops:
I think you are not following his argument.
> jacob: We can improve C by adding A and B
> thomas: No, C can't be improved. It is a bad language because
> it lacks A and B. Use C++ instead.
He absolutely said nothing of the sort.
He did not say C was "a bad language". He did not say "C can't be improved".
He did say that he didn't think that adding A and B to C would improve it,
but rather, that it would make more sense to use languages which have
them.
You know what's an awesome feature in a programming language? An "eval"
operation, which interprets strings as code. Incredibly flexible and
powerful.
Do you think we should add eval() to C? I don't.
> thomas: C is low level and nothing should be improved. It is low level
> because it lacks A and B. Use C++ that has A and B.
I do not think this is a fair representation of his argument.
Here is a piece of advice I got from a friend once: If you want to argue
with someone, a good starting point is to understand their position well
enough that you can present their argument well enough that *they* agree
that you are presenting their argument fairly and well. If you can do that,
then it's reasonable to move on to arguing with them. If every time you
claim you are presenting their argument, they say "no, that's not what I
said at all", then you aren't ready to argue against them, because you don't
understand what they said.
I believe his argument is that he does not feel that adding A and B would
improve C. For instance, I don't think that adding operator overloading would
improve C. I think it would make C worse. One of the things I like about
C is the confidence that I know what it's doing. Operator overloading is
a great fit for an OO language, where I expect objects to have internal state
and define their own rules. It's a poor fit for a language where I
expect operations to map very closely onto machine instructions.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
> And C has been waiting for a standard generic container library for
> what, like 30 years? I don't think there's any hurry on this, and I
> don't know if the committee is even looking for a container library.
I'm not on the committee these days, but I really don't think a container
library is the right class of problem for the language spec to solve.
There are simply too many design tradeoffs that, *for C programs*, are too
significant for the language to nail them down.
The problem is, if we provide a "container library" in the spec, people
will be strongly inclined to use it even when it's a bad fit. I'm not sure
I want to do that -- look at the damage done by rand()!
I have seen a few possible container designs for C. None of them have
particularly appealed to me. Of the ones I've seen, the one that... uhm...
Guy whose name I've forgotten. The "embedded containers" approach, where
you have a list pointer anywhere in an object, and convert a pointer to the
list member of the object back into a pointer to the object. That's by far
the nicest -- and I'd never seen it until a couple-few months ago. Which
is to say, if we'd standardized any of the things I'd heard of by 2005 in
the language, we'd have missed a really good idea.
> I don't know if it's even possible to get a de-facto container
> standard these days. Many people have their own pet library that they
> use and it may be difficult if not impossible to motivate them away
> from it. I believe that your pursuit of a generic standardized
> container library in C would be an endurance race, not a sprint.
I would agree. And I think it's important to realize that there are going
to be mutually-exclusive requirements, so either you implement more than one,
or you write it off as being impossible.
> I don't believe the work is ever a waste of time. Even if the C
> standard committee rejects your proposal doesn't invalidate the
> attempt. If you make standard committee acceptance or rejection your
> definition of whether the effort is worth it, then I believe you are
> doing it for the wrong reasons. If you are doing it because you love
> doing it, then the work *is* worth it no matter the outcome. In the
> end, you have to realize that the only person who you have control of
> is yourself.
Totally agreed. I don't expect the language to pick up my string library
or my list library, but I use them and like having them around.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Walter Banks
> jacob navia wrote:
> > The proliferation of libraries that do the same thing WITHOUT a standard
> > in C means that each big project in C has several versions of the same
> > data structure because library XYZ uses lists with the "Next" field
> > in the fiorst position and library"XXX" uses a list with Next in the
> > second position. Besides all APIs are different, etc.
>
> One interesting question is why, after over 30 years of use, there
> hasn't appeared a widely accepted a general and extensible container
> interface for C?
Feature additions in C essentially takes two things.
1) A working example of new feature that is part of a current set of tools.
This is important to understand the implementation ramifications
and resolve the implementation conflicts that transforms a good
idea into good practice.
2) A champion that will formally explain and promote the new feature.
New ideas are debated on several levels. Does the new
feature address a real need, does the need have a broad application.
Are there alternative approaches. What is the impact on the existing
code base.
To answer the question some of the same people serve on C and C++
committees and one of the differences they saw between the languages
was it was more appropriate for an extensible container to be promoted
for C++ and not in C. I don't remember an extensible container
interface for C ever being discussed in WG-14.
Regards,
Walter..
jacob navia
> On 2010-03-07, Ian Collins <ian-...@hotmail.com> wrote:
>> Why hasn't the same thing happened with C?
>
> too much work for too little gain.
>
> C does not have templates, only macros, and using macros template
> functiuons longer than 5 lines are hard to maintain, and longer than
> 50 are impossible.
>
A container library doesn't need macros. You can use void * and
it works.
I have developed a container library using plain C, and I have
already:
o lists (single/double linked)
o flexible arrays
o bitstrings
o AVL trees
o Red/Black trees
and it is not finished yet.
Ian Collins
I think you probably are on the right track (at least you have the same
thoughts as me!). Early adoption was the key. I guess the same applied
to the C standard library; most of it was in use on early Unix systems
and the standard simply standardised existing practice (see a lot of the
examples in the original K&R).
Along with early availability, there has to be a strong desire from
users to improve and grow a language. Drawing another comparison with
C++, compare the work going on with C++0x and C99. By the time C++0x is
ratified, there will probably be more (almost complete) implementations
of it than there are C99, over a decade after ratification. A large
part of the new standard library is already in widespread use. There
are also significant improvements to the core language, driven by a
desire to improve upon what we currently have. One of these is language
support for concurrency, so if the will is there, it's never too late!
<OT>
For anyone interested, http://www2.research.att.com/~bs/C++0xFAQ.html
gives an incite into motivations for the new C++ standard.
</OT>
--
Ian Collins
--
Ian Collins
> On 8 Mar, 08:59, Thomas Richter <t...@math.tu-berlin.de> wrote:
>> You still don't get it, don't you? I'm not a "C++ advocate". I'm a "use
>> the right tool for the job" advocate. That might be C, C++, java,
>> pyhton, bash, or whatever else is out in the field.
>>
> That sounds so sensible that no-one would ever disagree with it.
>
> The problem comes when the costs to using the tools are significant.
> Imagine a carpenter who has to walk from village to village picking up
> odd jobs. He'll take a hammer and a saw. A lathe and a drill would
> also be handy, but take too much and he's got to hire an assistant to
> carry the toolbag, which means that he'll have to bump up his charges
> considerably. Using a nail where ideally you'd put a screw might be
> the best solution.
Or he will buy a van and grow is business because ha can tackle a
broader range of jobs. He will do the job in less than half the time,
to the client pays less.
I like that analogy!
--
Ian Collins
Ian Collins
> Nick Keighley <nick_keigh...@hotmail.com> writes:
>> quite correct. This harping on about keywords is just silly. You can
>> write code that compiles with both and a C compiler and a C++
>> compiler. And it isn't that hard.
>
> From scratch, yes. Most existing C code will need modifications, such
> as casts for malloc() and renaming variables or functions called new and
> delete (which are the most common conflicts). The implicit "struct" /
> "class" will get you in trouble if you're in the habit of typedefing
> structs.
Why?
> You will also have to wrap headers for external C libraries in
> extern "C" { } if they aren't already. Older code may contain K&R-style
> function declarations and definitions (!prototypes), which won't work.
A good excuse to fix them!
--
Ian Collins
Flash Gordon
> Lorenzo Villari a �crit :
>> On Mon, 8 Mar 2010 02:59:32 -0600 (CST)
>> Thomas Richter <th...@math.tu-berlin.de> wrote:
>>
>>> You still don't get it, don't you? I'm not a "C++ advocate". I'm a
>>> "use the right tool for the job" advocate. That might be C, C++,
>>> java, pyhton, bash, or whatever else is out in the field. For complex
>>> algorithms on a desktop system, I wouldn't use C. Neither would I use
>>> C++ for a GUI-intensive problem, java is much better suited for that,
>>> nor would I write scripts in java, that's what I use python for.
>>
>> What does it means "GUI-intensive" and why should java be better at
>> solving these kinds of problems?
Doesn't it have some kind of graphics library as part of the standard?
Or did someone mis-lead me many years ago?
>> Excluding subjective aesthetic
>> consideration on the resulting GUIs, I think some operations
>> "could" (but I'm unaware of recent changes so I could be wrong) be a bit
>> slower than an analogous C or C++ counterpart. Of course if maximum
>> speed is not required that's ok. A slow menu is not that cool btw...
>
> For an example of a full C only program using advanced GUI features
> see the lcc-win debugger.
>
> The debugger+IDE+Project management+Editor+grep+diff+reformater+etc
> is just 800K (windows 32 bit).
>
> Only C allows you the speed AND power of direct GUI access with access
> to the low level debugging API.
No, if the API is available to C it is also available to C++.
Also, when writing a GUI I don't normally want to get under the hood by
accessing the GUI directly, I normally want to use a nice powerful
widget set that does a lot of the hard work for me.
--
Flash Gordon
jacob navia
> jacob navia wrote:
>> Only C allows you the speed AND power of direct GUI access with access
>> to the low level debugging API.
>
> No, if the API is available to C it is also available to C++.
>
No. As you (may) know, you have to write
extern "C"
in C++
> Also, when writing a GUI I don't normally want to get under the hood by
> accessing the GUI directly, I normally want to use a nice powerful
> widget set that does a lot of the hard work for me.
That's a viewpoint. Another viewpoint (mine) is that experience has told me NOT to use any widget
set but use the API. This way, I have been able to run programs written under windows 16 bits
today under windows 64 bits.
Ian Collins
> Flash Gordon a �crit :
>> jacob navia wrote:
>>> Only C allows you the speed AND power of direct GUI access with access
>>> to the low level debugging API.
>>
>> No, if the API is available to C it is also available to C++.
>>
> No. As you (may) know, you have to write extern "C" in C++
Er, so? Wrap the header in extern "C" {..} and away you go.
--
Ian Collins
Keith Thompson
> Flash Gordon a écrit :
>> jacob navia wrote:
>>> Only C allows you the speed AND power of direct GUI access with access
>>> to the low level debugging API.
>>
>> No, if the API is available to C it is also available to C++.
>
>
> No. As you (may) know, you have to write
> extern "C"
> in C++
If you replaced "No" by "Yes", I'd agree. Yes, you have to write
extern "C"; that's *how* the API is available to C++.
I'm sure you didn't mean to imply that typing extern "C" is too
difficult, but I can't figure out what point you were making.
Can you clarify?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia
>
> You know what's an awesome feature in a programming language? An "eval"
> operation, which interprets strings as code. Incredibly flexible and
> powerful.
>
> Do you think we should add eval() to C? I don't.
>
>> thomas: C is low level and nothing should be improved. It is low level
>> because it lacks A and B. Use C++ that has A and B.
>
> I do not think this is a fair representation of his argument.
>
Under lcc-win you can do:
typedef void (fnptr)(void);
fnptr fn;
fn = CompileString("int main(void)(printf("\hello\"); )");
fn();
and you get "hello"...
This is called a JIT (Just in Time Compiler). Lcc-win has a JIT version.
(snip advice)
>
> I believe his argument is that he does not feel that adding A and B would
> improve C. For instance, I don't think that adding operator overloading would
> improve C. I think it would make C worse. One of the things I like about
> C is the confidence that I know what it's doing. Operator overloading is
> a great fit for an OO language, where I expect objects to have internal state
> and define their own rules. It's a poor fit for a language where I
> expect operations to map very closely onto machine instructions.
>
> -s
You do operator overloading in c when you use an operator like
+ since the compiler will do all necessary conversions for you.
The only thing that operator overloading adds to the language is the possibility
for the USER to add itsb own numeric types. Besides, if you do not like that
feature, do not use it. The language stays the same otherwise.
And (you probably know that)
unsigned long a,b,c;
// ...
c = a+b;
This translates into a function call in some machines.
(Specially 16 bit machines).
Richard Heathfield
> Richard Heathfield wrote:
<snip>
>> [...] To
>> define a synonym for an existing type, all you have to do is pretend
>> you're defining an object of that type, and stick typedef on the
>> front.
>
> This is a method I /have/ to use in order to write typedefs, because I
> do not find them intuitive.
Because I use this method for writing typedefs, I find them intuitive.
<snip>
>> Let's say you want a synonym for an array of ten pointers to
>> function taking const char * and returning int.
>
> You're assuming I know what const char * means (and so did I).
I thought that was a reasonable assumption.
> Cdecl tells
> me it's actually a pointer to const char (not const pointer to char).
Obviously the assumption was misplaced.
<snip>
> To summarise, to declare a variable x with such a type:
>
> typedef int func(const char *);
> typedef func arr[10];
> arr x;
Yes.
>
> Which is an alternative to writing (with some help from cdecl):
>
> int (*x[10])(const char *);
Yes.
> The typedefs at least turn it from impossible to possible, although in my
> scheme, it would just be:
>
> [10]*function(* const char)int x;
EEK!
Seebs
>>> thomas: C is low level and nothing should be improved. It is low level
>>> because it lacks A and B. Use C++ that has A and B.
>> I do not think this is a fair representation of his argument.
> Under lcc-win you can do:
The existence of your eval-like feature doesn't make that a fair
representation of his argument.
> The only thing that operator overloading adds to the language is the possibility
> for the USER to add itsb own numeric types. Besides, if you do not like that
> feature, do not use it. The language stays the same otherwise.
If programs were written and maintained by a single person, sure.
But if you're looking at a few megabytes of code, the last thing you want
is to have the possibility that someone silently overloaded an operator.
> unsigned long a,b,c;
>
> // ...
> c = a+b;
>
> This translates into a function call in some machines.
> (Specially 16 bit machines).
It may, or may not, but at least its behavior is fully understood. It's
not going to do something totally unlike addition.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Flash Gordon
> Flash Gordon a �crit :
>> jacob navia wrote:
>>> Only C allows you the speed AND power of direct GUI access with access
>>> to the low level debugging API.
>>
>> No, if the API is available to C it is also available to C++.
>
>
> No. As you (may) know, you have to write
> extern "C"
> in C++
Which means yes it is available to me, since I'm quite capable of doing
that.
>> Also, when writing a GUI I don't normally want to get under the hood
>> by accessing the GUI directly, I normally want to use a nice powerful
>> widget set that does a lot of the hard work for me.
>
> That's a viewpoint. Another viewpoint (mine) is that experience has told
> me NOT to use any widget set but use the API. This way, I have been able
> to run programs written under windows 16 bits
> today under windows 64 bits.
So? I'm able to run programs which started life in DOS using a text mode
widget set under 64 bit Linux, and if I tried I could get them to run
under 64 bit Windows as well. You just have to pick a widget set which
will continue to be supported because it is popular and good enough.
A decent Widget set can also deal with some of the portability issues,
assuming you pick one which is sufficiently ported.
Oh, and MS does eventually drop support for obsolete interface.
--
Flash Gordon
bartc
news:dK6dnWhcWNSnFQjW...@bt.com...
> bartc wrote:
>> Which is an alternative to writing (with some help from cdecl):
>>
>> int (*x[10])(const char *);
>
> Yes.
>
>> The typedefs at least turn it from impossible to possible, although in my
>> scheme, it would just be:
>>
>> [10]*function(* const char)int x;
>
> EEK!
That's supposed to be my reaction to the C equivalent...
My version actually is based on Algol-68 syntax, something like this I
believe, without 'const' attribute:
[10]ref proc(ref char)int x;
I changed 'ref' to '*' in order to be more C-friendly, obviously that didn't
work...
--
Bartc
Ben Bacarisse
<snip stuff about C types and typedefs>
> The typedefs at least turn it from impossible to possible, although in my
> scheme, it would just be:
>
> [10]*function(* const char)int x;
>
> from your description above, and anyone can understand it by reading from
> left to right.
I think the word "function" is redundant in your scheme. Just as []s
announce an array, ()s announce a function. If you are concerned
about readability then "[]" could become "array []" and "*" could be
"pointer to" but if you are happy with minimal syntax elsewhere in the
scheme I'd suggest it for functions too.
<snip>
--
Ben.
Dennis (Icarus)
"jacob navia" <ja...@nospam.org> wrote in message
news:hn3t39$qhj$1...@speranza.aioe.org...
> Flash Gordon a �crit :
>> jacob navia wrote:
>>> Only C allows you the speed AND power of direct GUI access with access
>>> to the low level debugging API.
>>
>> No, if the API is available to C it is also available to C++.
>>
>
>
> No. As you (may) know, you have to write
> extern "C"
> in C++
Which I'm pretty sure makes it accessible, and hence usable, to C++
programs,
:-)
<snip>
Dennis
Michael Foukarakis
> On Mon, 8 Mar 2010 02:59:32 -0600 (CST)
>
>
> > You still don't get it, don't you? I'm not a "C++ advocate". I'm a
> > "use the right tool for the job" advocate. That might be C, C++,
> > java, pyhton, bash, or whatever else is out in the field. For complex
> > algorithms on a desktop system, I wouldn't use C. Neither would I use
> > C++ for a GUI-intensive problem, java is much better suited for that,
> > nor would I write scripts in java, that's what I use python for.
>
> What does it means "GUI-intensive" and why should java be better at
> solving these kinds of problems? Excluding subjective aesthetic
> consideration on the resulting GUIs, I think some operations
> "could" (but I'm unaware of recent changes so I could be wrong) be a bit
> slower than an analogous C or C++ counterpart. Of course if maximum
> speed is not required that's ok. A slow menu is not that cool btw...
Java was never that slow anyway, and with good JIT compilers its
performance is even closer to native code. I'm sure you can google
plenty of sources online that document this.
Nick
> Seebs a écrit :
>>
>> You know what's an awesome feature in a programming language? An "eval"
>> operation, which interprets strings as code. Incredibly flexible and
>> powerful.
>>
>> Do you think we should add eval() to C? I don't.
>>
>>> thomas: C is low level and nothing should be improved. It is low level
>>> because it lacks A and B. Use C++ that has A and B.
>>
>> I do not think this is a fair representation of his argument.
>>
>
> Under lcc-win you can do:
>
>
> typedef void (fnptr)(void);
>
> fnptr fn;
>
> fn = CompileString("int main(void)(printf("\hello\"); )");
> fn();
>
> and you get "hello"...
>
> This is called a JIT (Just in Time Compiler). Lcc-win has a JIT
> version.
Can you do:
typedef void (fnptr)(void);
void tt(const char *msg) {
char fnbuff[1000];
fnptr fn;
snprintf(fnbuff,1000,"int main(void)(printf(\"%s\"); )");
fn = CompileString(fnbuff);
fn();
}
?
Because, if so, aren't you shipping the compiler around with the
executable. What if the code to be compiled relies on a library that
isn't on the target machine? And if not, what does it give you apart
from losing a static function (or, I admit, a group of closely related
static functions all with the same boilerplate).
> The only thing that operator overloading adds to the language is the possibility
> for the USER to add itsb own numeric types. Besides, if you do not like that
> feature, do not use it. The language stays the same otherwise.
The danger with operator overloading is that it lets the USER add their
own NON NUMERIC [I thought I'd try adopting your STYLE for a while, but
got out of BREATH fairly QUICKLY] types. Look how long it took C++ to
get << and >> for streams - about 10 seconds.
The thing is though, this thread started by asking about what was got
wrong when C was designed. You immediately jumped in telling us about
what you've added to it. I think the intent of the question was what is
wrong with the underlying design.
Well I'd start with the inconsistencies in the standard library.
Half the functions that send things to a file take the file pointer as
the first argument. The other half take it as the last. puts is /not/
fputs defaulting to stdout.
By now these quirks are all second nature to me, but they are deeply
ugly and very confusing to newcomers.
Then I'd move on to the use of break inside both loops and switches -
leading to the behaviour of one of break/continue changing when you
embed a loop inside a switch clause but not the other.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Phred Phungus
> Ian Collins a �crit :
>> jacob navia wrote:
>>
>> One interesting question is why, after over 30 years of use, there
>> hasn't appeared a widely accepted a general and extensible container
>> interface for C?
>>
>> The C++ STL appeared fairly early on in that language's evolution and
>> was rapidly and widely accepted by C++ developers. The widespread use
>> resulted in it being incorporated into the standard library in first
>> language standard.
>>
>> Why hasn't the same thing happened with C?
>>
>
> an improvement to the language. The C++ standard committee decided that
> such an improvement WAS NECESSARY, and they develop one.
>
> I have written most of the STL clone (AVL trees, RB trees, bitstrings,
> flexible arrays, lists (double/single linked) and the whole library
> is extremely fast and compact. It is just less than 100K when you use
> all of it. If you use just the lists module it is less than 5K.
>
> But apparently all this work is a waste of time. The committee decided
> a feature freeze already, and I will not be ready to present this to
> the next meeting in April.
Jacob,
Do you a link for this source?
--
fred
Phred Phungus
> Casey Hawthorne wrote:
>> 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+.
>
> According to Stroustrup [TC++PL, intro], the name "C+" has already been
> taken, by a language unrelated to either C or C++.
>
I guessed the next one was going to be C flat.
Branimir Maksimovic
Michael Foukarakis <electr...@gmail.com> wrote:
>
> Java was never that slow anyway, and with good JIT compilers its
> performance is even closer to native code. I'm sure you can google
> plenty of sources online that document this.
Problem with java is that it runs on hardware which is not forgiving
as there is fast CPU and very slow RAM. GC grabs huge chunks of
memory and is not swap friendly, that's why overcommit and OOM killer
has to be turned on all the time.
Actually it is not problem with code itself, you can write
most lousy assembler and be cache friendly you can run circles
around most optimized JIT ;)
Greets
Sometimes online sometimes not
Nick Keighley
> jacob navia <ja...@nospam.org> writes:
> > Flash Gordon a écrit :
> >> jacob navia wrote:
> >>> Only C allows you the speed AND power of direct GUI access with access
> >>> to the low level debugging API.
>
> >> No, if the API is available to C it is also available to C++.
>
> > No. As you (may) know, you have to write
> > extern "C"
> > in C++
>
> If you replaced "No" by "Yes", I'd agree. Yes, you have to write
> extern "C"; that's *how* the API is available to C++.
>
> I'm sure you didn't mean to imply that typing extern "C" is too
> difficult, but I can't figure out what point you were making.
> Can you clarify?
"C's magic low level abilities allow us to do things no other language
can achieve"
jacob navia
>
> "C's magic low level abilities allow us to do things no other language
> can achieve"
For instance:
A full blown IDE under 1MB
A fast floating point package with 352 bits precision, in C+asm. The
core in assembler, the full C math library plus many other
special functions in C. Size: 204K.
I like C. The problem with modern softawre is BLOAT. Too much
features you do not need, too much inefficiency, the
contrary of "small is beautiful".
Well, I guess its a philosophical question anyway.
Ian Collins
The complexity of any given solution has to exist somewhere. It can
either be in the developer's code, or in the compiler writers.
--
Ian Collins
Nick Keighley
> bartc wrote:
> > And the typedef statement itself, which instead of having the type-spec
> > on one side, and the alias for it on the other, is all mixed up:
>
> > typedef int tenvector[10];
>
> > the typedef name is in the middle of the type-spec!
>
> That's actually irrelevant - the typedef is remarkably easy to use.
yeah right...
> To
> define a synonym for an existing type, all you have to do is pretend
> you're defining an object of that type, and stick typedef on the front.
so that defining a typedef is ***just as hard as*** defining an object
> Let's say you want a synonym for an array of ten pointers to function
> taking const char * and returning int.
the fact that you started with a readable english specification gives
a hint that there might be a better way.
> Start simple:
>
> int func(const char *);
>
> That isn't actually what we want, but it's the first step. Now let's
> turn it into a type synonym definition:
>
> s/int/typedef int/
>
> gives us
>
> typedef int func(const char *);
>
> func is now a type synonym. We use this in the next stage:
>
> func arr[10];
>
> Again, not quite what we want, so we:
>
> s/func/typedef func/
>
> to give
>
> typedef func arr[10];
>
> arr is now a synonym for "array of ten pointers to function taking const
> char * and returning int".
>
> It's hard to see how this could be made much simpler.
you missed the smiley!
Nick Keighley
all programming languages are a subset of Algol-68
bartc
"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:0.412476a8b6623415149f.2010...@bsb.me.uk...
Although my proposal wasn't too serious (merely pointing out the merits of
left-to-right type-specifications), I think it is just about workable as it
is.
The main problem is recognising whether a "*" symbol starts an expression,
or a type-spec, which I think can be established by examining the next
symbol (if it's a typename, type attribute, "[" or "function", then it's
probably a type-spec).
Making "function" optional however makes "(" highly ambiguous: you can have
an unlimited run of "*" and "(" symbols, and not know until the end (if even
then) what you are parsing.
Function declarations would also be rendered practically invisible...
--
Bartc
jacob navia
> jacob navia <ja...@nospam.org> writes:
>
>> Seebs a écrit :
>>> You know what's an awesome feature in a programming language? An "eval"
>>> operation, which interprets strings as code. Incredibly flexible and
>>> powerful.
>>>
>>> Do you think we should add eval() to C? I don't.
>>>
>>>> thomas: C is low level and nothing should be improved. It is low level
>>>> because it lacks A and B. Use C++ that has A and B.
>>> I do not think this is a fair representation of his argument.
>>>
>> Under lcc-win you can do:
>>
>>
>> typedef void (fnptr)(void);
>>
>> fnptr fn;
>>
>> fn = CompileString("int main(void)(printf("\hello\"); )");
>> fn();
>>
>> and you get "hello"...
>>
>> This is called a JIT (Just in Time Compiler). Lcc-win has a JIT
>> version.
>
> Can you do:
>
> typedef void (fnptr)(void);
>
> void tt(const char *msg) {
> char fnbuff[1000];
> fnptr fn;
> snprintf(fnbuff,1000,"int main(void)(printf(\"%s\"); )");
You have an error above The argument to printf is missing, and you get
an execution error. But I think I know what you mean. See later.
> fn = CompileString(fnbuff);
> fn();
> }
>
> ?
>
> Because, if so, aren't you shipping the compiler around with the
> executable.
The compiler is called "CompileString" of course, and is a static
library you link with.
> What if the code to be compiled relies on a library that
> isn't on the target machine?
The JIT linker will surely complain and you will get NULL back.
You must tell the JIT where the dynamic libraries or static
libraries are. The JIT can load object files, shared objects
or static libraries.
> And if not, what does it give you apart
> from losing a static function (or, I admit, a group of closely related
> static functions all with the same boilerplate).
>
The advantages of a JIT is that you can translate on the fly code
generated to fit certain circumstances that change from invocation to
invocation.
For instance a chemical company modelling molecules. The researcher
changes the high level model, they generate C from the model, and the
researches sees immediately the conserquences of his/her change
in the shape of the molecule displayed in the screen.
>> The only thing that operator overloading adds to the language is the possibility
>> for the USER to add itsb own numeric types. Besides, if you do not like that
>> feature, do not use it. The language stays the same otherwise.
>
> The danger with operator overloading is that it lets the USER add their
> own NON NUMERIC [I thought I'd try adopting your STYLE for a while, but
> got out of BREATH fairly QUICKLY] types. Look how long it took C++ to
> get << and >> for streams - about 10 seconds.
>
I am not convinced of any application of operator overloading that is not
(1) Done with new numeric types
(2) Done with access to containers (overloading [ ] )
ALl others, like using + to "add" srings or << or >> to print stuff are
bad usages in my opinion. Of course it can't be avoided. And, as you
know, in C I can write:
int AddTwoIntegers(int a,int b)
{
return a/b;
}
You can write bad code in ANY language.
> The thing is though, this thread started by asking about what was got
> wrong when C was designed. You immediately jumped in telling us about
> what you've added to it. I think the intent of the question was what is
> wrong with the underlying design.
>
Excuse me but the subject of this thread is:
Has thought been given given to a cleaned up C? Possibly called C+.
> Well I'd start with the inconsistencies in the standard library.
> Half the functions that send things to a file take the file pointer as
> the first argument. The other half take it as the last. puts is /not/
> fputs defaulting to stdout.
>
> By now these quirks are all second nature to me, but they are deeply
> ugly and very confusing to newcomers.
>
> Then I'd move on to the use of break inside both loops and switches -
> leading to the behaviour of one of break/continue changing when you
> embed a loop inside a switch clause but not the other.
Those are minor incoveniences. Yes, they are bad for newcomers but
what is essential is the stuff that is bad for newcomers AND for
experienced users.
Mr Heathfield is an experienced C programmer. The fact that even he had
a bug with zero terminated strings makes obvious that it is NOT his
abilities as a programmer that are bad, but a tool that uses ERROR PRONE
construct. (If you do not like my STYLE, please tell me how to put
emphasis in *plain ascii* :-) )
Nick Keighley
> jacob navia wrote:
> > Thomas Richter a crit :
> >> jacob navia wrote:
> >>> 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.
>
> >> Given the amount of existing code that builds on the existing C
> >> library, replacing it is actually plain nonsense.
>
> > Nobody is proposing that. This is an old trick in this discussions. Any
> > improvement to C is impossible because the old code. That is plainly not
> > true. The old code and the associated functions can be kept, but C
> > should be able to use BUFFERS of KNOWN length, avoiding the most common
> > cause of buffer overflows. Let's be explicit:
>
> > typedef struct {size_t length; char data[];} Buffer;
>
> > memset can be done as "Memset", for instance like this
> > bool Memset(Buffer *dest, int char_val);
<snip>
> > [...] Strcpy is just as trivial, but with a character
> > buffer.
>
> There is already a secure version of strcpy, see below.
where? I hope you don't mean strncpy().
> >> I don't think they're wrong. They require care, care some people forgot.
>
> > This has been discussed and discussed, and the essential point is that
> > if somebody makes a mistaken once, it is his/her fault. If thousands of
> > programmers make always the same errors it is the tool's fault.
>
> Then C is not the right tool for the job. As said below, there are other
> languages that can help. If you want to use C, there are also secured
> functions with buffer sizes that help. But even they won't prevent you
> from shooting yourself into the foot. C has no means to prevent bad
> pointers being dereferences, to give another example. If you want a
> child-proof C, use Java - it does have all the features you seem to
> miss. (And no, I've absolutely nothing against Java, no irony here.)
I've got some sympathy with both sides. C is a small, low level,
portable language. And this is its strong point. On the other hand
I've debugged too many (of other people's) linked lists to appreciate
a standard list library. The cool thing about C++ is the STL. On the
gripping hand I'm not sure a generic list/tree library can be written
for C and even more dubious that it will overcome C's intertia. I also
don't like the idea of C getting fat.
[no, I'm not on the Standards Commitee. I just drink their Kool Aid]
> > I am sure you can be proved wrong too.
>
> Of course I make mistakes, who wouldn't? And your point is? Again, if
> "avoiding errors" is your concern, use another tool and make other
> errors. Just that languages like java or C++ are neither the right tool
> for *some* jobs.
sometimes we don't have the opportunity to mix and match languages at
will. If we have a body of C code we can't usually add a Lisp module
just because we want a linked list.
A lot of this repeats so... <snip>
> >> If you want to avoid the hassle, go for C++, or use the limiting
> >> functions.
>
> > Here we have it again. Any development of C is always answered with
> > "Go to C++" even by committee members. C should remain full of warts
> > so that C++ can be seen as the only alternative. There should be NO
> > simpler language than C++, all development of C as a language should
> > STOP.
boring...
<snip>
> >> If you need library support for that, and a richer structure that
> >> helps you with such containers, use C++ and the STL.
>
> > OF COURSE that is the solution.
>
> Then where is the damn problem?
Jacob was being sarcastic
<snip>
> > C is still being used, and many important projects are based on it. My
> > thesis is that a simple language is necessary and useful.
>
> Then keep it simple. If writing a list or a tree is not simple for you,
> you are in the wrong field for applying C for that task.
what?! Just because something is reasonably straightforward doesn't
mean it should be done over and over again. Isn't the essence of
programming the packaging of ideas?
> Or look for a
> library that helps you. C is a small language; why whould that stuff be
> required in the language core - it would often not fit into the
> application because C doesn't have all the mechanisms of higher
> languages to hide the implementation behind the design.
I have a this feeling too
> > This is SO OBVIOUS that doesn't even need to be discussed. But C should
> > be kept in its present state so taht the only alternative is to swallow
> > C++
>
> It's obvious that you want to use C just for the means of it. Get over
> it, C is not the "saves all my problems" language. It is good in some
> cases, and bad in others. String manipulation and generic container
> support are not the strong parts of C, so why force it? If you want to
> make C another language, I again ask why. There *are* already other
> languages in first place you can use.
I think Jocob wants something that is "better" than C (and a bit
bigger) but not as monstrous as C++. I'm curious as to whether he can
do it.
--
After a couple of projects that I've done in scheme, after many years
of C (and assembler), I've come to the conclusion that even
*starting*
a program in C is an exercise in premature optimization.
(Andrew Reilly comp.lang.scheme)
Jasen Betts
> Richard Heathfield wrote:
>> Casey Hawthorne wrote:
>>> 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+.
>>
>> According to Stroustrup [TC++PL, intro], the name "C+" has already been
>> taken, by a language unrelated to either C or C++.
>
> I guessed the next one was going to be C flat.
there's already 2 different D-flats, so yeah. :)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Nick Keighley
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
[C and C++ are not compatible because new is a reserved word in C++]
> > quite correct. This harping on about keywords is just silly. You can
> > write code that compiles with both and a C compiler and a C++
> > compiler. And it isn't that hard.
>
> From scratch, yes. Most existing C code will need modifications, such
> as casts for malloc() and renaming variables or functions called new and
> delete (which are the most common conflicts). The implicit "struct" /
> "class" will get you in trouble if you're in the habit of typedefing
> structs.
really? Why? I'll have to go digging but I'm pretty sure I've done
this.
> You will also have to wrap headers for external C libraries in
> extern "C" { } if they aren't already. Older code may contain K&R-style
> function declarations and definitions (!prototypes), which won't work.
Dag-Erling Smørgrav
> Dag-Erling Smørgrav <d...@des.no> writes:
> > The implicit "struct" / "class" will get you in trouble [...]
> Why?
C keeps struct names in a separate namespace, C++ doesn't. The simplest
example I can come up with is this, which is legal in C but not in C++:
struct s { int i; };
typedef int s;
C++ has an exception for typedefing a struct or class under its own
name, i.e. this is fine in both languages:
typedef struct s { int i; } s;
DES
--
Dag-Erling Smørgrav - d...@des.no
Ben Bacarisse
<snip>
> I am not convinced of any application of operator overloading that is not
> (1) Done with new numeric types
> (2) Done with access to containers (overloading [ ] )
>
> ALl others, like using + to "add" srings or << or >> to print stuff are
> bad usages in my opinion.
What about a library for doing symbolic manipulation of expressions --
for example polynomials. Would you not want to define + as the
operation of addition on polynomials?
> Of course it can't be avoided. And, as you
> know, in C I can write:
>
> int AddTwoIntegers(int a,int b)
> {
> return a/b;
> }
>
> You can write bad code in ANY language.
True, but the arguments against operator overloading don't just rely
on similar inappropriate usage. In some cases, finding the "matching"
function is non-trivial. Your implementation may be such that this
issue never arises. If so, it is big point to talk up.
<snip>
--
Ben.
Stephen Sprunk
> Ian Collins <ian-...@hotmail.com> writes:
>> Dag-Erling Smørgrav <d...@des.no> writes:
>>> The implicit "struct" / "class" will get you in trouble [...]
>>
>> Why?
>
> C keeps struct names in a separate namespace, C++ doesn't. The simplest
> example I can come up with is this, which is legal in C but not in C++:
>
> struct s { int i; };
> typedef int s;
>
> C++ has an exception for typedefing a struct or class under its own
> name, i.e. this is fine in both languages:
>
> typedef struct s { int i; } s;
... and I suspect that exception was specifically added to C++ to
support compiling C code that uses that common idiom to work around C's
separate name space for structs.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Dag-Erling Smørgrav
> Thomas Richter <th...@math.tu-berlin.de> writes:
> > There is already a secure version of strcpy, see below.
> where? I hope you don't mean strncpy().
OpenBSD's strlcpy(), for one.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> C++ has an exception for typedefing a struct or class under its own
> name, i.e. this is fine in both languages:
>
> typedef struct s { int i; } s;
missing "but a no-op in C++"
Andrew Poelstra
I think the biggest missing feature of C is namespaces. If we had
namespaces it would be a lot easier to share (and reuse) libraries
because there'd be far less risk of name clashing.
Plus we would have to name everything something insane and confuse
the package name with the function name.
For example, if I were to use Jacob's library (whenever it is
"complete"), I might create a tree with
navia::avl_tree t1 = navia::new_avl_tree(/* whatever */);
Which is a little ugly, but if his was the only avl tree library
I could stick a
using navia::avl_tree*
at the top and be done with it.
As it stands, to avoid name clashes his avl tree functions might
need to be prefixed with navia_ (or something less self-serving
perhaps), which not only still has the potential for name clashing,
but also begs the question, is a "navia_list" a list of Navias
or a list from the Navia library. (Or a list used for some "navia"
widget, or maybe it means NAV for Intel Architecture, where NAV
could mean anything, or ...)
--
Andrew Poelstra
http://www.wpsoftware.net/andrew