Re: C++ pushback

Re: C++ pushback

[Robert Hancock]

Denis Vlasenko wrote:
> Random example. gcc-3.4.3/include/g++-v3/bitset:
> 
>   template<size_t _Nw>
>     struct _Base_bitset
>     {
>       typedef unsigned long _WordT;
> 
>       /// 0 is the least significant word.
>       _WordT            _M_w[_Nw];
> 
>       _Base_bitset() { _M_do_reset(); }
> ...
>       void
>       _M_do_set()
>       {
>         for (size_t __i = 0; __i < _Nw; __i++)
>           _M_w[__i] = ~static_cast<_WordT>(0);
>       }
>       void
>       _M_do_reset() { memset(_M_w, 0, _Nw * sizeof(_WordT)); }
> ...
> 

..

> Why _M_do_reset() is not inlined?

It is.. anything declared as part of the declaration is considered 
inline by default.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: C++ pushback

[Denis Vlasenko]

On Thursday 27 April 2006 17:23, Robert Hancock wrote:
> Denis Vlasenko wrote:
> > Random example. gcc-3.4.3/include/g++-v3/bitset:
> > 
> >   template<size_t _Nw>
> >     struct _Base_bitset
> >     {
> >       typedef unsigned long _WordT;
> > 
> >       /// 0 is the least significant word.
> >       _WordT            _M_w[_Nw];
> > 
> >       _Base_bitset() { _M_do_reset(); }
> > ...
> >       void
> >       _M_do_set()
> >       {
> >         for (size_t __i = 0; __i < _Nw; __i++)
> >           _M_w[__i] = ~static_cast<_WordT>(0);
> >       }
> >       void
> >       _M_do_reset() { memset(_M_w, 0, _Nw * sizeof(_WordT)); }
> > ...
> > 
> 
> ..
> 
> > Why _M_do_reset() is not inlined?
> 
> It is.. anything declared as part of the declaration is considered 
> inline by default.

You're right, I forgot about that 

Re: Compiling C++ modules

[Greg KH]

On Mon, Apr 24, 2006 at 01:16:26PM -0600, Gary Poppitz wrote:
> I have the task of porting an existing file system to Linux. This  
> code is in C++ and I have noticed that the Linux kernel has
> made use of C++ keywords and other things that make it incompatible.

We know they are "incompatible", why else would we allow "private" and
"struct class" in the kernel source if we some how expected it to work
with a C++ compiler?

Please see the lkml FAQ (linked to at the bottom of every lkml message)
for why this will not happen.

thanks,

greg k-h

C++ pushback

[Gary Poppitz]

> We know they are "incompatible", why else would we allow "private" and
> "struct class" in the kernel source if we some how expected it to work
> with a C++ compiler?


I can see that this was intentional, not an oversight.

If there is a childish temper tantrum mentality about C++ then I have  
no reason or desire to be on this list.

Grow up.

Re: C++ pushback

[Christoph Hellwig]

On Mon, Apr 24, 2006 at 02:02:27PM -0600, Gary Poppitz wrote:
> >We know they are "incompatible", why else would we allow "private" and
> >"struct class" in the kernel source if we some how expected it to work
> >with a C++ compiler?
> 
> 
> I can see that this was intentional, not an oversight.
> 
> If there is a childish temper tantrum mentality about C++ then I have  
> no reason or desire to be on this list.

so sodd off.

Re: C++ pushback

[Greg KH]

On Mon, Apr 24, 2006 at 02:02:27PM -0600, Gary Poppitz wrote:
> >We know they are "incompatible", why else would we allow "private" and
> >"struct class" in the kernel source if we some how expected it to work
> >with a C++ compiler?
> 
> 
> I can see that this was intentional, not an oversight.
> 
> If there is a childish temper tantrum mentality about C++ then I have  
> no reason or desire to be on this list.

If there is a lack of willingness to do a simple bit of research:
	http://www.google.com/search?q=linux+kernel+C%2B%2B
The responses you get back might seem a big harsh.

In short, the rule around here, as well with most groups in life, seems
to be:
	"show no respect, get none in return"

thanks,

greg k-h

Re: C++ pushback

[Martin Mares]

> If there is a childish temper tantrum mentality about C++ then I have  
> no reason or desire to be on this list.

Can you name any reasons for why should we support C++ in the kernel?
Why shouldn't we invest the effort to making it possible to write kernel
modules in Haskell instead?

The kernel is written in C and its maintainers have so far agreed that
C is enough and adding any other language brings more pain than gain.

If you think otherwise, feel free to submit some real code which shows
the advantages of using a different language.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
United Computer Wizards, Prague, Czech Republic, Europe, Earth, Universe
"C++: an octopus made by nailing extra legs onto a dog." -- Steve Taylor

Re: C++ pushback

[Jeff V. Merkey]

Martin Mares wrote:

>>If there is a childish temper tantrum mentality about C++ then I have  
>>no reason or desire to be on this list.
>>    
>>
>
>Can you name any reasons for why should we support C++ in the kernel?
>Why shouldn't we invest the effort to making it possible to write kernel
>modules in Haskell instead?
>
>The kernel is written in C and its maintainers have so far agreed that
>C is enough and adding any other language brings more pain than gain.
>
>If you think otherwise, feel free to submit some real code which shows
>the advantages of using a different language.
>
>				Have a nice fortnight
>  
>
C++ in the kernel is a BAD IDEA. C++ code can be written in such a 
convoluted manner as to be unmaintainable and unreadable.
All of the hidden memory allocations from constructor/destructor 
operatings can and do KILL OS PERFORMANCE. Java
is a great example as to why kernel OS code should NEVER be allowed in C++.

C and C++ really show their origins when used in kernel level 
programming. So what were C and C++ originally -- they were grades. :-)

I applaud the LKML folks pushing back on C++.

A++.

Jeff

Re: C++ pushback

[J.A. Magallon]

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

On Mon, 24 Apr 2006 15:36:50 -0600, "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> wrote:

Ahhh, I use to trash this discussions until I see something like this...

> Martin Mares wrote:
> 
> All of the hidden memory allocations from constructor/destructor 
> operatings can and do KILL OS PERFORMANCE.

FUD. Learn to write C++.

> Java
> is a great example as to why kernel OS code should NEVER be allowed in C++.
> 

Java and C++ are like apples and oranges.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam9 (gcc 4.1.1 20060330 (prerelease)) #1 SMP PREEMPT Tue

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: C++ pushback

[Harald Arnesen]

"J.A. Magallon" <jamagallon@able.es> writes:

>> Java
>> is a great example as to why kernel OS code should NEVER be allowed in C++.
>> 
>
> Java and C++ are like apples and oranges.

Fruity :-)
-- 
Hilsen Harald.

Re: C++ pushback

[Alan Cox]

On Llu, 2006-04-24 at 15:36 -0600, Jeff V. Merkey wrote:
> C++ in the kernel is a BAD IDEA. C++ code can be written in such a 
> convoluted manner as to be unmaintainable and unreadable.

So can C. 

> All of the hidden memory allocations from constructor/destructor 
> operatings can and do KILL OS PERFORMANCE. 

This is one area of concern. Just as big a problem for the OS case is
that the hidden constructors/destructors may fail. You can write C++
code carefully to avoid these things but it can be hard to see where the
problem is when you miss one.

C at least makes it verbose, but we trade that for poorer typechecking
and visibility control.

Alan

Re: C++ pushback

[J.A. Magallon]

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

On Mon, 24 Apr 2006 22:52:12 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Llu, 2006-04-24 at 15:36 -0600, Jeff V. Merkey wrote:
> > C++ in the kernel is a BAD IDEA. C++ code can be written in such a 
> > convoluted manner as to be unmaintainable and unreadable.
> 
> So can C. 
> 
> > All of the hidden memory allocations from constructor/destructor 
> > operatings can and do KILL OS PERFORMANCE. 
> 
> This is one area of concern. Just as big a problem for the OS case is
> that the hidden constructors/destructors may fail.

Tell me what is the difference between:


    sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
    if (!sbi)
        return -ENOMEM;
    sb->s_fs_info = sbi;
    memset(sbi, 0, sizeof(*sbi));
    sbi->s_mount_opt = 0;
    sbi->s_resuid = EXT3_DEF_RESUID;
    sbi->s_resgid = EXT3_DEF_RESGID;

and

    SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
    {}

    ...
    sbi = new SuperBlock;
    if (!sbi)
        return -ENOMEM;

apart that you don't get members initalized twice and get a shorter code :).

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam9 (gcc 4.1.1 20060330 (prerelease)) #1 SMP PREEMPT Tue

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: C++ pushback

[Harald Arnesen]

"J.A. Magallon" <jamagallon@able.es> writes:

> Tell me what is the difference between:
>
>
>     sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
>     if (!sbi)
>         return -ENOMEM;
>     sb->s_fs_info = sbi;
>     memset(sbi, 0, sizeof(*sbi));
>     sbi->s_mount_opt = 0;
>     sbi->s_resuid = EXT3_DEF_RESUID;
>     sbi->s_resgid = EXT3_DEF_RESGID;
>
> and
>
>     SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>     {}
>
>     ...
>     sbi = new SuperBlock;
>     if (!sbi)
>         return -ENOMEM;
>
> apart that you don't get members initalized twice and get a shorter code :).

The former is easier to read and understand?
-- 
Hilsen Harald.

Re: C++ pushback

[Diego Calleja]

El Tue, 25 Apr 2006 02:05:29 +0200,
Harald Arnesen <harald@skogtun.org> escribió:

> The former is easier to read and understand?

