C++ scope problem

I am writing a program that has an employee struct and a company class. I have a function within my company class that adds an employee object to a list of employees. When I add the employee to the company, I want the data member "employer" inside my employee object to change.

struct employee{
public:
    ...
    string employer;
    string getemployer();
    void changeEmployer(string x);
    ...
private:
    ...
};

string employee::getemployer(){
    return employer;
}

void employee::changeEmployer(string x){
    this->employer = x;
}

class company{
public:
    company(string x){name = x;}
   
    list<employee> employees;

    string getname(){return name;};
    void addEmployee(employee newperson);
    void company::removeEmployee(employee quitter);
    void printemployees();
private:
    string name;
};

void company::addEmployee(employee newperson){
    list<employee>::iterator addemp = employees.begin();
    advance(addemp, 0);
    employees.insert(addemp, newperson);
    newperson.changeEmployer(this->getname());   
}

The last line that reads: "newperson.changeEmployer(this->getname());" appears to be ineffective because when I check to see if the employee's employer has been changed, it shows that it has NOT.

I'm assuming this is a scope problem. Is it possible to do this? Does anyone know how I can change the employer data member for the employee object?

In my main function I have the following:

int main(){
   
    employee Sally("Sally");
    company Google("Google");

    Google.addEmployee(Sally);

    cout << Sally.getemployer();


    return 0;
}

When I build and run, it doesn't print the new employer. It's as if the employer was not changed by adding the employee to the Google company.

Thanks in advance for any insight anyone is willing to share.

(p.s. the data types are specified in the assignment requirements so I can't change lists to vectors, or structs to classes, etc.)

write it in guile scheme instead

Step 1: Reduce the code down to the absolute smallest possible program that reproduces the problem
Step 2: Post actual code, not "..." shit that won't compile
Step 3: Code tags

90% of the time, you'll figure out the problem in the process of doing step 1.  For the other 10% of the time, continue with steps 2 and 3 and come back here.

From your description, I'm guessing you are probably modifying an object by value, instead of reference...  but I'm not reading that big-ass post to figure it out.

I am almost 99% sure structs cannot have access specifiers. But hey, what do I know.

>>4
I'd hate to see something that you were only, say, %85 sure about.

>>4
you'd think so, but no, seeples actually went and did it.

>>3
get the stick out of your ass

>>7
get the bug out of your shit

>>6

So wait, they actually do have access specifiers?
Are structs basically gimped classes now?
Wtf is the point of this. Excuse my retardation.

the this pointer is constant
this ain't java!

It's because you're copying the object every time you assign it to something.
When you call the function addEmployee, Sally is copied and that copy is what's used in the local scope.
When you call the function insert, you're copying the copy.
When you call the function changeEmployer, you're doing it on the copy of Sally, but because that copy was copied to be inserted into the list, you're now operating on a copy that will be deallocated momentarily.

One solution (albeit not a good one) would be to call changeEmployer before calling insert. Sally will however not have her employer changed, as you can't avoid copying her. You could use a reference (employee& newperson) to get around that, but you'd still copy her rendering it moot.

>>9
Gimped? No sir, they can do everything classes can. They're literally identical to classes except their members are public by default, where in classes they are private by default. You might even be able to cross-inherit, but that's compiler specific.

>>9
What >>12 said.

struct were only kept for backwards-compatibility I guess.

>>13
If they kept it for backwards-compatibility, why change it into a class?

>>14
Now you're getting it.

>>15
No, I'm not the original poster, I'm just genuinely wondering. What the fuck did Stroustrup think?

>>16
Exactly

>>16
If there were no classes, it wouldn't be ``C with classes'' and if there were no structs, it wouldn't be compatible with C. BTW, unions can also have access specifiers and member functions.

fuck stroustrup

>>17
Why the fuck ...