Search:

you mean you want an (abstract) base class?

Bah. I should have guessed from the crappy title.

you have the answer when you do my unambiguous exercise. In my example there are five 5's. So the answer is 5...

Biggest sins at a glance:
- premature initialization
- magic numbers (used[100], sizeof(words)/4)
- using char* instead of strings

Given some array e.g. 1 5 6 5 2 5 3 5 4 5 how would you count the amount of number 5 values?

Given an integer, how do you print it? (hint: no friggin loop).

for (size_t i = 0; i < books.size(); i++)
{
books[i].set_check(false);
}
That code checks out every book in the library. How you get this wrong after...

I told you already it is bad to do checking in main. Class related checks should be done by the class in many cases. Btw you also did the check twice in the check_out.

As for your first question,...

Since the last 10 pages didn't help I posted a code example and even pointed out how my code differs from your check_out. I am out of ideas to help you understand. Set_check modifies a book object. A...

The last one is a function i.e. method that does not modify nembers of the class.

Like Jim said, you aren't. But if you can't tell the difference between my code and yours it means your basic code reading skill is too low. Notice I am modifying an object in a vector based on a...

//given a book object outbook to be checked out
for (Book& buhk : books) {if (buhk==outbook) buhk.set_check(false);}
//do you understand that the database has been updated now?

You need to...

Based on what I saw when you last posted the check_out function, yes it is wrong (I said you were ignoring the database step mentioned in the use case). Unless I missed a revision. Aside from that...

It seems you're on the right track. Your should cout the value of number of books to help you debug. If e.g. you have 10 books in the library and 3 are checked out, the loop should print the values...

No, we already talked about that. As far as checking in and out are concerned your library class is finished. It has all you need. Your logic is just failing because you don't realize you already...

Currently you ignore the updating database step. What your check_out does is akin to the librarian taking a black marker and writing "checked out" on the book itself.

Also lose the due date...

You are not getting it. Did you read the chapter on constructors? I didn't say anything about changing the initializer list, just change the constructor syntax, perhaps you don't know the difference,...

No, just leave it out, like you were told. You don't need to mention all the members in a constructor. It makes sense to just call patron(name, UUID) in main. Under the hood you initialize the fee to...

Library contains so much crap. It should look more like this.


private:
//transaction struct here
vector<Book> books{};
vector<Patron> patrons{};
vector<Transaction>...

Jim posted the answer in 262 and you still do it wrong...

The signature of a constructor (i.e. the parameters) need not be the same as, or even be related to the initialization list.

Sorry just checking: so the client can't declare the PIMPL class in their code if they want to use it anyway? Not saying they should, just wondering if it is possible.

Hmmm I think making library a friend of the isbn checker defeats the spec intention of separating it from library. I think a book and vector<book> parameter is ok. Though I would have made a simple...

Your update function makes a copy of the ship object, moves it, returns the copy. Since you don't store the return or overwrite the original object the object is trashed and nothing is truly updated....

You just said you're going to try using find(). As for the ISBN comparing, what syntax do you want the function to have? Should it take a vector? Variable arguments? Etc.

I'll give you a working example if you hit page 20 ;)

nothing happens to obj if you do v.push_back(obj).

no I said you already done it the moment you call add_book(). That is registering it by making a copy and storing it in your vector. Your...