bs@alice.UucP (Bjarne Stroustrup) (09/24/86)
> Path: ..!haddock!karl > > gaulke@uiucdcsp.CS.UIUC.EDU (Dave Gaulke) writes: > >I have found a problem with C++ when using it to write code for the DMD. > >The following is part of the output of the preprocessor when including the > >file <blit.h> for a simple program. > > > >typedef int (*ptr_fint)(); > >main() { (*((int (*)())((ptr_fint *)0x0071d700)[ 43]))( 1 ); } > > The problem is that "int (*)()" in oldC means "pointer to function returning > int" whereas in C++ it means "pointer to function taking no arguments and > returning int". "typedef int (*ptr_fint)(...);" is the correct declaration > in C++, and presumably there's a macro somewhere in blit.h that uses the > oldC cast "(int (*)())" which should be "(int (*)(...))" in C++. Thanks. There is. > The other compatibility problem which came up recently was a collision > between a structure tag and a variable (which share one namespace in C++). > > Bjarne: is there a CC option that gives you compatibility with oldC in these > two cases? Also, ANSI C preserves the oldC meaning of "int (*)()" and adds > "int (*)(void)" for functions with no arguments. Will C++ switch to this > notation? Does it currently accept this notation? C++ includes the "int (*)(void)" notation. After all, I did invent it. I don't particularly like it and dropped it as anything but a compatibility fudge after Doug McIlroy and Dennis Ritchie both condemmed it (that is, the ``f(void)'' notation) as an ``abommination''. For compatibility, cfront accepts the simplest cases of ``struct s s;''. It also typically warns against tham and there is no guarantee that this laxness will remain. ``struct s s;'' is not C++.