[omniORB-dev] C++ include guards, continued

Duncan Grisby duncan at grisby.org
Wed Apr 18 23:55:46 BST 2007


On Tuesday 17 April, Austin Bingham wrote:

> After some poking around, I've been able to modify the C++ backend to 
> accept an include guard prefix. In effect, where the generated header used 
> to say:
> 
>    #ifndef __<filename>_hh__
> 
> it now says:
> 
>    #ifndef <guard-prefix>__<filename>_hh__
> 
> I've made an analogous change to the EXTERNAL_GUARD macro, since it 
> suffers from the same deficiency.

Great!  Thanks for doing it.

> So my first question is: Are any other places that might 
> benefit from a change like this? I see an include guard in the 
> interface_Helper template, but I'm not entirely sure what that it used 
> for. I'll be happy to add guard-prefix support for that if needed.

Code for the interface_Helper is generated each time an interface
forward declaration is made. The guard macros are used to ensure only
one set of helpers are visible to C++. You'd only need to prefix the
guards if you have multiple IDL files defining interfaces with the same
fully scoped names of each other, and you have much bigger problems
than just guard macro names if that is the case.

> Next, would you rather use something other than or along with a simple 
> prefix string? We could add a suffix, or perhaps there is some other 
> alternative I haven't considered.

I don't think there's any need for anything other than the prefix. A
suffix would work fine as an alternative, but I don't see any value in
having both.

> Finally, how should I get these changes submitted? Should I just send a 
> patch to someone? I'm working against the omni4_0_develop branch.

Send a patch to this list, or send it just to me if you prefer. It would
be best if you can do the patch against omni4_1_develop, since
omni4_0_develop isn't really active any more, aside from critical issues.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --



More information about the omniORB-dev mailing list