What if?

What if?

[Shannon Lavenia]

Hi,

I hope you had a great weekend. John and I
spent the time playing with our daughter...
hard to believe she's 6 months old already.

Watching her grow made me realize that
time really does go by fast.

It's almost Easter already and a quarter
of the year has just flown by.

Which made me think: Will 2011 be
"just another year", or will it be
EXTRAORDINARY.

This year is turning out fantastic for us and
I sincerely hope it is for you too. We're taking
every step possible towards our goal:

"To help 100 people achieve their financial
and personal goals".

We made a decision a few months ago
to really focus on helping more people
achieve success...to help people
realize the freedom that we enjoy
working for ourselves.

We're doing it with http://www.UprofitPro.com

I mean, let's face it, with all the
fear mongering going on in the news
right now, it's easy for you and I to think
that it's hopeless.

But, it really isn't. Yes, there is a huge
transfer of wealth happening right now.
That doesn't mean you have to lay down
and be on the wrong side of the transfer.

You CAN win and win BIG right now
just by knowing a few key steps to take
that will make a HUGE difference.

We started UprofitPro to give you
access to:

1. Success coaching from 7 figure
earners and our exclusive alliance
of mentors including The Home Business
Diva Robin Firestone, Michael Hamburger -
Executive Vice President of Marketing at
WMI, Neal Peterson - World Renowned
Motivational Speaker and more.

That means you'll get motivated and
inspired whether you want to be or not...
on a daily basis.

Keeping your energy up is key to
success.

2. A very simple, yet powerful, way to
generate an on-going residual income
stream without ever mentioning it to
your friends, family or neighbors.

We actually do most of the marketing
for you...it's that simple.

3. And, if you're already building
a home based business, a way to
generate the highest quality, highest
converting leads known to man.

I know that sounds a bit "hypey", but
it's true. We'll show you how to get the
same quality of leads that top marketers
get and how to make money generating
leads instead of paying for them.

How serious are we about helping people?

John and I usually charge upwards of $500.00
for a 45 minute session of coaching.

Seriously.

But, we're giving you full access to the
UprofitPro coaching and wealth building
system for only $1.00.

You have nothing to lose and everything
to gain.

If, after a week you say "not for me", we'll
give you your buck back and wish you all the
best.

But, we know you won't. Noone has yet. Because
everything we've got in store for you will simply
blow you away.

So, give yourself a great boost today
and a huge step towards running first through
that ribbon at the finish line by joining us
at http://www.uprofitpro.com.

You'll be grateful you did.

With you in success!
Shannon Lavenia
Co-founder, Uprofitpro.com
+1(323) 834-9274

PS: If you have any questions, feel free to
give us ring. You'll get instant access to
all the member resources, training and coaching
videos.

What if?

[Imanpreet Singh Arora]

Hi All,
   
    Firstly I have read the FAQ. So though FAQ answers my question, it 
does so only partially.


    "What if Linux were to be implemented in C++?"


    I realize most of the unhappiness lies with C++ compilers being 
slow. Also the fact that a lot of Hackers around here are a lot more 
familiar with C, rather than C++. However other than that what are the  
_implementation_  issues that you hackers might need to consider if it 
were to be implemented in C++. My question is regarding how will kernel 
deal with C++ doing too much behind the back, Calling constructors, 
templates exceptions and other. What are the possible issues of such an 
approach while writing device drivers?  What sort of modifications do 
you reckon might be needed if such a move were to be made?




-- 
Imanpreet Singh Arora

Even if you are on the right track you are going to get runover if you just sit there.
	-- Will Rogers

Re: What if?

