using c++ features in extern "C"

[Rahul]

Hi Everyone,

I have the following code,

void f(int &)
{
printf("in f...\n");
}

#ifdef __cplusplus
extern "C"
{
#endif

int main()
{
int i = 5;
int &j = i;
f(i);
return(0);
}

#ifdef __cplusplus
}
#endif

and it compiles and works fine with vc++ 6.0. Does the compiler ignore
the c linkage?

 

[Victor Bazarov]

Hi Everyone,

I have the following code,

void f(int &)
{
printf("in f...\n");
}

#ifdef __cplusplus
extern "C"
{
#endif

int main()
{
int i = 5;
int &j = i;
f(i);
return(0);
}

#ifdef __cplusplus
}
#endif

and it compiles and works fine with vc++ 6.0. Does the compiler ignore
the c linkage?

There was a proposal recently in comp.lang.c++.moderated to treat
all VC++ v6 related queries as off-topic. The reason was that VC++
v6 is so non-standard, that you can't infer anything from the fact
that some code "works" when produced by VC++ v6. Not that you would
use a single compiler to see whether some construct is legal, but v6
of VC++ is just awful.

Now, your program is ill-formed because you changed the declaration
of the 'main' function. Do not do that. Use some other function
to fiddle with linkage, etc. I'll answer your question pretending
that your function is not 'main', but 'mian' or 'aimn' or 'mina' or
some such, and you just mistyped it.

You're not precluded from using C++ constructs in a C++ program.
No buts about it. When you add C linkage to a function, the
function becomes callable from C (and that's the intent of the
linkage) or you can declare a function as coming from a C program
(library) and call it from your C++ program. The body of your
C++ function can contain any C++ stuff you wish to put there.

V

 

[Rahul]

There was a proposal recently in comp.lang.c++.moderated to treat
all VC++ v6 related queries as off-topic. The reason was that VC++
v6 is so non-standard, that you can't infer anything from the fact
that some code "works" when produced by VC++ v6. Not that you would
use a single compiler to see whether some construct is legal, but v6
of VC++ is just awful.

Now, your program is ill-formed because you changed the declaration
of the 'main' function. Do not do that. Use some other function
to fiddle with linkage, etc. I'll answer your question pretending
that your function is not 'main', but 'mian' or 'aimn' or 'mina' or
some such, and you just mistyped it.

You're not precluded from using C++ constructs in a C++ program.
No buts about it. When you add C linkage to a function, the
function becomes callable from C (and that's the intent of the
linkage) or you can declare a function as coming from a C program
(library) and call it from your C++ program. The body of your
C++ function can contain any C++ stuff you wish to put there.

V

Further to this, recently we came up with a project where c (extern
"C") code calls c++ function.
The c++ function accepts a pointer to an int and returns an int.

There was a suggestion to change the prototype of c++ function to
accept a reference. In that case, is it possible for the c code
to call c++ function accepting a reference?

 

[Victor Bazarov]

[..], recently we came up with a project where c (extern
"C") code calls c++ function.
The c++ function accepts a pointer to an int and returns an int.

There was a suggestion to change the prototype of c++ function to
accept a reference. In that case, is it possible for the c code
to call c++ function accepting a reference?

No. C has no references. You'd have to write a wrapper.

V

 

[Andrey Tarasevich]

I have the following code,

void f(int &)
{
printf("in f...\n");
}

#ifdef __cplusplus
extern "C"
{
#endif

int main()
{
int i = 5;
int &j = i;
f(i);
return(0);
}

#ifdef __cplusplus
}
#endif

and it compiles and works fine with vc++ 6.0. Does the compiler ignore
the c linkage?

Why shouldn't it work? There's absolutely no problems with using "C++
features" inside the function with C linkage. There's no reason there
should be any problems. Why?

