A concern about mixing C and C++

[ziman137]

Hello all,

I have a question and am seeking for some advice.

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications, I
decide to write it in C instead of C++. However, I thought it might be
convenient to use some C++ code at some misc places. I'm aware that, I
could always use the C++ compiler to get it work.

My concerns are:

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?
2) Would the way I mix C and C++ code have any potential drawbacks for
the future users to use the library?

My intention for choosing C interface instead of C++ OOD is to gain the
maximum performance as possible, yet I still like to use some C++
coding features (e.g., "const", reference instead of pointers, ...).

Thanks,

Gary

[Ian Collins]

ziman137 wrote:

Hello all,

I have a question and am seeking for some advice.

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications, I
decide to write it in C instead of C++.

Why? The performance of a C++ version should be no worse than the C one
and possibly better if you can make use of existing well tuned standard
algorithms and containers. What did your profiling show?

However, I thought it might be
convenient to use some C++ code at some misc places. I'm aware that, I
could always use the C++ compiler to get it work.

You could, yes.

My concerns are:

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?

None what so ever.

2) Would the way I mix C and C++ code have any potential drawbacks for
the future users to use the library?

Yes, unless you release the source, if you expose any C++ interfaces you
will run into all of the ABI incompatibility problems that plague C++
libraries. You will also exclude C users from using you library. One
compromise is to only expose a C interface.

My intention for choosing C interface instead of C++ OOD is to gain the
maximum performance as possible, yet I still like to use some C++
coding features (e.g., "const", reference instead of pointers, ...).

Performance has nothing to do with it, portability is the reason to
stick with a C interface.

--
Ian Collins.

[Jack Klein]

On 28 Jul 2006 22:28:52 -0700, "ziman137" <ga********@yahoo.comwrote
in comp.lang.c:

Hello all,

I have a question and am seeking for some advice.

Here's advice: don't ask here. As far as C is concerned, C++ is just
one of many, many johnny-come-lately imitators that claim to improve
and extend C.

The C standard does not define an interface to any other language. Not
at all. C++, on the other hand, defines a mechanism that is intended
(but not guaranteed) to allow mixing code from a compatible C
compiler.

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications, I
decide to write it in C instead of C++. However, I thought it might be
convenient to use some C++ code at some misc places. I'm aware that, I
could always use the C++ compiler to get it work.

Absolutely astonishing. What proof do you have that C will provide
better performance than C++? What trials have you run, and where are
the timing comparison results?

My concerns are:

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?

C does not define any way to mix C and C++.

2) Would the way I mix C and C++ code have any potential drawbacks for
the future users to use the library?

C does not define any way to mix C and C++.

My intention for choosing C interface instead of C++ OOD is to gain the
maximum performance as possible, yet I still like to use some C++
coding features (e.g., "const", reference instead of pointers, ...).

But what evidence do you have that this choice will have any impact on
performance?

As for mixing C++ coding features such as "references" with C code,
that's just plain impossible, since there are no such things as
references in C.

Here are some hints:

If you want to know about mixing C++ and C, ask in a C++ newsgroup.

If you want to know about mixing Java and C, ask in a Java group.

If you want to know about...

....well, you're probably getting the point by now.

C is far senior to many of the popular flavor of the month languages,
and does not take any notice of their existence. And it may well
outlast many or all of them, as it has outlasted at least the original
Visual Basic for Windows.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Malcolm]

"ziman137" <ga********@yahoo.comwrote in message

Hello all,

I have a question and am seeking for some advice.

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications, I
decide to write it in C instead of C++. However, I thought it might be
convenient to use some C++ code at some misc places. I'm aware that, I
could always use the C++ compiler to get it work.

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?

Potentially yes. It must be compiled with a C++ compiler, and it is not
impossible that the C++ compiler on a given system is inferior to the C
compiler. However it is not very likely, often they share substantially the
same code.
If you use C++ constructs in your code you will find them harder to optimise
than the C constructs, because C++ is designed to present a nice interface
to the programmer rather than to expose basic processor operations. However
you are probably aware of that already.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

[Ian Collins]

Malcolm wrote:

"ziman137" <ga********@yahoo.comwrote in message

>>Hello all,

I have a question and am seeking for some advice.

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications, I
decide to write it in C instead of C++. However, I thought it might be
convenient to use some C++ code at some misc places. I'm aware that, I
could always use the C++ compiler to get it work.

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?

Potentially yes. It must be compiled with a C++ compiler, and it is not
impossible that the C++ compiler on a given system is inferior to the C
compiler. However it is not very likely, often they share substantially the
same code.
If you use C++ constructs in your code you will find them harder to optimise
than the C constructs, because C++ is designed to present a nice interface
to the programmer rather than to expose basic processor operations. However
you are probably aware of that already.

