C or C++?

[Branimir Maksimovic]

Re: C or C++?

On May 21, 9:11 am, James Kanze <james.ka...@gm ail.comwrote:
It means, too, not

triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

I have found this article that says:
"If either the context of the template's instantiation or the context
of the template's definition changes, both get recompiled. That's why,
if the template definition changes, we have to go back to all the
points of instantiation and rebuild those translation units. (In the
case of the EDG compiler, the compiler recompiles all the calling
translation units needed to recreate every distinct specialization, in
order to recreate all of the instantiation contexts, and for each of
those calling translation units it also recompiles the file containing
the template definition in order to recreate the definition context.)
"

http://www.gotw.ca/publications/mill23-x.htm

and this is also interesting:

http://www.ddj.com/showArticle.jhtml?articleID=184401584#1

Greetings, Branimir

[James Kanze]

Re: C or C++?

On May 21, 11:49 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

James Kanze wrote:

On May 21, 1:11 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

...

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.

I think your reply indicates I didn't make my point.

... I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.

The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation

Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream " compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

but I suspect that debugging
will need to be worked out as well.

It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

... It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: C or C++?

On May 21, 11:49 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

James Kanze wrote:

On May 21, 1:11 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

...

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.

I think your reply indicates I didn't make my point.

... I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.

The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation

Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream " compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

but I suspect that debugging
will need to be worked out as well.

It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

... It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: C or C++?

On May 21, 11:49 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

James Kanze wrote:

On May 21, 1:11 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

...

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.

I think your reply indicates I didn't make my point.

... I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.

The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation

Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream " compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

but I suspect that debugging
will need to be worked out as well.

It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

... It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: C or C++?

On May 21, 11:49 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

James Kanze wrote:

On May 21, 1:11 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

...

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.

I think your reply indicates I didn't make my point.

... I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.

The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation

Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream " compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

but I suspect that debugging
will need to be worked out as well.

It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

... It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: C or C++?

On May 21, 11:49 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

James Kanze wrote:

On May 21, 1:11 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

...

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.

I think your reply indicates I didn't make my point.

... I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.

The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation

Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream " compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

but I suspect that debugging
will need to be worked out as well.

It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

... It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[JohnQ]

Re: C or C++?


"Branimir Maksimovic" <bmaxa@hotmail. comwrote in message
news:1179575126 .204954.309490@ k79g2000hse.goo glegroups.com.. .

C++ class is same thing as struct.

It would probably be better to make the two concepts (whatever they are)
separate. If they were different animals, how would you (anyone here)
distinguish the two for the better?

John

[JohnQ]

Re: C or C++?


"James Kanze" <james.kanze@gm ail.comwrote in message
news:1179731466 .398784.300790@ x35g2000prf.goo glegroups.com.. .

What I just said: there is no real technical reason for not
implementing export today. It does require a certain amount of
effort (i.e. cost), but nothing a company like Microsoft
couldn't easily afford.

And you think that a language spec that only mega-corps can implement is OK?

John

[red floyd]

Re: C or C++?

JohnQ wrote:

"James Kanze" <james.kanze@gm ail.comwrote in message
news:1179731466 .398784.300790@ x35g2000prf.goo glegroups.com.. .
>

>What I just said: there is no real technical reason for not
>implementing export today. It does require a certain amount of
>effort (i.e. cost), but nothing a company like Microsoft
>couldn't easily afford.

>
And you think that a language spec that only mega-corps can implement is OK?
>

Comeau implements export. I'd hardly call Comeau a mega-corp. No
offense intended to Greg.

[JohnQ]

Re: C or C++?


"red floyd" <no.spam@here.d udewrote in message
news:INJ4i.2081 $u56.1490@newss vr22.news.prodi gy.net...

JohnQ wrote:

>"James Kanze" <james.kanze@gm ail.comwrote in message
>news:117973146 6.398784.300790 @x35g2000prf.go oglegroups.com. ..
>>

>>What I just said: there is no real technical reason for not
>>implementin g export today. It does require a certain amount of
>>effort (i.e. cost), but nothing a company like Microsoft
>>couldn't easily afford.