C is not perfect, it could very well get a bit improved so it helps to make 
the code more readable, etc (and I mean: just improvements, not "lets try to
turn C into a OO language"). That however requires modifying the current
C standards, gcc...

But that doesn't justifies adding C++ support to the kernel.

Re: C++ pushback

[Harald Arnesen]

Diego Calleja <diegocg@gmail.com> writes:

> El Tue, 25 Apr 2006 02:05:29 +0200,
> Harald Arnesen <harald@skogtun.org> escribió:
>
>> The former is easier to read and understand?
>
> C is not perfect, it could very well get a bit improved so it helps to make 
> the code more readable, etc (and I mean: just improvements, not "lets try to
> turn C into a OO language"). That however requires modifying the current
> C standards, gcc...
>
> But that doesn't justifies adding C++ support to the kernel.

It was the C version I found easier to understand.
-- 
Hilsen Harald.

Re: C++ pushback

[linux-os (Dick Johnson)]

On Mon, 24 Apr 2006, J.A. Magallon wrote:

> On Mon, 24 Apr 2006 22:52:12 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>> On Llu, 2006-04-24 at 15:36 -0600, Jeff V. Merkey wrote:
>>> C++ in the kernel is a BAD IDEA. C++ code can be written in such a
>>> convoluted manner as to be unmaintainable and unreadable.
>>
>> So can C.
>>
>>> All of the hidden memory allocations from constructor/destructor
>>> operatings can and do KILL OS PERFORMANCE.
>>
>> This is one area of concern. Just as big a problem for the OS case is
>> that the hidden constructors/destructors may fail.
>
> Tell me what is the difference between:
>
>
>    sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
>    if (!sbi)
>        return -ENOMEM;
>    sb->s_fs_info = sbi;
>    memset(sbi, 0, sizeof(*sbi));
>    sbi->s_mount_opt = 0;
>    sbi->s_resuid = EXT3_DEF_RESUID;
>    sbi->s_resgid = EXT3_DEF_RESGID;
>
> and
>
>    SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>    {}
>
>    ...
>    sbi = new SuperBlock;
>    if (!sbi)
>        return -ENOMEM;
>
> apart that you don't get members initalized twice and get a shorter code :).
>
> --
> J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
> werewolf!able!es                         \         It's better when it's free
> Mandriva Linux release 2006.1 (Cooker) for i586
> Linux 2.6.16-jam9 (gcc 4.1.1 20060330 (prerelease)) #1 SMP PREEMPT Tue
>

I'd like to write modules in FORTRAN, myself. Unless you have been
writing software since computers were programmed with diode-pins, one
tends to think that the first programming language learned is the
best. It's generally because they are all bad, and once you learn how
to make the defective language do what you want, you tend to identify
with it. Identifying with one's captors, the Stockholm syndrome,
that's what these languages cause.

But, a master carpenter has many tools. He chooses the best for each
task. When you need to make computer hardware do what you want, in
a defined manner, in the particular order in which you require,
you use assembly language to generate the exact machine-code required.
It is possible to compromise a bit and use a slightly higher-level
procedural language called C. One loses control of everything with
any other language. Note that before C was invented, all operating
system code was written in assembly.

C++ wasn't written for this kind of work. It was written so that a
programmer didn't have to care how something was done only that somehow
it would get done. Also, as you peel away the onion skins from many
C++ graphics libraries, you find inside the core that does the work.
It's usually written in C.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: C++ pushback

[marty fouts]

On 4/24/06, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:

> It is possible to compromise a bit and use a slightly higher-level
> procedural language called C. One loses control of everything with
> any other language. Note that before C was invented, all operating
> system code was written in assembly.

Even if by "operating system" you mean kernel,  this turns out not to
be true. Operating systems written in other 'moderate-level' languages
such as Fortran predate C.  (Once upon a time, a company called Pr1me
had an OS called PrimeOS, written in Fortran.)

My all time favorite OS, RSTS/E, was largely written in a Dec variant
of BASIC, called BASIC-PLUS.

High level languages  have been invented just for writing OSes (BLISS)
and OSes have been successfully written in a LISP,  PL/1, and even
C++. The last OS I worked on was almost entirely in C++ and worked ok.

What you don't want to do is add a new language to a system that was
largely written in another language. It's tempting to add C++ to a
large C system because C and C++ are similar, but it's almost always a
disaster, because you organize large systems much differently if you
design them for C++.

Re: C++ pushback

[Bill Davidsen]

linux-os (Dick Johnson) wrote:
> On Mon, 24 Apr 2006, J.A. Magallon wrote:
> 
>> On Mon, 24 Apr 2006 22:52:12 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>
>>> On Llu, 2006-04-24 at 15:36 -0600, Jeff V. Merkey wrote:
>>>> C++ in the kernel is a BAD IDEA. C++ code can be written in such a
>>>> convoluted manner as to be unmaintainable and unreadable.
>>> So can C.
>>>
>>>> All of the hidden memory allocations from constructor/destructor
>>>> operatings can and do KILL OS PERFORMANCE.
>>> This is one area of concern. Just as big a problem for the OS case is
>>> that the hidden constructors/destructors may fail.
>> Tell me what is the difference between:

...clear readable code...
>>
>> and
>>
>>    SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>>    {}
...double bagger...

> I'd like to write modules in FORTRAN, myself. Unless you have been
> writing software since computers were programmed with diode-pins, one
> tends to think that the first programming language learned is the
> best. It's generally because they are all bad, and once you learn how
> to make the defective language do what you want, you tend to identify
> with it. Identifying with one's captors, the Stockholm syndrome,
> that's what these languages cause.

No, I wouldn't touch any of the early languages I learned, the first one 
I liked was ALGOL-60. The software for GE's first CT scanner was 
developed in ALGOL-60. I liked PL/1 when GE was part of the MULTICS 
project, and the whole BCPL->B->C family was fun, although I do like C 
best. GE had an implementation language called I-language which was a 
great system language, but they buried it instead of releasing it. I 
hated FORTRAN, LISP and APL, although I wrote a lot of each, predicted 
that Ada would not be popular, but I like PERL. I wrote text tools in 
TRAC (look that one up ;-) but that's kind of all it did well.

If you hadn't made this next point I would have...
> 
> But, a master carpenter has many tools. He chooses the best for each
> task. When you need to make computer hardware do what you want, in
> a defined manner, in the particular order in which you require,
> you use assembly language to generate the exact machine-code required.
> It is possible to compromise a bit and use a slightly higher-level
> procedural language called C. One loses control of everything with
> any other language. Note that before C was invented, all operating
> system code was written in assembly.

Hate to tell you, C came about a decade after MULTICS was written in 
PL/1, and I think DEC had VMS out in BLISS before C. C came from B (as 
did IMP68), which came from BCPL.
> 
> C++ wasn't written for this kind of work. It was written so that a
> programmer didn't have to care how something was done only that somehow
> it would get done. Also, as you peel away the onion skins from many
> C++ graphics libraries, you find inside the core that does the work.
> It's usually written in C.

C++ allows more abstraction than C, unfortunately too many people go 
right past past abstraction to obfuscation. With operator overloading 
it's possible to generate write-only code, and programs where "A=B+C" 
does file operations :-( That doesn't belong in an operating system, C 
is the right choice.

Sorry for the history lesson, you got me thinking about my first languages.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: C++ pushback

[Randy.Dunlap]

On Thu, 27 Apr 2006 18:55:02 -0400 Bill Davidsen wrote:

> linux-os (Dick Johnson) wrote:
> > On Mon, 24 Apr 2006, J.A. Magallon wrote:

> 
> If you hadn't made this next point I would have...
> > 
> > But, a master carpenter has many tools. He chooses the best for each
> > task. When you need to make computer hardware do what you want, in
> > a defined manner, in the particular order in which you require,
> > you use assembly language to generate the exact machine-code required.
> > It is possible to compromise a bit and use a slightly higher-level
> > procedural language called C. One loses control of everything with
> > any other language. Note that before C was invented, all operating
> > system code was written in assembly.
> 
> Hate to tell you, C came about a decade after MULTICS was written in 
> PL/1, and I think DEC had VMS out in BLISS before C. C came from B (as 
> did IMP68), which came from BCPL.

and Burroughs used Algol for multi-proc (master/slave, not SMP)
virtual memory OSes in the 1960s.  :)

---
~Randy

RE: C++ pushback

[David Schwartz]

> C++ allows more abstraction than C, unfortunately too many people go
> right past past abstraction to obfuscation. With operator overloading
> it's possible to generate write-only code, and programs where "A=B+C"
> does file operations :-( That doesn't belong in an operating system, C
> is the right choice.

>     -bill davidsen (davidsen@tmr.com)

	I reject any argument of the type "because a language *allows* you to do X,
and X is not always good, the language is bad". Now, if the language
*required* you to do bad things, that would be a different story.

	If I could demonstrate ways to do bad things in C that don't belong in an
operating system, would that convince you that C is not the right choice?
For example, C allows easy use of floating point math, which doesn't belong
in an operating system either.

	DS

Re: C++ pushback

[Xavier Bestel]

On Tue, 2006-04-25 at 00:16, J.A. Magallon wrote:

> Tell me what is the difference between:
> 
> 
>     sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
>     if (!sbi)
>         return -ENOMEM;
>     sb->s_fs_info = sbi;
>     memset(sbi, 0, sizeof(*sbi));
>     sbi->s_mount_opt = 0;
>     sbi->s_resuid = EXT3_DEF_RESUID;
>     sbi->s_resgid = EXT3_DEF_RESGID;
> 
> and
> 
>     SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>     {}
> 
>     ...
>     sbi = new SuperBlock;
>     if (!sbi)
>         return -ENOMEM;

In the first case you know that exactely *one* kmalloc(GFP_KERNEL)
occurs. In the second case you have to browse SuperBlock's constructor
to check if it allocates things, needs to run with/without interrupts,
PREEMPT, whatever... (not even talking about exceptions).

	Xav

Re: C++ pushback

[Avi Kivity]

Xavier Bestel wrote:
> In the first case you know that exactely *one* kmalloc(GFP_KERNEL)
> occurs. In the second case you have to browse SuperBlock's constructor
> to check if it allocates things, needs to run with/without interrupts,
> PREEMPT, whatever... (not even talking about exceptions).
>   
That seems to be a case against writing functions.

Why is a C function acceptable where a C++ constructor isn't?

-- 
error compiling committee.c: too many arguments to function

Re: C++ pushback

[Martin Mares]

Hello!

> That seems to be a case against writing functions.
> 
> Why is a C function acceptable where a C++ constructor isn't?

Because examining a single constructor is not enough -- you need to
check constructors of all objects contained within the object you
initialize.

Calling a C function is simple and explicit -- a quick glance over
the code is enough to tell what gets called.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Man is the highest animal. Man does the classifying.

Re: C++ pushback

[Avi Kivity]

Martin Mares wrote:
>   
>> That seems to be a case against writing functions.
>>
>> Why is a C function acceptable where a C++ constructor isn't?
>>     
>
> Because examining a single constructor is not enough -- you need to
> check constructors of all objects contained within the object you
> initialize.
>
> Calling a C function is simple and explicit -- a quick glance over
> the code is enough to tell what gets called.
>
>   
No, you need to check all the functions it calls as well.

But I agree that C is more explicit than C++.

-- 
error compiling committee.c: too many arguments to function

Re: C++ pushback

[Martin Mares]

> >Calling a C function is simple and explicit -- a quick glance over
> >the code is enough to tell what gets called.
> >
> No, you need to check all the functions it calls as well.

Yes, but if it calls none (or calls basic functions I already know),
it's immediately visible without having to circumnavigate the globe
to find declarations of all sub-objects :)

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Homo homini lupus, frater fratri lupior, bohemus bohemo lupissimus.

Re: C++ pushback

[Avi Kivity]

Martin Mares wrote:
>>> Calling a C function is simple and explicit -- a quick glance over
>>> the code is enough to tell what gets called.
>>>
>>>       
>> No, you need to check all the functions it calls as well.
>>     
>
> Yes, but if it calls none (or calls basic functions I already know),
> it's immediately visible without having to circumnavigate the globe
> to find declarations of all sub-objects :)
>
>   
Yes, but if the constructor constructs no sub objects (or basic objects 
you already know) then it's immediately visible as well.


-- 
error compiling committee.c: too many arguments to function

Re: C++ pushback

[Xavier Bestel]

On Tue, 2006-04-25 at 11:13, Avi Kivity wrote:
> Martin Mares wrote:
> >>> Calling a C function is simple and explicit -- a quick glance over
> >>> the code is enough to tell what gets called.
> >>>
> >>>       
> >> No, you need to check all the functions it calls as well.
> >>     
> >
> > Yes, but if it calls none (or calls basic functions I already know),
> > it's immediately visible without having to circumnavigate the globe
> > to find declarations of all sub-objects :)
> >
> >   
> Yes, but if the constructor constructs no sub objects (or basic objects 
> you already know) then it's immediately visible as well.

Yes, "if". With straight C, it's immediatly obvious the kmalloc() is the
only function with side-effects and special requirements - an
experienced hacker won't even look it up. With C++ those may be hidden
behind each object or object member, that's the philosophy of the
language. 
The problem is that in kernel mode you must know precisely when and how
you allocate memory.

	Xav

Re: C++ pushback

[J.A. Magallon]

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

On Tue, 25 Apr 2006 11:22:32 +0200, Xavier Bestel <xavier.bestel@free.fr> wrote:

> 
> Yes, "if". With straight C, it's immediatly obvious the kmalloc() is the
> only function with side-effects and special requirements - an
> experienced hacker won't even look it up. With C++ those may be hidden
> behind each object or object member, that's the philosophy of the
> language. 
> The problem is that in kernel mode you must know precisely when and how
> you allocate memory.
> 

Don't mix allocation with initialization.
Well, lets see:

  struct xxx {
    struct yyy* y;
    int z;
  }
  
  xxx_init(struct xxx* x)
  {
     z = 0;
     y = kmalloc(GPF_KERNEL,sizeof(struct yyy));
     yyy_init(y);
  }

Now, if on other source file you read:
  ...
  struct xxx* x;
  x = kmallloc(GPF_KERNEL,sizeof(struct xxx));
  xxx_init(x);
  ..
  struct xxx  x2;
  xxx_init(&x2);

How do you know what xxx_init() does without looking at it ?
Cay you have just the allocation without init ? What happens if you forget it ?
What happens if you cut'n'paste from other driver and let something like

  struct xxx* x;
  x = kmallloc(GPF_KERNEL,sizeof(struct qqqqq));
  xxx_init(x);

The only difference it that
  x = new(GPF_KERNEL) XXX;

always does what it has to do correctly. What does XXX() constructor ?
You have to look at it, same as xxx_init().

As I said in other answer: I'm not advocating to include C++ support in
current kernel. I just say that the only valid argument is that
'KERNEL IS C', and interfacing C with C++ just would add bloat and errors.
There is no technical argument to reject to write an OS kernel in C++.
It would not be slower nor more complicated, and it will be probably safer
because it leaves less things (from thost you always _must_ do) to
programmers memories.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam9 (gcc 4.1.1 20060330 (prerelease)) #1 SMP PREEMPT Tue

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: C++ pushback

[Barry Kelly]

On Tue, 25 Apr 2006 22:20:26 +0200, "J.A. Magallon" <jamagallon@able.es>
wrote:

> There is no technical argument to reject to write an OS kernel in C++.
> It would not be slower nor more complicated, and it will be probably safer
> because it leaves less things (from thost you always _must_ do) to
> programmers memories.

In a pageable kernel, it would be harder to guarantee that virtual
methods' code is paged in while locks that govern the VM are held.

Of course you could get the same problem with C and pointers to functions,
but at least you could probe them explicitly. With C++, the vtable is one
step removed.

-- Barry

Re: C++ pushback

[Nikita Danilov]

J.A. Magallon writes:

[...]

 > 
 > Tell me what is the difference between:
 > 
 > 
 >     sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
 >     if (!sbi)
 >         return -ENOMEM;
 >     sb->s_fs_info = sbi;
 >     memset(sbi, 0, sizeof(*sbi));
 >     sbi->s_mount_opt = 0;
 >     sbi->s_resuid = EXT3_DEF_RESUID;
 >     sbi->s_resgid = EXT3_DEF_RESGID;
 > 
 > and
 > 
 >     SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
 >     {}
 > 
 >     ...
 >     sbi = new SuperBlock;
 >     if (!sbi)
 >         return -ENOMEM;
 > 
 > apart that you don't get members initalized twice and get a shorter code :).

The difference is that second fragment doesn't mention GFP_KERNEL, so
it's most likely wrong. Moreover it's shorter only because it places
multiple initializations on the same like, hence, contradicting
CodingStyle.

 > 
 > --
 > J.A. Magallon <jamagallon()able!es>     \               Software is like sex:

Nikita.

Re: C++ pushback

[J.A. Magallon]

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

On Tue, 25 Apr 2006 13:09:47 +0400, Nikita Danilov <nikita@clusterfs.com> wrote:

> J.A. Magallon writes:
> 
> [...]
> 
>  > 
>  > Tell me what is the difference between:
>  > 
>  > 
>  >     sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
>  >     if (!sbi)
>  >         return -ENOMEM;
>  >     sb->s_fs_info = sbi;
>  >     memset(sbi, 0, sizeof(*sbi));
>  >     sbi->s_mount_opt = 0;
>  >     sbi->s_resuid = EXT3_DEF_RESUID;
>  >     sbi->s_resgid = EXT3_DEF_RESGID;
>  > 
>  > and
>  > 
>  >     SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>  >     {}
>  > 
>  >     ...
>  >     sbi = new SuperBlock;
>  >     if (!sbi)
>  >         return -ENOMEM;
>  > 
>  > apart that you don't get members initalized twice and get a shorter code :).
> 
> The difference is that second fragment doesn't mention GFP_KERNEL, so
> it's most likely wrong. Moreover it's shorter only because it places
> multiple initializations on the same like, hence, contradicting
> CodingStyle.
> 

Well, you could always have 

   sbi = new(GPF_KERNEL) SuperBlock;

And CodingStyle was written for C.

Just to make a thing clear: I'm not advocating to include C++ support in
current kernel. I just say that the only valid argument is that
'KERNEL IS C', and interfacing C with C++ just would add bloat and errors.
There is no technical argument to reject to write an OS kernel in C++.
It would not be slower not more complicated, and it will be probably safer
because it leaves less things (from thost you always _must_ do) to
programmers memories.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam9 (gcc 4.1.1 20060330 (prerelease)) #1 SMP PREEMPT Tue

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: C++ pushback

[Geert Uytterhoeven]

On Tue, 25 Apr 2006, J.A. Magallon wrote:
> On Mon, 24 Apr 2006 22:52:12 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > This is one area of concern. Just as big a problem for the OS case is
> > that the hidden constructors/destructors may fail.
> 
> Tell me what is the difference between:
> 
> 
>     sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
>     if (!sbi)
>         return -ENOMEM;
>     sb->s_fs_info = sbi;
>     memset(sbi, 0, sizeof(*sbi));
>     sbi->s_mount_opt = 0;
>     sbi->s_resuid = EXT3_DEF_RESUID;
>     sbi->s_resgid = EXT3_DEF_RESGID;
> 
> and
> 
>     SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>     {}
> 
>     ...
>     sbi = new SuperBlock;

