Вы серьезно уже во всю 17 юзаете?

20 уже юзаем

Вы серьезно уже во всю 17 юзаете?

С прошлого года еще

Ну apply можно и накостылять в отдельный файлик, если у тебя древний C++14

Можно и на С++11 накостылять

Можно.

Да.

У нас просто с++11 только недавно завезли...

/* File: old cpp kludges */ namespace std { auto apply(...) { ... } }

Всегда так делаю.

Даже при наличии C++20

Ведь будет C++22!

Ведь будет C++22!

Не будет же

Разве не c++23 должен быть?

А хз.

Я юзаю C++14, потому что проект начинал ещё до выхода C++17.

А то бы юзал C++17, отчего нет? Если начальство разрешает, надо брать самое лучшее.

(ну или если ты сам и есть начальство, хе-хе)

То чувство, когда проект начинался где-то в конце 90х...

Ну, его можно и проапгрейдить.

Можно, наверн

Комитет старается специально ради тебя, чтоб тебе не было больно апгрейдиться на новые версии языка.

Но так-то я джун, я ничего не решаю.

я как-то брал древний проект виндовый и перепиливал его на c++11 - в целом изменений было не слишком много и оно даже завелось

Джун может со старшим обсудить перспективы обновления проекта, а старший уже может поднять вопрос перед теми, кто имеет решающий голос.

ну да, ну да

Мне кажется, именно в зарезервированном смысле он их и использует.

Ну то есть да, этот код *должен* сломаться, когда появится std::apply.

Комитет старается специально ради тебя, чтоб тебе не было больно апгрейдиться на новые версии языка.

Но вот с апгрейдами vs нередко всякие конфузы встречаются, независимо от пожеланий комитета

Давай, мне интересно было бы почитать.

Но вот с апгрейдами vs нередко всякие конфузы встречаются, независимо от пожеланий комитета

Ну, блин, понятное дело, что в жизни частенько бывает всякое.

Не обязательно.

С обновлением VS может обновиться много сопутствующего барахла — MFC там какой-нибудь или ATL.

А в новом ATL могут убрать или сломать фичи старого. Редко, но бывает.

(не спрашивайте, откуда я знаю)

Почему нельзя?

Как сказано было выше, оно сломается при апдейте и можно будет просто удалить свою реализацию.

кроме тех случаев когда это можно да

Формально Александр прав. Размещение пользовательского кода в std:: это плохо, в стандарте это указано.

Я уже рассказывал, что у нас в проекте было 4 весрии буста, которые потом долго и мучительно изводили? С тех пор для 3rd-party нужны веские основания

Можно завернуть в #ifdef

=)

Я уже рассказывал, что у нас в проекте было 4 весрии буста, которые потом долго и мучительно изводили? С тех пор для 3rd-party нужны веские основания

йопт

Трижды виновны, ага.

Я верю, что все три раза были какие-то причины для того, чтобы вносить такую вот дивергенцию в проект. Но это технический долг, и рано или поздно его придётся оплатить.

Появлялись не только новые баги, но и новые фичи. Фичи хотелось, а баги — нет

Формально Александр прав. Размещение пользовательского кода в std:: это плохо, в стандарте это указано.

This is one of these situations where declaring something in namespace std is legal. namespace std { template <> struct is_error_code_enum<FlightsErrc> : true_type {}; } кеке

@zamazan4ik так ты его в итоге убедил? Есть какие-то подвижки? Чего предпринимал для достижения цели?

пользовательский код в std!

@zamazan4ik так ты его в итоге убедил? Есть какие-то подвижки? Чего предпринимал для достижения цели?

А что ты тут сделаешь? Применяй инженерный подход: анализируй проблему, собирай список преимуществ и недостатков своего решения, обсуждай с руководством или коллегами.

А дальше либо вы вместе придёте к выводу, что твоё решение плохое, либо запланируете его применение.

@zamazan4ik так ты его в итоге убедил? Есть какие-то подвижки? Чего предпринимал для достижения цели?

2 сезон 1 серия "Джун против тимлида". Новые герои, новые коммиты, новые баги и фичи, чем же всё закончится?

Проблем_решено += 1;

/stat@combot

(тот же самый инженерный подход, между прочим: недостатки от нахождения на проекте перевесили преимущества)

А что ты тут сделаешь? Применяй инженерный подход: анализируй проблему, собирай список преимуществ и недостатков своего решения, обсуждай с руководством или коллегами.

Это ещё зависит от типа человека, мне благо повезло работать в коллективе без, так скажем, предвзятости в этом плане.

Ты там один чтоли его пишешь? :)

👍

победа

ну если сам с собой не можешь спорить, найди кого-нибудь!

ты ж вроде говорил что не удаётся убедить начальство на внедрение каких-то новых технологий, ибо временнОй бюджет поджимает )

а, вспомнил, там про ковыряние в CI было

ребят, а кто знает хороший парсер\билдер JSON ? Желательно плюсы.

о, уже второй раз советуют. Видимо, действительно хороший

https://github.com/miloyip/nativejson-benchmark выбирай по вкусу )

ну можешь взять dropbox/json11

rapidjson самый быстрый, но и жирноват при этом

https://github.com/miloyip/nativejson-benchmark выбирай по вкусу )

крутяк, спасибо

ну вообще, rapidjson серьёзней всех выглядит

даже модель нарисовали

ну для моих целей один хедер удобнее целой телеги которую надо отдельно собирать

ну, у меня проект под линукс. Мне только зависимости прописать

да слинковать

Люди где почитать про release sequence, тоесть почему read-modify-write после release не требует release?

Супапро не предлагать

Да был

Там написано что да read-modify-write входит в release sequence

И все

что это такое? в первые слышу

ох ебать круто

а я по старинке deb пакеты делаю

Но дебпакеты лучше же?