Printable View
Hello I have a namespace and two classes. Bar inherits Foo. How can I hide Foo from external usage? One way would be to do it like the following:
I don't want to be able to access Foobar::Foo, But I don't think that's the ultimate way.Code:namespace Foobar {
class Bar {
private:
class Foo: private Enemy {
private:
Suit value;
} foos[3];
};
}
Any suggestions?
If you want Bar to inherit from Foo, you cannot have Foo as a nested class in Bar, methinks. A more feasible way would be to declare a namespace mamed detail in the Foobar namespace, then use the convention that this detail namespace contains implementation detail... USE AT YOUR OWN RISK.Quote:
Originally Posted by Tux0r
By the way, why do you want to do this?
Thanks for your answer.
Ok the way I'm seeing it now is that I want an array of 3 Foo in Bar and to do that the right way I would have to hide Foo from rest of the program, no one else needs it!
If I nest another namespace it is still visible to the rest of the program only at another scope.
Oh, so you just want a member array of 3 Foo objects? In that case what you have done is correct.Quote:
Originally Posted by Tux0r
Of course, hence this is a convention: a user of your library knows that whatever is in the detail namespace is implementation detail. If he/she uses the constructs found in that namespace, he/she must be prepared for his/her program to break when your library is updated, even when the update is supposed to maintain backward compatibility.Quote:
Originally Posted by Tux0r
Yeah but my key point here is: is there a way to have the class Foo in the namespace without it being accessible outside of it? Because I have another base class, Enemy, and I don't see any reason to have it accessible.Quote:
Originally Posted by laserlight
It would be nice if I could use an anonymous namespace to wrap it up with but it does not have the effect I desire.
Not that I know of: the detail namespace convention that I described is the way that I know to address this shortcoming. Besides, namespaces are not closed: even if such a construct existed, your users could theoretically just open your namespace and write whatever they want to easily defeat this access control without modifying any code that you wrote - you would effectively end up with another convention, albeit one that was better supported by language constructs.Quote:
Originally Posted by Tux0r
Not in a header file, at least.Quote:
Originally Posted by Tux0r
Well when you're talking about access do you mean you want to not have objects of specific classes or that they shouldn't be derived from? Because there are different ways.
If class A should not be an object because it's nonsensical, then A should be an abstract data type. A will only exist through its children.
If you want to prevent inheritance the path with least resistance is with a non-virtual destructor. Non-virtual destructors do not properly clean up after a derived object has been sliced, so competent programmers do not extend such classes.
Come to think of it, I do know a way to accomplish roughly what you want, but it requires you to switch from private inheritance to composition. You could use the pointer to an implementation (pimpl) idiom. Since you only have a forward declaration of Enemy in the header file, your users cannot do much with the Enemy class anyway, but you can do all you want in the corresponding source file.
Ok. This is what I think I'll settle down with.
Code:enum class Suit: unsigned char{SPADE,HEART,DIAMOND,CLUB};
class Cards {
private:
class Card: private Enemy {
private:
Suit value;
public:
Suit suit() const;
} cards[3];
public:
void update();
};
Suit Cards::Card::suit() const {
return value;
}
void Cards::update() {
if(cards[0].suit()==cards[1].suit() && cards[1].suit()==cards[2].suit())
delete this;
}
Eh, do not use delete this. I believe that it is only defined if the object was created by new, and even then the user has no way of knowing that the object has been destroyed.
Three-of-a-Kind - Zeldapedia, The Legend of Zelda wiki - Twilight Princess, Ocarina of Time, Spirit Tracks, and more
That's the enemy in the game I'm writing, they come in 3 and to defeat them they should be set to the same value.
When the values of them are the same then the destructor is called. The destructor will call an event. Like, creating a chest with treasure because the enemies were defeated. I believe it makes perfect sense, and because I'm using polymorphism I have to new (afaik).
Code:enum class Suit: char{NONE,SPADE,HEART,DIAMOND,CLUB};
class Cards: private Enemy {
private:
class Card: private Enemy {
private:
Suit value;
public:
Suit suit() const;
void set_suit(Suit&&);
void update();
} cards[3];
public:
void update();
};
Suit Cards::Card::suit() const {
return value;
}
void Cards::Card::set_suit(Suit&& val) {
value=val;
}
void Cards::update() {
for(int i{}; i<3; ++i)
cards[i].update();
//Check for equality
if(cards[0].suit()!=Suit::NONE && cards[1].suit()!=Suit::NONE && cards[2].suit()!=Suit::NONE) {
if(cards[0].suit()==cards[1].suit() && cards[1].suit()==cards[2].suit()) {
delete this;
}
else {
for(int i{}; i<3; ++i)
cards[i].set_suit(Suit::NONE);
}
}
}
I find it weird though that when you essentially win no attempt is made to communicate the fact to the outside and your object just dies.
You should let the scope that created your object be where the object is destroyed wherever possible. Even dynamic storage tends to be managed this way. It mirrors automatic storage, which is easy to understand, and typically is well defined.
Ok well there's the other option of adding a bool member variable to Cards, maybe destroyed.
Then my delete loop on std::vector<Enemy*> will take care of the rest when it's time.
C++ does not have the notion of public and private classes as other languages do. If the class is in a namespace and the namespace is visible to the object then the object can use any class in the namespace - generally speaking. You cannot 'hide' classes in namespaces. The only way I know to 'hide' classes is either hide them in the impl of an interface, use pimpl (public functions operate on a private instance of the impl), or do what you have done and make the class private to another. Anytime I see a class nested in another class to me it implies the outside class has ownership of the nested class.
Another very ugly way to do this is to make a class completely private and then use friend to expose the class to any class needing to use it. Some completely dislike friend as it breaks encapsulation but in this case it is more enforcing encapsulation than breaking it. You are forcing a user of the class to access the nested class members and data via the owning class. One huge problem with friend, even when used appropriately, is that it is not inherited. So any classes derived from a base that has friends does not inherit those friends. This will break a facade pattern rather quickly and does not work well with interfaces.
The most common reason I see for people not liking friend is that they believe encapsulation means "everything in a class is accessed via a member function". A more correct definition of encapsulation is that nothing can access private details (data or implementation) of an entity the designer specifically allows such access. A friend declaration is fully compliant with such a definition of encapsulation: it allows a programmer to explicitly grant access to private members of a class.Quote:
Originally Posted by Bubba
Allowing inheritence of friendship would completely violate encapsulation (a class could receive access to private data of aniother class without knowledge of the designer of that other class).Quote:
Originally Posted by Bubba
It will break broken usages of the facade pattern. There is nothing in the facade pattern that requires the facade to be a friend. Specifically, the facade pattern is not intended as a means of circumventing access control.Quote:
Originally Posted by Bubba
Interfaces specify the semantics for usage of a class. They do not specify how compliance with the interface is implemented. Friendship simply allows a class definition to explicitly specify that other entities (eg other classes or other functions) are part of that interface.
Or, to put it another way, if inability to inherit friendship breaks the implementation of a derived class then either the design of the base class is broken (i.e. it does not provide access to capabilities required by derived classes) or the derived class implementation is trying to do something invalid (access private members of a base class without permission).
I suspect you're referring to the fact that poor design of a base can make life inconvenient for implementers of derived classes. That does not mean the derived class implementer should have access to private members of a base class that are not granted by that base class. It means the base class should be modified so it allows the derived class to perform operations it needs.
You do not have to use new to use polymorphism.Quote:
Originally Posted by Tux0r
All you need is a pointer or reference to the base class. Thus this will work:
Furthermore, using delete this is something I would not recommend.Code:Derived a;
Base* pa = &a;
pa->myfunction();
// Or
Base& ra = a;
ra.myfunction();
If you don't want to do manual deleting, then use smart pointers.
Well that's a crap way to demonstrate polymorphism, since that's not polymorphic at all.
Imagine two classes to represent the time, TwelveHourClock and TwentyFourHourClock, related through the abstract data type Time, which at minimum specifies for its children a timestamp method. One way to dump the time for all the Time types is through a polymorphic function.
Code:void print (std::ostream& os, const Time& now) {
os << "The time is " << now.timestamp() << '\n';
}
It was a way to demonstrate that you don't have to use new to use polymorphism.Quote:
Originally Posted by whiteflags
But you didn't use polymorphism, so sorry if it's really my fault that you demonstrated so little.
Alright, perhaps it was a bad example. I realize that now... I used a single class.
Well, I edited it to use Derived and Base to demonstrate that we're talking about polymorphism.
I was not indicating this was the case.Quote:
It will break broken usages of the facade pattern. There is nothing in the facade pattern that requires the facade to be a friend. Specifically, the facade pattern is not intended as a means of circumventing access control.