[Theodore Ts'o]

On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> 
>    I realize most of the unhappiness lies with C++ compilers being 
> slow. Also the fact that a lot of Hackers around here are a lot more 
> familiar with C, rather than C++. However other than that what are the  
> _implementation_  issues that you hackers might need to consider if it 
> were to be implemented in C++. 

The suckitude of C++ compilers is only part of the issues.

> My question is regarding how will kernel 
> deal with C++ doing too much behind the back, Calling constructors, 
> templates exceptions and other. What are the possible issues of such an 
> approach while writing device drivers?  What sort of modifications do 
> you reckon might be needed if such a move were to be made?

The way the kernel will deal with C++ language being a complete
disaster (where something as simple as "a = b + c + d +e" could
involve a dozen or more memory allocations, implicit type conversions,
and overloaded operators) is to not use it.  Think about the words of
wisdom from the movie Wargames: "The only way to win is not to play
the game".

					- Ted

Re: What if?

[Norbert van Nobelen]

On Thursday 02 December 2004 05:40, Theodore Ts'o wrote:
> On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> >    I realize most of the unhappiness lies with C++ compilers being
> > slow. Also the fact that a lot of Hackers around here are a lot more
> > familiar with C, rather than C++. However other than that what are the
> > _implementation_  issues that you hackers might need to consider if it
> > were to be implemented in C++.
>
> The suckitude of C++ compilers is only part of the issues.
>
> > My question is regarding how will kernel
> > deal with C++ doing too much behind the back, Calling constructors,
> > templates exceptions and other. What are the possible issues of such an
> > approach while writing device drivers?  What sort of modifications do
> > you reckon might be needed if such a move were to be made?
>
> The way the kernel will deal with C++ language being a complete
> disaster (where something as simple as "a = b + c + d +e" could
> involve a dozen or more memory allocations, implicit type conversions,
> and overloaded operators) is to not use it.  Think about the words of
> wisdom from the movie Wargames: "The only way to win is not to play
> the game".

Let us do it all in assembler. Real optimization for every CPU.

BTW, that sparks a question: 
Did anybody already do a benchmark to see what happens if you address an AMD 
cpu not with x86 instructions but with it's native code, so to circumvent the 
internal translation in the CPU?


>
> 					- Ted
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: What if?

[James Bruce]

Theodore Ts'o wrote:

>The way the kernel will deal with C++ language being a complete
>disaster (where something as simple as "a = b + c + d +e" could
>involve a dozen or more memory allocations, implicit type conversions,
>and overloaded operators) is to not use it.  Think about the words of
>wisdom from the movie Wargames: "The only way to win is not to play
>the game".
>

I think this oft-repeated argument is a strawman, since C++ and C are 
identical on primitive types, and for non-primitive types, C can't use 
operators anyway.  So translating some C++ thing like your example where 
[a,...,e] are all "struct foo", we would have a C function called 
"bar(a,b,c,d,e)".  Well, guess what, without looking at its definition, 
it could be doing all sorts of things too.  In C++ you look at the 
struct definition and the C++ standard, in C you look at the function.  
How is that so different?  In C, functions are arbitrary but operators 
are not.  In C++, both are arbitrary.  Considering that Linux wraps 
almost everything into function calls, there would be little difference 
in the end.

That's not to say I think C++ is a good idea for the kernel; It isn't.  
C++ is more complex in the sense it requires more analysis to figure out 
what the CPU is really doing, thus it does entail a higher cost.  It's 
not that bad for an expert, and in a large part it depends on how many 
of the advanced features you use; Don't use them and your code is 
practically the same as in C.  So it really boils down to what you 
*gain* compared to that extra analysis cost.  For a kernel, there is 
really not much gain.  "Some cost vs. little gain" implies "not worthwhile".

For example, filesystems would probably be more cleanly implemented as 
classes with virtual functions, but as the kernel code shows, with a 
little extra effort you can achieve the same thing with structs of 
function pointers in plain C.  Extra effort is easy to come by when you 
have thousands of contributors, so there's no real difference.  The case 
is similar with many other C++ features.

The C language was developed for writing the original Unix kernel and 
utilities, and not suprisingly it has all the features you need for 
that.  C++ was developed for improved development of user applications, 
mostly through more effective reuse of code.  So again, not suprisingly, 
applications are what it is best at.  Let's also try not to mix up "use 
the right tool for the right job" with "use the best tool for my normal 
job for all problems".  Many people who espouse one language above all 
others need to look outside of their own usual problem area.

 - Jim Bruce

Re: What if?

[Theodore Ts'o]

On Thu, Dec 02, 2004 at 03:24:32AM -0500, James Bruce wrote:
> 
> I think this oft-repeated argument is a strawman, since C++ and C are 
> identical on primitive types, and for non-primitive types, C can't use 
> operators anyway.

While that may be true, the problem is that you don't know off the top
of your head whether something like:

	a = b + c + d + e;

involves primitive types or not just by inspection.  So it could be
something that takes no time at all, or a monstrosity which takes a
dozen or more memory allocations, and where it requires a Ph.D. in
understanding obfuscated code to figure out which overloaded operators
and which type coercions had actually taken place.  And remember, this
is a language where you can even override the comma (',') operator.
You think you know what a piece of code will do just by looking at it?
Think again!

This is perhaps one of the reasons why no one has bothered to make a
C++ analogue of the Obfuscated C Programming Contest.  There simply is
no challenge involved.  I have seen propietary codebases written in
C++, where said codebase was the crown jewel of the company, and while
the original C code was understandable, when it was re-written in C++,
it was completely unmaintainable and impossible to understand what was
going on.  I was reduced to placing printf's all over the place just
to figure out the flow of control.  

(Out of respect to the company involved, I won't name names, but it
was a filesystem-related product, and I was adding ext2 support to the
codebase at the time.  While on paper it may have made sense to use
C++ classes to represent different filesystem drivers, the
implementation was a complete and mitigated disaster, IMHO.  And this
is not the only C++ project I have seen where it would have been much
easier to understand the darned thing if it had been written in C
instead.)

On Thu, Dec 02, 2004 at 08:33:44AM +0000, J.A. Magallon wrote:
> Don't ge silly. I have written C++ code to deal with SSE operations
> on vectors, and there you really need to control the assembler produced,
> and with the correct const and & on correct places the code is as
> efficient as C. Or more. You can control everything.....
>
> It is as all things, you need to know it deeply to use it well.
> There are a ton of myths around C++.

If you know how to use a table saw deeply and well, you can use it
safely even with all of the safeties disabled and the blade guard
removed.  There are even a few cases where you have to do this.
However, I wouldn't recommend it for most people since it is far too
likely they will lose a finger or a hand....

That's the problem with C++; it is far too easy to misuse.  And with a
project as big as the Linux Kernel, and with as many contributors as
the Linux Kernel, at the end of the day, it's all about damage
control.  If we depend on peer review to understand whether or not a
patch is busted, it is rather important that something as simple as 

	a = b + c;

does what we think it does, and not something else because someone has
overloaded the '+' operator.  Or God help us, as I have mentioned
earlier, the comma operator.

> In short, with C++ you can generate code as efficient as C or asm.
> You just have to know how.

You can juggle running chain saws if you know how, too.  But I think I
would rather leave that to the Flying Karamazov Brothers.

							- Ted

RE: What if?

[David Schwartz]

> While that may be true, the problem is that you don't know off the top
> of your head whether something like:
>
> 	a = b + c + d + e;
>
> involves primitive types or not just by inspection.  So it could be
> something that takes no time at all, or a monstrosity which takes a
> dozen or more memory allocations, and where it requires a Ph.D. in
> understanding obfuscated code to figure out which overloaded operators
> and which type coercions had actually taken place.  And remember, this
> is a language where you can even override the comma (',') operator.
> You think you know what a piece of code will do just by looking at it?
> Think again!

	You can write bad code in any language.

> That's the problem with C++; it is far too easy to misuse.  And with a
> project as big as the Linux Kernel, and with as many contributors as
> the Linux Kernel, at the end of the day, it's all about damage
> control.  If we depend on peer review to understand whether or not a
> patch is busted, it is rather important that something as simple as
>
> 	a = b + c;
>
> does what we think it does, and not something else because someone has
> overloaded the '+' operator.  Or God help us, as I have mentioned
> earlier, the comma operator.

	The UNIX way is to allow people to shoot themselves in the foot.
Overloading the comma operator is shooting yourself in the foot. If being
allowed to overload it is bad, then being allowed to do anything harmful is
bad.

> > In short, with C++ you can generate code as efficient as C or asm.
> > You just have to know how.
>
> You can juggle running chain saws if you know how, too.  But I think I
> would rather leave that to the Flying Karamazov Brothers.

	I know all the reasons why writing a kernel in C++ is bad, and I largely
agree with them. However, this argument I don't find convincing.

	The part of it that's correct is just this: with C++, it can be harder to
tell exactly what a line of code does under the hood. For user-space code,
the vast majority of the time, that's great, it saves you from having to do
a whole lot of work. However, for kernel code, the vast majority of the
time, you must understand exactly what's going on under the hood.

	DS

Re: What if?

[J.A. Magallon]

On 2004.12.02, Theodore Ts'o wrote:
> On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> > 
> >    I realize most of the unhappiness lies with C++ compilers being 
> > slow. Also the fact that a lot of Hackers around here are a lot more 
> > familiar with C, rather than C++. However other than that what are the  
> > _implementation_  issues that you hackers might need to consider if it 
> > were to be implemented in C++. 
> 
> The suckitude of C++ compilers is only part of the issues.
> 
> > My question is regarding how will kernel 
> > deal with C++ doing too much behind the back, Calling constructors, 
> > templates exceptions and other. What are the possible issues of such an 
> > approach while writing device drivers?  What sort of modifications do 
> > you reckon might be needed if such a move were to be made?
> 
> The way the kernel will deal with C++ language being a complete
> disaster (where something as simple as "a = b + c + d +e" could
> involve a dozen or more memory allocations, implicit type conversions,
> and overloaded operators) is to not use it.  Think about the words of
> wisdom from the movie Wargames: "The only way to win is not to play
> the game".
> 

Don't ge silly. I have written C++ code to deal with SSE operations
on vectors, and there you really need to control the assembler produced,
and with the correct const and & on correct places the code is as
efficient as C. Or more. You can control everything. No more temporal
objects, no more copies, but still the type checking. I can send you,
for example, the code for a Vector class (no __asm in it),
and the assembler that g++ spits for a thing like a = b+c.
You would do not better in handcoded asm.

It is as all things, you need to know it deeply to use it well.
There are a ton of myths around C++.

For the kernel, you don't need exceptions nor iostreams, so don't use
the C++ runtime library.

Constructor/destuctor is needed, and also virtual single inheritance.
And those two things are already being done by hand with function
pointers inside structs in the kernel. The cost of (single and multiple)
inheritance in C++ is also just an indexed jump, the difference is that
in the pseudo object oriented things done in the kernel you have to
always initializa the funtions pointers, and C++ will do it for you.
How many bugs have you seen because somebody wrote a bad
.method = the wrong_func in an initializer ?

The kernel is full of things like
if (__builtin_constant_pointer(xxxx) and others to check if an argument
is constant and optimize some path, and in C++ you could write
class T {
	T& f();
	const T& f() const;
}
and the compiler will do it at compile time also.

In short, with C++ you can generate code as efficient as C or asm.
You just have to know how.

But C++ is not supported in the kernel. I can live with it.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-rc2-jam4 (gcc 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #2

Re: What if?

[Bernd Petrovitsch]

On Thu, 2004-12-02 at 08:33 +0000, J.A. Magallon wrote:
[...]
> Constructor/destuctor is needed, and also virtual single inheritance.
> And those two things are already being done by hand with function
> pointers inside structs in the kernel. The cost of (single and multiple)
> inheritance in C++ is also just an indexed jump, the difference is that
> in the pseudo object oriented things done in the kernel you have to

If software is object-oriented is a question of design, not the
implementation language. So it is neither necessary nor sufficient to
use a (so called) "object-oriented language" to get (or not get)
OO-software.

> always initializa the funtions pointers, and C++ will do it for you.
> How many bugs have you seen because somebody wrote a bad
> .method = the wrong_func in an initializer ?

You like putting the "read" function into the place of the "open"
function in a struct file_operations?
If you name your functions meaningful, you probably see it at the time
you write the code.
And if you do not see it during coding, you probably will see it on the
very first test run.
So the effect is at most moving initialization code and logic from a
the .c in a .h file?!

The unanswered question is: What does it actually buy?

Exceptions, STL, and most of the fancy features are not usable and must
be thrown out (you even have to forbid them and look after it).
The holds - more or less - for operator overloading (except in very few
cases).
So the usual C++-(and OO-) marketing propaganda does not help since most
features (including all standard run-time libs) are either not usable or
forbidden.
Yes, you get probably stricter type checking - most of this is in C also
doable.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: What if?

[Pawel Sikora]

On Thu, 2 Dec 2004, Bernd Petrovitsch wrote:

> Exceptions, STL, and most of the fancy features are not usable and must
> be thrown out (you even have to forbid them and look after it).
> The holds - more or less - for operator overloading (except in very few
> cases).
> So the usual C++-(and OO-) marketing propaganda does not help since most
> features (including all standard run-time libs) are either not usable or
> forbidden.
> Yes, you get probably stricter type checking - most of this is in C also
> doable.

The first step was done.

http://netlab.ru.is/exception/KernelExceptions.pdf
http://netlab.ru.is/exception/LinuxCXX.shtml

Re: What if?

[H. Peter Anvin]

Followup to:  <1101984361.28965.10.camel@tara.firmix.at>
By author:    Bernd Petrovitsch <bernd@firmix.at>
In newsgroup: linux.dev.kernel
> 
> The unanswered question is: What does it actually buy?
> 

Type-safe linkage, mainly.  That actually would be a nice thing.

	-hpa

Re: What if?

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]


On 2004.12.13, H. Peter Anvin wrote:
> Followup to:  <1101984361.28965.10.camel@tara.firmix.at>
> By author:    Bernd Petrovitsch <bernd@firmix.at>
> In newsgroup: linux.dev.kernel
> > 
> > The unanswered question is: What does it actually buy?
> > 
> 
> Type-safe linkage, mainly.  That actually would be a nice thing.
> 

And let the compiler do all what now is done by hand wrt driver methods,
inheritance, specialized methods and so on, with a 1000% increase in security
because compiler does not forget to do thinks, like we do ;)

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-rc2-jam4 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-1mdk)) #4


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: What if?