You forgot the `nothrow'.

>     if (!sbi)
>         return -ENOMEM;
> 
> apart that you don't get members initalized twice and get a shorter code :).

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: C++ pushback

[Alexander E. Patrakov]

J.A. Magallon wrote:
> Tell me what is the difference between:
> 
> 
>     sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
>     if (!sbi)
>         return -ENOMEM;
>     sb->s_fs_info = sbi;
>     memset(sbi, 0, sizeof(*sbi));
>     sbi->s_mount_opt = 0;
>     sbi->s_resuid = EXT3_DEF_RESUID;
>     sbi->s_resgid = EXT3_DEF_RESGID;
> 
> and
> 
>     SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>     {}
> 
>     ...
>     sbi = new SuperBlock;
>     if (!sbi)
>         return -ENOMEM;
> 
> apart that you don't get members initalized twice and get a shorter code :).

The second example is simply incorrect, because the operator new throws an 
exception when we run out of memory, instead of returning a null pointer.

So it has to be written as:

sbi = new SuperBlock;
/* The rest of code assumes that the sbi pointer is valid. If this was not the 
case, let's hope that the caller caught std::bad_alloc properly */

-- 
Alexander E. Patrakov

Re: C++ pushback

[Willy Tarreau]

On Mon, Apr 24, 2006 at 10:52:12PM +0100, Alan Cox wrote:
> On Llu, 2006-04-24 at 15:36 -0600, Jeff V. Merkey wrote:
> > C++ in the kernel is a BAD IDEA. C++ code can be written in such a 
> > convoluted manner as to be unmaintainable and unreadable.
> 
> So can C. 
> 
> > All of the hidden memory allocations from constructor/destructor 
> > operatings can and do KILL OS PERFORMANCE. 
> 
> This is one area of concern. Just as big a problem for the OS case is
> that the hidden constructors/destructors may fail. You can write C++
> code carefully to avoid these things but it can be hard to see where the
> problem is when you miss one.

Not counting the compiler bugs. When you see how the kernel tends to
trigger gcc bugs on which people spend a lot of time, I wouldn't want
to be the guy trying to identify bad code generation in C++...

Cheers,
Willy

Re: C++ pushback

[Jeff V. Merkey]

Alan Cox wrote:

>On Llu, 2006-04-24 at 15:36 -0600, Jeff V. Merkey wrote:
>  
>
>>C++ in the kernel is a BAD IDEA. C++ code can be written in such a 
>>convoluted manner as to be unmaintainable and unreadable.
>>    
>>
>
>So can C. 
>
>  
>
>>All of the hidden memory allocations from constructor/destructor 
>>operatings can and do KILL OS PERFORMANCE. 
>>    
>>
>
>This is one area of concern. Just as big a problem for the OS case is
>that the hidden constructors/destructors may fail. You can write C++
>code carefully to avoid these things but it can be hard to see where the
>problem is when you miss one.
>
>C at least makes it verbose, but we trade that for poorer typechecking
>and visibility control.
>
>Alan
>  
>

Yep.

Jeff

>-
>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: C++ pushback

[David Schwartz]

> Can you name any reasons for why should we support C++ in the kernel?
> Why shouldn't we invest the effort to making it possible to write kernel
> modules in Haskell instead?

	I don't recall anyone asking you to so much as lift a finger. Feel free to
invest your effort where you feel it will do the most good, and try not to
criticize others for doing the same with their own resources.

	DS

Re: C++ pushback

[Martin Mares]

> 	I don't recall anyone asking you to so much as lift a finger. Feel free to
> invest your effort where you feel it will do the most good, and try not to
> criticize others for doing the same with their own resources.

As far as they intend to stay away from the main kernel tree, I don't
critize anybody. But for example renaming otherwise logically named structure
members (`class' etc.) just for C++ compatibility _IS_ wasting time of
other people, who need to remember new names, review the patch and so on.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
If at first you don't succeed, redefine success.

Re: C++ pushback

[Jan Engelhardt]

>> 	I don't recall anyone asking you to so much as lift a finger. Feel free to
>> invest your effort where you feel it will do the most good, and try not to
>> criticize others for doing the same with their own resources.
>
>As far as they intend to stay away from the main kernel tree, I don't
>critize anybody. But for example renaming otherwise logically named structure
>members (`class' etc.) just for C++ compatibility _IS_ wasting time of
>other people, who need to remember new names, review the patch and so on.
>
That said, VMware does use C++ in its kernel modules at one point. So, it 
is possible to some degree with enough effort. Of the
C++ kernel module writer, that is!


Jan Engelhardt
-- 

RE: C++ pushback

[David Schwartz]

> > I don't recall anyone asking you to so much as lift a
> > finger. Feel free to
> > invest your effort where you feel it will do the most good, and
> > try not to
> > criticize others for doing the same with their own resources.

> As far as they intend to stay away from the main kernel tree, I don't
> critize anybody. But for example renaming otherwise logically
> named structure
> members (`class' etc.) just for C++ compatibility _IS_ wasting time of
> other people, who need to remember new names, review the patch and so on.

	Hahaha. So now, it's not good enough that they not ask you to do anything,
they have to actively *prevent* you from choosing to waste time on their
changes?

	DS

Re: C++ pushback

[Martin Mares]

> 	Hahaha. So now, it's not good enough that they not ask you to do anything,
> they have to actively *prevent* you from choosing to waste time on their
> changes?

If you wish to interpret it that way, I won't prevent you :-)

Anyway -- what I meant is that even if somebody writes a patch changing
names to avoid collisions with C++, _merging_ such a patch could be
easily a waste of other people's time, especially when there is no
other advantage in merging such a patch (like if the reason is that
somebody wishes to port his closed-source driver to Linux [*]).

[*]: Not that I'm claiming that this is the case now, but it already
happened.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
First law of socio-genetics: Celibacy is not hereditary.

RE: C++ pushback

[David Schwartz]

> > Hahaha. So now, it's not good enough that they not ask you
> > to do anything,
> > they have to actively *prevent* you from choosing to waste time on their
> > changes?

> If you wish to interpret it that way, I won't prevent you :-)

> Anyway -- what I meant is that even if somebody writes a patch changing
> names to avoid collisions with C++, _merging_ such a patch could be
> easily a waste of other people's time, especially when there is no
> other advantage in merging such a patch (like if the reason is that
> somebody wishes to port his closed-source driver to Linux [*]).

> [*]: Not that I'm claiming that this is the case now, but it already
> happened.

	You are being ambiguous here, possibly deliberately possibly through honest
confusion and possibly because you know what you're saying and can't imagine
how anyone else could not understand you. For example, does "merging" mean
the process of making the kernel continue to compile cleanly with the patch
applied? Or does "merging" mean the effort in maintaining your current level
of understanding and proficiency with the kernel once the patch is in the
mainline?

	If the former, you are totally correct. Nobody should work on merging a
patch they don't believe in. If the latter, then see my criticism.

	You originally said:

>>> As far as they intend to stay away from the main kernel tree, I don't
>>> critize anybody. But for example renaming otherwise logically
>>> named structure
>>> members (`class' etc.) just for C++ compatibility _IS_ wasting time of
>>> other people, who need to remember new names, review the patch and so
on.

	If you don't believe the patch will benefit anyone, the review shouldn't
take you more than a second or two. You should definitely say "I don't
believe in this patch, I don't like C++ in the kernel, my review is that it
should not go in" and that's it. Nobody is forcing you to work to adopt
changes you don't believe in, and you should *not* do so as your part in
keeping kernel code quality high.

	As for remembering new names, that's a load of complete crap and I find it
hard to believe that you're raising the argument for honest reasons.

	DS

RE: C++ pushback

[Matthew Frost]

--- David Schwartz <davids@webmaster.com> wrote:

> 
> > > Hahaha. So now, it's not good enough that they not ask you
> > > to do anything,
> > > they have to actively *prevent* you from choosing to waste time on
> their
> > > changes?
> 
> > If you wish to interpret it that way, I won't prevent you :-)
> 
> > Anyway -- what I meant is that even if somebody writes a patch
> changing
> > names to avoid collisions with C++, _merging_ such a patch could be
> > easily a waste of other people's time, especially when there is no
> > other advantage in merging such a patch (like if the reason is that
> > somebody wishes to port his closed-source driver to Linux [*]).
> 
> > [*]: Not that I'm claiming that this is the case now, but it already
> > happened.
> 
> 	You are being ambiguous here, possibly deliberately possibly 
> through honest confusion and possibly because you know what you're 
> saying and can't imagine how anyone else could not understand you. For 
> example, does "merging" mean the process of making the kernel continue 
> to compile cleanly with the patch applied? Or does "merging" mean the 
> effort in maintaining your current level of understanding and 
> proficiency with the kernel once the patch is in the mainline?
> 

How long have you been paying attention here?  0) You're pushing a
non-starter, rudely, and ignoring the pushback, and 1) you don't know how
 patches get merged into mainline.

Merging does involve pretty much all of that.  In consideration of a
patch or patch set for merging, its benefit to the kernel, compliance
with coding standards for the kernel, ease of maintenance of the whole
kernel by a vast, far-flung community of developers after the patch goes
in, the quality of the code, and how nicely its author plays with others
are taken into account.  Patches become part of the kernel.  Patches
belong to everybody once they're accepted, and they have to be workable
for anybody that might have to touch the systems they modify.  If you
rename vast parts of the kernel for no reason other than your wish to
have C++ work in it, you screw up everybody.  Naming is important.

> 	If the former, you are totally correct. Nobody should work on 
> merging a patch they don't believe in. If the latter, then see my 
> criticism.

It isn't about belief.  It's about code.  In point of fact, it isn't even
about you until you become such an irritant that your personality makes
people shy away from your patches.  It is about working well in the
pre-existing structure.  Minimal, focused changes that achieve one goal
per patch, that can be proven useful.

> 
> 	You originally said:
> 
>> As far as they intend to stay away from the main kernel tree, I
>> don't critize anybody. But for example renaming otherwise logically
>> named structure members (`class' etc.) just for C++ compatibility _IS_
>> wasting time of other people, who need to remember new names, review 
>> the patch and so on.
> 
> 	If you don't believe the patch will benefit anyone, the review
> shouldn't take you more than a second or two. You should definitely say
> "I don't believe in this patch, I don't like C++ in the kernel, my 
> review is that it should not go in" and that's it. Nobody is forcing
you
> to work to adopt changes you don't believe in, and you should *not* do 
> so as your part in keeping kernel code quality high.

You are partially correct.  Nobody forces anybody to review or accept a
patch that they believe is in bad taste, or is malformed, or will do Bad
Things to the kernel.  You may, at your discretion, submit all of the
patches you wish to this list, or to Linus, or to Andrew, or anyone you
like.  Should they be for the purpose of converting functioning kernel C
into what you think ought to be functional C++, I can practically
guarantee they will go absolutely nowhere.  

$ cat convert_kernel_to_c++.patch >/dev/null 

would be faster.  You may think of it as pearls before swine if it makes
you feel better, but the kernel devs are being rational.

> 
> 	As for remembering new names, that's a load of complete crap and I
> find it hard to believe that you're raising the argument for honest 
> reasons.
> 

The scale of the kernel, the number and churn of developers, and the
importance of not breaking things in a stable kernel tend to argue
against you.  Humans develop the kernel.  Humans remember names well. 
You may think that's arbitrary, but when you change naming across the
entire kernel, you confuse a very large and diverse group of people who
do this because they enjoy it.  It's hard enough when this has to happen
for useful or necessary reasons; you're asking the kernel developers to
accept it for a completely arbitrary whim that they have rejected
successfully several times in the past.  You want C++?  Fork the freely
available source code at a convenient point and convert it yourself.  As
long as it stays GPL, you're perfectly within your rights so to do. 
Hobson's choice is yours.  Belaboring this point is silly.

MAF


> 	DS
> 
> 
> -
> 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: C++ pushback

[David Schwartz]

> > 	As for remembering new names, that's a load of complete crap and I
> > find it hard to believe that you're raising the argument for honest
> > reasons.

> The scale of the kernel, the number and churn of developers, and the
> importance of not breaking things in a stable kernel tend to argue
> against you.  Humans develop the kernel.  Humans remember names well.
> You may think that's arbitrary, but when you change naming across the
> entire kernel, you confuse a very large and diverse group of people who
> do this because they enjoy it.  It's hard enough when this has to happen
> for useful or necessary reasons; you're asking the kernel developers to
> accept it for a completely arbitrary whim that they have rejected
> successfully several times in the past.

	C++ has how many additional reserved words? I believe the list is delete,
friend, private, protected, public, template, throw, try, and catch.
Renaming every symbol that currently has a name from this list to the
corresponding name with a trailing underscore is an easily understood
consistent change.

	That you would argue against is with things like "not breaking things" is a
load of complete crap.

> You want C++?  Fork the freely
> available source code at a convenient point and convert it yourself.  As
> long as it stays GPL, you're perfectly within your rights so to do.
> Hobson's choice is yours.  Belaboring this point is silly.

	Making ridiculous arguments like that a consistent change of a small set of
names is "breaking things in a stable kernel" is silly.

	And, FWIW, it isn't even necessary to change those names. That is only
needed to compile the kernel in C++, which is not what anyone was talking
about. Supporting C++ modules, for example, would work fine even if the
kernel had variables called 'class' or 'private'. (Though things could be
done a lot more cleanly if it didn't as it would require some remapping
before and after compilation.)

	DS

Re: C++ pushback

[Jan-Benedict Glaw]

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

On Wed, 2006-04-26 12:25:19 -0700, David Schwartz <davids@webmaster.com> wrote:
[Variable names that are reserved in C++]
> 	And, FWIW, it isn't even necessary to change those names. That is only
> needed to compile the kernel in C++, which is not what anyone was talking
> about. Supporting C++ modules, for example, would work fine even if the
> kernel had variables called 'class' or 'private'. (Though things could be
> done a lot more cleanly if it didn't as it would require some remapping
> before and after compilation.)

There's one _practical_ thing you need to keep in mind: you'll either
need 'C++'-clean kernel headers (to interface low-level kernel
functions) or a separate set of headers.

For separate headers, I see the problem of keeping them synchronized
with the kernel. The clean-up-kernel-headers-for-userspce-consumption
guys already took that bullet once and up to now, there's no "real"
result. (That's while we all know that kernel values *are* somewhat
for the userspace guys:-)  I see an even smaller user-base for
separate C++ kernel headers (and thus more work per person)--and I
think that the current in-kernel headers just won't be C++ compatible,
ever[*].

MfG, JBG
[*] Famous last words...

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

Re: C++ pushback

[Linus Torvalds]

On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote:
> 
> There's one _practical_ thing you need to keep in mind: you'll either
> need 'C++'-clean kernel headers (to interface low-level kernel
> functions) or a separate set of headers.

I suspect it would be easier to just do

	extern "C" {
	#include <linux/xyz.h>
	...
	}

instead of having anything really C++'aware in the headers.

If by "clean" you meant that the above works, then yeah, there might be 
_some_ cases where we use C++ keywords etc in the headers, but they should 
be pretty unusual and easy to fix.

The real problem with C++ for kernel modules is:

 - the language just sucks. Sorry, but it does.
 - some of the C features we use may or may not be usable from C++ 
   (statement expressions?)
 - the compilers are slower, and less reliable. This is _less_ of an issue 
   these days than it used to be (at least the reliability part), but it's 
   still true.
 - a lot of the C++ features just won't be supported sanely (ie the kernel 
   infrastructure just doesn't do exceptions for C++, nor will it run any 
   static constructors etc).

Anyway, it should all be doable. Not necessarily even very hard. But I 
doubt it's worth it.

		Linus

Re: C++ pushback

[Al Viro]

On Wed, Apr 26, 2006 at 01:09:38PM -0700, Linus Torvalds wrote:
> The real problem with C++ for kernel modules is:
> 
>  - the language just sucks. Sorry, but it does.
>  - some of the C features we use may or may not be usable from C++ 
>    (statement expressions?)
>  - the compilers are slower, and less reliable. This is _less_ of an issue 
>    these days than it used to be (at least the reliability part), but it's 
>    still true.
>  - a lot of the C++ features just won't be supported sanely (ie the kernel 
>    infrastructure just doesn't do exceptions for C++, nor will it run any 
>    static constructors etc).

   - a lot of C++ advocates agree that some subset could be used sanely,
     but there's no agreement as to _which_ subset would that be.

Re: C++ pushback

[Sam Ravnborg]

On Wed, Apr 26, 2006 at 09:19:09PM +0100, Al Viro wrote:
> On Wed, Apr 26, 2006 at 01:09:38PM -0700, Linus Torvalds wrote:
> > The real problem with C++ for kernel modules is:
> > 
> >  - the language just sucks. Sorry, but it does.
> >  - some of the C features we use may or may not be usable from C++ 
> >    (statement expressions?)
> >  - the compilers are slower, and less reliable. This is _less_ of an issue 
> >    these days than it used to be (at least the reliability part), but it's 
> >    still true.
> >  - a lot of the C++ features just won't be supported sanely (ie the kernel 
> >    infrastructure just doesn't do exceptions for C++, nor will it run any 
> >    static constructors etc).
> 
>    - a lot of C++ advocates agree that some subset could be used sanely,
>      but there's no agreement as to _which_ subset would that be.
The original question was related to port existing C++ code to be used
as a kernel module.
Magically this always ends up in long discussions about how applicable
C++ is the the kernel as such which was not the original intent.

