Всегда создавать классы на C ++? [закрыто]

17

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

Теперь я реализую общую библиотеку, которая не имеет основной функции и исключительно статических функций-членов. Что-то говорит против создания класса для инкапсуляции функций?

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

    
задан Konrad Reiche 19.04.2011 в 21:54
источник
  • Может показаться интересным: класс статических членов против обычного C-подобного интерфейса. –  Xeo 19.04.2011 в 21:58

6 ответов

3

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

class HelperFunctions
{
public:
    static void DoSomethingUseful() { /* useful bits */ }
    // yata yata
private:
    HelperFunctions(); // private default constructor
    HelperFunctions(const HelperFunctions&); // private copy constructor
};

Тогда вы можете сделать что-то вроде этого:

HelperFunctions::DoSomethingUseful();

Но вы не могли бы сделать что-то вроде этого:

HelperFunctions myHelperFunction; // private constructor = compile error

Вы также можете создавать пространства имен для целей организации, не являющихся членами.

namespace HelperFunctions
{
   void DoSomethingUseful() { /* useful bits */ }
   // yata yata
}

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

В отличие от Java, где все - это метод в C ++, мы можем иметь функции в глобальном пространстве имен или в пространстве членов. Вы также можете иметь функции друзей, не являющихся членами, которые могут обращаться к внутренним членам класса, не являясь самим классом.

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

Изменить: Почему так серьезно?

Я не предполагал, что OP должен или не должен делать. Казалось, что они были новыми для C ++, исходящими из мира Java, где все это метод, а все «функции» являются членами класса. На это повлиял мой ответ: показать, как сначала вы можете создать что-то на C ++, аналогично тому, что у вас есть на Java, а во-вторых, как вы можете делать и другие вещи, и почему это так.

Как утверждали другие, считается хорошей практикой предпочитать не-членские функции, отличные от друга, по возможности по разным причинам. Я согласен, если вам не нужен объект с состоянием, чем вы, вероятно, не должны его проектировать. Однако я не уверен, искал ли OP философское обсуждение лучших практик в области проектирования и реализации или просто любопытство для эквивалентного C ++.

Я надеялся, что моя последняя строка, шутящая о том, чтобы выстрелить себе в ногу, была достаточной, чтобы подчеркнуть, что «просто потому, что вы можете, не означает, что вам следует», но, возможно, не с этой толпой.

    
ответ дан AJG85 19.04.2011 в 22:06
источник
  • -1: Да, вы можете это сделать. Но если вы создадите класс с общедоступной статикой и даже перейдете к тому, чтобы сделать ctor private: так, чтобы никто не смог его создать, тогда IMO вы должны просто сделать эти функции, не являющиеся членами, в пространстве имен. Помещение их в класс не дает вам ничего кроме области пространства имен (которую вы можете получить напрямую) и может подразумевать семантику, которая не существует. –  John Dibling 19.04.2011 в 22:24
  • -1 Я полностью согласен с Джоном. –  ltjax 19.04.2011 в 22:25
  • @Billy, @ AJG85, @platzhirsch: Честно говоря, если бы OP не принял этот ответ, я бы не отказался от него. Но OP специально сказал: «Что-то говорит против создания класса для инкапсуляции функций?» И я думаю, что ответ на этот вопрос «да». Это указывает на то, что OP думает, что это означает, что они должны быть статическими членами, и я пытаюсь привлечь внимание к тому факту, что некоторые (большинство) из нас не думают, что они должны. –  John Dibling 19.04.2011 в 22:31
  • @Giovanni: Пожалуйста, скажите, что это не так. –  John Dibling 19.04.2011 в 22:59
  • @ AJG85: повторите свое редактирование. Когда я читаю OP: «Что-то говорит против создания класса для инкапсуляции функций?» который звучал для меня так, как будто он запрашивал совет о том, что он должен или не должен делать. Вы ответили не так, но когда OP принял это, он сказал мне, что он думал, что это то, что он должен делать, и это неправильно. Здесь вы просто невинная жертва. –  John Dibling 19.04.2011 в 23:02
Показать остальные комментарии
20

Если вы обнаружите, что у вас есть класс, где каждый метод статичен, возможно, более подходящим будет namespace .

    
ответ дан chrisaycock 19.04.2011 в 21:57
источник
10