Eh? C++ can wrap basic processor operations in a higher level
abstraction, but it can still expose then in the same way C does.

--
Ian Collins.

[jacob navia]

Jack Klein a écrit :

>
Absolutely astonishing. What proof do you have that C will provide
better performance than C++? What trials have you run, and where are
the timing comparison results?

We discussed this with an example on Saturday May 6th.
The topic of the thread was

strtok behavior with multiple consecutive delimiters

and C++ came at best as twice as slow as C.

jacob

P.S. this is NOT a "proof" of course. There may be situations
where C++ templates outperform assembly language, and there will
be situations when lisp outperforms C and C++.

[Richard Heathfield]

jacob navia said:

There may be situations
where C++ templates outperform assembly language,

Jacob's talking through his hat again. His claim is easily disproved. All we
have to do is tell the compiler to generate assembly language from the C++
template code. We now have assembly language that performs exactly as well
as the C++ template code. And, given an experienced assembly language
programmer (to match the experienced C++ programmer who produces such
astoundingly quick code), we can almost certainly find an optimisation,
however trivial, that will make the assembly language version at least a
little faster than the C++ template version from which it was generated.

--
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)

[Malcolm]

"Ian Collins" <ia******@hotmail.comwrote in message
news:4j*************@individual.net...

Malcolm wrote:

>"ziman137" <ga********@yahoo.comwrote in message

>>>Hello all,

I have a question and am seeking for some advice.

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications, I
decide to write it in C instead of C++. However, I thought it might be
convenient to use some C++ code at some misc places. I'm aware that, I
could always use the C++ compiler to get it work.

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?

Potentially yes. It must be compiled with a C++ compiler, and it is not
impossible that the C++ compiler on a given system is inferior to the C
compiler. However it is not very likely, often they share substantially
the
same code.
If you use C++ constructs in your code you will find them harder to
optimise
than the C constructs, because C++ is designed to present a nice
interface
to the programmer rather than to expose basic processor operations.
However
you are probably aware of that already.

Eh? C++ can wrap basic processor operations in a higher level
abstraction, but it can still expose then in the same way C does.

Can, yes. But Bjarne Strousup believes that malloc(), for example, should
not be used in new C++ code.
Modern C++ using the standard library will have set of abstracted interfaces
to basic structures. They work well and might even be more efficient than
hand-coded similar C structures. However it is not possible for the
programmer to exert fine control over them. So for instance if he wants to
interate over an array, he will use the vector class iterator. This may be a
bare pointer, but probably it carries some run time checks with it to
protect the pointer from going out of bounds. Generally a good thing, but
harder to optimise.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
..

[chris.fairles]

ziman137 wrote:

Hello all,

I have a question and am seeking for some advice.

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications, I
decide to write it in C instead of C++. However, I thought it might be
convenient to use some C++ code at some misc places. I'm aware that, I
could always use the C++ compiler to get it work.

My concerns are:

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?
2) Would the way I mix C and C++ code have any potential drawbacks for
the future users to use the library?

My intention for choosing C interface instead of C++ OOD is to gain the
maximum performance as possible, yet I still like to use some C++
coding features (e.g., "const", reference instead of pointers, ...).

Thanks,

Gary

Hello Gary,

I've recently gone through the process of deciding to use C or C++ for
a high performace "algorithmic" library.

As far as raw performance goes, you'll find benchmarks throughout the
net going both ways. Since C++ is more popular, you'll see more claming
C++ is as fast/faster. At the end of the day it seems that if you just
want to generically compare performance of C vs C++ you'll arrive at
the answer "it depends on how well you know and understand the
language".

I'm much more familiar with C. I know how it works, I know how to make
nice API's and modular code with it and I know how to avoid some issues
that might degrade performance. But these will apply to both C++ and C
for the most part since C++ is a superset, things like use narrow
ranged case statements, avoid deeply nested if statements, using the
smallest integer types isnt always beneficial etc etc.

However, I don't know much about how templates are internally handled,
I don't know how multiple inheritance works and I have only a small
notion of how virtual functions work. So the problem for me is that I
don't know how to write efficient C++ code because I don't fully
understand how it all works. Not only that but because I've used C
since forever, I don't have much intuition when it comes to OO
application design. So I stick with C. Call me lazy ;)

So my advice, either stick with what you know or learn the performance
pitfalls.

Cheers,
Chris

P.S. as for combining C++ and C in a scientific libray, check out
openCV. It's a computer vision API written like C but with both a C and
C++ interface.

