Linux-Development-Sys Digest #893, Volume #6 Sat, 26 Jun 99 22:14:00 EDT
Contents:
Re: Why not C++ (John E. Davis)
Re: Why not C++ (NF Stevens)
Re: gcc byte packing of inherited class data (BOIRIE Gregor CNAM 98-99)
Re: Why not C++ (Tristan Wibberley)
Re: You can now use Winmodems in Linux!!!!!!! (Sudip Sarbajna)
Re: TAO: the ultimate OS (Frank Sweetser)
Re: tcp port no.s vs. processes (Sudip Sarbajna)
Re: NT kernel guy playing with Linux (Peter Samuelson)
Re: Why not C++ (John E. Davis)
Re: NT kernel guy playing with Linux (Peter Samuelson)
ins_network.mk errors -lpeer (Matt)
Re: Why not C++ (Paul Jackson)
Re: Why not C++ (Peter Samuelson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 21:37:09 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 26 Jun 1999 16:46:30 -0400, Jeffrey L Straszheim <[EMAIL PROTECTED]>
wrote:
>Nathan Myers wrote:
>> False. The same thing in C++ would be the same thing, period.
>
>> It is possible to declare non-const reference arguments in C++,
>> but that doesn't mean one finds it unexpectedly, in good code.
Are you (Nathan) saying that you would never find a function like
int something_silly (int& y)
{
if (y < 0)
return -1;
y += 3;
return 0;
}
in good code? Perhaps a good C++ coder would use:
int something_silly (int *y)
{
if (*y < 0)
return -1;
*y += 3;
return 0;
}
which is how it is done in C.
>Ah, but one doesn't always have the luxury of working with good code.
>This is a wart on C++. Not a major wart, granted, and certainly one
>which is easily avoided by a healthy degree of idiom, but I've seen
>commercial libraries that modified reference variables.
I agree, but the above example shows that if `y' is a scalar variable,
e.g., an int, then
if (-1 == something_silly (y))
.
.
one cannot assume that the value of `y' cannot be changed, even in
good code that uses `const' in all the right places. Unless, of
course, one always uses the `C' form with pointers.
--John
------------------------------
From: [EMAIL PROTECTED] (NF Stevens)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 00:05:50 GMT
[EMAIL PROTECTED] (Nathan Myers) wrote:
[snip]
>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.
Norman
------------------------------
From: [EMAIL PROTECTED] (BOIRIE Gregor CNAM 98-99)
Subject: Re: gcc byte packing of inherited class data
Date: 26 Jun 1999 07:26:20 GMT
Nathan Myers ([EMAIL PROTECTED]) wrote:
: Erwin S. Andreasen <[EMAIL PROTECTED]> wrote:
: >On Tue, 22 Jun 1999 18:27:42 +0000, Bruce Edge <[EMAIL PROTECTED]> wrote:
: >>I can't get gcc to pack this data:
: >>
: >>class a { char c; };
: >>class b { long l; };
: >>class c : public a, public b {};
:
: Why should it? This is a _gross_ misuse of multiple inheritance.
:
: struct c { a m_a; b m_b; };
:
: is a much better starting point for this kind of work, if indeed
: it's wise to trust the compiler to do it (which I doubt).
:
: --
: Nathan Myers
: [EMAIL PROTECTED] http://www.cantrip.org/
:
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Fri, 25 Jun 1999 22:41:07 +0100
Reply-To: [EMAIL PROTECTED]
Johan Kullstam 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.
A compiler is *not* C++.
C++ can *easily* create faster code. *Any*thing you can do in C you can
do in C++ with identical syntax (or near identical in a few cases such
as where C++ requires an explicit class), which allows the programmer to
at least match the speed in any cases where it could help. Classes,
inheritance, templates and explicit references (which are *not*
alternate syntax for pointers except when calling a non-inlined
function) allow the programmer to provide alternate code for special
cases much simpler than in C and which the compiler can optimise easier.
Doing many of these things with C syntax can become so ugly and
difficult that it would be stupid to try to do it (for maintenance
reasons), and people *have* to use the C equivalent to virtual functions
(arrays of function pointers) where, in C++, the programmer has the
option of going non-virtual, or even inline.
For small programs, C's speed potential *may* be greater than C++'s -
for big ones, no-way.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: [EMAIL PROTECTED] (Sudip Sarbajna)
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: 26 Jun 1999 21:47:53 GMT
This is in reply to Billy Moon's post.
I am also looking for my PCI modem (so far I know they are all winmodems and
uses specific drivers to run under windows) to work under Linux (redhat).
So could you tell me whether your application is modem specific and if it is
then which are the ones supported by your app.
Wishing to hear from you soon.
Thanks
Sudip
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: TAO: the ultimate OS
Date: 26 Jun 1999 17:33:18 -0400
[EMAIL PROTECTED] (Christopher B. Browne) writes:
> On 26 Jun 1999 18:46:57 GMT, Paul Jackson <[EMAIL PROTECTED]> posted:
> >As someone who lives in ...
> >
> > that "niche" of people that prefer to spend their
> > nights redesigning the allocation of disk space
> > between Linux and WinTel.
> >
> >I can confirm what cbbrowne recommended: Partition Magic suits
> >me fine for resizing my NT/Win/Linux/DOS/Warp/... partitions.
>
> And here it is worth mentioning that the issue is *not* that there
> would be no value in there being a "free" alternative to Partition
> Magic; it is that there is not enough value (e.g. - the "niche" is
> small enough) to put it high on the "must-do" list.
last i heard, partition magic was developing the ext2 resizing code with
Ted T'so under the agreement that after a period of time (a year or two) it
would be released as a standalone linux app under the GPL.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet. So if it works, you should be doubly impressed.
(Linus Torvalds, announcing kernel 1.3.3 on the linux-kernel mailing list.)
------------------------------
From: [EMAIL PROTECTED] (Sudip Sarbajna)
Subject: Re: tcp port no.s vs. processes
Date: 26 Jun 1999 22:07:27 GMT
Hi
Does this command come in standard package?
I am not being able to find this command even as 'root' user.
My bash shell says 'command not found' when I type 'Isof' or, 'isof' etc. at
the command prompt.
Could you pls. help me out?
Thanks
Sudip
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: NT kernel guy playing with Linux
Date: 26 Jun 1999 18:39:03 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
> > > Rubini says there's a global semaphore that
> > > is grabbed every time a process enters the kernel.
[Arun Sharma <[EMAIL PROTECTED]>]
> Careful about the use of the word semaphore. On Linux, semaphore is a
> blocking, long term synchronization primitive.
Come on, you know that's pedantry. A spinlock *is* a type of
semaphore. It just isn't a `semaphore_t'.
I say this in the hope of sparing others the confusion I had about what
a spinlock is. (It looked a lot like what CS calls a semaphore, so why
don't they just call it a semaphore, and what's this semaphore_t...?)
Here's at least my take on the two types:
A spinlock is a semaphore used for very short critical sections; while
waiting for a spinlock to be released, the kernel sits on the CPU and
does nothing. A `semaphore_t' is a longer-term semaphore which has the
advantage that the kernel puts the needy process to sleep and goes and
does something else rather than busy-waiting.
However, you need to grab a spinlock for the purpose of grabbing a
semaphore_t, so for short critical sections a spinlock (even with the
potential of busy-waiting) is more efficient. Since the usual practice
is to make your critical sections as short as possible, the result is
that the kernel uses a lot more spinlocks than semaphore_t's.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 21:57:32 GMT
Reply-To: [EMAIL PROTECTED]
On 26 Jun 1999 11:10:23 -0700, Nathan Myers <[EMAIL PROTECTED]>
wrote:
>Classes are not a very powerful feature; you can emulate them pretty
>well in C. Exceptions are quite powerful, though of limited use.
You can emulate classes and inheritance but doing so requires ugly
preprocessor hacks that make the code less understandable. If you
know of another way, then please let me know.
>Far more powerful than either are templates.
I believe that these can also be emulated to a certain extent via the
preprocessor. But in all honesty, weren't C++ templates one of the
things to avoid when using g++ because of its buggy implementation? I
realise that egcs may have finally overcome this obstacle, but this
has only come about recently.
--
John E. Davis Center for Space Research/AXAF Science Center
617-258-8119 One Hampshire St., Building NE80-6019
http://space.mit.edu/~davis Cambridge, MA 02139-4307
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: NT kernel guy playing with Linux
Date: 26 Jun 1999 19:02:57 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Holden McGroin <[EMAIL PROTECTED]>]
> Semaphores still aren't good even if you use lots of them. Suppose
> you have two instances of the same process trying to run on smp.
> they would be using the same parts of the kernel and eventually
> hitting the same semaphores, thus hozing the smp benefit to them.
No, most semaphores in the kernel are for kernel-internal things like
manipulating page tables or process scheduling queues, stuff like that.
The ones you'll notice by running two processes of the same executable
(*not* two instances of the same process, mind) would mostly have to do
with I/O (filesystem code, networking code, etc). There *is* a known
lack of parallelism in Linux net and fs code, and that is being worked
on as we speak. Another major place of contention directly affecting
user space as you say would be in memory management, and it's a poor
implementation of malloc() that has to call sbrk() too often anyway.
> > The kernel knows only of tasks, and these can be processes or
> > threads , the only difference being that threads share the same
> > virtual address space. The kernel can create processes and it can
> > control the page table so you can do anything you could do
> > with threads.
> hmm. rather not be concerned with the page table.
Oh, you don't have to be, don't worry. Just use the pthread API.
> I get the impression that daemons are used alot to provide a
> controlled thread context to kernel drivers. ie, load daemon. daemon
> privately calls into it accompanying driver. driver blocks it on a
> queue. Then when driver needs to do real work at the request of other
> apps, driver can block other apps, wakeup its daemon thread and don't
> worry, be happy...
Actually daemons *are* used some, but not because of threading. The
real reason to use daemons is to do things that are easier to do in
user space than in kernel space. Writing kernel code is hard. There's
no easy way to run the code under a debugger. You can't link to
arbitrary libraries. (Especially libc. There's an *extremely* limited
subset of libc in the kernel.) You have to worry about kernel memory
use, since it is mostly non-pageable. So any major complexity that can
reasonably be pushed out to user space, often is.
In the case of `insmod' (which you allude to above), it is essentially
performing the functions of an object linker, resolving symbols and so
forth. As such it uses libbfd, the "binary file descriptor" library
from the GNU binutils, which knows all about object files and those
kinds of things. Doing this in kernel space -- without a libbfd --
would have involved a *lot* of wheel-reinvention.
> > There is a significant overhead to fine grain kernel locking and
> > this is most noticed on single processor systems. In the past the
> > Linux kernel was optimised for single processor systems and
> > currently and in the future it is being given better SMP support so
> > it is capable of running well on single and multiple processor
> > environments.
> understood. thanx
Actually the overhead goes away if you don't compile for SMP. The
locking primitives get defined to no-ops by the C preprocessor. So the
real overhead is in kernel complexity. But yes, Linux SMP is still
something of a work-in-progress. As I said, the global filesystem lock
is going away soon and the TCP/IP stack locking (made famous by
Mindcraft III) has already been refined somewhat in the 2.3.x kernel
series.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
Date: Sun, 27 Jun 1999 01:49:03 +0100
From: Matt <[EMAIL PROTECTED]>
Subject: ins_network.mk errors -lpeer
Crossposted-To:
comp.oracle.databases.server,comp.oracle.databases.misc,comp.oracle.databases.tools,comp.os.linux.development.apps
Hi,
I have been having problems with the TCP listener on oracle 8.0.5
I have found a possible answer and that was to relink the network
and listener.
cd $ORACLE_HOME/network/lib
make -f ins_network.mk install
However I then get the error
usr/i486-linux/bin/ld: cannot open -lpeer: No such file or directory
make: *** [tnslsnr] Error 1
where is -lpeer and what should I do to correct this please
any ideas ?
Many thanks
Matt
========================================================================================================
chmod 755 /usr/local/oracle/bin
/usr/local/oracle/bin/echodo `if /usr/local/oracle/bin/get_platform |
grep "SOL" > /dev/null ; then echo "ld -dy
/usr/local/oracle/lib/SC4.2/crti.o /usr/local/oracle/lib/SC4.2/crt1.o
/usr/local/oracle/lib/SC4.2/crtn.o" ; else echo "cc" ; fi`
-L/usr/local/oracle/lib/ -L/usr/local/oracle/rdbms/lib
-L/usr/local/oracle/network/lib -o tnslsnr
/usr/local/oracle/network/lib/s0nsgl.o
/usr/local/oracle/network/lib/snsglp.o
/usr/local/oracle/network/lib/nsglpnp.o \
/usr/local/oracle/rdbms/lib/kpudfo.o /usr/local/oracle/lib/scorept.o
/usr/local/oracle/rdbms/lib/ssdbaed.o /usr/local/oracle/lib/nautab.o
/usr/local/oracle/lib/naeet.o /usr/local/oracle/lib/naect.o
/usr/local/oracle/lib/naedhs.o `cat /usr/local/oracle/lib/naldflgs`
-lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient
-lvsn -lcommon -lgeneric -lmm -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4
-lnlsrtl3 -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork
-lclient -lvsn -lcommon -lgeneric -lepc -lnlsrtl3 -lcore4 -lnlsrtl3
-lcore4 -lnlsrtl3 -lclient -lvsn -lcommon -lgeneric -lnlsrtl3 -lcore4
-lnlsrtl3 -lcore4 -lnlsrtl3 `cat /usr/local/oracle/lib/sysliblist`
-lm -lnetv2 -lnncc -lnetv2 -lnetwork -lnsgl -lnsglc -lnmd -lnms -lnfp
-lnmsp -lpeer -lncr -lnetwork -lepc -lnetv2 -lnncc -lnsgl -lnsglc
-lnmd -lnms -lnfp -lnmsp -lnetwork -L/usr/lib `if
/usr/local/oracle/bin/get_platform | grep "DG" > /dev/null ; then echo
'-ldl ' ; elif /usr/local/oracle/bin/get_platform | grep "SOL" >
/dev/null ; then echo '-ldl -lc' ; else echo '-ldbt -lx -ldl -lc' ; fi`
-lpeer
cc -L/usr/local/oracle/lib/ -L/usr/local/oracle/rdbms/lib
-L/usr/local/oracle/network/lib -o tnslsnr
/usr/local/oracle/network/lib/s0nsgl.o
/usr/local/oracle/network/lib/snsglp.o
/usr/local/oracle/network/lib/nsglpnp.o
/usr/local/oracle/rdbms/lib/kpudfo.o /usr/local/oracle/lib/scorept.o
/usr/local/oracle/rdbms/lib/ssdbaed.o /usr/local/oracle/lib/nautab.o
/usr/local/oracle/lib/naeet.o /usr/local/oracle/lib/naect.o
/usr/local/oracle/lib/naedhs.o -lnetv2 -lnttcp -lnetwork -lncr -lnetv2
-lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lmm -lnlsrtl3
-lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnetv2 -lnttcp -lnetwork -lncr
-lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lepc
-lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lclient -lvsn -lcommon
-lgeneric -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lm -lnetv2
-lnncc -lnetv2 -lnetwork -lnsgl -lnsglc -lnmd -lnms -lnfp -lnmsp -lpeer
-lncr -lnetwork -lepc -lnetv2 -lnncc -lnsgl -lnsglc -lnmd -lnms -lnfp
-lnmsp -lnetwork -L/usr/lib -ldbt -lx -ldl -lc -lpeer
/usr/i486-linux/bin/ld: cannot open -lpeer: No such file or directory
make: *** [tnslsnr] Error 1
------------------------------
From: [EMAIL PROTECTED] (Paul Jackson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 01:50:56 GMT
Nathan Myers wrote:
|> it's slower than (e.g.) C are just spreading FUD.
well, yes and no. Narrowly speaking, yes, give or
take secondary points, such as:
- it gives you more ways to speed things up
- exception handling can impact the calls a little
- the tighter types can help the optimizer a little
- templates and STL can really help some apps
but in some broader sense, there is an increased
risk with C++, as compared to C, that someone not
sufficiently skilled in the art will end up with
slower code, not realizing that the extra features
they are using do have a cost (virtual calls, lots
of nickle and dime mallocs, ...)
Then again, C has an increased risk, compared with
C++, that someone will end up with a slower app
because the lack of explicit support for certain
patterns and techniques led them to doing something
in some inappropriate homebrew fashion.
But my primary point here is that C++ is complex,
like a Boeing 747 cockpit. I've seen some large
scale project pain, when developers tried too hard
to use all that nice new "object oriented" stuff
that was suppost to make life wonderful. The pain
certainly included "too slow", though a bigger
problem was "difficult to maintain and adapt".
Put it this way -- if I could actually try ten
different teams of professional but not superstar
programmers, using different languages to implement
a real world (multi-year, requirements changing
for the life of the project, ...) app, right
now I'd bet that Python team (a delightful language
that I just learning) would produce the fastest
working app (because they'd have time to get the
architecture and algorithms 'right'), and the C++
team would produce one of the slower apps, with
a few key loops going fast, but bogged down in a
slew of other confusions.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson ([EMAIL PROTECTED]; [EMAIL PROTECTED]) 3x1373 http://sam.engr.sgi.com/pj
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 20:52:09 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Ralph Glebe <[EMAIL PROTECTED]>]
> I remember one of my first linux projects written in C on a Red Hat
> 5.2 system. I attempted to demo the program on a Red Hat 4.x system.
> It didn't run. Somewhat embarrasing.
Ah, yes, the migration from libc5 to libc6. Considering the *major*
(no pun intended) differences between libc5 and libc6, it's not
surprising that they aren't even *close* to binary-compatible.
Going the other way is much less painful. Most libc6 systems
(including Red Hat 5 & 6) also have libc5 on them, so a Red Hat 4.x
program will run fine. For obvious reasons, the converse is not true.
> Anyway, the egcs. I take it that this is automatically invoked when
> I enter g++. Or do I have to do something special to link egcs to
> the g++ command?
Depends on your distribution. It sounds like you're a Red Hat person,
and I am not, so I don't know. If you want to check, you can just run
`g++ -version'.
Recent Debian releases have made egcs the default `g++', and in the
next release (potato) it will also get to be `gcc'. (The latter was
not reasonable in previous Debian releases due to the use of 2.0.x
kernels.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** 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
******************************
