• Log InLog In
  • Register
Liquid`
Team Liquid Liquipedia
EDT 07:46
CEST 13:46
KST 20:46
  • Home
  • Forum
  • Calendar
  • Streams
  • Liquipedia
  • Features
  • Store
  • EPT
  • TL+
  • StarCraft 2
  • Brood War
  • Smash
  • Heroes
  • Counter-Strike
  • Overwatch
  • Liquibet
  • Fantasy StarCraft
  • TLPD
  • StarCraft 2
  • Brood War
  • Blogs
Forum Sidebar
Events/Features
News
Featured News
Serral wins Maestros of the Game 238ByuL, and the Limitations of Standard Play3Team Liquid Map Contest #22: Results and Winners7Code S Season 2 (2026): RO4 and Finals Preview12TL.net Map Contest #22 - Voting & Ladder Map Selection7
Community News
BSL Season 22 Full Overview & Conclusion5BSL Season 22 Full Overview & Conclusion5Weekly Cups (June 29-July 5): Solar Doubles0MC vs IdrA, Boxer vs Nal_rA to be Legacy Matches @ BlizzCon445.0.16 Hotfix (June 30) - Balance + Bug Fixes40
StarCraft 2
General
Most successful SC2 players of Q2 2026 Serral wins Maestros of the Game 2 MC vs IdrA, Boxer vs Nal_rA to be Legacy Matches @ BlizzCon Is the larve respawn broken? 5.0.16 patch for SC2 goes live (8 worker start)
Tourneys
GSL CK #5 Race War RSL Revival: Season 6 - Qualifiers and Main Event HomeStory Cup 29 Vespene Cup #1 — $300+ USD, July 10 Sea Duckling Open (Global, Bronze-Diamond)
Strategy
[G] Having the right mentality to improve
Custom Maps
New Map Maker - Looking for Advice - Love or Hate Work In Progress Melee Maps [D]RTS in all its shapes and glory <3
External Content
Mutation # 533 Die Together The PondCast: SC2 News & Results Mutation # 532 Nuclear Family Mutation # 531 Experimental Artillery
Brood War
General
ASL 22 Proposed Map Pool ASL22 General Discussion BW General Discussion BGH Auto Balance -> http://bghmmr.eu/ BSL Season 22 Full Overview & Conclusion
Tourneys
[ASL22] Wildcard Qualifier [Megathread] Daily Proleagues IPSL Spring 2026 Top 4! CSLAN 4 is Coming!
Strategy
Fighting Spirit mining rates Simple Questions, Simple Answers Creating a full chart of Zerg builds Relatively freeroll strategies
Other Games
General Games
Summer Games Done Quick 2026! General RTS Discussion Thread Nintendo Switch Thread Stormgate/Frost Giant Megathread Dawn of War IV
Dota 2
Looking for a Dota Mentor Official 'what is Dota anymore' discussion
League of Legends
Heroes of the Storm
Simple Questions, Simple Answers Heroes of the Storm 2.0
Hearthstone
Deck construction bug
TL Mafia
NeO.D_StephenKing vs This Guy From 1 Million Dance TL Mafia Community Thread TL Mafia Power Rank Vanilla Mini Mafia
Community
General
US Politics Mega-thread Russo-Ukrainian War Thread UK Politics Mega-thread YouTube Thread Canadian Politics Mega-thread
Fan Clubs
The IdrA Fan Club The HerO Fan Club!
Media & Entertainment
Anime Discussion Thread Movie Discussion! Series you have seen recently...
Sports
2024 - 2026 Football Thread McBoner: A hockey love story Tennis[sport] Formula 1 Discussion TeamLiquid Health and Fitness Initiative For 2023
World Cup 2022
Tech Support
FPS when play League Of Legend on laptop How to clean a TTe Thermaltake keyboard? Computer Build, Upgrade & Buying Resource Thread
TL Community
The Automated Ban List
Blogs
Major Shifts in the Gaming I…
TrAiDoS
An Exploration of th…
waywardstrategy
Gauntlet SC2: A Retrospectiv…
Ctone23
ramps on octagon
StaticNine
Funny Nicknames
LUCKY_NOOB
Evil Gacha Games and the…
ffswowsucks
Customize Sidebar...

Website Feedback

Closed Threads



Active: 6696 users

The Big Programming Thread - Page 355

Forum Index > General Forum
Post a Reply
Prev 1 353 354 355 356 357 1032 Next
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks.
tec27
Profile Blog Joined June 2004
United States3702 Posts
Last Edited: 2013-09-17 05:05:08
September 17 2013 05:04 GMT
#7081
On September 17 2013 14:00 sluggaslamoo wrote:
Show nested quote +
On September 17 2013 12:57 Millitron wrote:
On September 17 2013 09:12 sluggaslamoo wrote:
If your language requires you to write getters/setters then it is probably a terrible language, e.g Java/.NET.

If you don't have a choice however (working in a corporate environment), the debate is asking the wrong question. You shouldn't be lumping Getter and Setter in the same question.

Getters are perfectly fine in any situation and very useful for immutable attributes, in fact there's no point in not having them unless you are just feeling lazy. If it is mutable then don't provide a Getter obviously.

Setters on the other hand are a problem, there are almost no instances where you would need a Setter for an object. If you have setters for your objects you are in the wrong frame of mind and need to do a lot more research on the paradigm of OOP.

Neither Java nor .NET force getters and setters. You can have public instance variables in both of them.


I never said force, I said require.

Force and require are the same thing in that context? It would only be different if you had said "if your language's idiomatic style requires..." or something along those lines. C# also has properties, which remove the need to write getters/setters for "future refactoring possibility" purposes and make it so even the idiomatic style does not encourage them.
Can you jam with the console cowboys in cyberspace?
sluggaslamoo
Profile Blog Joined November 2009
Australia4494 Posts
Last Edited: 2013-09-17 05:27:56
September 17 2013 05:27 GMT
#7082
On September 17 2013 14:04 tec27 wrote:
Show nested quote +
On September 17 2013 14:00 sluggaslamoo wrote:
On September 17 2013 12:57 Millitron wrote:
On September 17 2013 09:12 sluggaslamoo wrote:
If your language requires you to write getters/setters then it is probably a terrible language, e.g Java/.NET.

If you don't have a choice however (working in a corporate environment), the debate is asking the wrong question. You shouldn't be lumping Getter and Setter in the same question.

Getters are perfectly fine in any situation and very useful for immutable attributes, in fact there's no point in not having them unless you are just feeling lazy. If it is mutable then don't provide a Getter obviously.

Setters on the other hand are a problem, there are almost no instances where you would need a Setter for an object. If you have setters for your objects you are in the wrong frame of mind and need to do a lot more research on the paradigm of OOP.

Neither Java nor .NET force getters and setters. You can have public instance variables in both of them.


I never said force, I said require.

Force and require are the same thing in that context? It would only be different if you had said "if your language's idiomatic style requires..." or something along those lines. C# also has properties, which remove the need to write getters/setters for "future refactoring possibility" purposes and make it so even the idiomatic style does not encourage them.


If your language's idiomatic style requires you to write getters/setters then it is probably a terrible language.

Properties are really the same as writing getters and setters. When it is pre-compiled they are literally turned into a get_ and set_ method by name.

Future refactoring possibility isn't really a good reason to be writing a setter.

Objects are about providing services to other objects, it is called Responsibility Driven Design. If you are thinking about writing properties you are already doing it wrong.

The only time you should write properties is for creating read-only attributes, but then I don't know why the just don't have read-only attributes instead of having to waste time writing properties. Unfortunately read-only in C# is reserved when they really meant immutable not read-only.
Come play Android Netrunner - http://www.teamliquid.net/forum/viewmessage.php?topic_id=409008
Amnesty
Profile Joined April 2003
United States2054 Posts
September 17 2013 05:37 GMT
#7083
Write any container class without setters.
See if you like them better afterwards.

std::vector would be pretty useless without at() and overloaded [] operator for example.
The sky just is, and goes on and on; and we play all our BW games beneath it.
WindWolf
Profile Blog Joined July 2012
Sweden11767 Posts
September 17 2013 05:56 GMT
#7084
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself
EZ4ENCE
tec27
Profile Blog Joined June 2004
United States3702 Posts
September 17 2013 05:58 GMT
#7085
On September 17 2013 14:27 sluggaslamoo wrote:
Show nested quote +
On September 17 2013 14:04 tec27 wrote:
On September 17 2013 14:00 sluggaslamoo wrote:
On September 17 2013 12:57 Millitron wrote:
On September 17 2013 09:12 sluggaslamoo wrote:
If your language requires you to write getters/setters then it is probably a terrible language, e.g Java/.NET.

If you don't have a choice however (working in a corporate environment), the debate is asking the wrong question. You shouldn't be lumping Getter and Setter in the same question.

Getters are perfectly fine in any situation and very useful for immutable attributes, in fact there's no point in not having them unless you are just feeling lazy. If it is mutable then don't provide a Getter obviously.

Setters on the other hand are a problem, there are almost no instances where you would need a Setter for an object. If you have setters for your objects you are in the wrong frame of mind and need to do a lot more research on the paradigm of OOP.

Neither Java nor .NET force getters and setters. You can have public instance variables in both of them.


I never said force, I said require.

Force and require are the same thing in that context? It would only be different if you had said "if your language's idiomatic style requires..." or something along those lines. C# also has properties, which remove the need to write getters/setters for "future refactoring possibility" purposes and make it so even the idiomatic style does not encourage them.


If your language's idiomatic style requires you to write getters/setters then it is probably a terrible language.

Properties are really the same as writing getters and setters. When it is pre-compiled they are literally turned into a get_ and set_ method by name.

Future refactoring possibility isn't really a good reason to be writing a setter.

Objects are about providing services to other objects, it is called Responsibility Driven Design. If you are thinking about writing properties you are already doing it wrong.

The only time you should write properties is for creating read-only attributes, but then I don't know why the just don't have read-only attributes instead of having to waste time writing properties. Unfortunately read-only in C# is reserved when they really meant immutable not read-only.

I don't know why you're arguing with me, I wasn't trying to get into this debate again; its been had at least like 4 times in this thread already. I was just replying because you were a bit short/rude with the previous poster and acted as if what you said made sense. It didn't.

I don't even disagree with you really, so your arguments are kind of useless here.
Can you jam with the console cowboys in cyberspace?
tec27
Profile Blog Joined June 2004
United States3702 Posts
September 17 2013 06:02 GMT
#7086
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself

This is an example of where you probably wouldn't want to name the method setSeed. getX and setX have connotations that they have very little side effects (e.g. getX has no side effects and setX has a single side effect, namely setting X). If they are expensive and/or have more side effects than just that, a different naming choice could indicate that to the user better.

But you're setting up a straw-man for your "reasoning for using setters" here. Your alternative is to repeat the same code everywhere, which is obviously bad and not what any of the anti-gettersetter crowd is arguing for.
Can you jam with the console cowboys in cyberspace?
sluggaslamoo
Profile Blog Joined November 2009
Australia4494 Posts
Last Edited: 2013-09-17 06:09:58
September 17 2013 06:06 GMT
#7087
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself


There are plenty of reasons. In this case it could make the code hard to debug. Someone could easily already be using setSeed() deeply nested within some code file.

Then when your code doesn't randomize differently, you are sitting their scratching your head why your RNG code didn't work when really it was setSeed causing the issue.

The seed should be set in the initialiser or as a config variable or both. You aren't going to need to set the seed on the fly for RNG in a game. When the game starts you initialise the RNG object with the seed using the game's config table, after that it doesn't need to change until the next game. This allows you to isolate the issue and make debugging much easier.

IMO it is also simpler and much more intuitive than using setSeed.
Come play Android Netrunner - http://www.teamliquid.net/forum/viewmessage.php?topic_id=409008
rasnj
Profile Joined May 2010
United States1959 Posts
September 17 2013 06:08 GMT
#7088
On September 17 2013 13:34 Amnesty wrote:
Anyone know of a way to put something into a input stream. So there is a default value there.

So instead of


cout >> "Input a number :";
int x;
cin << x;

printing
Input a number :

it would print
Input a number :150_<cursor right here>

For example.


I do not believe there is a standard C++ way of doing this. You can inject data into cin as follows:
std::cin.putback('1');
std::cin.putback('5');
std::cin.putback('0');
But it will not show up on the console and you cannot erase those characters. Generally standard C++ is very limited in what you can do at the console. If you are just using the console because you are still learning and it is more convenient than coding a GUI interface, then I would just settle for something simpler like:
Input a number (default: 150): _

If you actually want to do it properly you will need to do something platform dependent or use a third-party library that abstracts away the platform dependence. On Win32 you could do (this has no error-handling and can only handle digits, but the idea can easily be generalized if you wish):
#include <iostream>
#include <windows.h>

void write_digit_to_stdin(char digit)
{
// Calculate virtual-key code.
// Look up on MSDN for codes for other keys than the digits.
int virtual_key_code = static_cast<int>(digit) + 0x30 - static_cast<int>('0');

// Fill out an input record that simulates pressing the desired key followed
// by releasing the same key.
INPUT_RECORD input_record[2];
for(int i = 0; i < 2; ++i)
{
input_record[i].EventType = KEY_EVENT;
input_record[i].Event.KeyEvent.dwControlKeyState = 0;
input_record[i].Event.KeyEvent.uChar.UnicodeChar = digit;
input_record[i].Event.KeyEvent.wRepeatCount = 1;
input_record[i].Event.KeyEvent.wVirtualKeyCode = virtual_key_code;
input_record[i].Event.KeyEvent.wVirtualScanCode = MapVirtualKey(virtual_key_code, MAPVK_VK_TO_VSC);
}
input_record[0].Event.KeyEvent.bKeyDown = TRUE;
input_record[1].Event.KeyEvent.bKeyDown = FALSE;

DWORD tmp = 0;
WriteConsoleInput( GetStdHandle(STD_INPUT_HANDLE) ,input_record,2,&tmp);
}

int main()
{
int x;
std::cout << "Input a number: ";
write_digit_to_stdin('1');
write_digit_to_stdin('5');
write_digit_to_stdin('0');
std::cin >> x;
std::cout << "Wrote: " << x << std::endl;

return 0;
}
rasnj
Profile Joined May 2010
United States1959 Posts
September 17 2013 06:20 GMT
#7089
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself

It is some what misleading to call it "set seed" because that suggests that you are just setting an internal seed variable (which very well may happen, but you don't want the user to care). A better way to think of it is that you are asking the RNG to seed itself with some value, you are asking it to perform an action, not accessing a data element (whether or not the two may equivalent in implementation is irrelevant). You should call it "seed" not "setSeed" in my opinion.

However in any case a RNG is probably one of the cases where the user might very well care about implementation-details and therefore leaking implementation details might not be as bad.
Amnesty
Profile Joined April 2003
United States2054 Posts
September 17 2013 06:34 GMT
#7090
On September 17 2013 15:08 rasnj wrote:
Show nested quote +
On September 17 2013 13:34 Amnesty wrote:
Anyone know of a way to put something into a input stream. So there is a default value there.

So instead of


cout >> "Input a number :";
int x;
cin << x;

printing
Input a number :

it would print
Input a number :150_<cursor right here>

For example.


I do not believe there is a standard C++ way of doing this. You can inject data into cin as follows:
std::cin.putback('1');
std::cin.putback('5');
std::cin.putback('0');
But it will not show up on the console and you cannot erase those characters. Generally standard C++ is very limited in what you can do at the console. If you are just using the console because you are still learning and it is more convenient than coding a GUI interface, then I would just settle for something simpler like:
Input a number (default: 150): _

If you actually want to do it properly you will need to do something platform dependent or use a third-party library that abstracts away the platform dependence. On Win32 you could do (this has no error-handling and can only handle digits, but the idea can easily be generalized if you wish):
#include <iostream>
#include <windows.h>

void write_digit_to_stdin(char digit)
{
// Calculate virtual-key code.
// Look up on MSDN for codes for other keys than the digits.
int virtual_key_code = static_cast<int>(digit) + 0x30 - static_cast<int>('0');

// Fill out an input record that simulates pressing the desired key followed
// by releasing the same key.
INPUT_RECORD input_record[2];
for(int i = 0; i < 2; ++i)
{
input_record[i].EventType = KEY_EVENT;
input_record[i].Event.KeyEvent.dwControlKeyState = 0;
input_record[i].Event.KeyEvent.uChar.UnicodeChar = digit;
input_record[i].Event.KeyEvent.wRepeatCount = 1;
input_record[i].Event.KeyEvent.wVirtualKeyCode = virtual_key_code;
input_record[i].Event.KeyEvent.wVirtualScanCode = MapVirtualKey(virtual_key_code, MAPVK_VK_TO_VSC);
}
input_record[0].Event.KeyEvent.bKeyDown = TRUE;
input_record[1].Event.KeyEvent.bKeyDown = FALSE;

DWORD tmp = 0;
WriteConsoleInput( GetStdHandle(STD_INPUT_HANDLE) ,input_record,2,&tmp);
}

int main()
{
int x;
std::cout << "Input a number: ";
write_digit_to_stdin('1');
write_digit_to_stdin('5');
write_digit_to_stdin('0');
std::cin >> x;
std::cout << "Wrote: " << x << std::endl;

return 0;
}


I'm not new to C++, just i was rather surprised i was stumped on this. I don't think I ever wanted to do such a thing before.

Anyway, i started learning assembly and wrote this puzzle game using just assembly.
[image loading]

Since i'm not really good at assembly yet i wrote the map editor in C++ and its a console app because a full blown GUI app would be a bit overkill.
It would be nice to press S for save and instead of getting a blank input for the filename it would default to something. And after saving it as a certain name, it would default to that too. Its been really annoying typing in the full name every time.

I could just write my own input loop where i push back chars into a string, popback on backspace, and set the cursor position accordingly. But I thought i would ask if there was something easy to do.
The sky just is, and goes on and on; and we play all our BW games beneath it.
WindWolf
Profile Blog Joined July 2012
Sweden11767 Posts
September 17 2013 07:20 GMT
#7091
On September 17 2013 15:06 sluggaslamoo wrote:
Show nested quote +
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself


There are plenty of reasons. In this case it could make the code hard to debug. Someone could easily already be using setSeed() deeply nested within some code file.

Then when your code doesn't randomize differently, you are sitting their scratching your head why your RNG code didn't work when really it was setSeed causing the issue.

The seed should be set in the initialiser or as a config variable or both. You aren't going to need to set the seed on the fly for RNG in a game. When the game starts you initialise the RNG object with the seed using the game's config table, after that it doesn't need to change until the next game. This allows you to isolate the issue and make debugging much easier.

IMO it is also simpler and much more intuitive than using setSeed.

I didn't meant about RNG's specifically, I was just the principal of using a set method for a long piece of code instead of writing all of that code again.

And even is setSeed isn't a good name, what would make for a good name (we can take the debate on whenever you should be able to change the seed of a RGN or not another time)
EZ4ENCE
Tobberoth
Profile Joined August 2010
Sweden6375 Posts
September 17 2013 07:37 GMT
#7092
RNG just happens to be a very unfortunate example since it's probably one of the main examples where you DON'T want to let anything set the value. To get as random results as possible, it's best practice to only make a singleton Random object, set the seed at program start and then poll that same object. Changing seed is just straight up bad practice, so an RNG class which lets you do that wouldn't make much sense.

However, the background concept makes sense of course. If a class has a mutable property in its interface which is implemented with a lot of code, it's definitely worth doing a setter for it. RNG just doesn't have such a mutable property in its interface, you're not supposed to change the seed of a RNG object.
WindWolf
Profile Blog Joined July 2012
Sweden11767 Posts
September 17 2013 07:46 GMT
#7093
On September 17 2013 16:37 Tobberoth wrote:
RNG just happens to be a very unfortunate example since it's probably one of the main examples where you DON'T want to let anything set the value. To get as random results as possible, it's best practice to only make a singleton Random object, set the seed at program start and then poll that same object. Changing seed is just straight up bad practice, so an RNG class which lets you do that wouldn't make much sense.

However, the background concept makes sense of course. If a class has a mutable property in its interface which is implemented with a lot of code, it's definitely worth doing a setter for it. RNG just doesn't have such a mutable property in its interface, you're not supposed to change the seed of a RNG object.

Yeah, I just couldn't think of any better thing at that very moment
EZ4ENCE
alexbrown
Profile Joined August 2013
United Kingdom6 Posts
September 17 2013 08:36 GMT
#7094
Thanks for the information.
sluggaslamoo
Profile Blog Joined November 2009
Australia4494 Posts
September 17 2013 23:33 GMT
#7095
On September 17 2013 16:20 WindWolf wrote:
Show nested quote +
On September 17 2013 15:06 sluggaslamoo wrote:
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself


There are plenty of reasons. In this case it could make the code hard to debug. Someone could easily already be using setSeed() deeply nested within some code file.

Then when your code doesn't randomize differently, you are sitting their scratching your head why your RNG code didn't work when really it was setSeed causing the issue.

The seed should be set in the initialiser or as a config variable or both. You aren't going to need to set the seed on the fly for RNG in a game. When the game starts you initialise the RNG object with the seed using the game's config table, after that it doesn't need to change until the next game. This allows you to isolate the issue and make debugging much easier.

IMO it is also simpler and much more intuitive than using setSeed.

I didn't meant about RNG's specifically, I was just the principal of using a set method for a long piece of code instead of writing all of that code again.

And even is setSeed isn't a good name, what would make for a good name (we can take the debate on whenever you should be able to change the seed of a RGN or not another time)


The same principle still applies for lots of things. You want to reduce the amount of side effects to a minimum in order to make maintenance easier. I can't even remember the last time I have used a setter.
Come play Android Netrunner - http://www.teamliquid.net/forum/viewmessage.php?topic_id=409008
berated-
Profile Blog Joined February 2007
United States1134 Posts
September 17 2013 23:45 GMT
#7096
On September 18 2013 08:33 sluggaslamoo wrote:
Show nested quote +
On September 17 2013 16:20 WindWolf wrote:
On September 17 2013 15:06 sluggaslamoo wrote:
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself


There are plenty of reasons. In this case it could make the code hard to debug. Someone could easily already be using setSeed() deeply nested within some code file.

Then when your code doesn't randomize differently, you are sitting their scratching your head why your RNG code didn't work when really it was setSeed causing the issue.

The seed should be set in the initialiser or as a config variable or both. You aren't going to need to set the seed on the fly for RNG in a game. When the game starts you initialise the RNG object with the seed using the game's config table, after that it doesn't need to change until the next game. This allows you to isolate the issue and make debugging much easier.

IMO it is also simpler and much more intuitive than using setSeed.

I didn't meant about RNG's specifically, I was just the principal of using a set method for a long piece of code instead of writing all of that code again.

And even is setSeed isn't a good name, what would make for a good name (we can take the debate on whenever you should be able to change the seed of a RGN or not another time)


The same principle still applies for lots of things. You want to reduce the amount of side effects to a minimum in order to make maintenance easier. I can't even remember the last time I have used a setter.


Can you make some clarifications, for those of us in the peanut gallery.

What language do you do most of your programming in? And what are the size of the projects you work on? Also, are you excluding domain objects from outside of your discussions of getters and setters are bad.
phar
Profile Joined August 2011
United States1080 Posts
September 18 2013 00:27 GMT
#7097
Mutable objects that you pass around a lot in general are confusing as shit to keep track of, especially in larger code bases. Immutability wherever possible keeps things sane.

Setters are just one example of a highly mutable object that can easily get out of hand.

For example, see Effective Java ch 15.
Who after all is today speaking about the destruction of the Armenians?
waxypants
Profile Blog Joined September 2009
United States479 Posts
Last Edited: 2013-09-18 01:20:17
September 18 2013 01:17 GMT
#7098
On September 17 2013 16:20 WindWolf wrote:
Show nested quote +
On September 17 2013 15:06 sluggaslamoo wrote:
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself


There are plenty of reasons. In this case it could make the code hard to debug. Someone could easily already be using setSeed() deeply nested within some code file.

Then when your code doesn't randomize differently, you are sitting their scratching your head why your RNG code didn't work when really it was setSeed causing the issue.

The seed should be set in the initialiser or as a config variable or both. You aren't going to need to set the seed on the fly for RNG in a game. When the game starts you initialise the RNG object with the seed using the game's config table, after that it doesn't need to change until the next game. This allows you to isolate the issue and make debugging much easier.

IMO it is also simpler and much more intuitive than using setSeed.

I didn't meant about RNG's specifically, I was just the principal of using a set method for a long piece of code instead of writing all of that code again.

And even is setSeed isn't a good name, what would make for a good name (we can take the debate on whenever you should be able to change the seed of a RGN or not another time)


What you described is not a "setter" just because it has name "set" in it. Of course almost every function or even single statement in programming involves something getting "set" to something else. Doesn't make it a "setter".

edit: Although I think you inadvertently brought up a good question, which is "how much work can a method do before it's not really a 'setter' or 'getter' anymore?" I think you brought up an example where it is clearly doing too much work to be a "setter".
sluggaslamoo
Profile Blog Joined November 2009
Australia4494 Posts
Last Edited: 2013-09-18 04:02:56
September 18 2013 03:57 GMT
#7099
On September 18 2013 08:45 berated- wrote:
Show nested quote +
On September 18 2013 08:33 sluggaslamoo wrote:
On September 17 2013 16:20 WindWolf wrote:
On September 17 2013 15:06 sluggaslamoo wrote:
On September 17 2013 14:56 WindWolf wrote:
One reason I'm wondering why people hate setters and getters:

Lets assume that you've written a RNG that has complex internal code (just as an example) and requires lots of code just to set a seed (once again, just as an example). In that case, I would find it easier to read setSeed() than reading all of the code required to set the seed itself


There are plenty of reasons. In this case it could make the code hard to debug. Someone could easily already be using setSeed() deeply nested within some code file.

Then when your code doesn't randomize differently, you are sitting their scratching your head why your RNG code didn't work when really it was setSeed causing the issue.

The seed should be set in the initialiser or as a config variable or both. You aren't going to need to set the seed on the fly for RNG in a game. When the game starts you initialise the RNG object with the seed using the game's config table, after that it doesn't need to change until the next game. This allows you to isolate the issue and make debugging much easier.

IMO it is also simpler and much more intuitive than using setSeed.

I didn't meant about RNG's specifically, I was just the principal of using a set method for a long piece of code instead of writing all of that code again.

And even is setSeed isn't a good name, what would make for a good name (we can take the debate on whenever you should be able to change the seed of a RGN or not another time)


The same principle still applies for lots of things. You want to reduce the amount of side effects to a minimum in order to make maintenance easier. I can't even remember the last time I have used a setter.


Can you make some clarifications, for those of us in the peanut gallery.

What language do you do most of your programming in? And what are the size of the projects you work on? Also, are you excluding domain objects from outside of your discussions of getters and setters are bad.


I use Ruby mostly, but in certain companies I have had to deal with other languages, and I've worked on both small and behemoth monolithic Java projects.

Basically what phar said. For every time you allow something to change, it means one extra thing you have to think of when debugging.

Setting is best left to initialisers or factories, then the object performs services using those parameters and keeps everything self contained. Instead of using setters, you can create a new object with new parameters.

Think of it as people working within an organisation, you don't set attributes to people, you have different people who are capable of doing different things. "Hire" the people you need, then hand off the work to each of these people to get the work done.

In Ruby I also tend to do a lot of things functionally, which removes the issue of side effects, but you also don't have these hand offs between objects when really you just want something short and sweet.

Its very hard to do right and will take years to figure out how to be able to do it in a way that makes the code look better not worse, let alone figure it out quickly. Just realise that in the long term you are going to be much better off.

The reason people write setters is because they don't realise other patterns exist to allow you to perform operations without them.
Come play Android Netrunner - http://www.teamliquid.net/forum/viewmessage.php?topic_id=409008
Manit0u
Profile Blog Joined August 2004
Poland17786 Posts
Last Edited: 2013-09-18 05:29:58
September 18 2013 04:22 GMT
#7100
On September 17 2013 15:08 rasnj wrote:
Show nested quote +
On September 17 2013 13:34 Amnesty wrote:
Anyone know of a way to put something into a input stream. So there is a default value there.

So instead of


cout >> "Input a number :";
int x;
cin << x;

printing
Input a number :

it would print
Input a number :150_<cursor right here>

For example.


I do not believe there is a standard C++ way of doing this. You can inject data into cin as follows:
std::cin.putback('1');
std::cin.putback('5');
std::cin.putback('0');
But it will not show up on the console and you cannot erase those characters. Generally standard C++ is very limited in what you can do at the console. If you are just using the console because you are still learning and it is more convenient than coding a GUI interface, then I would just settle for something simpler like:
Input a number (default: 150): _

If you actually want to do it properly you will need to do something platform dependent or use a third-party library that abstracts away the platform dependence. On Win32 you could do (this has no error-handling and can only handle digits, but the idea can easily be generalized if you wish):
#include <iostream>
#include <windows.h>

void write_digit_to_stdin(char digit)
{
// Calculate virtual-key code.
// Look up on MSDN for codes for other keys than the digits.
int virtual_key_code = static_cast<int>(digit) + 0x30 - static_cast<int>('0');

// Fill out an input record that simulates pressing the desired key followed
// by releasing the same key.
INPUT_RECORD input_record[2];
for(int i = 0; i < 2; ++i)
{
input_record[i].EventType = KEY_EVENT;
input_record[i].Event.KeyEvent.dwControlKeyState = 0;
input_record[i].Event.KeyEvent.uChar.UnicodeChar = digit;
input_record[i].Event.KeyEvent.wRepeatCount = 1;
input_record[i].Event.KeyEvent.wVirtualKeyCode = virtual_key_code;
input_record[i].Event.KeyEvent.wVirtualScanCode = MapVirtualKey(virtual_key_code, MAPVK_VK_TO_VSC);
}
input_record[0].Event.KeyEvent.bKeyDown = TRUE;
input_record[1].Event.KeyEvent.bKeyDown = FALSE;

DWORD tmp = 0;
WriteConsoleInput( GetStdHandle(STD_INPUT_HANDLE) ,input_record,2,&tmp);
}

int main()
{
int x;
std::cout << "Input a number : ";
write_digit_to_stdin('1');
write_digit_to_stdin('5');
write_digit_to_stdin('0');
std::cin >> x;
std::cout << "Wrote: " << x << std::endl;

return 0;
}


Why make it so complicated?


#include <iostream>
#include <string>
#include <locale>
#include <sstream>
using namespace std;

int main()
{
locale loc;
int x = 150;
string str;

cout << "Input a number (default 150): ";
getline(cin, str);

if(strlen str)
{
if(isdigit(str[0], loc))
{
stringstream(str) >> x;
}
}

cout << "Your chosen number is: " << x << endl;

return 0;
}
Time is precious. Waste it wisely.
Prev 1 353 354 355 356 357 1032 Next
Please log in or register to reply.
Live Events Refresh
Sparkling Tuna Cup
10:00
Weekly #137
ByuN vs SHINLIVE!
herO vs Percival
CranKy Ducklings224
CranKy Ducklings SOOP14
LiquipediaDiscussion
RSL Revival
09:00
Season 6 - Group B
Ryung 745
IntoTheiNu 298
Rex130
Liquipedia
[ Submit Event ]
Live Streams
Refresh
StarCraft 2
Ryung 745
Rex 130
ProTech83
MindelVK 13
StarCraft: Brood War
Britney 32269
Calm 7406
Hyuk 774
Shuttle 759
Jaedong 530
Soma 382
firebathero 256
BeSt 252
Mini 230
Stork 192
[ Show more ]
EffOrt 183
Horang2 179
Last 168
actioN 150
Soulkey 132
Light 124
Mong 122
ZerO 75
hero 63
ggaemo 49
Sharp 42
ToSsGirL 40
scan(afreeca) 39
soO 32
Free 28
HiyA 27
sorry 26
Aegong 25
Killer 24
yabsab 19
Hm[arnc] 15
Sacsri 14
ajuk12(nOOB) 13
Noble 11
JulyZerg 8
Purpose 8
Dota 2
Gorgc4646
Dendi570
League of Legends
Doublelift2651
JimRising 584
Counter-Strike
x6flipin277
Sick173
kRYSTAL_4
Other Games
FrodaN2922
B2W.Neo410
DeMusliM267
crisheroes244
Pyrionflax222
Happy214
KnowMe113
Livibee81
ZerO(Twitch)7
Organizations
StarCraft: Brood War
lovetv 16
StarCraft 2
Blizzard YouTube
StarCraft: Brood War
BSLTrovo
[ Show 13 non-featured ]
StarCraft 2
• StrangeGG 30
• Response 1
• AfreecaTV YouTube
• intothetv
• Kozan
• IndyKCrew
• LaughNgamezSOOP
• Migwel
• sooper7s
StarCraft: Brood War
• BSLYoutube
• STPLYoutube
• ZZZeroYoutube
League of Legends
• Jankos3391
Upcoming Events
IPSL
4h 14m
Bonyth vs Hawk
GSL
23h 14m
Monday Night Weeklies
1d 4h
Replay Cast
1d 12h
WardiTV Weekly
1d 23h
The PondCast
2 days
Replay Cast
3 days
CrankTV Team League
3 days
Replay Cast
4 days
CrankTV Team League
4 days
[ Show More ]
Replay Cast
5 days
RSL Revival
5 days
Clem vs Lambo
Scarlett vs Cure
CranKy Ducklings
5 days
RSL Revival
6 days
Classic vs Trap
herO vs SHIN
Sparkling Tuna Cup
6 days
Liquipedia Results

Completed

ASL Season 22: Wild Card Qualifier
HSC XXIX
Eternal Conflict S2 E1

Ongoing

IPSL Spring 2026
Acropolis #4
YSL S3
CSL 2026 Summer (S21)
RSL Revival: Season 6
CranK Gathers Season 4: BW vs SC2 Team League
SCTL 2026 Spring
Eternal Conflict S2 E2
XSE Pro League 2026
IEM Cologne Major 2026
Stake Ranked Episode 2
CS Asia Championships 2026
Asian Champions League 2026
IEM Atlanta 2026
PGL Astana 2026
BLAST Rivals Spring 2026

Upcoming

Escore Tournament S3: W3
ASL S22 SEASON OPEN Day 1
Escore Tournament S3: W4
ASL S22 SEASON OPEN Day 2
Escore Tournament S3: W5
CSLAN 4
Blizzard Classic Cup 2026
HSC XXX
SC4ALL II: StarCraft II
Kung Fu Cup 2026 Grand Finals
Light Tournament 2026
Eternal Conflict S2 Finale
Eternal Conflict S2 E3
Logitech G Connect 2026
StarSeries Fall 2026
FISSURE Playground #5
BLAST Open Fall 2026
Esports World Cup 2026
BLAST Bounty Summer 2026
BLAST Bounty Summer Qual
Stake Ranked Episode 3
TLPD

1. ByuN
2. TY
3. Dark
4. Solar
5. Stats
6. Nerchio
7. sOs
8. soO
9. INnoVation
10. Elazer
1. Rain
2. Flash
3. EffOrt
4. Last
5. Bisu
6. Soulkey
7. Mini
8. Sharp
Sidebar Settings...

Advertising | Privacy Policy | Terms Of Use | Contact Us

Original banner artwork: Jim Warren
The contents of this webpage are copyright © 2026 TLnet. All Rights Reserved.