So following the original intent it does not matter what subset is
sanely used, only what adaptions is needed to kernel proper to support
modules written in C++.

But I have seen no patches this time either, so required modifications
are yet to be identified.

	Sam

Re: C++ pushback

[Avi Kivity]

Sam Ravnborg wrote:
> The original question was related to port existing C++ code to be used
> as a kernel module.
> Magically this always ends up in long discussions about how applicable
> C++ is the the kernel as such which was not the original intent.
>
> So following the original intent it does not matter what subset is
> sanely used, only what adaptions is needed to kernel proper to support
> modules written in C++.
>
>   

Here at last is a sane response. If the kernel were enhanced/bastardized 
(pick one) to support C++ modules, we could evaluate how C++ actually 
does in terms of runtime and developer performance.

> But I have seen no patches this time either, so required modifications
> are yet to be identified.
>   

Since such patches are sure to be rejected (apparently renaming 'struct 
class' would wreak havoc on the development process), I doubt that they 
will appear. Not to mention the attacks on the submitters that would follow.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: C++ pushback

[linux-os (Dick Johnson)]

On Fri, 28 Apr 2006, Avi Kivity wrote:

> Sam Ravnborg wrote:
>> The original question was related to port existing C++ code to be used
>> as a kernel module.
>> Magically this always ends up in long discussions about how applicable
>> C++ is the the kernel as such which was not the original intent.
>>
>> So following the original intent it does not matter what subset is
>> sanely used, only what adaptions is needed to kernel proper to support
>> modules written in C++.
>>
>>
>
> Here at last is a sane response. If the kernel were enhanced/bastardized
> (pick one) to support C++ modules, we could evaluate how C++ actually
> does in terms of runtime and developer performance.
>
>> But I have seen no patches this time either, so required modifications
>> are yet to be identified.
>>
>
> Since such patches are sure to be rejected (apparently renaming 'struct
> class' would wreak havoc on the development process), I doubt that they
> will appear. Not to mention the attacks on the submitters that would follow.
>

I'm fairly sure that if header structure members were renamed (one
patch at a time), and were renamed sanely (like struct class should not
be renamed to struct TheyDidntKnowAnything)... and sanely also means
trying to have the same length like (struct klass)...and if every file
that included those headers were updated.... I think the patches would
not be rejected, especially if Linus said, "Let's get rid of the
C++ keywords."

It is well known that in a few years you won't be able to find a 'C'
compiler or C++ for that matter. Everything will be written in Z##
or whatever. The problem I see is that newcomers, who have only
learned one language, assume that they have some special enlightenment
and that 'C' is wrong. Simple changes that let these newcomers experiment,
perhaps finding the errors of their ways, as long as they are not
harmful, should not be discouraged.

Maybe it's fork time, but maybe not. There seem to be very few C++
keywords being used although, where they are used, affect many files.
If it was my ballgame, I'd let the C++ advocates submit patches to
remove those keywords. Then, after they get their first module
to load, they will learn the errors of their ways as they find
that there isn't enough RAM available to do any useful work. But,
at least the "bad" words will have been removed from the headers
by highly motivated programmers. The cost is zero.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.lymanschool.com
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: C++ pushback

[Jan-Benedict Glaw]

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

On Fri, 2006-04-28 08:00:17 -0400, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
> I'm fairly sure that if header structure members were renamed (one
> patch at a time), and were renamed sanely (like struct class should not
> be renamed to struct TheyDidntKnowAnything)... and sanely also means
> trying to have the same length like (struct klass)...and if every file

*cough* This is the Linux Kernel, not a KDE application...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

Re: C++ pushback

[Jan-Benedict Glaw]

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

On Wed, 2006-04-26 13:09:38 -0700, Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote:
> > There's one _practical_ thing you need to keep in mind: you'll either
> > need 'C++'-clean kernel headers (to interface low-level kernel
> > functions) or a separate set of headers.
> 
> I suspect it would be easier to just do
> 
> 	extern "C" {
> 	#include <linux/xyz.h>
> 	...
> 	}
> 
> instead of having anything really C++'aware in the headers.

...but you need to admit that your left hand tried to make your right
hand not typing this, didn't it?

>  - the language just sucks. Sorry, but it does.
>  - some of the C features we use may or may not be usable from C++ 
>    (statement expressions?)

In the constructor pathes, I expect higher stack usage than we now
have.

>  - a lot of the C++ features just won't be supported sanely (ie the kernel 
>    infrastructure just doesn't do exceptions for C++, nor will it run any 
>    static constructors etc).

So what actually can be made useable (and what actually makes sense):

  * Classes with public and private funct^Wmembers, constructors.
  * Namespaces? Don't think they're all _that_ useful for us.
  * Static constructors probably won't fly.

> Anyway, it should all be doable. Not necessarily even very hard. But I 
> doubt it's worth it.

I guess if somebody has a large portion of well-separated C++ code
(eg. a complete and complex filesystem), it would be easier to write
some glue code to "run" the C++ code with the kernel.

Though it would be even easier to use FUSE's bindings:-)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

RE: C++ pushback

[David Schwartz]

Linus wrote:

> On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote:

> > There's one _practical_ thing you need to keep in mind: you'll either
> > need 'C++'-clean kernel headers (to interface low-level kernel
> > functions) or a separate set of headers.

> I suspect it would be easier to just do
>
> 	extern "C" {
> 	#include <linux/xyz.h>
> 	...
> 	}

> instead of having anything really C++'aware in the headers.

	I agree. This could include things like:

#define class class_

	You'd need two includes, one that goes first and one that goes last (to
undefine these things). Yeah, it's ugly, but it imposes the minimum cost on
those who don't care.

> If by "clean" you meant that the above works, then yeah, there might be
> _some_ cases where we use C++ keywords etc in the headers, but
> they should
> be pretty unusual and easy to fix.

	They can be fixed ugly ways or nice ways, depending on a cost/benefit
analysis.

> The real problem with C++ for kernel modules is:
>
>  - the language just sucks. Sorry, but it does.
>  - some of the C features we use may or may not be usable from C++
>    (statement expressions?)
>  - the compilers are slower, and less reliable. This is _less_ of
> an issue
>    these days than it used to be (at least the reliability part),
> but it's
>    still true.
>  - a lot of the C++ features just won't be supported sanely (ie
> the kernel
>    infrastructure just doesn't do exceptions for C++, nor will it run any
>    static constructors etc).

	I would phrase the argument as such: any project that can really benefit
from what C++ adds to C is probably too big and complex to belong in the
kernel. Better to do what you need to get it out of the kernel.

	A better project might be some compromise between kernel space and user
space that doesn't abuse the kernel stack and where things like exceptions
can be supported.

> Anyway, it should all be doable. Not necessarily even very hard. But I
> doubt it's worth it.

	If FUSE made it so that you could just as well put a filesystem in user
space as kernel space, I'd agree with you. File systems are the only kernel
drivers I can think of that can justify sufficient complexity to get much
benefit from C++. This may change though, and this could just be a lack of
imagination on my part.

	By the way, I am not a proponent of C++ in the kernel or of making changes
to the kernel to support C++. I'm just someone who labels bullshit as such
when he sees it.

	DS

Re: C++ pushback

[Roman Kononov]

Linus Torvalds wrote:
> 
> On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote:
>> There's one _practical_ thing you need to keep in mind: you'll either
>> need 'C++'-clean kernel headers (to interface low-level kernel
>> functions) or a separate set of headers.
> 
> I suspect it would be easier to just do
> 
> 	extern "C" {
> 	#include <linux/xyz.h>
> 	...
> 	}
> 
> instead of having anything really C++'aware in the headers.
> 
> If by "clean" you meant that the above works, then yeah, there might be 
> _some_ cases where we use C++ keywords etc in the headers, but they should 
> be pretty unusual and easy to fix.
> 
> The real problem with C++ for kernel modules is:
> 
>  - the language just sucks. Sorry, but it does.
Sorry, you do not know the language, and your statement is not 
credible. I think that C sucks.

>  - some of the C features we use may or may not be usable from C++ 
>    (statement expressions?)
Statement expressions are working fine in g++. The main difficulties are:
    - GCC's structure member initialization extensions are syntax
      errors in G++: struct foo_t foo={.member=0};
    - empty structures are not zero-sized in g++, unless they are like
      this one: struct really_empty_t { char dummy[0]; };

>  - the compilers are slower, and less reliable. This is _less_ of an issue 
>    these days than it used to be (at least the reliability part), but it's 
>    still true.
G++ compiling heavy C++ is a bit slower than gcc. The g++ front end is 
reliable enough. Do you have a particular bug in mind?

>  - a lot of the C++ features just won't be supported sanely (ie the kernel 
>    infrastructure just doesn't do exceptions for C++, nor will it run any 
>    static constructors etc).
A lot of C++ features are already supported sanely. You simply need to 
understand them. Especially templates and type checking. C++ 
exceptions are not very useful tool in kernels. Static constructor 
issue is trivial. I use all C++ features (except exceptions) in all 
projects: Linux kernel modules, embedded real-time applications, 
everywhere. They _really_ help a lot.

>
> Anyway, it should all be doable. Not necessarily even very hard. But I 
> doubt it's worth it.
> 
> 		Linus

I think that allowing C++ code to co-exist with the kernel would be a 
step forward.

Re: C++ pushback

[Kyle Moffett]

On Apr 26, 2006, at 19:00:52, Roman Kononov wrote:
> Linus Torvalds wrote:
>>  - some of the C features we use may or may not be usable from C+ 
>> +    (statement expressions?)
>
> Statement expressions are working fine in g++. The main  
> difficulties are:
>    - GCC's structure member initialization extensions are syntax
>      errors in G++: struct foo_t foo={.member=0};

And that breaks a _massive_ amount of kernel code, including such  
core functionality like SPIN_LOCK_UNLOCKED and a host of others.   
There are all sorts of macros that use member initialization of that  
form.


>    - empty structures are not zero-sized in g++, unless they are like
>      this one: struct really_empty_t { char dummy[0]; };

And that provides yet more ways to break binary compatibility.  Not  
to mention the fact that it appears to change other aspects of the  
way structs are packed.  Since the kernel uses a lot of data  
structures to strictly define binary formats for transmission to  
hardware, across a network, or to userspace, such changes can cause  
nothing but heartache.


>>  - the compilers are slower, and less reliable. This is _less_ of  
>> an issue    these days than it used to be (at least the  
>> reliability part), but it's still true.
>
> G++ compiling heavy C++ is a bit slower than gcc. The g++ front end  
> is reliable enough. Do you have a particular bug in mind?

A lot of people would consider the "significantly slower" to be a  
major bug.  Many people moaned when the kernel stopped supporting GCC  
2.x because that compiler was much faster than modern C compilers.   
I've seen up to a 3x slowdown when compiling the same files with g++  
instead of gcc, and such would be unacceptable to a _lot_ of people  
on this list.


>>  - a lot of the C++ features just won't be supported sanely (ie  
>> the kernel    infrastructure just doesn't do exceptions for C++,  
>> nor will it run any    static constructors etc).
>
> A lot of C++ features are already supported sanely. You simply need  
> to understand them. Especially templates and type checking.

First of all, the only way to sanely use templated classes is to  
write them completely inline, which causes massive bloat.  Look at  
the kernel "struct list_head" and show me the "type-safe C++" way to  
do that.  It uses a templated inline class, right?  That templated  
inline class gets duplicated for each different type of object put in  
a linked list, no?  Think about how many linked lists we have in the  
kernel and tell me why that would be a good thing.


> Static constructor issue is trivial.

How so?  When do you want the static constructors to be run?  There  
are many different major stages of kernel-level initialization;  
picking one is likely to make them useless for other code.

Cheers,
Kyle Moffett

Re: C++ pushback

[Roman Kononov]

Kyle Moffett wrote:
> On Apr 26, 2006, at 19:00:52, Roman Kononov wrote:
>> Linus Torvalds wrote:
>>>  - some of the C features we use may or may not be usable from C++    
>>> (statement expressions?)
>>
>> Statement expressions are working fine in g++. The main difficulties are:
>>    - GCC's structure member initialization extensions are syntax
>>      errors in G++: struct foo_t foo={.member=0};
> 
> And that breaks a _massive_ amount of kernel code, including such core 
> functionality like SPIN_LOCK_UNLOCKED and a host of others.  There are 
> all sorts of macros that use member initialization of that form.
This does not break the code at run time, this breaks the code at 
compile time, and should be less painful.

>>    - empty structures are not zero-sized in g++, unless they are like
>>      this one: struct really_empty_t { char dummy[0]; };
> 
> And that provides yet more ways to break binary compatibility.  Not to 
> mention the fact that it appears to change other aspects of the way 
> structs are packed.  Since the kernel uses a lot of data structures to 
> strictly define binary formats for transmission to hardware, across a 
> network, or to userspace, such changes can cause nothing but heartache.
This breaks the code at run time and is the _real_ pain to think 
about. As for packing for network and hardware - not an issue at all. 
The difference between gcc and g++ is _only_ in empty structures.

>>>  - the compilers are slower, and less reliable. This is _less_ of an 
>>> issue    these days than it used to be (at least the reliability 
>>> part), but it's still true.
>>
>> G++ compiling heavy C++ is a bit slower than gcc. The g++ front end is 
>> reliable enough. Do you have a particular bug in mind?
> 
> A lot of people would consider the "significantly slower" to be a major 
> bug.  Many people moaned when the kernel stopped supporting GCC 2.x 
> because that compiler was much faster than modern C compilers.  I've 
> seen up to a 3x slowdown when compiling the same files with g++ instead 
> of gcc, and such would be unacceptable to a _lot_ of people on this list.
I agree, it would be a bad idea to compile the existing C code by g++. 
  The good idea is to be able to produce new C++ modules etc.

>>>  - a lot of the C++ features just won't be supported sanely (ie the 
>>> kernel    infrastructure just doesn't do exceptions for C++, nor will 
>>> it run any    static constructors etc).
>>
>> A lot of C++ features are already supported sanely. You simply need to 
>> understand them. Especially templates and type checking.
> 
> First of all, the only way to sanely use templated classes is to write 
> them completely inline, which causes massive bloat.  Look at the kernel 
> "struct list_head" and show me the "type-safe C++" way to do that.  It 
> uses a templated inline class, right?  That templated inline class gets 
> duplicated for each different type of object put in a linked list, no?  
> Think about how many linked lists we have in the kernel and tell me why 
> that would be a good thing.
You mentioned a bad example. The struct list_head has [almost?] all 
"members" inlined. If they were not, one could simply make a base 
class having [some] members outlined, and which class does not enforce 
type safety and is for inheritance only. The template class would then 
inherit the base one enforcing type safety by having inline members. 
This technique is well known, trust me. If you need real life 
examples, tell me.

>> Static constructor issue is trivial.
> 
> How so?  When do you want the static constructors to be run?  There are 
> many different major stages of kernel-level initialization; picking one 
> is likely to make them useless for other code.
For modules there are #defines module_init() and module_exit(). These 
are the natural places for the constructors and destructors.