[Frederick Gotham]

Malcolm posted:

Modern C++ using the standard library will have set of abstracted
interfaces to basic structures. They work well and might even be more
efficient than hand-coded similar C structures. However it is not
possible for the programmer to exert fine control over them. So for
instance if he wants to interate over an array, he will use the vector
class iterator. This may be a bare pointer, but probably it carries some
run time checks with it to protect the pointer from going out of bounds.
Generally a good thing, but harder to optimise.

There is nothing stopping a C++ programmer from simply using the C features,
i.e. normal arrays, rather than std::vector.

I myself write C++ code with a heavy bias toward C.

--

Frederick Gotham

[Ian Collins]

Malcolm wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:4j*************@individual.net...

>>Malcolm wrote:

>>>"ziman137" <ga********@yahoo.comwrote in message

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?
Potentially yes. It must be compiled with a C++ compiler, and it is not
impossible that the C++ compiler on a given system is inferior to the C
compiler. However it is not very likely, often they share substantially
the
same code.
If you use C++ constructs in your code you will find them harder to
optimise
than the C constructs, because C++ is designed to present a nice
interface
to the programmer rather than to expose basic processor operations.
However
you are probably aware of that already.

Eh? C++ can wrap basic processor operations in a higher level
abstraction, but it can still expose then in the same way C does.

Can, yes. But Bjarne Strousup believes that malloc(), for example, should
not be used in new C++ code.

Correct, but you can provide your own version of new/delete, which puts
the developer back in the driver's seat.

Modern C++ using the standard library will have set of abstracted interfaces
to basic structures. They work well and might even be more efficient than
hand-coded similar C structures. However it is not possible for the
programmer to exert fine control over them. So for instance if he wants to
interate over an array, he will use the vector class iterator. This may be a
bare pointer, but probably it carries some run time checks with it to
protect the pointer from going out of bounds. Generally a good thing, but
harder to optimise.

He probably would, but if push came to shove, he could take the address
of the first element and use a plain pointer. Iterators tend to be well
optimised. Some implementations use raw pointers and none are required
to do any bounds checking, although this may be available as an
extension for testing.

C++ gives the developer a choice between the C way of doing something
and the C++ way.

--
Ian Collins.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

jacob navia said:

>There may be situations
where C++ templates outperform assembly language,

Jacob's talking through his hat again. His claim is easily disproved. All we
have to do is tell the compiler to generate assembly language from the C++
template code. We now have assembly language that performs exactly as well
as the C++ template code. And, given an experienced assembly language
programmer (to match the experienced C++ programmer who produces such
astoundingly quick code), we can almost certainly find an optimisation,
however trivial, that will make the assembly language version at least a
little faster than the C++ template version from which it was generated.

On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

For example, if I'm writing low-level code that I expect to be
maintained, I'm not likely to perform a pervasive optimization that
works only if an array size is a power of 2.

A skilled assembly language programmer is likely to be much smarter
than an optimizing compiler, but an optimizer has a different set of
tradeoffs to consider. A programmer will perform optimizations over
time as he's working on a piece of code; an optimizing compiler will
redo all its work from scratch every time it's invoked.

Yes, you can use an optimizing compiler as a way to generate assembly
language -- but that argument doesn't apply to hand-written assembly
language.

--
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.

[Richard Heathfield]

Keith Thompson said:

<snip>

>
On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

Sure, but perhaps you missed my point, which is that the /starting point/
for the assembly language programmer would be the super-efficient C++
template code, expressed in assembly language form. Given that starting
base, (a) it's bound to be as fast as the C++ template code, because it's
the same code that the C++ template code is compiled to - which is in
itself sufficient to destroy Mr Navia's point, and (b) it would be quite
surprising if the skilled assembly language programmer couldn't find /one/
hand-optimisation to make the asm form just a tiny smidgenette faster.

<snip>

Yes, you can use an optimizing compiler as a way to generate assembly
language -- but that argument doesn't apply to hand-written assembly
language.

It does if the starting point for the handwriting is the generated code.

--
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)

[Ian Collins]

Richard Heathfield wrote:

Keith Thompson said:

<snip>

>>On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

Sure, but perhaps you missed my point, which is that the /starting point/
for the assembly language programmer would be the super-efficient C++
template code, expressed in assembly language form. Given that starting
base, (a) it's bound to be as fast as the C++ template code, because it's
the same code that the C++ template code is compiled to - which is in
itself sufficient to destroy Mr Navia's point, and (b) it would be quite
surprising if the skilled assembly language programmer couldn't find /one/
hand-optimisation to make the asm form just a tiny smidgenette faster.

