Linux-Development-Sys Digest #930, Volume #6 Sat, 3 Jul 99 22:13:56 EDT
Contents:
Re: Why not C++ (John Stevens)
Re: Why not C++ (Larry Blanchard)
Re: C++ templates: More than Turing Complete? (Tenexus)
Re: Why not C++ (Kaz Kylheku)
Re: C++ templates: More than Turing Complete? (Johan Kullstam)
Kernel 2.2, slow networking (John Stevens)
Re: Why we are still holding on to X Windows ("Thomas Steffen")
Re: Winmodem in Linux? Help! (David M. Cook)
Re: Why we are still holding on to X Windows (Todd Knarr)
Re: Why we are still holding on to X Windows (John Stevens)
Re: Why we are still holding on to X Windows (John Stevens)
Re: gcc byte packing of inherited class data (Shankar Unni)
Re: Smallest memory allocation block? (Robert Nichols)
Re: using C++ for linux device drivers ([EMAIL PROTECTED])
Re: Why not C++ (Justin Vallon)
Re: Remote login problems in custom RedHat env... (Bryan)
Re: Why not C++ (Nathan Myers)
Re: Kernel 2.2, slow networking (Peter Mardahl)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Stevens)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 17:25:46 GMT
On 1 Jul 1999 20:47:54 -0700, david parsons <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Bruce Hoult <[EMAIL PROTECTED]> wrote:
>
>>Dylan is not several hundred percent slower than C as Java is.
>
> Have you benchmarked Java vs C on the same machine? (No, I don't
> mean benchmarking C on a machine vs Java running on a p-machine
> on that machine); there's certainly nothing in the design of
> Java that would make it much slower than C on the same machine.
Excuse, but:
Java, even compiled to machine code, will be slower than C or C++.
Java requires a run time system (ala Objective-C), making it both more
dynamic, and slower.
In fact, Java is more like Objective-C, except for the truly
horrible syntax, than C++.
John S.
------------------------------
From: Larry Blanchard <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 03 Jul 1999 09:13:23 PDT
Reply-To: [EMAIL PROTECTED]
Enough already!
Can we let this thread die now? It's had more arguments than Northern
Ireland!
--
Larry Blanchard - Old roses, old motorcycles, and old trains
Homo Sapiens is a goal, not a description.
------------------------------
From: [EMAIL PROTECTED] (Tenexus)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: Sat, 03 Jul 1999 18:01:42 GMT
On 2 Jul 1999 16:16:52 -0400, [EMAIL PROTECTED] (Alexander Viro)
wrote:
>
>Oops. Hate to followup to myself, but...
>
>In article <7li0fd$[EMAIL PROTECTED]>, I wrote:
>>In article <[EMAIL PROTECTED]>,
>>Stephan Houben <[EMAIL PROTECTED]> wrote:
>>>No, not every C++ program is compiled to a finite amount of assembly.
>>>Take the following counter-example:
>>>----------------begin code------------------
>>>template <class A>
>>>void call_me(A a, int i)
>>>{
>>> if (i > 0)
>>> call_me(&a, i - 1);
> ^-- arrgh. Sorry, I missed it. That's what one gets for posting
>when too low on caffeine...
> But comment still stands:
>
[clip]
Not really. A compiler is required to support only 12 levels of
pointer indirection (at least for ANSI C). I would assume a similar
restriction exists for C++. Hence this program degenerates into
INVALID C++ at runtime.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 18:05:54 GMT
On 03 Jul 1999 09:30:01 -0400, Johan Kullstam <[EMAIL PROTECTED]> wrote:
>not at all. dynamic typing does not imply sloppiness. on the
>contrary, it facilitates graceful error recovery.
I think that people are simply confusing ``no typing'' with ``dynamic typing''.
>> The canonical example is the message that pops up on the screen in an
>> airplane cockpit: "Method not implemented".
>
>you might just be able to recover from a `method not implemented'.
Or if the plane is programmed in C++, you might get a ``pure virtual function
called''. :)
Actually ``method not implemented'' is sometimes done in C anyway. Just look in
the Linux kernel. Null function pointers are used in many places to indicate
that some operation is not supported. For example, the SLIP line discipline
module does not bother implementing poll, read or write. The code that
dispatches control to these functions must check and recover.
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 03 Jul 1999 14:05:14 -0400
[EMAIL PROTECTED] (Tenexus) writes:
> On 2 Jul 1999 16:16:52 -0400, [EMAIL PROTECTED] (Alexander Viro)
> wrote:
>
> >
> >Oops. Hate to followup to myself, but...
> >
> >In article <7li0fd$[EMAIL PROTECTED]>, I wrote:
> >>In article <[EMAIL PROTECTED]>,
> >>Stephan Houben <[EMAIL PROTECTED]> wrote:
> >>>No, not every C++ program is compiled to a finite amount of assembly.
> >>>Take the following counter-example:
> >>>----------------begin code------------------
> >>>template <class A>
> >>>void call_me(A a, int i)
> >>>{
> >>> if (i > 0)
> >>> call_me(&a, i - 1);
> > ^-- arrgh. Sorry, I missed it. That's what one gets for posting
> >when too low on caffeine...
> > But comment still stands:
> >
> [clip]
>
> Not really. A compiler is required to support only 12 levels of
> pointer indirection (at least for ANSI C). I would assume a similar
> restriction exists for C++. Hence this program degenerates into
> INVALID C++ at runtime.
it never gets to runtime. the compile fails because the template
recurses and doesn't bottom out before the compiler gives up.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (John Stevens)
Subject: Kernel 2.2, slow networking
Date: Sat, 03 Jul 1999 17:12:32 GMT
I have a home network that consists of two Linux machines running
on 10 base T cable, at 10 MBps, using two NE2000 compatible network
cards.
When both machines were installed with RedHat 5.2 (kernel versions
in the 2.0.3x range) I could FTP a file from one machine to the other
at around 450 to 600 KBytes per second.
One machine was installed with RedHat 6.0 (kernel versions 2.2.5 and
2.2.10) and now, for some reason, the best speed I can get is 24 KBytes
per second.
What changed in kernel version 2.2 that slowed this down so very much?
Anybody have any idea?
John S.
------------------------------
From: "Thomas Steffen" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 03 Jul 1999 21:10:10 +0200
Mario Klebsch <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Mike McDonald) writes:
>
> > Second, X isn't suppose to have a "style guide".
...
> > You're real problem is not that there isn't one written done for Unix/X11
> >but that there are too many. A completely different problem.
>
> You call it too many standards, I call it absence of standard. How do
> you call something standard, if it is not agreed upon?
maybe you forget the most important point: not the author is to decide
how a program "feels", but nor is any standard around. it is up to the
user to decide how programs should behave. in theory the user should
be able to switch a program from motif style to (eg) kde style. a few
approaches in this direction have been made, see (parc place)
smalltalk or the Qt library. maybe the most promissing option is
wxWindows, which supports MSWindows, MacOS, Qt, Gtk+, motif and
XView. and have a look an some Enlightment theme pages, it is amazing
how different windows can look under the same window manager.
"one size fits all" is Micro$oft FUD, 'coz it doesn't.
--
linux, linuctis - f, das beste Betriebssystem ;-)
------------------------------
From: [EMAIL PROTECTED] (David M. Cook)
Subject: Re: Winmodem in Linux? Help!
Reply-To: [EMAIL PROTECTED]
Date: Sat, 03 Jul 1999 20:40:28 GMT
On Sat, 3 Jul 1999 10:00:56 +0200, JN <[EMAIL PROTECTED]> wrote:
>I got a Winmodem in my computer. Can I make so I can run it under Linux or
>must I buy a new?
You have 2 choices:
* spend many hours of aggravation trying to get something to work that in
all likelihood will never work.
* buy an external modem. If you believe that time=money, it will pay for
itself.
Dave Cook
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 3 Jul 1999 21:08:16 GMT
In comp.os.linux.development.system Mario Klebsch
<[EMAIL PROTECTED]> wrote:
> Integration with X11 and having a separate protocol are not oposite
> positions. You can have your own sound protocol, but integrate it
> into X11. As I have mentioned in an early posting, I can imagine using
> X11 resources to store references to use for audio. Perhaps the
> references can use a syntax like URLs.
That would be application configuration, which has little or nothing to
do with the sound protocol in use. The protocol should not care how the
application stores information about what things the application will
need, like the name of the sound server or the location of sounds it
needs to play.
Also, in my view there's a difference between "integrated with" and
"can be used by or in conjunction with". Eg. LBX is integrated with X11,
in that you need the X11 protocols for LBX to make sense at all. HTTP and
HTML, OTOH, can be and regularly are used by X11 applications but they are
not integrated into X11.
--
Collin was right. Never give a virus a missile launcher.
-- Erk, Reality Check #8
------------------------------
From: [EMAIL PROTECTED] (John Stevens)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Sat, 03 Jul 1999 21:50:10 GMT
On Sat, 3 Jul 1999 13:19:14 +0200,
Mario Klebsch <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Alan McLean) writes:
>
>>Mario Klebsch <[EMAIL PROTECTED]> wrote:
>>> This topic is just not covered by X11.
>
>>You are right. However, this is by design.
>
>I know, and this is, what I criticise. Of course I am vary well aware,
>that it is not needed inside the X server, but IMHO it is needed, if
>X wants to compete with MS-Windows or MacOS.
Who ever claimed that X wanted to compete with Windows or MacOS?
GNOME or KDE may want to, and even be able to, compete against Windows/MacOS,
but talking about X competing is the equivalent of talking about having
a video card manafacturer compete against Windows/MacOS.
>As I say, there is no real standard except X11,
And you're wrong. This is either inadvertent FUDL, or deliberate.
There are indeed GUI standards. Try reading the Motif style guide, for
starters.
>so if X11 would include
>a standard GUI, it probably would autoimaticly become standard on most
>systems.
Probably not. The technology necesary to support X on most systems was
not available until relatively recently (last 8 to 10 years).
John S.
------------------------------
From: [EMAIL PROTECTED] (John Stevens)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Sat, 03 Jul 1999 21:53:31 GMT
On Sat, 3 Jul 1999 13:23:19 +0200,
Mario Klebsch <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Chris Hedley) writes:
>
>>I have a Motif Style Guide lying around somewhere. I can't find it at
>>the moment, but it's very large and heavy.
>
>.. and I have read it several years ago, as I have done with the open
>look styleguide, too. I found lots of their principles in MacOS and in
>Windows 95, but a lot of X11 programs still do ignore these guides
>completely. :-(
Not all programs are written for the Motif GUI, therefore, not all of them
*SHOULD* follow the Motif style guide.
>And the developer community would have to agree on one of them. And year
>after year lots of programs are written, each only acording to the autors
>stype giude. Delaying only makes the problem bigger and bigger.
There is no real, serious problem. Those who use Unix very quickly learn
that the issues that most GUI arguments raise are trivial. . . we quickly
learn to abtract general principles, and after that, we don't really care
that much.
For those that have some kind of fixation on which side of the window your
scroll bar is: there are GUI's. Stick with one, instead of mixing and
matching.
John S.
------------------------------
From: Shankar Unni <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc,gnu.g++,comp.os.linux.development
Subject: Re: gcc byte packing of inherited class data
Date: Sat, 03 Jul 1999 14:40:59 -0700
Bruce Edge wrote:
> I can't get gcc to pack this data:
> class a { char c; };
> class b { long l; };
> class c : public a, public b { };
> I need the alignment for class c to be:
> cc ll ll ll ll
No can do.
Most C++ compilers ignore packing attributes across base class
boundaries, because it's too painful to deal with possible unaligned
virtual table pointers, etc. And rather than try to distinguish between
classes that have virtual tables, and those that don't, many just apply
this rule in a blanket fashion.
Besides, I can conceive of situations in which a compiler cannot
determine whether a particular class is a member of a packed structure
or not.
Bottom line: if you want to play with packed structures, make sure that
the entire packed "structure" (in real life) is modeled by a single
packed struct in your code.
You can then wrap some other class around it to manipulate the contents
of this packed struct. Heck, you can do whatever sort of inheritance,
etc., that you want, provided that each subclass maintains its own
packed buffer separately, and you have some sort of composition and
unpacking methods at the top level to collect all the pieces of the
packed structure and assembles them for transmission, or vice versa.
--
Shankar Unni [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Robert Nichols)
Subject: Re: Smallest memory allocation block?
Date: Sat, 3 Jul 1999 19:12:21 GMT
In article <[EMAIL PROTECTED]>,
Juergen Heinzl <[EMAIL PROTECTED]> wrote:
:In article <7l0odp$ell$[EMAIL PROTECTED]>, Anand wrote:
:>What is the smallest amount of memory that Linux allocates? If I do
:>"malloc(1)" does Linux allocate only 1 byte from its internal free
:>memory pool or is there a minimum amount of memory that is allocated?
:>
:>If the amount of memory requested is less than this minimum then is the
:>remaining memory in the allocated block a waste or is it used for any
:>purpose?
:>
:>An answer for any version of Linux kernel is good enough for me.
:
:It is one page and the actual page size can differ ...
:#include <stdio.h>
:#include <unistd.h>
:
:int main() {
: printf( "%lu\n", (unsigned long)getpagesize() );
:}
:... so I do not want to state 4K is true on DEC's too.
Yes, the kernel gives memory to the application in page sized blocks,
but the original question appeared to be about how malloc() parcels out
the memory in the blocks it obtains from the kernel. This appears to be
in minimum increments of 8 bytes, at least for the malloc() in my rather
archaic libc-5.2.18. You can always write your own malloc()/free() to
manage memory any way you want.
$ cat tryit.c
#include <stdio.h>
#include <stdlib.h>
int
main()
{
unsigned int n;
for(n = 1; n <= 16; ++n) {
printf("%2u at %lx\n", n, (long)malloc(n));
}
return(0);
}
$ make tryit && tryit
cc -Wall -O2 tryit.c -o tryit
1 at 8005000
2 at 8005ff8
3 at 8005ff0
4 at 8005fe8
5 at 8005fe0
6 at 8005fd8
7 at 8005fd0
8 at 8005fc8
9 at 8007000
10 at 8007ff0
11 at 8007fe0
12 at 8007fd0
13 at 8007fc0
14 at 8007fb0
15 at 8007fa0
16 at 8007f90
$
--
Bob Nichols [EMAIL PROTECTED]
PGP public key 1024/9A9C7955
Key fingerprint = 2F E5 82 F8 5D 06 A2 59 20 65 44 68 87 EC A7 D7
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: using C++ for linux device drivers
Date: Sun, 20 Jun 1999 23:45:14 GMT
Justin Vallon <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Alexander Viro) writes:
:> In article <7kdqj9$l1o$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
:> >Hi all,
:> >
:> > I am working a sound driver for linux (I will probably use OSS).I
:> >am planning to use C++, instead of C. Has anyone used C++ before for
:> >kernel/device driver programming for linux. If so what are the
:> >complications with using C++. I heard that C++ needs some OS support,
:> >especially for calls like "new", "delete" and stuff like that.
:>
:> It will not get it. It's beaten to death many, many times. Oh, and forget
:> about try and catch - they are not going to work. Ditto for standard classes
:> - runtime environment is not available too.
: Too bad. All you should need is:
: void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
: void operator delete(void *p) { free(p); }
: Compile with -nostdinc++ -fno-exceptions.
: Static constructors may need a C++ link phase, or you could warn that
: C++ static constructors will not be executed.
The main argument against C++ is still overhead. Even when you turn off
many of the features, you still have overhead that is greater than C.
Check out EROS, currently being discussed on linux-kernel. It is an OS
that _was_ written in C++, and the author thinks this was a bad
decision.
Jeff
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 3 Jul 1999 01:31:54 -0400
[EMAIL PROTECTED] (Chance Harris) writes:
> Johan Kullstam ([EMAIL PROTECTED]) wrote:
>
> : the developers of C++ think so too. templates are a way to avoid
> : explicit typing.
>
> I disagree.
>
> I think they are a hack to get around the lack of parameterized typing.
Stated another say, they are an implementation of parametric
declarations.
--
-Justin
[EMAIL PROTECTED]
------------------------------
Date: Sat, 03 Jul 1999 20:45:10 +0000
From: Bryan <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.security
Subject: Re: Remote login problems in custom RedHat env...
> DNS is disabled on this box. I've even gone as far as to remove the resolv.conf
> file.
That's what I meant. It can't do a reverse lookup (as mentioned in
another reply).
> Besides, tcpdump shows that the box is able to send acks to whatever
> remote machine is involved.
I would hope so. That's ethernet protocol. ;)
> Also remember that all established connections can
> reach any host via telnet, ftp, rlogin, etc... (as long as they're in the hosts
> table of course).
It may still be trying to perform reverse lookups. There is somewhere
where you tell it how to look up names on the network, and you can
configure the order (hosts, NIS, DNS, etc.) I'm assuming that's been
set to only use /etc/hosts...
> As for the network card, this problem has been replicated on
> three other identical systems to rule out just that.
You're saying you got the exact same problem on the other three
identical computers? Did they use the exact same brand of network card,
or different types? (Different NICs rules out driver problem; different
machines rules out bad NIC problem.) You might have a driver problem if
all NICs are identical. Try to replicate it in unidentical machines,
using the same NIC and drivers, or on identical machines with different
NICs.
> Network traffic is non-existent on this box. I've even prevented misc. services such
>> as sendmail from starting to make sure to no avail. Thanks for your responses
>though.
>
Then it should be easy to tail the logs and watch tcpdump
simultaneously, provided that the aforementioned NIC and driver tests
fail to prove anything.
> Wally
> [EMAIL PROTECTED]
>
-- Bryan Scott
-- CTR Online Systems Administration
> Bryan wrote:
>
> > Jon Skeet wrote:
> > >
> > > [EMAIL PROTECTED] wrote:
> > >
> > > > I have an unusual problem with telnet, rlogin, ftp and any other
> > > > program which requires logging in remotely. The system specs are: 400Mhz
> > > > Pentium Pro, 256MB RAM, onboard Intel etherexpress pro 10/100Mbs network
> > > > card, 2 serial ports, running a custom Red Hat 5.2 kernel. Four kernel
> > > > header files were modified to allow for a 3072 process limit ( fs.h,
> > > > limits.h, posix_types.h, /usr/include/gnu/types.h ). The machine will
> > > > boot and run fine for about 10 minutes then any form of remote log in
> > > > (even rcp and rsh) will hang after it successfully connects to the
> > > > system just before it gives you the opportunity to provide your login
> > > > name and/or password. On telnet you can even see the "Connected to
> > > > <host>" message. Any connection made before this problem occurs is fine
> > > > and has full capabilities. I can get out of the box using any method I
> > > > choose (telnet, ftp, etc). The oddest thing about this problem is that
> > > > all other inetd services are unaffected. They continue to respond to
> > > > request on their respective ports without fail. A tcpdump on the machine
> > > > will show telnet, rlogin, etc ... activity. They send their initial acks
> > > > and replies but don't complete their initialization procedures.
> > >
> > > Is it feasible that the problem is in reverse host lookup? I know telnetd
> > > checks that the host that is telnetting to it is valid before going ahead
> > > with the connection; it's possible that rcp does the same. If so,
> > > possibly your DNS is going wrong...
> > >
> >
> > I agree; it could be reverse DNS or no DNS at all.
> >
> > Another idea: Network card burps...
> >
> > How much activity is there once the system is up? I had a Netgear
> > 10/100 card in my box with one of the original DEC tulip chips (they've
> > since created their own proprietary set due to DEC's discontinuation of
> > the 21something series), and it would come up with some overrun problems
> > at high NFS loads. I finally swapped it with a newer one I had bought
> > for a Windows box, and the old card works fine in the Windows box, and
> > the new one works beautifully in the Linux box (gotta love 100Mbps).
> > (Probably some inconsistencies with the tulip driver and that older
> > chipset..)
> > .
> > Which kernel version are you using? You can use the 2.2.x kernel series
> > on Redhat 5.2. A custom RedHat 5.2 kernel sounds like you used th
> > 2.0.36 kernel that came with it.
> >
> > 2.2.5 runs really stable on three of my 5.2 machines. I'm suggesting a
> > kernel and network card driver upgrade because even if you turn off
> > networking, like you said you're doing, the card may still be on the
> > fritz, and there may be a compatibility issue with the EtherExpress
> > Pro. (Is that intel or 3com? 3com's drivers were semi-broken in
> > 2.0.36...)
> >
> > > --
> > > Jon Skeet - [EMAIL PROTECTED]
> > > http://www.pobox.com/~skeet/
> >
> > -- Bryan Scott
> > -- CTR Online Systems Administration
> > (remove the NOSPAM. for email)
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: 3 Jul 1999 18:32:59 -0700
Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>Nathan Myers wrote:
>> Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>> >Nathan Myers wrote:
>
>> The point you missed is that the most important aspects of C++ are
>> its expressive powers, and specifically those designed to help
>> decompose problems into libraries. Maintainability and robustness
>> depend on effective decomposition. But it isn't enough to be able
>> to code something, you must be able to *afford* to code it.
>
>This also not to say that other languages aren't as good in
>decomposing problems. Object-Orientation isn't always the best
>paradigm for a given problem, granted it will probably produce
>a better decomposition of the problem domain than for instance
>top-down structured analysis.
C++ is _not_ an Object-Oriented Language. It supports procedural
(top-down), object-oriented, generic, and functional styles, plus
others which don't have names but which we all use at times. It is
precisely this catholicity that makes it a good at decomposing
problems -- that is, writing libraries -- because big problems call
for different styles at different scales.
I don't know of any other language designed with such close attention
to the effect of design choices on library designers and users.
>Also dynamic extendibility is
>something not easy to achieve in C++ programs, many programs
>don't need it but some benefit greatly (for instance, Emacs).
One often achieves this in a C++ program by linking an interpreter.
Python is specifically designed to be used that way; some Scheme
interpreters are, also. Furthermore, the virtual function mechanism
lends itself to dynamically linked libraries, so much so that
Microsoft (probably unwisely) built their whole DLL architecture on
top of it.
(C programs that need dynamic extensibility get it the same way,
except they simulate virtual functions "by hand". The Linux kernel
and GNOME are examples of this.)
It is no Bad Thing to use two different languages in the same
program to address radically different goals.
>... including a standard for classes meant to interface with other
>compilers/languages would have been helpful.
>(something like: exported class <name> { <decl> };)
Already there: C++ defines a subset of its types to be "POD types"
which are compatible with C and with the standard C ABI for the
target. Approximately, a POD type is anything that can appear in
a C header. ("POD" is named by analogy with the telecomm jargon,
"POTS", which is usually elaborated as "Plain Old Telephone System".
I swear I am not making this up.)
>> The machine-code-speed requirement is what keeps the design honest.
>> There are too many low-level details to allow you to decide in each
>> case if your language primitives are fast enough. You have to be able
>> to trust that they always are as efficient as can be, because low-level
>> inefficiencies multiply. High-level efficiency leaves no room for
>> low-level design mistakes.
>
>But when you use a library (for instance the STL) you still have
>to decide what functions are fast enough.
The standard specifies the performance of low-level library functions,
where there is anything specifiable to count.
>> The combination of expressiveness in the construction of libraries,
>> and scrupulous fidelity to the real machine model, is what gives C++
>> its strength. That strength has been enough to overcome its most
>> unfortunate inheritances from C: bad declaration syntax and
>> promiscuous numeric conversions.
>
>I still run into the numeric conversions part in C++, the
>compiler should be a bit more helpful in informing about them
>especially signed/unsigned and float/int. I mostly program numerical
>algorithms for work.
Do you use '-Wall'? If you have suggestions for good warnings,
by all means send them to the Egcs maintainer. The quality of
a compiler's warnings makes a huge difference in its usefulness.
If you're doing numerics, do you know about the Blitz++ library
and its kin? See http://www.oonumerics.org/ .
>I don't have anything against
>using C++ in programs, but if they are meant to interface with
>other programs or especially if they are GUI toolkits, libraries,
>or something else meant for wide use, please do not engage in
>languistic (and compileristic) practices; create a C interface.
The C ABI _is_ the lingua franca, and will be for a long time.
Still, it's worth noting that some languages are taking on a
degree of direct C++ compatibility, including Eiffel, Java,
and Python.
(Thank you, Timo, for raising the level of discourse on this
thread far above what it had achieved.)
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Peter Mardahl)
Subject: Re: Kernel 2.2, slow networking
Date: 3 Jul 1999 18:50:09 -0700
In article <[EMAIL PROTECTED]>,
John Stevens <[EMAIL PROTECTED]> wrote:
>I have a home network that consists of two Linux machines running
>on 10 base T cable, at 10 MBps, using two NE2000 compatible network
>cards.
>
>When both machines were installed with RedHat 5.2 (kernel versions
>in the 2.0.3x range) I could FTP a file from one machine to the other
>at around 450 to 600 KBytes per second.
>
>One machine was installed with RedHat 6.0 (kernel versions 2.2.5 and
>2.2.10) and now, for some reason, the best speed I can get is 24 KBytes
>per second.
>
>What changed in kernel version 2.2 that slowed this down so very much?
Why don't you tell us what's in
/proc/net/dev
It's possible your ethernet drivers aren't configured correctly.
PeterM
------------------------------
** 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
******************************
