A question regarding singleton

[MrViggy]

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

[MrViggy]

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/

Yep, this is be definition.

Viggy

[TheGreatCthulhu]

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.

[Eri523]

Doesn't this introduce some confusion (assuming that you don't know everything there is to know about friend functions)?

Oh yes, it definitely does, at least for me. If it didn't, I probably wouldn't have posted in this thread at all.

Unless there's some scenario where this would be significantly beneficial?

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.

[LarryChen]

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.

[laserlight]

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.

I have not checked the standard, but g++ 4.4.5 and the Comeau online compiler happily compile:

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);
}

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).

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.

Yes.

[superbonzo]

Unless there's some scenario where this would be significantly beneficial?

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.

EDIT: @TheGreatCthulhu, ... ignore my post above given that I misinterpreted yours ...

[nuzzle]

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.

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.

[Lindley]

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.

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.

[nuzzle]

however, it's better to use a static method because that's what the design pattern specifies,

That's wrong.

Design patterns are language independent and no implementations are stipulated.

[nuzzle]

but, from an OO design point of view: how can a function the enclosing context of which is a class not be a member function of that class?

What OO design point of view are you referring to?

[TheGreatCthulhu]

//...
friend void A::foo(const B& b) const;
//...

Now that does make sense to me.

EDIT: @TheGreatCthulhu, ... ignore my post above given that I misinterpreted yours ...

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.

That's wrong.

Design patterns are language independent and no implementations are stipulated.

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.
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.

What OO design point of view are you referring to?

Well, how would you model that (a function defined within a class, which is not a member of that class)?
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).

[Lindley]

The word "specifies" in my post may have been poorly chosen, but the general point I was making stands.

[superbonzo]

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.

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.