статические данные класса по сравнению с анонимными пространствами имен в C++

1) There is a drawback in the form of an added restriction on binary organization. In a presentation at a C++ conference in the 1990s, Walter Bright reported achieving significant performance increases by organizing his code so that functions that called each other were in the same compilation unit. For example, if during execution Class1::method1 made far more calls to Class2 methods than to other Class1::methods, defining Class1::method1 in class2.cpp meant that Class1::method1 would be on the same code page as the methods it was calling, and thus less likely to be delayed by a page fault. This kind of refactoring is easier to undertake with class statics than with file statics.

2) One of the arguments against introducing the namespace keyword was "You can do the same thing with a class," and you will see class and struct being used as a poor-man's namespace in sources from the pre-namespace era. The convincing counter-argument was because namespaces are re-openable, and any function anywhere can make itself part of a namespace or access a foreign namespace, then there were things you could do with a namespace that you could not do with a class. This has bearing on your question because it suggests that the language committee was thinking of namespace scope as very much like class scope; this reduces the chance that there is some subtle linguistic trap in using an anonymous namespace instead of a class static.

Я не согласен с другими ответами. Держите как можно больше вне класса определение как возможно.

В Эффективный C ++ 3-е издание Скотта Мейерса он рекомендует предпочитать не-друг функции в методы класса. Таким образом, определение класса выглядит как как можно меньше, личные данные доступны в минимальном количестве мест, возможно (инкапсулировано).

Следование этому принципу приводит к идиоме pimpl . Тем не мение, нужен баланс. Убедитесь, что ваш код удобен для сопровождения. Слепо, следуя этому правилу, вы сделаете все свои частные методы file local и просто передайте необходимые члены в качестве параметров. это улучшит инкапсуляцию , но ухудшит ремонтопригодность.

При этом локальные объекты файлов очень трудно поддаются модульному тестированию. С участием какой-то хитрый взлом вы можете получить доступ к частным членам во время модульных тестов. Доступ к локальным объектам файла требует немного больше .

I'm not convinced that the benefit is worth the readability impact. I generally consider something that's private to be "hidden enough."

It not only hides them from users of the class, it hides them from you! If these variables are part of the class, they should be associated with the class in some way.

Depending on what you are going to do with them, you could consider making them static variables inside static member functions:

// header file
class A {
  public:
     static void func();
};


// cpp file
void A :: func() {
    static int avar = 0;
    // do something with avar
}

I guess it boils down to whether these variables have some actual meaning in the context of the class (e.g., pointer to some common memory used by all objects) or just some temporary data you need to pass around between methods and would rather not clutter the class with. In the latter case I would definitely go with the unnamed namespace. In the former, I'd say it's a matter of personal taste.

Я частично согласен с Грегом в том, что безымянные элементы пространства имен не более инкапсулированы, чем личные данные. В конце концов, цель инкапсуляции - скрыть детали реализации от других модулей, а не от других программистов. Тем не менее, я думаю, что в некоторых случаях это полезный метод.

Рассмотрим такой класс:

class Foo {
public:
    ...
private:
    static Bar helper;
};

В этом случае любой модуль, который хочет использовать Foo, должен также знать определение Bar, даже если это определение вообще не имеет значения. Подобные зависимости заголовков приводят к более частым и длительным перестройкам. Перенос определения помощника в безымянное пространство имен в Foo.cpp - отличный способ разорвать эту зависимость.

Я также категорически не согласен с представлением о том, что безымянные пространства имен почему-то менее читабельны или менее удобны в обслуживании, чем статические элементы данных. Удаление нерелевантной информации из заголовка делает его более лаконичным.