Сразу скажу — ничего не понимаю в разработке под Apple. Но с моей, чайниковской, колокольни — неужели в iOS нельзя зашедулить какое-то событие, которое бы запускало приложение XXX в заданный момент времени? А как же тогда работает будильник?
PS: Обычный будильник то есть в iOS? Не может быть, чтобы его не было!
Базовая станция сама по себе — вещь сравнительно простая. SX1308 + пара SX1257 и вот вам уже базовая станция. Осталось подобрать антенну и запихнуть в соответствующий корпус.
Рефакторинг — это конечно прекрасно, но с учетом отсутствия тестов провести разумный рефакторинг бывает очень сложно. Точнее провести может быть и легко. Но как проверить, что ничего не сломалось? Ведь тестов нет.
«Получили» — это наверное несколько кхм… громко сказано. Не уверен, что они — интересно а кто лично? — её эту критику вообще увидят :)
PS: Не имея ничего против статьи тем не менее автор и яндекс — они в разных лодках. Я бы даже сказал — галактиках. У них абсолютно разные цели и оценивать одно с позиции другого бессмысленно.
PSS: Разве что у автора есть какие-то свои, личные, отношения с яднексом. Не буду гадать. Тогда да, лодка таки одна.
Если мы про Россию — а мы про Россию путь даже из Москвы? — то тур в NA тем более на неделю — это какое-то самоубийство. Вы лететь/отходить будете дня три а потом сразу обратно. И нафига :-?
Два десятка тон готовой продукции в сутки — это одна-две фуры на выход. Допустим x5 на вход. Итого — ну допустим максимум 10ть фур в сутки. Очень умеренный транспортный поток.
А, вспомнил, что мне показалось таким неправильным в попытке запихнуть pthread_t куда-либо включая атомик. Даже если вы не проводите над ними арифметических операций, даже сравнивать два потока нужно не абы как но через pthread_equal()
Все остальное UB. Как эксперимент на попробовать здесь и сейчас — согласен, забавно. Но как тенденция — навряд ли.
PS: Если уж мы говорим за «на Linux» то он, родимый, по этому поводу в своем мане говорит, что:
NOTES
The pthread_equal() function is necessary because thread IDs should be considered opaque: there is no portable way for applications to directly compare two pthread_t values.
Впрочем, если pthread_t сам по себе — это указатель на структуру, код выше вполне валиден т.к. арифметических операций над ним не производится но лишь присваивание или сравнение на равенство. Хотя выглядит все равно подозрительно.
> Во первых не у меня, а у Саттера на одном из слайдов
Нет, ну если у самого Саттера то конечно да. Это весомый аргумент.
> Во вторых если мы говорим о Linux в первую очередь, то pthread_t это unsigned long int.
Как там было выше…
========
NB: Всё обсуждаемое касается разработки на C++ под Linux, но может быть применимо ко всем POSIX.1-2008 совместимым системaм (с оглядкой на конкретную реализацию).
========
Все-так скорее «Все обсуждаемое применимо сугубо для Linux и не применимо к остальным POSIX совместимым платформам» т.к. вы делаете фундаментальные допущения, которые верны и то с оговорками только для Linux.
> В третьих, сомневаюсь, что этот элемент (XBD/TC2/D6/26), в какой-либо распространнённой ОС применяется. Я-бы предположил, что в целях совместимости pthread_t в большинстве систем останется арифметическим, либо может быть имплементирован как указатель на структуру (что оставлят его арифметическим).
Неверное предположение. Первое, что приходит в голову — *BSD. Второе — почти уверен что QNX. Третье — скорее всего остальные *NIX. Сугубо для проформы:
Просто потому, что pthread_t нигде не используется по значению. Мы всегда оперируем указателем на этот тип. Детали реализации по-определению скрыты от пользователя и он не должен делать каких-либо предположений на этот счет. Как следствие, гораздо удобнее объявить его как прозрачную структуру чтобы упростить себе жизнь внутри реализации.
IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is applied, adding pthread_t to the list of types that are not required to be arithmetic types, thus allowing pthread_t to be defined as a structure.
откуда следует, что pthread_t — это не обязательно арифметический тип. Это может быть и прозрачная структура. Как следствие, попытка инициализировать её нулем некорректна.
PS: Обычный будильник то есть в iOS? Не может быть, чтобы его не было!
Да уж. Окончание — очень в тему. Бывает, нужно пару раз вляпаться, чтобы в живую оценить всю важность этого простого совета :)
PS: Интерес не праздный.
PS: Не имея ничего против статьи тем не менее автор и яндекс — они в разных лодках. Я бы даже сказал — галактиках. У них абсолютно разные цели и оценивать одно с позиции другого бессмысленно.
PSS: Разве что у автора есть какие-то свои, личные, отношения с яднексом. Не буду гадать. Тогда да, лодка таки одна.
Если мы про Россию — а мы про Россию путь даже из Москвы? — то тур в NA тем более на неделю — это какое-то самоубийство. Вы лететь/отходить будете дня три а потом сразу обратно. И нафига :-?
pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_equal.html#
Все остальное UB. Как эксперимент на попробовать здесь и сейчас — согласен, забавно. Но как тенденция — навряд ли.
PS: Если уж мы говорим за «на Linux» то он, родимый, по этому поводу в своем мане говорит, что:
NOTES
The pthread_equal() function is necessary because thread IDs should be considered opaque: there is no portable way for applications to directly compare two pthread_t values.
Нет, ну если у самого Саттера то конечно да. Это весомый аргумент.
> Во вторых если мы говорим о Linux в первую очередь, то pthread_t это unsigned long int.
Как там было выше…
========
NB: Всё обсуждаемое касается разработки на C++ под Linux, но может быть применимо ко всем POSIX.1-2008 совместимым системaм (с оглядкой на конкретную реализацию).
========
Все-так скорее «Все обсуждаемое применимо сугубо для Linux и не применимо к остальным POSIX совместимым платформам» т.к. вы делаете фундаментальные допущения, которые верны и то с оговорками только для Linux.
> В третьих, сомневаюсь, что этот элемент (XBD/TC2/D6/26), в какой-либо распространнённой ОС применяется. Я-бы предположил, что в целях совместимости pthread_t в большинстве систем останется арифметическим, либо может быть имплементирован как указатель на структуру (что оставлят его арифметическим).
Неверное предположение. Первое, что приходит в голову — *BSD. Второе — почти уверен что QNX. Третье — скорее всего остальные *NIX. Сугубо для проформы:
github.com/freebsd/freebsd/blob/master/sys/sys/_pthreadtypes.h
Просто потому, что pthread_t нигде не используется по значению. Мы всегда оперируем указателем на этот тип. Детали реализации по-определению скрыты от пользователя и он не должен делать каких-либо предположений на этот счет. Как следствие, гораздо удобнее объявить его как прозрачную структуру чтобы упростить себе жизнь внутри реализации.
Как говорится в священном писании:
Issue 6
IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is applied, adding pthread_t to the list of types that are not required to be arithmetic types, thus allowing pthread_t to be defined as a structure.
откуда следует, что pthread_t — это не обязательно арифметический тип. Это может быть и прозрачная структура. Как следствие, попытка инициализировать её нулем некорректна.
Да и вообще в общем случае завернуть её в атомик не получится по той же самой причине.