где бы вы использовали функцию друга вместо статической функции-члена?

<p>мы делаем функцию, не являющуюся членом, другом класса, когда хотим, чтобы он имел доступ к закрытым членам этого класса. это дает ему те же права доступа, что и статическая функция-член. обе альтернативы дадут вам функцию, которая не связана ни с одним экземпляром этого класса.</p><p>когда мы должны использовать функцию друга? когда мы должны использовать статическую функцию? если оба варианта являются жизнеспособными для решения проблемы, как мы можем взвесить их пригодность? есть ли тот, который должен быть предпочтительным по умолчанию?</p><p>например, при реализации фабрики, которая создает экземпляры класса <code>foo</code>, который имеет только закрытый конструктор, должна ли эта фабричная функция быть статическим членом <code>foo</code> (вы бы вызвали <code>foo::create()</code>) или это была функция друга (вы бы назвали <code>create\_foo()</code>)?</p>

<p>в разделе 11.5 "язык программирования c++" бьярна страуструпа говорится, что обычные функции-члены получают 3 вещи:</p><ol> <li>доступ к внутренностям класса</li> <li>находятся в рамках класса</li> <li>должен быть вызван на экземпляр</li> </ol><p><code>friend</code>s получить только 1.</p><p><code>static</code> функции получают 1 и 2.</p>