Честно говоря, это философское и нечеткое руководство, но я предпочитаю сначала использовать простейшие вещи, а затем создавать сложную сложность, когда это необходимо.

Мое первое предпочтение

  1. Свободные, безгосударственные, побочные эффекты, которые выполняют некоторые операции / вычисления / преобразования на своих аргументах и ​​возвращают результат (ы).

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

Файловый ввод-вывод является примером того, что имеет состояние. Вы открываете файл, записываете в него некоторые данные, которые перемещаются вперед по указателю записи и в конечном итоге закрывают его, что является хорошим примером того, где вы хотите класс.

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

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

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

    
ответ дан Doug T. 19.04.2011 в 22:04
источник
  • +1 для того, чтобы поставить это в терминах «имеет ли функция состояние то, что должно принять это решение». –  Billy ONeal 19.04.2011 в 22:05
  • @Mike, yup исправлено. –  Doug T. 19.04.2011 в 22:51
  • +1 Благодарю вас за то, что вы выбрали все суеты и бесполезные соображения, которые загрязняют такую ​​дискуссию ни о чем. –  gd1 20.04.2011 в 02:14
  • @ Giacomo да, это все еще нечеткое, потому что вы не хотите ставить каждую операцию, которая может работать с частью данных с сохранением состояния в методе, но эти функции должны, по крайней мере, работать через безопасный объект состояния, красиво инкапсулированный интерфейс, чтобы что-то сделать. Но я думаю, что в целом это хороший совет. –  Doug T. 20.04.2011 в 02:16
4

Вы можете определить пространство имен вместо класса.

namespace mycode
{
    //Code for the library here
    void myfunction()
    {
         //function definition
    }
}

, тогда, когда вам нужно его использовать, вы можете либо предисловие, либо использование пространства имен

mycode::myfunction()

или

using mycode;

myfunction();
    
ответ дан Kyle Sletten 19.04.2011 в 21:58
источник
3

Собственно, если код не принадлежит классу, вы не должны помещать его в класс на C ++. То есть, следует отдать предпочтение не- friend не-членным функциям для функций member и friend . Причина в том, что вытаскивание метода из класса приводит к лучшей инкапсуляции.

