Linux-Development-Sys Digest #913, Volume #6 Wed, 30 Jun 99 14:14:35 EDT
Contents:
Re: Why not C++ ([EMAIL PROTECTED])
Re: Why not C++ (Greg Comeau)
Re: [BUG] current->mm NULL in SMP version of 2.2.x (root)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Postgresql Success rate ("Alexander F. Hartner")
Microsoft equivilant classes (looking for) (Tom glass)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Wed, 30 Jun 1999 15:46:08 GMT
In article <7l6a5b$ueh$[EMAIL PROTECTED]>,
Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> 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
Not necessarily true. If you write a good optimizing C++ to C
translator you could include a code analyzer that may be smart enough to
put a direct call to the "pointed to" function rather than having to
call it through a pointer. It may also be able to inline the body of
the virtual function in some cases. Good native code C++ compilers
already do this -- C++ to C translators can too. Then the generated C
code can be compiled with an optimizing compiler for perhaps more
improvement.
> 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.
>
> Greetings
> Bernd
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
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 10:24:05 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Martin
Aupperle) writes:
>On 28 Jun 1999 17:05:17 -0400, [EMAIL PROTECTED] (Greg Comeau) wrote:
>
>>>
>>>C++ *is* slower than C.
>>
>>I suspect there is some knee-jerking going on here.
>>Certainly C++ is not always fast compared to anything.
>>But certainly saying it is always slower than C is not the case either.
>>
>I can equally well say: C++ is faster than C.
The fairer statement is not that it is but can be.
>* Code a function to concatenate two strings in C and C++.
>* Code some container like vector, list etc. in C by hand and compare
>its performance to the STL counterparts.
>
>Not only are the C++ versions much faster, the client code is easier
>to write, easier to read etc. AND everything is thoroughly tested. In
>your C-version, there might well be bugs in your string concatenation
>routine (Don't laugh: I saw a lot of C-like string concatenations
>that worked in the first place, but failed later during maintenance of
>the program).
I'm definitely not laughing.... I bet I've seen more of those kinds
of bugs, both initially and in maintained code, than you have. :(
IMO, this is the canonical example to use when teaching C programmers
moving to C++. There is a great example Robert Murray uses when he
teaches C++ that blows your socks off, especially since it's a real example.
He composes a UNIX file path name in C from its respective parts.
You're left crying.
- 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: root <[EMAIL PROTECTED]>
Subject: Re: [BUG] current->mm NULL in SMP version of 2.2.x
Date: 30 Jun 1999 17:07:32 GMT
Arun Sharma <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Jun 1999 14:35:29 GMT, Christopher Boyd <[EMAIL PROTECTED]> wrote:
>> this is a nonzero value and on SMP 2.2.x kernels, I get
>> a 'um_write: current->mm = 0x00000000'.
> Did you compile your module twice, once with -D__SMP__ and once without ?
> If you don't, the offsets within current could be wrong for a SMP
> kernel i.e. current->mm could be accessing the wrong field.
Err, you're right. With __SMP__ def'd, the offset is 1168, whilst
without it it's 920. This fixes it. Many thanks :-)
I am curious where the different offsetting occurs? task_struct
doesn't appear to be modified in linux/sched.h depending by a
conditional define, so it is not instantly obvious (to me).
> If current->mm was really null, your kernel will panic in no time
> - guaranteed!
Yes, I see. It would be kinda silly not to be able to access
the task's memory, wouldn't it :-)
> -Arun
Regards,
Christopher Boyd
------------------------------
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:31:52 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Johan Kullstam <[EMAIL PROTECTED]>
writes:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>> >the memory fragmentation problem pretty much precludes seriously using
>> >C++ for kernel work. look to microsoft for examples of C++ in action.
>
>> Nazis eat peanut butter. Therefore peanut butter is bad.
>
>thanks for trying godwin's law.
>
>> This supposed "memory fragmentation problem" is just more FUD.
>> Shame on you, Johan.
>
>no, this one really *is* *true*. if you malloc and free a lot of
>things of different sizes, then heap memory does get chopped up. there
>are little bits of free memory here and there. you cannot consolidate
>them. and when allocating you search around for these free holes.
>the typical C++ program does a lot of malloc and free. memory
>fragmentation does occur and it does cause performance loss.
Ok, let's try this again:
The LINUX kernel does memory allocation.
Therefore the LINUX kernel would be a typical C++ program.
Round 3? :)
- 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 13:49:35 -0400
Reply-To: [EMAIL PROTECTED]
In article <7l6h61$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Don Waugaman)
writes:
>In article <[EMAIL PROTECTED]>,
>Johan Kullstam <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Don Waugaman) writes:
>>
>>> In article <[EMAIL PROTECTED]>,
>>> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>>>
>>> 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.
>
>[ snip ]
>
>>and in C, mallocs tend to be rare. most C programs will malloc
>>everything they need right off the bat and keep hold of the memory
>>until they exit.
>
>I disagree with this generalization. I've seen numerous examples of
>C programs which will use malloc() / free() frequently during their
>execution.
>
>I would welcome correction if I am wrong. Has anyone seen any studies
>to either effect?
I've never seen any studies but would imagine that only the savviest of
C programmers would know about this.
>> however, C++ encourages more dynamic memory
>>exercising because its syntax hides the malloc/free somewhat.
>
>This *may* be true, but - again - this is a case of programmer choice.
>Nothing stops programmers from using the style that you describe for
>the C language. For many types of programs, less-powerful classes may
>be better than general classes which allocate consistently on the heap -
>thus a FixedSizeArray<> template may be preferable to using vector<> in
>some situations. However, when you need the additional power of the
>built-in classes, it's good to have them easily available.
This is a most excellent point.
In fact it's part of the beauty of C and C++ that other options
are available.
>>> >the memory fragmentation problem pretty much precludes seriously using
>>> >C++ for kernel work.
>>>
>>> I don't think that memory fragmentation is worse in C than in C++.
>>> It's true that some features of C++ can cause programmers to use
>>> dynamic memory more than in C. but that's an attribute of the use of
>>> the language, not of the language itself.
>>>
>>> What it means is that in areas where memory fragmentation is an issue,
>>> you'll have to be very careful about how you manage memory. This is
>>> an issue in C programs as well, of course. The difference is that you
>>> can use C++'s features to more easily move between different methods
>>> of memory and fragmentation management.
>>
>>in eg lisp you let your vendor take care of this for you.
>
>And your vendor may sometimes get it wrong. Will he guess correctly for
>every instance of a quick-and-dirty filter, an OS kernel, a daemon and
>a number-crunching application?
Yep, this BTQ, is exactly the problem with malloc and free.
Can you imagine that you are only presented with one implementation of it?
This ties in with, but does not necessarily replace, the various
levels of granularity allowed with C++'s 'new'.
>>C++ doesn't have insignificant runtime costs.
>
>Please name some of C++'s significant runtime costs (that we haven't
>already addressed above - namely, memory management issues).
I'm suspecting he said this as a reaction to all the comments that
C++ is efficient and so all he's saying is that some things do
have costs. If the OP means more than this, please chime in.
- 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: "Alexander F. Hartner" <[EMAIL PROTECTED]>
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.development.apps
Subject: Postgresql Success rate
Date: Wed, 30 Jun 1999 19:49:30 +0200
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
------------------------------
From: Tom glass <[EMAIL PROTECTED]>
Subject: Microsoft equivilant classes (looking for)
Date: Wed, 30 Jun 1999 11:42:49 -0600
I'm trying to convert code written in VC++ to my new Linux platform. In
VC I used some microsoft classes like CString and CPtrArray, which were
very handy. I'm thinking I can't be the only one who liked these
classes and I'm wondering if anyone has created equivilents for Linux.
Can anyone help?
Thanks
Tom
------------------------------
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:15:42 -0400
Reply-To: [EMAIL PROTECTED]
In article <QGtd3.4830$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Using the latest egcs (from CVS) to compile a C program, with options
>'-fno-exceptions -fno-rtti -O2', the C assembler output is still
>smaller (in terms of # of instructions, not symbol length) while
>producing the same results.
>
>C++ is still slower and bulkier.
I think that you know that you have not done a serious comparison here
and so any conclusion(s) you could possible make must be bogus.
- 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,comp.lang.c++
Subject: Re: Why not C++
Date: 30 Jun 1999 14:00:05 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Isaac) writes:
>On Mon, 28 Jun 1999 07:55:12 +0200, Thomas Stuefe
><[EMAIL PROTECTED]> wrote:
>>
>>>> In my opinion, the only thing that C++ has over C is
>>>>better support for data encapsulation via classes and, possibly,
>>>>exception handling.
>>
>>Only is good.
>>
>
>I think the argument that the syntactical differences aren't compelling
>is supportable, although I don't agree with it. But even after dismissing
>things like // comments, declaring variables at point of use, class names
>as types, etc.
(Assuming dismissing it was ok :| )
>I still find the following 5 things the most compelling
>reasons to use C++ over C (roughly in decreasing order of importance)
>
>1) Data Encapsulation
>2) Inheritance
>3) Polymorphism
>4) STL library
>5) Templates
These would probably be on most folks top 10.
- 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 ***
------------------------------
** 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
******************************