I don't know if you do this, but I often find I can obtain more
productive optimisations by using the generated assembly language to
tune the high level language code rather than hand editing the assembly.

One area optimising compilers have an edge and will continue to improve
is global optimisations, there is only so much code a human can retain
in working memory. We can often do better with micro-optimisations, but
the compiler is better equipped to see the big picture.

--
Ian Collins.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:

<snip>

>>
On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

Sure, but perhaps you missed my point, which is that the /starting point/
for the assembly language programmer would be the super-efficient C++
template code, expressed in assembly language form. Given that starting
base, (a) it's bound to be as fast as the C++ template code, because it's
the same code that the C++ template code is compiled to - which is in
itself sufficient to destroy Mr Navia's point, and (b) it would be quite
surprising if the skilled assembly language programmer couldn't find /one/
hand-optimisation to make the asm form just a tiny smidgenette faster.

<snip>

>Yes, you can use an optimizing compiler as a way to generate assembly
language -- but that argument doesn't apply to hand-written assembly
language.

It does if the starting point for the handwriting is the generated code.

If the optimizing compiler generates code that pervasively depends on
some semantically trivial aspect of the high-level source, the
generated assembly won't be a good basis for maintenance. For
example, a compiler might generate radically different code if an
array size is a power of two than if it isn't, even if there's only,
say, a 1% advantage. If you change the array declaration, the
compiler will happily re-write the entire application when you
recompile it. A sane assembly language programmer would probably
avoid such an optimization if it would hurt maintainability that much.

--
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.

[Ark]

Richard Heathfield wrote:

Keith Thompson said:

<snip>

>On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

Sure, but perhaps you missed my point, which is that the /starting point/
for the assembly language programmer would be the super-efficient C++
template code, expressed in assembly language form. Given that starting
base, (a) it's bound to be as fast as the C++ template code, because it's
the same code that the C++ template code is compiled to - which is in
itself sufficient to destroy Mr Navia's point, and (b) it would be quite
surprising if the skilled assembly language programmer couldn't find /one/
hand-optimisation to make the asm form just a tiny smidgenette faster.

<snip>

>Yes, you can use an optimizing compiler as a way to generate assembly
language -- but that argument doesn't apply to hand-written assembly
language.

It does if the starting point for the handwriting is the generated code.

The real point is that the compiler-generated assembly code ain't
necessarily a good starting point, for it perhaps takes advantages of
accidental coincidences of data that a human programmer will not indulge
in. So (maintainable) assembly code _may_ be worse than
compiler-generated, the point Keith Thompson had made pretty clear.
Example:
The line
int x = NUMBER;
is compiled (for ARM) differently depending on
#define NUMBER 1
#define NUMBER 257
#define NUMBER 0x101010101
A human would stick to a single implementation.

[Ark]

Ian Collins wrote:

Malcolm wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:4j*************@individual.net...

>>Malcolm wrote:

"ziman137" <ga********@yahoo.comwrote in message

1) Would the way I mix C and C++ code have any potential drawbacks to
the performance?
>
Potentially yes. It must be compiled with a C++ compiler, and it is not
impossible that the C++ compiler on a given system is inferior to the C
compiler. However it is not very likely, often they share substantially
the
same code.
If you use C++ constructs in your code you will find them harder to
optimise
than the C constructs, because C++ is designed to present a nice
interface
to the programmer rather than to expose basic processor operations.
However
you are probably aware of that already.
Eh? C++ can wrap basic processor operations in a higher level
abstraction, but it can still expose then in the same way C does.

Can, yes. But Bjarne Strousup believes that malloc(), for example, should
not be used in new C++ code.

Correct, but you can provide your own version of new/delete, which puts
the developer back in the driver's seat.

>Modern C++ using the standard library will have set of abstracted interfaces
to basic structures. They work well and might even be more efficient than
hand-coded similar C structures. However it is not possible for the
programmer to exert fine control over them. So for instance if he wants to
interate over an array, he will use the vector class iterator. This may be a
bare pointer, but probably it carries some run time checks with it to
protect the pointer from going out of bounds. Generally a good thing, but
harder to optimise.

He probably would, but if push came to shove, he could take the address
of the first element and use a plain pointer. Iterators tend to be well
optimised. Some implementations use raw pointers and none are required
to do any bounds checking, although this may be available as an
extension for testing.

C++ gives the developer a choice between the C way of doing something
and the C++ way.

