UNIX, C, Perl
Pilcrow
how come so many things are almost impossible in ordinary C? Examples:
Network and internet access, access to UNIX interprocess controls and
communication, locale determination, EBCDIC/ASCII discrimination, etc.
Almost all of these are easy in Perl. Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these? Isn't
anyone working on this problem? or is it all being left for proprietary
systems?
James Kuyper
> Given that UNIX, including networking, is almost entirely coded in C,
> how come so many things are almost impossible in ordinary C? Examples:
> Network and internet access, access to UNIX interprocess controls and
They are not impossible in "ordinary C", they are impossible in strictly
conforming C. The C that operating systems are written in will make
heavy use of highly non-portable constructs that give access to all of
these things. In some cases, those non-portable constructs will consist
of calls to routines written in assembly language, or in-line assembly
language, but a very large fraction of the system can be written
entirely in non-portable C.
> ... locale determination, EBCDIC/ASCII discrimination, etc.
I'm not at all clear to me why you think that those can't be performed
in ordinary C. What features are you asking for that aren't provided by
<locale.h>? Perhaps if you described in more detail the desired
functionality I could address the question better.
> Almost all of these are easy in Perl. Why isn't there a mechanism like
> perl modules to allow easy extentions for facilities like these?
There are such mechanisms - they are called "header files" and
"libraries", and together they serve a very similar purpose.
> ... Isn't
> anyone working on this problem? or is it all being left for proprietary
> systems?
There's no reasons why the libraries have to be proprietary, though many
certainly are.
Eric Sosman
Should a programming language set standards for all
the application arenas in which it can be used?
--
Eric Sosman
eso...@ieee-dot-org.invalid
Bill Reid
Eric Sosman <eso...@ieee-dot-org.invalid> wrote in message
news:2uadnYbBJKv5syDV...@comcast.com...
> Pilcrow wrote:
Sun Microsystems: "YOU BETCHA!!!"
Java, the Esperanto of computer programming languages...
---
William Ernest Reid
Bill Reid
Pilcrow <pil...@pp.info> wrote in message
news:11aqb4dfqm5k92um5...@4ax.com...
I thought "PERL" WAS coded in "C"...
Somebody, many people have worked on this "problem"; for example,
I got a "regex" PERL-like library for free with MY "C" compiler, along
with a bunch of other stuff, including stuff you mention...the only
people who haven't worked on it are those DAMN BEAURUCRATS
IN WASHINGTON!!! (or whever the "C" standards committee met,
and of course, their "portability" yipping lap-dogs here)...
---
William Ernest Reid
John Bellone
> Pilcrow <pilc...@pp.info> wrote in message
What are we considering "ordinary C?" Are we talking about the
libraries that are distributed with the GNU C library, any C compiler
that is POSIX standard supported, or are we talking about Visual C++?
The beauty of C is that it will run on damn near any piece of hardware
you throw at it. Almost every single platform's operating system is
written in a combination of C and (some form of) assembler. All of
these things that you mentioned are very possible, because frankly,
the language that you mentioned was implemented in C. The foundations
that you are building on were written in C, Pascal and assembler.
But here is the other interesting tidbit. Many languages that make it
easier for programmers to simply create a socket connection with two
lines of code (Python, C# and Java) have C libraries behind them doing
all the dirty work. If you really want to do all of these things in C
then your best bet is to follow a POSIX standard for sockets
(networking) and work strictly with C99 standards. You are almost
guaranteed that your code will run almost anywhere except certain
embedded platforms (and even those now are using POSIX compilers).
I am a firm believer that both C/C++ are portable as long as you have
someone in the background managing the projects. As long as the proper
libraries are used and standards are followed the code should be
relatively easy to port across platforms. But don't take my word for
it: there are many projects available at sourceforge.net that are open
source that can give you examples of a portable C application.
Although take a note: many "C" applications nowadays are essentially a
C++ application.
james...@verizon.net
...
> IN WASHINGTON!!! (or whever the "C" standards committee met,
As you might expect for an international standards organization, the
meetings of ISO/IEC JTC1/SC22/WG14 are held in a wide variety of
places around the world. Judging from
<http://www.open-std.org/jtc1/sc22/wg14/www/meetings>, it would appear
that they have not met in Washington at any time since at least 1994,
and probably earlier. Since the US member is INCITS J11
<http://www.ncits.org/tc_home/j11.htm>, and that committee's meetings
are co-located with those of WG14, it doesn't look like Washington has
anything to do with this.
Antoninus Twink
> Given that UNIX, including networking, is almost entirely coded in C,
> how come so many things are almost impossible in ordinary C?
> Examples: Network and internet access, access to UNIX interprocess
> controls and communication, locale determination, EBCDIC/ASCII
> discrimination, etc.
You've spent too much time being brainwashed by the clc regulars.
ALL of these things are possible in C, OF COURSE. And if Official
Standards (peace be upon them) are really important to you, there's this
one you might have heard of: POSIX.
Keith Thompson
It depends on what you mean by "ordinary C".
The C language is defined by an ISO standard. (Actually by two
versions of the same ISO standard, since the most recent one has not
yet been widely implemented.) That standard specifically permits
extensions with certain limitations -- and many implementations
provide extensions without those limitations in a non-conforming mode.
If you want to write code that depends only on features defined in the
language standard, then your code will be portable to any conforming C
implementation -- but it won't be able to do networking, interprocess
communication, and so forth.
If you need to use such features, you can. You'll just have to use
some extension (such as POSIX) that's provided by your implementation.
Your program won't be portable to an implementation that doesn't
provide the particular extension(s) you're depending on, and in many
cases your program's behavior won't be defined by the language
standard.
This kind of tradeoff is unavoidable.
C is *designed* to allow writing non-portable code.
The thing is, though, that for most of the extensions you might want
to use, this newsgroup isn't the best place to discuss them. If you
want to ask how to use POSIX, there's comp.unix.programmer; for Win32,
there's comp.os.ms-windows.programmer.win32.
Don't confuse the scope of this newsgroup (as agreed upon by most of
the participants) with the scope of C programming.
--
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"
Pilcrow
wrote:
I am certainly glad to hear that these things are possible. But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.
The program I wrote is generalized enough to be able to do the same with
any other similar list. This saved me the chore of manually entering
each address into the form on that web page and copying and pasting the
zip code to my list. That chore would have taken several days, since I
am a clumsy typist, and the list, as I have said, has several hundred
entries.
How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?
I am sure that it is possible, since Perl itself is written in standard
C, or at least GCC.
Kenny McCormack
Keith Thompson <ks...@mib.org> meant to say:
...
>Don't confuse the scope of this newsgroup (as defined by a small, but
>very vocal subset, of the participants) with the scope of C programming.
Typos fixed. No thanks are necessary. HTH. HAND.
Eric Sosman
> [...] But perhaps
> an example of what I mean is appropriate. Last year I had a list of
> several hundred addresses in the USA for which I wanted the 5+4 postal
> zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
> <http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
> write a program (or a 'script'), in perl, that would access
> <http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
> address, parse the response, extract the zip codes I needed, and update
> my list.
Good: Problem solved, need satisfied, it's Miller Time.
> How could I do the same sort of thing using C? Is there a repository of
> libraries for C, similar to CPAN for Perl? If not, is anyone working on
> it?
One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will
you then go on to solve it in Ada, Fortran, Lisp, Jovial, ...?
Or to put it another way: If you feel impelled to throw out your
working Perl solution and write a fresh one in C, what is it
about Perl that you find unsatisfactory?
I'm not familiar with the libraries you mention, but there
are plenty of C libraries out there, perhaps including a few that
perform the kinds of tasks you're interested in.
> I am sure that it is possible, since Perl itself is written in standard
> C, or at least GCC.
I suspect you'll find that it's written in a C dialect --
maybe strictly-conforming C, maybe something looser -- and that
it also makes use of libraries of various kinds that are in turn
written in Lordknowswhat. Perhaps all you're really looking for
is the packaging of a bunch of libraries into a single convenient
framework so you don't have to hunt them up and integrate them?
That's a perfectly reasonable thing to want, but ... as part of
the definition of a general-purpose language?
In your kitchen, I imagine you have an assortment of various
knives. You've probably got a few general-purpose knives, and a
few that are more specialized: heavy broad-bladed knives for chopping,
skinny flexible-bladed knives for filleting, knives with serrated
edges for slicing bread, knives with finer serrations for cutting
tomatoes ... Why do you have so many knives, instead of doing all
your cutting, slicing, and chopping with just one? Is it, perhaps,
because a knife that could handle *all* cutting tasks might have
usability problems?
Stretching the analogy right up to the breaking point, here
are two competing views of what C should be:
http://www.victorinox.com/index.cfm?site=victorinox.ch&page=158&lang=D
http://www.thinkgeek.com/gadgets/tools/8b97/zoom/
You'll notice that they differ mostly in degree.
james...@verizon.net
> Pilcrow wrote:
> > [...] But perhaps
> > an example of what I mean is appropriate. Last year I had a list of
> > several hundred addresses in the USA for which I wanted the 5+4 postal
> > zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
> > <http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
> > write a program (or a 'script'), in perl, that would access
> > <http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
> > address, parse the response, extract the zip codes I needed, and update
> > my list.
>
> Good: Problem solved, need satisfied, it's Miller Time.
>
> > How could I do the same sort of thing using C? Is there a repository of
> > libraries for C, similar to CPAN for Perl? If not, is anyone working on
> > it?
>
> One first wonders why you feel a need to re-solve a problem
> already solved, just for the sheer joy of doing it in C. Will
This isn't about a particular problem and it's solution, it's about
the availability of problem-solving tools. He's asking how he could
have used a similar approach to solving the problem in the first
place, if he had chosen C rather than perl.
james...@verizon.net
...
> I am certainly glad to hear that these things are possible. But perhaps
> an example of what I mean is appropriate. Last year I had a list of
> several hundred addresses in the USA for which I wanted the 5+4 postal
> zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
> <http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
> write a program (or a 'script'), in perl, that would access
> <http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
> address, parse the response, extract the zip codes I needed, and update
> my list.
>
> The program I wrote is generalized enough to be able to do the same with
> any other similar list. This saved me the chore of manually entering
> each address into the form on that web page and copying and pasting the
> zip code to my list. That chore would have taken several days, since I
> am a clumsy typist, and the list, as I have said, has several hundred
> entries.
>
> How could I do the same sort of thing using C? Is there a repository of
> libraries for C, similar to CPAN for Perl? If not, is anyone working on
> it?
There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many
similar repositories do exist for C code. What you're asking about is
mostly a social issue having to do with how CPAN works; it isn't
related to any technical differences between C and perl. Personally,
the repository I have the most familiarity with is sourceforge.net,
which handles a lot more than just C libraries.
Ian Collins
Where the facilities exist, the C libraries are provided. What do you
think Perl modules use?
--
Ian Collins.
Kenny McCormack
<james...@verizon.net> wrote:
...
(ditzy Eric scribbled)
>> One first wonders why you feel a need to re-solve a problem
>> already solved, just for the sheer joy of doing it in C. Will
>
>This isn't about a particular problem and it's solution, it's about
>the availability of problem-solving tools. He's asking how he could
>have used a similar approach to solving the problem in the first
>place, if he had chosen C rather than perl.
Yes. Anyone with a couple of brain cells to rub together can see that.
But it doesn't fit in with the CLC regs approach.
Go back and re-read Eric's text. It is chock full of nasty sarcasm
aimed at belittling the OP, while clearly feigning ignorance of what
this thread is really about.
Richard
> Pilcrow wrote:
>> [...] But perhaps
>> an example of what I mean is appropriate. Last year I had a list of
>> several hundred addresses in the USA for which I wanted the 5+4 postal
>> zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
>> <http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
>> write a program (or a 'script'), in perl, that would access
>> <http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
>> address, parse the response, extract the zip codes I needed, and update
>> my list.
>
> Good: Problem solved, need satisfied, it's Miller Time.
>
>> How could I do the same sort of thing using C? Is there a repository of
>> libraries for C, similar to CPAN for Perl? If not, is anyone working on
>> it?
>
> One first wonders why you feel a need to re-solve a problem
> already solved, just for the sheer joy of doing it in C. Will
Yes. I mean, who on earth EVER prototypes something in a high level
language and then moves to something like C for, oh, I dont know,
speed, memory usage etc. Are you always so ready to belittle people?
> you then go on to solve it in Ada, Fortran, Lisp, Jovial, ...?
> Or to put it another way: If you feel impelled to throw out your
> working Perl solution and write a fresh one in C, what is it
> about Perl that you find unsatisfactory?
>
> I'm not familiar with the libraries you mention, but there
> are plenty of C libraries out there, perhaps including a few that
> perform the kinds of tasks you're interested in.
So you do not know. Just throw in a bit of sarcasm because you are
bored?
>
>> I am sure that it is possible, since Perl itself is written in standard
>> C, or at least GCC.
>
> I suspect you'll find that it's written in a C dialect --
> maybe strictly-conforming C, maybe something looser -- and that
> it also makes use of libraries of various kinds that are in turn
> written in Lordknowswhat. Perhaps all you're really looking for
> is the packaging of a bunch of libraries into a single convenient
> framework so you don't have to hunt them up and integrate them?
> That's a perfectly reasonable thing to want, but ... as part of
> the definition of a general-purpose language?
>
> In your kitchen, I imagine you have an assortment of various
> knives. You've probably got a few general-purpose knives, and a
> few that are more specialized: heavy broad-bladed knives for chopping,
> skinny flexible-bladed knives for filleting, knives with serrated
> edges for slicing bread, knives with finer serrations for cutting
> tomatoes ... Why do you have so many knives, instead of doing all
> your cutting, slicing, and chopping with just one? Is it, perhaps,
> because a knife that could handle *all* cutting tasks might have
> usability problems?
Who the hell do you think you are second guessing the OP? He came here
for C help - not you strutting around and telling him what he wants.
>
> Stretching the analogy right up to the breaking point, here
> are two competing views of what C should be:
>
> http://www.victorinox.com/index.cfm?site=victorinox.ch&page=158&lang=D
>
> http://www.thinkgeek.com/gadgets/tools/8b97/zoom/
>
> You'll notice that they differ mostly in degree.
The only thing I noticed is that you made a right fool out of
yourself. Congratulations and another clc stripe.
Kenny McCormack
Richard <rgr...@gmail.com> wrote:
...
>> Good: Problem solved, need satisfied, it's Miller Time.
>>
>>> How could I do the same sort of thing using C? Is there a repository of
>>> libraries for C, similar to CPAN for Perl? If not, is anyone working on
>>> it?
>>
>> One first wonders why you feel a need to re-solve a problem
>> already solved, just for the sheer joy of doing it in C. Will
>
>Yes. I mean, who on earth EVER prototypes something in a high level
>language and then moves to something like C for, oh, I dont know,
>speed, memory usage etc. Are you always so ready to belittle people?
>
Answering for Eric: Yes. In a word. Yes. It is my biggest thrill in
life.
Pilcrow
>Pilcrow wrote:
>...
>> I am certainly glad to hear that these things are possible. But perhaps
>> an example of what I mean is appropriate. Last year I had a list of
>> several hundred addresses in the USA for which I wanted the 5+4 postal
>> zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
>> <http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
>> write a program (or a 'script'), in perl, that would access
>> <http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
>> address, parse the response, extract the zip codes I needed, and update
>> my list.
>>
>> The program I wrote is generalized enough to be able to do the same with
>> any other similar list. This saved me the chore of manually entering
>> each address into the form on that web page and copying and pasting the
>> zip code to my list. That chore would have taken several days, since I
>> am a clumsy typist, and the list, as I have said, has several hundred
>> entries.
>>
>> How could I do the same sort of thing using C? Is there a repository of
>> libraries for C, similar to CPAN for Perl? If not, is anyone working on
>> it?
>
>There is no single repository for C libraries which plays the same
>role for C that CPAN does for perl, but I would guess that many
why do you have to guess? CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included (unless you're installing ActiveState Perl, and a
similar facility is provided there).
>similar repositories do exist for C code. What you're asking about is
>mostly a social issue having to do with how CPAN works; it isn't
>related to any technical differences between C and perl. Personally,
>the repository I have the most familiarity with is sourceforge.net,
>which handles a lot more than just C libraries.
Similar repositories? How do I search them? Do they include
documentation? Are they cross-platform compatible? (I did my trick on a
MS platform, using a distribution of Perl know as 'Strawberry' perl, but
it would have worked also in a UNIX or Linux environment, using Perl
compiled for those). I have made use of Google's code search facility,
but it has its limitations.
Perhaps the reason for this contrast between C and Perl is the
cooperative spirit behind the Open Source movement. Also the evolving
nature of Perl, which, though it dates to 1987, has been frequently
improved and expanded. Facilities for OO programming, multi-threading,
forking, and others, though not in Perl a few years ago, are now
standard. And backward compatability has always been a consideration.
The documentation for Perl is also exemplary. There is little need to go
beyond the documentation available at the command line. All the
documentation needed is included with the installation. Little need to
buy other texts. I admit that more documentation is needed than with C,
but perl is a more complex language.
james...@verizon.net
> On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), james...@verizon.net wrote:
>
> >Pilcrow wrote:
...
> >> libraries for C, similar to CPAN for Perl? If not, is anyone working on
> >> it?
> >
> >There is no single repository for C libraries which plays the same
> >role for C that CPAN does for perl, but I would guess that many
>
Because I don't possess enough information to be certain, one way or
the other. Do you? If your question was just rheotorical, as now seems
to be the case, then all you're doing is trolling this newsgroup to
promote perl as a superior alternative to C. I know too much about
perl to fall for that one: perl has a number of advantages over C in
particular contexts, and i use it routinely when those contexts apply,
but it has nowhere near enough advantages to replace C in all
contexts. I wouldn't dream of using it for any of the tasks that I
currently use C for.
> ... CPAN is so much integrated with Perl, that
> whenever Perl is installed, the access to CPAN (cpan.pm) is
> automatically included (unless you're installing ActiveState Perl, and a
> similar facility is provided there).
I can't figure out what relevance that has to my guesswork. It almost
seems as if you're saying that a C repository cannot count as
"similar" unless access to that repository is automatically installed
when you install your C compiler; but I can't imagine that you're
making such a fatuous suggestion.
> >similar repositories do exist for C code. What you're asking about is
> >mostly a social issue having to do with how CPAN works; it isn't
> >related to any technical differences between C and perl. Personally,
> >the repository I have the most familiarity with is sourceforge.net,
> >which handles a lot more than just C libraries.
>
> Similar repositories? How do I search them? Do they include
> documentation? Are they cross-platform compatible?
The only such repository I'm familiar with is sourceforge.net. If you
check out their web site, it's pretty obvious how to search it.
Documentation seems to be the norm, not the exception, but I'm sure
that the quality of the documentation is highly variable. I'm sure
that cross-platform compatibility is also highly variable. That's
pretty much unavoidable when source code comes from such a wide
variety of sources.
Pilcrow
So many people have accused me of having a hidden agenda that I feel I
should declare my agenda explicitly. I am a man who has had a bit of
programming experience, most recently with Perl, who is now trying to
acquire a working knowledge of C, sufficient to do the kinds of things I
am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, especially as to the resources available to
the C programmer who is trying not to have to reinvent the wheel, but I
seem to have ruffled some feathers, for which I apologize. Please bear
with me, and be patient.
I already have gotten some answers, such as the existence of the
locale.h header file, which I should have noticed before.
I again apologize to all of you, but C, though faster than Perl, seems
to me very constricting. I am still working my way through K&R2, (and
posting some of my solutions on clc-wiki), so maybe there will be an
epiphany soon. I hope so.
Pilcrow
I apologize. I don't think Perl is superior to C. Every Perl
programmer, however, knows of the existence of CPAN. I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN, so that I don't have to reinvent the wheel with every
new task. I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.
Ron Ford
>>The only such repository I'm familiar with is sourceforge.net. If you
>>check out their web site, it's pretty obvious how to search it.
>>Documentation seems to be the norm, not the exception, but I'm sure
>>that the quality of the documentation is highly variable. I'm sure
>>that cross-platform compatibility is also highly variable. That's
>>pretty much unavoidable when source code comes from such a wide
>>variety of sources.
>
> I apologize. I don't think Perl is superior to C. Every Perl
> programmer, however, knows of the existence of CPAN. I was trying to
> find how I could find tested solutions in C, similar to the tested
> solutions of CPAN, so that I don't have to reinvent the wheel with every
> new task. I will try to explore sourceforge more thoroughly, which I
> have already used for various utilities.
You're not going to find CPAN here with the unterlanguage. It requires an
ecumenism that doesn't exist for C. Not sure why.
Every time time you "reinvent the wheel," you have to have a caller and a
target. I find that crossing syntax avoids weaknesses in given syntaxes.
Now that I think about it, the first reason for the lack of ecumenism is
history and the second is that there are dozens of competing
implementations of C while perl competes more convincingly for a
narrowslice, like sysadmins.
--
What men value in this world is not rights but privileges. 7
H. L. Mencken
Nick Keighley
> On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:
> >>The only such repository I'm familiar with is sourceforge.net. If you
> >>check out their web site, it's pretty obvious how to search it.
> >>Documentation seems to be the norm, not the exception, but I'm sure
> >>that the quality of the documentation is highly variable. I'm sure
> >>that cross-platform compatibility is also highly variable. That's
> >>pretty much unavoidable when source code comes from such a wide
> >>variety of sources.
>
> > I apologize. I don't think Perl is superior to C. Every Perl
> > programmer, however, knows of the existence of CPAN. I was trying to
> > find how I could find tested solutions in C, similar to the tested
> > solutions of CPAN,
C has no equivalent to CPAN. But then CPAN is pretty unique
to perl. You could say it was one of perl's selling points.
> > so that I don't have to reinvent the wheel with every
> > new task. I will try to explore sourceforge more thoroughly, which I
> > have already used for various utilities.
>
> You're not going to find CPAN here with the unterlanguage. It requires an
> ecumenism that doesn't exist for C. Not sure why.
>
> Every time time you "reinvent the wheel," you have to have a caller and a
> target.
>I find that crossing syntax avoids weaknesses in given syntaxes.
what does that mean? Is it even english?
> Now that I think about it, the first reason for the lack of ecumenism is
> history and the second is that there are dozens of competing
> implementations of C while perl competes more convincingly for a
> narrowslice, like sysadmins.
effectivly there is only one perl implementation
--
Nick Keighley
I have found that all ugly things are made by those who strive to make
something beautiful and that all beautiful things are made by those
who
strive to make something useful.
-- Oscar Wilde
Flash Gordon
<snip>
> I apologize. I don't think Perl is superior to C. Every Perl
> programmer, however, knows of the existence of CPAN. I was trying to
> find how I could find tested solutions in C, similar to the tested
> solutions of CPAN, so that I don't have to reinvent the wheel with every
> new task. I will try to explore sourceforge more thoroughly, which I
> have already used for various utilities.
Every Linux distribution comes with shed loads of libraries that are
accessible through C. Every OS provides a number of system specific
libraries for doing certain things (such as networking & graphics if the
system supports them natively, as modern personal computers generally
do). There are commercially available libraries for a number of tasks if
you can pay the money and live with the licensing terms. There are
things like Sourceforge. A number of posters here have their own
libraries they make available. However, there are things which are
fundamentally easier in Perl even if you have C libraries to do the
donkey work for you.
Oh, and modules in CPAN don't always work on all systems to which Perl
has been ported (I had some problems with modules on SCO a few years
back), so C libraries for specific tasks not always being portable to
everywhere is no different.
--
Flash Gordon
Richard Bos
> On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), james...@verizon.net wrote:
>
> >There is no single repository for C libraries which plays the same
> >role for C that CPAN does for perl, but I would guess that many
>
> why do you have to guess? CPAN is so much integrated with Perl, that
> whenever Perl is installed, the access to CPAN (cpan.pm) is
> automatically included
That's a neat trick, given that I've installed PERL on machines without
internet access.
Richard
Ron Ford
> On 3 Sep, 07:47, Ron Ford <r...@example.invalid> wrote:
>> On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:
>
>>>>The only such repository I'm familiar with is sourceforge.net. If you
>>>>check out their web site, it's pretty obvious how to search it.
>>>>Documentation seems to be the norm, not the exception, but I'm sure
>>>>that the quality of the documentation is highly variable. I'm sure
>>>>that cross-platform compatibility is also highly variable. That's
>>>>pretty much unavoidable when source code comes from such a wide
>>>>variety of sources.
>>
>>> I apologize. I don't think Perl is superior to C. Every Perl
>>> programmer, however, knows of the existence of CPAN. I was trying to
>>> find how I could find tested solutions in C, similar to the tested
>>> solutions of CPAN,
>
> C has no equivalent to CPAN. But then CPAN is pretty unique
> to perl. You could say it was one of perl's selling points.
Absolutely. The rest of us, eg, c, c++, c sharp, c flat, fortran, fortran
flat and karaoke, best note the strength of perl's syntax.
>
>
>>> so that I don't have to reinvent the wheel with every
>>> new task. I will try to explore sourceforge more thoroughly, which I
>>> have already used for various utilities.
>>
>> You're not going to find CPAN here with the unterlanguage. It requires an
>> ecumenism that doesn't exist for C. Not sure why.
>>
>> Every time time you "reinvent the wheel," you have to have a caller and a
>> target.
>
>>I find that crossing syntax avoids weaknesses in given syntaxes.
>
> what does that mean? Is it even english?
Since texans have monopolized vapidity, I'm afraid the answer is yes. I
can't make the point without posting a syntax which is not c, but that just
reminds me of texans, the not-constitution oil retards.
>
>
>> Now that I think about it, the first reason for the lack of ecumenism is
>> history and the second is that there are dozens of competing
>> implementations of C while perl competes more convincingly for a
>> narrowslice, like sysadmins.
>
> effectivly there is only one perl implementation
Right.
--
We must respect the other fellow's religion, but only in the sense and to
the extent that we respect his theory that his wife is beautiful and his
children smart. 5
H. L. Mencken
Ron Ford
.pm brings you farther with perl and a net connection than your installs.
--
Unquestionably, there is progress. The average American now pays out twice
as much in taxes as he formerly got in wages. 1
H. L. Mencken
James Kuyper
...
> am used to doing with Perl. I ask provocative questions in the attempt
Asking provocative questions tends, by definition, to provoke negative
reactions. I'd recommend asking interesting questions, rather than
provocative ones.
...
> I already have gotten some answers, such as the existence of the
> locale.h header file, which I should have noticed before.
I didn't realize that you were that unfamiliar with C, and therefore
misunderstood your comments as a dismissal of <locale.h> as being
insufficiently powerful. It might be insufficiently powerful; C++'s
support for locales, for instance, is much more sophisticated - so much
so that I can't quite figure out how to take advantage of it's powerful
capabilities - so there's certainly room for improvement (in both
languages).
Richard
> Pilcrow wrote:
> ...
>> am used to doing with Perl. I ask provocative questions in the attempt
>> of gaining new knowledge, ...
>
> Asking provocative questions tends, by definition, to provoke negative
> reactions. I'd recommend asking interesting questions, rather than
> provocative ones.
"Provocative" means interesting. It does not mean it needs an aggressive
reply.
Nick Keighley
> On Wed, 3 Sep 2008 00:23:52 -0700 (PDT), Nick Keighley posted:
> > On 3 Sep, 07:47, Ron Ford <r...@example.invalid> wrote:
> >> On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:
<snip>
> >> Every time time you "reinvent the wheel," you have to have a caller and a
> >> target.
>
> >>I find that crossing syntax avoids weaknesses in given syntaxes.
>
> > what does that mean? Is it even english?
>
> Since texans have monopolized vapidity, I'm afraid the answer is yes. I
> can't make the point without posting a syntax which is not c, but that just
> reminds me of texans, the not-constitution oil retards.
since this makes no more sense than the bit I tried to get you clarify
I assume you don't actaully want to communicate.
<snip>
--
Nick Keighley
Kenny McCormack
James Kuyper <james...@verizon.net> wrote:
>Pilcrow wrote:
>...
>> am used to doing with Perl. I ask provocative questions in the attempt
>> of gaining new knowledge, ...
>
>Asking provocative questions tends, by definition, to provoke negative
>reactions. I'd recommend asking interesting questions, rather than
>provocative ones.
This is true on Usenet and is Usenet's primary flaw.
It's not true in general (Note: You should probably spend some time with
a dictionary - look up the word "provocative") - that is, in real life - but
it is true that anything the least bit off the well-trodden path in a
Usenet posting, just gets people's dander up. The thread then just
turns into a big mess of defensiveness.
Kenny McCormack
Pilcrow <pil...@pp.info> wrote:
...
>So many people have accused me of having a hidden agenda that I feel I
>should declare my agenda explicitly. I am a man who has had a bit of
>programming experience, most recently with Perl, who is now trying to
>acquire a working knowledge of C, sufficient to do the kinds of things I
>am used to doing with Perl. I ask provocative questions in the attempt
>of gaining new knowledge, especially as to the resources available to
>the C programmer who is trying not to have to reinvent the wheel, but I
>seem to have ruffled some feathers, for which I apologize. Please bear
>with me, and be patient.
>
>I already have gotten some answers, such as the existence of the
>locale.h header file, which I should have noticed before.
>
>I again apologize to all of you, but C, though faster than Perl, seems
>to me very constricting. I am still working my way through K&R2, (and
>posting some of my solutions on clc-wiki), so maybe there will be an
>epiphany soon. I hope so.
Comments:
1) The obvious question is: Why? Others have alluded to this
question as well. The basic fact is that, in the context of
hosted systems, C is a legacy language; I can't see any reason
to do new development in it. People are pretty open about the
fact that, in today's world, C's domain is a) maintaining legacy
code and b) embedded systems.
2) Despite the name, this is not the newsgroup for you. None of the
things that you want to do are "on topic" here. I'm surprised
people haven't been hammering this point a lot harder than they
have. In fact, it can be said that, in general, anything that
you can do in C that is "on topic" here, shouldn't be done in C.
It should be done in a simple scripting language, such as AWK or Perl.
jacob navia
>
> Comments:
> 1) The obvious question is: Why? Others have alluded to this
> question as well. The basic fact is that, in the context of
> hosted systems, C is a legacy language; I can't see any reason
> to do new development in it.
This is a pile of shit. Yes, it can be tasteful to many flies,
that find always something useful in that...
C is by no means a legacy language, it is a *simple* language, and its
conceptual simplicity is what makes it much better choice
than other languages like C++.
> People are pretty open about the
> fact that, in today's world, C's domain is a) maintaining legacy
> code and b) embedded systems.
This is the opinion of many people here, specially the regulars.
I am really disappointed that you are basically in agreement
with them.
I am convinced that C is a language with a future, that can be
modified and improved to fit better the needs of software development
today without losing its inherent simplicity.
All my posts, and my work building a freely distributable
C99 compiler go in that direction.
I would propose that people that think that C is dead should
keep their opinion and go to other newsgroups.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Richard Heathfield
> Given that UNIX, including networking, is almost entirely coded in C,
> how come so many things are almost impossible in ordinary C?
I don't know of anything computable that isn't computable in ordinary C.
> Examples:
> Network and internet access,
C allows you to call library functions that provide these features, but
doesn't go so far as to make their provision mandatory. (Otherwise, you
couldn't have a C implementation on a system that didn't have internet
access - and that would be silly.)
> access to UNIX interprocess controls and communication,
Unix systems provide this access. Other systems don't. Don't blame the
language for the lack of provision of Unix interprocess communication
functionality on (some) non-Unix systems.
> locale determination,
It's not very well-named, but setlocale() has a query option.
> EBCDIC/ASCII discrimination, etc.
Well, if those were the only two choices, it would be trivial to determine
between them: if('A' == 65) it's ASCII. But since there are many choices,
why these two in particular?
(As it turns out, very often it doesn't actually matter what character set
you're using.)
> Almost all of these are easy in Perl.
That's nice.
> Why isn't there a mechanism like
> perl modules to allow easy extentions for facilities like these?
There is. It's called "libraries".
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
jacob navia
> Pilcrow said:
>
>> Given that UNIX, including networking, is almost entirely coded in C,
>> how come so many things are almost impossible in ordinary C?
>
> I don't know of anything computable that isn't computable in ordinary C.
>
>> Examples:
>> Network and internet access,
>
> C allows you to call library functions that provide these features, but
> doesn't go so far as to make their provision mandatory. (Otherwise, you
> couldn't have a C implementation on a system that didn't have internet
> access - and that would be silly.)
>
Exactly.
There are many implementations of networking, from
Windows sockets, BSD sockets, Netware, USB networking,
Wan, LANs, etc.
To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftplib.pl');
use strict;
my(@dirList);
ftp::debug('ON');
ftp::open('ftp.cis.ufl.edu', 'anonymous', 'med...@planet.net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary();
ftp::gets('FAQ.gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
ftp::debug();
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
----------------------------------------------perl
Using lcc-win the above program looks like this:
----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)
>
> Unix systems provide this access. Other systems don't. Don't blame the
> language for the lack of provision of Unix interprocess communication
> functionality on (some) non-Unix systems.
>
Exactly. The OP is completely confusing what a computer language is, and
what an operating system is.
>> locale determination,
>
> It's not very well-named, but setlocale() has a query option.
>
>> EBCDIC/ASCII discrimination, etc.
>
> Well, if those were the only two choices, it would be trivial to determine
> between them: if('A' == 65) it's ASCII. But since there are many choices,
> why these two in particular?
>
> (As it turns out, very often it doesn't actually matter what character set
> you're using.)
>
>> Almost all of these are easy in Perl.
>
> That's nice.
>
>> Why isn't there a mechanism like
>> perl modules to allow easy extentions for facilities like these?
>
> There is. It's called "libraries".
>
Exactly. C has "modules", and the interface is simple and efficient.
There is an enormous amount of C libraries around.
vipp...@gmail.com
<snip>
> To make mandatory the usage of some kind of network would
> be a foolish. Besides, you can do things in C that are MUCH
> more cumbersome in perl. For instance an ftp transfer in Perl
> looks like this:
> ----------------------------------------------perl
> #!/usr/bin/perl -w
> require('ftplib.pl');
> use strict;
> my(@dirList);
> ftp::debug('ON');
> ftp::open('ftp.cis.ufl.edu', 'anonymous', 'medi...@planet.net') or die($!);
> @dirList = ftp::list('pub/perl/faq');
> ftp::cwd('/pub/perl/faq');
> ftp::binary();
> ftp::gets('FAQ.gz');
> @dirList = ftp::list();
> print("list of /pub/perl/faq\n");
> foreach (@dirList) {
> print("\t$_\n");}
>
> @dirList = ftp::dir();
> print("list of /pub/perl/faq\n");
> foreach (@dirList) {
> print("\t$_\n");}
>
> ftp::debug();
> ftp::cwd('/pub/perl/faq');
> @dirList = ftp::list();
> print("list of /pub/perl/faq\n");
> foreach (@dirList) {
> print("\t$_\n");}
>
> ----------------------------------------------perl
>
> Using lcc-win the above program looks like this:
>
> ----------------------------------------------C (lcc-win)
> int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
> ----------------------------------------------C (lcc-win)
And using my implementation of perl, the above program looks like
this:
f()
So what?
Richard Heathfield
> Kenny McCormack wrote:
>
<snip>
>> People are pretty open about the
>> fact that, in today's world, C's domain is a) maintaining legacy
>> code and b) embedded systems.
>
> This is the opinion of many people here, specially the regulars.
It certainly isn't my opinion.
> I am really disappointed that you are basically in agreement
> with them.
I don't think he is.
> I am convinced that C is a language with a future,
Sure.
> that can be
> modified and improved to fit better the needs of software development
> today without losing its inherent simplicity.
The whole C99 experience suggests that the process of changing C will not
be an easy one. That does not in itself mean that the task should not be
attempted, but it is at least a heads-up that Here Be Dragons.
> All my posts, and my work building a freely distributable
> C99 compiler go in that direction.
>
> I would propose that people that think that C is dead should
> keep their opinion and go to other newsgroups.
On the contrary, I would propose that they change their opinion, since
there is no point in holding onto broken opinions.
jacob navia
Then, that proves that in any language, verbosity is a function of the
libraries that you are using!
Ben Bacarisse
> Richard Heathfield wrote:
>> Pilcrow said:
>>
>>> Given that UNIX, including networking, is almost entirely coded in C,
>>> how come so many things are almost impossible in ordinary C?
>>
>> I don't know of anything computable that isn't computable in ordinary C.
>>
>>> Examples:
>>> Network and internet access,
>>
>> C allows you to call library functions that provide these features,
>> but doesn't go so far as to make their provision
>> mandatory. (Otherwise, you couldn't have a C implementation on a
>> system that didn't have internet access - and that would be silly.)
>>
>
> Exactly.
>
> There are many implementations of networking, from
> Windows sockets, BSD sockets, Netware, USB networking,
> Wan, LANs, etc.
>
> To make mandatory the usage of some kind of network would
> be a foolish. Besides, you can do things in C that are MUCH
> more cumbersome in perl. For instance an ftp transfer in Perl
> looks like this:
> ----------------------------------------------perl
<snip bad Perl>
> ----------------------------------------------perl
No, using the correct module it is two lines.
> Using lcc-win the above program looks like this:
>
> ----------------------------------------------C (lcc-win)
> int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
> ----------------------------------------------C (lcc-win)
You need at least a #include and a main function as well, no? Your C
program will be no shorter than my Perl one.
These sorts of discussions (about program length) are daft and will
often degenerate into pointless comparisons like this.
But there *is* an important issue here. Perl's modules work well
together because of the dynamic type system, and the fact that Perl
has very flexible containers. Using C, you may be able to find a
great XML parsing library (for example) but it will probably represent
its lists and tables using different types (and access functions) to
all the other libraries you need. This is why Perl is so good at
"gluing" tasks.
This is the elephant in the room as far as C is concerned. Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.
--
Ben.
jacob navia
> But there *is* an important issue here. Perl's modules work well
> together because of the dynamic type system, and the fact that Perl
> has very flexible containers. Using C, you may be able to find a
> great XML parsing library (for example) but it will probably represent
> its lists and tables using different types (and access functions) to
> all the other libraries you need. This is why Perl is so good at
> "gluing" tasks.
>
> This is the elephant in the room as far as C is concerned. Because
> there is no agreed way to program a flexible array, a list or a map,
> everyone writes their own, or uses a published one that is
> incompatible with all the other published ones out there. It is often
> a lot of work just to coax two libraries to work together.
>
That is why I have been insisting that we adopt the operator overloading
feature that would allow using the '[' and ']' notation for general
containers. Then, we could agree that lists/flexible arrays/arrays
and all sequential containers could be accessed with that notation and
code would be compatible.
Richard Heathfield
> Ben Bacarisse wrote:
<snip>
>> Because
>> there is no agreed way to program a flexible array, a list or a map,
>> everyone writes their own, or uses a published one that is
>> incompatible with all the other published ones out there. It is often
>> a lot of work just to coax two libraries to work together.
>
> That is why I have been insisting that we adopt the operator overloading
> feature that would allow using the '[' and ']' notation for general
> containers.
I don't think you're in a position to insist, are you? Not even Microsoft
is in a position to insist on a change to the C language. In fact, not
even Dennis Ritchie is in that position.
It is sometimes difficult to remember that what one person sees as an
obvious improvement, another person sees as a hideous wart. Putting
oneself in another person's position is a useful and informative
intellectual exercise. Think up a change to C that you would really NOT
like to see in the language, and you should get the idea.
By the way, I'm not particularly against the idea of introducing operator
overloading into C (although many people probably are). But politicking
about it in comp.lang.c isn't going to get you anywhere. It's the ISO
people, not us, that you have to convince, and they are going to take a
lot of convincing after the drubbing they took over C99.
jacob navia
> jacob navia said:
>
>> Ben Bacarisse wrote:
>
> <snip>
>
>>> Because
>>> there is no agreed way to program a flexible array, a list or a map,
>>> everyone writes their own, or uses a published one that is
>>> incompatible with all the other published ones out there. It is often
>>> a lot of work just to coax two libraries to work together.
>> That is why I have been insisting that we adopt the operator overloading
>> feature that would allow using the '[' and ']' notation for general
>> containers.
>
> I don't think you're in a position to insist, are you? Not even Microsoft
> is in a position to insist on a change to the C language. In fact, not
> even Dennis Ritchie is in that position.
>
I know your position. Let's do nothing, and leave C to die a
peaceful death.
Any language that refuses to change anything and still tries
to see the world as we were in the times of the PDP 11 will
die, and C is going into that direction.
There is NO other solution that to introduce a way to share
libraries using lists/ flexible arrays, what have you in
a simple at the same time general way!
If we use the '[' and ']' notation for that, C libraries can
implement any container they like behind the scenes, the
user of those libraries writes
data[2]
and that is all there is to it!
The library has defined data as a flexible array, a list,
or a simple array and that will work with user code unchanged.
> It is sometimes difficult to remember that what one person sees as an
> obvious improvement, another person sees as a hideous wart. Putting
> oneself in another person's position is a useful and informative
> intellectual exercise. Think up a change to C that you would really NOT
> like to see in the language, and you should get the idea.
>
How would *you* solve the above problem?
Obviously you just do NOT want to solve it, and leave the problem
untouched. That way, C libraries can't share any general containers,
and newcomers are put off by needing to code a linked list for the
thousandth time.
> By the way, I'm not particularly against the idea of introducing operator
> overloading into C (although many people probably are).
Until now you have always attacked me because I dared not only to
say
"I am not against it"
but proposed a concrete implementation to do exactly that.
> But politicking
> about it in comp.lang.c isn't going to get you anywhere.
I am trying to convince people that what I am proposing is a better
alternative. Why should I stay away from a discussion here?
> It's the ISO
> people, not us, that you have to convince, and they are going to take a
> lot of convincing after the drubbing they took over C99.
>
They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c. Any time I have proposed there
to change anything like even get rid of a buffer overflow in asctime()
the negative reaction of those people was almost unanimous.
For instance I proposed to get rid of trigraphs. Just read that
discussion.
Keith Thompson
> Richard Heathfield wrote:
>> jacob navia said:
>>> Ben Bacarisse wrote:
>> <snip>
>>
>>>> Because
>>>> there is no agreed way to program a flexible array, a list or a map,
>>>> everyone writes their own, or uses a published one that is
>>>> incompatible with all the other published ones out there. It is often
>>>> a lot of work just to coax two libraries to work together.
>>> That is why I have been insisting that we adopt the operator overloading
>>> feature that would allow using the '[' and ']' notation for general
>>> containers.
>> I don't think you're in a position to insist, are you? Not even
>> Microsoft is in a position to insist on a change to the C
>> language. In fact, not even Dennis Ritchie is in that position.
>>
>
> I know your position. Let's do nothing, and leave C to die a
> peaceful death.
Your gross misrepresentations of other people's opinions are really
getting old. It's possible to disagree with people without being
hostile, but you don't seem to have the knack.
To be clear, your silly parody, "Let's do nothing, and leave C to die
a peaceful death", does not resemble anything Richard has ever written
as far as I know.
[...]
> They will never do anything since their main objective is to preserve
> C as a language that should run legacy code with no new development,
> as Mr Gwyn explained in comp.std.c.
I don't recall Doug Gwyn ever saying that, and I'm certainly not going
to take your word for it. Please post the Message-ID of an article in
which he said that.
> Any time I have proposed there
> to change anything like even get rid of a buffer overflow in asctime()
> the negative reaction of those people was almost unanimous.
In that discussion, there were several concrete proposals to change
the specification of asctime.
Most of the negative reactions were in response to your stubborn
refusal to acknowledge that your proposal would change the behavior of
asctime in circumstances where that behavior is now unambiguously (but
strangely) defined. I said, several time, that I'd be willing to
accept your proposal *if* that fact were acknowledged (not that I have
any say in the matter), but you wouldn't compromise even that much.
And for the Nth time, the problem with asctime isn't that it's
possible to trigger a buffer overflow by using it incorrectly, it's
that the conditions under which that buffer overflow is triggered are
not stated clearly enough. strcpy can trigger a buffer overflow just
as easily as asctime can.
> For instance I proposed to get rid of trigraphs. Just read that
> discussion.
I did read it. Concrete examples were presented of systems on which
trigraphs are still in use. And it was pointed out that the problems
that can be caused by accidental trigraphs are rare, and can be
addressed by issuing warnings when their use might be accidental.
I wouldn't oppose dropping trigraphs from the language, but again,
such a change would alter the behavior of some programs whose behavior
is now unambiguously defined. And if a new C2008 standard were issued
tomorrow, identical to C99 but with trigraphs eliminated, programmers
would still have to deal with the possibility that their code might be
used with older compilers that still support trigraphs.
As long as you refuse to acknowledge the importance of backward
compatibility, even in cases that *you* think are unimportant, it will
be difficult to take your proposals seriously.
If I had as many smart people disagreeing with me as you do, I'd start
to consider very seriously the possibility that I might be wrong.
--
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"
Flash Gordon
<snip>
> But there *is* an important issue here. Perl's modules work well
> together because of the dynamic type system, and the fact that Perl
> has very flexible containers. Using C, you may be able to find a
> great XML parsing library (for example) but it will probably represent
> its lists and tables using different types (and access functions) to
> all the other libraries you need. This is why Perl is so good at
> "gluing" tasks.
Hmm. I had no major problems stitching together an XML processing
library (and the xslt and xmlsec libraries built on top of it) and
libraries for communicating over the internet in various forms, and
custom in-house libraries that still use their own customer data
structures. All of this in C (plus networking extensions obviously). You
just have to pick the right libraries.
> This is the elephant in the room as far as C is concerned. Because
> there is no agreed way to program a flexible array, a list or a map,
> everyone writes their own, or uses a published one that is
> incompatible with all the other published ones out there. It is often
> a lot of work just to coax two libraries to work together.
Sometimes it is, sometimes it is hard. Sometimes stitching things
together in Perl is a right pain.
--
Flash Gordon
Richard Heathfield
> Richard Heathfield wrote:
>> jacob navia said:
>>
>>> Ben Bacarisse wrote:
>>
>> <snip>
>>
>>>> Because
>>>> there is no agreed way to program a flexible array, a list or a map,
>>>> everyone writes their own, or uses a published one that is
>>>> incompatible with all the other published ones out there. It is often
>>>> a lot of work just to coax two libraries to work together.
>>> That is why I have been insisting that we adopt the operator
>>> overloading feature that would allow using the '[' and ']' notation for
>>> general containers.
>>
>> I don't think you're in a position to insist, are you? Not even
>> Microsoft is in a position to insist on a change to the C language. In
>> fact, not even Dennis Ritchie is in that position.
>>
>
> I know your position. Let's do nothing, and leave C to die a
> peaceful death.
Well, no, that isn't my position. But it seems you have misunderstood the
point I was making, and I have no particular desire to explain the
blindingly obvious twice over.
<snip>
>> By the way, I'm not particularly against the idea of introducing
>> operator overloading into C (although many people probably are).
>
> Until now you have always attacked me because I dared not only to
> say
>
> "I am not against it"
>
> but proposed a concrete implementation to do exactly that.
No, I would not be so foolish as to attack you for daring to propose a
change to the C language. I'm just curious as to why you propose it here,
since nobody here has any authority to change the language definition
(except Larry, perhaps, since he's actually a voting member of the ISO C
Committee). It seems rather pointless.
>> But politicking
>> about it in comp.lang.c isn't going to get you anywhere.
>
> I am trying to convince people that what I am proposing is a better
> alternative.
Fine. Why not go convince the ducks in St James's Park? (Serious question,
and if you answer it seriously, the answer will reveal a serious point.)
> Why should I stay away from a discussion here?
Why should you stay away from a discussion with the ducks in St James's
Park?
>> It's the ISO
>> people, not us, that you have to convince, and they are going to take a
>> lot of convincing after the drubbing they took over C99.
>>
>
> They will never do anything
If you think so, then you're sunk, because they're the only ones who /can/
do anything.
> since their main objective is to preserve
> C as a language that should run legacy code with no new development,
So you claim.
> as Mr Gwyn explained in comp.std.c.
Cite, please. You're so completely useless at understanding what people say
that I want to see some evidence before I'll even think about believing
that claim.
> Any time I have proposed there
> to change anything like even get rid of a buffer overflow in asctime()
> the negative reaction of those people was almost unanimous.
I can think of several reasons for that, none of which does you any credit,
so I'll keep them to myself.
> For instance I proposed to get rid of trigraphs.
...and just abandon platforms with limited character sets. Nice one.
> Just read that discussion.
What's the point? It'll just be same ol' same ol'. I've read your
"discussions" before, the ones where you call people idiots and liars for
daring to have a viewpoint different from yours. No, thanks.
jacob navia
[snip]
I asked you a question Heathfield, a question that you conveniently
snipped away.
I repeat it:
How would *you* solve the above problem?
How would you make different libraries interoperate with lists,
flexible arrays, arrays, double linked lists, etc?
If I use a networking library I get a list of servers
from a dns request. I need the list package of the
net library.
If I use in the same program a file handling library I get
a list of files from a request like
"*.c"
Both lists packages will be redundant code and name clashes are
highly probable
How would *you* solve this problem?
jacob navia
> jacob navia <ja...@nospam.com> writes:
>
> [...]
>
>> They will never do anything since their main objective is to preserve
>> C as a language that should run legacy code with no new development,
>> as Mr Gwyn explained in comp.std.c.
>
> I don't recall Doug Gwyn ever saying that, and I'm certainly not going
> to take your word for it. Please post the Message-ID of an article in
> which he said that.
>
The 26 september 1997, Dennis Yelle had the idea of asking in comp.std.c:
Can we get rid of gets()?
Mr Gwyn defended keeping gets() in the standard document.
And he won. gets() is still in the C99 document.
I started a similar discussion last year, 11 years later and Mr Gwyn
was again in the group of the ultra-conservatives that want to keep
gets(), trigraphs, and vehemently deny that ANY changes should
be done.
He repeated the same position in 2004, when I started again a discussion
about gets().
And in 2007 he repeated his position. No changes, gets belong to the
language.
The same for ALL the proposals to change a minimal part of the
language. Not even blatant errors like trigraphs.
Eric Sosman
The fact that Doug Gwyn opposes one proposed change to C
does not demonstrate that he opposes or would oppose all changes.
The fact that one prime number is even does not demonstrate that
all prime numbers are even.
Even if Doug Gwyn opposed all changes, it would not follow
that he wants "to preserve C as a language that should run legacy
code with no new development." The fact that all prime numbers are
even does not mean that they are all blue.
Also, loaded terms like "ultra-conservatives," "vehemently,"
and "blatant" do not make your argument stronger, just hotter. Or
to put it differently: Your childish and irresponsible use of loaded
terms like "ultra-conservatives," "vehemently," and "blatant" do not
make your pathetic excuse for an argument stronger, just hotter,
louder, and even MORE ridiculous than usual.
Kenny McCormack
Eric Sosman <Eric....@sun.com> bloviated:
...
> Also, loaded terms like "ultra-conservatives," "vehemently,"
>and "blatant" do not make your argument stronger, just hotter. Or
>to put it differently: Your childish and irresponsible use of loaded
>terms like "ultra-conservatives," "vehemently," and "blatant" do not
>make your pathetic excuse for an argument stronger, just hotter,
>louder, and even MORE ridiculous than usual.
Calm down. Take your medicine. You'll feel better soon.
jacob navia
> Calm down. Take your medicine. You'll feel better soon.
>
Kenny, you did not answer my post...
You consider C really dead?
I mean your opinion *is* important (at least to me)
Willem
) Richard Heathfield wrote:
)
) [snip]
)
) I asked you a question Heathfield, a question that you conveniently
) snipped away.
)
) I repeat it:
) How would *you* solve the above problem?
You're begging the question.
Richard never claimed (in this thread at least) that your
solution was bad in any way.
And here's the question *you* never answered.
The question that *is* relevant:
Why do you argue about changing C *here*, in this newsgroup ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
jacob navia
> jacob navia wrote:
> ) Richard Heathfield wrote:
> )
> ) [snip]
> )
> ) I asked you a question Heathfield, a question that you conveniently
> ) snipped away.
> )
> ) I repeat it:
> ) How would *you* solve the above problem?
>
> You're begging the question.
> Richard never claimed (in this thread at least) that your
> solution was bad in any way.
>
He just snipped the question. Obviously if I asked the question
again I wanted to know what he thinks.
I did not say that he answered...
> And here's the question *you* never answered.
> The question that *is* relevant:
>
> Why do you argue about changing C *here*, in this newsgroup ?
>
Because this group discusses the C language obviously.
I presented my ideas to the comp.std.c group, many times.
I discuss them there too.
Malcolm McLean
"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
> This is the elephant in the room as far as C is concerned. Because
> there is no agreed way to program a flexible array, a list or a map,
> everyone writes their own, or uses a published one that is
> incompatible with all the other published ones out there. It is often
> a lot of work just to coax two libraries to work together.
>
campaign for 64 bit ints.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Pilcrow
wrote:
You seem to be using a very old version of perl - perhaps even perl 4.
And no perl user would use that style. The two lines before the last
bracket, for example, would probably be coded like this:
print "\t$_\n" for @dirlist;
See the modules Net::FTP or WWW::Mechanize or LWP::Simple for modern
methods.
>Using lcc-win the above program looks like this:
>
>----------------------------------------------C (lcc-win)
>int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
>----------------------------------------------C (lcc-win)
>
You can not have tested that, since there is no such directory at the
site of the University of Florida.
However, here is a one-line perl script I've actually tested:
perl -MLWP::Simple -e 'getstore "http://www.google.com","demo.html"'
You type it on the command line. It retrieves Google's home page and
stores it in the file demo.html .
But you need the module LWP::Simple to run it
(snip)
>Exactly. C has "modules", and the interface is simple and efficient.
>There is an enormous amount of C libraries around.
I am so glad to hear that. Perhaps someone would be so kind as to post
a list of them? At least the more important ones. URL's would be nice.
Keith Thompson
> Keith Thompson wrote:
>> jacob navia <ja...@nospam.com> writes:
>> [...]
>>
>>> They will never do anything since their main objective is to preserve
>>> C as a language that should run legacy code with no new development,
>>> as Mr Gwyn explained in comp.std.c.
>> I don't recall Doug Gwyn ever saying that, and I'm certainly not
>> going
>> to take your word for it. Please post the Message-ID of an article in
>> which he said that.
>>
>
> The 26 september 1997, Dennis Yelle had the idea of asking in comp.std.c:
>
> Can we get rid of gets()?
>
> Mr Gwyn defended keeping gets() in the standard document.
>
> And he won. gets() is still in the C99 document.
Ok.
> I started a similar discussion last year, 11 years later and Mr Gwyn
> was again in the group of the ultra-conservatives that want to keep
> gets(), trigraphs, and vehemently deny that ANY changes should
> be done.
Ok.
> He repeated the same position in 2004, when I started again a discussion
> about gets().
Ok.
> And in 2007 he repeated his position. No changes, gets belong to the
> language.
Ok.
> The same for ALL the proposals to change a minimal part of the
> language. Not even blatant errors like trigraphs.
Ok.
Please post the Message-ID of an article in which Doug Gwyn said that
the main objective of the C standard committee is to preserve C as a
language that should run legacy code with no new development.
Given your track record for inferring people's opinions from what they
write, I don't believe that Doug holds or has ever expressed that
opinion or anything like it. More specifically, I'm sure he thinks
that C should continue to be a language that can deal with legacy code
(so do I; do you?); I don't believe for a moment that he thinks there
should be no new develpment in C.
james...@verizon.net
> Willem wrote:
...
> > Why do you argue about changing C *here*, in this newsgroup ?
> >
>
> Because this group discusses the C language obviously.
>
> I presented my ideas to the comp.std.c group, many times.
>
> I discuss them there too.
While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal. Only a small number of committee
members participate in that group. If you really want anything to
change, you have to present your proposal to the committee, or at
least convince one of the committee members that your ideas have
sufficient merit to for that committee member to present them for you.
The committee members ore the ONLY ones who can actually make it
happen - nothing you say to anyone else will have much effect.
Further piece of advice: if and when you actually make your proposals
to the committee, please try to lay off on the slanderous accusations
that pepper your typical postings in this newsgroup. Even if those
accusations were true, you couldn't possibly expect accusations of
idiocy, incompetence, and laziness to make the people you so accuse
more willing to cooperate with you, could you?
Antoninus Twink
james...@verizon.net
> Keith Thompson wrote:
> > jacob navia <ja...@nospam.com> writes:
> >
> > [...]
> >
> >> They will never do anything since their main objective is to preserve
> >> C as a language that should run legacy code with no new development,
> >> as Mr Gwyn explained in comp.std.c.
> >
> > I don't recall Doug Gwyn ever saying that, and I'm certainly not going
> > to take your word for it. Please post the Message-ID of an article in
> > which he said that.
To which you responded (without presenting even a single Message-ID):
> The 26 september 1997, Dennis Yelle had the idea of asking in comp.std.c:
>
> Can we get rid of gets()?
>
> Mr Gwyn defended keeping gets() in the standard document.
>
> And he won. gets() is still in the C99 document.
>
> I started a similar discussion last year, 11 years later and Mr Gwyn
> was again in the group of the ultra-conservatives that want to keep
> gets(), trigraphs, and vehemently deny that ANY changes should
> be done.
>
> He repeated the same position in 2004, when I started again a discussion
> about gets().
>
> And in 2007 he repeated his position. No changes, gets belong to the
> language.
>
> The same for ALL the proposals to change a minimal part of the
> language. Not even blatant errors like trigraphs.
You've cited a lot of evidence suggesting that Doug Gwyn opposes
particular changes to the standard. That was never in question. Any
reasonable person will, occasionally, oppose particular changes to the
standard, and sometimes for reasons that are wrong. Doug has
occasionally also spoken in favor of particular changes to the
standard. Personally, I favor more changes to the standard than he
does, and fewer than you do. However, that's all very different from
your slanderous claim that
> >> They will never do anything since their main objective is to preserve
> >> C as a language that should run legacy code with no new development,
Nothing you've cited above says anything about "no new development".
Where, precisely, did Doug Gwyn (or anyone else on the committee)
express THAT opinion? And this time, please provide precise message
identification.
jacob navia
> While such a suggestion is on-topic in that group, it is still not the
> right place to make your proposal. Only a small number of committee
> members participate in that group. If you really want anything to
> change, you have to present your proposal to the committee, or at
> least convince one of the committee members that your ideas have
> sufficient merit to for that committee member to present them for you.
> The committee members ore the ONLY ones who can actually make it
> happen - nothing you say to anyone else will have much effect.
>
I need 10 thousand euros (15 000 US$) to buy the AFNOR
(French ISO organization) to present my proposal after
I got sponsored by some company.
I do not have either the sponsors nor that amount of money.
And I have repeated this MANY times, to you and to others.
And you STILL tell me to present proposals to ISO.
I do not have the financial resources for that is that clear?
> Further piece of advice: if and when you actually make your proposals
> to the committee, please try to lay off on the slanderous accusations
> that pepper your typical postings in this newsgroup. Even if those
> accusations were true, you couldn't possibly expect accusations of
> idiocy, incompetence, and laziness to make the people you so accuse
> more willing to cooperate with you, could you?
I have never said that they are idiots or lazy or whatever. You
are just lying (as you often do)
jacob navia
> jacob navia wrote:
>> Keith Thompson wrote:
>>> jacob navia <ja...@nospam.com> writes:
>>>
>>> [...]
>>>
>>>> They will never do anything since their main objective is to preserve
>>>> C as a language that should run legacy code with no new development,
>>>> as Mr Gwyn explained in comp.std.c.
>>> I don't recall Doug Gwyn ever saying that, and I'm certainly not going
>>> to take your word for it. Please post the Message-ID of an article in
>>> which he said that.
>
> To which you responded (without presenting even a single Message-ID):
>
This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
<47052645...@null.net> Thread name "C needs a BOOST"
<quote>
Ian Collins wrote:
> > My conclusion has to be that the demand isn't there.
The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.
The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
> > By the way, does the C standard committee have an active library group?
Not as a separate entity.
<end quote>
Yes, you read correctly.
"Much new development really ought to use higher level languages"
than C.
This is in essence what I said.
I remember asking him:
<quote>
Actually then, you say it is better not to develop anything new in C.
<end quote>
Then he answered:
<quote>
That's not what I said. I said that *much* new development ought
to be done in higher-level languages. (In fact, it often is.)
That means that the potential benefit of new facilities for such
applications is diminished.
> I would like that you claify this of course. Did I understand you
> correctly?
I doubt that you did.
My opinion, based on considerable experience in this area, is that
C remains the best choice for much "systems implementation" work,
but that it is more cost-effective to use other, higher-level
languages for many "applications".
I happen to prefer C for my own one-person development projects,
but then I am especially proficient in it. For larger projects,
if C is selected then much attention/supervision will be needed
to ensure that appropriate disciplines are imposed upon its use,
in order to meet goals of reliability and maintainability. There
are other languages where less effort is needed for that purpose.
Also, C is designed to give the programmer considerable control
over details, to the extent that it *requires* the programmer to
be concerned over details. Again, there are other languages
where this is less of a burden.
It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a
good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.
<end quote>
He says "it is not what I said"... then repeats everything again.
C is good only for systems work, etc etc, new development or
application dveelopment should be done in better languages, etc.
jacob navia
<end quote>
<end quote>
--
Flash Gordon
> james...@verizon.net wrote:
>> jacob navia wrote:
>>> Keith Thompson wrote:
>>>> jacob navia <ja...@nospam.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> They will never do anything since their main objective is to preserve
>>>>> C as a language that should run legacy code with no new development,
>>>>> as Mr Gwyn explained in comp.std.c.
>>>> I don't recall Doug Gwyn ever saying that, and I'm certainly not going
>>>> to take your word for it. Please post the Message-ID of an article in
>>>> which he said that.
>>
>> To which you responded (without presenting even a single Message-ID):
>
> This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
> <47052645...@null.net> Thread name "C needs a BOOST"
<snip>
> The only real use for such a library would be for new program
> development, once the learning hurdle has been overcome. Much
^^^^
> new development really ought to use higher-level languages in
> the first place.
<snip>
> Yes, you read correctly.
> "Much new development really ought to use higher level languages"
^^^^
> than C.
>
> This is in essence what I said.
No, it is very different from what you claimed he said. Much freight is
transported by ship, but that does not prevent freight from being
transported by rail, road and plane. Most Chinese speakers live in
China, yet I hear Chinese being spoken in England by people living in
England.
<snip>
> My opinion, based on considerable experience in this area, is that
> C remains the best choice for much "systems implementation" work,
> but that it is more cost-effective to use other, higher-level
> languages for many "applications".
^^^^
Many is not all.
<snip>
> It is (in my opinion) a mistake to try to push C (in any variant)
> as a general solution for all programming problems. It's a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> good choice for the systems programming that it was designed for,
> although it still has deficiencies even for that. I would rather
> the time spent discussing directions for C concentrate more on
> remedies for its remaining deficiencies for systems work than on
> trying to support applications where there are better choices.
Are you claiming that C should be used as a general solution to ALL
programming problems?
> He says "it is not what I said"... then repeats everything again.
Nowhere in what you have quoted has he said that no new development or
applications should be done in C. He has also stated that he does want
some changes to the language, for how can the deficiencies be remedied
without changing the language?
> C is good only for systems work, etc etc,
You are miss-quoting here what you have quoted above.
> new development or
> application dveelopment should be done in better languages, etc.
He said much, not all.
--
Flash Gordon
jacob navia
>
> Are you claiming that C should be used as a general solution to ALL
> programming problems?
>
Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...
You apparently are of the same opinion.
By leaving application programming for other languages, you
effectively destroy C.
Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.
I am claiming that C can be used for general application
programming. It needs just a single modification
(operator overloading) and a rewrite of the standard library
to be able to be very useful in application programming.
Why?
Because it is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.
I am opposed to most current trends in language development exactly
because I think that simplicity is a virtue and simple things are
basically much more powerful than complicated ones.
Pilcrow
Thank you sir; that's a beginning.
james...@verizon.net
> james...@verizon.net wrote:
> > While such a suggestion is on-topic in that group, it is still not the
> > right place to make your proposal. Only a small number of committee
> > members participate in that group. If you really want anything to
> > change, you have to present your proposal to the committee, or at
> > least convince one of the committee members that your ideas have
> > sufficient merit to for that committee member to present them for you.
> > The committee members ore the ONLY ones who can actually make it
> > happen - nothing you say to anyone else will have much effect.
> >
>
> I need 10 thousand euros (15 000 US$) to buy the AFNOR
> (French ISO organization) to present my proposal after
> I got sponsored by some company.
Then join ANSI instead. Membership is not restricted to organizations;
individuals can join as well. It is not restricted to US citizens; in
fact a large number of its members are foreign citizens like you who
were unable to afford their own national body's prohibitively high
fees. The Basic membership fee is currently $495, easily within the
range that could be afforded by most professionals. Actually attending
meetings is required only if you want to be a voting member.
I confess to a certain amount of uncertainty about the organizational
connections here; hopefully someone here can fill out the details. I
know that ANSI is listed as participating in ISO/IEC JTC 1, but that
the US Technical Advisory Group for ISO/IEC JTC1/SC22 is INCITS.
INCITS membership is not cheap, and I could find nothing to suggest
that it is open to individuals. I was under the impression that it is
possible to participate in the C standardization process as an
individual member of ANSI, but I can't find anything that clarifies
that it is possible to do so without being a member of INCITS.
> > Further piece of advice: if and when you actually make your proposals
> > to the committee, please try to lay off on the slanderous accusations
> > that pepper your typical postings in this newsgroup. Even if those
> > accusations were true, you couldn't possibly expect accusations of
> > idiocy, incompetence, and laziness to make the people you so accuse
> > more willing to cooperate with you, could you?
>
> I have never said that they are idiots or lazy or whatever. You
> are just lying (as you often do)
No, I'm just summarizing. You've accused the committee of wanting C to
be a language restricted to use on legacy code, with no new
development. With no new development, it would be pointless for
committee members to paying hard-earned money for membership fees that
buy them the privilege of putting in hard work on changes to the
standard. Who in their right minds would make such sacrifices to
achieve such a pointless goal? By making such a ridiculous accusation
you're implying that they are at least idiots, if not certifiably
insane.
Keith Thompson
> Keith Thompson wrote:
>> jacob navia <ja...@nospam.com> writes:
>>> Keith Thompson wrote:
>>>> jacob navia <ja...@nospam.com> writes:
>>>> [...]
>>>>
>>>>> They will never do anything since their main objective is to preserve
>>>>> C as a language that should run legacy code with no new development,
>>>>> as Mr Gwyn explained in comp.std.c.
>>>> I don't recall Doug Gwyn ever saying that, and I'm certainly not
>>>> going
>>>> to take your word for it. Please post the Message-ID of an article in
>>>> which he said that.
> This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
> <47052645...@null.net> Thread name "C needs a BOOST"
>
>
> <quote>
> Ian Collins wrote:
>> > My conclusion has to be that the demand isn't there.
>
> The very age of C might be partly responsible, in that the vast
> amount of existing C applications already embed some solutions
> to the requirements for lists, etc. The maintenance programmer
> (a)is unlikely to rework the existing app just to use some new
> standardized interface for the same thing; and (b) has to
> continue to maintain whatever libraries he has been using.
>
> The only real use for such a library would be for new program
> development, once the learning hurdle has been overcome. Much
> new development really ought to use higher-level languages in
> the first place.
There is a difference between your claim that he said there should be
"no new development", and his actual statement that "Much new
development really ought to use higher-level languages in the first
place."
Just as I've come to expect, you have grossly misrepresented what he
actually wrote.
[...]
> Yes, you read correctly.
> "Much new development really ought to use higher level languages"
> than C.
>
> This is in essence what I said.
Nonsense.
> I remember asking him:
> <quote>
> Actually then, you say it is better not to develop anything new in C.
> <end quote>
>
> Then he answered:
> <quote>
> That's not what I said. I said that *much* new development ought
> to be done in higher-level languages. (In fact, it often is.)
He even told you that you had misrepresented his words.
[snip]
> He says "it is not what I said"... then repeats everything again.
>
> C is good only for systems work, etc etc, new development or
> application dveelopment should be done in better languages, etc.
Which, one more time, is not what he said.
Learn to read.
james...@verizon.net
> james...@verizon.net wrote:
> > jacob navia wrote:
> >> Keith Thompson wrote:
> >>> jacob navia <ja...@nospam.com> writes:
> >>>
> >>> [...]
> >>>
> >>>> They will never do anything since their main objective is to preserve
> >>>> C as a language that should run legacy code with no new development,
> >>>> as Mr Gwyn explained in comp.std.c.
> >>> I don't recall Doug Gwyn ever saying that, and I'm certainly not going
> >>> to take your word for it. Please post the Message-ID of an article in
> >>> which he said that.
> This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
> <47052645...@null.net> Thread name "C needs a BOOST"
> development, once the learning hurdle has been overcome. Much
> new development really ought to use higher-level languages in
> the first place.
> Yes, you read correctly.
> "Much new development really ought to use higher level languages"
> than C.
Quite a reaonable statement, and not at all what you claimed he said.
> This is in essence what I said.
No, "much" is quite different from "all". The first makes for an
entirely reasonable statement; replacing "much" with "all" would
produce a preposterous statement, and one that Doug Gwyn did NOT make.
> I remember asking him:
> <quote>
> Actually then, you say it is better not to develop anything new in C.
> <end quote>
>
> Then he answered:
> <quote>
> That's not what I said. I said that *much* new development ought
^^^^^^^^^^^^^^^^^^^^^
> to be done in higher-level languages. (In fact, it often is.)
Note the use of the word "much" rather than "all".
> That means that the potential benefit of new facilities for such
> applications is diminished.
>
> > I would like that you claify this of course. Did I understand you
> > correctly?
>
> I doubt that you did.
^^^^^^^^^^^^^^^^^^^^
> My opinion, based on considerable experience in this area, is that
> C remains the best choice for much "systems implementation" work,
> but that it is more cost-effective to use other, higher-level
> languages for many "applications".
Note the key word "many". Not "all", "many". Understand the
difference.
...
> He says "it is not what I said"... then repeats everything again.
Yes, because you quite clearly did not understand it the first time.
You still do not - you still make the mistake of confusing "many" with
"all". Are you consistent in this misconception? If I told you that
the total value of all of my stocks exceeded $500K, and offered to
sell you "many" of my stocks for a mere $200K, would you be under the
misapprehension that I was offering you a good deal? If so, I've got
quite a number of similarly "good deals" I'd be willing to discuss
with you.
Bartc
news:lnzlmos...@nuthaus.mib.org...
Reading the quoted text of Mr Gwyn, it does appear to show considerable bias
against interesting new developments in C, in fact appearing to be backward
looking rather than forward looking.
The attitude seemed to be that there's no point in adding new stuff to C
because (a) it's not much use for programmers maintaining existing code; (b)
for new code, it's better to use a 'better' language. So, forget it.
And, C apparently only just cuts it for systems programming, let alone
general programming. In it's present standard form, he might be right, but
seemed completely against the idea of improving C to make it more suitable,
which is what Jacob is trying to do.
>> C is good only for systems work, etc etc, new development or
>> application dveelopment should be done in better languages, etc.
>
> Which, one more time, is not what he said.
Er, I think he did:
"
It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a
good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.
"
--
Bartc
Keith Thompson
Perhaps, but there's a clear contradiction between what Doug Gwyn
actually said and what jacob nava claims Doug Gwyn said.
Doug Gywn said that "Much new development really ought to use
higher-level languages in the first place."
jacob navia claimed that Doug Gwyn said that "their [the committee's]
main objective is to preserve C as a language that should run legacy
code with no new development".
You can agree or disagree with what Doug actually said, but it's very
different from jacob's (deliberate?) misrepresentation.
[snip]
Richard Heathfield
> james...@verizon.net wrote:
<snip>
>> Further piece of advice: if and when you actually make your proposals
>> to the committee, please try to lay off on the slanderous accusations
>> that pepper your typical postings in this newsgroup. Even if those
>> accusations were true, you couldn't possibly expect accusations of
>> idiocy, incompetence, and laziness to make the people you so accuse
>> more willing to cooperate with you, could you?
>
> I have never said that they are idiots or lazy or whatever. You
> are just lying (as you often do)
If I've counted properly, it has taken till your sixth reply in this
subthread to start with the stupid accusations. What took you so long?
Should we be worried? Do you need a doctor?
Richard Heathfield
>
> "Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
>> This is the elephant in the room as far as C is concerned. Because
>> there is no agreed way to program a flexible array, a list or a map,
>> everyone writes their own, or uses a published one that is
>> incompatible with all the other published ones out there. It is often
>> a lot of work just to coax two libraries to work together.
>>
> I still have some "give me 64" mugs left.
I'd have thought you'd still have all but one of them left (presumably
you've reserved one for yourself).
> I trust you are now joining the campaign for 64 bit ints.
Why? They're legal already. In any case, one day they will be too small.
Ian Collins
>
> <quote>
> Ian Collins wrote:
>> > My conclusion has to be that the demand isn't there.
>
> The very age of C might be partly responsible, in that the vast
> amount of existing C applications already embed some solutions
> to the requirements for lists, etc. The maintenance programmer
> (a)is unlikely to rework the existing app just to use some new
> standardized interface for the same thing; and (b) has to
> continue to maintain whatever libraries he has been using.
>
> The only real use for such a library would be for new program
> development, once the learning hurdle has been overcome. Much
> new development really ought to use higher-level languages in
> the first place.
>
>> > By the way, does the C standard committee have an active library group?
>
> Not as a separate entity.
>
earlier conclusions. There were requirements for higher level
application programming languages with more abstract libraries. C
didn't evolve to fill the gap, so new languages were developed. The
most successful (in terms of adoption) languages aren't the most
expressive, or elegant but the ones with the most useful libraries.
Many of these are well established C libraries wrapped and in a thin
veneer and bundled with the language distribution. C has lost the
mindshare in hosted applications programming and there's little point in
trying to win it back. To do so invites comparisons with that great
English hero King Canute.
One only has to compare the activities of the current C++ and C
committees to see which one is working on an evolving language. I'd be
pleasantly surprised to see the C programming community get as excited
about the next C standard as the C++ programming community is about theirs.
--
Ian Collins.
Richard Heathfield
<snip>
> C has lost the
> mindshare in hosted applications programming and there's little point in
> trying to win it back.
Am I the only one who isn't particularly bothered about this? Let people
write applications in whatever language /they/ want, as long as they leave
me to write them in whatever language /I/ want. I choose C (often - not
always). If they want to use C# or F# or Eb or D minor, that's up to them
- who cares?
> To do so invites comparisons with that great
> English hero King Canute.
A much-misunderstood man, who had a far better understanding of reality
than did his courtiers.
> One only has to compare the activities of the current C++ and C
> committees to see which one is working on an evolving language. I'd be
> pleasantly surprised to see the C programming community get as excited
> about the next C standard as the C++ programming community is about
> theirs.
The principal advantage of an unstable language is that you can add bits to
it. The principal advantage of a stable language is that you know what all
the bits are. Both are good, but you can't have both in the same language.
Ian Collins
> Ian Collins said:
>
> <snip>
>
>> C has lost the
>> mindshare in hosted applications programming and there's little point in
>> trying to win it back.
>
> Am I the only one who isn't particularly bothered about this? Let people
> write applications in whatever language /they/ want, as long as they leave
> me to write them in whatever language /I/ want. I choose C (often - not
> always). If they want to use C# or F# or Eb or D minor, that's up to them
> - who cares?
>
>
>> One only has to compare the activities of the current C++ and C
>> committees to see which one is working on an evolving language. I'd be
>> pleasantly surprised to see the C programming community get as excited
>> about the next C standard as the C++ programming community is about
>> theirs.
>
> The principal advantage of an unstable language is that you can add bits to
> it. The principal advantage of a stable language is that you know what all
> the bits are. Both are good, but you can't have both in the same language.
>
A bit like Latin and English?
I think the activities of the two committees reflect the desire for
change in the user communities. Well before the 1998 C++ standard was
published, most compiler vendors were shipping compilers with most of
the new features. This was followed by a post standard rush to bring
out conforming compilers. Contrast this with C99.
It wasn't only the desire for change, but the nature of the changes.
Most C++ programmers wanted the new features, hardly any C programmers
appear to want most of C99.
So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.
--
Ian Collins.
Richard Heathfield
> Richard Heathfield wrote:
<snip>
>> The principal advantage of an unstable language is that you can add bits
>> to it. The principal advantage of a stable language is that you know
>> what all the bits are. Both are good, but you can't have both in the
>> same language.
>>
> A bit like Latin and English?
Quidquid C dictum sit, altum viditur.
> I think the activities of the two committees reflect the desire for
> change in the user communities. Well before the 1998 C++ standard was
> published, most compiler vendors were shipping compilers with most of
> the new features. This was followed by a post standard rush to bring
> out conforming compilers. Contrast this with C99.
Perhaps fairer to compare it with C*8*9, where there was a *pre*-standard
rush to bring out conforming compilers.
>
> It wasn't only the desire for change, but the nature of the changes.
> Most C++ programmers wanted the new features, hardly any C programmers
> appear to want most of C99.
That's because C99's changes were the *wrong* changes.
> So my point is C fills its (large) niche very well and the only
> worthwhile changes are small improvements (like mandating function
> prototypes and expunging gets) to improve the quality of C code.
Actually, the really worthwhile changes are never going to happen. For
example, I do actually think it would be worth adding operator overloading
to C - but I know that ISO is never going to buy that, and I don't see any
point in fighting a losi... well, not /that/ losing battle, anyway.
Richard Bos
> Kenny McCormack wrote:
>
> > Calm down. Take your medicine. You'll feel better soon.
>
> Kenny, you did not answer my post...
So, you take a slug of your own medicine... like it, do you?
Richard
Ian Collins
> Ian Collins said:
>
>> worthwhile changes are small improvements (like mandating function
>> prototypes and expunging gets) to improve the quality of C code.
>
> Actually, the really worthwhile changes are never going to happen. For
> example, I do actually think it would be worth adding operator overloading
> to C - but I know that ISO is never going to buy that, and I don't see any
> point in fighting a losi... well, not /that/ losing battle, anyway.
>
offering operator overloading as an extension? It's probably fair to
assume they have the finger on the pulse of what a large percentage of
C programmers want. The useful subset of C99 additions had been
extensions in a lot of compilers for years before they were standardised.
--
Ian Collins.
jacob navia
> Richard Heathfield wrote:
>> Ian Collins said:
>>
>>> So my point is C fills its (large) niche very well and the only
>>> worthwhile changes are small improvements (like mandating function
>>> prototypes and expunging gets) to improve the quality of C code.
>> Actually, the really worthwhile changes are never going to happen. For
>> example, I do actually think it would be worth adding operator overloading
>> to C - but I know that ISO is never going to buy that, and I don't see any
>> point in fighting a losi... well, not /that/ losing battle, anyway.
>>
> I'm sure they would be, but how many embedded C compiler vendors are
> offering operator overloading as an extension?
Operator overloading is not an objective per se. It is a means of making
libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:
data[2]
to acces the third element of a list/array/other
Operator overloading is needed to implement fixed point arithmetic, what
is needed in many small CPUs that do not implement floating point.
Ian Collins
do dispute is the demand. As I said in the bit you snipped, the good
bits of C99 where around for a long time before they were standardised
because there was a demand for them. What extensions are most vendors
offering now?
--
Ian Collins.
James Kuyper
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnzlmos...@nuthaus.mib.org...
>> jacob navia <ja...@nospam.com> writes:
...
>>> Yes, you read correctly.
>>> "Much new development really ought to use higher level languages"
>>> than C.
>>>
>>> This is in essence what I said.
>>
>> Nonsense.
>
> Reading the quoted text of Mr Gwyn, it does appear to show considerable
> bias against interesting new developments in C, in fact appearing to be
> backward looking rather than forward looking.
It's not clear, however, whether the bias he shows is excessive, or a
bias that is entirely appropriate. From my experience with him, my
impression is that he's very much a defender of the words of the current
standard against most changes - but that's primarily because he thinks
that most of the many defects in the standard should be dealt with by
having the reader apply a bizarre mind-reading technique which he calls
"common sense", rather than by having the committee fix the words of the
standard to say what it was actually intended to say.
However, he's not against change itself. He just thinks it should occur
slower and with more consideration and in a different direction than
what jacob wants.
> The attitude seemed to be that there's no point in adding new stuff to C
You're making exactly the same mistake jacob did. You're converting
statements that favor making few changes into statements that favor
making no change, and that's a misrepresentation of Doug's position.
> because (a) it's not much use for programmers maintaining existing code;
> (b) for new code, it's better to use a 'better' language. So, forget it.
Again, you're misrepresenting him by converting statements that say that
"much" code should be done in other languages into statements that "all"
code should be done in other languages.
> And, C apparently only just cuts it for systems programming, let alone
> general programming. In it's present standard form, he might be right,
> but seemed completely against the idea of improving C to make it more
> suitable, which is what Jacob is trying to do.
No - he's in favor of improving C, and disagrees with jacob about
whether jacob's proposed changes would have that effect. Since a lot of
other smart people who like programming in C agree with him in that
regard, you might want to consider the possibility that it's the nature
of the proposed change that is the problem, not just the simple fact
that it is a change.
>>> C is good only for systems work, etc etc, new development or
>>> application dveelopment should be done in better languages, etc.
>>
>> Which, one more time, is not what he said.
>
> Er, I think he did:
>
> "
> It is (in my opinion) a mistake to try to push C (in any variant)
> as a general solution for all programming problems. It's a
> good choice for the systems programming that it was designed for,
> although it still has deficiencies even for that. I would rather
> the time spent discussing directions for C concentrate more on
> remedies for its remaining deficiencies for systems work than on
> trying to support applications where there are better choices.
> "
Once again, you're converting non-absolute statements into absolute
ones. To show you how you've misinterpreted, I'll rewrite it so that it
actually supports your misinterpretation:
DISCLAIMER: THIS IS NOT MY OPINION - IT IS NOT DOUG'S OPINION - IT IS
NOT ANYONE'S OPINION, AFAIK:
"It is a mistake to try to push C (in any variant) as a solution for any
programming problem other than the systems programming tasks that it was
designed for, although it still has deficiencies even for that. Time
spent discussing directions for C should be exclusively spend on
remedying its remaining deficiencies for systems work, and not on trying
to support applications where there is always a better choice."
Can you see the difference between my re-write and what he actually
said? Do you understand that your statements apply only to my rewrite,
and not to the original? I only changed a few words, but the result is
that it converts a legitimate point of view (which I don't fully share)
into a statement that could only be made by an idiot.
Antoninus Twink
> Perhaps, but there's a clear contradiction between what Doug Gwyn
> actually said and what jacob nava claims Doug Gwyn said.
>
> Doug Gywn said that "Much new development really ought to use
> higher-level languages in the first place."
>
> jacob navia claimed that Doug Gwyn said that "their [the committee's]
> main objective is to preserve C as a language that should run legacy
> code with no new development".
>
> You can agree or disagree with what Doug actually said, but it's very
> different from jacob's (deliberate?) misrepresentation.
Bullshit. It's strikingly similar. If you remove your fundamentalist
glasses for a second, you'll see that Jacob has expressed the same
thought in different words. It's called paraphrase, and that doesn't
make it a misrepresentation.
Antoninus Twink
> Quidquid C dictum sit, altum viditur.
You mean videtur.
If you're going to ponce around like a pretentious dick, at least get it
right.
Antoninus Twink
> Operator overloading is not an objective per se. It is a means of
> making libraries that use lists, flexible arrays and other sequential
> containers interoperable using the same notation:
>
> data[2]
>
> to acces the third element of a list/array/other
Trouble is, you quickly end up pulling in a whole load of other stuff
too. You start out thinking how nice it is to be able to write
c=(a+b)*d;
instead of
mpf_add(c, a, b);
mpf_mul(c, c, d);
and then before you know it you've got overloaded functions because
b=sqrt(a);
is simpler than
mpf_sqrt(b, a);
Then it's iterators so that you can meaningfully overload ++ to index
your list/array/other...
And before you know it, you've got a horrible mess...
jacob navia
> On 4 Sep 2008 at 9:02, jacob navia wrote:
>> Operator overloading is not an objective per se. It is a means of
>> making libraries that use lists, flexible arrays and other sequential
>> containers interoperable using the same notation:
>>
>> data[2]
>>
>> to acces the third element of a list/array/other
>
> Trouble is, you quickly end up pulling in a whole load of other stuff
> too. You start out thinking how nice it is to be able to write
>
> c=(a+b)*d;
>
This is nice
> instead of
>
> mpf_add(c, a, b);
> mpf_mul(c, c, d);
>
That is ugly.
> and then before you know it you've got overloaded functions because
>
> b=sqrt(a);
>
> is simpler than
>
> mpf_sqrt(b, a);
>
lcc-win provides overloaded functions already. Not a big deal.
> Then it's iterators so that you can meaningfully overload ++ to index
> your list/array/other...
>
Surely not. That doesn't follow at all. Why it is so complicated
to write a loop?
> And before you know it, you've got a horrible mess...
>
If you do not know how to stop!
Your argument is similar to this:
Antoninus: DO NOT DRINK MILK!!!!
Jacob: But... Why? Milk is tasteful and good for your health.
Antoninus: Yes, but then you drink 8 liters and you are DEAD!
Antoninus Twink
> Antoninus Twink wrote:
>> And before you know it, you've got a horrible mess...
>
> If you do not know how to stop!
Sure... unfortunately the main historical example is Bjarne Stroustoup,
who definitely didn't know how to stop!
Personally I see nothing wrong with writing
C-with-the-odd-nice-C++-feature and compiling it with a C++ compiler.
Kenny McCormack
>Kenny McCormack wrote in response to loony Eric Sosman:
>
>> Calm down. Take your medicine. You'll feel better soon.
>>
But then Jacob picked up the ball thusly:
>Kenny, you did not answer my post...
>
>You consider C really dead?
>
>I mean your opinion *is* important (at least to me)
Well, thank you for that.
Basically, my opinion is irrelevant (in this context). My purpose in
posting was to alert the newbie to the nature of this newsgroup. Sort
of a "newbie's guide to CLC. Despite the name, this is *not* a
technical newsgroup!". So, at least for the moment, I was parrotting
the view held by the regs (which is that it is for legacy and embedded
only, since their highly restrictive definition of what C is makes it
impossible to do anything interesting in it). This is the view held by
the CLC regs, aka, the Heathfield clique. Heathfield (et al) of course,
denies it all (lying as they always do).
In the "for what it is worth" department...
My own opinion on C is that it is still useful as a systems language
(that is, for building OSs and other useful tools), but since this is
completely outside the scope (read: off topic, not portable, blah, blah,
blah) of this NG, you're kinda stuck. Finally, no, I don't think that,
in 2008, C is an honest choice for new development at the purely
applications level.
Pilcrow
But a knowledge of C seems to be a prerequisite for learning some other
things, such as Win32, various GUIs, certain modules in Perl, etc. which
are useful for applications.
----
Everybody needs somebody that they can look down on.
If you ain't got noone else, why, help yourself to me.
Bartc
"James Kuyper" <james...@verizon.net> wrote in message
news:AlPvk.565$Wd.61@trnddc01...
It's not too hard to read between the lines of the original. Clearly he has
the skills to put across what he thinks without making any hard and fast
commitments. Tact and diplomacy I think it's called.
But the same ideas have been expressed by others in this thread. So in the
clc world at least Jacob seems to be fighting a losing battle in getting any
official support for his work.
--
Bartc
Richard Heathfield
> On Thu, 4 Sep 2008 17:57:32 +0000 (UTC), gaz...@shell.xmission.com
> (Kenny McCormack) wrote:
<snip>
>>Finally, no, I don't think that,
>>in 2008, C is an honest choice for new development at the purely
>>applications level.
>
> But a knowledge of C seems to be a prerequisite for learning some other
> things, such as Win32, various GUIs, certain modules in Perl, etc. which
> are useful for applications.
Right. It's also a really-nice-to-have for reading technical docs, since
they are often illustrated with C fragments (cases in point:
Aho-Sethi-Ullman (the Dragon Book), Petzold (Programming Windows), Knuth
(TAOCP)). It's good for writing libraries, since so many languages can
link to C libraries nowadays.
And of course it's good for new development at the applications level, if
it's the language that suits you best for that need. For some, it's the
right choice. For others, it isn't. Sweeping generalisations need not
apply.
BTW before taking Kenny McCormack too seriously, check out his technical
contributions to this group (if you can find any).
Malcolm McLean
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
>
> And of course it's good for new development at the applications level, if
> it's the language that suits you best for that need. For some, it's the
> right choice. For others, it isn't. Sweeping generalisations need not
> apply.
>
environment. Personally I like almost everything in C. However I will knock
up a few Perl scripts to avoid hardcoding paths into C source - they seldom
do anything much I couldn't do as easily in C - and then I've got legacy
Fortran 77 to "maintain".
You get into the way of Fortran 77 coding after a while. Basically you've
got do loops, arrays, if blocks, and gotos. Nothing much else. It's a very
pure programming experience.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
james...@verizon.net
> "James Kuyper" <james...@verizon.net> wrote in message
> news:AlPvk.565$Wd.61@trnddc01...
> > Bartc wrote:
> >> "Keith Thompson" <ks...@mib.org> wrote in message
> >> news:lnzlmos...@nuthaus.mib.org...
> >>> jacob navia <ja...@nospam.com> writes:
> >> "
> >> It is (in my opinion) a mistake to try to push C (in any variant)
> >> as a general solution for all programming problems. It's a
> >> good choice for the systems programming that it was designed for,
> >> although it still has deficiencies even for that. I would rather
> >> the time spent discussing directions for C concentrate more on
> >> remedies for its remaining deficiencies for systems work than on
> >> trying to support applications where there are better choices.
> >> "
> >
> > Once again, you're converting non-absolute statements into absolute ones.
> > To show you how you've misinterpreted, I'll rewrite it so that it actually
> > supports your misinterpretation:
> >
> > DISCLAIMER: THIS IS NOT MY OPINION - IT IS NOT DOUG'S OPINION - IT IS NOT
> > ANYONE'S OPINION, AFAIK:
> > "It is a mistake to try to push C (in any variant) as a solution for any
> > programming problem other than the systems programming tasks that it was
> > designed for, although it still has deficiencies even for that. Time spent
> > discussing directions for C should be exclusively spend on remedying its
> > remaining deficiencies for systems work, and not on trying to support
> > applications where there is always a better choice."
> >
> > Can you see the difference between my re-write and what he actually said?
> > Do you understand that your statements apply only to my rewrite, and not
> > to the original? I only changed a few words, but the result is that it
> > converts a legitimate point of view (which I don't fully share) into a
> > statement that could only be made by an idiot.
>
> It's not too hard to read between the lines of the original.
If, by "read between the lines", you mean converting a legitimate
point of view that was actually expressed into a ridiculous point of
view that he did not express, and which is not at all what I think he
actually intended -- well, I have to agree; it is easy. Not everything
that is easy to do is something that you should actually do.
> But the same ideas have been expressed by others in this thread.
If you mean "the same ideas he actually expressed", then yes, similar
ideas have been expressed elsewhere. If, on the other hand, you mean
the slanderously ridiculous ideas that his words have been
misinterpreted as expressing, then no, I don't think that anyone has
expressed support for those ideas, or for any ideas remotely
resembling them.
> ... So in the
> clc world at least Jacob seems to be fighting a losing battle in getting any
> official support for his work.
If that's what he was trying to achieve, then his battle was doomed to
failure before it even began, because he choose to fight it in the
wrong place. clc is nowhere near to being the right place to obtain
official support for his work. It's like battling to gain control of
Afghanistan by sending your troops to Peru. He's got to present his
ideas to the committee, either directly or by convincing some
committee member that his ideas have sufficient merit to justify that
committee member to present them instead. If this seems unfair, keep
in mind that that in order to actually win, a majority of the
committee members will have to be convinced of the merit of his ideas;
convincing a single committee member is just the first step.
It would also help if his ideas actually had merit - but that's a
separate issue, and by definition it's one he's unlikely to agree with
me about.
Malcolm McLean
"Richard Heathfield" <r...@see.sig.invalid> wrote in message news
> Malcolm McLean said:
>
>> I trust you are now joining the campaign for 64 bit ints.
>
> Why? They're legal already. In any case, one day they will be too small.
>
I don't think we will actually run out of integers with 64 bits. With 32
bits yes, you can't quite give one to everyone in the world. But 64 bits
aren't going to have that problem for a long time yet.
Lassie
"jacob navia" <ja...@nospam.com> schreef in bericht
news:g9o87r$c21$1...@aioe.org...
> Ian Collins wrote:
>> Richard Heathfield wrote:
>>> Ian Collins said:
>>>
>>>> So my point is C fills its (large) niche very well and the only
>>>> worthwhile changes are small improvements (like mandating function
>>>> prototypes and expunging gets) to improve the quality of C code.
>>> Actually, the really worthwhile changes are never going to happen. For
>>> example, I do actually think it would be worth adding operator
>>> overloading to C - but I know that ISO is never going to buy that, and I
>>> don't see any point in fighting a losi... well, not /that/ losing
>>> battle, anyway.
>>>
>> I'm sure they would be, but how many embedded C compiler vendors are
>> offering operator overloading as an extension?
>
> Operator overloading is not an objective per se. It is a means of making
> libraries that use lists, flexible arrays and other sequential
> containers interoperable using the same notation:
>
> data[2]
>
> to acces the third element of a list/array/other
I really would not implement operator[] for a linked list. operator[] has
the semantics of being a random access operator. A linked list is not a data
stucture one would use when random access is needed and operator[] would
have to loop to the correct index every time which is suddenly invisible
from the programmer.
jacob navia
Well, if you are using a list and you need the nth element you will
have to start at the start and go to the nth. That is because of the
data structure used.
When you see that you are accessing random elements you change your
declaration to a flexible array and you have more efficient random
access. And you do not need to change the code.
I agree that operator overloading has its drawbacks within this context.
Specially because even if it *can* be used to standardize access to
sequential containers, it needs furthe standards to be able to define
the operations in a meaningful way (like First, next, last, etc).
lawrenc...@siemens.com
>
> How would you make different libraries interoperate with lists,
> flexible arrays, arrays, double linked lists, etc?
Like the old joke says: If I were going there, I wouldn't be starting
from here.
--
Larry Jones
Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin
lawrenc...@siemens.com
>
> No, I would not be so foolish as to attack you for daring to propose a
> change to the C language. I'm just curious as to why you propose it here,
> since nobody here has any authority to change the language definition
> (except Larry, perhaps, since he's actually a voting member of the ISO C
> Committee). It seems rather pointless.
Actually, at the moment I'm not a voting member of the committee. I am,
however, the document editor. Which role provides more *authority* to
change the language definition I can't say, but the latter role
certainly provides more *opportunity* to do so. :-)
--
Larry Jones
I hate being good. -- Calvin
lawrenc...@siemens.com
>
> I need 10 thousand euros (15 000 US$) to buy the AFNOR
> (French ISO organization) to present my proposal after
> I got sponsored by some company.
That's not necessary -- committee meetings are open to the public.
Anyone is welcome to attend and participate in the discussions and even
straw votes, just not formal votes. Requests for agenda time (e.g., for
a presentation) are normally granted, particularly when made reasonably
in advance. The committee even tries to meet in a variety of locations
to make it easier for people to attend.
--
Larry Jones
How am I supposed to learn surgery if I can't dissect anything? -- Calvin
lawrenc...@siemens.com
>
> Trouble is, you quickly end up pulling in a whole load of other stuff
> too. You start out thinking how nice it is to be able to write
>
> c=(a+b)*d;
>
> instead of
>
> mpf_add(c, a, b);
> mpf_mul(c, c, d);
>
> and then before you know it you've got overloaded functions because
>
> b=sqrt(a);
>
> is simpler than
>
> mpf_sqrt(b, a);
>
> Then it's iterators so that you can meaningfully overload ++ to index
> your list/array/other...
>
> And before you know it, you've got a horrible mess...
You mean C++? ;-)
--
Larry Jones
My brain is trying to kill me. -- Calvin
Richard Heathfield
<snip>
> Actually, at the moment I'm not a voting member of the committee. I am,
> however, the document editor. Which role provides more *authority* to
> change the language definition I can't say, but the latter role
> certainly provides more *opportunity* to do so. :-)
"He who drafts the document wins the day" - Jay and Lynn, in "Yes,
Minister"