Return to Answer

Problems with add:

• the while(true) is useless
• you want to notify_one, not notify_all because you've only added one thing, and so only one thread waiting to remove can remove it.
• you should overload for two version which take const T& and T&& (the latter would std::move. This would be optimal in all cases. (analogous to push_back in standard containers)
• You may also want to add an emplace to complement the add() versions so you can construct T in-place at the top of the Buffer.
• you can use lock_guard instead of unique_lock and scope it with {}s. I'd just say always prefer the lighter weight construct when a heavier weight one isn't strictly needed.

Problems with add:

• the while(true) is useless
• you want to notify_one, not notify_all because you've only added one thing, and so only one thread waiting to remove can remove it.
• you should overload for two version which take const T& and T&& (the latter would std::move). This would be optimal in all cases. (analogous to push_back in standard containers)
• You may also want to add an emplace to complement the add() versions so you can construct T in-place at the top of the Buffer.
• you can use lock_guard instead of unique_lock and scope it with {}s. I'd just say always prefer the lighter weight construct when a heavier weight one isn't strictly needed.

problems with remove:

• the while (true) is useless
• the cond var lambda can be return !buffer.empty();
• the back variable can be std::moved
• what happens if you destruct an empty Buffer while a thread is waiting on remove? That case isn't handled at all, and it's a problem
• there's no reason to notify_all in remove. Who is it notifying and why?

problems with size:

• use a lock_guard unless unique_lock is needed
• just do: std::lock_guard<std::mutex> lock{mu}; return buffer.size();

Problems with add:

• the while(true) is useless
• you want to notify_one, not notify_all because you've only added one thing, and so only one thread waiting to remove can remove it.
• you should overload for two version which take const T& and T&& (the latter would std::forward. This would be optimal in all cases.
• With perfect forwarding you may also want to add an emplace to complement the add() versions so you can construct T in-place at the top of the Buffer.
• you can use lock_guard instead of unique_lock and either let the lock cover the notify_one (cleanest code) or scope it with {}s (most optimal code)

Lots of problems with the other functions too. I'll come back and comment more later if I get a chance.

Problems with add:

• the while(true) is useless
• you want to notify_one, not notify_all because you've only added one thing, and so only one thread waiting to remove can remove it.
• you should overload for two version which take const T& and T&& (the latter would std::move. This would be optimal in all cases. (analogous to push_back in standard containers)
• You may also want to add an emplace to complement the add() versions so you can construct T in-place at the top of the Buffer.
• you can use lock_guard instead of unique_lock and scope it with {}s. I'd just say always prefer the lighter weight construct when a heavier weight one isn't strictly needed.

Problems with add:

• the while(true) is useless
• you want to notify_one, not notify_all because you've only added one thing, and so only one thread waiting to remove can remove it.
• you should overload for two version which take const T& and T&& (the latter would std::forward. This would be optimal in all cases.
• you can use lock_guard instead of unique_lock and either let the lock cover the notify_one (cleanest code) or scope it with {}s (most optimal code)

Lots of problems with the other functions too. I'll come back and comment more later if I get a chance.

Problems with add:

• the while(true) is useless
• you want to notify_one, not notify_all because you've only added one thing, and so only one thread waiting to remove can remove it.
• you should overload for two version which take const T& and T&& (the latter would std::forward. This would be optimal in all cases.
• With perfect forwarding you may also want to add an emplace to complement the add() versions so you can construct T in-place at the top of the Buffer.
• you can use lock_guard instead of unique_lock and either let the lock cover the notify_one (cleanest code) or scope it with {}s (most optimal code)

Lots of problems with the other functions too. I'll come back and comment more later if I get a chance.