Have there been any changes from the ARM regarding 'extern "C"'
functions?

I see three main problems with the rules in the ARM in relation to
the "C" standard library inherited from ANSI C:

    a) qsort/bsearch - must the function pointer supplied to this be
a "C" or "C++" function.  If the ANSI C library is now a part of the
C++ standard library, then having to use 'extern "C"' functions with
qsort/bsearch will be inconvenient and not a little ridiculous.  For
example using static member functions or template functions as the
comparison function.

    b) atexit - similarly for this - though the function of this can
be replaced by a destructor for a global static object.

    c) signal - the handler function may cause problems.

I'm sure there's other similar cases.

There's many similar problems when trying to hook into other existing
"C" libraries, the most visible case to me has been windowing systems
(MS Windows, X Window etc).  For example see the "C++ Report" Vol 6,
No 9, p43.

Has there been any discussion on this, as it can affect portability.
Should a compiler give a diagnostic when a "C++" function pointer is
passed where a "C" function is required or vica-versa?

Of course I could be speaking through my hat (if I had one...)

I am curious, does:

    extern "C" {
    class A
    {
      public:
        static int f();
    };
    }

    int A::f()
    {
        return 0;
    }

mean that A::f() has "C" calling convention? (I doubt it...)

I can only see this as an issue for extern "C" functions, as C is so
closely tied to C++ - it's not really such an issue for 'extern
"Ada"' or 'extern "FORTRAN"' as these languages are not so closely
tied to C++.


--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

In article <2rpeko$f27@news.utdallas.edu>, vmathur@utdallas.edu (Vineet K Mathur) writes:
|> I am using Borland C++ 3.1 and it appears that the extern "C" specification
|> is really redundant. In every case, I am able to compile my C functions without
|> the extern "C" qualifier. Basically I can call any C function as a global C++
|> function.
|>
|> Can anyone give an example where *not* using extern "C" can cause a problem ?
|> (In any compiler)
|> --

Every time you link C++ code and C code together.

Compilers provide the facility of 'adding' extern "C" specifications to the functions you reference
and that it explicitely declares.

Example :

main () {
 printf("Hello world\n");
}

With g++ this code compiles and links without any problem, but the compiler warns and implicitely
declares printf as : extern "C" int printf (const char * ...);  (or whatever)

Try the same program by declaring yourself printf as : int printf (const char * ...); and
you will get the following link error :

/bin/ld:
Undefined:
printf__FPCce

Add yourself extern "C" before the concerned declaration and your program will compile without
warning and will link fine.

--------Etienne FREJAVILLE---Bull S.A   ---------------------------------
 OSS/HEU/ACS/LPS/TOPAS                  e-mail: E.Frejaville@frcl.bull.fr
 Rue Jean-Jaures, F6/1D/17, BP 53       tel: (33-1) 30806548
 78340 Les Clayes-sous-Bois, France     Fax: (33-1) 30807950

In article <2rpeko$f27@news.utdallas.edu>
vmathur@utdallas.edu (Vineet K Mathur) stepped in it:

VKM>I am using Borland C++ 3.1 and it appears that the extern "C" specification
VKM>is really redundant. In every case, I am able to compile my C functions with
VKM>the extern "C" qualifier. Basically I can call any C function as a global C+
VKM>function.

VKM>Can anyone give an example where *not* using extern "C" can cause a problem
VKM>(In any compiler)
VKM>--

char* strcpy(char* dest, const char* src);
int main()
{
char buff[80];
(void) strcpy(buff, "hi there");
return 0;
}

Linker error : Undefined symbol strcpy(char*, const char*)
(In any compiler).

---
. OLX 2.2 . I tryed to draw a picture of my shadow but it kept moving

I am using Borland C++ 3.1 and it appears that the extern "C" specification
is really redundant. In every case, I am able to compile my C functions without
the extern "C" qualifier. Basically I can call any C function as a global C++
function.

Can anyone give an example where *not* using extern "C" can cause a problem ?
(In any compiler)
--

Vineet K Mathur (vmathur@utdallas.edu) wrote:
: I am using Borland C++ 3.1 and it appears that the extern "C" specification
: is really redundant. In every case, I am able to compile my C functions without
: the extern "C" qualifier. Basically I can call any C function as a global C++
: function.
: Can anyone give an example where *not* using extern "C" can cause a problem ?
: (In any compiler)
: --
//Try the following program:

//////Filename: testc.cpp
//////compile&link: bcc testc.cpp
/////do NOT include <stdio.h>
///note that printf is in "C" library, NOT in "C++" library
//
extern "C" int __cdecl printf(char *fmt, ...);
void swap(int &m, int &n)  //is a c++ program
{
   int tmp=m; m=n; n=tmp;
}
void main()
{     int x=38, y=49;
   printf("x=%d, y=%d\n",x,y);
   swap(x,y);
   printf("x=%d, y=%d\n",x,y);
}

--
--------------------------------------------
 Wen-Nung Tsai
 INTERNET:    tsaiwn@csunix.csie.nctu.edu.tw Dep. of CSIE
 BITNET:      tsaiwn@twnctu01.bitnet  National Chiao Tung University
      HsinChu, Taiwan, R.O.C.

vmathur@utdallas.edu (Vineet K Mathur) writes:

>I am using Borland C++ 3.1 and it appears that the extern "C" specification
>is really redundant. In every case, I am able to compile my C functions without
>the extern "C" qualifier. Basically I can call any C function as a global C++
>function.

>Can anyone give an example where *not* using extern "C" can cause a problem ?
>(In any compiler)

extern "C" is not used to "compile" C function, it is used to "link"
with C functions that have been compiled already by the C compiler.
You should use extern "C" any time you want a C program (i.e. compiled
with the C compiler) to be able to call a C++ program, or vice versa.


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++