The Big Programming Thread - Page 356

On September 18 2013 13:22 Manit0u wrote:


Why make it so complicated?

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

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

    cout << "Input a number (default 150): ";
    getline(cin, str);
    
    if(strlen str)
    {
        stringstream(str) >> x;
    }

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

    return 0;
}

On September 18 2013 14:11 rasnj wrote:

Well because the person I was replying to asked for it to have a prompt of the form:
"Input a number: 150"
where the "150" can be edited, so I may type
<backspace>23<enter>
and the console would look like
Input a number: 1523
Wrote: 1523
What you wrote is similar to the simple alternative I suggested.

On September 18 2013 14:36 Manit0u wrote:


You may want to look here then: http://www.cplusplus.com/reference/vector/vector/push_back/

On September 18 2013 10:17 waxypants wrote:


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

On September 18 2013 14:44 rasnj wrote:

I think you are misunderstanding what is expected. std::cin is not a vector it is an std::istream, so the relevant instruction is
std::istream::putback
as I remarked in my post. However this does not actually show up on the console, only in cin's internal buffer, and the user cannot delete it.

What we want is that when we launch the prompt looks as follows:
> Input a number: 150
If we press backspace we get
> Input a number: 15
If we press 2 at this point we get:
> Input a number 152
And we can now press enter at which point cin appends sends "152" to str.

class mystream
{
	stringstream stream;

	public:
	template<typename T>
	istream& operator >> (T& x)
	{
		return stream.str().empty() ? cin >> x : stream >> x;
	}

	template<typename T>
	ostream& operator << (const T& x)
	{
		return stream << x;
	}
} myin;

On September 18 2013 17:41 Manit0u wrote:


How about this?

class mystream
{
	stringstream stream;

	public:
	template<typename T>
	istream& operator >> (T& x)
	{
		return stream.str().empty() ? cin >> x : stream >> x;
	}

	template<typename T>
	ostream& operator << (const T& x)
	{
		return stream << x;
	}
} myin;

myin << x will print x into the buffer. myin >> x will read from the cin.

Damn it's hard... How about just using the GNU readline library?

On September 18 2013 23:26 darkness wrote:
I've been wondering, what's the reason for C style pointers missing in languages such as Java? Is object reference the better replacement?

On September 18 2013 23:36 rasnj wrote:

It comes down to:
1) It's hard to manage memory, and even if most programmers believe they are superstars they often make mistakes so we don't allow them to.
2) It is much easier to make an efficient garbage collector if you control all of memory allocation. It's hard to say when to destroy an object when at any time a programmer might pull of some fancy pointer arithmetic that points to an object you thought no one was referencing.
3) Why would you want to?

If you can come up with an example where you think they might help you, then we can comment more concretely on that.

EDIT: And no, object reference is not "better". For the sake of just passing objects by reference, object reference is likely better, but pointers give you more flexibility. They are different concepts. It is like asking whether monitors or printers are better. It depends on your application.

On September 19 2013 08:28 Azerbaijan wrote:
So from all this discussion about getters and setters I have gathered that I should generally avoid them except in very specific situations where their use will not cause problems later?

On September 19 2013 08:36 zzdd wrote:


You should use them in most situations but it depends on the language and what you're using them for. Programmer are very nitpicky when it comes to certain things and if it doesn't work in certain situations, it becomes their mission in life to make sure that no one ever uses it even if it will be useful.

On September 19 2013 01:58 Morfildur wrote:


While that sounds nice in theory, not using setters at all often produces needless overhead.

Take for an example a simple forum with user management. You have users, users have passwords and passwords are encrypted and occasionally get changed. In your example, everytime a user changes his password, you would clone the old user object with a different password parameter, which is a lot more overhead than taking an existing object and simply changing a property of it through a setter.

A simple "SetPassword(new Password)" method is easier to read, write and understand with exactly zero useless overhead. You can even hide the password encrypting, salting, spicing and garnishing behind it and not use a getter because passwords are 1-way encrypted and reading it doesn't make sense.

Yes, there are lots of getters/setters that are bad and i'm usually in favour of only using what is really neccessary and not go by the internal datastructure of the object, but there are also lots of legitimate reasons to use getters/setters, even in semi-functional languages like ruby. You just always have to think before blindly creating getters and setters, which admittedly is something not a lot of programmers do. Setters should never be a replacement for a proper constructor nor be required to initialize an object; That should always happen in the constructor so the object always has a valid state.

