Будет pthreads стать устаревшим однажды std:thread превращает в [закрытого] Вола C++
Я склонен иметь методы считывания и методы set, я просто не склонен называть их "getX и "setX", обычно я буду делать что-то вроде этого, например:
int x = o->x() // getter
o->setX(5); // setter
я нахожу, что наличие метода считывания просто быть названием "свойства" просто читает лучше.
7 ответов
Си никуда не денется. POSIX никуда не денется. Многопоточный код, написанный на C для POSIX, никуда не денется. Так что pthreads никуда не денется.
Многие реализации std :: thread будут использовать pthreads под капотом.
«API Pthreads определен в стандарте ANSI / IEEE POSIX 1003.1 - 1995». - POSIX Threads Programming https://computing.llnl.gov/tutorials/pthreads/
POSIX - это стандарт операционной системы. C ++ 0X - это стандарт языка. Наличие потоков во втором не приведет к устареванию первого. Между ними существует сотрудничество, так что второе можно реализовать на первом. (Также ведется работа по созданию интерфейса C ++ для POSIX).
Реализации C ++ на платформах, поддерживающих pthreads, вероятно, будут реализовывать языковые функции в терминах pthreads - так что нет, это не будет устаревшим.
std :: thread не включает поддержку приоритетов, управление размером стека потоков, управление политикой планирования или управление сродством процессора.
Класс планирования и приоритеты имеют решающее значение для системы реального времени. Соответствие процессоров и размер стека действительно важны для высокопроизводительных систем. Такие приложения будут либо продолжать использовать собственные средства потоков, возможно, в дополнение к std :: thread, может быть, вместо std :: thread, возможно, через расширения поставщика, которые предоставляют необходимые функции вместе с std :: thread.
Независимо от технических сравнений, потребовалось почти десять лет, чтобы получить хотя бы разумно достойную поддержку C ++ 98 от всех основных платформ / поставщиков. Уже одно это гарантирует, что pthreads будут расти в 2020 году.
Возможно, для нового кода использование того, что есть в стандарте, будет правильным путем. Придется подождать и посмотреть, насколько надежны реализации в основных компиляторах. Но не будет большой пользы от преобразования существующего кода из pthreads, если он работает сейчас. Сюда входит новый код, написанный в магазине, который уже имеет большой опыт работы с pthreads.
По крайней мере, правильно для ускоряющего потока:
- Он не поддерживает параметр размера стека
- Он не поддерживает атрибут
setpshared
Так что нет ... Прежде чем API ОС можно будет считать устаревшим, нужно кое-что сделать. (и потоки BTW реализованы через pthreads)