If you're exporting symbols, you could have the visibility attribute be part of
the macro you wrap around 'extern' anyway:
#if defined(__cplusplus)
#define MY_EXTERN extern "C"
#else
#define MY_EXTERN extern
#endif
#define MY_EXPORT MY_EXTERN __attribute__((visibility("default")))
(The LLVM compiler uses the same attributes as GCC by and large, for
compatibility.)
This is essentially how such macros are defined in the various OS frameworks'
public <Framework/FrameworkDefines.h> headers and <Foundation/NSObjCRuntime.h>.
The visibility itself may have a macro in the main <Availability.h> header,
much like DEPRECATED_ATTRIBUTE. (Not able to check right now...)
Alternately, you could use an exports file to control visibility of what's
exported.
-- Chris
On Aug 10, 2011, at 4:06 PM, Daniel DeCovnick <[email protected]> wrote:
> The disadvantage is if you need to use string constants across binaries (such
> as constants used by plugins). If you strip symbols, you can't use them at
> all (whereas you can use #defines from an imported header file). If you don't
> strip symbols, you still need to declare them as follows:
>
> extern NSString *const __attribute__ ((visibility ("default"))) kStringName;
> so the linker won't mark the symbol hidden. (This is for GCC; I don't know
> the equivalent for Clang/LLVM)
>
> -Dan
>
> On Aug 9, 2011, at 10:10 AM, Gregory Weston wrote:
>
>> Devraj Mukherjee wrote:
>>
>>> I am writing an API client for a REST service, parts of the REST API
>>> returns fixed String values. E.g. status of an order.
>>>
>>> I want to represents these fixed responses as constants. I have
>>> represented fixed numeric values using enums and used a typedef to
>>> represent the data type.
>>>
>>> Are Strings defined using #define good enough as String constants?
>>>
>>> Or Should I be doing this another way?
>>>
>>> Thanks for your time.
>>
>> I'm still generally in favor of named constants over pre-processor
>> substitution. Gives you types and no worry about parentheses.
>
> _______________________________________________
>
> Cocoa-dev mailing list ([email protected])
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/cmh%40me.com
>
> This email sent to [email protected]
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