>>
>And you think that a language spec that only mega-corps can implement is
>OK?
>>

>
Comeau implements export. I'd hardly call Comeau a mega-corp. No offense
intended to Greg.

It's already been noted though that they are "gifted"
(intellectually/technically) over at Comeau. If it's inaccessible to "the
layman", it's probably just as bad. If 'export' has to do with dynamic
linking, it sounds like something I want. If it goes "way overboard" into
binary compatibilty of objects, I can probably do without it.

John

[Gianni Mariani]

Re: C or C++?

On May 23, 8:35 am, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
wrote:

"red floyd" <no.s...@here.d udewrote in message
>
news:INJ4i.2081 $u56.1490@newss vr22.news.prodi gy.net...
>

JohnQ wrote:

"James Kanze" <james.ka...@gm ail.comwrote in message
>news:117973146 6.398784.300790 @x35g2000prf.go oglegroups.com. ..

>

>What I just said: there is no real technical reason for not
>implementing export today. It does require a certain amount of
>effort (i.e. cost), but nothing a company like Microsoft
>couldn't easily afford.

>

And you think that a language spec that only mega-corps can implement is
OK?

>

Comeau implements export. I'd hardly call Comeau a mega-corp. No offense
intended to Greg.

>
It's already been noted though that they are "gifted"
(intellectually/technically) over at Comeau. If it's inaccessible to "the
layman", it's probably just as bad. If 'export' has to do with dynamic
linking, it sounds like something I want. If it goes "way overboard" into
binary compatibilty of objects, I can probably do without it.
>
John

It may be easier to implement a binary independant format. If you're
generating code, you may as well generate all the code rather than
some of the code.

Having said that, there are some interesting new failure modes that
need to be considered.

[Carlo Milanesi]

Re: C or C++?

Herhor wrote:

An antiquated C language is now outdated and only old lazy coders who
can't understand and learn object oriented languages seek naive persons
to hire them as a new C programmers.

Are coders who seek persons to hire as programmers? No, they are
managers or businessmen.

In reality now 95% professional code is written in C++ not C.

Where did you get such figures? I look here, where C looks still more
popular than C++:

http://www.tiobe.com/index.htm?tiobe_index

Perhaps, most C programmers now build embedded systems or device
drivers, and few build applications for Windows or Unix, but
nevertheless they are professional computer programmers.

--
Carlo Milanesi

http://digilander.libero.it/carlmila

[Herhor]

Re: C or C++?

Carlo Milanesi pisze:

Herhor wrote:

>An antiquated C language is now outdated and only old lazy coders who
>can't understand and learn object oriented languages seek naive
>persons to hire them as a new C programmers.

Are coders who seek persons to hire as programmers? No, they are
managers or businessmen.
>

It is simple! There are business managers who hired old C coders to seek
naive beginning programmers to hire them as their programming in C
successors.

>In reality now 95% professional code is written in C++ not C.

Where did you get such figures? I look here, where C looks still more
popular than C++:

http://www.tiobe.com/index.htm?tiobe_index

Perhaps, most C programmers now build embedded systems or device
drivers, and few build applications for Windows or Unix, but
nevertheless they are professional computer programmers.
>

Because I didn't take into account programming cell phones, iPods,
microwave kitchens and similar shit but computer systems only.
Moreover, firstly as for now C competes mainly _with Java_ not C++ in
the embedded systems area, secondly _many people_ don't know that it is
possible to write OS kernels, device drivers or embedded programs in C++
which are *more compact and efficient* than similar ones wrote in C!

[Herhor]

Re: C or C++?

Carlo Milanesi pisze:

>In reality now 95% professional code is written in C++ not C.

I look here, where C looks still more popular than C++:

http://www.tiobe.com/index.htm?tiobe_index

>

Additionally this rating is idiotic!
How can they compare native programming languages (C, C+), interpreted
languages (C#, Java) and Internet script pseudo-languages (PHP, Perl,
Javascript) regardless of their structural differences and very diverse
area of application???

[Default User]

Re: C or C++?

Carlo Milanesi wrote:

Herhor wrote:

In reality now 95% professional code is written in C++ not C.

Where did you get such figures?

This guy's a troll, just ignore him.




Brian