[Alan Cox]

On Llu, 2004-12-13 at 21:08, J.A. Magallon wrote:
> > Type-safe linkage, mainly.  That actually would be a nice thing.
> > 
> 
> And let the compiler do all what now is done by hand wrt driver methods,
> inheritance, specialized methods and so on, with a 1000% increase in security
> because compiler does not forget to do thinks, like we do ;)

This is not a C++ thing per se however. A future gcc could do type safe
linkage of C programs instead of C++.

Re: What if?

[H. Peter Anvin]

Alan Cox wrote:
> On Llu, 2004-12-13 at 21:08, J.A. Magallon wrote:
> 
>>>Type-safe linkage, mainly.  That actually would be a nice thing.
>>>
>>And let the compiler do all what now is done by hand wrt driver methods,
>>inheritance, specialized methods and so on, with a 1000% increase in security
>>because compiler does not forget to do thinks, like we do ;)
> 
> This is not a C++ thing per se however. A future gcc could do type safe
> linkage of C programs instead of C++.

Yes, but there is also no really big deal compiling C code with a C++ 
compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.

There is a huge difference between "C compiled with a C++ compiler" and 
the "go crazy with keeping the programmer in the dark" concept proposed 
by Mr. Magallon.

	-hpa

Re: What if?

[Alan Cox]