Ehmmm... please help me here: I am not a C++ guy.
AFAIK, C++ does not allow all the C way (example: tentative declarations).
Then, if I write C-style in C++, at the very minimum the C++ compiler
doesn't know e.g. about any exceptions that may be thrown in a function
I call and which is in a different translation unit. So it just has to
bring in the heavy machinery in just in case. Am I missing something?

[Ian Collins]

Ark wrote:

Ian Collins wrote:

>C++ gives the developer a choice between the C way of doing something
and the C++ way.

Ehmmm... please help me here: I am not a C++ guy.
AFAIK, C++ does not allow all the C way (example: tentative declarations).
Then, if I write C-style in C++, at the very minimum the C++ compiler
doesn't know e.g. about any exceptions that may be thrown in a function
I call and which is in a different translation unit. So it just has to
bring in the heavy machinery in just in case. Am I missing something?

If my understanding of tentative declarations is correct, they are
synonymous with forward declarations in C++ due to the differing use of
'struct' in a declaration, that is:

struct X;

forward declares the type X.

The compiler doesn't have to bother with unexpected exceptions when
compiling idiomatic C code, any unhandled exception can be caught by
whatever calls main().

As a trivial example, on my platform the following generated essentially
the same code when compiled as C or C++:

extern int fn(void);
extern void fn1(int);

typedef struct { int n; } X;

int main(void)
{
X x;

x.n = fn();

fn1( x.n );
}

--
Ian Collins.

[Ark]

Ian Collins wrote:

Ark wrote:

>Ian Collins wrote:

>>C++ gives the developer a choice between the C way of doing something
and the C++ way.

Ehmmm... please help me here: I am not a C++ guy.
AFAIK, C++ does not allow all the C way (example: tentative declarations).
Then, if I write C-style in C++, at the very minimum the C++ compiler
doesn't know e.g. about any exceptions that may be thrown in a function
I call and which is in a different translation unit. So it just has to
bring in the heavy machinery in just in case. Am I missing something?

If my understanding of tentative declarations is correct, they are
synonymous with forward declarations in C++ due to the differing use of
'struct' in a declaration, that is:

struct X;

forward declares the type X.

The compiler doesn't have to bother with unexpected exceptions when
compiling idiomatic C code, any unhandled exception can be caught by
whatever calls main().

As a trivial example, on my platform the following generated essentially
the same code when compiled as C or C++:

extern int fn(void);
extern void fn1(int);

typedef struct { int n; } X;

int main(void)
{
X x;

x.n = fn();

fn1( x.n );
}

1. Tentative declarations of variables are (in C) indistinguishable from
definitions until the end of the translation unit; they AFAIK expressly
prohibited in C++. E.g., a (const) circular data structure like
typedef struct X {int x, const struct X *next} X;
const X x;
const X y;
const X z = {5, &x};
const X y = {6, &z};
const X x = {7, &y};
is a valid C but not C++.
2. Interesting example; just curious what the differences are and
whether it matters that your function is called main, not, say, foo.

[Ian Collins]

Ark wrote:

Ian Collins wrote:

>Ark wrote:

>>Ian Collins wrote:

C++ gives the developer a choice between the C way of doing something
and the C++ way.

Ehmmm... please help me here: I am not a C++ guy.
AFAIK, C++ does not allow all the C way (example: tentative
declarations).
Then, if I write C-style in C++, at the very minimum the C++ compiler
doesn't know e.g. about any exceptions that may be thrown in a function
I call and which is in a different translation unit. So it just has to
bring in the heavy machinery in just in case. Am I missing something?

If my understanding of tentative declarations is correct, they are
synonymous with forward declarations in C++ due to the differing use of
'struct' in a declaration, that is:

struct X;

forward declares the type X.

The compiler doesn't have to bother with unexpected exceptions when
compiling idiomatic C code, any unhandled exception can be caught by
whatever calls main().

As a trivial example, on my platform the following generated essentially
the same code when compiled as C or C++:

extern int fn(void);
extern void fn1(int);

typedef struct { int n; } X;

int main(void)
{
X x;

x.n = fn();

fn1( x.n );
}

1. Tentative declarations of variables are (in C) indistinguishable from
definitions until the end of the translation unit; they AFAIK expressly
prohibited in C++. E.g., a (const) circular data structure like
typedef struct X {int x, const struct X *next} X;

typedef struct X {int x; const struct X *next;} X;

Is valid C but not C++.

typedef struct X {int x; const X *next;} X;

Is valid C++ but not C.

typedef struct X_t {int x; const struct X_t *next;} X;

Is valid C++ and C.

const X x;
const X y;
const X z = {5, &x};
const X y = {6, &z};
const X x = {7, &y};
is a valid C but not C++.

Correct , C++ prohibits uninitialised consts. Easily fixed for both thus:

extern const X x;
extern const X y;
const X z = {5, &x};
const X y = {6, &z};
const X x = {7, &y};

2. Interesting example; just curious what the differences are and
whether it matters that your function is called main, not, say, foo.

The C++ compiler pushed one extra register on the stack. The function
name does not make any difference.

--
Ian Collins.

[jacob navia]

Keith Thompson a écrit :

Richard Heathfield <in*****@invalid.invalidwrites:

>>jacob navia said:

>>>There may be situations
where C++ templates outperform assembly language,

Jacob's talking through his hat again. His claim is easily disproved. All we
have to do is tell the compiler to generate assembly language from the C++
template code. We now have assembly language that performs exactly as well
as the C++ template code. And, given an experienced assembly language
programmer (to match the experienced C++ programmer who produces such
astoundingly quick code), we can almost certainly find an optimisation,
however trivial, that will make the assembly language version at least a
little faster than the C++ template version from which it was generated.

On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

For example, if I'm writing low-level code that I expect to be
maintained, I'm not likely to perform a pervasive optimization that
works only if an array size is a power of 2.

A skilled assembly language programmer is likely to be much smarter
than an optimizing compiler, but an optimizer has a different set of
tradeoffs to consider. A programmer will perform optimizations over
time as he's working on a piece of code; an optimizing compiler will
redo all its work from scratch every time it's invoked.

Yes, you can use an optimizing compiler as a way to generate assembly
language -- but that argument doesn't apply to hand-written assembly
language.

The things I had in mind is that templates expose to the
compiler details that allows more optimizations than what
an assembly language programmer would do. Specifically it would
be highly surprising that he/she writes the same optimized version
for a qsort search for each possible type of argument that the
function could receive. Most likely it will design a general
qsort interface (like C offers) that will be highly optimized
but never as optimized as a specially tailored qsort for each
input type.

jacob

[Ark]

Ian Collins wrote:

Ark wrote:

>Ian Collins wrote:

>>Ark wrote:

Ian Collins wrote:

C++ gives the developer a choice between the C way of doing something
and the C++ way.
>
Ehmmm... please help me here: I am not a C++ guy.
AFAIK, C++ does not allow all the C way (example: tentative
declarations).
Then, if I write C-style in C++, at the very minimum the C++ compiler
doesn't know e.g. about any exceptions that may be thrown in a function
I call and which is in a different translation unit. So it just has to
bring in the heavy machinery in just in case. Am I missing something?

If my understanding of tentative declarations is correct, they are
synonymous with forward declarations in C++ due to the differing use of
'struct' in a declaration, that is:

struct X;

forward declares the type X.

The compiler doesn't have to bother with unexpected exceptions when
compiling idiomatic C code, any unhandled exception can be caught by
whatever calls main().

As a trivial example, on my platform the following generated essentially
the same code when compiled as C or C++:

extern int fn(void);
extern void fn1(int);

typedef struct { int n; } X;

int main(void)
{
X x;

x.n = fn();

fn1( x.n );
}

1. Tentative declarations of variables are (in C) indistinguishable from
definitions until the end of the translation unit; they AFAIK expressly
prohibited in C++. E.g., a (const) circular data structure like
typedef struct X {int x, const struct X *next} X;

typedef struct X {int x; const struct X *next;} X;

Is valid C but not C++.

typedef struct X {int x; const X *next;} X;

Is valid C++ but not C.

typedef struct X_t {int x; const struct X_t *next;} X;

Is valid C++ and C.

>const X x;
const X y;
const X z = {5, &x};
const X y = {6, &z};
const X x = {7, &y};
is a valid C but not C++.

Correct , C++ prohibits uninitialised consts. Easily fixed for both thus:

extern const X x;
extern const X y;
const X z = {5, &x};
const X y = {6, &z};
const X x = {7, &y};

>2. Interesting example; just curious what the differences are and
whether it matters that your function is called main, not, say, foo.

The C++ compiler pushed one extra register on the stack. The function
name does not make any difference.

1. It is not an easy fix if I want x, y, z to also be static. (Actually,
regardless of whether they are const).
2. It's interesting to understand /why/ C++ uses more stack. Is it, by
any chance, for passing (e.g. passing through) a pointer to an exception
object? In any event, those things get compounded... definitely a
consideration for resource-constrained environments...
- Ark

[Malcolm]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:44*********************@news.orange.fr...

Keith Thompson a écrit :

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

>>>jacob navia said:
There may be situations
where C++ templates outperform assembly language,