Но не верьте мне на слово, см. «Эффект C ++» Скотта Майерса Эффективный элемент C ++ # 23: Предпочитайте функции, отличные от членов, не являющихся членами для функций-членов .

    
ответ дан Billy ONeal 19.04.2011 в 22:03
источник
  • Я был бы признателен за комментарий, объясняющий нижний план. И если это месть за то, что я склоняюсь к другому ответу, это ужасная причина для понижения ... –  Billy ONeal 19.04.2011 в 22:15
  • +1: Я согласен, что этот d / v кажется необоснованным. Хотя это не самый полезный ответ (т. Е. Потому, что он не рассматривает, как решить, действительно ли код принадлежит или не принадлежит классу), и он дискуссионный (некоторые утверждают, что статические публики более естественны), это, конечно, не неверен. –  John Dibling 19.04.2011 в 22:20
  • @ Джон, я думаю, что три из самых влиятельных личностей в мире C ++ (Meyers, Sutter, Alexandrescu) публично объявляют, что вы должны предпочесть не-членские функции, отличные от друзей, почти всегда составляют довольно хороший аргумент. –  ltjax 19.04.2011 в 22:24
  • ___ answer5721926 ___ <div class="post-text" itemprop="text"> <p> Если вы обнаружите, что у вас есть класс, где каждый метод статичен, возможно, более подходящим будет %code% . </p>     </DIV> ___ qstnhdr ___ Всегда создавать классы на C ++? [закрыто] ___ answer5722025 ___ <div class="post-text" itemprop="text"> <p> Не уверен, что я полностью понимаю вас, но да, вы можете создать класс контейнера, который предоставляет статические методы. Возможно, стоит сделать конструкторы частными, чтобы люди не могли создавать экземпляр класса. </P> %pre% <p> Тогда вы можете сделать что-то вроде этого: </p> %pre% <p> Но вы не могли бы сделать что-то вроде этого: </p> %pre% <p> Вы также можете создавать пространства имен для целей организации, не являющихся членами. </p> %pre% <p> Помните, что вы можете определить пространства имен для нескольких файлов, а также сделать их особенно полезными для группировки объектов и функций, где бы они ни находились. <strong> Это предпочтительнее, поскольку он логически разделяет функции, делающие дизайн и предполагаемое использование более очевидными </strong> </p> <p> В отличие от Java, где все - это метод в C ++, мы можем иметь функции в глобальном пространстве имен или в пространстве членов. Вы также можете иметь функции друзей, не являющихся членами, которые могут обращаться к внутренним членам класса, не являясь самим классом. </P> <p> В принципе, вы можете делать все, что хотите, включая стрелять себе в ногу. </p> <p> Изменить: Почему так серьезно? </p> <p> Я не предполагал, что OP <strong> должен </strong> или <strong> не должен </strong> делать. Казалось, что они были новыми для C ++, исходящими из мира Java, где все это метод, а все <em> «функции» </em> являются членами класса. На это повлиял мой ответ: показать, как сначала вы можете создать что-то на C ++, аналогично тому, что у вас есть на Java, а во-вторых, как вы можете делать и другие вещи, и почему это так. </P> <p> Как утверждали другие, считается хорошей практикой предпочитать не-членские функции, отличные от друга, по возможности по разным причинам. Я согласен, если вам не нужен объект с состоянием, чем вы, вероятно, не должны его проектировать. Однако я не уверен, искал ли OP философское обсуждение лучших практик в области проектирования и реализации или просто любопытство для эквивалентного C ++. </P> <p> Я надеялся, что моя последняя строка, шутящая о том, чтобы выстрелить себе в ногу, была достаточной, чтобы подчеркнуть, что «просто потому, что вы можете, не означает, что вам следует», но, возможно, не с этой толпой. </p>     </DIV> ___ qstntxt ___ <div class="post-text" itemprop="text"> <p> Исходя из фона Java, для меня совершенно неожиданно иметь дело с выбором создания класса или просто с реализацией функций, которые могут мне понадобиться. Обычно это не вопрос, когда речь идет о моделировании чего-то, что может иметь состояние. </P> <p> Теперь я реализую общую библиотеку, которая не имеет основной функции и исключительно статических функций-членов. Что-то говорит против создания класса для инкапсуляции функций? </P> <p> Далее я хотел инкапсулировать дополнительный код, особенно вспомогательные функции, в другой файл. Код выполнения всегда один и тот же, и состояние его не изменяется, поэтому я предполагаю, что я объявляю их также статическими, поэтому здесь возникают те же вопросы. </P>     </DIV> ___ answer5721947 ___ <div class="post-text" itemprop="text"> <p> Вы можете определить пространство имен вместо класса. </p> %pre% <p>, тогда, когда вам нужно его использовать, вы можете либо предисловие, либо использование пространства имен </p> %pre% <p> или </р> %pre%     </DIV> ___ answer5721985 ___ <div class="post-text" itemprop="text"> <p> Осторожно, на C ++, статические функции <strong> </strong> - это функции, которые видны только для других функций в одном файле. Таким образом, в основном это вспомогательные функции, которые не могут быть частью интерфейса библиотеки. </P> <p> <strong> Статические методы </strong> в классах - это нечто совершенно другое (хотя в обоих случаях используется ключевое слово <em> same </em>). Они похожи на обычные функции, которые могут вызвать защищенные / частные методы в одном классе. Вы можете думать о статических методах как о простых (нестатических) функциях, которые являются «друзьями» с классом. </P> <p> Что касается общего руководства, я не думаю, что имеет значение, если у вас есть (нестатические) функции или статические методы в качестве интерфейса вашей библиотеки, это в основном вопрос синтаксиса: вызов %code% или вызов% код%. Вы также можете использовать %code% для инкапсуляции. В этом случае синтаксис: %code% для функции и %code% для статического метода. </P> <p> <strong> РЕДАКТИРОВАТЬ: </strong> Хорошо, но, хотя в ключевом слове <strong> static </strong> возникла путаница, получается, что это скорее спорный ответ, чем я бы хотел. Я лично предпочитаю термин <strong> метод </strong> для функций-членов (который также является тем же самым лексиконом, который используется в фактическом вопросе). И когда я сказал, что статические методы <em> могут вызывать частные методы </em>, я имел в виду видимость (контроль доступа a.k.a.). </P>     </DIV> ___ answer5721995 ___ <div class="post-text" itemprop="text"> <p> Собственно, если код не принадлежит классу, вы не должны помещать его в класс на C ++. То есть, следует отдать предпочтение не- %code% не-членным функциям для функций member и %code% . Причина в том, что вытаскивание метода из класса приводит к лучшей инкапсуляции. </P> <p> Но не верьте мне на слово, см. «Эффект C ++» Скотта Майерса <em> Эффективный элемент C ++ # 23: Предпочитайте функции, отличные от членов, не являющихся членами для функций-членов </em>. </p>     </DIV> ___ commmment6543500 ___ -1 Я полностью согласен с Джоном. ___ commmment6543480 ___ -1: Да, вы можете это сделать. Но если вы создадите класс с общедоступной статикой и даже перейдете к тому, чтобы сделать ctor private: так, чтобы никто не смог его создать, тогда IMO вы должны просто сделать эти функции, не являющиеся членами, в пространстве имен. Помещение их в класс не дает вам ничего кроме области пространства имен (которую вы можете получить напрямую) и может подразумевать семантику, которая не существует. ___ commmment6543065 ___ Может показаться интересным: класс статических членов против обычного C-подобного интерфейса. ___ commmment6544100 ___ @Giovanni: Пожалуйста, скажите, что это не так. ___ commmment6543628 ___ @Billy, @ AJG85, @platzhirsch: Честно говоря, если бы OP не принял этот ответ, я бы не отказался от него. Но OP специально сказал: «Что-то говорит против создания класса для инкапсуляции функций?» И я думаю, что ответ на этот вопрос «да». Это указывает на то, что OP думает, что это означает, что они должны быть статическими членами, и я пытаюсь привлечь внимание к тому факту, что некоторые (большинство) из нас не думают, что они должны. ___ commmment6544141 ___ @ AJG85: повторите свое редактирование. Когда я читаю OP: «Что-то говорит против создания класса для инкапсуляции функций?» который звучал для меня так, как будто он запрашивал совет о том, что он должен или не должен делать. Вы ответили не так, но когда OP принял это, он сказал мне, что он думал, что это то, что он должен делать, и это неправильно. Здесь вы просто невинная жертва. ___ commmment6543545 ___ @John @ltjax: Я не думаю, что AJG85 говорит, что это правильный курс действий; он говорит, что это можно сделать так (что есть). Я согласен с вами, ребята, но я не думаю, что это очень плохой ответ. ___ commmment6544106 ___ @ Гиованни - синглтоны плохие! Почему синглтоны злы ___ commmment6543846 ___ Я мог бы расходиться, но я предпочитаю одноточие для этого шаблона static-methods-and-private-constructor. Даже если он теперь выглядит без гражданства, вещи всегда развиваются, и синглтонная модель лучше подходит для эволюции с точки зрения состояния. ___ commmment6543511 ___ +1 для краткого указания всех мест C ++ позволяет нам ставить функции; хотя немного больше советов о том, когда кто-то должен использовать то, что было бы хорошо. :) (Для записи я согласен с Джоном и ltjax, но это субъективная вещь ...) ___ commmment6544210 ___ Я так не думаю. Конечно, есть проблемы с реализацией вокруг синглетонов, большинство из них связаны с C ++, а не концептуальными. Да, они могут злоупотреблять плохими разработчиками, но они плохие разработчики, и все. Синглтоны чувствуют себя лучше для меня, чем static-methods-and-private-constructor. ___ commmment6544120 ___ @ Giovanni Теперь банку червей, если она полностью открыта;) Многие считают, что синглтоны широко используются. Некоторые считают, что это анти-шаблон. В этом случае можно утверждать, что это будет хуже, чем класс контейнеров статических методов, поскольку теперь у вас есть семантика, обеспечивающая существование только одного экземпляра объекта, который вообще не должен существовать. ___ commmment6544239 ___ @ Джон. Полагаю, я должен был сказать, что второй вариант - это то, что вы, вероятно, должны сделать в качестве части моего ответа. В общем, я против сильных заявлений о «Единственном правильном пути», но позвольте мне продолжить и добавить это сейчас. ___ commmment6544381 ___ @ AJG85: На самом деле, если бы ФП собирался заметить дебаты о том, что он должен или не должен делать, он бы уже заметил. И в этот момент, ответ на ваш ответ больше не подходит для каких-либо целей, поэтому я просто отменил его. FWIW, я также против заявлений One True Way. ___ commmment6543162 ___ +1 для того, чтобы поставить это в терминах «имеет ли функция состояние то, что должно принять это решение». ___ commmment6543976 ___ @Mike, yup исправлено. ___ commmment6546127 ___ +1 Благодарю вас за то, что вы выбрали все суеты и бесполезные соображения, которые загрязняют такую ​​дискуссию ни о чем. ___ commmment6544269 ___ @Giovanni: некоторые сказали бы, что дизайн должен быть как можно более простым (но не проще). Учитывая ситуацию, когда вам не нужен класс, вы должны: (a) не иметь класс; (b) иметь пустой класс, но не создавать его; (c) иметь пустой класс, плюс код для предотвращения создания экземпляра; (d) иметь пустой класс, плюс код для создания экземпляра; или (e) ни один из вышеперечисленных? ___ commmment6546150 ___ @ Giacomo да, это все еще нечеткое, потому что вы не хотите ставить каждую операцию, которая может работать с частью данных с сохранением состояния в методе, но эти функции должны, по крайней мере, работать через безопасный объект состояния, красиво инкапсулированный интерфейс, чтобы что-то сделать. Но я думаю, что в целом это хороший совет. ___ commmment6543322 ___ Я был бы признателен за комментарий, объясняющий нижний план. И если это месть за то, что я склоняюсь к другому ответу, это ужасная причина для понижения ... ___ ___ commmment6543546 @ltjax: Я не говорю, что они не правы, просто, что это спорно. Заметьте, что я проголосовал за ответ Билли. ___ commmment6543398 ___ +1: Я согласен, что этот d / v кажется необоснованным. Хотя это не самый полезный ответ (т. Е. Потому, что он не рассматривает, как решить, действительно ли код принадлежит или не принадлежит классу), и он дискуссионный (некоторые утверждают, что статические публики более естественны), это, конечно, не неверен. ___ commmment6543565 ___ @John: Я чувствую, что действительно не могу понять, почему я так думаю, потому что для этого мне действительно нужно было скопировать главу Майерса, и я действительно не думаю, что это справедливо для него. ___ commmment6543600 ___ @ltjax: Хм .. Я действительно согласен с Джоном здесь; умные люди, соглашающиеся со мной, не являются достаточным оправданием для курса действий. Но в книге объясняется, что мне кажется, что нужно идти сюда. ___ commmment6543626 ___ +1 для ссылки на отличную книгу ... думать о том, что вы должны делать, иногда более важно, чем то, что вы могли бы сделать. ___ commmment6543253 ___ @Billy ONeal, вы пропустили слово «статический»? ___ commmment6543999 ___ @ Билли, конечно же, это не столько об этом, сколько о том, как они спорят по этому поводу, и делают это очень убедительно! (И это на самом деле работает очень хорошо - по моему опыту). Может быть, цитата или что-то было бы хорошо? ___ commmment6543478 ___ @ Джон, я думаю, что три из самых влиятельных личностей в мире C ++ (Meyers, Sutter, Alexandrescu) публично объявляют, что вы должны предпочесть не-членские функции, отличные от друзей, почти всегда составляют довольно хороший аргумент. ___ commmment6543273 ___ Я говорю о статических функциях, а не о статических методах. Также C ++ не является надмножеством C. См. Это: stackoverflow.com/questions/1201593/... ___ commmment6543300 ___ -1: Re: «Они похожи на обычные функции, которые могут вызвать защищенные / частные методы в одном классе». статические методы сильно отличаются от обычных методов. а именно, вы не можете вызвать нестатический метод из статического метода, потому что этого указателя нет. ___ commmment6543302 ___ @ergosys: Нет, я этого не делал. Но я пропустил различие между «функцией» и «методом». В стандарте C ++ не используется обозначение «метод» - он использует обозначение «функция-член» или «функция без члена». Я бы удалил свой downvote, если @Giovanni отредактировал бы его ответ (потому что сейчас я не могу его изменить), и я изменю его на upvote, если он изменит его, чтобы использовать язык стандарта. ___ answer5722008 ___ <div class="post-text" itemprop="text"> <p> Честно говоря, это философское и нечеткое руководство, но я предпочитаю сначала использовать простейшие вещи, а затем создавать сложную сложность, когда это необходимо. </p> <p> Мое первое предпочтение </p> <ol> <li> <p> Свободные, безгосударственные, побочные эффекты, которые выполняют некоторые операции / вычисления / преобразования на своих аргументах и ​​возвращают результат (ы). </p> </li> <li> <p> Однако, если какой-либо из этих аргументов эволюционирует, чтобы стать работоспособными, и ваша функция станет ответственной за сохранение этого состояния, рассмотрите возможность переноса данных состояния и методов, которые управляют этими данными в класс для хорошего скрытия инкапсуляции / данных. </р> </LI> </ol> <p> Файловый ввод-вывод является примером того, что имеет состояние. Вы открываете файл, записываете в него некоторые данные, которые перемещаются вперед по указателю записи и в конечном итоге закрывают его, что является хорошим примером того, где вы хотите класс. </P> <p> Наиболее очевидным примером того, где свободные функции являются лучшими, являются математика. Другие примеры могут выполнять регулярное выражение, преобразовывая один вид сообщения в другой тип и т. Д. </P> <p> (1) Простейший, поскольку в его чистом виде нет постоянного состояния, все является трансформационным, и вы должны последовательно получать одинаковый вывод с одним и тем же входом. Легко проверить, легко понять, как это работает. В идеале нам не нужно было бы сохранять какое-либо состояние, и мы все могли бы программировать таким образом. </P> <p> (2) Необходимо, потому что безопасное обновление состояния является необходимой частью жизни, и если вы не можете скрывать данные или инкапсуляцию данных, вы теряете уверенность в правильном и безопасном состоянии состояния. </p>     </DIV> ___ –  John Dibling 19.04.2011 в 22:27
  • @John: Я чувствую, что действительно не могу понять, почему я так думаю, потому что для этого мне действительно нужно было скопировать главу Майерса, и я действительно не думаю, что это справедливо для него. –  Billy ONeal 19.04.2011 в 22:28