On Iau, 2004-12-16 at 02:44, H. Peter Anvin wrote:
> Yes, but there is also no really big deal compiling C code with a C++ 
> compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.

g++ is still much slower. We don't know how many bugs it would show up
in the compiler and tools either, especially on embedded platforms.
Finally the current kernel won't go through a C++ compiler because we
use variables like "new" quite often.

Re: What if?

[Geert Uytterhoeven]

On Thu, 16 Dec 2004, Alan Cox wrote:
> On Iau, 2004-12-16 at 02:44, H. Peter Anvin wrote:
> > Yes, but there is also no really big deal compiling C code with a C++ 
> > compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.
> 
> g++ is still much slower. We don't know how many bugs it would show up
> in the compiler and tools either, especially on embedded platforms.

Interesting to find out, anyway (for the g++-developers :-)

> Finally the current kernel won't go through a C++ compiler because we
> use variables like "new" quite often.

Not something that can't be worked around using a simple #define...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: What if?

[H. Peter Anvin]

Alan Cox wrote:
> On Iau, 2004-12-16 at 02:44, H. Peter Anvin wrote:
> 
>>Yes, but there is also no really big deal compiling C code with a C++ 
>>compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.
> 
> 
> g++ is still much slower. We don't know how many bugs it would show up
> in the compiler and tools either, especially on embedded platforms.
> Finally the current kernel won't go through a C++ compiler because we
> use variables like "new" quite often.

