Забавынй факт если задуматься — MacOS 10.6 уже считается лохматой древностью и почти никто ее не поддерживает, хотя вышли они почти одновременно с Windows 7 =)
У MS гораздо более длинный «хвост» поддержки…
Да, пересылки как таковой нет, есть кхм, «отправка ссылки» на сообщение в другом канале.
Исходники открыты, по идее можно запилить фичу форматирования по типу цитаты, архитектурных ограничений я не вижу. Но у меня пока времени нет этим заняться.
Тоже не понял, что там не так с мобильными клиентами.
Мы недавно анализировали у себя минусы после перехода — помимо всяких мелкких неудобств, типа отсутствие интеграции с доменом — отсутствие форвардинга сообщений как в телеге/скайпе. Этого правда не хватает. Ну звонки еще да, только через сторонний сервис.
Самое главное даже не то что бесплатный, а то что self-hosted, не надо думать, что он там будет заблокирован/вендор забьет на сервера и тп. Ну и работа во внутренней сети тоже неплохо)
subtree сильно хуже, когда есть несколько слабо зависимых команд и надо периодически между ними синхронизировать код.
сабмодули позволяют грубо говоря всегда иметь точно ту же самую версию кода.
subtree в принципе может быть вариантом, если конкретный репозиторий всегда меняет ровно одна команда и никакая другая (так что конфликты исключены). Иначе — не в ту сторону решенный конфликт является багом замедленного действия (который ты не выявишь diff-ом, ибо дифф-то и должен быть в ситуации правок с нескольких источников).
Переходили с subtree на submodule пару лет назад. Сперва было больно, а потом ничего, понравилось. Из плюсов — быстрая синхронизация кода (и предсказуемая)
из минусов — надо всегда держать в голове, какие коммиты ты должен сохранить и не ребейзить (обычно это все release/* ветки, но бывают исключения).
Мне они нравятся из-за какой-то своей ODR-ности, что ли.
В один репозиторий 10-15 сабмодулей подключается если что.
Цитата хорошая, но что если библиотека хорошая, проверенная, но:
а) мне уже не нужна совместимость с Win 95, OS/2, и что там еще в библиотеке осталось;
б) код который хорошо работал с устройствами на Win2000 как-то криво работает на Windows 10
в) автор свою разработку забросил лет 10 назад
Вроде как там есть и куча накопленного багажа, но надо четко оценивать насколько он применим и нужен нам.
А так да, даже std::variant в C++ человек опытный скорее всего не повторит корректно
Как бы появлялись существующие решения, если бы не было велосипедистов?
Ну из определения «велосипеда» (изобретения того, что уже есть), самая первая версия велосипедом не являлась.
Обычно так говорят все же о проектах, которых, ну прям ОЧЕНЬ много видов уже написано. Например, не знаю, какой-нибудь сишной либы конвертации utf* туда-обратно.
Вот как раз о таких вещах говорят «нет смысла изобретать велосипед».
А когда на рынке 1-2 библиотеки, и одна не подходит по лицензии, вторая по функциональности… что плохого написать третью?
(вещи связанные с безопасностью, конечно отдельная тема. я в основном про библиотеки общего назначения)
Простите, а что такое размер? площадь или население?
Количество ресурсов — ну это может только в случае довольно больших территорий, да и то спорно, ресурсы КРАЙНЕ неравномерно распределены.
Я если честно не понимаю и Араса, и Бен Дина по поводу некоторых пунктов:
— Комитет С++ вообще никак не занимается вопросами оптимизации инструментов (и инструментами), как и вопросами «как нам сделать чтобы в дебаге код был быстрый».
Имхо, если кому-то это важно, пусть пинают вендора, чтобы запилил в библиотеке флаг, с которым в начале включается pragma optimize, а в конце — выключается.
Я лично частенько отлаживаю код в релизе, если мне нужна прям хорошая работа отладчика со всем стеком в конкретном файле, я добавляю сразу после инклюдов подавление оптимизации (работает для MSVC и clang по крайней мере).
В общем, как там релизную сборку отлаживать — это точно мимо. Мимо и комитета, и мимо претензий к языку
— следующее, про скорость сборки. Тут половина в целом по делу, как не оптимизируй, какие-то вещи тупо алгоритмически сложные. Но! Я заметил некоторую общую претензию и к реализации Ranges, и к Boost, мол это монструозно и т.п.
Boost — стремится быть в первую очередь портируемым. никакой цели оптимизировать скорость сборки там точно нет. Ну и для меня это скорее как такая площадка использовать заранее то, чего пока нет в стандарте:
1. Boost, медленно собирается, немножко багов
2. --smth-ts, experimental/ — собирается уже быстро, т.к. привязано к конкретной платформе, багов +- (скорее всего нет платформоспецифичных, но потенциально могут быть в другой логике)
3. std — и быстро, и с минимумом багов. (возможно в качестве бонуса еще с урезанным функционалом по сравнению с Boost, правда).
Я это очень грубо, понято, что наверное можно найти и контрпримеры. Но я к тому, что используя Boost ты сразу соглашаешься что сборка будет медленной.
Собственно, я полагаю, если вместо вот этой жести github.com/ericniebler/range-v3/blob/master/include/meta/meta.hpp
будет специфичная для современного компилятора реализация на constexpr-ах, то все это будет сильно быстрее (constexpr everything тренд).
ну и вообще не понимаю оправданий «отладка STL тормозит» — «ну так надо, это цена которую ты платишь за абстракции» — КАТЕГОРИЧЕСКИ против такого подхода, идеология С++ — «не платишь за то, что не используешь». Собственно, если мне не надо отлаживать STL, я не должен за него платить.
Блин, вот я совсем не рассеянный, (за время учебы у меня была одна единственная флешка на 4 Гб, которую я не потерял и не сломал), но вот ни разу в голову не приходило что-то хранить на ней важное в единственном экземпляре. Да будь эта флешка с рейдом и с защитой от восстановления, ну и что, я МОГУ ее потерять, я МОГУ ее сломать, её МОГУТ украсть (у одногруппников флешки пропадали оставленные на парте в аудиотории во время перерыва).
Общее правило не то что не хранить важные данные на флешке, а не хранить «в одной корзине», что вы собственно и упомянули про бекапы и облако.
Моя память говорит что было 50 баллов. Я если честно, больше 20-25 даже не пытался решать) ну и да, я даже первый том не осилил (бросил может где-то на трети или четверти, не помню). Не стыжусь и не жалею.
У MS гораздо более длинный «хвост» поддержки…
тут можно сгенерировать сразу готовый ответ по рандому, в большинстве случаев сразу подходит.
Исходники открыты, по идее можно запилить фичу форматирования по типу цитаты, архитектурных ограничений я не вижу. Но у меня пока времени нет этим заняться.
Мы недавно анализировали у себя минусы после перехода — помимо всяких мелкких неудобств, типа отсутствие интеграции с доменом — отсутствие форвардинга сообщений как в телеге/скайпе. Этого правда не хватает. Ну звонки еще да, только через сторонний сервис.
вот как раз в емейл-рассылке QtC сейчас эту тему активно обсуждают, кстати.
сабмодули позволяют грубо говоря всегда иметь точно ту же самую версию кода.
subtree в принципе может быть вариантом, если конкретный репозиторий всегда меняет ровно одна команда и никакая другая (так что конфликты исключены). Иначе — не в ту сторону решенный конфликт является багом замедленного действия (который ты не выявишь diff-ом, ибо дифф-то и должен быть в ситуации правок с нескольких источников).
из минусов — надо всегда держать в голове, какие коммиты ты должен сохранить и не ребейзить (обычно это все release/* ветки, но бывают исключения).
Мне они нравятся из-за какой-то своей ODR-ности, что ли.
В один репозиторий 10-15 сабмодулей подключается если что.
а) мне уже не нужна совместимость с Win 95, OS/2, и что там еще в библиотеке осталось;
б) код который хорошо работал с устройствами на Win2000 как-то криво работает на Windows 10
в) автор свою разработку забросил лет 10 назад
Вроде как там есть и куча накопленного багажа, но надо четко оценивать насколько он применим и нужен нам.
А так да, даже std::variant в C++ человек опытный скорее всего не повторит корректно
Ну из определения «велосипеда» (изобретения того, что уже есть), самая первая версия велосипедом не являлась.
Обычно так говорят все же о проектах, которых, ну прям ОЧЕНЬ много видов уже написано. Например, не знаю, какой-нибудь сишной либы конвертации utf* туда-обратно.
Вот как раз о таких вещах говорят «нет смысла изобретать велосипед».
А когда на рынке 1-2 библиотеки, и одна не подходит по лицензии, вторая по функциональности… что плохого написать третью?
(вещи связанные с безопасностью, конечно отдельная тема. я в основном про библиотеки общего назначения)
Количество ресурсов — ну это может только в случае довольно больших территорий, да и то спорно, ресурсы КРАЙНЕ неравномерно распределены.
— Комитет С++ вообще никак не занимается вопросами оптимизации инструментов (и инструментами), как и вопросами «как нам сделать чтобы в дебаге код был быстрый».
Имхо, если кому-то это важно, пусть пинают вендора, чтобы запилил в библиотеке флаг, с которым в начале включается pragma optimize, а в конце — выключается.
Я лично частенько отлаживаю код в релизе, если мне нужна прям хорошая работа отладчика со всем стеком в конкретном файле, я добавляю сразу после инклюдов подавление оптимизации (работает для MSVC и clang по крайней мере).
В общем, как там релизную сборку отлаживать — это точно мимо. Мимо и комитета, и мимо претензий к языку
— следующее, про скорость сборки. Тут половина в целом по делу, как не оптимизируй, какие-то вещи тупо алгоритмически сложные. Но! Я заметил некоторую общую претензию и к реализации Ranges, и к Boost, мол это монструозно и т.п.
Boost — стремится быть в первую очередь портируемым. никакой цели оптимизировать скорость сборки там точно нет. Ну и для меня это скорее как такая площадка использовать заранее то, чего пока нет в стандарте:
1. Boost, медленно собирается, немножко багов
2. --smth-ts, experimental/ — собирается уже быстро, т.к. привязано к конкретной платформе, багов +- (скорее всего нет платформоспецифичных, но потенциально могут быть в другой логике)
3. std — и быстро, и с минимумом багов. (возможно в качестве бонуса еще с урезанным функционалом по сравнению с Boost, правда).
Я это очень грубо, понято, что наверное можно найти и контрпримеры. Но я к тому, что используя Boost ты сразу соглашаешься что сборка будет медленной.
Собственно, я полагаю, если вместо вот этой жести
github.com/ericniebler/range-v3/blob/master/include/meta/meta.hpp
будет специфичная для современного компилятора реализация на constexpr-ах, то все это будет сильно быстрее (constexpr everything тренд).
ну и вообще не понимаю оправданий «отладка STL тормозит» — «ну так надо, это цена которую ты платишь за абстракции» — КАТЕГОРИЧЕСКИ против такого подхода, идеология С++ — «не платишь за то, что не используешь». Собственно, если мне не надо отлаживать STL, я не должен за него платить.
Блин, вот я совсем не рассеянный, (за время учебы у меня была одна единственная флешка на 4 Гб, которую я не потерял и не сломал), но вот ни разу в голову не приходило что-то хранить на ней важное в единственном экземпляре. Да будь эта флешка с рейдом и с защитой от восстановления, ну и что, я МОГУ ее потерять, я МОГУ ее сломать, её МОГУТ украсть (у одногруппников флешки пропадали оставленные на парте в аудиотории во время перерыва).
Общее правило не то что не хранить важные данные на флешке, а не хранить «в одной корзине», что вы собственно и упомянули про бекапы и облако.