For #defines core_initcall() ... late_initcall() I would type 
something like this:
	class foo_t { foo_t(); ~foo_t(); }
	static char foo_storage[sizeof(foo_t)];
	static foo_t& foo=*reinterpret_cast<foo_t*>(foo_storage);
	static void __init foo_init() { new(foo_storage) foo_t; }
	core_initcall(foo_init);
This ugly-looking code can be nicely wrapped into a template, which, 
depending on the type (foo_t in this case), at compile time, picks the 
proper stage for initialization.

Regards,
Roman

Re: C++ pushback

[Kyle Moffett]

On Apr 26, 2006, at 22:05:31, Roman Kononov wrote:
> Kyle Moffett wrote:
>> On Apr 26, 2006, at 19:00:52, Roman Kononov wrote:
>>> Linus Torvalds wrote:
>>>>  - some of the C features we use may or may not be usable from C+ 
>>>> +    (statement expressions?)
>>>
>>> Statement expressions are working fine in g++. The main  
>>> difficulties are:
>>>    - GCC's structure member initialization extensions are syntax
>>>      errors in G++: struct foo_t foo={.member=0};
>>
>> And that breaks a _massive_ amount of kernel code, including such  
>> core functionality like SPIN_LOCK_UNLOCKED and a host of others.   
>> There are all sorts of macros that use member initialization of  
>> that form.
>
> This does not break the code at run time, this breaks the code at  
> compile time, and should be less painful.

So breaking 90% of the source code at compile time is ok?  I think  
not.  The kernel relies really _really_ heavily on such structure  
initializers, and breaking them would effectively break the world as  
far as the kernel is concerned.


>>> G++ compiling heavy C++ is a bit slower than gcc. The g++ front  
>>> end is reliable enough. Do you have a particular bug in mind?
>>
>> A lot of people would consider the "significantly slower" to be a  
>> major bug.  Many people moaned when the kernel stopped supporting  
>> GCC 2.x because that compiler was much faster than modern C  
>> compilers.  I've seen up to a 3x slowdown when compiling the same  
>> files with g++ instead of gcc, and such would be unacceptable to a  
>> _lot_ of people on this list.
>
> I agree, it would be a bad idea to compile the existing C code by g+ 
> +.  The good idea is to be able to produce new C++ modules etc.

No, this is a reason why C++ modules are _not_ a good idea.  If you  
could write the module in C or C++, but in C++ it compiled 100-200%  
slower, then you would write it in C.  Why?  A simple matter of numbers:

Say it takes you 100 hours to write and debug the module in C++, and  
140 to write and debug it in C.  I estimate that at least 200,000  
people would download and compile a single version of the kernel with  
your module (not an unreasonable estimate).  Note that I'm not even  
including the people who do repeated regression testing of versions,  
or people who download and compile multiple versions of the kernel.    
If the source file takes an average of 1.0 seconds to compile in C  
and 2.0 seconds to compile in C++, then:

(2.0 sec - 1.0 sec) * 200,000 = 200,000 seconds = 55.6 hours
140 hours - 100 hours = 40 hours
40 hours < 55.6 hours

So for a single version of the kernel your module, you've already  
wasted 15.6 hours of time across people using it.  Over time that  
number is just going to grow, _especially_ if people start writing  
more and more modules in C++ because they can.  If you want to build C 
++ in the kernel, write a compiler that does not include all the  
problematic C++ features that add so much parsing time (overloaded  
operators, etc).


>>> A lot of C++ features are already supported sanely. You simply  
>>> need to understand them. Especially templates and type checking.
>>
>> First of all, the only way to sanely use templated classes is to  
>> write them completely inline, which causes massive bloat.  Look at  
>> the kernel "struct list_head" and show me the "type-safe C++" way  
>> to do that.  It uses a templated inline class, right?  That  
>> templated inline class gets duplicated for each different type of  
>> object put in a linked list, no?  Think about how many linked  
>> lists we have in the kernel and tell me why that would be a good  
>> thing.
>
> You mentioned a bad example. The struct list_head has [almost?] all  
> "members" inlined. If they were not, one could simply make a base  
> class having [some] members outlined, and which class does not  
> enforce type safety and is for inheritance only.  The template  
> class would then inherit the base one enforcing type safety by  
> having inline members. This technique is well known, trust me. If  
> you need real life examples, tell me.

Ok, help me understand here:  Instead of helping using one sensible  
data structure and generating optimized code for that, the language  
actively _encourages_ you to duplicate classes and interfaces,  
providing even _more_ work for the compiler, making the code harder  
to debug, and probably introducing inefficiencies as well.  If C++  
doesn't work properly for a simple and clean example like struct  
list_head, why should we assume that it's going to work any better  
for more complicated examples in the rest of the kernel?  Whether or  
not some arbitrary function is inlined should be totally orthogonal  
to adding type-checking.

>>> Static constructor issue is trivial.
>>
>> How so?  When do you want the static constructors to be run?   
>> There are many different major stages of kernel-level  
>> initialization; picking one is likely to make them useless for  
>> other code.
>
> For #defines core_initcall() ... late_initcall() I would type  
> something like this:
> 	class foo_t { foo_t(); ~foo_t(); }
> 	static char foo_storage[sizeof(foo_t)];
> 	static foo_t& foo=*reinterpret_cast<foo_t*>(foo_storage);
> 	static void __init foo_init() { new(foo_storage) foo_t; }
> 	core_initcall(foo_init);
>
> This ugly-looking code can be nicely wrapped into a template,  
> which, depending on the type (foo_t in this case), at compile time,  
> picks the proper stage for initialization.

You proved my point.  Static constructors can't work.  You can add  
silly wrapper initcall functions which create objects in static  
memory at various times, but the language-defined static constructors  
are yet another C++ feature that doesn't work by default and has to  
be hacked around.  C++ gives us no advantage over C here either.   
Plus this would break things like static spinlock initialization.   
How would you make this work sanely for this static declaration:

spinlock_t foo_lock = SPIN_LOCK_UNLOCKED;

Under C that turns into (depending on config options):

spinlock_t foo_lock = { .value = 0, .owner = NULL, (...) };

How could that possibly work in C++ given what you've said?  Anything  
that breaks code that simple is an automatic nonstarter for the  
kernel.  Also remember that spinlocks are defined preinitialized at  
the very earliest stages of init.  Of course I probably don't have to  
say that anything that tries to run a function to iterate over all  
statically-allocated spinlocks during init would be rejected out of  
hand.

Cheers,
Kyle Moffett

Re: C++ pushback

[Roman Kononov]

Kyle Moffett wrote:
> On Apr 26, 2006, at 22:05:31, Roman Kononov wrote:
>> Kyle Moffett wrote:
>>> On Apr 26, 2006, at 19:00:52, Roman Kononov wrote:
>>>> Linus Torvalds wrote:
>>>>>  - some of the C features we use may or may not be usable from 
>>>>> C++    (statement expressions?)
>>>>
>>>> Statement expressions are working fine in g++. The main difficulties 
>>>> are:
>>>>    - GCC's structure member initialization extensions are syntax
>>>>      errors in G++: struct foo_t foo={.member=0};
>>>
>>> And that breaks a _massive_ amount of kernel code, including such 
>>> core functionality like SPIN_LOCK_UNLOCKED and a host of others.  
>>> There are all sorts of macros that use member initialization of that 
>>> form.
>>
>> This does not break the code at run time, this breaks the code at 
>> compile time, and should be less painful.
> 
> So breaking 90% of the source code at compile time is ok?  I think not.  
> The kernel relies really _really_ heavily on such structure 
> initializers, and breaking them would effectively break the world as far 
> as the kernel is concerned.

I agree: do not break code, fix it. Make it more robust language-wise.

>>>> G++ compiling heavy C++ is a bit slower than gcc. The g++ front end 
>>>> is reliable enough. Do you have a particular bug in mind?
>>>
>>> A lot of people would consider the "significantly slower" to be a 
>>> major bug.  Many people moaned when the kernel stopped supporting GCC 
>>> 2.x because that compiler was much faster than modern C compilers.  
>>> I've seen up to a 3x slowdown when compiling the same files with g++ 
>>> instead of gcc, and such would be unacceptable to a _lot_ of people 
>>> on this list.
>>
>> I agree, it would be a bad idea to compile the existing C code by 
>> g++.  The good idea is to be able to produce new C++ modules etc.
> 
> No, this is a reason why C++ modules are _not_ a good idea.  If you 
> could write the module in C or C++, but in C++ it compiled 100-200% 
> slower, then you would write it in C.  Why?  A simple matter of numbers:
> 
> Say it takes you 100 hours to write and debug the module in C++, and 140 
> to write and debug it in C.  I estimate that at least 200,000 people 
> would download and compile a single version of the kernel with your 
> module (not an unreasonable estimate).  Note that I'm not even including 
> the people who do repeated regression testing of versions, or people who 
> download and compile multiple versions of the kernel.   If the source 
> file takes an average of 1.0 seconds to compile in C and 2.0 seconds to 
> compile in C++, then:
> 
> (2.0 sec - 1.0 sec) * 200,000 = 200,000 seconds = 55.6 hours
> 140 hours - 100 hours = 40 hours
> 40 hours < 55.6 hours
> 
> So for a single version of the kernel your module, you've already wasted 
> 15.6 hours of time across people using it.  Over time that number is 
> just going to grow, _especially_ if people start writing more and more 
> modules in C++ because they can.  If you want to build C++ in the 
> kernel, write a compiler that does not include all the problematic C++ 
> features that add so much parsing time (overloaded operators, etc).

It is hard take this seriously. For people like me, it is 5 times faster 
to type and debug C++ code. And debug time is 50 times more expensive 
then compile time.

>>>> A lot of C++ features are already supported sanely. You simply need 
>>>> to understand them. Especially templates and type checking.
>>>
>>> First of all, the only way to sanely use templated classes is to 
>>> write them completely inline, which causes massive bloat.  Look at 
>>> the kernel "struct list_head" and show me the "type-safe C++" way to 
>>> do that.  It uses a templated inline class, right?  That templated 
>>> inline class gets duplicated for each different type of object put in 
>>> a linked list, no?  Think about how many linked lists we have in the 
>>> kernel and tell me why that would be a good thing.
>>
>> You mentioned a bad example. The struct list_head has [almost?] all 
>> "members" inlined. If they were not, one could simply make a base 
>> class having [some] members outlined, and which class does not enforce 
>> type safety and is for inheritance only.  The template class would 
>> then inherit the base one enforcing type safety by having inline 
>> members. This technique is well known, trust me. If you need real life 
>> examples, tell me.
> 
> Ok, help me understand here:  Instead of helping using one sensible data 
> structure and generating optimized code for that, the language actively 
> _encourages_ you to duplicate classes and interfaces, providing even 
> _more_ work for the compiler, making the code harder to debug, and 
> probably introducing inefficiencies as well.

The C++ language does not encourage anything like this. Instead it 
actively debugs my code. And it does not produce inefficiencies at run 
time unless I do something stupid.

> If C++ doesn't work 
> properly for a simple and clean example like struct list_head, why 
> should we assume that it's going to work any better for more complicated 
> examples in the rest of the kernel?  Whether or not some arbitrary 
> function is inlined should be totally orthogonal to adding type-checking.

You misunderstood something. The struct list_head is indeed a perfect 
type to be templatized with all members inlined. C++ works properly in 
this case.

>>>> Static constructor issue is trivial.
>>>
>>> How so?  When do you want the static constructors to be run?  There 
>>> are many different major stages of kernel-level initialization; 
>>> picking one is likely to make them useless for other code.
>>
>> For #defines core_initcall() ... late_initcall() I would type 
>> something like this:
>>     class foo_t { foo_t(); ~foo_t(); }
>>     static char foo_storage[sizeof(foo_t)];
>>     static foo_t& foo=*reinterpret_cast<foo_t*>(foo_storage);
>>     static void __init foo_init() { new(foo_storage) foo_t; }
>>     core_initcall(foo_init);
>>
>> This ugly-looking code can be nicely wrapped into a template, which, 
>> depending on the type (foo_t in this case), at compile time, picks the 
>> proper stage for initialization.
> 
> You proved my point.  Static constructors can't work.  You can add silly 
> wrapper initcall functions which create objects in static memory at 
> various times, but the language-defined static constructors are yet 
> another C++ feature that doesn't work by default and has to be hacked 
> around.  C++ gives us no advantage over C here either.

Nothing works by default. I did not say that static constructors are 
advantageous. I said that it is easy for the kernel to make static 
constructors working. Global variables should be deprecated anyway.

> Plus this would 
> break things like static spinlock initialization.  How would you make 
> this work sanely for this static declaration:
> 
> spinlock_t foo_lock = SPIN_LOCK_UNLOCKED;
> 
> Under C that turns into (depending on config options):
> 
> spinlock_t foo_lock = { .value = 0, .owner = NULL, (...) };

I would make it exactly like this:
	#define SPIN_LOCK_UNLOCKED (spinlock_t){0,-1,whatever}
	spinlock_t foo_lock=SPIN_LOCK_UNLOCKED;
This is easy to change. The empty structures look far more painful.

> How could that possibly work in C++ given what you've said?  Anything 
> that breaks code that simple is an automatic nonstarter for the kernel.  
> Also remember that spinlocks are defined preinitialized at the very 
> earliest stages of init.  Of course I probably don't have to say that 
> anything that tries to run a function to iterate over all 
> statically-allocated spinlocks during init would be rejected out of hand.

Apparently this would be rejected. Why would it?

Regards
Roman Kononov

Re: C++ pushback

[Michael Buesch]

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

On Thursday 27 April 2006 07:37, you wrote:
> > If C++ doesn't work 
> > properly for a simple and clean example like struct list_head, why 
> > should we assume that it's going to work any better for more complicated 
> > examples in the rest of the kernel?  Whether or not some arbitrary 
> > function is inlined should be totally orthogonal to adding type-checking.
> 
> You misunderstood something. The struct list_head is indeed a perfect 
> type to be templatized with all members inlined. C++ works properly in 
> this case.

I am not sure, if you can relieably use the container_of() magic
in C++. Do you know?
I have a C++ linked list example here:
http://websvn.kde.org/trunk/extragear/security/pwmanager/pwmanager/libpwmanager/linkedlist.h?rev=421676&view=markup
It is very simple and in some points different from the kernel
linked lists. It has a separate "head" and "entry" class and it stores
a pointer to the entry (the kernel linked lists would use container_of()
instead)

> Nothing works by default. I did not say that static constructors are 
> advantageous. I said that it is easy for the kernel to make static 
> constructors working. Global variables should be deprecated anyway.

You are kidding. Must be...

> > Plus this would 
> > break things like static spinlock initialization.  How would you make 
> > this work sanely for this static declaration:
> > 
> > spinlock_t foo_lock = SPIN_LOCK_UNLOCKED;
> > 
> > Under C that turns into (depending on config options):
> > 
> > spinlock_t foo_lock = { .value = 0, .owner = NULL, (...) };
> 
> I would make it exactly like this:
> 	#define SPIN_LOCK_UNLOCKED (spinlock_t){0,-1,whatever}
> 	spinlock_t foo_lock=SPIN_LOCK_UNLOCKED;
> This is easy to change. The empty structures look far more painful.

The lack of named initializers is one of the main reasons (for me)
why C++ damn sucks. Hopefully they will include them in the
next C++ standard.

-- 
Greetings Michael.

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