-Dnew=_New, problem solved.

I'm not in any way advocating compiling with g++ exclusively, but it 
would be nice to be *able to* for bugchecking.  It would be an 
interesting experiment, of nothing else.  I suspect it'd require some 
minor code tweaks and turn up a small handful of bugs right off the bat.

	-hpa

Re: What if?

[Jan Engelhardt]

>> g++ is still much slower. We don't know how many bugs it would show up
>> in the compiler and tools either, especially on embedded platforms.
>> Finally the current kernel won't go through a C++ compiler because we
>> use variables like "new" quite often.
>
> -Dnew=_New, problem solved.

It's not that easy. Just when you expect it least, a few tiny sourcecode bits 
already use new (in the C++ sense) and whoops:
	int *b = _New int[4];
(self-explanatory)





Jan Engelhardt
-- 
ENOSPC

Re: What if?

[H. Peter Anvin]

Jan Engelhardt wrote:
>>>g++ is still much slower. We don't know how many bugs it would show up
>>>in the compiler and tools either, especially on embedded platforms.
>>>Finally the current kernel won't go through a C++ compiler because we
>>>use variables like "new" quite often.
>>
>>-Dnew=_New, problem solved.
> 
> 
> It's not that easy. Just when you expect it least, a few tiny sourcecode bits 
> already use new (in the C++ sense) and whoops:
> 	int *b = _New int[4];
> (self-explanatory)
> 

