LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 09-03-2008, 07:10 PM   #46
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 15

Rep: Reputation: 0

Quote:
Originally Posted by paulsm4 View Post
Again - I think most of what you're saying is absurd. At least the parts that aren't simply false...

IMHO .. PSM
Any particular point that you can refute? I thought not. Responding to you is like talking to a wall. And just as much of a waste of time. Go examine the machine code generated from a C and a C++ compiler for the same program. (You can read assembler, can't you? ;-)

BTW, I attended a talk given by Brian Kernighan in which he compared popular programming languages for clarity of expression. It was his opinion that C++ was the clear winner. (You do know who BK is, don't you? ;-)

I've gone back over your posts and have confirmed that they are totally information-free. Case closed.

Last edited by lmenten; 09-03-2008 at 07:52 PM. Reason: Clarification
 
Old 09-03-2008, 09:54 PM   #47
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
Quote:
Originally Posted by lmenten View Post
BTW, I attended a talk given by Brian Kernighan in which he compared popular programming languages for clarity of expression. It was his opinion that C++ was the clear winner. (You do know who BK is, don't you? ;-)
Was it a talk on kernel programming?
ta0kira
 
Old 09-13-2008, 04:57 AM   #48
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by lmenten View Post
C++ code is exactly the same size as the equivalent C code. If you would not otherwise use an object-oriented paradigm, you are free to use straight procedural code with exactly the same footprint but with the advantage of much more compile-time checking. Since the Linux kernel is huge and in a single shared memory space, more compile-time checking is badly needed. Microsoft's Singularity goes even further by requiring managed code throughout to achieve reliability in a monolithic kernel.

Apple's device driver framework (I/O Kit) uses inheritance and wrappers (C++) to achieve more reliable driver code with little or no run-time overhead. The key is an expressive language that enables more complete compile-time checking. In an OS, the most error-prone code are the device drivers. This is why NeXT and OS X have enhanced the reliability of kernel-resident device drivers through a Objective-C framework and C++-based framework, respectively.

C++ is the preeminent language for embedded systems programming and the most stable and secure OS kernels are written in C++. The Linux kernel is, unfortunately, not numbered among the most stable and secure kernels. C++ was designed to enable clearer expression of the programmer's intent while retaining the efficiency of assembler language and C. C++ does not rely upon libraries any more than C does and can leverage any APIs created for C. You must be thinking of Java ; )
I am not a C++ fan, but I agree with you.

Furthermore, C++ can automatically be translated into "C" - see, for example, llvm.org - also supported by Apple.

And, anyway, whenever possible, write a user-space driver.
 
Old 09-14-2008, 04:18 AM   #49
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Another thing on C++ - if classes with data members are used instead of plain variables, access to the said data members is through 'this', i.e. through yet another pointer - some performance degradation.

But that would be true for "C" too whenever a struct is allocated and access is through pointer.
 
Old 09-15-2008, 07:41 AM   #50
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 15

Rep: Reputation: 0
Quote:
Originally Posted by Sergei Steshenko View Post
Another thing on C++ - if classes with data members are used instead of plain variables, access to the said data members is through 'this', i.e. through yet another pointer - some performance degradation.

But that would be true for "C" too whenever a struct is allocated and access is through pointer.
I agree. In fact in C++ a struct is a simple kind of class and access to a data member in C++ class results in the same sequence of machine instructions as access to a data member in a C struct (as compiled by a C compiler.) Just as access to a member of a C struct will (often) require access through a pointer, access to a member of a C++ class will(often) require access through a pointer. (If the class is a stack variable, access will be through an offset just as for a struct.)

When programming in any language, one must be aware of the cost/complexity of the expressions, data structures, and algorithms one uses. I haven't met any kernel developer, programming in C or C++, who is unaware of issues of efficiency.

Thanks for the contributions, Sergei!
 
Old 09-15-2008, 02:00 PM   #51
schneidz
Senior Member
 
Registered: May 2005
Location: boston, usa
Distribution: fc-15/ fc-20-live-usb/ aix
Posts: 4,010

Rep: Reputation: 624Reputation: 624Reputation: 624Reputation: 624Reputation: 624Reputation: 624
^ i read your arguements; it contradicts my own limited study (posts # 12 13 22 24).

another argument that was made is like comparing a ferrari to a moving truck. both have a purpose that is far better than the other one.

Last edited by schneidz; 09-15-2008 at 02:01 PM.
 
Old 09-16-2008, 01:41 AM   #52
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by schneidz View Post
^ i read your arguements; it contradicts my own limited study (posts # 12 13 22 24).

another argument that was made is like comparing a ferrari to a moving truck. both have a purpose that is far better than the other one.
Regarding post #13 - wrong example.

If you are serious about embedded/kernel programming, first learn how to use compiler in a manner it does _not_ link standard runtime.

Your example in post #13 does not satisfy the above requirement because the example is a typical C/C++ main program _with_ standard runtime.

Benchmark a function without standard runtime and see its assembly code - that would be the correct study.
 
1 members found this post helpful.
Old 09-16-2008, 08:34 AM   #53
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 15

Rep: Reputation: 0
Quote:
Originally Posted by Sergei Steshenko View Post
Regarding post #13 - wrong example.

If you are serious about embedded/kernel programming, first learn how to use compiler in a manner it does _not_ link standard runtime.

Your example in post #13 does not satisfy the above requirement because the example is a typical C/C++ main program _with_ standard runtime.

Benchmark a function without standard runtime and see its assembly code - that would be the correct study.
I totally agree. 12 is an unsubstantiated remark, and 13, 22, and 24 are based on a bogus example and have been already well rebutted. As Sergei says, the generated assembler/machine code is a more objective way to compare the languages for efficiency.
 
Old 09-17-2008, 12:01 AM   #54
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
Quote:
Originally Posted by lmenten View Post
I totally agree. 12 is an unsubstantiated remark, and 13, 22, and 24 are based on a bogus example and have been already well rebutted. As Sergei says, the generated assembler/machine code is a more objective way to compare the languages for efficiency.
Only if such code is intended to run a CPU directly, i.e. maintain an idle loop, manage processes, handle interrupts, control hardware, map memory, etc. You can't make a user-space comparison valid for kernel-space no matter how you spin it, even if you write a mock kernel for a virtual machine to be run in user-space.
ta0kira
 
Old 09-18-2008, 04:43 PM   #55
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 15

Rep: Reputation: 0
Quote:
Originally Posted by ta0kira View Post
Only if such code is intended to run a CPU directly, i.e. maintain an idle loop, manage processes, handle interrupts, control hardware, map memory, etc. You can't make a user-space comparison valid for kernel-space no matter how you spin it, even if you write a mock kernel for a virtual machine to be run in user-space.
ta0kira
Once the C++ code is compiled it is essentially indistinguishable from the equivalent code compiled from C. Except that the C++ code will take better advantage of inline optimizations and elimination of redundant pointer validation and so will be faster than the C version.
 
Old 09-18-2008, 10:54 PM   #56
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
What I was really commenting on was the intention of the code. Both languages are better in some areas, so comparing code intended for user-space might be a disproportionate comparison. A better comparison would be a basic kernel written in C++ (C++ style) vs. one written in C. If you can't write a functioning kernel that's mostly C-less C++ then you'll just have a C++-enhanced C kernel.
ta0kira
 
Old 09-18-2008, 10:57 PM   #57
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by lmenten View Post
Once the C++ code is compiled it is essentially indistinguishable from the equivalent code compiled from C. Except that the C++ code will take better advantage of inline optimizations and elimination of redundant pointer validation and so will be faster than the C version.
I am not 100% sure, but I think that support of "inline" in a sense of really transforming the code tagged "inline" into inline code, is not mandatory.

I think it is not mandatory for both "C" and C++.

gcc/g++ in reality support "inline".
 
Old 09-18-2008, 11:06 PM   #58
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by ta0kira View Post
What I was really commenting on was the intention of the code. Both languages are better in some areas, so comparing code intended for user-space might be a disproportionate comparison. A better comparison would be a basic kernel written in C++ (C++ style) vs. one written in C. If you can't write a functioning kernel that's mostly C-less C++ then you'll just have a C++-enhanced C kernel.
ta0kira
You've entered a very grey area, since it's difficult to well define "style".

Typical C++ programs create class instances through "new" which is very similar to "malloc".

Neither "new" nor "malloc" memory allocation mechanism is suitable for kernel.

I think the point of using C++ in kernel is its template programming features, for example. I mean, C++ has both CPP and templates while "C" has only CPP.

But, as a Perl guy, I'd say C++ templates are far behind Perl in their features :-).
 
Old 09-21-2008, 09:37 AM   #59
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 15

Rep: Reputation: 0
Quote:
Originally Posted by Sergei Steshenko View Post
You've entered a very grey area, since it's difficult to well define "style".

Typical C++ programs create class instances through "new" which is very similar to "malloc".

Neither "new" nor "malloc" memory allocation mechanism is suitable for kernel.

I think the point of using C++ in kernel is its template programming features, for example. I mean, C++ has both CPP and templates while "C" has only CPP.

But, as a Perl guy, I'd say C++ templates are far behind Perl in their features :-).
When programming in the kernel one overrides the new operator to use kmalloc, kfree, or whatever the particular OS provides in the kernel environment. This is all done inline with no additional overhead.

Templates are a nice option but strong type checking, inheritance, polymorphism, references, and other fundamental features of C++ provide great advantages in creating highly reliable software.

There are a number of excellent features coming up supporting such concepts as generic programming. These won't appear in the GNU compilers until they have been adopted as part of the next C++ standard.

Perl has the advantages that the creators can play fast-and loose with the language definition and that the language is interpreted. Great for user-space, but not safe (in most current OS implementations) for kernel space.

My point about inlining is this: In C++ the language expresses modularity well and provides features (private, protected) in the language to express and enforce access restrictions. This is highly desirable in a very large, single address-space monolithic kernel like the Linux kernel. These language features work very well with inlining in supporting information hiding/protection without any loss of efficiency in the code.

For example, the only way to prevent access to private functions and data structures in C is to declare them (or pointers to them) "static" requiring that any functions needing to access these static functions or variables be present in the same C file. This foils modularity and adds the cost of a function call for access.

In contrast, C++ allows the developer to limit visibility/access while still providing total efficiency for access to the protected functions and data structures. Where C requires a function call for access to a protected data structure, C++ does not and is, consequently, very much much faster.
 
Old 09-21-2008, 10:57 AM   #60
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by lmenten View Post
...
Perl has the advantages that the creators can play fast-and loose with the language definition and that the language is interpreted. Great for user-space, but not safe (in most current OS implementations) for kernel space.
...

I think you missed my point regarding Perl.

I meant I use Perl to generate C/C++ code, i.e. I use it as a better than CPP/C++ templates engine.

And, FWIW, Perl is compiled into bytecode (as Java, Python, Ruby, but _not_ as sh, tcl), so it's not an interpreted language.
 
  


Reply

Tags
arm, c++, compile, fine, kernel, linux, modules


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Linux kernel development vwal_13 Programming 3 03-09-2005 02:27 AM
Linux Device Driver Development aslv Linux - Certification 0 09-27-2004 08:42 AM
Linux Kernel Development impact on Slackware carboncopy Slackware 5 07-28-2004 03:43 PM
Touch screen driver development for Linux peso Linux - Software 1 02-02-2004 12:15 PM
Lexmark Released A Linux Driver Development Kit FearPasion710 Linux - Software 0 09-09-2003 06:18 PM


All times are GMT -5. The time now is 03:07 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration