Why We Use C Than C++...

[sonugeetha]

Hi, Please help me in this regard...
All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++... I personally feel that C++ is
more easy to code than C... When i searched in our encyclopedia (i.e
Google), i came up with several answers, telling "C is much faster than
C++ and most kernal prgms uses only C" ... But why is it so...? Why
they use C for these OS based programs.. Please Help me with detailed
explanation...

Cheers,
Balaji Jayaraman...

[Richard Heathfield]

Keith Thompson said:

[Prefixing] is a fairly ugly solution, and not all library
authors follow it.

<OT>
C++'s namespace facility provides a cleaner way around this. For
example, an "xyz" library might put all its symbols in the "xyz"
namespace, giving symbol names like "xyz::create()". The difference
is that it's a feature built into the language, making it easier to
use and harder to avoid, and you can refer to the function as just
"create()" if you want to. (I don't use C++, so I could be missing
something.)
</OT>

What you're missing is that it doesn't solve the problem, because Company A
and Company B can each wrap their libraries in the same namespace. This is
easily done, simply by not consulting each other when choosing a name for
the namespace. It probably doesn't happen much, but it probably does
happen!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Imre Palik said:

Richard Heathfield <in*****@invalid.invalid> writes:

> Ok, and then write me a working equivalent to the C++ template
> mechanism... ;o)

Why bother?

To spare a few hundred lines of code?

<shrug> Not for me. I'm not afraid of void *.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Logan Shaw]

Richard Heathfield wrote:

Walter Bright said:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...

Partly because C is faster (in places).

I'm not aware of any places where, compiling the same source code, it's
faster.

If you're using the same source code with identical semantics, it's true
that there's no particular reason for one to be faster than the other. But,
if you're using the same source code with identical semantics, why bother
with C++?

That's a good point. But, C++ has about 14 billion extra features
beyond that which C has. If restricting yourself to the C-like features
carries no performance penalty, doesn't it seem likely that at least a
few useful C++-only features have no performance penalty compared to
equivalent way of doing things in C?

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write? Also, will the compiler catch
the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));

Also templates carry no overhead compared to doing the equivalent
thing in C. In some cases, they can even make it easier to make
fast code. Say, for example, you need to implement sets of floats
and ints. With C, you write everything twice or you wastefully
store everything as void * values that point to the actual data.
C++ templates let you write the code only once and avoid the
performance penalties of dealing with pointers when you want to
deal directly with the native types. Of course, templates can
easily get out of control and lead to bloat, but they don't have
to if you use them wisely.

- Logan

[Malcolm]

"Logan Shaw" <ls**********@austin.rr.com> wrote

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write? Also, will the compiler catch
the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));

Sure, but then you've got to remember whether to free() or delete your
array.
Also, you can overload the new operator to use a custom memory allocation
scheme. Care to tell me how to do this without looking it up?

Then you'll find that the consensus nowadays is that new is deprecated, you
should be using an stl vector instead.

These are the sorts of problems you get with a move to C++. A few benefits,
such as "new" being easier to type than "malloc()", are trivial in
comparison.

[Michael Mair]

Logan Shaw wrote:

Richard Heathfield wrote:

Walter Bright said:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com... Partly because C is faster (in places). I'm not aware of any places where, compiling the same source code, it's
faster.

If you're using the same source code with identical semantics, it's
true that there's no particular reason for one to be faster than the
other. But, if you're using the same source code with identical
semantics, why bother with C++?

That's a good point. But, C++ has about 14 billion extra features
beyond that which C has. If restricting yourself to the C-like features
carries no performance penalty, doesn't it seem likely that at least a
few useful C++-only features have no performance penalty compared to
equivalent way of doing things in C?

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write? Also, will the compiler catch
the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));

*sigh*
That is why _C_ people write

T *p = malloc(size * sizeof *p);

Of course, you can do it the wrong way, as you demonstrated it,
but using the handle of the screwdriver to hammer down the screw
being peculiar at best does not convince me that using a screwdriver
with screws leads to nailed down screws.
Also templates carry no overhead compared to doing the equivalent
thing in C. In some cases, they can even make it easier to make
fast code. Say, for example, you need to implement sets of floats
and ints. With C, you write everything twice or you wastefully
store everything as void * values that point to the actual data.
C++ templates let you write the code only once and avoid the
performance penalties of dealing with pointers when you want to
deal directly with the native types. Of course, templates can
easily get out of control and lead to bloat, but they don't have
to if you use them wisely.

Agreed. Without a typeof operator or similar, C cannot match the
power of templates. Considering the number of template classes
and functions in a >1MLoC project I am involved in, the choice for
C++ certainly was not made because of templates but exactly in order
to have virtual functions, RTTI, etc such that design patterns can
be easily implemented.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard Heathfield]

Logan Shaw said:

Richard Heathfield wrote:

Walter Bright said:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com... Partly because C is faster (in places). I'm not aware of any places where, compiling the same source code, it's
faster.

If you're using the same source code with identical semantics, it's true
that there's no particular reason for one to be faster than the other.
But, if you're using the same source code with identical semantics, why
bother with C++?

That's a good point. But, C++ has about 14 billion extra features
beyond that which C has.

If you want those features, use C++.
If restricting yourself to the C-like features
carries no performance penalty, doesn't it seem likely that at least a
few useful C++-only features have no performance penalty compared to
equivalent way of doing things in C?
Put it this way: when I select C++ over C, my reasoning is not "this will be
no slower than C". Rather, it is "I am sufficiently desperate to use a C++
feature that it overcomes my innate preference for C".

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write?
int *i = malloc(100 * sizeof *i);

(My fingers have it down pat now, and I can type it much faster than I can
type either of your choices.)

Also, will the compiler catch
the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));

Let's see:

double *i = malloc(100 * sizeof *i);

Seems correct to me.

<snip>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Bjørn Augestad]

Logan Shaw wrote:
[snip]

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write?
Straw-mans argument, the proper way to do this in C is to write
int *i = malloc(100 * sizeof *i);

Now try to deallocate the memory in C++, how do you do that?
delete i;
or maybe
delete[] i;

Pretty inconsistent, isn't it, and also a common source to memory leaks,
IIRC.

Also, will the compiler catch the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));
Not an issue, see above.

Also templates carry no overhead compared to doing the equivalent
thing in C.
No size overhead either?
In some cases, they can even make it easier to make
fast code. Say, for example, you need to implement sets of floats
and ints. With C, you write everything twice or you wastefully
store everything as void * values that point to the actual data.
C++ templates let you write the code only once and avoid the
performance penalties of dealing with pointers when you want to
deal directly with the native types.
If *profiling* shows that this really is an issue, it can be solved.
Of course, templates can
easily get out of control and lead to bloat, but they don't have
to if you use them wisely.

Which is one of the major problems with C++, too many pitfalls.

Bjørn

[Keith Thompson]

Logan Shaw <ls**********@austin.rr.com> writes:
[...]

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write? Also, will the compiler catch
the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));

No, which is why the recommended way of writing that is

double *d = malloc(100 * sizeof *d);

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ian]

Malcolm wrote:

Sure, but then you've got to remember whether to free() or delete your
array.
That's one of the great benefits of C++, you don't if you use a smart
pointer. Smart pointer are a great way of removing memory leeks.
Also, you can overload the new operator to use a custom memory allocation
scheme. Care to tell me how to do this without looking it up?
void* operator new( size_t n ) throw( std::bad_alloc );
Then you'll find that the consensus nowadays is that new is deprecated, you
should be using an stl vector instead.
Is it? No one's told me... how do you think vector gets its memory?
These are the sorts of problems you get with a move to C++. A few benefits,
such as "new" being easier to type than "malloc()", are trivial in
comparison.

These being?

Ian

[Walter Bright]

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq*********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...

Walter Bright said:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...

Partly because C is faster (in places).

I'm not aware of any places where, compiling the same source code, it's
faster.

If you're using the same source code with identical semantics, it's true
that there's no particular reason for one to be faster than the other.
But, if you're using the same source code with identical semantics, why
bother
with C++?

It's perfectly reasonable to use C++ to pick and choose what features you
might want to use. It's clear that simply using a C++ compiler is not going
to slow your code down. There are many valid reasons why one might choose to
stick with C rather than C++, but performance isn't one of them.

There is one case where using a C++ compiler for C code may increase
performance - C++ uses a different function calling convention than C, a
faster one. The reason C compilers don't adopt it is for binary
compatibility with C compilers that predate function prototypes. The
difference (callee cleans the stack, rather than the caller) can amount to 1
to 3%. (Yes, I've measured it <g>.)

Walter Bright
www.digitalmars.com C, C++, D programming language compilers

[Richard Heathfield]

Walter Bright said:

It's perfectly reasonable to use C++ to pick and choose what features you
might want to use.

If you want to use C++-specific features, clearly you will need a C++
compiler. I don't think anyone is disputing that.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ulrich Eckhardt]

Logan Shaw wrote:

If restricting yourself to the C-like features
carries no performance penalty, doesn't it seem likely that at least a
few useful C++-only features have no performance penalty compared to
equivalent way of doing things in C?

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

Yes there is. operator new[] will throw an exception when it fails, so the
'equivalent' in C at least requires some error checking.

Also, let's not use bad programming habits as example, both your lines are
examples of bad code.

// C++
std::tr1::scoped_array<int> i(new int[size]);

// C
int* i = malloc( size * (sizeof (int)));
if(!i)
return ENOMEM;

Uli

[Ulrich Eckhardt]

Keith Thompson wrote:

C++'s namespace facility provides a cleaner way around this. For
example, an "xyz" library might put all its symbols in the "xyz"
namespace, giving symbol names like "xyz::create()". The difference
is that it's a feature built into the language, making it easier to
use and harder to avoid, and you can refer to the function as just
"create()" if you want to. (I don't use C++, so I could be missing
something.)

Almost. Normally, you can refer to a symbol in a namespace only explicitly
via 'xyz::symbol', not just with 'symbol'. However, you can manipulate the
current context a bit: 'using namespace xyz;' will make the compiler
search the whole namespace when looking for a symbol, 'using xyz::symbol;'
will only import that particular symbol into the current context.

When you write code that is in a namespace, that namespace is implicitly
added to the list of searched namespaces.

When you call a function, it is also looked for in the namespace(s) of its
argument(s).

You can nest namespaces, i.e. declare another namespace inside a namespace.

You can do aliasing like with typedef. E.g. a fictitious library 'webtools'
for web related stuff containing code in several namespaces:
namespace smtp = webtools::protocols::smtp;
smtp::query q; // refers to webtools::protocols::smtp::query

So much for a short overview of C++ namespaces.

Uli

[Mark McIntyre]

On Fri, 13 Jan 2006 21:26:49 -0800, in comp.lang.c , "Walter Bright"
<wa****@nospamm-digitalmars.com> wrote:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...

Partly because C is faster (in places).

I'm not aware of any places where, compiling the same source code, it's
faster.

I am. The overhead however isn't inherent in C or C++, its to do with
the implementation and how libraries are loaded - some C++ compilers
I've met like an app to load all their libraries at startup, even if
you don't need all the functions in them...
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Sat, 14 Jan 2006 08:00:53 GMT, in comp.lang.c , Logan Shaw
<ls**********@austin.rr.com> wrote:

That's a good point. But, C++ has about 14 billion extra features
beyond that which C has.

Possibly true, but irrelevant. Obviously, if you use those features,
the C++ app is likely to run slower than the "hello world" C app...
:-)

Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Sat, 14 Jan 2006 22:57:25 +1300, in comp.lang.c , Ian
<ia******@hotmail.com> wrote:

Malcolm wrote:

Then you'll find that the consensus nowadays is that new is deprecated, you
should be using an stl vector instead.

Is it? No one's told me... how do you think vector gets its memory?

How the implementation does something is not relevant - it could use
black magic for all you care. Personally I strongly suspect that on
intel architectures, its calling the low level malloc function....

Enough of the stupid C vs C++ war. Both languages have their place.
This thread was probably started by a troll, lets just all killfile
it.
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Walter Roberson]

In article <42*************@uni-berlin.de>,
Ulrich Eckhardt <do******@knuut.de> wrote:

Logan Shaw wrote:

If restricting yourself to the C-like features
carries no performance penalty, doesn't it seem likely that at least a
few useful C++-only features have no performance penalty compared to
equivalent way of doing things in C? For example, C++ allows you to do this:
int *i = new int[100];
There is no reason the performance of this should be any worse than
the C equivalent:
int *i = (int *) malloc (100 * sizeof (int));

Yes there is. operator new[] will throw an exception when it fails, so the
'equivalent' in C at least requires some error checking.

I'm not sure if you are arguing for or against the proposition there ;-)

As you point out, new[] will throw exceptions -- and that means you
need the overhead of exception support, unless you are *sure*
you aren't going to catch the exception (which would require
a lot of intra-procedural analysis.) From what I've read, the
overheads of exception support are quite high.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

[Walter Roberson]

In article <-I********************@comcast.com>,
Walter Bright <wa****@nospamm-digitalmars.com> wrote:

There is one case where using a C++ compiler for C code may increase
performance - C++ uses a different function calling convention than C, a
faster one. The reason C compilers don't adopt it is for binary
compatibility with C compilers that predate function prototypes. The
difference (callee cleans the stack, rather than the caller) can amount to 1
to 3%. (Yes, I've measured it <g>.)

Ah? Could you post the relevant section numbers of the C and C++
standards that mandate particular calling conventions? Or, for
that matter, the section number of the C standard that mandates
that a "stack" exist at all ?
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

[Ian]

Walter Roberson wrote:

Yes there is. operator new[] will throw an exception when it fails, so the
'equivalent' in C at least requires some error checking.

I'm not sure if you are arguing for or against the proposition there ;-)

As you point out, new[] will throw exceptions -- and that means you
need the overhead of exception support, unless you are *sure*
you aren't going to catch the exception (which would require
a lot of intra-procedural analysis.) From what I've read, the
overheads of exception support are quite high.

Don't forget we are talking about kernel programming. In this domain
you don't have the luxury of run time support, so you provide your own
new and delete operators. The signature may have an exception
specification, but you don't have to use it.

Ian

[Walter Bright]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:dq**********@canopus.cc.umanitoba.ca...

In article <-I********************@comcast.com>,
Walter Bright <wa****@nospamm-digitalmars.com> wrote:

There is one case where using a C++ compiler for C code may increase
performance - C++ uses a different function calling convention than C, a
faster one. The reason C compilers don't adopt it is for binary
compatibility with C compilers that predate function prototypes. The
difference (callee cleans the stack, rather than the caller) can amount to
1
to 3%. (Yes, I've measured it <g>.)

Ah? Could you post the relevant section numbers of the C and C++
standards that mandate particular calling conventions? Or, for
that matter, the section number of the C standard that mandates
that a "stack" exist at all ?

We're talking about performance of using C vs C++ for a project. Nothing in
either standard mandates a word about performance, and nobody said they did.
However, in the real world for real CPUs and real compilers, that
implementation difference does exist for the reasons mentioned. The C++
standard does allow for a difference in calling convention with the extern
"C" construct.

There's a lot more to picking a language for a particular project than what
the standard says.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers

[Keith Thompson]

Ulrich Eckhardt <do******@knuut.de> writes:

Keith Thompson wrote:

C++'s namespace facility provides a cleaner way around this. For
example, an "xyz" library might put all its symbols in the "xyz"
namespace, giving symbol names like "xyz::create()". The difference
is that it's a feature built into the language, making it easier to
use and harder to avoid, and you can refer to the function as just
"create()" if you want to. (I don't use C++, so I could be missing
something.)
Almost. Normally, you can refer to a symbol in a namespace only explicitly
via 'xyz::symbol', not just with 'symbol'. However, you can manipulate the
current context a bit: 'using namespace xyz;' will make the compiler
search the whole namespace when looking for a symbol, 'using xyz::symbol;'
will only import that particular symbol into the current context.

Right, that's what I meant by "if you want to".

[...]
You can do aliasing like with typedef. E.g. a fictitious library 'webtools'
for web related stuff containing code in several namespaces:
namespace smtp = webtools::protocols::smtp;
smtp::query q; // refers to webtools::protocols::smtp::query

One more question. In C, if two libraries use the same identifier,
it's difficult or impossible for a program to use both libraries.
Using a library-specific prefix can avoid this, but if two libraries
use the same prefix you still have the same problem.

Suppose two C++ libraries use the same namespace identifier, say
"foo". Is it possible to use both libraries by aliasing one or both
of the namespaces? For example, could the program refer to one
namespace as "foo1" and the other as "foo2"?

Without such a feature, namespaces are useful, but all they really do
is encourage some structure in naming and allow abbreviations in some
cases; the don't give you anything you couldn't do in C with some
extra work. With such a feature, they would solve a problem that
can't really be solved in C, which could be an argument (here's where
it becomes marginally topical) for adding C++-style namespaces to a
future C standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Logan Shaw]

Bjørn Augestad wrote:

Logan Shaw wrote:

Also templates carry no overhead compared to doing the equivalent
thing in C.

No size overhead either?

Nope, no size overhead, because the equivalent thing is to implement
a set of functions twice, once for each type that must be dealt with.
Whether you do this manually in C or have the compiler do it for you
automatically in C++, it still results in two chunks of object code
that are very similar.

Granted, it's not all that often that you encounter a situation
where you need to do that, but it can happen, and C++ could make
your life easier in that case, without reducing the performance
or increasing the size of the executable.

I realize this is not a common problem, but my whole point here is
this: most people already agree that putting the same code through
a C and a C++ compiler will result in similar speeds in the output.
I am just trying to establish that it is possible to have similar
speed (and code size) when using some C++-only features. Once
that is established, there is no argument that using C++ leads to
bad performance; it becomes an argument against using certain slow
C++ features leads to bad performance, not an argument against C++
in general.

Also, I apologize for my poor malloc() style that about 10 people
pointed out. :-) Obviously, I've gotten into a habit of doing it
in a bad way. I think it may be because I ran into a compiler that
would only allow the type name in sizeof() years ago, although that
is obviously not a good reason to keep doing it...

- Logan

[Ian]

Keith Thompson wrote:

You can do aliasing like with typedef. E.g. a fictitious library 'webtools'
for web related stuff containing code in several namespaces:
namespace smtp = webtools::protocols::smtp;
smtp::query q; // refers to webtools::protocols::smtp::query

One more question. In C, if two libraries use the same identifier,
it's difficult or impossible for a program to use both libraries.
Using a library-specific prefix can avoid this, but if two libraries
use the same prefix you still have the same problem.

Suppose two C++ libraries use the same namespace identifier, say
"foo". Is it possible to use both libraries by aliasing one or both
of the namespaces? For example, could the program refer to one
namespace as "foo1" and the other as "foo2"?

One solution would be to wrap one within another namespace, for example

foo1.h:

namesapce foo1
{
# include "someFoo.h"
}

foo1::foo::fun();

Ian

[Malcolm]

"Ian" <ia******@hotmail.com> wrote

Then you'll find that the consensus nowadays is that new is deprecated,
you should be using an stl vector instead.

Is it? No one's told me... how do you think vector gets its memory?

This is exactly the sort of problems people have.
You're out of date and no one has bothered to tell you.

The modern consenus is that arrays shouldn't be used, and (less firm)
objects shouldn't be allocated with new. You should use a managed array
instead.

Once you start trying to mix arrays and dymanic objects with stl controlled
sequences, you really get into trouble. Hence the wisdom of the rule.

Of course if you are implenting a controlled sequence, there must be some
way of getting the memory - so that would be the one exception.

[Walter Bright]

"Ulrich Eckhardt" <do******@knuut.de> wrote in message
news:42*************@uni-berlin.de...

Logan Shaw wrote:

For example, C++ allows you to do this:
int *i = new int[100];

Also, let's not use bad programming habits as example, both your lines are
examples of bad code.

// C++
std::tr1::scoped_array<int> i(new int[size]);

This modern trend of C++ to deprecate the straightforward constructs and
replace them with tedious ones is going to drive the language towards
unusability.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers

[Thad Smith]

Walter Bright wrote:

There is one case where using a C++ compiler for C code may increase
performance - C++ uses a different function calling convention than C, a
faster one. The reason C compilers don't adopt it is for binary
compatibility with C compilers that predate function prototypes.

How important is binary compatibility with an older compiler? It
would seem normal to recompile source for new compilers. Aren't there
differences between compilers that pass some parameters in registers
vs. all on stack? In C, you could easily use called function stack
cleanup for all non-variadic functions, I would think. The compiler
could even have a compatibility mode, for caller cleanup, and
different entry point naming prefix for faster calling mode, couldn't
it?

--
Thad

[jacob navia]

Keith Thompson a écrit :

Logan Shaw <ls**********@austin.rr.com> writes:
[...]

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write? Also, will the compiler catch
the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));

No, which is why the recommended way of writing that is

double *d = malloc(100 * sizeof *d);

better
double *d = malloc( sizeof(double[100]) );

[Ian]

Malcolm wrote:

"Ian" <ia******@hotmail.com> wrote

Then you'll find that the consensus nowadays is that new is deprecated,
you should be using an stl vector instead.

Is it? No one's told me... how do you think vector gets its memory?

This is exactly the sort of problems people have.
You're out of date and no one has bothered to tell you.

Nope, C++ (along with C and others) is my bread and butter, so I keep up
to date.
The modern consenus is that arrays shouldn't be used, and (less firm)
objects shouldn't be allocated with new. You should use a managed array
instead.
Ah, now I see your context. Yes, this has been the case for since the
STL became part of the language standard. However, containers are often
used to hold (ideally managed) dynamic objects.
Once you start trying to mix arrays and dymanic objects with stl controlled
sequences, you really get into trouble. Hence the wisdom of the rule.
Hence smart pointers, the 'modern' way of managing the lifetime of
dynamic objects. There is no need in C++ to work with raw pointers. As
I've said before on this thread, the is very useful feature in kernel code.
Of course if you are implenting a controlled sequence, there must be some
way of getting the memory - so that would be the one exception.

Exactly, by providing one's own new and delete operators, code can more
easily be moved from one environment (user space) to another (kernel space).

Ian

[Walter Bright]

"Thad Smith" <Th*******@acm.org> wrote in message
news:43***************@acm.org...

Walter Bright wrote:

There is one case where using a C++ compiler for C code may increase
performance - C++ uses a different function calling convention than C, a
faster one. The reason C compilers don't adopt it is for binary
compatibility with C compilers that predate function prototypes.
How important is binary compatibility with an older compiler?

Critical. For example, the operating system ABI's are normally C interfaces.
It would seem normal to recompile source for new compilers. Aren't there
differences between compilers that pass some parameters in registers
vs. all on stack? In C, you could easily use called function stack
cleanup for all non-variadic functions, I would think. The compiler
could even have a compatibility mode, for caller cleanup, and
different entry point naming prefix for faster calling mode, couldn't
it?

Many C compilers offer extensions for more efficient calling sequences, but
they are non-standard.

Walter Bright
www.digitalmars.com C, C++, D programming language compilers

[Walter Roberson]

In article <Hc********************@comcast.com>,
Walter Bright <wa****@nospamm-digitalmars.com> wrote:

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:dq**********@canopus.cc.umanitoba.ca...

In article <-I********************@comcast.com>,
Walter Bright <wa****@nospamm-digitalmars.com> wrote:

There is one case where using a C++ compiler for C code may increase
performance - C++ uses a different function calling convention than C, a
faster one. The reason C compilers don't adopt it is for binary
compatibility with C compilers that predate function prototypes. The
difference (callee cleans the stack, rather than the caller) can amount to
1 to 3%. (Yes, I've measured it <g>.)

Ah? Could you post the relevant section numbers of the C and C++
standards that mandate particular calling conventions?

We're talking about performance of using C vs C++ for a project. Nothing in
either standard mandates a word about performance, and nobody said they did.
However, in the real world for real CPUs and real compilers, that
implementation difference does exist for the reasons mentioned.
You stated that "C++ uses a different function calling convention than C".
You admit that the standards say nothing about calling conventions,
but try to justify your statement by saying that the differences DOES
exist.

Your statement is readily disproved.

SGI IRIX 6.5 with the N32 or 64 ABI uses the same calling convention
for ALL languages.

http://techpubs.sgi.com/library/tpl/...html/ch07.html

I'm not quite sure what you mean by "callee cleans the stack",
but step 8 of the N32 and 64 ABI for IRIX is "Clean up the stack"
which occurs immediately before step 9, "return".

There's a lot more to picking a language for a particular project than what
the standard says.

So you had a good experience with ONE C++ compiler. That's nice.
And it proves nothing about how C or C++ generally handle calling
conventions.

If you had said that "On -some- systems, C++ does X while C does Y"
then you might have been correct... but that's obviously a
QOI issue and other compilers might have completely diferent
QOI's.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

[Sjouke Burry]

Malcolm wrote:

"Ian" <ia******@hotmail.com> wrote

Then you'll find that the consensus nowadays is that new is deprecated,
you should be using an stl vector instead.

Is it? No one's told me... how do you think vector gets its memory?

This is exactly the sort of problems people have.
You're out of date and no one has bothered to tell you.

The modern consenus is that arrays shouldn't be used, and (less firm)
objects shouldn't be allocated with new. You should use a managed array
instead.

Once you start trying to mix arrays and dymanic objects with stl controlled
sequences, you really get into trouble. Hence the wisdom of the rule.

Of course if you are implenting a controlled sequence, there must be some
way of getting the memory - so that would be the one exception.

C++? C++? C++? C++? (Or wat are you talking about?)
Also I have used arrays (with no memory leak)
and avoided malloc successfully for the last 30+
years.
Malloc is fine if you need to build/shrinck
structures for exsample ,but it it not the
cure for every problem.
Use language features when you need them,and
not because somebody tells you they are the
latest and greatest.

[Thad Smith]

Walter Bright wrote:

"Thad Smith" <Th*******@acm.org> wrote in message

In C, you could easily use called function stack
cleanup for all non-variadic functions, I would think. The compiler
could even have a compatibility mode, for caller cleanup, and
different entry point naming prefix for faster calling mode, couldn't
it?

Many C compilers offer extensions for more efficient calling sequences, but
they are non-standard.

By non-standard, I assume you mean not compatible with older compilers,
not non-compliant with the C standard.

--
Thad

[Walter Bright]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:dq**********@canopus.cc.umanitoba.ca...

You admit that the standards say nothing about calling conventions,

"Admit", LOL!

[Michael Mair]

jacob navia wrote:

Keith Thompson a écrit :

Logan Shaw <ls**********@austin.rr.com> writes: <snip>

double *d = (double *) malloc (100 * sizeof (int));

No, which is why the recommended way of writing that is

double *d = malloc(100 * sizeof *d);

better
double *d = malloc( sizeof(double[100]) );

Nope; you missed the point (not accidentally, I am sure).
The aim is to avoid a second mention of the type, so that
type changes or copy-paste(-disaster) cannot cause errors.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Emmanuel Delahaye]

so********@gmail.com a écrit :

Hi, Please help me in this regard...
All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++... I personally feel that C++ is
more easy to code than C... When i searched in our encyclopedia (i.e
Google), i came up with several answers, telling "C is much faster than
C++ and most kernal prgms uses only C" ... But why is it so...? Why
they use C for these OS based programs.. Please Help me with detailed
explanation...

AFAIK, C was invented before C++. The main systems (Unix, Linux,
Windows) have been written in C, just because C was considered as a
'portable assembler', allowing to drive the hardware (with some
extensions) on one hand, and to provide a sufficient level of
abstraction to build portable interfaces (API).

If this is possible in some other language, there is nothing that
prevents you to write a new system from scratch using this language
(except time and money, I guess). Good luck.

--
A+

Emmanuel Delahaye

[Ulrich Eckhardt]

Walter Roberson wrote:

In article <42*************@uni-berlin.de>,
Ulrich Eckhardt <do******@knuut.de> wrote:

Logan Shaw wrote:

For example, C++ allows you to do this:
int *i = new int[100];
There is no reason the performance of this should be any worse than
the C equivalent:
int *i = (int *) malloc (100 * sizeof (int));Yes there is. operator new[] will throw an exception when it fails,
so the 'equivalent' in C at least requires some error checking.

I'm not sure if you are arguing for or against the proposition there ;-)

There is a comparison between two non-equivalent pieces of code, so using
this as a measure for speed is just flawed. That's all I wanted to point
out.
Also, BTW, instead of saying exceptions are an overhead, you could as well
say that not having them is a disadvantage.
From what I've read, the overheads of exception support are quite high.

Can you give a quote/URL? From what I know, there is indeed an overhead and
early implementations of C++ didn't perform too well, but better
implementations have made the cost when not throwing an exception
negligible.

Uli

[Ulrich Eckhardt]

Keith Thompson wrote:

Ulrich Eckhardt <do******@knuut.de> writes:

You can do aliasing like with typedef. E.g. a fictitious library
'webtools' for web related stuff containing code in several
namespaces:
namespace smtp = webtools::protocols::smtp;
smtp::query q; // refers to webtools::protocols::smtp::query
One more question. In C, if two libraries use the same identifier,
it's difficult or impossible for a program to use both libraries.
Using a library-specific prefix can avoid this, but if two libraries
use the same prefix you still have the same problem.

Suppose two C++ libraries use the same namespace identifier, say
"foo". Is it possible to use both libraries by aliasing one or both
of the namespaces? For example, could the program refer to one
namespace as "foo1" and the other as "foo2"?

No. Those namespace aliases are just that, just as a typedef is just an
alias and doesn't change the symbol emitted to the linker (with the
exception of typedef'ing an anonymous type).

Ian, your solution doesn't work, it changes the declarations found in a
header, but it still doesn't change the symbols exported from a library.

No, I think in order to shoehorn two conflicting two libs into one program
one needs to resort to things like changing the linker symbols manually or
writing a wrapper lib that consists of a bunch of forwarding functions
with just a different name.
Without such a feature, namespaces are useful, but all they really do
is encourage some structure in naming and allow abbreviations in some
cases; the don't give you anything you couldn't do in C with some
extra work. With such a feature, they would solve a problem that
can't really be solved in C, which could be an argument (here's where
it becomes marginally topical) for adding C++-style namespaces to a
future C standard.