Unlikely, since we'd already have caught it, but either way -- hat's a 
bug too.  There shouldn't be any C++ code in the kernel, period.

	-hpa

Re: What if?

[Jan Engelhardt]

> There shouldn't be any C++ code in the kernel, period.

Don't tell _me_ that. (I'm staying pure with C here.)



Jan Engelhardt
-- 
ENOSPC

Re: What if?

[Jan Engelhardt]

>    Firstly I have read the FAQ. So though FAQ answers my question, it
>does so only partially.
>
>    "What if Linux were to be implemented in C++?"

To quota Alan Cox (IIRC): "Been there, done that, threw it out".



Jan Engelhardt
-- 
ENOSPC

Re: What if?

[Horst von Brand]

Jan Engelhardt <jengelh@linux01.gwdg.de> said:
> Imanpreet Singh Arora <imanpreet@gmail.com> said:
> >    Firstly I have read the FAQ. So though FAQ answers my question, it
> >does so only partially.
> >
> >    "What if Linux were to be implemented in C++?"

> To quota Alan Cox (IIRC): "Been there, done that, threw it out".

Not really. There was support to compile Linux using g++ for a C compiler
some time back (because of better (at the time) type checking), the result
was horrible (mainly due to compiler bugs, IIRC). The gain wasn't near
worth the pain.

Rewriting Linux in C++ means fundamental redesign(s); as mentioned, the VFS
would become a class, as would the driver interfaces, and much more. The
object model inside Linux is sufficiently different from C++'s that it
would be a _huge_ job. And pointless, you'd just get Linux as it stands
today, and loose many current developers (due to unfamiliarity with C++).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: What if?

[Kyle Moffett]

On Dec 04, 2004, at 19:23, Horst von Brand wrote:
> ... And pointless, you'd just get Linux as it stands
> today, and loose many current developers (due to unfamiliarity with 
> C++).

Personally, the reason _I_ hate C++ is that I got tired of having to 
learn the obtuse
combinations of symbols and excess keywords necessary to bludgeon my
favorite refcount and memory management systems into the C++ objects.  
It just
wasn't worth the effort when I could write equivalent, better, and 
easier to read
code in C.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: What if?

