[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

Calling C library functions from C++ program

mthread

12/7/2008 3:11:00 PM


Hi,
I am using C (ex : calloc etc..) library functions in my C++
program. I am able to compile and link without any issue. But I am
skeptic about the usage (ie whether it will cause any issues in
future) as I have learned that both C & C++ follow their own language
linking.

I have also understood in order to call a C method from a C++ program
I need to declare the method using
' extern "C" ' keyword. Kindly let me know if it necessary for me
declare the C methods with ' extern "C" ' keyword for my usage in C++
program.
23 Answers

Paavo Helde

12/7/2008 4:16:00 PM

0

mthread <rjkumr@gmail.com> kirjutas:

>
> Hi,
> I am using C (ex : calloc etc..) library functions in my C++
> program. I am able to compile and link without any issue. But I am
> skeptic about the usage (ie whether it will cause any issues in
> future) as I have learned that both C & C++ follow their own language
> linking.
>
> I have also understood in order to call a C method from a C++ program
> I need to declare the method using
> ' extern "C" ' keyword. Kindly let me know if it necessary for me
> declare the C methods with ' extern "C" ' keyword for my usage in C++
> program.

For using e.g. malloc() you should not declare it yourself. You should
include the relevant header, e.g. <stdlib.h>, otherwise I believe the
behavior is not defined. The system header might define malloc() as a
macro forwarding to another function, for example, in which case your
program won't link. The system guarantees the proper behavior when you
compile C++ and #include <stdlib.h>, so there is nothing you should worry
about.

Now if you now take a look in the <stdlib.h> header (actually not
guaranteed as all this stuff is implementation-defined) then you will
probably see that the whole header is defined as extern "C", e.g.

#ifdef __cplusplus
extern "C" {
#endif

// ... rest of the <stdlib.h> header

#ifdef __cplusplus
}
#endif

If one implements a C library and wants it to be usable also in C++, this
is what one should do then as well.

hth
Paavo

Sherm Pendley

12/7/2008 4:27:00 PM

0

Paavo Helde <paavo@nospam.please.ee> writes:

> For using e.g. malloc() you should not declare it yourself. You should
> include the relevant header, e.g. <stdlib.h>

Shouldn't that be <cstdlib>?

sherm--

--
My blog: http://shermspace.bl...
Cocoa programming in Perl: http://camelbones.sourc...

Paavo Helde

12/7/2008 4:40:00 PM

0

Sherm Pendley <spamtrap@dot-app.org> kirjutas:

> Paavo Helde <paavo@nospam.please.ee> writes:
>
>> For using e.g. malloc() you should not declare it yourself. You should
>> include the relevant header, e.g. <stdlib.h>
>
> Shouldn't that be <cstdlib>?
>
> sherm--
>

<stdlib.h> is working and not going away. As far as I have understood,
calling it deprecated was kind of wishful thinking in the current standard,
and will be corrected in the next standard. IMO, the main controversy is
that it is not understandable why I should call a C function through a name
in std:: namespace, albeit in C there are no namespaces.

Paavo

jason.cipriani@gmail.com

12/7/2008 6:37:00 PM

0

On Dec 7, 11:39 am, Paavo Helde <pa...@nospam.please.ee> wrote:
> Sherm Pendley <spamt...@dot-app.org> kirjutas:
>
> > Paavo Helde <pa...@nospam.please.ee> writes:
>
> >> For using e.g. malloc() you should not declare it yourself. You should
> >> include the relevant header, e.g. <stdlib.h>
>
> > Shouldn't that be <cstdlib>?
>
> > sherm--
>
> <stdlib.h> is working and not going away. As far as I have understood,
> calling it deprecated was kind of wishful thinking in the current standard,
> and will be corrected in the next standard. IMO, the main controversy is
> that it is not understandable why I should call a C function through a name
> in std:: namespace, albeit in C there are no namespaces.

It's understandable because the C++ standard defines it as so (sorry I
do not have the document in front of me to cite section numbers). In C+
+, use <cstdlib>, and std::malloc(). It's true <stdlib.h> is not going
away, and I have to admit I frequently use it myself, but it's only
maintained for backwards compatibility with C.