Jacob's talking through his hat again. His claim is easily disproved. All
we have to do is tell the compiler to generate assembly language from the
C++ template code. We now have assembly language that performs exactly as
well as the C++ template code. And, given an experienced assembly
language programmer (to match the experienced C++ programmer who produces
such astoundingly quick code), we can almost certainly find an
optimisation, however trivial, that will make the assembly language
version at least a little faster than the C++ template version from which
it was generated.

On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

For example, if I'm writing low-level code that I expect to be
maintained, I'm not likely to perform a pervasive optimization that
works only if an array size is a power of 2.

A skilled assembly language programmer is likely to be much smarter
than an optimizing compiler, but an optimizer has a different set of
tradeoffs to consider. A programmer will perform optimizations over
time as he's working on a piece of code; an optimizing compiler will
redo all its work from scratch every time it's invoked.

Yes, you can use an optimizing compiler as a way to generate assembly
language -- but that argument doesn't apply to hand-written assembly
language.

The things I had in mind is that templates expose to the
compiler details that allows more optimizations than what
an assembly language programmer would do. Specifically it would
be highly surprising that he/she writes the same optimized version
for a qsort search for each possible type of argument that the
function could receive. Most likely it will design a general
qsort interface (like C offers) that will be highly optimized
but never as optimized as a specially tailored qsort for each
input type.

I did see some benchmarks for the standard template library, and they were
better than C equivalents. I thought that maybe the time had come to go to
C++.
What I forgot was that the syntax was difficult, and in fact a step too far,
with an already difficult and overloaded language. No one could use the STL
constructs effectively. So the experiment was short-lived, and now I have
virtually given up on C++ altogether.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

[Stephen Sprunk]

"ziman137" <ga********@yahoo.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...

I am currently working to implement an algorithmic library. Because
the performance is the most important factor in later applications,
I
decide to write it in C instead of C++. However, I thought it might
be
convenient to use some C++ code at some misc places. I'm aware
that, I could always use the C++ compiler to get it work.

There's two basic approaches to mixing C and C++:

1. Write the code in C and provide (optional) C++ wrappers.
2. Write the code in C++ and provide (optional) C wrappers.

Once you use _any_ C++isms in your library, you're forever chained to
the portability problems that C++ still encounters, limit yourself to
systems with C++ available, etc. Once you've paid that price, you
might as well write the whole library in C++ and then it's off-topic
for clc (though clc++ will probably be happy to help with the C
wrappers).

My intention for choosing C interface instead of C++ OOD is to gain
the
maximum performance as possible, yet I still like to use some C++
coding features (e.g., "const", reference instead of pointers, ...).

If you're going to write the library in the subset of C++ that looks
like C, you might as well write it in C and forgo the syntactic sugar
that C++ provides (except, perhaps, in some C++ wrappers). If you
can't give up C++'s syntactic sugar, then write the library in _real_
C++ (not some ugly common subset of the two) and provide C wrappers.

Mixing languages in the same project is considered bad form unless you
have a really strong reason, and "const" or "references" are IMHO not
a reason worth dealing with all the headaches of that "solution".

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

--
Posted via a free Usenet account from http://www.teranews.com

[Al Balmer]

On Sun, 30 Jul 2006 10:42:21 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>Richard Heathfield wrote:

>Keith Thompson said:

<snip>

>>>On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.

Sure, but perhaps you missed my point, which is that the /starting point/
for the assembly language programmer would be the super-efficient C++
template code, expressed in assembly language form. Given that starting
base, (a) it's bound to be as fast as the C++ template code, because it's
the same code that the C++ template code is compiled to - which is in
itself sufficient to destroy Mr Navia's point, and (b) it would be quite
surprising if the skilled assembly language programmer couldn't find /one/
hand-optimisation to make the asm form just a tiny smidgenette faster.

I don't know if you do this, but I often find I can obtain more
productive optimisations by using the generated assembly language to
tune the high level language code rather than hand editing the assembly.

When you do that, are you not tuning your code to a particular
compiler? No worse than tuning the assembler code, of course, and less
detrimental to portability. For the ultimate in (non-portable)
efficiency, you might do another iteration of the process.

>
One area optimising compilers have an edge and will continue to improve
is global optimisations, there is only so much code a human can retain
in working memory. We can often do better with micro-optimisations, but
the compiler is better equipped to see the big picture.

Even if the programmer can see the big picture, the compiler can do it
systematically and much more quickly.

--
Al Balmer
Sun City, AZ

[Ian Collins]

Al Balmer wrote:

On Sun, 30 Jul 2006 10:42:21 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>>Richard Heathfield wrote:

>>>Keith Thompson said:

<snip>