The only thing language-specific linkage affects is... well... linkage,
which is roughly limited to a set of certain _external_ properties of
the function, which in the end basically boil down to the formal
requirement that only one function with any given name can have C
linkage (i.e. you can't have several overloaded functions with C linkage).

Of course, it also might make no sense to declare as 'extern "C"'
function that rely on "C++ features" in their parameter declarations
(classes, references etc.), yet it might have some limited usability, so
the language doesn't prohibit such declarations.

 

[James Kanze]

I have the following code,

void f(int &)
{
printf("in f...\n");
}

#ifdef __cplusplus
extern "C"
{
#endif

int main()
{
int i = 5;
int &j = i;
f(i);
return(0);
}

#ifdef __cplusplus
}
#endif

and it compiles and works fine with vc++ 6.0. Does the
compiler ignore the c linkage?

Sort of. Main (or rather ::main) is a very, very special
function, which follows different rules than any other function.
Typically, for example, it will be generated as if it were an
extern "C" function, even without the user requesting it. It is
treated specially regardless of where it occurs. The standard
specifically forbids declaring it static or inline, and I
suspect that the standard would have also forbid the above, had
anyone thought of it (because it's simpler to ban it, and
there's no good reason to allow it). But since they didn't ban
it, the above is perfectly legal code. And in it, main remains
main, to be treated specially. (Note, for example, that
declaring `extern "C"' doesn't give you the right to call it
recursively, just because you are allowed to call it recursively
in C.)

 

[James Kanze]

There was a proposal recently in comp.lang.c++.moderated to treat
all VC++ v6 related queries as off-topic.

I pretty much disagree with the current moderation trends in
comp.lang.c++.moderated---to the point of abandoning the group
completely (although I was one of the founders). But I don't
think they've gotten to the point of censuring because of the
version of the compiler you use.

If someone is trying to implement something using some of the
latest template techniques, of course, I would certainly
recommend that they upgrade the compiler. But not all
organizations insist on obfuscating their code to that degree,
and not all organizations can afford the upgrade. (You might be
able to upgrade without paying a penny to Microsoft, but it
still isn't free. No more than upgrading g++ or any other
compiler is free.)

The reason was that VC++ v6 is so non-standard, that you can't
infer anything from the fact that some code "works" when
produced by VC++ v6.

Nor with any other compiler, for that matter. I suppose you've
heard of undefined behavior.

Not that you would use a single compiler to see whether some
construct is legal, but v6 of VC++ is just awful.

Not awful: old. It's not the same thing. (VC++ 6.0 was one of
the better compilers around when it first appeared. G++ didn't
catch up until five or six years later.)

If you want to check legality using a compiler, of course, about
the only one which is any use at all for that would be Comeau.
Checking with several compilers can also be useful.

Now, your program is ill-formed because you changed the
declaration of the 'main' function.

I just checked the standard, and *IT* says that the code is
legal. FWIW: Sun CC 5.8 and g++ 4.1.0 agree as well, as does
VC++ 8. I'll admit that I didn't expect that, but of course,
::main is treated specially---Sun CC and g++, at least, always
treat it as if it were `extern "C"' (and I didn't check the
generated code this time, but in the past, more than one
compiler I've used generated a lot of extra code in the
function).

 

[Alf P. Steinbach]

* James Kanze:

I pretty much disagree with the current moderation trends in
comp.lang.c++.moderated---to the point of abandoning the group
completely (although I was one of the founders). But I don't
think they've gotten to the point of censuring because of the
version of the compiler you use.

It would be nice if you could be more clear about that disagreement, and
e.g. help the active moderators by explaining the potential for
improvement on the moderator's mailing list instead of referring
obliquely to it in [clc++].

The proposal Victor referred to was, IIRC, by Francis Glassborow.

I'm not sure but I think he was also one of the founders of the group.


Cheers,

- Alf

 

[James Kanze]

* James Kanze:

It would be nice if you could be more clear about that
disagreement,

I thought we'd been through that before. It's not something
concrete that I can say: change that, and I'd be happy. It's
just a general feeling---I don't feel comfortable with the group
any more.

My first reaction was somewhat bitter: I am, after all, one of
the founders of the group, and had been one of the most
important contributors for the longest time. But when I
consider the issue objectively, it's normal that the group and
moderation policy evolve---and I've doubtlessly evolved as
well---and there's nothing surprising that my relationship with
the group evolve as well. If you look at the group, I don't
think that any of the original founders are particularly active
in it today, although in some cases, this is more for
professional reasons than any discomfort with the group.

and e.g. help the active moderators by explaining the
potential for improvement on the moderator's mailing list
instead of referring obliquely to it in [clc++].

I think my discomfort is well known. It should be rather
apparent, at least, from my participation, which went from the
most frequent poster to never posting rather abruptly.

The proposal Victor referred to was, IIRC, by Francis
Glassborow.

I'm not sure but I think he was also one of the founders of
the group.

Nope. He actually signed on rather late.