| |||||||||||||
A look at C++14, part 1A look at C++14, part 1Posted Mar 30, 2013 17:46 UTC (Sat) by jwakely (subscriber, #60262)In reply to: A look at C++14, part 1 by simlo Parent article: A look at C++14, part 1
So you like new stuff, but only the stuff you want, and you don't like anything else even if other people want it. Got it.
If you don't like the new threading features don't use them. Sounds like you have no need for them, so it shouldn't be a problem for you.
(Log in to post comments)
A look at C++14, part 1 Posted Mar 31, 2013 14:06 UTC (Sun) by nix (subscriber, #2304) [Link] So you like new stuff, but only the stuff you want, and you don't like anything else even if other people want it. Got it.This should be called "the user's lament" or something: it is universal. Note that since users often don't know if they'll like something before they try it, predicting this reliably requires not only telepathy but also precognition.
A look at C++14, part 1 Posted Mar 31, 2013 20:58 UTC (Sun) by simlo (subscriber, #10866) [Link]
Before the newest C++ standeard the compiler didn't know about threading. That is it could optimize away as it wanted. Only the OS knew about threading. Now the compiler have to lay out code, which can work in a multi-threaded environment. So unless, I use non-standeard options on the compiler I can't avoid it. Of course you can say the same for exceptions.
I am not against features in libraries: Those I can simply avoid.
I do have as I mentioned above (https://lwn.net/Articles/545352/) a thing against multi threading in general. And now C++ tries to jump the wagon, too.
The good thing about C++ is that it doesn't do much opposite for instance Java. There is no standeard for GUI either. STL is a library of containers and types you can use anywhere on any OS and without an OS (except for file IO).
Of course, to make portable multi threaded programs, wrappers around the OS specific implementations where needed. But then why not wrappers for sockets, serial ports etc?
Before STL and C++ was really not about portability. There weren't even a standeard like int32_t in C++. With threading, atomic types, chrono etc. STL have been given the task of supplying portability.
The thing about threads:
What we need in general (not only C++) is _not_ more support for threading, but non-blocking APIs and a good framework for writing applications using non-blocking IO.
A look at C++14, part 1 Posted Apr 1, 2013 11:43 UTC (Mon) by jwakely (subscriber, #60262) [Link]
> Before the newest C++ standeard the compiler didn't know about threading.
Nonsense, people have been using Pthreads with C++ for decades. The *standard* didn't mention threads, but compilers live in the real world and had to deal with what programmers actually do.
You're making a silly leap from "some people don't use threads correctly" to "I wish noone was allowed to use threads." Luckily you're not actually involved in the standardisation process, you're just whining on the internet.
> What we need in general (not only C++) is _not_ more support for threading, but non-blocking APIs and a good framework for writing applications using non-blocking IO.
There are proposals to add such things to the next C++ standard, because the committee realises not everyone programs the same way and that different tools are suitable for different tasks. Maybe you would benefit from the same realisation.
A look at C++14, part 1 Posted Apr 1, 2013 15:41 UTC (Mon) by tjc (subscriber, #137) [Link]
Thanks for starting the sub-thread on multithreading. I'm not sure if I agree with you or not--I have to think about this more--but it was very interesting.
A look at C++14, part 1 Posted Apr 1, 2013 23:05 UTC (Mon) by nix (subscriber, #2304) [Link] Before the newest C++ standeard the compiler didn't know about threading. That is it could optimize away as it wanted. Only the OS knew about threading. Now the compiler have to lay out code, which can work in a multi-threaded environment.I commend to you Hans Boehm's Threads Cannot be Implemented as a Library.
|
|||||||||||||