this is wrong code.

this is wrong code.

dont ever do this

Yes I agree... But for student projects it is acceptable

this is wrong code.

Yes, can you correct that, i want to create a template function object

Yes, can you correct that, i want to create a template function object

For which you need to include functional

I agree u have given a better alternative, but can we create function template object?

You also have the scope wrong. It should be typename std::unary_function<T, T>::result_type

Also, in general, I try to avoid auto. It is usually a source of problems. Not using it, forces you to think about what you are doing, and if the code changes, it will be less likely to keep running the wrong way

unary function is also not needed actually, and never was needed. The code would work brilliantly without those unary|binary|mem function.

You don't need to anymore, forget about them

Don't

Don't what?

I would if I can

Ok thanks, can you suggest good c++ book for modern practices standpoint

Very few circumstances need it

No, that is part of unary_function structure in c++

No, AUTO is fully transparent and remove tavtology because it needs initializer and the type is completely cleanly seen from it

Not transparent at all. If at a given point of the development the variable declared with auto changes the type, auto will adapt it and, if some other part of the code expects the old type, you are in trouble. It may be more convenient in some cases like the one mentioned by @András, but you risk breaking the code if you aren't careful with changes. I prefer to spend 0.5 seconds more writing vector<int>::iterator and save hours trying to find out why my code broke when I changed vector<int> by vector<something_else>

Not transparent at all. If at a given point of the development the variable declared with auto changes the type, auto will adapt it and, if some other part of the code expects the old type, you are in trouble. It may be more convenient in some cases like the one mentioned by @András, but you risk breaking the code if you aren't careful with changes. I prefer to spend 0.5 seconds more writing vector<int>::iterator and save hours trying to find out why my code broke when I changed vector<int> by vector<something_else>

Its match easier to write auto instead of everything (except of int). For example vector<int>::iterator

Variables can't change their types

It's easier and riskier. vector<int>::iterator is a random access iterator. If now you change your container to one whose iterator isn't random access, and you used this feature somewhere else, you'll get an error in a different point, and it will be more difficult to find out the problem

Variables can't. You can refactor your code and decide that a variable is better suited with a different type

But compiler at the compile time know which type should auto be, so If u change type radical, then you catch compile error

Compile time error

double var=v[i]/23;

At a different place. And this is a case where you are lucky to get a compile error. Imagine that you change vector<double> b y vector<int>. And somewhere else in your code you have something like

Unsafe code

Error like compiler cant do that with double types

It's a silly example. If you prefer, you can have double var=v[i]/v[i+1];

The compiler will replace auto with whatever it fits. And the error will happen somewhere else. Imagine that the line is auto var=myfunction(); Now I refactor and myfunction returns a different type. You won't get an error here. You'll get it somewhere else if you are lucky. If not, your program will simply give you wrong results

Anyway, if u try to store int to double, it's unsafe

If you change the return type of a function, the auto is probably the less important thing you should worry about

During development, it can happen. And anyway, why adding another problem? Just spend 0.5 seconds writing the type explicitly and save trouble

I don't feel like writing std::map<std::string, int>::const_iterator everytime I do a begin or end, when I already know the type and the compiler can deduce it for me

I find it a waste of time and leads to less readable code

If the type is explicit, you don't have to look anywhere. That line is clear as water

If you do a begin, it's clear water you're assinging an iterator

I don't say never use auto, but if you can avoid it. I think it makes the code clearer and less prone to errors not to use it

Makes refactoring a lot easier, less verbose, less error-prone

https://stackoverflow.com/questions/6434971/how-much-is-too-much-with-c11-auto-keyword