Показать остальные комментарии
0

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

Статические методы в классах - это нечто совершенно другое (хотя в обоих случаях используется ключевое слово same ). Они похожи на обычные функции, которые могут вызвать защищенные / частные методы в одном классе. Вы можете думать о статических методах как о простых (нестатических) функциях, которые являются «друзьями» с классом.

Что касается общего руководства, я не думаю, что имеет значение, если у вас есть (нестатические) функции или статические методы в качестве интерфейса вашей библиотеки, это в основном вопрос синтаксиса: вызов f() или вызов% код%. Вы также можете использовать obj::f() для инкапсуляции. В этом случае синтаксис: namespaces для функции и ns::f() для статического метода.

РЕДАКТИРОВАТЬ: Хорошо, но, хотя в ключевом слове static возникла путаница, получается, что это скорее спорный ответ, чем я бы хотел. Я лично предпочитаю термин метод для функций-членов (который также является тем же самым лексиконом, который используется в фактическом вопросе). И когда я сказал, что статические методы могут вызывать частные методы , я имел в виду видимость (контроль доступа a.k.a.).

    
ответ дан Giovanni Funchal 19.04.2011 в 22:02
источник
  • @Billy ONeal, вы пропустили слово «статический»? –  ergosys 19.04.2011 в 22:11
  • Я говорю о статических функциях, а не о статических методах. Также C ++ не является надмножеством C. См. Это: stackoverflow.com/questions/1201593/... –  Giovanni Funchal 19.04.2011 в 22:12
  • -1: Re: «Они похожи на обычные функции, которые могут вызвать защищенные / частные методы в одном классе». статические методы сильно отличаются от обычных методов. а именно, вы не можете вызвать нестатический метод из статического метода, потому что этого указателя нет. –  John Dibling 19.04.2011 в 22:14
  • @ergosys: Нет, я этого не делал. Но я пропустил различие между «функцией» и «методом». В стандарте C ++ не используется обозначение «метод» - он использует обозначение «функция-член» или «функция без члена». Я бы удалил свой downvote, если @Giovanni отредактировал бы его ответ (потому что сейчас я не могу его изменить), и я изменю его на upvote, если он изменит его, чтобы использовать язык стандарта. –  Billy ONeal 19.04.2011 в 22:14