Linux-Development-Sys Digest #917, Volume #6 Wed, 30 Jun 99 17:14:20 EDT
Contents:
Re: Why not C++ (Greg Comeau)
Re: Postgresql Success rate (mlw)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Chris Double)
Re: Why not C++ (Greg Comeau)
Re: PTHREADS kernel/user level threading? (Dave Erdmann)
Re: Can Linux Boot and Run without a BIOS? (Bill Anderson)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Re: Wield system, X11 glibc2 or egcs1.1.2 broken? (Graffiti)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 30 Jun 1999 12:22:57 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Bruce Hoult)
writes:
>In article <7l3en8$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Don Waugaman) wrote:
>
>> 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?
>
>Well, here's what *I* don't like about C++'s templates...
>
>Actually, C++ templates are just fine -- they're probably one of the best
>parts of the language.
>
>The *problem* is that C++ templates are an ad-hoc solution to just one
>problem, and C++ has too *many* ad-hoc solutions. When you write a
>function in C++ you've got to choose between template functions, inline
>functions, overloaded functions, virtual functions ... it's a mess. (Yes,
>I know those choices aren't orthogonal, and can be combined -- that just
>makes it worse.)
>
>Bjarne Stroustrup started with the simple "one name = one function"
>principle in C and added on on virtual functions with runtime dispatch on
>the first argument so that he could emulate Simula.
>
>Then he thought "wouldn't it be nice if you could write new versions of
>'+' and '<' and use the same name for several similar functions of your
>own?". So he created overloaded functions, which are a completly
>different and incompatable thing from virtual functions.
>
>To try to close the gap between overloaded functions and virtual functions
>a bit, he eventually added template functions, which basically let you
>write a number of overloaded functions more economically.
>
>It's a big untidy mess. And sometimes you actually can't do what you want
>to do.
>
>Don't get me wrong -- I greatly admire Bjarne Stroustrup and think he did
>a great job, and C++ was a big improvement on the state-of-the-art in 1980
>when he started to implement it (or 1990, when it started to spread
>widely). But I think it's time to move on now.
Hmmm. Well, ok, yeah, sure, it does get a messy feeling.
But too, you then have to do more of a surmisal of the situation
that just that. It seems to me that these various aspects (solutions)
are necessary to meet the diversity of problems and needs of
applications, and their designs. As such, I don't really feel this
is as ad hoc as you say it is. Indeed it is a solution to one problem
(really a class of problems, but ok), but as just mentioned, that's
exactly the point. I mean, do you not want the ability to express
a solution to a class of problems/designs/etc??? I definitely do.
>> how a statically-checked language that intends to minimize runtime cost
>> could do better?
>
>Ok, let's look at what happens in Dylan.
>
>Dylan has only *one* kind of function -- the generic method -- but
>depending on the circumstances, the compiler will do any of:
>
>- compile time selection of the right function
> - inlining of the right function
> - outlining of the right function (using it as a template)
>- run time selection of the right function
>
>
>Let's look at an example:
>
>define inline method myAdd(a, b)
> a + b;
>end myAdd;
>
>define method f(x, y)
> myAdd(x, y);
>end f;
>
>define method g(x :: <integer>, y :: <integer>) => (z :: <integer>)
> myAdd(x, y);
>end g;
>
>define method h(x :: <single-float>, y :: <single-float>)
>=> (z :: <single-float>)
> myAdd(x, y);
>end h;
>
>
>Look at "myAdd". Unlike g and h, it doesn't declare the paramter types,
>or the return value type(s). What sort of function is it?
Hmm again. You were trying to say you should move on from C++ because
it has a number of ways to to allow your to compose functions.
Now you're showing Dylan does too. ????? Sounds like a mess too then.
>think of it either as a C++ template function with a and b declared to be
>of some unspecified type...
>
>template<class T> T myAdd(T a, T b){
> return a + b;
>}
>
>... but it's bit more than that. C++ templates require that the actual
>types of a and b be known at compile time. This C++ template requires
>that a and b be of the *same* type, which is also the type of the result.
>But with the Dylan function the arguments could be of different types,
>more like this:
>
>template<class T1, class T2> ???? myAdd(T1 a, T2 b){
> return a + b;
>}
>
>But this is not easy in C++.
It's not (assuming you're talking about the T1 and T2 as compared to
the first template)?? I don't understand this point.
>What is the function return type? T1? Not
>necessarily. T2? Not necessarily. Something else? But *what* else?
>It's impossible to say. Dylan doesn't care.
WhaWhaWhat? Ok, I can see some case where it doesn't matter, but I can also
see some cases where it does. If there is no way to address the latter,
they I would consider this a fundamental flaw.
>You could also think of myAdd as being like a C++ virtual function that is
>not actually part of a class, and that does runtime type dispatch based on
>the types of *both* arguments, not just the first one.
But that doesn't address the return type issue.
>Let's see what "d2c" (see <http://www.gwydiondylan.org>) does with this --
>here is the C code output by d2c (with my comments after //):
Nothing here seems compellingly different (than say C++).
>We can force the issue (and demonstrate the point) by adding the following
>functions:
>
>define method myAdd(a :: <integer>, b :: <integer>, #next super)
>=> (c :: <integer>)
> super();
>end myAdd;
>
>define method myAdd(a :: <single-float>, b :: <single-float>, #next super)
>=> (c :: <single-float>)
> super();
>end myAdd;
>
>This is essentially identical in purpose and effect to C++ explicit
>instantiation of template functions.
Again, you just seem to keep showning similarlties while calling
the C++ way a mess.
>"super()" is essentially the same idea as "super" in Java or SmallTalk or
>"inherited" in Object Pascal (or the unsucessful C++ "inherited::"
>proposal -- see section 13.6 in "The Design and Evolution of C++") --
>except that in Dylan it applies to any overloaded function, not just
>virtual functions.
So Dylan has overloaded function too. That same mess keeps peeking out! :)
>Unlike C++ template functions, these specialised functions are also useful
>when the types of a and b are NOT known in advance, but fortuitously turn
>out to be <integer> or <single-float> at run time. The specialised method
>will automatically be called, rather than the general one, which will
>result in not having to do virtual (generic) calls of arithmetic,
>comparisons etc inside the function, and it may result in more efficient
>calling (or even inlining) of any other functions called from within
>myAdd().
You're starting to loose me, but I think you're essentially saying it
would end up being the equivalent of a runtime instantiation of a
C++ template?
>I hope that I have demonstrated that a single simple mechanism in Dylan
>can sucessfully replace *all* the different kinds of functions in C++,
>with no loss of efficiency over C++.
The problem I'm having is that you attacks some aspects of C++ but
really have not shown how Dylan is not the same mess.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.development.apps
Subject: Re: Postgresql Success rate
Date: Wed, 30 Jun 1999 19:07:27 +0000
"Alexander F. Hartner" wrote:
>
> Has anybody experienced serious problems using Postgresql 6.4 with Java
> (JDBC) on a medium size network. Is Datacorruption a problem. From what I
> have experienced in the short time that I have been using Postgresql it is
> the best thing since sliced bread, but people seem unsure to use it.
>
> Thanks
> Alex
It is my understanding the 6.4 and 6.4.1 are buggy, but 6.4.2 is solid.
I am currently running 6.4.2
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 30 Jun 1999 15:46:34 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Chris Double <[EMAIL PROTECTED]> writes:
>Personally I'm in agreement with you Greg (I think) - the reason some
>C++ compilers produce bad code is exactly the same reason as why some
>C compilers produce bad code, and some lisp compilers produce bad
>code, and <insert favourite langauage> compilers produce bad
>code. That reason being someone made a mistake in the
>implementation. It is not because the language itself is the problem.
Frankly, I DO believe that the issue goes beyond a bug in the compiler,
or a not too savvy compiler writer, etc and that it DOES include the
languages itself. But it's not _just_ the latter, or _just_ one
of those things. Yet that's more or less the reckless way I've heard
this thread go so far (speaking out loud here, not particularly to you).
Most of the "BLAH is" statements being made are too strong and misleading.
Actually, an executive summary of many of my points in this thread
is that there are too any blanket statements being made and too many
biased comparisons being brought forth. As always, some of this is
because of the limitations of this medium, but others are not.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: Chris Double <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 01 Jul 1999 07:11:18 +1200
[EMAIL PROTECTED] (Greg Comeau) writes:
> This DOES NOT address Bruce's Q. Are you seriously going to
> defend Linus's skewed response to Bruce by showing that MSVC++
> actually has one sole isolated bug some mag reported on (ok that
> in C mode the compiler did not happen to have too)?
I didn't intend it to come across as any form of defence of anyone's
response. It was just an example of a compiler that produced bad code
when compiling C++ but good code in C mode which is what I thought
Bruce was asking about.
Personally I'm in agreement with you Greg (I think) - the reason some
C++ compilers produce bad code is exactly the same reason as why some
C compilers produce bad code, and some lisp compilers produce bad
code, and <insert favourite langauage> compilers produce bad
code. That reason being someone made a mistake in the
implementation. It is not because the language itself is the problem.
> OTOH, since we're just jesting: Do recall that MS products do not
> have bugs.
Of course ;-)
Chris.
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 30 Jun 1999 13:07:02 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (NF Stevens)
writes:
>[EMAIL PROTECTED] (Nathan Myers) wrote:
>
>>NF Stevens <[EMAIL PROTECTED]> wrote:
>>>[EMAIL PROTECTED] (Nathan Myers) wrote:
>>>
>>>>If you don't know C++ templates, you don't know C++ at all. It is
>>>>templates, for example, that make it possible to write a C++ library
>>>>that does matrix operations as efficiently as specially-optimizing
>>>>Fortran on machines specifically designed to run Fortran well. Unlike
>>>>Fortran, though, C++ templates are not tuned specificially for matrix
>>>>math, so can be used to accomplish similar wonders in any area.
>>>
>>>I have to disagree with this. Templates do not in any way improve
>>>the efficiency of generated code. They are no faster (and no
>>>slower) than the equivalent hand written code. Templates only
>>>improve the efficiency of the programmer since only one (templated)
>>>version has to be coded rather than individual versions for each
>>>template class.
>>
>>C++ cannot of course be faster than the equivalent assembly
>>code, but the C++ compiler can optimize code better than you
>>can by hand in C, because it knows more about expressions than
>>you can tell the C compiler.
>
>That was not the point. I was comparing the code generated
>by instanciation of a template with hand written C++ code.
>The fact that templates expand to C++ code means that
>_templates_ cannot improve the efficiency of code.
What you are saying is clearly understandable, so much so
that some would say that it is intuitively obvious.
Well, intuition is often wrong. What you've done is
to present a rather mechanical equivalence and then left
things at that. But templates are more than just that.
Templates create a distinct family of relationships.
This is not just a cognitive conceptual statement, but
one with physical implications too.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: Dave Erdmann <[EMAIL PROTECTED]>
Subject: Re: PTHREADS kernel/user level threading?
Date: Wed, 30 Jun 1999 20:02:16 GMT
Thanks to the people that responded. I now have a follow-up
question that I am hoping somebody can answer. :)
In article <[EMAIL PROTECTED]>,
Michael Hirsch <[EMAIL PROTECTED]> wrote:
> Dave Erdmann <[EMAIL PROTECTED]> writes:
>
> > I am wondering if the pthreads implementation on
> > Linux does any kernel level threading, or both
> > kernel and user level threading.
> >
> > For instance if I have a dual CPU system can my server
> > take advantage of both CPUs having two concurrent
> > threads in the same process running on both CPUs
> > at once?
>
> That is exactly what it does. As far as the kernel is concerned, each
> thread is a separate process.
>
Ok. Then given that each thread is a process as far as the kernel is
concerned what happens with locking calls such as semaphores.
If I want to a lock on a variable does this generate a context switch
through the kernel? Or does the process just try for the lock in user
space and if it succeeds...great...it keeps processing along, releases
the lock...
Context:
Here is what I am considering. Having a large amount of shared
data ...yes yes I know that threading works better with the least
amount of shared data. Each shared data entry is just a counter.
There will a low contention for the locks. 99.9% of the time
a process will get and release a lock without interfering with another
process. So I would have multiple threads chugging along using this
data.
Some of the threads have to be extremely quick and don't really want
to wait around for unneeded context switches.
-Dave
David Erdmann
mailto:[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Subject: Re: Can Linux Boot and Run without a BIOS?
Date: Wed, 30 Jun 1999 13:49:59 -0600
Jim Robertson wrote:
...
> However, I'm pretty sure that once Linux is running, it does not depend
> on the BIOS at all. Of course, the root file system must reside on a
> device whose driver is not in a module, but compiled into the kernel.
Nope, it can be a module, and for many people it is.
--
Bill Anderson Linux Administrator
MCS-Boise (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 30 Jun 1999 13:27:40 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Johan Kullstam <[EMAIL PROTECTED]>
writes:
>is `alloca' a valid `allocator'?
It's not a standard function if that's what you mean.
>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.
It's certainly an annoyance given you will get a diagnostic if you
let out a decl etc, but I don't see how you can say it is a
disadvantage in a large app. Certainly if I don't have static types
I would would a static analyzer program, to say the least.
>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.
Nobody said it was insignificant costs.
>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.
Every so often I wish for something like this,
I'm not sure how it fits into this conversation though.....
> (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)
You've lost me somewhat. Perhaps some Q's:
* Are you fmiliar with template partial specialization?
* How would you substitute another <? How you you use this for
classes (or whatever lisp has) for which < is not defined?
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 30 Jun 1999 14:19:59 -0400
Reply-To: [EMAIL PROTECTED]
In article <7l6a5b$ueh$[EMAIL PROTECTED]> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
>In comp.os.linux.networking Johan Kullstam <[EMAIL PROTECTED]> wrote:
>>> ... 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).
>
>sure, but if you have virtual functions, then those need a lookup. I think
>it is measured between 2-30%. This is True for Eiffel Compilers who generate
>C from Eiffel code, too.
>
>In theory there is no overhead if you dont use C++ Features, but then
>again.. it is not faster as C.
This thread continues to be ridiculously narrow-minded and biased.
Has it dawned on you that to use the equivalent of virtual functions
in C also requires a lookup? And that would also be measured 2-30%?
Sigh.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: Graffiti <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Wield system, X11 glibc2 or egcs1.1.2 broken?
Date: 30 Jun 1999 11:12:27 -0700
In article <[EMAIL PROTECTED]>,
y chen <[EMAIL PROTECTED]> wrote:
>So I installed egcs-1.1.2 and binutil 2.9, then glibc2.1.1
>At this point, my system goes very well. I recompiled
>kernel and it is stable.
I'll assume you're using x86, so...
Hopefully, you compiled a 2.2.x kernel, and not a 2.0.x
(which is known to have issued w/ gcc > 2.7.2.3 on the x86
platform, whether or not you apply that one tiny patch for
ioperm).
If you're using a 2.0.x kernel, compile that with 2.7.2.3.
You can use egcs for the rest of the stuff, but don't compile
2.0.x with egcs.
>Then I compiled X3331 and windowmaker0.60.0.
>
>Now, I can run windowmaker, but when I run a small piece
>of X program, it segment fault in xterm, but I can run it in
>gdb. ( this is very wield, isn't it?)
This sounds like you're playing with a NULL pointer somewhere.
Under some circumstances, gdb will fiddle w/ things so it
doesn't catch a NULL pointer dereference. Been a while since
I read about it, so you might want to try the newest version of
gdb out there and search the dejanews^H^H^H^H archive.
If you're running a 2.0.x kernel compiled w/ egcs, ignore the
above. Recompile w/ 2.7.2.3.
>Another wield thing is I compiled a small piece program
>doesn't require X and pthread. When I run it, It said libXext
>can not be found. Finally it found it(2), it seg fault.
Try: ldd a.out
And see if it lists libc5 and libc6 at the same time. If it
does, you need to replace the library that depends on libc5 w/
a libc6 version (and be careful, as you can nuke important
binaries if the libc it's using disappears from under it).
>So any advice will be highly apreciated. Which part of my
>system is broken, glibc2, libX or compiler egcs or ld?
>I can not figure it out.
>
>Some clues I think are useful:
>(1) gcc draw.cxx -lX11 doesn't work, I should
> gcc -L/usr/X11R6/lib -lXext -lX11 draw.cxx.
By default on most platforms, gcc usually looks only in
/usr/lib, maybe /lib.
>(2) I must put /usr/X11R6/lib in LD_LIBRARY_PATH
> otherwise, a.out won't run.
Then add it to your LD_LIBRARY_PATH or modify /etc/ld.so.conf
Or hard-code the path during link-time. The (looks at the
ld man page) -rpath and -rpath-link options are what you're
looking for.
-- DN
P.S. Don't compile 2.0.x with egcs!
------------------------------
** 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
******************************
