
Reuzel – A tiny C++ thread pool - leohotfn
https://github.com/leohotfn/Reuzel
======
usefulcat
PSA: Please don't do stuff like this in header files:

using std::string;

It's not cool to impose that decision on clients of the library.

~~~
blackflame7000
Note that this is not the same as "using namespace std;" since you are only
exporting the namespace std::string.

This should almost always be ok since no sane programmer should ever name
their class string in the namespace of std.

As a developer, I wouldn't feel too bad about causing namespace conflicts in
this manner because hopefully it will suggest to the maintainer that their
class name is a poor choice.

~~~
sclangdon
Actually, it tells the compiler that every time it comes across a class called
string that isn't fully qualified, it should use std::string. And since he's
put it in the global namespace, it will apply everywhere this header is
visible.

He really shouldn't do that in a header, but if he at least moved it down a
couple of lines so it's inside his private namespace, it at least wouldn't
affect anyone else. There is no good reason to do it globally.

~~~
blackflame7000
But that begs the question why do you have two classes named string to begin
with? The ambiguous name choice of string for an alternative to the standard
is a terrible idea and all the problems associated with it should be the
responsibility of the person making that decision. Putting using std::string
in the header would at the very least make whoever is using your class
strongly consider the necessity of 2 classes named string. They would be
forced to use the fully qualified name for their type instead of ambiguously
referring to their alternative string class as string. This prevents future
maintainers from getting confused as to why there are 2 versions of the class
string.

~~~
to3m
But "string" in std _isn 't_ ambiguous, precisely because it's in the std
namespace.

As to why a program would have two classes called string... well, there's a
funny thing there, because it _didn 't_, at least not until it started using
this library that does "using std::string" in its header...

(Anyway, why is it the library author's concern? They're writing a library!
Not only is this the tail wagging the dog, but they're actually making it
harder to use, and easier to say no to. Exactly the wrong thing.)

~~~
blackflame7000
I think we're viewing the issue from 2 different stand points. You are correct
that from a library authors perspective they shouldn't impose undue
restrictions. I was thinking more along the lines of code maintenance within
the same library module where it could be helpful to signal to others that
come along that the stl string is the expected default. I think most people
would agree that (using...) in the header is a bad idea if the header is
intended to be apart of the Public API for the library but I think its use can
be justified in a few select instances of internal headers in order to impose
cohesive coding convention.

If its my library and I don't want other maintainers adding additional string
classes internally, I can at the very least force them to use fully qualified
names for their alternative string classes to avoid ambiguity. I hate working
on code that has 5 different versions of the same freaking thing because each
developer decided to implement their own version when the standard way would
have sufficed. That was the point I was trying to make. Just like putting
const and override on functions, it's a way to help maintainers avoid doing
dumb things.

~~~
usefulcat
It kind of sounds like you're looking for technical means by which to "signal
to others". In that case, perhaps some documentation (for other
contributors/maintainers) could be of use?

Beyond that I'm not sure what to suggest. The problem is that even if you have
a Really Good Reason for what might otherwise appear to be a bit of gratuitous
incompatibility, it's rather unlikely that others will figure out what that
reason is without some explanation. IME anyway.

~~~
blackflame7000
Documentation is only good if people read it... which most developers don't.
If someone tried to make a class called string in my module, they would
receive immediate feed back from the compiler that there are now multiple
definitions of string which should tell them that they are creating another
copy of something that already exists.

Nevertheless, I'll concede that its not the best way to go about things. But
it is something you can do and I wanted to highlight a case of why a "Never do
This" feature is even allowed in the first place.

------
to3m
The C++11 thread library
([http://en.cppreference.com/w/cpp/thread](http://en.cppreference.com/w/cpp/thread))
is at least not insane, and at best you might even like it. In my view it's
certainly a better bet than pthreads, because it runs on Windows too.

~~~
JDevlieghere
Indeed, it's portable and part of the standard. Personally I'm a big fan of
this implementation:
[https://github.com/progschj/ThreadPool/](https://github.com/progschj/ThreadPool/)

~~~
gcp
Thanks, this looks a lot better than the one in the subject.

------
pacaro
Another simpleapproach to exception handling (beyond calling abort) is to
allow an exception callback to be registered. This can allow appropriate
diagnostic logging, and/or compensation

~~~
leohotfn
Thanks!

------
blackflame7000
What does this library offer over std::async?

~~~
leohotfn
What do you mean?

~~~
blackflame7000
the c++11 library std::async provides a built in mechanism for spawning
asynchronous tasks. Under the hood, std::async uses a thread pool. So I'm
asking why use this library when the stl already provides a thread-pool
mechanism?

~~~
leohotfn
I think The C++ thread library is overdesigned so it lost some function.
What's more, on Linux it's chicken ribs. So I encapsulate POSIX Threads using
C++, to take advantage of RAII.

~~~
blackflame7000
Good explanation, and frankly I agree. From looking through it, I like the
control your lib allows. If its performance is superior on Linux as you say,
nice work!

~~~
leohotfn
Thanks! BTW, the encapsulation is not finished yet, such as mutex and
condition variable. I'll go on with the work, and welcome to contribute if
you're interested!

