Linux-Development-Sys Digest #892, Volume #6 Sat, 26 Jun 99 18:14:15 EDT
Contents:
Re: You can now use Winmodems in Linux!!!!!!! (Zolee)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ ("Tom Leete")
Re: Why not C++ (Johan Kullstam)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Johan Kullstam)
Re: using C++ for linux device drivers (Nathan Myers)
Re: using C++ for linux device drivers (Johan Kullstam)
Re: Why not C++ (Don Waugaman)
Re: Why not C++ (Jeffrey L Straszheim)
Re: Why not C++ (John E. Davis)
Re: memcpy from mmap'ed buffers (Arun Sharma)
----------------------------------------------------------------------------
From: Zolee <[EMAIL PROTECTED]>
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: 26 Jun 1999 17:30:42 GMT
Billy Moon wrote:
>
> I am currently working on a application that enables winmodems to
function
> in Linux. Anyone who would like to help test this app please contact me.
>
>
>
Hi
One of my friend want's to use an MWAVE modem under SuSE 6.1
If your Program will be able to handle that, please send him an E-mail ant
send him your application, I am sure he would like to test it!
And please tell him what it does.
His address is: [EMAIL PROTECTED]
thanks and bye!
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 11:51:56 -0700
Greg Comeau <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
>>Ralph Glebe <[EMAIL PROTECTED]> wrote:
>>> Are all the programs in C because: [speculation]
>>
>>There are quite a lot of C++ projects on Linux. C projects (still)
>>outnumber them for several reasons. ...
>>
>>2. It takes substantial extra effort to code C++ libraries that are
>> binary-compatible from one release to the next, so library version
>> problems are incrementally harder.
>
>Luckily Standard C++ is out and at least for now binary compatible issues
>are known and can be addressed by compiler implementors as they upgrade.
>Of course, some compilers have done this more than others. :)
I did not mean releases of the compiler, or releases of the standard
library, both of which break binary-compatibility but will stabilize,
eventually.
I meant releases of other libraries. Any time you change the layout
of a struct, or (e.g.) add a new virtual function in a base class,
you risk breaking code that depends on the library. The same is true
with C libraries, but C lacks some of the language features that create
a dependency, and people already know about those which do.
It is possible to build C++ libraries that are safe for old program
binaries to link to, but it's harder. For example, you have to be
very careful about what inline functions and virtual functions you
expose in the public interface, and be sure not to change anything
between releases that those interfaces depend on.
This is a maturity issue. As people become aware of the problems,
they arrive at the same solution.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 12:02:38 -0700
Andi Kleen <[EMAIL PROTECTED]> wrote:
>Well, the theory is that:
> int f(vector<vector<float> > array)
>is easier than
> int f(float **array)
>to handle for a beginner.
No. The theory is that
vector<float> vec;
vector<vector<float > > array;
array.pushback(vec);
is easier for a beginner to handle than
int nelems;
float *vec;
float **newarray = realloc(array, ((nelems+1) * M) * sizeof(float));
if (!newarray) {
abort(); /* ? */
} else {
memcpy(&newarray[nelems][0], vec, M * sizeof(float));
array = newarray;
++nelems;
}
This theory is correct.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 10:50:07 -0700
Bruce Hoult <[EMAIL PROTECTED]> wrote:
> "Thomas Steffen" <[EMAIL PROTECTED]> wrote:
>> apart from that, C++ might not be a very elegant language, but it is
>> fast. at least compared to other OO languages. and still has about
>> every feature you can expect.
>
>You might want to check out Dylan. It's much simpler and easier to learn
>than C++, and yet is more powerful than C++ ...
> Plus Dylan is designed to be as fast as C++. ...
> Dylan is much better than C++ and Java.
Nonsense. If you think Dylan is as fast as C++, you really
don't know C++ at all, and should know better than to compare
the languages so glibly. Anyway, this is not a languages list.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 12:20:00 -0700
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.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: "Tom Leete" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 26 Jun 1999 02:21:38 -0400
John E. Davis wrote in message ...
>On Sat, 26 Jun 1999 11:53:08 +1200, Bruce Hoult <[EMAIL PROTECTED]>
>wrote:
>> some_function(&foo);
>>
>>What will be foo's value after the call to some_function? Will it be
>>altered? In C he has no way of knowing because C programmers often pass
>>structs by reference even when they don't intend to change them.
>
>At least the syntax indicates whether or not foo could be altered.
>The fact remains that one cannot look at
>
> some_function (x)
>
>in C++ and be sure that x was not modified, whereas in C you know that
>the local variable x will not be affected. And yes, like many people,
>I use an editor that supports tags. When reading C++ code, I do have
>to look up every such function to see whether or not something like x
>could be modified by the function. With C, knowing instantly that x
>could not be modified is a big help to understanding code fragments.
>
>--John
This is FUD. If your compiler really acts like that, get a new compiler. And
look to your headers.
In C & C++ both:
somefunction(&x);
somefunction has signature f(x_type *). If you hand somebody a pointer, they
can do anything to its target. The identical syntax applies in C++, with
identical results.
In C and C++ both:
somefunction(x_type x);
is like C, a local copy is passed on the stack and local changes dont leave
the scope.
In C++
somefunction(x_type & x);
this x is semantically like x_type, not x_type*. This is a C++ reference. C
doesn't have them. It refers to an object outside the function scope, and
can modify it. It is always an error to think it won't.
somefunction(const x_type & x);
here you have a guarantee that x will remain unchanged,both in scope and
out. This is used for passing heavyweight arguments on the stack, where a
pointer would be an invitation for somebody to free() it. x does not have to
be a const as far as the rest of the world is concerned.
somefunction(const x_type x);
is an optimization construct, the compiler will howl if x isn't defined as a
constant somewhere visible.
Addressing some other misconceptions that have been voiced in this thread:
There is no objection to using throws, but the kernel is written in C, dont
expect it to know what you mean. Catch all your throws and convert the
errors to POSIX. An uncaught throw will abort() and dump core. Whether this
oopses depends on how much kernel state you are messing with, just like in
C.
C doesnt know about destructors either, but that doesnt prevent you from
passing pointers to in-memory structures, you just need to define your
destructors correctly, so they dont delete a pointer the kernel will
eventually free. A C free() is perfectly all right as a standin for delete,
just get your arguments right. As always dont do it twice.
For C++ classes passed by value, C will unwind the stack just fine so long
as the class was put there using "C" linkage. When C uses them, call them
struct. It is a good idea to define a C struct to contain the stack layout,
and then use the struct as the lone data member in a class. Another approach
is to use one header to define your class, and wrap up the C++-isms in the
stock cpp switch.
C and C++ are both very good at binding to other, stranger, languages than
each other. Assertions to the contrary should not be given credence.
TML
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 26 Jun 1999 16:09:00 -0400
[EMAIL PROTECTED] (Nathan Myers) writes:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >Well, the theory is that:
> > int f(vector<vector<float> > array)
> >is easier than
> > int f(float **array)
> >to handle for a beginner.
(defun f (vec)
...)
is about as easy as it gets. put in declares if warrented by
profiling results.
> No. The theory is that
>
> vector<float> vec;
> vector<vector<float > > array;
> array.pushback(vec);
>
> is easier for a beginner to handle than
>
> int nelems;
> float *vec;
> float **newarray = realloc(array, ((nelems+1) * M) * sizeof(float));
> if (!newarray) {
> abort(); /* ? */
> } else {
> memcpy(&newarray[nelems][0], vec, M * sizeof(float));
> array = newarray;
> ++nelems;
> }
>
> This theory is correct.
>
> --
> Nathan Myers
> [EMAIL PROTECTED] http://www.cantrip.org/
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. -- and the my memory is fragmented into oblivion
after all these malloc/frees so now my performance is losing hard.
the memory fragmentation problem pretty much precludes seriously using
C++ for kernel work. look to microsoft for examples of C++ in action.
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?
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.
after using lisp's macros i don't know whether to laugh or cry when i
think of C++ templates.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 12:12:09 -0700
Tristan Wibberley <[EMAIL PROTECTED]> wrote:
>
>If I'm using a C library, my program might have to say:
> some_function( &x );
>so, when debugging, I know right there that I can't assume x won't be
>altered. The same thing in C++ would be:
> some_function( x );
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.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 26 Jun 1999 16:12:55 -0400
[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.
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.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 26 Jun 1999 12:06:41 -0700
Justin Vallon <[EMAIL PROTECTED]> wrote:
>void *::operator new(size_t s) { return kmalloc(s, GFP_KERNEL); }
>void ::operator delete(void *p) { kfree(p); }
>
>I think we are agreeing here. No?
No. This neglects error recovery. Also, the declaration of pointer
types above is not C++-like. In good C++ we use "void* p", not "void *p".
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
Subject: Re: using C++ for linux device drivers
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 26 Jun 1999 16:43:47 -0400
[EMAIL PROTECTED] (Nathan Myers) writes:
> Justin Vallon <[EMAIL PROTECTED]> wrote:
> >void *::operator new(size_t s) { return kmalloc(s, GFP_KERNEL); }
> >void ::operator delete(void *p) { kfree(p); }
> >
> >I think we are agreeing here. No?
>
> No. This neglects error recovery. Also, the declaration of pointer
> types above is not C++-like. In good C++ we use "void* p", not
> "void *p".
how do you declare more than one pointer thing on a line? like
double *xp, *yp;
or is that verboten in good C++?
imho
double* xp, *yp;
or
double* xp,* yp;
look pretty lousy.
logically it makes no sense to paste the star to the type either.
double *xp;
means that *xp is a double. xp is then forced to point so that * can
dereference it.
double*
doesn't make sense.
look at
double* xp, z;
one gets the idea that z is also a pointer but that would be wrong.
too bad
&double xp;
isn't allowed but it's at least consistent with the rest of the
language.
of all the things C++ has introduced, the star movement is the
silliest -- it adds nothing but gratuitous breakage of previous
convention and risk of confusion. since it's not required, i refuse
to use it.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 13:55:04 -0700
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.
>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.
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.
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?
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
I hate it when my foot falls asleep during the day cause that means
it's going to be up all night. -- Steven Wright
------------------------------
From: Jeffrey L Straszheim <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 26 Jun 1999 16:46:30 -0400
Nathan Myers wrote:
> Tristan Wibberley <[EMAIL PROTECTED]> wrote:
> >If I'm using a C library, my program might have to say:
> > some_function( &x );
> >so, when debugging, I know right there that I can't assume x won't be
> >altered. The same thing in C++ would be:
> > some_function( x );
> 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.
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 expect this is a C++ culture issue more so than a technical issue.
In Eiffel, for instance, one can write functions with side effects;
however, such is considered well outside of accpeted Eiffel practice.
And it turns out that I have yet to come accross any moderately serious
peice of Eiffel code which did not follow the idiom. The idiom is
presented as a central aspect of the language and the Eiffel community
has maintained it. C++ has not done so for the case of non-constant
reference function arguments.
-- Jeffrey Straszheim
-- Systems Engineer, Programmer
-- http://www.shadow.net/~stimuli
-- stimuli AT shadow DOT net
------------------------------
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:12:56 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 26 Jun 1999 02:21:38 -0400, Tom Leete <[EMAIL PROTECTED]>
wrote:
>This is FUD. If your compiler really acts like that, get a new compiler. And
You should probably re-read the message. If the compiler does *not*
behave the way I described, then I will get a new one. Just because I
criticized a particular C++ feature does not make me wrong, as you
apparantly have assumed.
--John
------------------------------
From: [EMAIL PROTECTED] (Arun Sharma)
Subject: Re: memcpy from mmap'ed buffers
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 Jun 1999 21:16:28 GMT
On Sat, 26 Jun 1999 00:43:10 -0400, Nitin Malik <[EMAIL PROTECTED]>
wrote:
> Why is this abnormal time for memcpy? Is it because of some special access
> checks to read the device buffers? But I thought all these checks will be
> avoided due to the mmap operation... so the memcpy shud be as though it
> were occuring in the user space... which takes 25 microsec per 1460 bytes.
>
> Someone please assist me in this problem...
>
(a) How are you measuring time ? rdtsc is a good way to do it on ix86.
(b) If you're seeing abnormal numbers, they could be attributed to:
(a) Cachability of the memory range in question.
(b) Page fault handling overhead - you may be doing a lot more
user->kernel transitions.
I'd suggest:
- varying the size of the buffers to see the variation in numbers
- watching the page fault stats in /proc/stat
- profile the kernel (man readprofile)
You may want to note that some of the kernel developers do not think that
these zero copy schemes are useful for any practical purpose, since in
any real world application, you will want to do something with the data
you received on the network - so it makes sense for the kernel to cache
a copy. Search the archives of linux-kernel for more.
-Arun
------------------------------
** 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
******************************
