在Objective C [duplicate]中使用#define或extern NSString *const是更好的选择

时间:2022-09-07 21:08:59

This question already has an answer here:

这个问题已经有了答案:

I have some strings in my project and I want to put all the strings in a common file say constants.

我的项目中有一些字符串,我想把所有字符串放到一个普通文件中,比如常量。

(1st Approach) In constants.h, I can do :

(方法1)常量。h,我可以:

    #define COMMON_STRING @"myString"

OR

(2nd Approach)

(方法二)

In constants.h

在constants.h

    extern NSString *const COMMON_STRING;

In constants.m

在constants.m

    NSString *const COMMON_STRING = @"myString";

Which approach is better to use and why?or do we have some other better approach for this?

使用哪种方法更好,为什么更好?或者我们还有其他更好的方法吗?

EDIT:

编辑:

According to that post extern NSString *const COMMON_STRING; is better in terms of memory perspective. But somewhere I have also read that The #define will insert the string into all the occurrences, by that - multiplying the memory usage unless compiler optimizing same constant string occurrences — which is the case.So does it make sense not to use #define?

根据那个post extern NSString *const COMMON_STRING;从记忆的角度来说更好。但是我也读到过,#define将把字符串插入到所有的事件中,这样,除非编译器优化相同的常量字符串,否则将增加内存使用。不使用#define有意义吗?

In the suggested posts one post only defines the structure and other is explaining the comparison but very limited and not what I am expecting.If compiler is optimizing same constant string occurrences then why to use extern NSString *const COMMON_STRING and not #define COMMON_STRING?

在建议的帖子中,一个帖子只定义了结构,另一个帖子解释了比较,但非常有限,并不是我所期望的。如果编译器正在优化相同的常量字符串出现,那么为什么要使用extern NSString *const COMMON_STRING而不是#define COMMON_STRING呢?

1 个解决方案

#1


2  

Generally speaking:

一般来说:

static const

It respects scope and it is type-safe.

它尊重范围并且类型安全。

The only limitation I could see was that if you want the variable to be possibly defined on the command line.

我能看到的唯一限制是,如果您希望在命令行上定义变量。

But there is still an alternative:

但还有一个选择:

#ifdef VAR // Very bad name, not long enough, too general, etc..
static int const var = VAR;
#else
static int const var = 5; // default value
#endif

Whenever possible, instead of macros / ellipsis, use a type-safe alternative.

尽可能使用类型安全的替代方法,而不是宏/省略号。

If you really NEED to go with a macro (for example, you want FILE or LINE), then you'd better name your macro VERY carefully because in its naming convention Boost recommends all upper-case, beginning by the name of the project (here BOOST_), while using the library you will notice this is (generally) followed by the name of the particular area (library) then with a meaningful name.

如果你真的需要去与宏观(例如,你想要的文件或线),然后你最好仔细命名您的宏,因为在它的命名约定提高建议所有大写,开始由项目的名称(这里BOOST_),在使用图书馆你会发现这是(通常)紧随其后的是特定区域的名称(图书馆),那么一个有意义的名字。

#1


2  

Generally speaking:

一般来说:

static const

It respects scope and it is type-safe.

它尊重范围并且类型安全。

The only limitation I could see was that if you want the variable to be possibly defined on the command line.

我能看到的唯一限制是,如果您希望在命令行上定义变量。

But there is still an alternative:

但还有一个选择:

#ifdef VAR // Very bad name, not long enough, too general, etc..
static int const var = VAR;
#else
static int const var = 5; // default value
#endif

Whenever possible, instead of macros / ellipsis, use a type-safe alternative.

尽可能使用类型安全的替代方法,而不是宏/省略号。

If you really NEED to go with a macro (for example, you want FILE or LINE), then you'd better name your macro VERY carefully because in its naming convention Boost recommends all upper-case, beginning by the name of the project (here BOOST_), while using the library you will notice this is (generally) followed by the name of the particular area (library) then with a meaningful name.

如果你真的需要去与宏观(例如,你想要的文件或线),然后你最好仔细命名您的宏,因为在它的命名约定提高建议所有大写,开始由项目的名称(这里BOOST_),在使用图书馆你会发现这是(通常)紧随其后的是特定区域的名称(图书馆),那么一个有意义的名字。