On the other hand, for any language at a higher level than assembler,
the compiler may find opportunities for optimizations that someone
creating hand-written assembler wouldn't find, or would choose not to
use.
Sure, but perhaps you missed my point, which is that the /starting point/
for the assembly language programmer would be the super-efficient C++
template code, expressed in assembly language form. Given that starting
base, (a) it's bound to be as fast as the C++ template code, because it's
the same code that the C++ template code is compiled to - which is in
itself sufficient to destroy Mr Navia's point, and (b) it would be quite
surprising if the skilled assembly language programmer couldn't find /one/
hand-optimisation to make the asm form just a tiny smidgenette faster.

I don't know if you do this, but I often find I can obtain more
productive optimisations by using the generated assembly language to
tune the high level language code rather than hand editing the assembly.

When you do that, are you not tuning your code to a particular
compiler? No worse than tuning the assembler code, of course, and less
detrimental to portability. For the ultimate in (non-portable)
efficiency, you might do another iteration of the process.

Like most low level optimisations, I tend to do this on embedded
systems, where portability isn't too much of an issue (I've found it
more cost effective to throw faster hardware at desktop applications
rather than fiddle with low level optimisations). The results can be
dramatic, one compiler I used generated diabolical code with loops like

for( i = 0; i < size; ++i )
{
doStuffWith( array[i] );
}

But good tight code with

int* p = array;
int* end = array+size;

while( p != end )
{
doStuffWith( *p++ );
}

--
Ian Collins.

[Al Balmer]

On Mon, 31 Jul 2006 19:21:07 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>Like most low level optimisations, I tend to do this on embedded
systems, where portability isn't too much of an issue (I've found it
more cost effective to throw faster hardware at desktop applications
rather than fiddle with low level optimisations). The results can be
dramatic, one compiler I used generated diabolical code with loops like

for( i = 0; i < size; ++i )
{
doStuffWith( array[i] );
}

But good tight code with

int* p = array;
int* end = array+size;

while( p != end )
{
doStuffWith( *p++ );
}

I can believe it - I've seen some strange things. Sometimes compilers
used for embedded devices seem to assume that the user will tweak the
assembler :-)

I don't do much embedded programming myself anymore, but the hardware
guy down the hall yells for help quite often, so I still see a lot of
it. We often sit in his office and massage C source until the
assembler looks the way he wants it.

--
Al Balmer
Sun City, AZ

[Frederick Gotham]

Ian Collins posted:

One compiler I used generated diabolical code with loops like

for( i = 0; i < size; ++i )
{
doStuffWith( array[i] );
}

But good tight code with

int* p = array;
int* end = array+size;

while( p != end )
{
doStuffWith( *p++ );
}

If I know the the loop must execute at least once, then I choose:

T *p = array;

T const *const p_over = array + len;

do Process(*p++);
while(p_over != p);

--

Frederick Gotham

[Dave Thompson]

On Sun, 30 Jul 2006 17:07:12 +1200, Ian Collins <ia******@hotmail.com>
wrote:

Ark wrote:

1. Tentative declarations of variables are (in C) indistinguishable from
definitions until the end of the translation unit; they AFAIK expressly
prohibited in C++. E.g., a (const) circular data structure like
typedef struct X {int x, const struct X *next} X;

typedef struct X {int x; const struct X *next;} X;

Is valid C but not C++.

Wrong. In C++ it is a 'benign' redefinition of the typename, which is
allowed. For essentially this reason.

typedef struct X {int x; const X *next;} X;

Is valid C++ but not C.

typedef struct X_t {int x; const struct X_t *next;} X;

Is valid C++ and C.

Both right.

const X x;
const X y;
const X z = {5, &x};
const X y = {6, &z};
const X x = {7, &y};
is a valid C but not C++.

Correct , C++ prohibits uninitialised consts. Easily fixed for both thus:

Even for nonconst C++ prohibits the declare-now define-later approach
without (explicit) extern, which as you note fixes the problem.

extern const X x;
extern const X y;
const X z = {5, &x};
const X y = {6, &z};
const X x = {7, &y};

However, this does not work for static=internal-linkage variables.
C++ does not allow /*qual?*/ static X x;
then /*qual*/ /*static*/ X x = init;

Or, write a ctor or other factory routine for X and:
const X z = X /* or makeX */ (5, &x);
etc.

For this particular case in EITHER C or C++
I might also consider something like:
const /*struct*/ X array [3] =
{ { 5, &array[2] }, { 6, &array[1] }, { 7, &array[0] } };
#define x array[2] // only if x is a more unique name
or in C++ X & x (&array[2])
etc.

- David.Thompson1 at worldnet.att.net