Re: Adding C++ header guards?

On Sun, Sep 11, 2016 at 04:32:07PM -0700, Sterling Hughes wrote: > I think a temporary exception would be fine: but I’m not sure the > impact, perhaps somebody who understands C++ better can chime in. Why > are ‘#includes’ _excluded_ from the extern “C” namespace? Is it > just to avoid

Re: Adding C++ header guards?

I think a temporary exception would be fine: but I’m not sure the impact, perhaps somebody who understands C++ better can chime in. Why are ‘#includes’ _excluded_ from the extern “C” namespace? Is it just to avoid cluttering that namespace? Or are there subtle/nefarious effects? If its

Re: Adding C++ header guards?

Right. You don't want to apply the namespace to *other* headers, just the current file. Those other headers might be designed for inclusion by a C++ program. On Sun, Sep 11, 2016 at 2:58 PM, Peter Snyder wrote: > I think this is great too, but I don’t think it’s keeping to

Re: Adding C++ header guards?

Ah ok, I didn't read the style guide - I just copied the style of the existing files I checked (the HAL headers) seem to put #ifdef __cplusplus before #includes. I had a further search and some files put it after, some before. I'll have a look at getting them after the #includes. Might be quite

Re: Adding C++ header guards?

I think this is great too, but I don’t think it’s keeping to the mynewt coding standard. In particular I think the C++ wrappers are supposed to appear after other included files and before any file content. For sure this messes up your script (sorry) but it avoids any potential conflicts with

Re: Adding C++ header guards?

On Sun, Sep 11, 2016 at 12:39:27PM -0700, Christopher Collins wrote: > Look great to me, thanks! I just have a question - the commit message > indicates that two files were not modified: > > libs/baselibc/src/baselibc_test/unittests.h > libs/shell/include/shell/shell_prompt.h > > Why

Re: Adding C++ header guards?

On Sun, Sep 11, 2016 at 08:19:58PM +0100, Tim Hutt wrote: > I like C++ and would like to use it with MyNewt, so I've written a very > hacky tool in Go to detect C++ header guards: > > https://github.com/Ti/GuardChecker > > Here is the result of running it on apache-mynewt-core: > >

Re: Removing os_error_t

On Sun, Sep 11, 2016 at 10:42:07AM -0700, Sterling Hughes wrote: [...] > So — prior to 1.0, I think we should clean this up. My proposal is to > go with plain old integers as error codes across the system. 0 is no > error, a negative value is the error code and a positive value can be > used

Removing os_error_t

Hey, Across the OS, we have two interfaces: some that use os_error_t, and the other that uses int’s for return codes. Personally, I have never liked using a typedef for an error code (largely as a short hand for an enum.) I like to have a single variable “rc” that I use for error