Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90419 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-15 23:36 +0200 |
| Last post | 2016-08-02 13:20 -0700 |
| Articles | 20 on this page of 164 — 22 participants |
Back to article view | Back to comp.lang.c
High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-15 23:36 +0200
Re: High level C supercat@casperkitty.com - 2016-07-15 15:17 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:09 +0200
Re: High level C supercat@casperkitty.com - 2016-07-17 20:02 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-15 15:17 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-07-31 23:55 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:13 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 02:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 11:07 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:29 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:40 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 11:57 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 11:30 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:53 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 07:49 -0700
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-16 17:08 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 09:09 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 16:26 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 18:05 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 20:15 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 23:44 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:39 +0000
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:58 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:52 +0000
Re: High level C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 16:29 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:38 +0000
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 14:17 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:46 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 12:05 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 11:03 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 03:39 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 18:20 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 14:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 23:13 +0530
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 20:14 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-17 20:14 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 20:45 +0100
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-07-17 21:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 09:48 +0530
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 00:55 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:25 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 11:40 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 05:05 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:59 +0530
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:50 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 19:07 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:53 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 11:15 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 14:00 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:01 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:26 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:57 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:13 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 18:14 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:20 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 19:46 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:44 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-20 10:59 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 01:44 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:58 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 17:20 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 20:52 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:14 +0100
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-21 13:23 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:50 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 12:52 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 04:03 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:56 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:09 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:49 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:37 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 19:16 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:17 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 21:07 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:36 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:27 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 16:27 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:14 +0100
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 10:08 +0200
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:04 +0530
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 10:18 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:26 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:21 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-25 10:19 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:31 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-28 21:13 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 09:05 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-29 09:30 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 10:08 -0700
Re: High level C Ike Naar <ike@iceland.freeshell.org> - 2016-07-29 17:57 +0000
Re: High level C supercat@casperkitty.com - 2016-07-29 11:50 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 07:16 -0700
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:34 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 14:55 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 03:10 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:40 -0700
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-01 19:43 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 10:21 -0500
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-03 13:14 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:40 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:28 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-05 09:55 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:51 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:43 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:43 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:52 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:42 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 12:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-07-31 16:42 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:59 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-07-31 17:12 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:12 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 00:54 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 08:08 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 12:58 -0500
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 12:25 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:44 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 11:56 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 19:29 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-03 13:45 -0400
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 13:23 -0500
Re: High level C BartC <bc@freeuk.com> - 2016-08-03 19:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 21:04 +0200
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-03 20:08 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:09 -0500
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:06 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 23:36 +0200
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 19:44 -0500
Re: High level C supercat@casperkitty.com - 2016-08-03 15:03 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 19:17 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 05:48 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 08:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:30 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 10:34 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 20:50 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:39 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:50 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 17:08 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 02:23 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:03 +0000
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 12:13 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:10 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:40 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:56 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:51 +0200
Re: High level C supercat@casperkitty.com - 2016-08-08 09:12 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 22:07 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 15:05 -0700
Re: High level C Ian Collins <ian-news@hotmail.com> - 2016-08-03 11:22 +1200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:50 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 01:12 +0100
Re: High level C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 20:16 -0400
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:17 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 08:20 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 17:24 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 09:24 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:15 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:22 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 23:58 +0200
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-02 13:20 -0700
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-15 23:36 +0200 |
| Subject | High level C |
| Message-ID | <nmbl0s$t8n$1@dont-email.me> |
I started working in a better infinite precision integer package. I took
the code of Tom StDenis from the git repository, and started hacking
around. It is now much faster than the best optimized code from gcc can
do, but that is another story.
To distribute the code I think that one of the best ideas is the one
from BartC. One file, one header, no makefile no nothing.
Well, the library is splitted into several dozens files. I decided to
write a C program then, that would take all the files and produce a
single file containing all others.
That gives:
166 int main(void)
167 {
168 int res;
169 List *fileList = iList.Create(sizeof(SourceFile));
170 GlobalIncludes = iDictionary.Create(sizeof(void *),500);
171
172 res = BuildFileList(fileList);
173 if (res) return res;
174 res = ProcessFiles(fileList);
175 if (res) return res;
176 res = Output(fileList);
177 return res;
178 }
I build a list of files, then process them and output the result.
Nothing earth shattering here. But it was nice to be able to express it
like that.
Yes, C++ does that since a while now. But then, you have to cope with
C++, STL, class inheritance, templates, and many other things I do not
care about. I just want to do a list of files, then build them into one,
not a big deal really, and nothing that requires classes, templates or
whatever. I use a plain C package that is very simple.
I make a list of source files. Then I need a list of all the includes in
all files to generate a single list of includes, without repeating them.
I will output that at the head of the result file.
Then, I get this:
static int BuildFileList(List *file_list)
{
/* Read all the contents of the file called "filelist.txt" into a string
list of lines. Why bother giving parameters to this program?
Just keep it simple and assume filelist.txt
*/
strCollection *files =istrCollection.CreateFromFile("filelist.txt");
/* Abort if there is no list of files to process */
if (files == NULL) return -1;
/* Let's go through each line, creating a file descriptor into an
extended list */
Iterator *it1 = istrCollection.NewIterator(files);
/* This structure wxill contain the info gathered for each source
file */
SourceFile thisFile;
char *Filename;
/* Fill the structure that holds information about the file, its name,
the includes it uses, and other fields maybe later. This part is ellided
here.
*/
return 0;
}
Then, I process all lines of all files, using the ccl iterators. I
detect (with a very crude strstr :-( not very sophisticated) the include
lines, put them in a hash table that keeps all unique keys, and output
them later with an iterator, after outputting the copyright notice of
Tom StDenis.
Throw away C programs where C works as a fast and powerful scripting
language. C comes with a garbage collector if you want one, so all that
stuff about constructors, destructors and whatever falls away. How much
easier!
No lambdas, no complicated constructs but as powerful as anything else.
C++ was originally written in C and for C. The fad was in that time,
"object oriented" programming and everything should have a class and
inherit to reuse the code. Sceptics were classified as folks that just
didn't understand anything about data processing.
And then it went downwards, till today. Object oriented programming is
no longer "en vogue" and the fad went for templates, now lambdas, and
tomorrow whatever computer science students learn at the university,
where those fads are fabricated.
What is nice about C precisely, it is the total lack of assumptions (I
would say pretention) of imposing some conecpt into your data. I wanted
to process a list of files and if that list is a class, or a template,
or whatever, it is of no importance.
It is a list of lines period.
C doesn't prescribe anything but that doesn't mean you can't have a list
easily built when you take some time. I took that time and it is nice to
use.
Don't like mine?
Build yours!
jacob
P.S. In this newsgroup religion appearas to be an important topic. Is
the CCL a religion? Am I a prohet? Am I preaching the "way of the CCL"?
Maybe,
who knows what can happen in a hacker's mind.
[toc] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-15 15:17 -0700 |
| Message-ID | <1efee380-1d5e-4b6c-906e-64375c1efe9d@googlegroups.com> |
| In reply to | #90419 |
On Friday, July 15, 2016 at 4:36:36 PM UTC-5, jacobnavia wrote: > What is nice about C precisely, it is the total lack of assumptions (I > would say pretention) of imposing some conecpt into your data. I wanted > to process a list of files and if that list is a class, or a template, > or whatever, it is of no importance. You're describing a language which was popular in the 1990s, but seems to have become unfashionable. The present philosophy is that it's more important for compilers to achieve optimal performance from code which doesn't use any of the features that let C take overtake Pascal as the language for microcomputer development in the late 1980s and early 1990s, than to usefully accommodate code which does make use of such features. Perhaps both the old and new languages should be given names to disambiguate them. Perhaps the clearest name I can think of for the language Dennis Ritchie designed might be "Low Level C"; the most favorable name I can think of for today's fashionable language would be "Automatically-Optimizable C". Note that AOC, unlike LLC, places some severe constraints on how storage can be used, and in some cases programs written in LLC may be able to outpace those written in AOC significantly. LLC applies the Common Initial Sequence rule in such a way that a pointer to one structure type can be used to access members of the Common Initial Seequence of another; AOC guts the Common Initial Sequence rule so as to make it basically useless. Which language to you like?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-16 09:09 +0200 |
| Message-ID | <nmcmic$jh7$1@dont-email.me> |
| In reply to | #90421 |
Le 16/07/2016 à 00:17, supercat@casperkitty.com a écrit : > On Friday, July 15, 2016 at 4:36:36 PM UTC-5, jacobnavia wrote: >> What is nice about C precisely, it is the total lack of assumptions (I >> would say pretention) of imposing some conecpt into your data. I wanted >> to process a list of files and if that list is a class, or a template, >> or whatever, it is of no importance. > > You're describing a language which was popular in the 1990s, but seems > to have become unfashionable. That is the opinion of fashion circles. C is no longer "in". But since I do not consider fashion as a reliable source of decisions, I do not give much about what fashion followers do. > The present philosophy is that it's more > important for compilers to achieve optimal performance from code which > doesn't use any of the features that let C take overtake Pascal as the > language for microcomputer development in the late 1980s and early > 1990s, than to usefully accommodate code which does make use of such > features. > This is ridiculous. Fashion dictates then that we should revert to some language that is easy for a compiler to optimize. Nonsense. As I described earlier, I have improved the speed of Tom StDenis's library to twice that of fully optimized gcc by... WRITING DIRECTLY IN ASSEMBLER. There is NO compiler that can beat a hacker's brain. If you REALLY want performance, you do not write in C at all. Assembler is the best choice. > Perhaps both the old and new languages should be given names to > disambiguate them. Perhaps the clearest name I can think of for the > language Dennis Ritchie designed might be "Low Level C"; the most > favorable name I can think of for today's fashionable language would > be "Automatically-Optimizable C". Note that AOC, unlike LLC, places > some severe constraints on how storage can be used, and in some cases > programs written in LLC may be able to outpace those written in AOC > significantly. LLC applies the Common Initial Sequence rule in such > a way that a pointer to one structure type can be used to access members > of the Common Initial Seequence of another; AOC guts the Common Initial > Sequence rule so as to make it basically useless. > > Which language to you like? > It depends what your goals with your program are. Your language can be great for compilers to optimize, but is speed the only criteria to judge a program? In this example I am emphasizing easy of use at relatively big speed, comparable to C++ STL. Does your "Automatically-optimizable C" include lists? How does that language handle hash tables, flexible arrays, etc? Please give some example to see what we are talking about.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-17 20:02 -0700 |
| Message-ID | <d6d1a9d1-ab46-4f54-add2-d297c965a5c5@googlegroups.com> |
| In reply to | #90430 |
On Saturday, July 16, 2016 at 2:09:12 AM UTC-5, jacobnavia wrote:
> As I described earlier, I have improved the speed of Tom StDenis's
> library to twice that of fully optimized gcc by...
>
> WRITING DIRECTLY IN ASSEMBLER.
In many cases, C code which is tailored to a platform's strengths and
abilities can come close enough to machine code that it's not worth trying
to eke out the last bit of performance. If one can speed up a major
bottleneck enough that something else becomes the limiting factor in
performance without having to write directly in assembly, that would seem
desirable.
> Does your "Automatically-optimizable C" include lists? How does that
> language handle hash tables, flexible arrays, etc?
Nah. Nothing like that.
> Please give some example to see what we are talking about.
Sure. Assuming "int" is 32 bits and "short" is 16 bits, consider:
unsigned mul(unsigned short x, unsigned short y)
{ return x*y; }
In 1990s C, that wouldn't do anything but return the arithmetical product
of x*y. In modern AOC, it will sometimes have the additional bonus feature
of telling the compiler that that x will never exceed 2147483647/y, and y
will never exceed 2147483647/x, thus allowing the compiler to optimize out
any code which would only be relevant if x or y exceeded the indicated
values.
Consider also the effect of:
struct header {int x; short y;}
struct s1 {int x; short y; short q[5];}
struct s2 {int x; short y; short z; long long l[15];}
union heads1s2 {struct header h; struct s1 v1; struct s2 v2; }
void process_s1(struct s1 *p)
{
p->x += p->q[0];
}
void process_s2(struct s2 *p)
{
p->x += p->l[0]/65536;
}
int process_thing(struct header *p1, struct header *p2)
{
if (p1->x < -16)
process_s1( (struct s1*)p2);
if (p1->x > 16)
process_s2( (struct s2*)p2);
return p1->x;
}
A 1990s C compiler would reload the value of p1->x if it called one of
the indicated functions since the code is clearly very likely to alter
the value of an object of type "struct header". A modern AOC compiler
would realize that--at least according to fashionable readings--the
Standard doesn't require such behavior and thus omit the reload.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-15 15:17 -0700 |
| Message-ID | <ln1t2uwnou.fsf@kst-u.example.com> |
| In reply to | #90419 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> I started working in a better infinite precision integer package. I took
> the code of Tom StDenis from the git repository, and started hacking
> around. It is now much faster than the best optimized code from gcc can
> do, but that is another story.
>
> To distribute the code I think that one of the best ideas is the one
> from BartC. One file, one header, no makefile no nothing.
>
> Well, the library is splitted into several dozens files. I decided to
> write a C program then, that would take all the files and produce a
> single file containing all others.
FYI, Sqlite3 is maintained in multiple C source files, but normally
compiled as an automatically built "amalgamation", a single C source
file.
https://www.sqlite.org/amalgamation.html
[...]
> P.S. In this newsgroup religion appearas to be an important topic.
It isn't. (Personally, I've corrected that impression by using a
killfile.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-07-31 23:55 -0700 |
| Message-ID | <e58539f5-0002-46b5-a32e-9177b6d2e828@googlegroups.com> |
| In reply to | #90422 |
W dniu sobota, 16 lipca 2016 00:18:01 UTC+2 użytkownik Keith Thompson napisał: > jacobnavia <jacob@jacob.remcomp.fr> writes: > [...] > > > P.S. In this newsgroup religion appearas to be an important topic. > > It isn't. (Personally, I've corrected that impression by using a > killfile.) > I doubt if this is worse than thompson activity who tries to show this group as his own club and flod this group with stream his banal insulting namings and uninteligent remarks (this 'i doubt' is some like joke - to be honest i find thompson worse and more boring than hodgin, though hodgin often produces weak stuff too, at least once or twice i interchanged some interesting moments with thompson it was always "go down to bore" or yet worse "go down to conventional sick troll-killfile 'climates' over and over as maniacs of stupidity do over and over" ) note that, is christianity worse than troll-kilfile dark religion of thompson and those other usenet simpletons who make that?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-15 23:27 +0100 |
| Message-ID | <87mvlimt9i.fsf@bsb.me.uk> |
| In reply to | #90419 |
jacobnavia <jacob@jacob.remcomp.fr> writes: <snip> > .... Object oriented programming is > no longer "en vogue" and the fad went for templates, now lambdas, and > tomorrow whatever computer science students learn at the university, > where those fads are fabricated. Lambdas date from the 1930s. There were amongst the very first concepts to be implemented in a programming language (in the 1950s). They are a very long-lived fad. But they become important when you provide high-level operations like mapping and folding over a sequence. Presumably your C containers have map, filter and fold (sometimes called reduce) operations on its sequences. Without lambdas, you have write a named top-level function and arrange a convention for any user data to be passed in (usually an extra void *). It's the ability to simplify this "capturing" of data that makes them useful. The fact that they are unnamed (which is what the lambda part is about) is less important. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-16 09:13 +0200 |
| Message-ID | <nmcmq9$k4a$1@dont-email.me> |
| In reply to | #90423 |
Le 16/07/2016 à 00:27, Ben Bacarisse a écrit : > jacobnavia <jacob@jacob.remcomp.fr> writes: > <snip> >> .... Object oriented programming is >> no longer "en vogue" and the fad went for templates, now lambdas, and >> tomorrow whatever computer science students learn at the university, >> where those fads are fabricated. > > Lambdas date from the 1930s. There were amongst the very first concepts > to be implemented in a programming language (in the 1950s). They are a > very long-lived fad. > Lambda Calculus dates from 1930s. There was no lisp then. > But they become important when you provide high-level operations like > mapping and folding over a sequence. Presumably your C containers have > map, filter and fold (sometimes called reduce) operations on its > sequences. Without lambdas, you have write a named top-level function > and arrange a convention for any user data to be passed in (usually an > extra void *). It's the ability to simplify this "capturing" of data > that makes them useful. The fact that they are unnamed (which is what > the lambda part is about) is less important. > > <snip> > Any construct can be useful in some circumstances. So you start piling up features and constructs without any consideration for the resulting language and you obtain... EUREKA! You obtain C++, a language overgrown to the excess, dying of obesity.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-16 02:07 -0700 |
| Message-ID | <cbc446ba-15a8-4d91-a878-1a74fcf25b15@googlegroups.com> |
| In reply to | #90431 |
On Saturday, July 16, 2016 at 8:13:20 AM UTC+1, jacobnavia wrote: > Le 16/07/2016 à 00:27, Ben Bacarisse a écrit : > > > But they become important when you provide high-level operations like > > mapping and folding over a sequence. Presumably your C containers have > > map, filter and fold (sometimes called reduce) operations on its > > sequences. Without lambdas, you have write a named top-level function > > and arrange a convention for any user data to be passed in (usually an > > extra void *). It's the ability to simplify this "capturing" of data > > that makes them useful. The fact that they are unnamed (which is what > > the lambda part is about) is less important. > > > > <snip> > > > > Any construct can be useful in some circumstances. So you start piling > up features and constructs without any consideration for the resulting > language and you obtain... > > EUREKA! > > You obtain C++, a language overgrown to the excess, dying of obesity. > Though that's not actually the problem with lambdas. Lisp is an extremely simple language, so much so that one's natural instinct is to write a little interpreter for it. You can write any program with lambdas, and not much other machinery. But Lisp never really caught on, it's just too difficult to write even simple functions in Lisp. Even things like fibonacci generators, which are the poster boys for that type of programming. It's too hard to work out whether the program is efficient or exhibits catastrophic multiple recursion.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-16 11:07 +0100 |
| Message-ID | <87bn1xnbg8.fsf@bsb.me.uk> |
| In reply to | #90433 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 16, 2016 at 8:13:20 AM UTC+1, jacobnavia wrote:
<snip>
>> Any construct can be useful in some circumstances. So you start piling
>> up features and constructs without any consideration for the resulting
>> language and you obtain...
>>
>> EUREKA!
>>
>> You obtain C++, a language overgrown to the excess, dying of obesity.
>>
> Though that's not actually the problem with lambdas.
> Lisp is an extremely simple language, so much so that one's natural
> instinct is to write a little interpreter for it. You can write
> any program with lambdas, and not much other machinery.
>
> But Lisp never really caught on,
That's debatable, but what isn't in doubt is that what we've been
loosely calling "lambdas" *have* caught on. The term itself just refers
to a device that permits functions values to be written, but the most
useful attribute is often that they can form closures: they capture
local names.
> it's just too difficult to write
> even simple functions in Lisp. Even things like fibonacci generators,
> which are the poster boys for that type of programming. It's too
> hard to work out whether the program is efficient or exhibits
> catastrophic multiple recursion.
You often trot this out. It's either just propaganda or you don't know
Lisp. For example
(defun fib (x)
(let ((a 0) (b 1))
(loop repeat x do
(psetq a b
b (+ a b)))
a))
has no recursion, "catastrophic" or otherwise.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-16 03:29 -0700 |
| Message-ID | <aad337f5-88a8-4960-90ed-cf3561a55a1b@googlegroups.com> |
| In reply to | #90435 |
On Saturday, July 16, 2016 at 11:07:13 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > it's just too difficult to write > > even simple functions in Lisp. Even things like fibonacci generators, > > which are the poster boys for that type of programming. It's too > > hard to work out whether the program is efficient or exhibits > > catastrophic multiple recursion. > > You often trot this out. It's either just propaganda or you don't know > Lisp. For example > > (defun fib (x) > (let ((a 0) (b 1)) > (loop repeat x do > (psetq a b > b (+ a b))) > a)) > > has no recursion, "catastrophic" or otherwise. > No loop macro in my lisp interpreter. Which I will admit was never totally finished. I based it on an old book which was hanging around the library of a redbrick university I won't name, because it was one of literally only half a dozen books in the entire library on Lisp. However I think you can build it from car and cdr. It doesn't have to be what Lisp calls special forms. You mustn't ever introduce another special form or you've violated the spirit of Lisp. I did have go a knocking one up, and failed. It's fiddly. As I said, it's easier to write the Lisp interpreter in C than a basic function in Lisp.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-16 13:40 +0100 |
| Message-ID | <87ziphlps2.fsf@bsb.me.uk> |
| In reply to | #90436 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 16, 2016 at 11:07:13 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> > it's just too difficult to write >> > even simple functions in Lisp. Even things like fibonacci generators, >> > which are the poster boys for that type of programming. It's too >> > hard to work out whether the program is efficient or exhibits >> > catastrophic multiple recursion. >> >> You often trot this out. It's either just propaganda or you don't know >> Lisp. For example >> >> (defun fib (x) >> (let ((a 0) (b 1)) >> (loop repeat x do >> (psetq a b >> b (+ a b))) >> a)) >> >> has no recursion, "catastrophic" or otherwise. >> > No loop macro in my lisp interpreter. That's no reason to keep repeating the same old tropes about Lisp. There are lots of C-like languages out there but you can't say such and such is impossible in C if it's possible in the accepted standard version of C. > Which I will admit was never totally finished. I based it on an > old book which was hanging around the library of a redbrick > university I won't name, because it was one of literally only > half a dozen books in the entire library on Lisp. However I think > you can build it from car and cdr. It doesn't have to be what > Lisp calls special forms. You mustn't ever introduce another > special form or you've violated the spirit of Lisp. I hope you will forgive me for not taking your word on what constitutes the spirit of Lisp. > I did have go a knocking one up, and failed. It's fiddly. As I > said, it's easier to write the Lisp interpreter in C than a basic > function in Lisp. Contradicted by facts so many times I must conclude that you are just trying (and succeeding!) to get a rise out of people. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-17 11:57 +0530 |
| Message-ID | <nmf8hk$9ef$1@dont-email.me> |
| In reply to | #90436 |
[Multipart message — attachments visible in raw view] — view raw
On 07/16/2016 03:59 PM, Malcolm McLean wrote: > No loop macro in my lisp interpreter. Which I will admit was never > totally finished. I based it on an old book which was hanging around > the library of a redbrick university I won't name, because it was one > of literally only half a dozen books in the entire library on Lisp. You can save yourself a lot of time and effort by using one of the many good systems that sport native code *compilers* as well as interpreters. Some of these are Allegro Common Lisp, LispWorks, and Clozure Common Lisp. Two good free systems that have good compilers only are CMUCL and SBCL. > [Elided.] > You mustn't ever introduce another special form or you've violated the > spirit of Lisp. > > I did have go a knocking one up, and failed. It's fiddly. As I said, > it's easier to write the Lisp interpreter in C than a basic function > in Lisp. I would love to know the premises that led to these conclusions. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-16 11:30 +0100 |
| Message-ID | <nmd2bt$ke0$1@dont-email.me> |
| In reply to | #90435 |
On 16/07/2016 11:07, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> it's just too difficult to write
>> even simple functions in Lisp. Even things like fibonacci generators,
>> which are the poster boys for that type of programming. It's too
>> hard to work out whether the program is efficient or exhibits
>> catastrophic multiple recursion.
>
> You often trot this out. It's either just propaganda or you don't know
> Lisp. For example
>
> (defun fib (x)
> (let ((a 0) (b 1))
> (loop repeat x do
> (psetq a b
> b (+ a b)))
> a))
>
> has no recursion, "catastrophic" or otherwise.
Lisp didn't catch on because its syntax stinks. People don't want to
write in what looks like some intermediate code of a compiler.
I had to guess what some of the above did, especially psetq, but the
following styles are far easier on the eye:
def fib(x):
a = 0
b = 1
for _ in range(x):
a, b = b, a+b
return a
function fib(x)=
(a, b) := (0,1)
to x do
(a, b) := (b, a+b)
od
return a
end
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-16 03:43 -0700 |
| Message-ID | <f6c8882c-5404-4501-b108-19b5cd71d28e@googlegroups.com> |
| In reply to | #90437 |
On Saturday, July 16, 2016 at 11:30:29 AM UTC+1, Bart wrote: > On 16/07/2016 11:07, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > >> it's just too difficult to write > >> even simple functions in Lisp. Even things like fibonacci generators, > >> which are the poster boys for that type of programming. It's too > >> hard to work out whether the program is efficient or exhibits > >> catastrophic multiple recursion. > > > > You often trot this out. It's either just propaganda or you don't know > > Lisp. For example > > > > (defun fib (x) > > (let ((a 0) (b 1)) > > (loop repeat x do > > (psetq a b > > b (+ a b))) > > a)) > > > > has no recursion, "catastrophic" or otherwise. > > Lisp didn't catch on because its syntax stinks. People don't want to > write in what looks like some intermediate code of a compiler. > > I had to guess what some of the above did, especially psetq, but the > following styles are far easier on the eye: > > def fib(x): > a = 0 > b = 1 > for _ in range(x): > a, b = b, a+b > return a > > function fib(x)= > (a, b) := (0,1) > to x do > (a, b) := (b, a+b) > od > return a > end > > This isn't exactly what I worked from but is essentially the same material. (Maddeningly, he says supply only quote, atom, eq, cons, car, cdr, cond. and then doesn't explain defun, which puts the function into Lisp's global namespace. So actually I think you also need to supply "set".) http://ep.yimg.com/ty/cdn/paulgraham/jmc.lisp But you see how simple and elegant it is? And it's not a "Turing tarpit" either. It's powerful and expressive. But humans can only cope with three levels of nested parentheses, that's the flaw in the scheme.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-16 13:53 +0100 |
| Message-ID | <87oa5xlp6t.fsf@bsb.me.uk> |
| In reply to | #90438 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> But humans can only cope with three levels of nested parentheses,
> that's the flaw in the scheme.
Please stop saying this. It's trivial to write highly nested forms in
Lisp because they are not arbitrary. The patterns are just as easy to
see as 'while (...) { ... }' and so on.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-16 07:49 -0700 |
| Message-ID | <1224a3b5-85ba-4445-8dd6-4cc9cc260b59@googlegroups.com> |
| In reply to | #90442 |
On Saturday, July 16, 2016 at 1:53:22 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
> > But humans can only cope with three levels of nested parentheses,
> > that's the flaw in the scheme.
>
> Please stop saying this. It's trivial to write highly nested forms in
> Lisp because they are not arbitrary. The patterns are just as easy to
> see as 'while (...) { ... }' and so on.
>
No, you need special software support to write Lisp code.
The rule of three is in my view the main reason why the language
didn't succeed. It's alive, it has niche because of its theoretical
interest and, as I said, it's also very easy to write the
interpreter. But it's not used much for industrial programming.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-07-16 17:08 +0200 |
| Message-ID | <874m7pzkm8.fsf@news.bourguet.org> |
| In reply to | #90444 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > It's alive, it has niche because of its theoretical interest If what I get from my POV is correct, theoritical interest nowadays favorize Haskell over Lisp, and I'm far from sure that people interested in Clojure or Hy -- to cite two of the latest Lisp dialects -- are driven by theory: wanting interoperability with Java or Python seems more practical than theoritical. > But it's not used much for industrial programming. It's the extension language for some important CAD tools, so you are using things which were designed using variants of lisp. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-16 09:09 -0700 |
| Message-ID | <145f307e-cff6-4756-b82a-3fd253a8c256@googlegroups.com> |
| In reply to | #90445 |
On Saturday, July 16, 2016 at 4:08:25 PM UTC+1, Jean-Marc Bourguet wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It's alive, it has niche because of its theoretical interest > > If what I get from my POV is correct, theoritical interest nowadays > favorize Haskell over Lisp, and I'm far from sure that people > interested in Clojure or Hy -- to cite two of the latest Lisp > dialects -- are driven by theory: wanting interoperability with > Java or Python seems more practical than theoritical. > Functional programming has come back in to fashion. Largely because Lisp-heads had a go at Javascript and put in features like closures and nested functions, plus functions as first class objects. Javascript caught on because you need a programming language that runs in web browsers, not I suspect because of the Lisp-like features. But it was enough to trigger a functional programming renaissance. > > > But it's not used much for industrial programming. > > It's the extension language for some important CAD tools, so > you are using things which were designed using variants of lisp. > Yes, it's used a bit. It's also the extension language for Emacs (described by a friend as "not so much a text editor, more a way of life"). If your job happens to be to write plug-in for those CAD tools, or enhancing Emacs, then of course you'll use it a lot. It's also used quite a bit in AI, and I think Google used it for their core search engine. The reason was they hired Harvard people, and Lisp is taught in programming 101 at Harvard. The vulgar MIT people next university down the block get taught Python. Gerald Sussman, who teaches computer science there, tried to make Scheme (a Lisp) language of choice, but a couple of years ago he admitted defeat. It's still alive. But in comparison to the amount of C/C++ and variant code out there, it's not used much.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-16 16:26 +0100 |
| Message-ID | <87inw5li3g.fsf@bsb.me.uk> |
| In reply to | #90444 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 16, 2016 at 1:53:22 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>> > But humans can only cope with three levels of nested parentheses,
>> > that's the flaw in the scheme.
>>
>> Please stop saying this. It's trivial to write highly nested forms in
>> Lisp because they are not arbitrary. The patterns are just as easy to
>> see as 'while (...) { ... }' and so on.
>>
> No, you need special software support to write Lisp code.
I wrote:
(defun fib (x)
(let ((a 0) (b 1))
(loop repeat x do
(psetq a b
b (+ a b)))
a))
I (and I am sure I am not alone in this) think of "(defun" and its ")"
like any other block structured language:
DEFUN fib (x)
LET ((a 0) (b 1))
LOOP repeat x do
SETVARS a b
b (+ a b)
END
END
a
END
END
> The rule of three is in my view the main reason why the language
> didn't succeed. It's alive, it has niche because of its theoretical
> interest and, as I said, it's also very easy to write the
> interpreter. But it's not used much for industrial programming.
How do you know that? I ask because I suspect that it is, but I don't
want to make a claim that is just a guess. I have no evidence to
support my suspicion, so I'll just ask how you know that you are
correct.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web