I'm not so sure it will be "corrected" in the next standard (nor what
you mean by "corrected"), but they'd certainly be well within their
rights to make stdlib.h go away entirely, seeing as how it's been
deprecated for quite some time.

Jason

Paavo Helde

12/7/2008 9:45:00 PM

0

"jason.cipriani@gmail.com" <jason.cipriani@gmail.com> kirjutas:

> On Dec 7, 11:39 am, Paavo Helde <pa...@nospam.please.ee> wrote:
>> Sherm Pendley <spamt...@dot-app.org> kirjutas:
>>
>> > Paavo Helde <pa...@nospam.please.ee> writes:
>>
>> >> For using e.g. malloc() you should not declare it yourself. You
>> >> should include the relevant header, e.g. <stdlib.h>
>>
>> > Shouldn't that be <cstdlib>?
>>
>> > sherm--
>>
>> <stdlib.h> is working and not going away. As far as I have
>> understood, calling it deprecated was kind of wishful thinking in the
>> current standar
> d,
>> and will be corrected in the next standard. IMO, the main controversy
>> is that it is not understandable why I should call a C function
>> through a na
> me
>> in std:: namespace, albeit in C there are no namespaces.
>
> It's understandable because the C++ standard defines it as so (sorry I
> do not have the document in front of me to cite section numbers). In
> C+ +, use <cstdlib>, and std::malloc(). It's true <stdlib.h> is not
> going away, and I have to admit I frequently use it myself, but it's
> only maintained for backwards compatibility with C.
>
> I'm not so sure it will be "corrected" in the next standard (nor what
> you mean by "corrected"), but they'd certainly be well within their
> rights to make stdlib.h go away entirely, seeing as how it's been
> deprecated for quite some time.

This has been up before. See e.g.

http://groups.google.com/group/comp.lang.c++/browse_thread/thre...
1afc0caec/8d59901225968ac9

By "corrected" I was referring to something what James Kanze mentioned in
a message in that thread: "Implementations where the <c...>
libraries work as specified are so rare that the standards
committee changed the specification."

However, I am not fully sure what the change involved. I thought this was
the removal of "deprecated" status of C headers, but rereading that
thread I now see they only talk about who exactly should propose the
issue to the committee.

Paavo

James Kanze

12/8/2008 10:49:00 AM

0

On Dec 7, 10:44 pm, Paavo Helde <pa...@nospam.please.ee> wrote:
> "jason.cipri...@gmail.com" <jason.cipri...@gmail.com> kirjutas:
> > On Dec 7, 11:39 am, Paavo Helde <pa...@nospam.please.ee> wrote:
> >> Sherm Pendley <spamt...@dot-app.org> kirjutas:
> >> > Paavo Helde <pa...@nospam.please.ee> writes:
> >> >> For using e.g. malloc() you should not declare it yourself. You
> >> >> should include the relevant header, e.g. <stdlib.h>

> >> > Shouldn't that be <cstdlib>?

> >> > sherm--

> >> <stdlib.h> is working and not going away. As far as I have
> >> understood, calling it deprecated was kind of wishful
> >> thinking in the current standard, and will be corrected in
> >> the next standard. IMO, the main controversy is that it is
> >> not understandable why I should call a C function through a
> >> name in std:: namespace, albeit in C there are no
> >> namespaces.

> > It's understandable because the C++ standard defines it as
> > so (sorry I do not have the document in front of me to cite
> > section numbers). In C+ +, use <cstdlib>, and std::malloc().
> > It's true <stdlib.h> is not going away, and I have to admit
> > I frequently use it myself, but it's only maintained for
> > backwards compatibility with C.

> > I'm not so sure it will be "corrected" in the next standard
> > (nor what you mean by "corrected"), but they'd certainly be
> > well within their rights to make stdlib.h go away entirely,
> > seeing as how it's been deprecated for quite some time.