I'm not sure that otherwise they wouldn't be worthwhile adding. Point is
that they could be added without breaking any existing code, they are
definitely no runtime overhead, because just a different syntax, and I
think they would indeed solve problems for which there is no solution:
Think about for example the Apache portable runtime library. If it had
used apache_runtime (let's just drop the portable) as prefix, everyone
would have to write
apache_runtime_file* f = apache_runtime_open("fou.texte");
Tedious. Very. That's the reason they chose apr_ as a prefix, which is much
shorter but then again bears the danger of conflicting. Using namespaces,
you could alias namespace apache::portable_runtime to just apr when using
it.

Uli

[Ian Collins]

Ulrich Eckhardt wrote:

Suppose two C++ libraries use the same namespace identifier, say
"foo". Is it possible to use both libraries by aliasing one or both
of the namespaces? For example, could the program refer to one
namespace as "foo1" and the other as "foo2"?

No. Those namespace aliases are just that, just as a typedef is just an
alias and doesn't change the symbol emitted to the linker (with the
exception of typedef'ing an anonymous type).

Ian, your solution doesn't work, it changes the declarations found in a
header, but it still doesn't change the symbols exported from a library.

Yes, you are correct, my mistake.
No, I think in order to shoehorn two conflicting two libs into one program
one needs to resort to things like changing the linker symbols manually or
writing a wrapper lib that consists of a bunch of forwarding functions
with just a different name.

This would be the only workable solution.

--
Ian Collins.

[Keith Thompson]

Ian Collins <ia******@hotmail.com> writes:

Ulrich Eckhardt wrote:

Suppose two C++ libraries use the same namespace identifier, say
"foo". Is it possible to use both libraries by aliasing one or both
of the namespaces? For example, could the program refer to one
namespace as "foo1" and the other as "foo2"?

No. Those namespace aliases are just that, just as a typedef is just
an
alias and doesn't change the symbol emitted to the linker (with the
exception of typedef'ing an anonymous type).
Ian, your solution doesn't work, it changes the declarations found
in a
header, but it still doesn't change the symbols exported from a library.

Yes, you are correct, my mistake.

No, I think in order to shoehorn two conflicting two libs into one program
one needs to resort to things like changing the linker symbols manually or
writing a wrapper lib that consists of a bunch of forwarding functions
with just a different name.

This would be the only workable solution.

Changing the linker symbols manually is obviously extremely
system-specific, assuming it's possible at all. A wrapper lib sounds
like a good idea, but I would think the original library with the
conflicting names would still be part of the program -- unless you do
something equally system-specific to hide the original names.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Malcolm]

"Ian" <ia******@hotmail.com> wrote

Once you start trying to mix arrays and dymanic objects with stl
controlled sequences, you really get into trouble. Hence the wisdom of
the rule.

Logan Shaw:
$For example, C++ allows you to do this:

$ int *i = new int[100];

$ There is no reason the performance of this should be any worse than
$ the C equivalent:

$ int *i = (int *) malloc (100 * sizeof (int));
Ian Hence smart pointers, the 'modern' way of managing the lifetime of dynamic
objects. There is no need in C++ to work with raw pointers. As I've said
before on this thread, the is very useful feature in kernel code.

There seem to be radical disagreements about what is and what isn't
idiomatic C++ code.

You can't sensibly do object-oriented programming in C, and in some
situations an object-oriented design is far superior to a procedural one.
But in my opinion trying to use C++ for bascially procedural code, with no
control about what language features will be used and which will be ignored,
is asking for trouble. That's why procedural programs are better written in
C.

[Ian Collins]

Malcolm wrote:

Hence smart pointers, the 'modern' way of managing the lifetime of dynamic
objects. There is no need in C++ to work with raw pointers. As I've said
before on this thread, the is very useful feature in kernel code.

There seem to be radical disagreements about what is and what isn't
idiomatic C++ code.

True, that's bound to happen with an expressive language. C has the
benefit of being concise, although there are still disagreements on
style, for instance the current thread on variable declaration and
initialisation (this tends not to be an issue in the C++ world where
variables are declared where used).
You can't sensibly do object-oriented programming in C, and in some
situations an object-oriented design is far superior to a procedural one.
But in my opinion trying to use C++ for bascially procedural code, with no
control about what language features will be used and which will be ignored,
is asking for trouble. That's why procedural programs are better written in
C.

I still disagree with this. My introduction to OO was the xview
toolkit. Very C and very OO.

If you are using C++ for kernel/driver code, you have to work within a
set of constraints what define the features of the language you can use.
The evolutionary path from C to C++ has left a legacy of compiler
options to enable/disable language features (for backwards
compatibility). These options can be used to define the feature set a
programmer can use for a specific application.

There are many cases where C++ is a good choice for procedural code, the
ability to manage the lifetime of dynamic memory and locks is the one I
have found most useful in kernel space.

--
Ian Collins.

[jacob navia]

Ulrich Eckhardt a écrit :

Walter Roberson wrote:

In article <42*************@uni-berlin.de>,
Ulrich Eckhardt <do******@knuut.de> wrote:

Logan Shaw wrote:

For example, C++ allows you to do this:
int *i = new int[100];
There is no reason the performance of this should be any worse than
the C equivalent:
int *i = (int *) malloc (100 * sizeof (int));

Yes there is. operator new[] will throw an exception when it fails,
so the 'equivalent' in C at least requires some error checking.

I'm not sure if you are arguing for or against the proposition there ;-)

There is a comparison between two non-equivalent pieces of code, so using
this as a measure for speed is just flawed. That's all I wanted to point
out.
Also, BTW, instead of saying exceptions are an overhead, you could as well
say that not having them is a disadvantage.

From what I've read, the overheads of exception support are quite high.

Can you give a quote/URL? From what I know, there is indeed an overhead and
early implementations of C++ didn't perform too well, but better
implementations have made the cost when not throwing an exception
negligible.

Uli

I have studied the implementation of exceptions in gcc. There are
basically two methods:
1)SJLJ (set jump/long jump) style, where the cost for any function is
high even when NOT throwing any exceptions,
2) dwarf2 based tables, where the compiler describes in detail each
stack frame so that the runtime is able to figure out where it should
jump. This method is fast when not throwing exceptions since there
is no overhead, but it costs a LOT in RAM space since those tables
must be generated for each function, and that is surely not cheap in
space requirements. The tables need to be there even for functions that
do not use exceptions at all.

