Linux-Development-Sys Digest #898, Volume #6 Sun, 27 Jun 99 19:14:05 EDT
Contents:
Re: Why not C++ ([EMAIL PROTECTED])
Re: Why we are still holding on to X Windows (Alan McLean)
Re: Ultimate OS (Tomas Ogren)
Re: Why we are still holding on to X Windows (Todd Knarr)
Re: Why not C++ (Craig Graham)
Re: TAO: the ultimate OS (Tristan Wibberley)
Differences in /usr/include/sys/ipc.h (Manickam Umasuthan)
Re: File Allocation Tables (Tristan Wibberley)
Re: vesafb for S3 868? (Roope Anttinen)
Re: Why not C++ (Johan Kullstam)
Re: Why not C++ (Johan Kullstam)
Re: Why not C++ (Johan Kullstam)
Where is the compose key? (Bernd Strieder)
Re: Why not C++ (Bruce Hoult)
Re: Why not C++ (Bruce Hoult)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why not C++
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Date: Sun, 27 Jun 1999 18:02:24 GMT
In comp.os.linux.development.system Nathan Myers <[EMAIL PROTECTED]> wrote:
: Linus Torvalds <[EMAIL PROTECTED]> wrote:
:>Bruce Hoult <[EMAIL PROTECTED]> wrote:
:>
:>But what others are saying is "a lot of existing C++ compilers generate
:>worse code than a lot of existing C compilers". And they are right too.
:>
:>Sometimes theory matters. Sometimes it doesn't. The world is not as
:>simple as you make it out to be.
: Enough generalities. Take for example Egcs. C and C++, same code
: generator, same optimizer. The last time you tried g++ was years
: and years ago. It's time to look again.
Using the latest egcs (from CVS) to compile a C program, with options
'-fno-exceptions -fno-rtti -O2', the C assembler output is still
smaller (in terms of # of instructions, not symbol length) while
producing the same results.
C++ is still slower and bulkier.
Jeff
------------------------------
From: [EMAIL PROTECTED] (Alan McLean)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Sun, 27 Jun 1999 17:58:10 GMT
Mario Klebsch <[EMAIL PROTECTED]> wrote:
> Tristan Wibberley <[EMAIL PROTECTED]> writes:
> >I think you are very confused
> >about what an OS does. An OS does not stop application developers from
> >choosing how to make their apps look - no OS does, not one, not UNIX,
> >not MS Windows, not BeOS, not MacOS, none of them.
>
> Believe me, I very well am aware of these problmes. But I also know,
> that there are Macintosh User Interface Guidelines, and there is a
> publication from Microsoft, called "The Windows Interface". There is
> nothing like this for UNIX. Well, there is a Motif style guide, and
> an open windows style guide and probably others, but none of them is
> about UNIX or about X11.
>
> This topic is just not covered by X11.
You are right. However, this is by design.
While I understand your concern, you are really comparing apples and
oranges. X is a generic networked window system, which by design does
not impose look-and-feel, this kind of policy does not belong at
the X level. Look and feel is layered above X, and is a policy
decision that the vendor decides.
X was a more ambitious effort than the Microsoft or Mac windowing
systems. Keep in mind, X was not built for *one* particular OS, but
for a slew of Unix-like OS'. Two of the main strengths of X are that
it is vendor neutral (i.e. it does *not* impose UI policy), and it is a
networked window system (i.e. you can migrate an applications output
across the network).
Now obviously not every vendor (especially proprietary ones) will
have the same UI or look-and-feel requirements. You are essentially
comparing the UI policy of one OS, Microsoft or the Mac, against
that of multiple Unix-like OS'.
Keep in mind you have stepped into a new world, with new ideas and
perspectives. The good software engineering practice of (re-)using
simple or generic tools to build larger and more specific ones
transcends Unix. I understand the utility of a consistent UI, but
there is also utility in generality. Namely the UI can be replaced
or evolve without a need to touch the core windowing system. X has
kicked around precisely because it is generic enough to allow this
kind of evolution.
-amcl
------------------------------
From: [EMAIL PROTECTED] (Tomas Ogren)
Subject: Re: Ultimate OS
Date: 27 Jun 1999 17:47:05 GMT
At 23 Jun, Konrad Mieredorff wrote:
> RaiX wrote:
>>
>> Linux with netscape as GUI.
>> That's it..
>
> Should I laugh or cry?
Both.. I guess..
/Tomas
--
Tomas �gren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Ume�
`- Sysadmin at {cs,ing,acc}.umu.se
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 27 Jun 1999 19:08:38 GMT
In comp.os.linux.development.system Justin Vallon <[EMAIL PROTECTED]> wrote:
> I'm not sure that the distinction is that clear. In 99.99% of the
> cases, an applications sound I/O and graphics I/O go to the same
> place: the user. It seems superfluous to create an alternate
> protocol.
Consider this: while both go to the same place, not all programs that
use graphics need sound and not all programs that need sound need
graphics. Making the sound protocol part of X, or piggybacking it as
an X extension, implies that _only_ programs that use X can use the
sound protocol. Making it a seperate protocol means that programs
that have no use for graphics at all can still use the sound
protocol.
You can also do things with the destination. In X the DISPLAY variable
can point to multiple displays on the same machine, so I can have
multiple displays or multiple X server sessions running and point a
program to any one of them. Similarly, I could have multiple sound
cards in the machine and point any sound session to any one of them
independently of where I had other sound routed.
--
Collin was right. Never give a virus a missile launcher.
-- Erk, Reality Check #8
------------------------------
From: Craig Graham <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 20:08:29 +0000
[EMAIL PROTECTED] (Nathan Myers) wrote:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >My point was simply:
> >In my first tries to use the STL, I had to fight with 10+ lines
> >really obscure template error messages. I wouldn't wish that to=20
> >any poor beginner (given that beginning is usually mostly syntax=20
> >error fixing at first)
>=20
> True, there is a great deal of work yet to be done on improving
> error reporting in Egcs, and similar work in Gdb.
>=20
> OTOH, once you get code past the compiler, it's far less buggy.
Actually, I had one case where the current EGCS generated really
faulty code (this is a fragment from it):
frame=3D0;
for(p=3Dlist_start; p; p=3Dp->next)
{
if(p->type=3D=3DtagShowFrame)
{
frame_array[frame++]=3Dp;
}
}
When actually run, EGCS did't generate any code for the frame=3D0 line,
resulting in huge memory corruption problems (it doesn't notice that
a local variable is re-used if the reuse is in the context shown and nowh=
ere
else, so it decides to remove the redundent (as it thinks) frame=3D0 line=
=2E That's
great......I had to include another use of frame later on to ensure it wa=
s set
to zero correctly (this happened even with no optimisation at all - mega =
bug).
Craig.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Sat, 26 Jun 1999 19:40:53 +0100
Reply-To: [EMAIL PROTECTED]
"Vladimir Z. Nuri" wrote:
>
> Alexander Viro ([EMAIL PROTECTED]) wrote:
>
> : Grasshopper, it's not you, it's boredom.
>
> what a coincidence!! you bore me to tears too!! when you want to
> talk about something I wrote rather than your delusions of grandeur or
> kookdom, plz drop me line!!
Aaaah, isn't it nice when old friends get re-united :)
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (Manickam Umasuthan)
Subject: Differences in /usr/include/sys/ipc.h
Date: 27 Jun 1999 20:03:08 GMT
Reply-To: [EMAIL PROTECTED]
I have two different versions of the ipc.h in RedHat 6.0 and Slackware
Linux OSs.
My problem is as follows. I like to use __POSIX__SOURCE macro to compile
some programs. However RedHat 6.0 forces me to use either __XOPEN__SOURCE
or __SVID__SOURCE.
The software fails to compile under RedHat 6.0. Could someone
please let me know how to use the __POSIX__SOURCE macro with
/usr/include/sys/ipc.h under RedHat 6.0??
Thanks
[EMAIL PROTECTED]
=====================================================================
Slackware Linux distribution --- /usr/include/sys/ipc.h
=====================================================================
#ifndef _SYS_IPC_H
#define _SYS_IPC_H
#include <features.h>
#include <linux/ipc.h>
__BEGIN_DECLS
extern key_t ftok __P((char *__pathname, char __proc_id));
extern int __ipc __P((int __call, int _first, int __second,
int __third, void * __ptr));
__END_DECLS
#endif /* _SYS_IPC_H */
=====================================================================
RedHat 6.0 Linux distribution --- /usr/include/sys/ipc.h
=====================================================================
/* Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.
You should have received a copy of the GNU Library General Public
License along with the GNU C Library; see the file COPYING.LIB. If not,
write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
#ifndef _SYS_IPC_H
#define _SYS_IPC_H 1
#include <features.h>
/* Get system dependent definition of `struct ipc_perm' and more. */
#include <bits/ipc.h>
#if !defined __USE_SVID && !defined __USE_XOPEN && __GNUC__ >= 2
# warning "Files using this header must be compiled with _SVID_SOURCE or _XOPEN_SOURCE"
#endif
__BEGIN_DECLS
/* Generates key for System V style IPC. */
extern key_t ftok __P ((__const char *__pathname, int __proj_id));
__END_DECLS
#endif /* sys/ipc.h */
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: File Allocation Tables
Date: Sat, 26 Jun 1999 19:55:18 +0100
Reply-To: [EMAIL PROTECTED]
Adam Brinley Codd wrote:
>
> > You'll find some format info in the Documentation directory of the
> > kernel source. The guy who wrote the FAT filesystem support has
> > documented it some.
>
> Is this available on a web site somewhere, because I can't find the
> directory on my CD?
http://www.kernelnotes.org/
Half way down the page, under the _Kernel_Development_Information_
section is a subsection titled _Source_Browsers_.
--
Tristan Wibberley
------------------------------
From: Roope Anttinen <[EMAIL PROTECTED]>
Subject: Re: vesafb for S3 868?
Date: 26 Jun 1999 18:45:52 GMT
Reply-To: [EMAIL PROTECTED]
JAGAT P BRAHMA <[EMAIL PROTECTED]> wrote:
> I am a newbie. can somebody tell me how to apply that patch to the kernel
> 2.2.9.
> I have already downloaded the kernel and unpacked it( unzipped and
> untarred).
The linux source tree has to be named linux-2.2.9 for that particular patch.
Then in /usr/src directory do:
zcat patch-s3lfb-2.2.9.gz | patch -p0
Roope
BTW: The patch works also against kernel 2.2.10
--
MicroSoft? is that some kind of a toilet paper?
PS: Look for address here, not from headers. And remove NOSPAM's
___________________________________________________________________________
[EMAIL PROTECTED] / [EMAIL PROTECTED]
+358 9 812 7567 / +358 500 445 565 / +358 49 445 565
http://myy.helia.fi/~anttiner/index.html
===========================================================================
Helsinki Business Polytechnic - Institute of information technology
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 27 Jun 1999 17:36:35 -0400
[EMAIL PROTECTED] (Bruce Hoult) writes:
> In article <[EMAIL PROTECTED]>, Johan Kullstam
> <[EMAIL PROTECTED]> wrote:
>
> > [EMAIL PROTECTED] (Nathan Myers) writes:
> >
> > > Thomas Steffen <[EMAIL PROTECTED]> wrote:
> > > > C++ might not be a very elegant language, but it is
> > > >fast, at least compared to other OO languages.
> > >
> > > Its syntax isn't very elegant, but where did that come from?
> > > It's fast compared to _any_ language, period. People who say
> > > it's slower than (e.g.) C are just spreading FUD.
> >
> > C++ *is* slower than C. not by orders of magnitude or even a factor
> > of two, but if you feed code to both C and C++ compilers, the C
> > compiler will optimize harder and generally make a better product.
> > this is because C is more mature and that C++ code is potentially more
> > complex which causes a more conservative compile.
>
> I'd love to see an example of this.
>
> Given...
>
> 1) code that is both valid C and valid C++, and
> 2) a C++ compiler that compiles to C (e.g. AT&T CFront)
>
> ... you will end up with identical machine code, no matter whether you
> compile with the C compiler, or compile with the C++ compiler (using the
> same C compiler as the back end).
>
> You may be able to find some particular C++ compiler that produces worse
> code compiling a C program than some particular C compiler, but that is a
> function of the compiler, not the language.
>
>
> > on the other hand, common-lisps like CMUCL can acheive near C or
> > fortran execution speed. speed is not exclusively the domain of the
> > C-like languages.
>
> I agree. The biggest problem with this is that Common Lisp is limited by
> things such as the lack of type (and other) declarations which would
> otherwise allow the compiler to generate even better code in many
> situations.
this is simply not true. lisp *has* types. lisp *has* type
declarations. just because the langauage doesn't require explicitly
declaring them everywhere doesn't mean it will not let you specify
type and optimize accordingly.
<URL:http://www.mindspring.com/~rtoy/software/cmu-user/index.html>
look at chapter 5 especially.
for example, in 5.13.3 we have this little fuction
(defun eff-note (x y z)
(declare (type (unsigned-byte 18) x y z))
(+ x y z))
see how the types really are defined. the compiler will optimize this
heavily.
> Dylan is much like Lisp, but has (optional) declarations of all
> sorts of things to aid program correctness and compiler
> optomisation. CMU Dylan (aka Gwydion Dylan, aka d2c) does the same
> sort of optomisations as CMUCL, and more.
dylan is a lisp variant with infix syntax. however, the syntax of
dylan makes macros difficult. that is why i like common lisp.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 27 Jun 1999 17:42:53 -0400
[EMAIL PROTECTED] (Nathan Myers) writes:
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
> >the memory fragmentation problem pretty much precludes seriously using
> >C++ for kernel work. look to microsoft for examples of C++ in action.
> Nazis eat peanut butter. Therefore peanut butter is bad.
thanks for trying godwin's law.
> This supposed "memory fragmentation problem" is just more FUD.
> Shame on you, Johan.
no, this one really *is* *true*. if you malloc and free a lot of
things of different sizes, then heap memory does get chopped up. there
are little bits of free memory here and there. you cannot consolidate
them. and when allocating you search around for these free holes.
the typical C++ program does a lot of malloc and free. memory
fragmentation does occur and it does cause performance loss.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 27 Jun 1999 17:20:37 -0400
[EMAIL PROTECTED] (Don Waugaman) writes:
> In article <[EMAIL PROTECTED]>,
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>
> [ referring to two code snippets to create a float matrix, in C & C++ ]
>
> >you forgot the freeing step. -- and the debug the memory management
> >step when you free the wrong thing or the right thing twice or forget
> >to free it at all.
>
> I take it that the above is your opinion of the C code, since the C++
> program suffers from none of these problems.
>
> > -- and the my memory is fragmented into oblivion
> >after all these malloc/frees so now my performance is losing hard.
>
> Which is as much a problem for the C code as for the C++ code, if not
> more so since schemes such as reference-counted objects is more
> difficult to implement in C.
yes. C and C++ because of explicit pointers preclude intelligent
memory management. you get reference counting, but you do not get
consolidation of older objects in the heap into contiguous memory.
and in C, mallocs tend to be rare. most C programs will malloc
everything they need right off the bat and keep hold of the memory
until they exit. however, C++ encourages more dynamic memory
exercising because its syntax hides the malloc/free somewhat.
> >the memory fragmentation problem pretty much precludes seriously using
> >C++ for kernel work.
>
> I don't think that memory fragmentation is worse in C than in C++.
> It's true that some features of C++ can cause programmers to use
> dynamic memory more than in C. but that's an attribute of the use of
> the language, not of the language itself.
>
> What it means is that in areas where memory fragmentation is an issue,
> you'll have to be very careful about how you manage memory. This is
> an issue in C programs as well, of course. The difference is that you
> can use C++'s features to more easily move between different methods
> of memory and fragmentation management.
in eg lisp you let your vendor take care of this for you.
> For example: collection templates in the C++ Standard Library take an
> "allocator" template parameter, which means that you can substitute in
> your own memory allocator if the built-in one isn't acceptable for your
> needs. This is part of what makes the C++ SL a rather robust design -
> and something that can't be done without C++'s substantial template
> support.
is `alloca' a valid `allocator'?
> A good designer will build something that is flexible and reusable - a
> poor one will create a mess. You've probably seen more C++ messes than
> C messes because there are fewer good C++ designers, largely because it
> takes a lot longer to become a good C++ designer. I don't mention this
> as a strength of C++ - it's not - but it's not wise to blame the tool
> for the poor hand that wields it, either.
>
> > look to microsoft for examples of C++ in action.
>
> You left out the phrase "poor use of" between "of" and "C++" in this
> sentence. Again, this is caused largely by libraries written by people
> with poor C++ design skills.
>
> >do you really mean that all this C++ incantation is somehow easier
> >than
> >
> > (let ((vec (make-array nelems :element-type single-float)))
> > ...)
> >
> >and then letting the garbage collector reap the results?
>
> Syntactically, I'd consider this to be about equal in complexity to
> the previous examples. However, the previous examples do clean up
> the vector when done, though you seem to be asserting the contrary
> in your last line.
>
> >C has the benefit of being rather lightweight and efficient. C++ can
> >be efficient when it comes to execution speed, but it is tedious to
> >program in resulting in poor development speed and poor
> >maintainability.
>
> I consider C++ to be a heck of a lot less tedious for programming than
> C, and the programs I write are done faster and are more easily
> maintained - though at least in part because C++ makes me think about
> the design more.
>
> >after using lisp's macros i don't know whether to laugh or cry when i
> >think of C++ templates.
>
> Could you describe what you don't like about C++ templates, and how a
> statically-checked language that intends to minimize runtime cost could
> do better?
static type checking has nothing to do with anything. imho it's a
negative. static types are more a disadvantage the larger and more
complex a program gets.
C++ doesn't have insignificant runtime costs. when you buy into the
complexity that C++ offers you, i think a more heavyweight language is
in order.
for example, here's a little macro i made in lisp
;; grouping function
(eval-when (:compile-toplevel :load-toplevel)
(defun group (source n)
(if (zerop n) (error "zero length"))
(labels ((rec (source acc)
(let ((rest (nthcdr n source)))
(if (consp rest)
(rec rest (cons (subseq source 0 n) acc))
(nreverse (cons source acc))))))
(if source (rec source nil) nil))))
;; setf helper
(defmacro _f (op place &rest args)
(multiple-value-bind (vars forms var set access)
(get-setf-expansion place)
`(let* (,@(mapcar #'list vars forms)
(,(car var) (,op ,access ,@args)))
,set)))
(defmacro asetf (&rest implicit-pairs)
;; unroll for multiple pairs
`(progn
,@(mapcar (lambda (pair)
`(_f (lambda (it)
(declare (ignorable it))
,(cadr pair))
,(car pair)))
(group implicit-pairs 2))))
in lisp assignment is done with setf
(setf foo 3)
is (roughly) equivalent to C
foo = 3;
now, i liked C's += -= &c operators. but how to do it in lisp? well,
there are incf and such, but i wanted something bigger. immagine a
an operator called _= where on the right hand side _ would be the left
hand side.
x _= foo(_);
would be the same as
x = foo(x);
this is not terribly important when x is just a variable, but if the
left hand side is complex and involves much pointer chasing like
x->y->z->w[5] then having a way to reference it would be a win.
x->y->z->w[5] _= fabs(_);
could perform
x->y->z->w[5] = fabs(x->y->z->w[5]);
the first is more clear imho just like += and friends.
with the lisp macros i made
(asetf foo (abs it))
is equivalent to
(setf foo (abs foo)).
whether asetf or _= are worthwhile ideas is not my point. my point is
that in lisp you *can* make an asetf. in C++, no matter what
templates you have, you cannot create a new operation like _=.
also note that in the definition of asetf i used a lisp function
group. how do you invoke C++ functions to help you expand a C++
template? what about functions which are 99% the same but differ in
one spot. how can you make an template-if which could invoke the
right part based on the type or some aspect of the type being passed?
consider a min function in C++ that you wish to templatize
template <class X>
X min(
X a,
Y b)
{
return a < b ? a : b;
}
how do you use this for classes for which < is not defined? how would
you substitute another definition of < if two less-than concepts would
make sense for a certain class? perhaps you could pass a function.
but now < and the alt_less_than function would take different syntaxes
and hence not work like
min(a,b,<) and min(a,b,alt_less_than)
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Where is the compose key?
Date: Sun, 27 Jun 1999 23:04:53 +0200
Hi,
where in the kernel is the default setting for "Compose", i.e. which
keys have to be pressed to start a compose sequence.
The problem behind it: I don't like dead-keys. I need those special
characters occasionally. I don't want to remember ASCII-Codes, to input
them as ALTLEFT+DIGIT DIGIT DIGIT.
I've been looking at the Keyboard-HOWTO, the man-pages and outputs of
various programs related to the keyboard. I even tried to understand to
some extent what is happening in the kernel when reading from keyboard
and putting characters to the console. But I couldn't figure out myself.
Well, under X11 this is no problem, but on console... It is mentioned
everywhere, but not what you have to press.
Bye,
Bernd Strieder
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Mon, 28 Jun 1999 10:54:37 +1200
In article <[EMAIL PROTECTED]>, Johan Kullstam
<[EMAIL PROTECTED]> wrote:
> > > on the other hand, common-lisps like CMUCL can acheive near C or
> > > fortran execution speed. speed is not exclusively the domain of the
> > > C-like languages.
> >
> > I agree. The biggest problem with this is that Common Lisp is limited by
> > things such as the lack of type (and other) declarations which would
> > otherwise allow the compiler to generate even better code in many
> > situations.
>
> this is simply not true. lisp *has* types. lisp *has* type
> declarations. just because the langauage doesn't require explicitly
> declaring them everywhere doesn't mean it will not let you specify
> type and optimize accordingly.
Yes I *know* Lisp has type declarations. See the "(and other)" above.
Does CMUCL have a way of declaring that a certain class will never have
subclasses added? Does CMUCL have a way of declaring that a certain
generic function will never have methods added or removed?
If it doens't then how can it optomise this call? Some other bit of code
may change what "+" means at runtime.
-- Bruce
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Mon, 28 Jun 1999 10:59:14 +1200
In article <QGtd3.4830$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> In comp.os.linux.development.system Nathan Myers
<[EMAIL PROTECTED]> wrote:
> : Linus Torvalds <[EMAIL PROTECTED]> wrote:
> :>Bruce Hoult <[EMAIL PROTECTED]> wrote:
> :>
> :>But what others are saying is "a lot of existing C++ compilers generate
> :>worse code than a lot of existing C compilers". And they are right too.
> :>
> :>Sometimes theory matters. Sometimes it doesn't. The world is not as
> :>simple as you make it out to be.
>
> : Enough generalities. Take for example Egcs. C and C++, same code
> : generator, same optimizer. The last time you tried g++ was years
> : and years ago. It's time to look again.
>
>
> Using the latest egcs (from CVS) to compile a C program, with options
> '-fno-exceptions -fno-rtti -O2', the C assembler output is still
> smaller (in terms of # of instructions, not symbol length) while
> producing the same results.
>
> C++ is still slower and bulkier.
I don't understand. C compilers don't have rtti and exceptions, so you're
clearly using a C++ compiler to compile C code. Cool.
Now, which C compiler are you comparing it against to say that "egcs
-fno-exceptions -fno-rtti -O2" is worse than it?
-- Bruce
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
