You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Sterling Hughes <st...@apache.org> on 2016/04/09 17:18:00 UTC

C++ compatibility

Hi,

I recently talked with a user of Mynewt, and they were trying to get our 
system header files into a C++ project.

I'm wondering if folks on the list know a better way of doing this, than 
just manually going to every header file and adding:

#ifdef __cplusplus
extern "C" {
#endif

#ifdef __cplusplus
}
#endif

If not, I guess we should probably go ahead and do that.

Sterling

Re: C++ compatibility

Posted by Greg Stein <gs...@gmail.com>.
On Sat, Apr 9, 2016 at 1:51 PM, Sterling Hughes <st...@apache.org> wrote:

> Hi Chris,
>
> On 4/9/16 11:41 AM, Christopher Collins wrote:
>
>> I know of no other way, aside from using a script to put those guards on
>> all the headers.  Note however that they only need to go on the public
>> include headers (include/), not the private headers in the src
>> directories.
>>
>
> Yup, although this should probably just go in the coding
> standards/standard header file framework.  I don't see there being a reason
> to keep these two different, except for a saving a little bit of work now.


I'd suggest just going with the guards, as y'all have noted. It's pretty
normal boilerplate, so won't scare anybody away.

(and as Chris noted: only needed within public headers)

>...

Cheers,
-g

Re: C++ compatibility

Posted by Sterling Hughes <st...@apache.org>.
Hi Chris,

On 4/9/16 11:41 AM, Christopher Collins wrote:
> I know of no other way, aside from using a script to put those guards on
> all the headers.  Note however that they only need to go on the public
> include headers (include/), not the private headers in the src
> directories.
>

Yup, although this should probably just go in the coding 
standards/standard header file framework.  I don't see there being a 
reason to keep these two different, except for a saving a little bit of 
work now.

> There is one other possibility.  I don't think it is what you're asking
> about, but I thought it was worth mentioning for completeness.  If the
> mynewt libraries were reduced to the subset of C and C++ (some people
> call this "Clean C"), then everything could be built with a C++
> toolchain.  In this case, there would be no need for the extern "C"
> guards.  I don't particularly care for this solution personally, as
> there are a few annoying differences between the languages (one of the
> biggest being that C++ does not support the implicit conversion to and
> from void*).
>

Nah.  We're writing this in C, and especially when it gets to mixed 
C/assembly, lower layer C, I'm not sure all the contortions make sense. 
  We can just '#ifdef __cplusplus.'

Sterling

Re: C++ compatibility

Posted by Christopher Collins <cc...@apache.org>.
I know of no other way, aside from using a script to put those guards on
all the headers.  Note however that they only need to go on the public
include headers (include/), not the private headers in the src
directories.

There is one other possibility.  I don't think it is what you're asking
about, but I thought it was worth mentioning for completeness.  If the
mynewt libraries were reduced to the subset of C and C++ (some people
call this "Clean C"), then everything could be built with a C++
toolchain.  In this case, there would be no need for the extern "C"
guards.  I don't particularly care for this solution personally, as
there are a few annoying differences between the languages (one of the
biggest being that C++ does not support the implicit conversion to and
from void*).

Chris

On Sat, Apr 09, 2016 at 08:18:00AM -0700, Sterling Hughes wrote:
> Hi,
> 
> I recently talked with a user of Mynewt, and they were trying to get our 
> system header files into a C++ project.
> 
> I'm wondering if folks on the list know a better way of doing this, than 
> just manually going to every header file and adding:
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> #ifdef __cplusplus
> }
> #endif
> 
> If not, I guess we should probably go ahead and do that.
> 
> Sterling