From: Andrea Arcangeli <andrea@suse.de>
To: Jakob Oestergaard <jakob@unthought.net>,
Larry McVoy <lm@work.bitmover.com>,
linux-kernel@vger.kernel.org
Subject: Re: gcc 2.95 vs 3.21 performance
Date: Mon, 10 Feb 2003 23:26:32 +0100 [thread overview]
Message-ID: <20030210222632.GD22275@dualathlon.random> (raw)
In-Reply-To: <20030204235112.GB17244@unthought.net>
On Wed, Feb 05, 2003 at 12:51:12AM +0100, Jakob Oestergaard wrote:
> On Tue, Feb 04, 2003 at 03:21:01PM -0800, Larry McVoy wrote:
> > > I'd love to see a small - and fast - C compiler, and I'd be willing to
> > > make kernel changes to make it work with it.
> >
> > I can't offer any immediate help with this but I want the same thing. At
> > some point, we're planning on funding some extensions into GCC or whatever
> > reasonable C compiler is around:
>
> [snipping Linus from To:]
>
> Cool.
>
> >
> > - associative arrays as a builtin type
> >
> > {
> > assoc bar = {}; // anonymous, no file backing
> >
> > bar{"some key"} = "some value";
> > if (defined(bar{"some other value"})) ...
> > }
>
> Allow me:
>
> {
> std::map<std::string,std::string> bar;
>
> bar["some key"] = "some value";
> if (bar.find("some other value") != bar.end()) ...
> }
Indeed. Hardcoding map and multimap templates with string,string
parameter in the language sounds like a very worthless effort. If he
wants an high level syntax on top of the abstractions he should use a
more high level language. C can do everything but it's going to be a
sintax like what we do in the kernel, with lists, rbtrees, structures of
pointer to functions etc..
> Works beautifully, all you need is to pick the existing language which
> allows for the existing standard library which already provide that
> functionality.
>
> I doubt there's much need for a C+ or C 2+/3 langauage variant ;)
>
> >
> > - regular expressions
> >
> > {
> > char *foo = "blech";
> >
> > if (foo =~ /regex are nice/) {
> > printf("Well isn't that special?\n");
> > }
> > }
>
> Ok, I can't help you with that.
>
> You have probably seen a Perl program before... Now imagine a two
> million line Perl program... That is why the above is not a good idea ;)
actually the python syntax for re is quite nice, and would be pretty
compatible with C, no magic perl =~ operator etc.. again a library like
STL in an highlevel language would do the trick just fine.
>
> It's still your right to want it of course...
>
> >
> > - tk bindings built in
>
> Built into the language (not a library)?
Oh my.
>
> <sarcasm>
> Then I'd want the compiler in a kernel module ;)
> </>
then I want insmod kde.o too ;)
Andrea
next prev parent reply other threads:[~2003-02-10 22:16 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-03 23:05 gcc 2.95 vs 3.21 performance Martin J. Bligh
2003-02-03 23:22 ` [Lse-tech] " Andi Kleen
2003-02-03 23:31 ` Richard B. Johnson
2003-02-04 0:43 ` J.A. Magallon
2003-02-04 13:42 ` Richard B. Johnson
2003-02-04 14:20 ` John Bradford
2003-02-04 6:54 ` Denis Vlasenko
2003-02-04 7:13 ` Martin J. Bligh
2003-02-04 12:25 ` Adrian Bunk
2003-02-04 15:51 ` Martin J. Bligh
2003-02-04 16:27 ` [Lse-tech] " Martin J. Bligh
2003-02-04 17:40 ` Patrick Mansfield
2003-02-04 17:55 ` Martin J. Bligh
2003-02-04 9:54 ` Bryan Andersen
2003-02-04 15:46 ` Martin J. Bligh
2003-02-04 19:09 ` Timothy D. Witham
2003-02-04 19:35 ` John Bradford
2003-02-04 19:44 ` Dave Jones
2003-02-04 20:11 ` John Bradford
2003-02-04 20:20 ` John Bradford
2003-02-04 20:45 ` Herman Oosthuysen
2003-02-04 21:44 ` Timothy D. Witham
2003-02-05 7:15 ` Denis Vlasenko
2003-02-05 10:36 ` Andreas Schwab
2003-02-05 11:41 ` Denis Vlasenko
2003-02-05 12:20 ` Dave Jones
2003-02-05 13:10 ` [Lse-tech] " Dipankar Sarma
2003-02-05 15:30 ` Martin J. Bligh
2003-02-04 21:38 ` Linus Torvalds
2003-02-04 21:54 ` John Bradford
2003-02-04 22:11 ` Linus Torvalds
2003-02-04 23:27 ` Timothy D. Witham
2003-02-04 23:21 ` Larry McVoy
2003-02-04 23:42 ` b_adlakha
2003-02-05 0:19 ` Andy Pfiffer
2003-02-04 23:51 ` Jakob Oestergaard
2003-02-05 1:03 ` Hugo Mills
2003-02-10 22:26 ` Andrea Arcangeli [this message]
2003-02-10 23:28 ` J.A. Magallon
2003-02-04 23:51 ` Eli Carter
2003-02-05 0:27 ` Larry McVoy
2003-02-06 20:42 ` Paul Jakma
2003-02-05 3:03 ` Tomas Szepe
2003-02-05 6:03 ` Mark Mielke
2003-02-07 16:09 ` Pavel Machek
2003-02-04 10:57 ` Padraig
2003-02-04 13:11 ` Helge Hafting
2003-02-04 13:29 ` Jörn Engel
2003-02-04 14:05 ` P
2003-02-04 20:36 ` Herman Oosthuysen
2003-02-04 12:20 ` [Lse-tech] " Dave Jones
2003-02-04 15:50 ` Martin J. Bligh
2003-02-10 12:13 ` Momchil Velikov
2003-02-06 15:42 ` gcc -O2 vs gcc -Os performance Martin J. Bligh
2003-02-06 15:51 ` [Lse-tech] " Andi Kleen
2003-02-06 17:48 ` Alan Cox
2003-02-06 17:06 ` Martin J. Bligh
2003-02-06 20:38 ` Martin J. Bligh
2003-02-06 21:32 ` John Bradford
2003-02-06 22:12 ` Linus Torvalds
2003-02-06 22:58 ` Martin J. Bligh
2003-02-06 23:16 ` Linus Torvalds
2003-02-06 23:59 ` Martin J. Bligh
2003-02-06 23:17 ` Roger Larsson
2003-02-06 23:33 ` Martin J. Bligh
[not found] <1044385759.1861.46.camel@localhost.localdomain.suse.lists.linux.kernel>
[not found] ` <200302041935.h14JZ69G002675@darkstar.example.net.suse.lists.linux.kernel>
[not found] ` <b1pbt8$2ll$1@penguin.transmeta.com.suse.lists.linux.kernel>
2003-02-04 22:05 ` gcc 2.95 vs 3.21 performance Andi Kleen
2003-02-04 22:14 ` Linus Torvalds
2003-02-05 10:04 ` Pavel Janík
2003-02-05 20:07 ` Linus Torvalds
2003-02-06 15:00 ` Horst von Brand
2003-02-04 22:59 ` Jeff Muizelaar
2003-02-04 23:12 ` b_adlakha
2003-02-05 8:41 ` Horst von Brand
2003-02-05 19:09 ` Linus Torvalds
2003-02-05 19:22 ` Randy.Dunlap
2003-02-05 19:24 ` John Bradford
2003-02-06 7:02 ` Neil Booth
[not found] ` <courier.3E423112.00007219@softhome.net>
[not found] ` <20030206212218.GA4891@daikokuya.co.uk>
2003-02-07 10:31 ` b_adlakha
2003-02-07 18:46 ` Horst von Brand
2003-02-07 21:49 ` Neil Booth
2003-02-10 2:14 ` Jeff Garzik
2003-02-10 9:19 ` Tomas Szepe
[not found] <120432836@toto.iv>
2003-02-05 2:45 ` Peter Chubb
[not found] <200302052021.h15KLrXv000881@darkstar.example.net>
2003-02-05 20:28 ` b_adlakha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030210222632.GD22275@dualathlon.random \
--to=andrea@suse.de \
--cc=jakob@unthought.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@work.bitmover.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.