AP
+
Попробуйте вместо value использовать declval
Попробуйте вместо value использовать declval
Size: a a a
2021 February 23
AP
test_value(std::declval<const T&>().test())
ВС
Теперь GCC собирает, и ведет себя ожидаемо, а ошибку clang я не понимаю.
https://godbolt.org/z/5Tds6z
https://godbolt.org/z/5Tds6z
Если у
c::test() убрать constexpr, то в gcc всё-равно компилится.АР
Тут спросить стоит: что вообще есть джун, а что миддл?
в самостоятельности
АР
условно миддлу можно доверить что-то сделать самому
AD
Единственное, что придумалось, требует чтобы проверяемый тип был compile-time default constructible: https://godbolt.org/z/nr9coM
ТК
Здравствуйте , подскажите пожалуйста есть видео курсы по Cmake?)
VS
Тигран Кандилян
Здравствуйте , подскажите пожалуйста есть видео курсы по Cmake?)
VS
А собщения из матрикс в телеграм не перенапрвляются?
через ботов наверняка все можно, но здесь это оффтоп
W
Andrey Davydov
Единственное, что придумалось, требует чтобы проверяемый тип был compile-time default constructible: https://godbolt.org/z/nr9coM
Благодарю за помощь.
Эх, компилтайм отладчик бы...
Эх, компилтайм отладчик бы...
ID
А собщения из матрикс в телеграм не перенапрвляются?
Пока не потерли оффтоп: https://github.com/42wim/matterbridge
AP
Благодарю за помощь.
Эх, компилтайм отладчик бы...
Эх, компилтайм отладчик бы...
W
Ух ты. Спасибо. Попробую.
AP
:)
2021 February 24
ГH
Я не изучал эту тему, у нас (ынтырпрайз лютый) серверные братья описываю все сигнатуры в xml, мы при сборке через xslt кодогенерим. Как результат, полный контроль над типом и числом аргументов. Если в сигнатуру добавили обязательный параметр - ломается билд
Может быть в 2008 году это было общепризнанной практикой (BPEL?), потому как и в моей команде практика из xml-дескрипторов через xslt генерить запросы.
Три года назад после очередного расширения клиентской базы (и внедрения JSON) система начала почихивать. После пары прототипов было решение переписать парсинг xml-дескрипторов на С++. Я сначала возмущался, что в старом проекте тесты не предусмотрены, и т.п. Постепенно допилил свою альтернативу до готовности. И сильно удивил тимлида тем, что новый проект на С++ а) однопоточный, б) довольствуется крохами ОЗУ, в) с SQL-прокси PgBouncer работает хуже, чем без него.
Три года назад после очередного расширения клиентской базы (и внедрения JSON) система начала почихивать. После пары прототипов было решение переписать парсинг xml-дескрипторов на С++. Я сначала возмущался, что в старом проекте тесты не предусмотрены, и т.п. Постепенно допилил свою альтернативу до готовности. И сильно удивил тимлида тем, что новый проект на С++ а) однопоточный, б) довольствуется крохами ОЗУ, в) с SQL-прокси PgBouncer работает хуже, чем без него.
AS
Может быть в 2008 году это было общепризнанной практикой (BPEL?), потому как и в моей команде практика из xml-дескрипторов через xslt генерить запросы.
Три года назад после очередного расширения клиентской базы (и внедрения JSON) система начала почихивать. После пары прототипов было решение переписать парсинг xml-дескрипторов на С++. Я сначала возмущался, что в старом проекте тесты не предусмотрены, и т.п. Постепенно допилил свою альтернативу до готовности. И сильно удивил тимлида тем, что новый проект на С++ а) однопоточный, б) довольствуется крохами ОЗУ, в) с SQL-прокси PgBouncer работает хуже, чем без него.
Три года назад после очередного расширения клиентской базы (и внедрения JSON) система начала почихивать. После пары прототипов было решение переписать парсинг xml-дескрипторов на С++. Я сначала возмущался, что в старом проекте тесты не предусмотрены, и т.п. Постепенно допилил свою альтернативу до готовности. И сильно удивил тимлида тем, что новый проект на С++ а) однопоточный, б) довольствуется крохами ОЗУ, в) с SQL-прокси PgBouncer работает хуже, чем без него.
Это здравый смысл. Необходимость. Если мы хотим синхронизировать изменения в клиенте и сервере, мы должны связать их общим формальным описанием, по которому идет кодогенерация. Примеры: protobuf, openapi и т.п. Мы используем описание сигнатур в xml и генерим клиентские код и серверные стабы
MK
Я как-то жил в проекте, где формальным описанием была книга (до RFC не дотянули, но суть дела это не меняет). RFC и интеграционное тестирование работало не плохо (хотя, потом все же постепенно перешли к код-генераторам).
MK
Но это был не «кровавый Энтерпрайз» а интернет (уровня ответственности IETF)
AS
Реализация стандарта и ежедневное изменение протокола - суть разные процессы, требующие разных подходов. Но туже кодогенерацию делают и для стандартов. Взять теже RFC в части PKI: там формальные описания ASN.1 никто уже руками не реализует.