no viable overloaded '='

Question

I'm taking a simulation course in C++ right now, and am getting the clang++ error quoted in the title. I was hoping someone could tell me why because I cannot seem to find a similar error for a similar situation anywhere (search as I may).

The error occurs for each Office* variable definition (lines 187 to 190).

175 class EventHandler {
176 
177     private:
178     double simulation_time;    // current simulation time
179     Office* aid, bursar, registrar, parking;
180     Event* current_event;
181     MinHeap* time_heap;
182 
183     public:
184 
185     void initialize_simulation() {  // initializes simulation time, offices, and event handler (time_heap)
186         simulation_time = 0;
187         aid = new Office(8, Tf);    // initializes financial aid office with Tf tellers, with serve time exponentially distributed with mean of 8 minutes
188         bursar = new Office(15, Tb);     // initializes bursar office w/ Tb tellers, exp distro, mean 15 min
189         registrar = new Office(5, Tr);    // registrar w/ Tr tellers, exp distro, mean 5 min
190         parking = new Office(10,Tp);       // parking office w/ Tp tellers, exp distro, mean 10
192         MinHeap* time_heap = new MinHeap();
193     }

If I replace the Office* aid declaration (for instance), and change aid = new Office(15, Tf) to Office* aid = new Office(15, Tf), the error goes away. I have no idea why, and would very much like to, because I want all of these class pointers to be private.

Interestingly (irritatingly?), the MinHeap* time_heap; time_heap = new MinHeap(); does not cause any problems. I thought it may have to do with declaring a pointer var as private then defining it in the public portion of the class but it looks like no.

help? =|

Solution 1

Office* aid, bursar, registrar, parking;

Declares a single pointer, and 3 objects. You probably think you want:

Office *aid, *bursar, *registrar, *parking;

And you actually want:

std::unique_ptr<Office> aid;
std::unique_ptr<Office> busar;
std::unique_ptr<Office> parking;
std::unique_ptr<Office> registrar;

and to initialize them in the constructor initializer list. If the class isn't the resource owner, go with std::shared_ptr.

Solution 2

Here:

Office* aid, bursar, registrar, parking;

only aid is an Office*, the rest are Office. Looking at your code, It looks like you can easily avoid problems by not using pointers:

Office aid, bursar, registrar, parking;

then

     aid = Office(8, Tf); 
     bursar = Office(15, Tb); 
     registrar = Office(5, Tr);
     parking = Office(10,Tp); 

Also, your initialize_simulation() seems designed to be only called once. You are probably better off initializing in the constructor.

EventHandler::EventHandler() 
 : aid(8,Tf), bursar(15, Tb), registrar(5, Tr), parking(10, Tp) {}

Comments

[user1647959]

rofl FML, compiles just fine if I change it. Three follow up questions: 1) ...why on earth? 2) it's because it's a pointer, correct? 3) what's the proper (compact) syntax for such a thing (right now i've got a new one each line)?

[Luchian Grigore]

@user1647959 please don't post follow-up questions in the comments. Ask a new one.

[Luchian Grigore]

@user1647959 also, it looks like you don't even need follow-up questions.

[juanchopanza]

I'm not sure they actually need pointers at all, but if they do, this is the way to do it!

[Luchian Grigore]

@user1647959 don't use pointers & dynamic allocation unless you have to. And even then, use managed objects (smart pointers).

[user1647959]

I know it is completely against the exchange we just had, but juan's approach is intuitively alot more appealing to me (moving the whole thing to the constructor and leaving the other declarations the way, to quote you luch, 'i think i want them').. why use std::unique_ptr? I sort-of liked the idea of initializing these pointers when the simulation starts, and deleting them myself when it's finished.. EDIT: sorry again, it just seems like such a worthless question to repost for

[juanchopanza]

@user1647959 you should only use dynamically allocated objects if you really, really need to. If in doubt, don't use.

[Luchian Grigore]

@user1647959 if you must you pointers and think raw ones are more intuitive, you'd better change your views really soon (or else I bet you'll come in an hour or two with memory management issues/double deletes/whatever). I'm sure juanchopanza can attest smart pointers are better.

[juanchopanza]

@user1647959 absolutely agree with Lucian, no pointers, or smart pointers if you really need dynamic allocation.