21–29 of 29 posts
The C++11 thread library ( 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.
Earlier quoted context omitted.
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…
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…
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.
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
What does this library offer over std::async?
What does this library offer over std::async?
What do you mean?
Earlier quoted context omitted.
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…
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 r…
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.
Earlier quoted context omitted.
What do you mean?
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?
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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.
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!