So, you can see, there is no free lunch...

jacob

[jacob navia]

Keith Thompson a écrit :

Changing the linker symbols manually is obviously extremely
system-specific, assuming it's possible at all. A wrapper lib sounds
like a good idea, but I would think the original library with the
conflicting names would still be part of the program -- unless you do
something equally system-specific to hide the original names.

Just build a dynamically loaded library (dll/so)

jacob

[Ian Collins]

jacob navia wrote:

Keith Thompson a écrit :

Changing the linker symbols manually is obviously extremely
system-specific, assuming it's possible at all. A wrapper lib sounds
like a good idea, but I would think the original library with the
conflicting names would still be part of the program -- unless you do
something equally system-specific to hide the original names.

Just build a dynamically loaded library (dll/so)

Doesn't help with duplicate symbols.

--
Ian Collins.

[Logan Shaw]

jacob navia wrote:

Ulrich Eckhardt a écrit :

Walter Roberson wrote:

From what I've read, the overheads of exception support are quite high.

Can you give a quote/URL? From what I know, there is indeed an
overhead and
early implementations of C++ didn't perform too well, but better
implementations have made the cost when not throwing an exception
negligible.

I have studied the implementation of exceptions in gcc. There are
basically two methods: 2) dwarf2 based tables, where the compiler describes in detail each
stack frame so that the runtime is able to figure out where it should
jump. This method is fast when not throwing exceptions since there
is no overhead, but it costs a LOT in RAM space since those tables
must be generated for each function, and that is surely not cheap in
space requirements. The tables need to be there even for functions that
do not use exceptions at all.

My guess is they don't need to be there for functions which exceptions
cannot pass through, right?

In which case, wouldn't all those functions have to have some sort of
other code to deal with error conditions anyway, at least if they are
doing proper error handling and not just ignoring errors?

Which makes me wonder: are there situation where a program with
exceptions actually has more overhead than a program that does proper
error handling without exceptions? In other words, is it the case
that eliminating exceptions only reduces overhead if you also leave
out the proper error handling?

- Logan

[jacob navia]

Ian Collins a écrit :

jacob navia wrote:

Keith Thompson a écrit :

Changing the linker symbols manually is obviously extremely
system-specific, assuming it's possible at all. A wrapper lib sounds
like a good idea, but I would think the original library with the
conflicting names would still be part of the program -- unless you do
something equally system-specific to hide the original names.

Just build a dynamically loaded library (dll/so)

Doesn't help with duplicate symbols.

Yes it helps, since you can rename the symbols within it,
hiding them from the rest of the world...

[jacob navia]

Logan Shaw a écrit :

My guess is they don't need to be there for functions which exceptions
cannot pass through, right?

No, ANY function can be passed by an exception handler
if it is not a leave function (doesn't call any other function)
in the absolute sense of the word, i.e. if it doesn't
*implicitely* call new() for instance, or if it doesn't
call some copy constructor, overloaded operator or whatever...

It would be quite impossible to the compiler to determine that
there is NEVER some path that directly or indirectly arrives
at that function so unless it is *really* evident the compiler
will generate the tables for each function.
In which case, wouldn't all those functions have to have some sort of
other code to deal with error conditions anyway, at least if they are
doing proper error handling and not just ignoring errors?

Which makes me wonder: are there situation where a program with
exceptions actually has more overhead than a program that does proper
error handling without exceptions? In other words, is it the case
that eliminating exceptions only reduces overhead if you also leave
out the proper error handling?

You can do a lot of error handling by relying on the
hardware:

If you set a hardware trap handler for "Segmentation violation"
then you can do:
int *a = malloc(sizeof(int[100]));
a[2] = 67;
and just suppose that if that crashes, the signal handler will
branch to the appropiate function...

jacob

[jacob navia]

jacob navia a écrit :

No, ANY function can be passed by an exception handler
if it is not a leave function (doesn't call any other function)

I think that should have been a "leaf function"....
Sorry

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

Keith Thompson a écrit :

Changing the linker symbols manually is obviously extremely
system-specific, assuming it's possible at all. A wrapper lib sounds
like a good idea, but I would think the original library with the
conflicting names would still be part of the program -- unless you do
something equally system-specific to hide the original names.

Just build a dynamically loaded library (dll/so)

I.e., "something equally system-specific".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ulrich Eckhardt]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.com> writes:

Ulrich Eckhardt wrote:

No, I think in order to shoehorn two conflicting two libs into one
program one needs to resort to things like changing the linker
symbols manually or writing a wrapper lib that consists of a bunch
of forwarding functions with just a different name.
This would be the only workable solution.

Not the only one. Using dlopen/dlsym or LoadLibrary/GetProcAddress, you can
load the same symbol from more than one lib. Of course, all this plays in
the real world (i.e. outside the standard) but still covers a reasonable
amount of systems.
Changing the linker symbols manually is obviously extremely
system-specific, assuming it's possible at all.

Last time I used it, I was pretty impressed by the capabilities of the GNU
binutils, in particular by objcopy, which can handle a whole bunch of
formats.

<snipped rant about signed binaries, digital restriction management etc
which will f*** it all up and that the whole world is evil and against me>

cheers

Uli