AP
тут дело не в теории, а что будет на практике?
на практике такой код работать не будет
Size: a a a
2020 July 13
AP
При том перестанет работать не сразу, в самый ответственный момент, когда начальство будет задумываться над тем, кого уволить из-за неработающего проекта
АВ
AK
Может ли поток разблокировать мьютекс, который заблокировал другой поток?
Тут скорее ответ на вопрос интересует. Последствия не важны.
VS
Тут скорее ответ на вопрос интересует. Последствия не важны.
кроссплатформенные ответы вам уже дали, а платформу и версию компилятора вы не написали
W
Может ли поток разблокировать мьютекс, который заблокировал другой поток?
Да.
в первом треде лочим, форкаемся, в дочернем анлокаемся. И получаем головную боль.
Для решения оной смотри pthread_atfork, в которую предаются обработчики, выполняемые до и после форка.
в первом треде лочим, форкаемся, в дочернем анлокаемся. И получаем головную боль.
Для решения оной смотри pthread_atfork, в которую предаются обработчики, выполняемые до и после форка.
VR
У кого-то уже есть опыт использования модулей из c++20 в продакшене?
ПК
У кого-то уже есть опыт использования модулей из c++20 в продакшене?
Модулей нет, а опыт есть? :)
VR
Модулей нет, а опыт есть? :)
Ну, вроде как 11 шланг умеет в модули уже)
AT
Ну, вроде как 11 шланг умеет в модули уже)
Кажется, он ещё только "учится":
https://clang.llvm.org/cxx_status.html
https://clang.llvm.org/cxx_status.html
AF
Переслано от Alexey Kuznetsov
Раз уж зашла речь про неймспейсы и использование unqualified имен типов подскажите у кого какие лучшие практики с nested namespaces.
Несколько раз сталкивался с такой проблемой:
Что делать в таком случае? Всегда использовать полные имена со всеми неймспейсами даже если они в родительском неймспейсе? Это плохо контроллировать, для компилятора это валидно, а переносить поддержку этого на человека и код ревью не выглядит как что-то надежное.
Не использовать nested namespaces?
Несколько раз сталкивался с такой проблемой:
// foo.hВсе прекрасно компилируется, вы получаете разные лэйауты в разных юнитах трансляции для имени foo и просто какуюто кашу в памяти в рантайме, дебажится это плохо, потому что детектится проблема неочевидно, особенно на больших кодовых базах, довольно неприятные баги.
namespace my { class foo; }
// bar.h
#include "foo.h"
namespace my::internal
{
void bar( foo& ); // << unqualified name. По задумке автора это my::foo
}
// internal/foo.h
namespace my::internal { class foo; }
// baz.cpp
#include "internal/foo.h"
#include "bar.h" // << а вот тут у нас odr-violation и my::internal::bar( foo& ) теперь принимает my::internal::foo
Что делать в таком случае? Всегда использовать полные имена со всеми неймспейсами даже если они в родительском неймспейсе? Это плохо контроллировать, для компилятора это валидно, а переносить поддержку этого на человека и код ревью не выглядит как что-то надежное.
Не использовать nested namespaces?
А bar сама по себе же не нарушение odr? Тут разные декларации, вот если это метод класса то да
AK
Функция или метод класса, резолвится оно одинаково в этом случае. Из-за того что используется неквалифицированное имя и происходит нарушение odr. Фиксится это полной квалификацией со всеми неймспейсами, просто компиляторы никак не помогают в обнаружении этого кейса, а разные тулы в духе решарпера вообще предлагают убрать неймспейсы, что собсна и приводит к таким кейсам
AF
Функция или метод класса, резолвится оно одинаково в этом случае. Из-за того что используется неквалифицированное имя и происходит нарушение odr. Фиксится это полной квалификацией со всеми неймспейсами, просто компиляторы никак не помогают в обнаружении этого кейса, а разные тулы в духе решарпера вообще предлагают убрать неймспейсы, что собсна и приводит к таким кейсам
В чем нарушение одр?
AK
в разных юнитах трансляции одно и то же имя объявляется по разному изза наличия/отсутствия инклудов
AF
в разных юнитах трансляции одно и то же имя объявляется по разному изза наличия/отсутствия инклудов
Функция не идентифицируется только именем
AF
в разных юнитах трансляции одно и то же имя объявляется по разному изза наличия/отсутствия инклудов
Да у нас контекстно зависимый язык, таких примеров бесконечно много можно придумать всех сортов
ПК
Ну, вроде как 11 шланг умеет в модули уже)
пока стандарт не выйдет, юзать что то в проде = целиться в ногу. Есть ненулевая вероятность, что на последнем заседании там найдут фатальный недостаток и выпилят полностью модули из стандарта и привет переписывание проекта на ровном месте.
ПК
с контрактами так и произошло
VR
пока стандарт не выйдет, юзать что то в проде = целиться в ногу. Есть ненулевая вероятность, что на последнем заседании там найдут фатальный недостаток и выпилят полностью модули из стандарта и привет переписывание проекта на ровном месте.
Разве с++20 не принят?
AK
Сигнатуры будут разные верно, но у меня возникала ситуация, когда для двух разных сигнатур в разных tu вызывалась одна и та же реализация в этом случае.