Comments for Pompi Pompi - A Gamers and Developers blog for indie games

Comment on Bug negative verification by Ground Truth « Pompi Pompi – A Gamers and Developers blog for indie games

Fri, 12 Feb 2010 16:37:36 +0000

[...] many other fields where you have some tool you know is working right. It is kind of similar to the Bug negative verification. Share and [...]

Comment on Accessing privates without ‘friend’(c++) by ofer

ofer — Fri, 15 Jan 2010 06:51:54 +0000

Hello Marcin,

I understand what you are saying, but I think sometimes you want classes to be closely dependent of each other.
The best way to decouple classes is data driven, but sometimes it’s not worth or doesn’t make sense to use that.

Comment on Accessing privates without ‘friend’(c++) by Marcin Seredynski

Marcin Seredynski — Thu, 14 Jan 2010 19:30:21 +0000

Hmmm… “Cruising alone” doesn’t look like a good reason to break encapsulation, really. IMHO: if you ever find yourself needing to break encapsulation, this is an indicator of a design that could be improved.

Other than that – interesting approach.

Comment on Happy Malloc Year! by Who moved my monitor(cheese)? « Pompi Pompi – A Gamers and Developers blog for indie games

Tue, 12 Jan 2010 19:15:36 +0000

[...] a lot of loose cable. We some time rationalize things or find excuses to not try things because of a future event we are looking forward to. It is a really important quality to be able to try things out even if you have no prior knowledge [...]

Comment on Accessing privates without ‘friend’(c++) by hermitC

hermitC — Fri, 08 Jan 2010 16:14:39 +0000

@ofer: Good point, didn’t consider that traffic lights are useless when cruising alone

Comment on Accessing privates without ‘friend’(c++) by ofer

ofer — Fri, 08 Jan 2010 15:41:08 +0000

hermitC, I don’t think the traffic light is a good example. Because private are useful for the lone programmer as well.
This pattern can be useful for a lone programer as well, of course it doesn’t mean you have to use it. It depend on a lot of things. For instance, I wouldn’t give the same attention to different parts of code. Some times I prefer the “quick and dirty” solutions, sometimes I prefer the “overkill”.

Comment on Accessing privates without ‘friend’(c++) by hermitC

hermitC — Fri, 08 Jan 2010 13:23:44 +0000

@ofer: You are right, private is just an artificial ’stop sign’ in the code.
An even better way to think of it is as a traffic light: public=green, protected=orange, private=red. It makes the compiler tell you (or other programmers using your code) what is accessible and what not.
When you are driving on a lonely road (small one-man project) there is no need for traffic lights. But chaos will rise when you enter a big city without any traffic controls.
The friend declaration is a kind of backstage pass, handed out only by the concert management. It’s an exception, a privilege for a few. The pattern discussed here is a backstage pass for everyone but reduced to small areas of the backstage. The only hurdle to overcome is the extra code to derive from the Observer class for each wanted member.

Conclusion: The pattern could be useful for libraries I write and hand out to other programmers. For my one-man project it’s just an overkill.

Comment on Accessing privates without ‘friend’(c++) by ofer

ofer — Thu, 07 Jan 2010 17:43:07 +0000

Hi hermitC,
I have been thinking about this for a bit. And I come to think of a good example to explain this.
What is “needed”? Do you need ‘private:’?
You know it is possible to write a complete program without using ‘private’ at all! You can make everything public. private only shout a compilation error when you try to access it outside of the class.
‘private’ is useful, eventhough it doesn’t change the game’s logic.

Comment on Accessing privates without ‘friend’(c++) by hermitC

hermitC — Thu, 07 Jan 2010 13:12:05 +0000

Pro:
- friend declaration makes all members available to friend class, your pattern allows to publish only a part of the member data
- member access declaration via friend is done in class owning the members (changes are intrusive), your pattern allows client class to choose access itself

Contra:
- less readable
- may not work (that way) with some compilers (VS6?, I’m not sure here)

Finally I can’t remember any situation in which I had a need for such a specific member publication. IMHO friend declarations should be made where the affected members are declared. This guarantees that the access policy is declared at one position (central access control). Friend declarations should be used with care, not at all if possible.
I will keep this pattern in mind. Maybe there are some situations where it is useful. ‘If you only have a hammer every problem looks like a nail’.

Comment on Minimizing “thought resources” by ofer

ofer — Fri, 18 Dec 2009 15:43:54 +0000

Sorry for the messy code. I am still looking for a code plugin that doesn’t break the whole website template. :/