Re: C++ pushback

[linux-os (Dick Johnson)]

On Thu, 27 Apr 2006, Michael Buesch wrote:

> On Thursday 27 April 2006 07:37, you wrote:
>>> If C++ doesn't work
>>> properly for a simple and clean example like struct list_head, why
>>> should we assume that it's going to work any better for more complicated
>>> examples in the rest of the kernel?  Whether or not some arbitrary
>>> function is inlined should be totally orthogonal to adding type-checking.
>>
>> You misunderstood something. The struct list_head is indeed a perfect
>> type to be templatized with all members inlined. C++ works properly in
>> this case.
>
> I am not sure, if you can relieably use the container_of() magic
> in C++. Do you know?
> I have a C++ linked list example here:
> http://websvn.kde.org/trunk/extragear/security/pwmanager/pwmanager/libpwmanager/linkedlist.h?rev=421676&view=markup
> It is very simple and in some points different from the kernel
> linked lists. It has a separate "head" and "entry" class and it stores
> a pointer to the entry (the kernel linked lists would use container_of()
> instead)
>
>> Nothing works by default. I did not say that static constructors are
>> advantageous. I said that it is easy for the kernel to make static
>> constructors working. Global variables should be deprecated anyway.
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Any operating system kernel needs globals.

1	CPUs require structures existing in physical memory. Such
structures are page-tables, interrupt descriptor tables, and global
descriptor tables.

2	The first element (at least) of a linked-list, accessed by
more than one task needs a global anchor-point.

3	The first element (at least) of an interrupt dispatch table
needs to be global. More efficient code makes the whole table
global for efficient indexing.

4	The first element (at least) of a kernel function request
dispatch table needs to be global. More efficient code makes the
whole table global.

5	Hardware, a.k.a., PCI bus access is global. There is no
way around that. If the operating system interfaces with hardware,
it interfaces with global objects. They might be artifically
"private", but still global.

6	Spin-lock and semaphore variables need to be global, existing
in non-paged memory. Again, they might be artifically "private", but
are still global.

This is just a handful of examples. If you are going to use a tool
to make an O.S., you need to use the correct tool(s).

> You are kidding. Must be...
>
[SNIPPED Rest...]


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.lymanschool.com
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: C++ pushback

[Avi Kivity]

Kyle Moffett wrote:
>>>
>>> And that breaks a _massive_ amount of kernel code, including such 
>>> core functionality like SPIN_LOCK_UNLOCKED and a host of others.  
>>> There are all sorts of macros that use member initialization of that 
>>> form.
>>
>> This does not break the code at run time, this breaks the code at 
>> compile time, and should be less painful.
>
> So breaking 90% of the source code at compile time is ok?  I think 
> not.  The kernel relies really _really_ heavily on such structure 
> initializers, and breaking them would effectively break the world as 
> far as the kernel is concerned.
>

Since we're now discussing how to effectively port the kernel to C++, 
I'd suggest getting g++ to accept these structure initializers, and move 
them incrementally to standard C++ code.

Should be similar to the conversion to C99 initializers.

>>
>> I agree, it would be a bad idea to compile the existing C code by 
>> g++.  The good idea is to be able to produce new C++ modules etc.
>
> No, this is a reason why C++ modules are _not_ a good idea.  If you 
> could write the module in C or C++, but in C++ it compiled 100-200% 
> slower, then you would write it in C.  Why?  A simple matter of numbers:
>
> Say it takes you 100 hours to write and debug the module in C++, and 
> 140 to write and debug it in C.  I estimate that at least 200,000 
> people would download and compile a single version of the kernel with 
> your module (not an unreasonable estimate).  Note that I'm not even 
> including the people who do repeated regression testing of versions, 
> or people who download and compile multiple versions of the kernel.   
> If the source file takes an average of 1.0 seconds to compile in C and 
> 2.0 seconds to compile in C++, then:
>
> (2.0 sec - 1.0 sec) * 200,000 = 200,000 seconds = 55.6 hours
> 140 hours - 100 hours = 40 hours
> 40 hours < 55.6 hours
>
> So for a single version of the kernel your module, you've already 
> wasted 15.6 hours of time across people using it.  Over time that 
> number is just going to grow, _especially_ if people start writing 
> more and more modules in C++ because they can.  If you want to build 
> C++ in the kernel, write a compiler that does not include all the 
> problematic C++ features that add so much parsing time (overloaded 
> operators, etc).
>
>

It looks like you don't value your time much. You're comparing human 
time (yours!) to machine time.

If we accept your 1.4 C++ vs C factor, then these 200,000 people would 
be compiling 2.6.24 instead of 2.6.16.12.

(Of course, not all code benefits equally from C++. I'd guess the VM 
internals wouldn't benefit as much, filesystems and drivers benefiting a 
lot).

C++ compilation isn't slower because the compiler has to recognize more 
keywords. It's slower because it is doing more for you: checking types 
(C++ code is usually free of void *'s except for raw data) and expanding 
those 4-line function to their 14-line goto-heavy equivalents.


>>
>> You mentioned a bad example. The struct list_head has [almost?] all 
>> "members" inlined. If they were not, one could simply make a base 
>> class having [some] members outlined, and which class does not 
>> enforce type safety and is for inheritance only.  The template class 
>> would then inherit the base one enforcing type safety by having 
>> inline members. This technique is well known, trust me. If you need 
>> real life examples, tell me.
>
> Ok, help me understand here:  Instead of helping using one sensible 
> data structure and generating optimized code for that, the language 
> actively _encourages_ you to duplicate classes and interfaces, 
> providing even _more_ work for the compiler, making the code harder to 
> debug, and probably introducing inefficiencies as well.  If C++ 
> doesn't work properly for a simple and clean example like struct 
> list_head, why should we assume that it's going to work any better for 
> more complicated examples in the rest of the kernel?  Whether or not 
> some arbitrary function is inlined should be totally orthogonal to 
> adding type-checking.

C++ works excellently for things like list_head. The generated code is 
as efficient or better that the C equivalent, and the API is *much* 
cleaner. You can iterate over a list without knowing the name of the 
field which contains your list_head (and possibly getting it wrong if 
there is more than one).


>>
>> For #defines core_initcall() ... late_initcall() I would type 
>> something like this:
>>     class foo_t { foo_t(); ~foo_t(); }
>>     static char foo_storage[sizeof(foo_t)];
>>     static foo_t& foo=*reinterpret_cast<foo_t*>(foo_storage);
>>     static void __init foo_init() { new(foo_storage) foo_t; }
>>     core_initcall(foo_init);
>>
>> This ugly-looking code can be nicely wrapped into a template, which, 
>> depending on the type (foo_t in this case), at compile time, picks 
>> the proper stage for initialization.
>
> You proved my point.  Static constructors can't work.  You can add 
> silly wrapper initcall functions which create objects in static memory 
> at various times, but the language-defined static constructors are yet 
> another C++ feature that doesn't work by default and has to be hacked 
> around.  C++ gives us no advantage over C here either.  Plus this 
> would break things like static spinlock initialization.  How would you 
> make this work sanely for this static declaration:
>
> spinlock_t foo_lock = SPIN_LOCK_UNLOCKED;
>
> Under C that turns into (depending on config options):
>
> spinlock_t foo_lock = { .value = 0, .owner = NULL, (...) };
>
> How could that possibly work in C++ given what you've said?  Anything 
> that breaks code that simple is an automatic nonstarter for the 
> kernel.  Also remember that spinlocks are defined preinitialized at 
> the very earliest stages of init.  Of course I probably don't have to 
> say that anything that tries to run a function to iterate over all 
> statically-allocated spinlocks during init would be rejected out of hand.
>

Why would it be rejected?

A static constructor is just like a module init function. Why are 
modules not rejected out of hand?


-- 
error compiling committee.c: too many arguments to function

Re: C++ pushback

[Denis Vlasenko]

On Thursday 27 April 2006 11:07, Avi Kivity wrote:
> C++ compilation isn't slower because the compiler has to recognize more 
> keywords. It's slower because it is doing more for you: checking types 
> (C++ code is usually free of void *'s except for raw data) and expanding 

Today's C is much better at typechecking than ancient K&R C.

> those 4-line function to their 14-line goto-heavy equivalents.

Where do you see goto-heavy code in kernel?

> > Ok, help me understand here:  Instead of helping using one sensible 
> > data structure and generating optimized code for that, the language 
> > actively _encourages_ you to duplicate classes and interfaces, 
> > providing even _more_ work for the compiler, making the code harder to 
> > debug, and probably introducing inefficiencies as well.  If C++ 
> > doesn't work properly for a simple and clean example like struct 
> > list_head, why should we assume that it's going to work any better for 
> > more complicated examples in the rest of the kernel?  Whether or not 
> > some arbitrary function is inlined should be totally orthogonal to 
> > adding type-checking.
> 
> C++ works excellently for things like list_head. The generated code is 
> as efficient or better that the C equivalent,

"or better" part is pure BS, because there is no magic C++ compiler
can possibly do which is not implementable in C.

"as efficient", hmmm, let me see... gcc 3.4.3, presumably an contemporary
C++ compiler, i.e. which is "rather good".

Random example. gcc-3.4.3/include/g++-v3/bitset:

  template<size_t _Nw>
    struct _Base_bitset
    {
      typedef unsigned long _WordT;

      /// 0 is the least significant word.
      _WordT            _M_w[_Nw];

      _Base_bitset() { _M_do_reset(); }
...
      void
      _M_do_set()
      {
        for (size_t __i = 0; __i < _Nw; __i++)
          _M_w[__i] = ~static_cast<_WordT>(0);
      }
      void
      _M_do_reset() { memset(_M_w, 0, _Nw * sizeof(_WordT)); }
...

A global or static variable of _Base_bitset or derived type
would need an init function?! Why not just preset sequence of
zeroes in data section?
[this disproves that C++ is very efficient]

Why _M_do_set() doesn't use memset()?
Why _M_do_reset() is not inlined?
[this disproves that today's C++ libs are well-written]?

> and the API is *much*  
> cleaner. You can iterate over a list without knowing the name of the 
> field which contains your list_head (and possibly getting it wrong if 
> there is more than one).

But kernel folks tend to *want to know* everything, including
names of the fields.

> > How could that possibly work in C++ given what you've said?  Anything 
> > that breaks code that simple is an automatic nonstarter for the 
> > kernel.  Also remember that spinlocks are defined preinitialized at 
> > the very earliest stages of init.  Of course I probably don't have to 
> > say that anything that tries to run a function to iterate over all 
> > statically-allocated spinlocks during init would be rejected out of hand.
> 
> Why would it be rejected?
> 
> A static constructor is just like a module init function. Why are 
> modules not rejected out of hand?

Because we do not like init functions which can be eliminated.
That's bloat.
--
vda

Re: C++ pushback

[Avi Kivity]

Denis Vlasenko wrote:
> On Thursday 27 April 2006 11:07, Avi Kivity wrote:
>   
>> C++ compilation isn't slower because the compiler has to recognize more 
>> keywords. It's slower because it is doing more for you: checking types 
>> (C++ code is usually free of void *'s except for raw data) and expanding 
>>     
> Today's C is much better at typechecking than ancient K&R C.
>   

It still can't typecheck void pointers. With C++ they're very rare.

Look at the contortions needed to get the min() macro to be typesafe.

>> those 4-line function to their 14-line goto-heavy equivalents.
>>     
>
> Where do you see goto-heavy code in kernel?
>
>   

[avi@cleopatra linux]$ grep -rw goto . | wc -l
37448

Repeat without 'wc' to get a detailed listing.

>> C++ works excellently for things like list_head. The generated code is 
>> as efficient or better that the C equivalent,
>>     
>
> "or better" part is pure BS, because there is no magic C++ compiler
> can possibly do which is not implementable in C.
>
>   

For list_head, no. But coding more complex data structures as type-safe 
macros is not practicable.

As an example, you can easily get C++ to inline the hash function in a 
generic hashtable or the compare in a sort. I dare you to do it in C.

> "as efficient", hmmm, let me see... gcc 3.4.3, presumably an contemporary
> C++ compiler, i.e. which is "rather good".
>   

4.1.0 is the latest.

> Random example. gcc-3.4.3/include/g++-v3/bitset:
>   

You're looking at a library while we were talking about the language and 
compiler. But anyway.

>   template<size_t _Nw>
>     struct _Base_bitset
>     {
>       typedef unsigned long _WordT;
>
>       /// 0 is the least significant word.
>       _WordT            _M_w[_Nw];
>
>       _Base_bitset() { _M_do_reset(); }
> ...
>       void
>       _M_do_set()
>       {
>         for (size_t __i = 0; __i < _Nw; __i++)
>           _M_w[__i] = ~static_cast<_WordT>(0);
>       }
>       void
>       _M_do_reset() { memset(_M_w, 0, _Nw * sizeof(_WordT)); }
> ...
>
> A global or static variable of _Base_bitset or derived type
> would need an init function?! Why not just preset sequence of
> zeroes in data section?
>   

I wouldn't count startup time as efficiency, unless you have several 
million global bitset objects.

> [this disproves that C++ is very efficient]
>   

Add a constructor which does not touch the data members, and the data 
will (probably) end up in .bss.

> Why _M_do_set() doesn't use memset()?
>   

Patches accepted :)

It's just a library, you're free to optimize it. I'd guess that 
_M_do_set() is very rarely called, and that the performance difference 
is small anyway.

> Why _M_do_reset() is not inlined?
>   

It is inlined. Why do you think it is not?

> [this disproves that today's C++ libs are well-written]?
>
>   

Certainly, one can't claim that all C++ libraries are will written. But 
gcc library mostly is.

Again, if you don't like some library, don't use it. The kernel would 
use its own version anyway since it has to be freestanding.

>> and the API is *much*  
>> cleaner. You can iterate over a list without knowing the name of the 
>> field which contains your list_head (and possibly getting it wrong if 
>> there is more than one).
>>     
>
> But kernel folks tend to *want to know* everything, including
> names of the fields.
>   

The names of the fields are not hidden. You just don't have to 
mindlessly repeat them.

The 'know everything' argument seems to apply equally well to ordinary 
functions: "I *must know* about calls to schedule() and those expensive 
atomic operations, don't hide them behind mutex_lock()!"

>>> How could that possibly work in C++ given what you've said?  Anything 
>>> that breaks code that simple is an automatic nonstarter for the 
>>> kernel.  Also remember that spinlocks are defined preinitialized at 
>>> the very earliest stages of init.  Of course I probably don't have to 
>>> say that anything that tries to run a function to iterate over all 
>>> statically-allocated spinlocks during init would be rejected out of hand.
>>>       
>> Why would it be rejected?
>>
>> A static constructor is just like a module init function. Why are 
>> modules not rejected out of hand?
>>     
>
> Because we do not like init functions which can be eliminated.
> That's bloat.

I'm sure you can eliminate them if you want, but working to remove some 
microseconds of boot time is a complete waste of effort IMO.

-- 
error compiling committee.c: too many arguments to function

Re: C++ pushback

[Denis Vlasenko]

On Thursday 27 April 2006 17:27, Avi Kivity wrote:
> > Where do you see goto-heavy code in kernel?
> >
> >   
> 
> [avi@cleopatra linux]$ grep -rw goto . | wc -l
> 37448
> 
> Repeat without 'wc' to get a detailed listing.

In 1999 Dave 'Barc0de' Jones, Paranoid wierdo noize making geek,
wrote this:

http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html

I failed to find a link, but in 2004 Dave Jones, a well-known
kernel hacker, wrote something like "Wow, it's fun to read
my own old mail, how naive I was back then :)"

Feel free to get your hards dirty with kernel development,
and maybe you will say something similar a few years from now.

Or maybe not, and I will be proven wrong.
--
vda

Re: C++ pushback

[Bob Copeland]

On 4/27/06, Denis Vlasenko <vda@ilport.com.ua> wrote:
> On Thursday 27 April 2006 17:27, Avi Kivity wrote:
> > > Where do you see goto-heavy code in kernel?
> > >
> > >
> >
> > [avi@cleopatra linux]$ grep -rw goto . | wc -l
> > 37448
> >
> > Repeat without 'wc' to get a detailed listing.
>
> In 1999 Dave 'Barc0de' Jones, Paranoid wierdo noize making geek,
> wrote this:
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html
>
> I failed to find a link, but in 2004 Dave Jones, a well-known
> kernel hacker, wrote something like "Wow, it's fun to read
> my own old mail, how naive I was back then :)"

Possibly:

http://marc.theaimsgroup.com/?l=linux-kernel&m=104246373424112

-Bob

Re: C++ pushback

[Avi Kivity]

Denis Vlasenko wrote:
> On Thursday 27 April 2006 17:27, Avi Kivity wrote:
>   
>>> Where do you see goto-heavy code in kernel?
>>>
>>>   
>>>       
>> [avi@cleopatra linux]$ grep -rw goto . | wc -l
>> 37448
>>
>> Repeat without 'wc' to get a detailed listing.
>>     
>
> In 1999 Dave 'Barc0de' Jones, Paranoid wierdo noize making geek,
> wrote this:
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html
>
> I failed to find a link, but in 2004 Dave Jones, a well-known
> kernel hacker, wrote something like "Wow, it's fun to read
> my own old mail, how naive I was back then :)"
>   

:)

I'll refer you to the 4-line vs 14-line examples. To the C++ trained 
mind, the 4 line segment is much clearer.

> Feel free to get your hards dirty with kernel development,
> and maybe you will say something similar a few years from now.
>   

I have some experience with kernel code (mucking about the asynchronous 
I/O implementation) and a lot of experience in C++ system code (both 
ring 0 and userspace). What I've written in this thread is a result of 
20+ (can't believe I'm writing that number) years of coding, not 
theoretical studies (I've studied aeronautical engineering but practiced 
it very little; if I talk about that maybe you can use the theory vs 
practice argument).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: C++ pushback

[Martin Mares]

> As an example, you can easily get C++ to inline the hash function in a 
> generic hashtable or the compare in a sort. I dare you to do it in C.

As you wish :-)

http://atrey.karlin.mff.cuni.cz/~mj/tmp/hashtable.h

It's somewhat ugly inside, but an equally strong generic structure build
with templates will be probably even uglier.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Immanuel doesn't pun, he Kant.

Re: C++ pushback

[Avi Kivity]

Martin Mares wrote:
>> As an example, you can easily get C++ to inline the hash function in a 
>> generic hashtable or the compare in a sort. I dare you to do it in C.
>>     
>
> As you wish :-)
>
> http://atrey.karlin.mff.cuni.cz/~mj/tmp/hashtable.h
>   
Touche :)