<p>похоже, этот вопрос касается ситуации, когда программисту необходимо ввести функцию, которая <strong>не</strong> работает с любым <em> экземпляром </em> класса (отсюда возможность выбора функции-члена <code>static</code>name\_\_). поэтому я ограничу этот ответ следующей ситуацией проектирования, где выбор между статической функцией <code>f()</code> и свободной от друга функцией <code>f()</code>:</p><pre><code>struct a { static void f(); // better this... private: friend void f(); // ...or this? static int x; }; int a::x = 0; void a::f() // defines static function { cout << x; } void f() // defines friend free function { cout << a::x; } int main() { a::f(); // invokes static function f(); // invokes friend free function } </code></pre><p>не зная ничего заранее о <em> семантике </em> <code>f()</code> и <code>a</code>(я вернусь к этому позже), у этого ограниченного сценария есть простой ответ: - <strong>функция <code>static</code>предпочтительна</strong>. я вижу две причины для этого.</p><hr><p><strong>общие алгоритмы :</strong></p><p>основная причина в том, что такой шаблон может быть написан следующим образом:</p><pre><code>template<typename t> void g() { t::f(); } </code></pre><p>если бы у нас было два или более классов, которые имеют функцию <code>static</code>на своем интерфейсе <code>f()</code>, это позволило бы нам написать одну единственную функцию, которая в общем случае вызывает <code>f()</code> для любого такого класса.</p><p>невозможно написать эквивалентную обобщенную функцию, если мы сделаем <code>f()</code> бесплатной функцией, не являющейся членом. хотя это правда, что мы могли бы поместить <code>f()</code> в пространство имен, чтобы синтаксис <code>n::f()</code> мог использоваться для имитации синтаксиса <code>a::f()</code>, все равно было бы невозможно написать функцию шаблона, такую как <code>g<>()</code> выше, поскольку имена пространства имен не являются допустимыми аргументами шаблона ,.</p><p><strong>избыточные декларации:</strong></p><p>вторая причина заключается в том, что <em> если бы </em> мы поместили свободную функцию <code>f()</code> в пространство имен, нам бы не разрешили встроить ее определение непосредственно в определение класса. без введения какого-либо другого объявления для <code>f()</code>:</p><pre><code>struct a { static void f() { cout << x; } // ok private: friend void n::f() { cout << x; } // error static int x; }; </code></pre><p>чтобы исправить вышесказанное, мы должны предшествовать определению класса <code>a</code>следующим объявлением:</p><pre><code>namespace n { void f(); // declaration of f() inside namespace n } struct a { ... private: friend void n::f() { cout << x; } // ok ... }; </code></pre><p>это, однако, противоречит нашему намерению объявить и определить <code>f()</code> в одном месте.</p><p>более того, если бы мы хотели объявлять и определять <code>f()</code> отдельно, сохраняя <code>f()</code> в пространстве имен, нам все равно пришлось бы вводить объявление для <code>f()</code> до того, как определение класса для <code>a</code>name\_\_: если это не будет сделано, компилятор будет жаловаться на тот факт, что <code>f()</code> должен был быть объявлен внутри пространства имен <code>n</code>name\_\_, прежде чем имя <code>n::f</code> могло использоваться легально.</p><p>таким образом, теперь у нас есть <code>f()</code>, упомянутая в <em> трех </em> отдельных местах, а не только в двух (объявление и определение):</p><ul> <li>объявление внутри пространства имен <code>n</code>перед определением <code>a</code>name \_\_;</li> <li>объявление <code>friend</code>внутри определения <code>a</code>name \_\_;</li> <li>определение <code>f()</code> внутри пространства имен <code>n</code>name\_\_.</li> </ul><p>причина, по которой объявление и определение <code>f()</code> внутри <code>n</code>не могут быть объединены (в общем случае), заключается в том, что <code>f()</code> должен иметь доступ к внутренним элементам <code>a</code>и, следовательно, определение <code>a</code>name \_\_ должно быть видно при определении <code>f()</code>. тем не менее, как было сказано ранее, объявление <code>f()</code> внутри <code>n</code>должно быть видно до того, как будет сделано соответствующее объявление <code>friend</code>внутри <code>a</code>name\_\_. это фактически вынуждает нас разделить объявление и определение <code>f()</code>.</p><hr><p><strong>семантические соображения:</strong></p><p>в то время как вышеупомянутые два пункта универсально действительны, есть причины, по которым можно предпочесть объявить <code>f()</code> как <code>static</code>вместо того, чтобы сделать его <code>friend</code>из <code>a</code>или наоборот, что обусловлено универсумом дискурса.</p><p>для пояснения важно подчеркнуть тот факт, что функция-член класса, будь то <code>static</code>или не -<code>static</code>name\_\_, является логически <em> частью </em>, которая учебный класс. это способствует его определению и, таким образом, дает концептуальную характеристику этого.</p><p>с другой стороны, функция <code>friend</code>name\_\_, несмотря на то, что ей предоставлен доступ к внутренним членам класса, которому она является другом, по-прежнему является алгоритмом, который логически <em> является внешним </em> к определению класса.</p><p><em> функция может быть <code>friend</code>из более чем одного класса, но может быть членом только одного </em>.</p><p>таким образом, в конкретной области приложения разработчик может пожелать учитывать <strong>семантику</strong> как функции, так и класса при принятии решения о том, следует ли сделать первое <code>friend</code>или членом последнего (это применимо не только для функций <code>static</code>name\_\_, но и для не -<code>static</code>функций, где могут вмешиваться другие языковые ограничения).</p><p>функция логически способствует характеристике класса и/или его поведения, или это скорее внешний алгоритм? на этот вопрос нельзя ответить без знания конкретной области приложения.</p><hr><p><strong>вкус:</strong></p><p>я считаю, что любой другой аргумент, который только что был приведен, проистекает исключительно из <strong>дело вкуса</strong>: как свободный <code>friend</code>name\_\_, так и подход <code>static</code>name\_\_, на самом деле, позволяют четко указать, к какому интерфейсу класса относится одно-единственное пятно (определение класса), поэтому по дизайну они эквивалентны (по модулю приведенных выше наблюдений, конечно).</p><p>остальные различия являются стилистическими: хотим ли мы написать ключевое слово <code>static</code>или ключевое слово <code>friend</code>при объявлении функции, и хотим ли мы написать квалификатор области класса <code>a::</code> при определении класса, а не спецификатор области пространства имен <code>n::</code>. таким образом, я не буду комментировать дальше это.</p>

<p>разница четко выражает намерение отношений между классом и функцией.</p><p>вы используете <code>friend</code>, когда хотите намеренно указать сильную связь и особые отношения между двумя <strong>не связанными</strong> классами или между классом и функцией.</p><p>вы используете функцию-член <code>static</code>, когда функция <strong>логически часть класса</strong>, членом которой она является.</p>

<p>статические функции используются, когда вы хотите, чтобы функция была одинаковой для каждого экземпляра класса. такие функции не имеют доступа к указателю "this" и, следовательно, не могут получить доступ к любым нестатическим полям. они часто используются, когда вам нужна функция, которую можно использовать без создания экземпляра класса.</p><p>функции друзей - это функции, которых нет в классе, и вы хотите предоставить им доступ к закрытым членам вашего класса.</p><p>и это (статика против друга) не является вопросом использования одного против другого, так как они не являются противоположностями.</p>

<p>функции друзей (и классы) могут получить доступ к закрытым и защищенным членам вашего класса. там редко хороший случай для использования функции друга или класса. избегайте их в целом.</p><p>статические функции могут получать доступ только к статическим данным (то есть данным в области классов). они могут быть вызваны без создания экземпляра вашего класса. статические функции отлично подходят для ситуаций, когда вы хотите, чтобы все экземпляры вашего класса вели себя одинаково. вы можете использовать их:</p><li>как функции обратного вызова</li><li>манипулировать членами класса</li><li>чтобы получить постоянные данные, которые вы не хотите перечислять в заголовочном файле</li>

<p>стандарт требует, чтобы операторы = () [] и -> были членами и специфичны для класса<br> операторы new, new [], delete и delete [] должны быть статическими членами. если ситуация<br> возникает, когда нам не нужен объект класса для вызова функции, а затем сделать<br> функция статическая. для всех других функций:<br> если функция требует операторов = () [] и -> для потокового ввода-вывода,<br> или если ему нужно преобразование типов в крайнем левом аргументе, или если это можно реализовать с использованием только открытого интерфейса класса, сделайте его некомбинированным (и другом, если необходимо в первых двух случаях)<br> если нужно вести себя виртуально,<br> добавить функцию виртуального члена для обеспечения виртуального поведения<br> и реализовать с точки зрения этого<br> еще<br> сделать его участником.</p>

<ul> <li> <p>одна из причин предпочитать друга статическому члену - это когда функцию нужно написать на ассемблере (или другом языке).</p> <p>например, у нас всегда может быть внешняя функция друга "c", объявленная в нашем файле .cpp</p> <pre><code>class thread; extern "c" int contextswitch(thread & a, thread & b); class thread { public: friend int contextswitch(thread & a, thread & b); static int stcontextswitch(thread & a, thread & b); }; </code></pre> <p>а позже определим в сборке:</p> <pre><code> .global contextswitch contextswitch: // ... retq </code></pre> <p>технически говоря, мы могли бы использовать статическую функцию-член для этого, но определить ее в assembly будет непросто из-за искажения имени ( <a href="http://en.wikipedia.org/wiki/name\_mangling">http://en.wikipedia.org/wiki/name\_mangling</a> )</p> </li> <li> <p>другая ситуация, когда вам нужно перегрузить операторов. перегрузка операторов может осуществляться только через друзей или нестатичных участников. если первый аргумент оператора не является экземпляром того же класса, то нестатический член также не будет работать; друг будет единственным вариантом:</p> <pre><code>class matrix { friend matrix operator * (double scalefactor, matrix & m); // we can't use static member or non-static member to do this }; </code></pre></li> </ul>

<p>статическая функция может получить доступ только к членам класса <em>one</em>. функция friend имеет доступ к нескольким классам, как описано в следующем коде:</p><pre><code>class b; class a { int a; friend void f(a &a, b &b); }; class b { int b; friend void f(a &a, b &b); }; void f(a &a, b &b) { std::cout << a.a << b.b; } </code></pre><p>функция f () может обращаться к данным как класса a, так и класса b.</p>

<p>функция друга не может быть унаследована, в то время как статическая функция может быть. поэтому, когда цель может быть достигнута как с помощью статической функции, так и с помощью функции друга, подумайте, хотите ли вы наследовать ее или нет.</p>

<p>вы бы использовали статическую функцию, если функция не нуждается в чтении или изменении состояния определенного экземпляра класса (то есть вам не нужно изменять объект в памяти), или если вам нужно использовать указатель на функцию для функция-член класса. во втором случае, если вам нужно изменить состояние резидентного объекта, вам нужно будет передать <code>this</code> и использовать локальную копию. в первом случае может возникнуть такая ситуация, когда логика для выполнения определенной задачи не зависит от состояния объекта, но ваша логическая группировка и инкапсуляция будут иметь член определенного класса.</p><p>вы используете функцию или класс друга, когда создали код, который не является членом вашего класса и не должен быть членом вашего класса, но имеет законное назначение для обхода закрытых/защищенных механизмов инкапсуляции. одна из целей этого может заключаться в том, что у вас есть два класса, которым нужны некоторые общие данные, но дважды кодировать логику было бы плохо. на самом деле, я использовал эту функциональность только в 1% классов, которые я когда-либо кодировал. это редко нужно.</p>

<p>функции друзей могут получить доступ к закрытым и защищенным членам других классов. означает, что они могут быть использованы для доступа ко всем данным, будь то частные или общедоступные. таким образом, дружественные функции используются для доступа к тем данным, которые статические методы не могут.</p><p>эти методы становятся статическими, которые вызываются так много раз, что объявляют разные места внутри каждого объекта, потому что они становятся слишком дорогими (с точки зрения памяти). это можно прояснить с помощью примера: пусть имя класса является фактом, а его член данных равен n (что представляет собой целое число, факториал которого имеет значение), тогда в этом случае объявление find\_factorial () как статического было бы мудрым решением !!</p><p>они используются в качестве функций обратного вызова для манипулирования членами в области классов для извлечения постоянных данных, которые вы не хотите перечислять в заголовочном файле.</p><p>теперь мы ясно со следующими вопросами ..</p><p>когда используется функция друга? когда используется статическая функция?</p><p>теперь, если оба варианта являются жизнеспособными вариантами решения проблемы, мы можем оценить их пригодность с точки зрения доступности (доступности личных данных) и эффективности использования памяти. по умолчанию никто не может быть предпочтительным, так как существует много ситуаций, когда нам нужно лучшее управление памятью, а иногда нас интересует объем данных.</p><p>например: foo :: create () будет предпочтительнее, чем create\_foo (), когда мы будем вызывать метод create () после каждого небольшого момента времени, и нас не интересует объем данных (личные данные)</p><p>и если нам интересно получить конфиденциальную информацию более чем одного класса (классов), то create\_foo () будет предпочтительнее, чем foo :: create ().</p><p>я надеюсь, что это поможет вам!</p>

<p>статическая функция - это функция, которая не имеет доступа к <code>this</code>.</p><p>функция friend - это функция, которая может получить доступ к закрытым членам класса.</p>

<p>статическая функция может использоваться по-разному.</p><p>например, как простая фабричная функция:</p><pre><code> class abstract { private: // no explicit construction allowed abstract(); ~abstract(); public: static abstract* construct() { return new abstract; } static void destroy(abstract* a) { delete a; } }; ... a* a\_instance = a::conctruct(); ... a::destroy(a\_instance); </code></pre><p>это очень упрощенный пример, но я надеюсь, что он объяснит, что я имел в виду.</p><p>или как функция потока, работающая с вашим классом:</p><pre><code> class a { public: static void worker(void* p) { a* a = dynamic\_cast<a*>(p); do something wit a; } } a a\_instance; pthread\_start(&thread\_id, &a::worker, &a\_instance); .... </code></pre><p>у друга совершенно другая история, и их использование в точности соответствует описанию</p>