[Horst von Brand]

Kyle Moffett <mrmacman_g4@mac.com> said:
> On Dec 04, 2004, at 19:23, Horst von Brand wrote:
> > ... And pointless, you'd just get Linux as it stands
> > today, and loose many current developers (due to unfamiliarity with 
> > C++).

> Personally, the reason _I_ hate C++ is that I got tired of having to
> learn the obtuse combinations of symbols and excess keywords necessary to
> bludgeon my favorite refcount and memory management systems into the C++
> objects.  It just wasn't worth the effort when I could write equivalent,
> better, and easier to read code in C.

C++ is sufficiently not C that for such it is probably best to just
redesign the systems. Well done it is probably more elegant than C, but to
get there is a _lot_ of work.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: What if?

[linux-os]

On Sun, 5 Dec 2004, Horst von Brand wrote:

> Kyle Moffett <mrmacman_g4@mac.com> said:
>> On Dec 04, 2004, at 19:23, Horst von Brand wrote:
>>> ... And pointless, you'd just get Linux as it stands
>>> today, and loose many current developers (due to unfamiliarity with
>>> C++).
>
>> Personally, the reason _I_ hate C++ is that I got tired of having to
>> learn the obtuse combinations of symbols and excess keywords necessary to
>> bludgeon my favorite refcount and memory management systems into the C++
>> objects.  It just wasn't worth the effort when I could write equivalent,
>> better, and easier to read code in C.
>
> C++ is sufficiently not C that for such it is probably best to just
> redesign the systems. Well done it is probably more elegant than C, but to
> get there is a _lot_ of work.
> -- 
> Dr. Horst H. von Brand                   User #22616 counter.li.org
> Departamento de Informatica                     Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria              +56 32 654239
> Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

There is another problem. The kernel requires a procedural language
to communicate with hardware. Interface with hardware is all about
the step-by-step methods necessary to make hardware run. C++ tries
to isolate one from the actual methods involved. That's what it
was designed for.

One would need to use "extensions" just to get text to the screen.
'C' being an "smart" assembler, is nearly ideal for kernel
development.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by John Ashcroft.
                  98.36% of all statistics are fiction.

Re: What if?

[Horst von Brand]

linux-os <linux-os@chaos.analogic.com> said:
> On Sun, 5 Dec 2004, Horst von Brand wrote:

[...]

> > C++ is sufficiently not C that for such it is probably best to just
> > redesign the systems. Well done it is probably more elegant than C, but to
> > get there is a _lot_ of work.

> There is another problem. The kernel requires a procedural language
> to communicate with hardware. Interface with hardware is all about
> the step-by-step methods necessary to make hardware run. C++ tries
> to isolate one from the actual methods involved. That's what it
> was designed for.

If you want isolation. The actual methods (I'm assuming function members)
are written in procedural style if you want to.

> One would need to use "extensions" just to get text to the screen.  'C'
> being an "smart" assembler, is nearly ideal for kernel development.

And C++ is supposed to be an OO extension to C, designed to give a
(knowledgeable) programmer exactly the same low-level control as C when
needed (knowlegdeable, tasteful programmer is requisite).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: What if?

[Bernd Petrovitsch]

On Thu, 2004-12-02 at 05:34 +0530, Imanpreet Singh Arora wrote:
>   Firstly I have read the FAQ. So though FAQ answers my question, it 
> does so only partially.
>
>     "What if Linux were to be implemented in C++?"

BTW some years ago, there were people who actually worked on compiling
the existing Linux kernel with g++. So probably you want to start with
such a project to get a feeling ....

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: What if?

[Gábor Lénárt]

On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> familiar with C, rather than C++. However other than that what are the  
> _implementation_  issues that you hackers might need to consider if it 
> were to be implemented in C++. My question is regarding how will kernel 

It's a quite simple question: why would it better to implement kernel
in C++? To CHANGE something, you should always consider the advantages
and disadvantages. I think it's NO advantages to implement kernel in C++
over to do it in C. So then why is it useful?

- Gábor (larta'H)