This is pushing all boundaries, however. That code is horrible.
> It's somewhat ugly inside, but an equally strong generic structure build
> with templates will be probably even uglier.
>
>   
Not at all.

-- 
error compiling committee.c: too many arguments to function

Re: C++ pushback

[Martin Mares]

> This is pushing all boundaries, however. That code is horrible.
>
> >It's somewhat ugly inside, but an equally strong generic structure build
> >with templates will be probably even uglier.
> >
> Not at all.

So, show your version :-)

(as fast as this one, of course)

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Outside of a dog, a book is man's best friend. Inside a dog, it's too dark to read.

Re: C++ pushback

[Avi Kivity]

Martin Mares wrote:
>> This is pushing all boundaries, however. That code is horrible.
>>
>>     
>>> It's somewhat ugly inside, but an equally strong generic structure build
>>> with templates will be probably even uglier.
>>>
>>>       
>> Not at all.
>>     
>
> So, show your version :-)
>
> (as fast as this one, of course)
>
> 				Have a nice fortnight
>   
Here you go. In practice one would probably uninline get() and possibly put().

It doesn't do all that your example does (a 15 minute hack), but it is easily expandable. It 
also allows a value to belong to two different hash tables (on two different keys) simultaneously.

#include <cassert>

template <typename Key, class Value, class Traits>
class Hashtable
{
public:
    class Link {
    private:
        Link* next;
        Value& value()
        {
            return *static_cast<Value*>(this);
        }
        friend class Hashtable;
    };
public:
    explicit Hashtable(int size)
        : _size(size)
        , _buckets(new Link[size])
    {
        assert((_size & (_size -  1)) == 0);
    }
    ~Hashtable()
    {
        delete[] _buckets;
    }
    Value* get(const Key& key)
    {
        Link* link = _buckets[Traits::hash(key) & (_size - 1)].next;
        while (link && !Traits::equal(key, link->value()))
            link = link->next;
        if (link)
            return &link->value();
        return 0;
    }
    void put(Value& value)
    {
        // assumes value (or a value with an equal key) is not already in
        Link& head = _buckets[Traits::hash(value) & (_size - 1)];
        static_cast<Link&>(value).next = &head;
        head.next= &value;
    }
private:
    int _size;
    Link* _buckets;
};

// example program

#include <iostream>
#include <string.h>

struct Word;
struct WordHashTraits;
typedef Hashtable<const char*, Word, WordHashTraits> WordHash;

struct Word : WordHash::Link
{
    explicit Word(const char* _word) : word(_word), count(0) {}
    const char* word;
    int count;
};

struct WordHashTraits
{
    static unsigned hash(const char* key)
    {
        // assume this is jenkin's hash.
        unsigned h = 0;
        while (*key) {
            h = (h << 3) | (h >> 29);
            h ^= (unsigned char)*key++;
        }
        return h;
    }
    static unsigned hash(const Word& value)
    {
        return hash(value.word);
    }
    static bool equal(const char* key, const Word& value)
    {
        return strcmp(key, value.word) == 0;
    }
};

int main(int ac, const char** av)
{
    WordHash hashtable(16); // make collisions likely
    for (int i = 1; i < ac; ++i) {
        const char* word = av[i];
        Word* word_in_hash = hashtable.get(word);
        if (!word_in_hash) {
            word_in_hash = new Word(word);
            hashtable.put(*word_in_hash);
        }
        ++word_in_hash->count;
        std::cout << "word: " << word << " count " << word_in_hash->count << "\n";
    }
}









-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: C++ pushback

[Avi Kivity]

Avi Kivity wrote:
>    void put(Value& value)
>    {
>        // assumes value (or a value with an equal key) is not already in
>        Link& head = _buckets[Traits::hash(value) & (_size - 1)];
>        static_cast<Link&>(value).next = &head;
>        head.next= &value;
>    }
s/&head/head.next/ in the third line, of course.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: C++ pushback

[Jan Engelhardt]

