On 26 November 2010 22:17, Jay K wrote:
>
> I somewhat tracked down the odd/dubious reason extern "C" is "good".
This behaviour of Apple's gdb is a poor reason to modify GCC sources.
It's probably just that gdb didn't use to be very good at matching C++
function names.
> ...
> (gdb) break F2
Wh
I somewhat tracked down the odd/dubious reason extern "C" is "good".
Some wierd interaction on Darwin with Apple's gcc and gdb.
Breakpoints don't work on non-extern "C", at least if a library is involved.
This isn't necessarily a problem with gcc, or current gcc, or non-Apple gcc,
or gdb, or n
On Mon, Nov 15, 2010 at 7:19 PM, Jay K wrote:
>
> I know it is debatable and I could be convinced otherwise, but I would
> suggest:
>
>
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> ...
>
>
> #ifdef __cplusplus
> } /* extern "C" */
> #endif
>
>
> be applied liberally in gcc.
> Not "around" #
Jay K writes:
> Any folks that get to see the mangled names, debugging, working on
> binutils, whatever, are saved from them.
Demangling is easy and readily available.
I don't see any reason to add extern "C" indiscriminately at this time.
If there are concrete problems, then those are prob
I know it is debatable and I could be convinced otherwise, but I would suggest:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
} /* extern "C" */
#endif
be applied liberally in gcc.
Not "around" #includes, it is the job of each .h file, and mindful of #ifdefs
(ie: cor