> This has been up before. See e.g.

> http://groups.google.com/group/comp.lang.c++/browse_thread/......
> 1afc0caec/8d59901225968ac9

> By "corrected" I was referring to something what James Kanze
> mentioned in a message in that thread: "Implementations where
> the <c...> libraries work as specified are so rare that the
> standards committee changed the specification."

The change is independant of any removal of deprecation. In the
current standard, inclusion of a <c...> header is not allowed to
introduce any names in the global namespace (except things
required to be macros, like assert). In practice, most
implementations use the C library, doing something along the
lines of:

#include <stdio.h>
namespace std {
using ::printf ;
...
}

There are some very, very good reasons for this, but according
to the current standard, it's illegal. The next version of the
standard will authorize it---if you include <c...>, you're
guaranteed to get the names in std::, and it's unspecified
whether they are also present in ::.

> However, I am not fully sure what the change involved. I
> thought this was the removal of "deprecated" status of C
> headers, but rereading that thread I now see they only talk
> about who exactly should propose the issue to the committee.

The current CD still declares the <...h> headers as
"deprecated". (CD, here, means committee draft; an official
draft which has been submitted for voting on by the national
bodies.)

I'll admit that I'm of two minds as to which to use. Somethings
are so much a part of C++ (e.g. size_t, or time()), that it
seems normal to prefix them with an std::, and thus to include
<cstddef> or <ctime>. On the other hand, if you really are
using them "as C", or if you're using them as Posix headers
(e.g. <time.h>, with strptime), it seems more normal (to me, at
least) to use the <xxx.h> forms, with the functions in ::. Of
course, if you're into using std::vector<T>::size_type, rather
than size_t or std::size_t, and other solutions for e.g. time
(say Boost), then about the only times you'll want to include
them is for Posix. And Posix doesn't defined any <cxxx>
headers. (Of course, in cases where Posix defines a modified
version of the C headers, with extensions, I'd expect to find
those extensions available in the corresponding <cxxx> header,
in the same way as the standard C functions are. But that's a
QoI issue, not guaranteed by any standard.)

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

Jobin Paul

12/8/2008 12:57:00 PM

0

Hi,
If you are skeptic about stdlib.h then just use cstdlib which will
bring the c functions to std::.
Which also means they are c++ equivalent to the c ones. ( May be both
will get linked to the same library by the compiler)

Then you should never worry about linkage and declaration

Regards
Jobin

Juha Nieminen

12/8/2008 8:08:00 PM

0

mthread wrote:
> I have also understood in order to call a C method from a C++ program
> I need to declare the method using
> ' extern "C" ' keyword.

Nitpicking, but C has no "methods". A method is, by definition, a
member function of a class, and C has none of that.

What C has is functions.

Paavo Helde

12/8/2008 8:19:00 PM

0

Juha Nieminen <nospam@thanks.invalid> kirjutas:

> mthread wrote:
>> I have also understood in order to call a C method from a C++ program
>> I need to declare the method using
>> ' extern "C" ' keyword.
>
> Nitpicking, but C has no "methods". A method is, by definition, a
> member function of a class, and C has none of that.

Nitpicking continued: C++ also does not have methods; instead it has member
functions. The standard only mentions "method" in sentences like: "The
method by which a sequence of preprocessing tokens between a < and a >
preprocessing token pair or a pair of " characters is combined into a
single header name preprocessing token is implementation-defined."

Paavo

Juha Nieminen

12/9/2008 8:37:00 PM

0

Paavo Helde wrote:
> Nitpicking continued: C++ also does not have methods; instead it has member
> functions. The standard only mentions "method" in sentences like: "The
> method by which a sequence of preprocessing tokens between a < and a >
> preprocessing token pair or a pair of " characters is combined into a
> single header name preprocessing token is implementation-defined."

Just because the standard doesn't use the term "method" as a synonym
for "member function" doesn't mean it isn't. Maybe the standard simply
wants to avoid confusion by using a more unambiguous term (and
rightfully so).