Content located on any Geeknet-hosted subdomain which is subject to the sole editorial control of the owner or licensee of such subdomain, shall be subject to the appropriate license applicable to such Content, or to such other licensing arrangements as may be approved by Geeknet as applicable to such Content. For the purposes of these Terms, "Code" means any software code you submit, post, display or distribute via: any of our software configuration management ("SCM") repositories (including, CVS, Subversion, Git, Bazaar and Mercurial) or SourceForge.net's file release system, and "Associated Content" means any text, data, music, sound, photograph, graphic, video, message or material, whether publicly posted or privately transmitted via SourceForge.net, but does not include Code. "SourceForge Content" means any Code or Associated Content.
When you submit, post, upload or otherwise provide Code to SourceForge.net, you must designate promptly the software license pursuant to which licensees (including Geeknet) obtain rights with respect to such Code. Except as otherwise expressly permitted by these Terms, any Code submitted to SourceForge.net must be licensed to Geeknet and other licensees under a license that is: compliant with the Open Source Initiative ("OSI")'s Open Source Definition (http://www.opensource.org/docs/osd) or certified as an "OSI-Approved License" (http://opensource.org/licenses).
@darkesfright well :D I got the basics :D but i will pm you if i'll have any questions :D tyvm
@ne555 Woa :D that's a lot that I can learn :D thanx ... i'm reading the article right now :D and it's pretty convincing , and :D about hours, minutes, seconds as i said :D i started this project to learn more and more things :D i'll look into that issue :D thanks for feedback :D i really appreciate it :)
@ OP: Thought I would help out where I could, the Win API command is "InitiateSystemShutdown()" declared in 'winreg.h' (be sure to include windows.h as well) and linked to with 'advapi32.lib': http://msdn.microsoft.com/en-us/library/windows/desktop/aa376873(v=vs.85).aspx I noticed you passed the "force" option in the windows shutdown block, this function will allow you to do that as well as set the timer.
You're on your own for *nix and Mac, sorry I can't help you there.
One basic principle of OO systems is data abstraction. You should completely hide the way in which an object implements a message handler from the rest of the program. That's one reason why all of your instance variables (a class's nonconstant fields) should be private.
If you make an instance variable public, then you can't change the field as the class evolves over time because you would break the external code that uses the field. You don't want to search 1,000 uses of a class simply because you change that class.
This implementation hiding principle leads to a good acid test of an OO system's quality: Can you make massive changes to a class definition—even throw out the whole thing and replace it with a completely different implementation—without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other OO features.
Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details. What if you need to change the accessed field's type? You also have to change the accessor's return type. You use this return value in numerous places, so you must also change all of that code. I want to limit the effects of a change to a single class definition. I don't want them to ripple out into the entire program.
Isn't using private members with getters and setters in place of public members, done to make it easier to change implementation details.
I guess I'm just confused.
And the question about getters and setters being evil was asked at stackoverflow, and someone with this answer got 75 upvotes.
Very evil: public fields.
Somewhat evil: Getters and setters where they're not required.
Good: Getters and setters only where they're really required - make the type expose "larger" behaviour which happens to use its state, rather than just treating the type as a repository of state to be manipulated by other types.
It really depends on the situation though - sometimes you really do just want a dumb data object.
I wanted your opinion.
I have seen post of rpgs where the hero class has over 12 fields. Of course, they say that making your members public is bad, so for every attribute there is a setter and a getter...
... over 72 lines of useless code.
The thing is, ¿why do you need to access them?
The logic is in the wrong place, check out "Tell Don't Ask".
Well ... As far as I understood from that article , which is kinda' great, I shouldn't use the object::get() or object::set() to do some actions but instead create the object::action() function which will do whatever i want it to do and access the variables inside object . So did I got it right ?
create the object::action() function which will do whatever i want it to do and access the variables inside object . So did I got it right ?
Yeah, for example, if you have a character that you want to reposition, you would use a function called "move" rather than "setposition" or whatever.
As for remote shutdown, that shouldn't be too hard. You'll want a networking library (such as SFML's network module), and then the program can just wait until the user sends a shutdown command across the network.