> #include <cassert>
>
> template <typename Key, class Value, class Traits>
> class Hashtable
> {
> public:
> class Link {

Does not match CodingStyle. SCNR.

>   assert((_size & (_size -  1)) == 0);

Names with underscores are usually reserved.

> // example program
>
> static unsigned hash(const char* key)
> {
> // assume this is jenkin's hash.
> unsigned h = 0;
> while (*key) {
> h = (h << 3) | (h >> 29);
> h ^= (unsigned char)*key++;

No const_cast<> and static_cast<> here?



Jan Engelhardt
-- 

Re: C++ pushback

[Jan Engelhardt]

>
> It still can't typecheck void pointers. With C++ they're very rare.
>
Using C++ just because one can't verify that all type conversions in a C 
program from/to void* are as they are supposed to be is... well, think of 
something.


Jan Engelhardt
-- 

Re: C++ pushback

[Avi Kivity]

Jan Engelhardt wrote:
>> It still can't typecheck void pointers. With C++ they're very rare.
>>
>>     
> Using C++ just because one can't verify that all type conversions in a C 
> program from/to void* are as they are supposed to be is... well, think of 
> something.
>   

If you remove the 'just', I'd say 'a way to catch more bugs at compile 
time'.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: C++ pushback

[Sam Ravnborg]

On Wed, Apr 26, 2006 at 11:37:05PM -0400, Kyle Moffett wrote:
> >
> >I agree, it would be a bad idea to compile the existing C code by g+ 
> >+.  The good idea is to be able to produce new C++ modules etc.
> 
> No, this is a reason why C++ modules are _not_ a good idea.  If you  
> could write the module in C or C++, but in C++ it compiled 100-200%  
> slower, then you would write it in C.
The original issue was the possibility to add support for C++
solely to support an existing implementation of a filesystem.
Not to rewrite the kernel in C++, neither to encourage the use of C++.
And with this in mind the figures above does not matter.

Likewise does neiter of the many arguments in this thread.
Now if the C++ fans could present what is needed to actually support
building a module in C++ instead of arguing.....

	Sam

Re: C++ pushback

[Martin Mares]

> I agree, it would be a bad idea to compile the existing C code by g++. 
> The good idea is to be able to produce new C++ modules etc.

For which you need to compile the existing headers correctly.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A computer without Windows is like a chocolate cake without mustard.

Re: C++ pushback

[Willy Tarreau]

On Wed, Apr 26, 2006 at 06:00:52PM -0500, Roman Kononov wrote:
> Linus Torvalds wrote:
> > - the compilers are slower, and less reliable. This is _less_ of an 
> > issue these days than it used to be (at least the reliability part), 
> >   but it's still true.
> G++ compiling heavy C++ is a bit slower than gcc. The g++ front end is 
> reliable enough. Do you have a particular bug in mind?

Obviously you're not interested in gcc evolutions. I suggest that you
take your browser to http://gcc.gnu.org/gcc-3.4/changes.html#3.4.5
This is the last version which showed per-subsystem problem reports
before they used SVN. Just count the lines : 9 bugs fixed for C, 45
for C++. And when you read those bugs, you don't have the feeling of
reading a description of something that people make their code rely on.

Regards,
Willy

Re: C++ pushback

[Roman Kononov]

On 04/26/2006 22:57, Willy Tarreau wrote:
> On Wed, Apr 26, 2006 at 06:00:52PM -0500, Roman Kononov wrote:
>> Linus Torvalds wrote:
>>> - the compilers are slower, and less reliable. This is _less_ of an 
>>> issue these days than it used to be (at least the reliability part), 
>>>   but it's still true.
>> G++ compiling heavy C++ is a bit slower than gcc. The g++ front end is 
>> reliable enough. Do you have a particular bug in mind?
> 
> Obviously you're not interested in gcc evolutions. I suggest that you
> take your browser to http://gcc.gnu.org/gcc-3.4/changes.html#3.4.5
> This is the last version which showed per-subsystem problem reports
> before they used SVN. Just count the lines : 9 bugs fixed for C, 45
> for C++. And when you read those bugs, you don't have the feeling of
> reading a description of something that people make their code rely on.

I am interested very much. And if one really understands the bugs 
listed, he can say that they are minor for both C and C++. I would 
certainly recommend rely on g++.

Regards,
Roman

Re: C++ pushback

[Jan-Benedict Glaw]

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

On Wed, 2006-04-26 18:00:52 -0500, Roman Kononov <kononov195-far@yahoo.com> wrote:
> Statement expressions are working fine in g++. The main difficulties are:
>    - GCC's structure member initialization extensions are syntax
>      errors in G++: struct foo_t foo={.member=0};

Erm, you may want to read the current C standard (C99). This isn't an
extension, it's standard.

There's a reason why C++ doesn't support that (yet): C++ is a fork of
C90 (IIRC), so everything that evolved in C during the years is still
missing from C++.

> > Anyway, it should all be doable. Not necessarily even very hard. But I 
> > doubt it's worth it.
> 
> I think that allowing C++ code to co-exist with the kernel would be a 
> step forward.

You can do with your code whatever you want to:)  I think it's just a
matter of practice: If C++ code shows up that is less error-prone than
C code, doesn't use unverifyable amounts of stack space during
constructor runs and is basically _superior_ to C code, that'll find
its way into the kernel. But if it's only as good as the C code, then
why should anybody bother implementing the neccessary stuff to link
C++ code (and to initialize it properly?)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

Re: C++ pushback

[Jan Harkes]

On Wed, Apr 26, 2006 at 06:00:52PM -0500, Roman Kononov wrote:
> Linus Torvalds wrote:
> > - a lot of the C++ features just won't be supported sanely (ie the kernel 
> >   infrastructure just doesn't do exceptions for C++, nor will it run any 
> >   static constructors etc).
> A lot of C++ features are already supported sanely. You simply need to 
> understand them. Especially templates and type checking. C++ 
> exceptions are not very useful tool in kernels. Static constructor 
> issue is trivial. I use all C++ features (except exceptions) in all 
> projects: Linux kernel modules, embedded real-time applications, 
> everywhere. They _really_ help a lot.

Seriously, your code must be broken.

The C++ standard does not allow an allocator to return NULL, it is
supposed to raise an exception.

Jan

RE: C++ pushback

[David Schwartz]

> The C++ standard does not allow an allocator to return NULL, it is
> supposed to raise an exception.
>
> Jan

	It is not that unusual for C++ projects to use no exceptions at all. They
simply replace the default standardized allocators with their own. These
allocators can do whatever you want when memory runs out, including waiting
until more memory is available while acting to reduce memory usage in other
parts of the program.

	You are not forced to use exceptions if you don't want to. Personally, I
don't like them, and I rarely use them, even in large C++ projects (hundreds
of thousands of lines).

	DS

RE: C++ pushback

[linux-os (Dick Johnson)]

On Wed, 26 Apr 2006, David Schwartz wrote:

>
>>> 	As for remembering new names, that's a load of complete crap and I
>>> find it hard to believe that you're raising the argument for honest
>>> reasons.
>
>> The scale of the kernel, the number and churn of developers, and the
>> importance of not breaking things in a stable kernel tend to argue
>> against you.  Humans develop the kernel.  Humans remember names well.
>> You may think that's arbitrary, but when you change naming across the
>> entire kernel, you confuse a very large and diverse group of people who
>> do this because they enjoy it.  It's hard enough when this has to happen
>> for useful or necessary reasons; you're asking the kernel developers to
>> accept it for a completely arbitrary whim that they have rejected
>> successfully several times in the past.
>
> 	C++ has how many additional reserved words? I believe the list is delete,
> friend, private, protected, public, template, throw, try, and catch.
> Renaming every symbol that currently has a name from this list to the
> corresponding name with a trailing underscore is an easily understood
> consistent change.
>
> 	That you would argue against is with things like "not breaking things" is a
> load of complete crap.
>
>> You want C++?  Fork the freely
>> available source code at a convenient point and convert it yourself.  As
>> long as it stays GPL, you're perfectly within your rights so to do.
>> Hobson's choice is yours.  Belaboring this point is silly.
>
> 	Making ridiculous arguments like that a consistent change of a small set of
> names is "breaking things in a stable kernel" is silly.
>
> 	And, FWIW, it isn't even necessary to change those names. That is only
> needed to compile the kernel in C++, which is not what anyone was talking
> about. Supporting C++ modules, for example, would work fine even if the
> kernel had variables called 'class' or 'private'. (Though things could be
> done a lot more cleanly if it didn't as it would require some remapping
> before and after compilation.)
>
> 	DS


You know. All one needs to do is to compile C++ module code outside
the kernel. I compile such code outside the kernel all the time.

You make make your own private header directory that contains the
few modified kernel headers that you need. You put this directory
first in the -I(SearchList) on the command-line so that the "bad"
kernel headers are never even found.

Then you make a kernel module with C++. Remember that you can't
include your C++ runtime library on stuff that runs inside the
kernel. I think that, just to access the "struct file" structure,
which is fairly important for modules, you are going to need
'C' wrappers around your C++ code. Once you get something to actually
load IFF you get it to load, you will probably find that most
of your code is wrappers, which don't disappear. They are essential
conversion procedures.

After a few days of capture the Stockholm syndrome person will probably
understand that C++ was not designed for operating system kernels.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

RE: C++ pushback

[Xavier Bestel]

Le mercredi 26 avril 2006 à 12:25 -0700, David Schwartz a écrit :

> 	C++ has how many additional reserved words? I believe the list is delete,
> friend, private, protected, public, template, throw, try, and catch.

You forgot namespace, mutable, new, class, const_cast, dynamic_cast,
static_cast, reinterpret_cast, explicit, true, false, operator, typeid,
typename and virtual. Maybe I forgot some (interface ?). Probably some
new ones will appear.

	Xav

Re: C++ pushback

[Randy.Dunlap]

On Wed, 26 Apr 2006 22:09:51 +0200 Xavier Bestel wrote:

> Le mercredi 26 avril 2006 à 12:25 -0700, David Schwartz a écrit :
> 
> > 	C++ has how many additional reserved words? I believe the list is delete,
> > friend, private, protected, public, template, throw, try, and catch.
> 
> You forgot namespace, mutable, new, class, const_cast, dynamic_cast,
> static_cast, reinterpret_cast, explicit, true, false, operator, typeid,
> typename and virtual. Maybe I forgot some (interface ?). Probably some
> new ones will appear.

I did a sparse patch to check for all(?) of those once (with Linus's
help).  I don't know if it still applies or not...

It's at http://www.xenotime.net/linux/sparse/check_keywords_v7.patch
(You'll also need the other patch there; they got a bit comingled:
http://www.xenotime.net/linux/sparse/check_sizeof_v7.patch)

---
~Randy

RE: C++ pushback

[Jiri Kosina]

On Wed, 26 Apr 2006, Xavier Bestel wrote:

> > 	C++ has how many additional reserved words? I believe the list is
> > delete, friend, private, protected, public, template, throw, try, and
> > catch.
> You forgot namespace, mutable, new, class, const_cast, dynamic_cast,
> static_cast, reinterpret_cast, explicit, true, false, operator, typeid,
> typename and virtual. Maybe I forgot some (interface ?). Probably some
> new ones will appear.

Please also don't forget that C is not a proper subset of C++ (i.e. the 
kernel might not be compilable by C++ compiler at all), so just renaming 
the variables which have names clashing with C++ reserved words might not 
be enough.

-- 
JiKos.

Re: C++ pushback

[Martin Mares]

> 	C++ has how many additional reserved words? I believe the list is delete,
> friend, private, protected, public, template, throw, try, and catch.
> Renaming every symbol that currently has a name from this list to the
> corresponding name with a trailing underscore is an easily understood
> consistent change.

... which, for the point of view of people developing most parts of the
kernel (and thus not caring about C++ much) just makes the names ugly.
When some struct member describes a device class the device belongs to,
calling it anything else than "class" is silly.

But yes, the C++ modules can redefine such things by macros when
including kernel headers.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Linux vs. Windows is a no-WIN situation.

Re: C++ pushback

[Avi Kivity]

[original poster de-cc'ed]

Martin Mares wrote:
> Can you name any reasons for why should we support C++ in the kernel?
>   
1. Porting existing modules written in C++ - the trigger for this thread?

2. Shorter, faster, more robust code.
> Why shouldn't we invest the effort to making it possible to write kernel
> modules in Haskell instead?
>   
C++ is a system programming language with good C compatibility. Making 
the kernel compatible with C++ is doable.

Haskell is an excellent language, but it is not a system programming 
language. Kernel programming does not fit well into the functional model.
> The kernel is written in C and its maintainers have so far agreed that
> C is enough and adding any other language brings more pain than gain.
>
> If you think otherwise, feel free to submit some real code which shows
> the advantages of using a different language.
>   
That's certainly doable, however it is quite pointless since we know 
that the code will be rejected regardless of any technical merits it may 
have.

-- 
error compiling committee.c: too many arguments to function

Re: C++ pushback

[Nick Piggin]

Avi Kivity wrote:
> [original poster de-cc'ed]
> 
> Martin Mares wrote:
> 
>> Can you name any reasons for why should we support C++ in the kernel?
>>   
> 
> 1. Porting existing modules written in C++ - the trigger for this thread?
> 
> 2. Shorter, faster, more robust code.
> 
>> Why shouldn't we invest the effort to making it possible to write kernel
>> modules in Haskell instead?
>>   
> 
> C++ is a system programming language with good C compatibility. Making 
> the kernel compatible with C++ is doable.

You could call it Linux++ and discuss it to your heart's content in l++kml ;)

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: C++ pushback

[Esben Nielsen]

On Tue, 25 Apr 2006, Avi Kivity wrote:

> [...]
> Haskell is an excellent language, but it is not a system programming
> language. Kernel programming does not fit well into the functional model.

I find it really funny you say that. I have been thinking about what
language would be the most suitable for writing a kernel in and I find
that _functional_  languages ought to do the trick.

The essential thing about functional languages is that they use copy on
write. You never modify a piece of memory but make new copy with the
changes. Doesn't that remind you of RCU? Yes, you don't need locks! This
is essential when dealing with the future computers which will have lots
of CPU cores. Ofcourse, when accessing a piece of hardware you can't take
a copy and you would need a lock around the hardware access.
And ofcourse, you will need to make a small runtime system with
garbage-collection. The choice there would be C. So the kernel would
consist of assembler, C and an almost functional language like OCaml.
The strong typing and the lack of pointer arithmetic would also silence
any talks about microkernels.

But dreaming asside and back to the real world and the original thread:

I have experience with C and C++ at the system level and I do a little
Linux kernel hacking as a hobby. I want to push Linux in the embedded
system area because even the very high end RTOS we use at work sucks in
many ways.
But although that RTOS is written in C, it does have the ability to load
modules written in C++.  It doesn't have any userspace so every
application is loaded  directly into the kernel - and applications
are very often written in C++.

I think one ought to be able to write kernel modules in C++ as well. Many
companies now running their own home-made "OS"  - typically written in
assambler and C++ - are considering switching to  Linux. One of the
tumbling blocks is that they can not reuse their drivers as they would
have to be ported _back_ to C. A lot of people find that redicoulus and would
findanother OS just because of that. Remember that many, many people out there
think that when you say "C", you really mean C++. For them old flat C is
simply not existing anymore.

Now I don't think the main line kernel tree should include modules written
in C++. I have in the past "converted" a mud from being compiled with gcc
to being compiled with g++. It worked fine for me but after that it was
much harder for others to participate in the project. I wouldn't admit it
at that time; but now I see that it could very well have raised the level
of entry by a lot. C++ is simply very _hard_ to learn.

That said I have a lot of fun coding C++ at work. Many companies use
C++ because you really are more productive than in C. (Another reason is
that in the Windows world code generators like flex, rpcgen etc. are frowned
upon as they are not "standeard" and are hard to fit into build
environment. Therefore terrible stuff like Spirit is invented.
C++  hackers want to do everything within C++ and can't imagine writing
scripts and small code generators for generating all the trivial C code.
That latter often gives a better result, too, because you can only do 95%
with templates.)

But I find C++ basicly broken. It wants to be both high and lowlevel.
It doesn't have garbage collection; but it is almost impossible to make
the semi-manual memory management work 100%. It works 99.9% so it is
acceptable for most uses but not in a OS kernel.

And like Lisp wants to do with macros, C++ wants to make the coder create
his own syntax with operator overloading and templates. That often makes
the code totally unreadable for the causual reader. C++ encourages programmers
to do this stuff but 90% of the time it is done, it shouldn't have been
done. A language feature which is abused 90% of the time is bad no matter
what beautifull things can be done with it.
It is fine that you sort of can make your own "language" for your specific
perpose, but it is a huge mistake to mix the language definitions with the
actual program. It ought to be layered, so you first take your basic
compiler, make your extentions/modifications and then use that compiler on
your program. Then those modifications can be well thought over before
being applied.

And like in all OO languages you need a complete UML diagram before you can
read the code. In C I can usually find what I am looking for in even large
projects like Linux with just grep and less; but for OO languages you need
tools which can actually parse and understand the code to help you find
the relevvant functions/methods for you. grep can simply not do it because
a lot of functions/methods have identical names.

I understand why people are using C++, but I think it is a dead end. Stay
with C or go to a true highlevel language. Even Microsoft have figured
that out now; but because they have pushed C++ for years a lot of people
use C++ today without even thinking it is possible to use plain C - or
anything else. I think it is worth for the Linux community to meet them half
way and make it possible to compile C++ modules to the kernel, but
disallow actual C++ in the official kernel tree.

This his is how the RTOS I mentioned supports C++ modules by the way:

All public headers are wrapped with

#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif

and no C++ keywords are used. No inline functions are present so no
actual code from the header files have to be compiled with the C++
compiler.

To initialize global and static constructors first the module is compiled
into a tmp.o. This is now searched for such constructors using nm. A
function which calls them all is now generated in a auto.c.
The final module is tmp.o and auto.o combined. The OS simply calls the
generated function if the module has successfully been linked.

Merging a patch fixing the header files and modifying modpost to also call
constructors wouldn't destroy anything for the Linux kernel and make it
possible to make C++ modules as long as one avoids exceptions.

Doing exceptions in the kernel would be much harder but doable - but it
might make a runtime overhead which isn't acceptable. But maybe a config
option enabling them could be tolerated.


Esben

Re: C++ pushback

[Thiago Galesi]

OK, let's get a couple of things clear...

No one here "hates" C++ per se. It is a tool, and every tool has its purpose.

Using C++ in the kernel has not been deemed apropriate for several
reasons. There are several (other) reasons to make the Linux Kernel C
only, this has been discussed, trolled, flamed, argued, come, gone,
etc, etc FAQs and searches are your friend there.

In your scenario, you have two possible option (IMHO)

1 - Port your existing code to C

2- keep it in C++, keep it in user level and have a simple file system
driver communicating with your existing code (I think FUSE applies to
the situation)

Thiago



On 4/24/06, Gary Poppitz <poppitzg@iomega.com> wrote:
> > We know they are "incompatible", why else would we allow "private" and
> > "struct class" in the kernel source if we some how expected it to work
> > with a C++ compiler?
>
>
> I can see that this was intentional, not an oversight.
>
> If there is a childish temper tantrum mentality about C++ then I have
> no reason or desire to be on this list.
>
> Grow up.
> -
> 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: C++ pushback

[Kurt Wall]

On Mon, Apr 24, 2006 at 02:02:27PM -0600, Gary Poppitz took 17 lines to write:
> >We know they are "incompatible", why else would we allow "private" and
> >"struct class" in the kernel source if we some how expected it to work
> >with a C++ compiler?
> 
> 
> I can see that this was intentional, not an oversight.

If you can see it was intentional, I'm baffled why it didn't occur to you
to do some simple research before posting or even trouble yourself to
ask "Why?" on LKML.

> If there is a childish temper tantrum mentality about C++ then I have  
> no reason or desire to be on this list.

If there is an unwillingness to learn the ground rules and conventions
of the group you want to join, then the group has no reason nor desire
to have you join.

> Grow up.

Bye now.

Kurt
-- 
Wit, n.:
	The salt with which the American Humorist spoils his cookery
... by leaving it out.
		-- Ambrose Bierce, "The Devil's Dictionary"

Re: C++ pushback

[Roman Kononov]

On 04/24/2006 15:02, Gary Poppitz wrote:
>> We know they are "incompatible", why else would we allow "private" and
>> "struct class" in the kernel source if we some how expected it to work
>> with a C++ compiler?
> 
> 
> I can see that this was intentional, not an oversight.
> 
> If there is a childish temper tantrum mentality about C++ then I have no 
> reason or desire to be on this list.
> 
> Grow up.

Please let me summarize:
	1) Many people are more efficient writing C++ modules.
	2) It does not make sense to rewrite existing C code in
	   another language.
	3) Kernel H-files are not compilable by g++.
	4) The H-files use C++ keywords.
	5) The H-files use member initialization syntax, unsupported
	   by g++.
	6) The H-files use empty structures which are not empty in
	   g++.

4), 5) and 6) are to be fixed if we want to be g++-friendly. I am not 
aware of any other issues. Features like static constructors and 
exceptions are not strictly necessary for successful C++ programming.

4) must be trivial.
5) is less trivial but still doable. Can we ask g++ folks?
6) looks rather painful.

What do you think?

Regards
Roman

Re: C++ pushback

[Grant Coady]

On Thu, 27 Apr 2006 11:17:58 -0500, Roman Kononov <kononov195-far@yahoo.com> wrote:

>Please let me summarize:
>	1) Many people are more efficient writing C++ modules.
>	2) It does not make sense to rewrite existing C code in
>	   another language.
>	3) Kernel H-files are not compilable by g++.
>	4) The H-files use C++ keywords.
>	5) The H-files use member initialization syntax, unsupported
>	   by g++.
>	6) The H-files use empty structures which are not empty in
>	   g++.
>
>4), 5) and 6) are to be fixed if we want to be g++-friendly. I am not 
>aware of any other issues. Features like static constructors and 
>exceptions are not strictly necessary for successful C++ programming.
>
>4) must be trivial.
>5) is less trivial but still doable. Can we ask g++ folks?
>6) looks rather painful.
>
>What do you think?

There's a document: CodingStyle

You seem to be arguing where the kernelspace / userspace boundary 
line is.  C++ is outside kernelspace.

Grant.

Re: C++ pushback

[Bill Davidsen]

Gary Poppitz wrote:
>> We know they are "incompatible", why else would we allow "private" and
>> "struct class" in the kernel source if we some how expected it to work
>> with a C++ compiler?
> 
> 
> I can see that this was intentional, not an oversight.

Possibly, what difference would it make?
> 
> If there is a childish temper tantrum mentality about C++ then I have no 
> reason or desire to be on this list.

I only see one temper tantrum, and when you leave there will be none. 
Oh, FORTRAN, PASCAL, and LISP aren't compatible either. And the comments 
are all in English, without subtitles, how can people from other 
cultures ever cope? Answer: nicely, it takes a native speaker of the 
language to really botch the grammar.
> 
> Grow up.

You're whining because the kernel wasn't written for your convenience 
and you tell US to grow up? Someone needs a time out.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: C++ pushback

[Jan Knutar]

On Friday 28 April 2006 01:09, Bill Davidsen wrote:

> Oh, FORTRAN, PASCAL, and LISP aren't compatible either. And the comments 

Wasn't there a patch for LISP in the kernel? I seem to remember such a thread...