Действительно ли использование является слишком большим количеством помех, плохих или хороших?

Я - все для использования статичного функции . Они просто имеют смысл особенно при организации в модули (static class в C#).

Однако момент для тех функций нужно некоторое внешнее (не константа времени компиляции) данные, тогда та функция должна делаться методом экземпляра и инкапсулироваться наряду с его данными в класс.

Вкратце: статические функции хорошо, статические данные плохо.

Используйте пространства имен для создания набора из функций:

namespace Console {
    void WriteLine(...) // ...
}

Что касается памяти, функции используют ту же сумму вне функции как статическая функция членства или в пространстве имен. Это: никакая память другой, что сам код.

Одна определенная причина статические данные являются неправильными, то, что C++ не делает гарантий о порядке инициализации статических объектов в различных единицах перевода. На практике это может вызвать проблемы, когда один объект зависит от другого в другой единице перевода. Scott Meyers обсуждает это в Объекте 26 из его книги Более эффективный C++.

Согласитесь с Frank здесь, нет проблемы со статическими (глобальными) функциями (конечно, если они организованы).. Проблемы только начинают действительно закрадываться, когда люди будут думать, "о, что я просто сделаю объем на этом бите данных немного шире".. Скользкий путь:)

Для помещения его действительно в перспективу.. Функциональное программирование ;)

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

BTW, если у Вас есть класс, который состоит только из статических данных и функций, необходимо объявить, что конструктор является частным, таким образом, никто не пытается инстанцировать его. (Это - одна из причин, некоторые требуют использовать пространства имен, а не классы.)

Проблема со статическими функциями состоит в том, что они могут привести к дизайну, который повреждает инкапсуляцию. Например, если Вы пишете что-то как:

public class TotalManager
{
    public double getTotal(Hamburger burger)
    {
        return burger.getPrice() + burget.getTax();
    }
}

... тогда Вы, возможно, должны были бы заново продумать свой дизайн. Статические функции часто требуют, чтобы Вы использовали методы set и методов get, которые создают помехи API Класса, и делает вещи более сложными в целом. В моем примере могло бы быть лучше удалить методов get Гамбургера и просто переместить getTotal () класс в сам Гамбургер.

Для организации используйте пространства имен, как уже указано.

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

Также быть уверенным, что Ваши статические функции являются не сохраняющими состояние так, чтобы они были ориентированы на многопотоковое исполнение.

Обычно я использую статику только в сочетании с системой друзей.

Например, у меня есть класс, который использует множество (встроенных) внутренних вспомогательных функций для вычислений, включая операции с личными данными.

Это, конечно, увеличивает количество функций, которые имеет интерфейс класса. Чтобы избавиться от этого, я объявляю вспомогательный класс в исходном файле классов .cpp (и, следовательно, невидимый для внешнего мира), делаю его другом исходного класса, а затем перемещаю старые вспомогательные функции в статический (встроенный) член. функции вспомогательного класса, передавая старый класс по ссылке в дополнение к старым параметрам.

Это делает интерфейс тонким и не требует большого списка бесплатных функций для друзей. Встраивание тоже хорошо работает, поэтому я не совсем против статики. (Я избегаю этого, насколько могу, но мне нравится использовать это таким образом.)