hello friends, i have this code, i know it is not complite even but i try to help my self to understand how supscript operator overloading work, so can you please help me to complitle this code as simple idea just to make it clear?
thank you
#include<iostream>
#include<string>
usingnamespace std;
class person{
string name;
int age;
public:
person(){}
person(string n,int a){
name=n;
age=a;
}
int getage(){return age;}
string getname(){return name;}
int& operator[](int index){
person obj;
if(index==[0])
returnelseif(index==(1))
cout<<obj.getname();
}
};
int main()
{
person objj;
cout<<"the index for friest one is "<<objj[1]<<endl;
cout<<"the index for secound index is "<<objj[1];
system("pause");
return 0;
}
Don't worry about operator overloading just yet, you're still missing some of the basics. For instance, if you want your variable 'objj' to be an array, then why didn't you make it as such? Or are you just doing something intentionally wacky with the overloaded operator?
Also, you are trying to extract meaning full data from uninitialized fields. That will never work.
if you want to make just an array you make it like with every other type: person arr[5];
If you want to overload operator you make it like so: return-type operator(type of operator without parentheses)(one or two arguments depending on operator);
e.g.
1 2
unsignedoperator+(person, unsigned);
unsignedoperator*(person); // it's not multiplying, you apply it like this: *some_type
Never say "never use X", it's lazy and unhelpful. While it's true that the "system()" function is mostly seen as a boondoggle for the lazy and un-productive, you have to sort of except that the people that wrote and upkeep these libraries are smarter then you and me so there is a reason that it exists. Even if that reason is as dumb as "Somebody someday might want to use it.", it is still one that they, the C++ committee, have excepted as being good enough.
There can be legitimate reasons to execute other commands and do it with system() rather than one of the other similar functions, but calling the program "pause" it not one of them.
If it was so good, anti-viruses wouldn't complain on software containing it. I know it's sometimes (I mean very rarely, hardly ever) useful. If you want to use it, check, if there is no other way with api. If there is no alternative you can use it (it's kind of like with goto, though goto is sometimes better alternative, e.g. nested loops).
@ TheHardew: I'm not attacking you, not intentionally. What I want to do is stamp out this 'fan-boyism'\bandwagon crap that saturates every other corner of the internet. It only serves to make users dumber. If you had said not to use "system()" because you don't have as much control over the child object as you would otherwise, or that all you get back is an error code and even then it's from the child app instead of the function that actually failed, or that it halts execution on your process until the child finishes or a myriad of other legitimate reasons that this function sucks then I would have agreed with you and left it alone. But a statement like the one you made without context doesn't help OP very much, and as you can see by their code they have more important things to worry about then other peoples pet-peeves.
The reason that calling system("pause"); is stupid by the way is that console programs are meant to be run in a console environment. Programs that happen to run in the console shell that are executed from a graphical desktop are not meant to preserve output, or if they are it's done to a secondary stream such as a log file. The point is that there is no need to "Hold the screen open so you can see what happened." because a command shell does that all by itself.
AV suites don't complain about "system()" btw. Only one, maybe two, of them ever really did and even that was for such a short while and such a long time ago that it's hardly worth mentioning. Heuristic detection schemes are a lot more complicated then just axing a program because of one black-balled function. Especially a function like this that has virtually no practical use for exploits when compared to alternative approaches.
Ok, thanks and sorry, I didn't plan on attacking you either. Next time I'll write why it is so bad. Just after seeing examples of finding whether a directory exists or not with system() I forgot, that rarely it's got some sense.