Printable View
I think (I can't seem to find a good reference online) that functions that are friends cannot be member functions of another class. Therefore, if the compiler sees a friend function enclosed in a class definition, it can assume that the function is indeed free, so there is no error.
Classes can be friends of other classes, which would allow the member functions of one class access to data members of the other.
Viggy
http://www.cplusplus.com/doc/tutorial/inheritance/Quote:
Originally Posted by MrViggy
Yep, this is be definition.
Viggy
Aah, I think I see. Well, at least in part. So, a friend function is a free function no matter what. The language design choice to make it possible to declare it as such and to define it at the same time feels a bit... strange to me. Doesn't this introduce some confusion (assuming that you don't know everything there is to know about friend functions)? Unless there's some scenario where this would be significantly beneficial?
So, basically, the enclosing class-level scope is non-existent to such a function? BTW, do any access modifiers have any effect? If it's not a member - they shouldn't. Which makes it all the more misleading when you list the function under one... I don't know. The whole practice feels wrong to me.
Oh yes, it definitely does, at least for me. If it didn't, I probably wouldn't have posted in this thread at all.Quote:
Originally Posted by TheGreatCthulhu
I tried to construct such a scenario (involving multiple classes derived from a common base class to provoke multiple definition errors) but to no avail: I always found a way to define the friend function outside of the class body.Quote:
Unless there's some scenario where this would be significantly beneficial?
Now is it safe to say singleton creator function could be either friend function or static function of a singleton class? So we have two choices.
I have not checked the standard, but g++ 4.4.5 and the Comeau online compiler happily compile:Quote:
Originally Posted by MrViggy
Besides, while it does not make sense for a member function to be a friend of its own class, it does make sense for it to be a friend of another class, without its class being a friend (i.e., reduced penalty in loss of encapsulation).Code:class B;
class A
{
public:
void foo(const B& b) const;
};
class B
{
public:
explicit B(int x) : x_(x) {}
friend void A::foo(const B& b) const;
private:
int x_;
};
#include <iostream>
void A::foo(const B& b) const
{
std::cout << b.x_ << std::endl;
}
int main()
{
A a;
B b(123);
a.foo(b);
}
Yes.Quote:
Originally Posted by LarryChen
name injection, like the Barton–Nackman trick as a notable example ( this is used in many boost libraries, like boost operators, boost iterators and others ... ). Note that in these scenarios this language feature is not only beneficial but also necessary.Quote:
Originally Posted by TheGreatCthulhu
EDIT: @TheGreatCthulhu, ... ignore my post above given that I misinterpreted yours :) ...
The Singleton design pattern stipulates that there's global access to one unique object, the rest is implementation detail. What you're attempting is called a Meyer's Singleton but that's just one way to do it.Quote:
Originally Posted by LarryChen
Both approaches will work. In general, however, it's better to use a static method because that's what the design pattern specifies, and so that's what anyone reading your code would expect to see. If you tell someone to get the MyClass singleton but don't show them any code, they're far more likely to figure out "MyClass::getInstance()" than "getMyClassInstance()" as the way to do it.Quote:
Originally Posted by LarryChen
That's wrong.Quote:
Originally Posted by Lindley
Design patterns are language independent and no implementations are stipulated.
What OO design point of view are you referring to?Quote:
Originally Posted by TheGreatCthulhu
Now that does make sense to me.Quote:
Originally Posted by laserlight
Yes - my point was: in what cases would declaring and defining a friend function at the same time within a scope of the class be significantly beneficial or desirable (in a way that would make sacrificing clarity worth it)? What's was the compelling reason for the language to allow it in the first place? Nevertheless, I did found your link informative.Quote:
Originally Posted by superbonzo
Yes - they are implementation independent - but note that they define a certain logical structure. The standard Singleton pattern provides a static function, and this is what people would expect. Logically, a static function is not the same as a free function. However, you are not entirely wrong either: when it comes to the implementation - not all the languages provide the same features; furthermore, with design patterns, nothing's really set in stone - and that's one of the benefits.Quote:
Originally Posted by nuzzle
But, one advantage of using patterns is that they define a sort of a language, a standard way to talk about common design solutions - a common grounds of sorts, so that those who are familiar with them can easily exchange ideas and information. For this reason, it's (IMO) best to leverage this advantage by implementing a pattern behind an interface most people would expect, especially if your language supports it.
Well, how would you model that (a function defined within a class, which is not a member of that class)?Quote:
Originally Posted by nuzzle
It's a C++ -specific thing (but not in the sense that there aren't any other languages that have that (there could be), but in the sense that it falls outside the scope of your standard OO paradigm, or at least it's something else in disguise).
The word "specifies" in my post may have been poorly chosen, but the general point I was making stands.
ah ... well, then my orignal interpretation of your post was correct; I mean, to my knowledge there's no way of defining those friend non member functions outside of the class template body when they depend on the template parameters. So, this is a scenario where this language feature is indeed necessary.Quote:
Originally Posted by TheGreatCthulhu