On September 19 2013 10:16 sluggaslamoo wrote:


Not trying to sound arrogant or anything, but I think its funny to say "it sounds nice in theory" when it is actually something I do in my profession all the time.

For databasing you should have a library which prevents you from having to use or write setters. Good libraries will provide an abstraction which takes you away from the process of having to manage data manually, mitigating the risk of human error. You then declare you database strategy, your validations, and data processing methods, and your library should handle the rest.

Sure in the end, you are still "setting" data but because it is all automated and declarative you are reducing side-effects to a minimum.

For example you will first be encapsulating the process in a transaction which gives you fail fast and rollback capabilities. Second of all instead of using setPassword, you would be using a system which takes form data and processes it automatically.

Any fields that are changed are processed within a transaction, if there are any errors it is rolled back, if not the transaction is committed and any processing required, e.g creating an encrypted password, is executed without procedural programming involved.

Feel free to keep shooting me examples. Keep in mind we are talking in the context of using OOP, which mostly useful for websites and business applications. The only thing I can think of where setters will be used extensively will be in an application where full OOP is not ideal, like traditional games.

EDIT:
I think I should clarify and answer your question more specifically.

Sometimes its impossible to avoid side-effects or setting data, your example is a good one. When you have to save user data, its physically impossible not to "set" data, it wouldn't make sense not to.

But as I said earlier, the only reason it doesn't make sense not to use a "setter" in this example is because you haven't learned a pattern to avoid doing so. There is always more overhead in writing and using setters.

To provide a solution to your example specifically.
- I would use a database library which handles my form data.
- I write a callback in my database which automatically encrypts and save the password whenever it changes.
- When the user submits form data which includes a password, the database library executes the callback which encrypts the password

This is much more elegant to using setPassword(), which I'm sure you would understand the headaches involved when it would come to maintaining very large program. You would have to make sure setPassword() is called in all the appropriate user save methods, finding those methods would take you hours in a corporate business application, and you would have to make sure that every other programmer knows to use it as well.

Having an on_change callback solves all these problems, if a person puts a password field in a new page that I don't know of, it will still take effect. Now I am completely abstracted away from the database management process. I don't need to use set() or save() anywhere in my code which makes my life much easier when I run into any problems.

On September 19 2013 10:47 berated- wrote:


This assumes that you are able to use a library like the ones used in ruby, python, or hibernate for java. Sometimes the sql that you have is so complex because you don't control the schema that this isn't possible. The strategy used for these is great for simple schemas, not so much when the schemas get super complex. This isn't an excuse to allow for poorly designed code, just sayin...

The thing to note here is that every in development is about trade offs. Even Holub's article on javaworld touches on this. Encapsulating all the code in the model is great because it allows for you to only touch the parts of code that you want to touch. Using libraries that handle this is even better.

What if you decided though that relational databases are complete shit, and nosql is the way to go? You would either have to redo all the libraries that were done for sql, or you hope that in that instance you wrote your own DAO layer and now you can just swap that out instead of having to touch all the rest of your model code.

Design is hard.

On September 19 2013 11:05 sluggaslamoo wrote:


When the schemas get super complex that's when this system becomes even better, however there should really never really be a time when your schemas get super complex. If that happens you are really over-engineering. I've worked with some very complex schemas using this system, I myself like to keep things very simple but that's probably due to the fact that things can be much simpler with ODM than SQL.

In my case most libraries reserve the same words as active_record, so swapping between a relational database and a document oriented database is a piece of cake. However in a large application the company wouldn't bother to give you the time to do this anyway.

All I'm doing is giving an appropriate example which in this case I'm assuming Java. Sure there are some edge cases where some obscure programming language won't have an appropriate library to do that, but there's nothing to be gained from using those examples in this debate.

It just seems silly to bring up an edge case example where you have to be dead set on writing setters. You may as well bring up C and ask how to write a website in it without using setters, then when I can't answer you just say "hah! see I told you!".

If an obscure language which nobody uses doesn't provide a library, I think many people would appreciate you writing the library yourself and sharing it . Otherwise don't use that language, any problems you face you brought upon yourself.