Как мы перевели 10 миллионов строк кода C++ на стандарт C++14 (а потом и на C++17)

    Некоторое время назад (осенью 2016), при разработке очередной версии технологической платформы 1С:Предприятие внутри команды разработки встал вопрос о поддержке нового стандарта C++14 в нашем коде. Переход на новый стандарт, как мы предполагали, позволил бы нам писать многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода. И в переводе вроде бы нет ничего экстраординарного, если бы не масштабы кодовой базы и специфические особенности нашего кода.

    Для тех кто не знает, 1С:Предприятие – это среда для быстрой разработки кросс-платформенных бизнес-приложений и runtime для их выполнения в разных ОС и СУБД. В общих чертах в состав продукта входят:


    Мы стараемся по максимуму писать один код для разных ОС — кодовая база сервера общая на 99%, клиента — примерно на 95%. Технологическая платформа 1С:Предприятие преимущественно написана на C++ и ниже приведены приблизительные характеристики кода:

    • 10 миллионов строк С++ кода,
    • 14 тысяч файлов,
    • 60 тысяч классов,
    • полмиллиона методов.

    И все это хозяйство надо было перевести на C++14. О том, как мы это делали и с чем столкнулись в процессе, мы сегодня и расскажем.

    image

    Дисклеймер


    Все написанное ниже о медленной/быстрой работе, (не)большом потреблении памяти реализациями стандартных классов в различных библиотеках означает одно: это справедливо ДЛЯ НАС. Вполне возможно, для ваших задач стандартные реализации подойдут наилучшим образом. Мы же отталкивались от своих задач: брали типичные для наших клиентов данные, прогоняли на них типичные сценарии, смотрели на быстродействие, объем потребляемой памяти и т.п., и анализировали – устраивают ли нас и наших клиентов такие результаты или нет. И поступали в зависимости от.

    Что у нас было


    Изначально мы писали код платформы 1С:Предприятие 8 на Microsoft Visual Studio. Проект начался в начале 2000-х и у нас была версия только под Windows. Естественно, с тех пор код активно развивался, многие механизмы были полностью переписаны. Но код писался по стандарту 1998 года, и правые угловые скобки у нас были разделены пробелами, чтобы успешно проходила компиляция, вот так:
    vector<vector<int> > IntV;

    В 2006 году, с выходом версии платформы 8.1, мы начали поддерживать Linux и перешли на стороннюю стандартную библиотеку STLPort. Одной из причин перехода была работа с широкими строками. В нашем коде мы повсеместно используем std::wstring, основанный на типе wchar_t. Его размер в Windows 2 байта, а в Linux по умолчанию 4 байта. Это приводило к несовместимости наших бинарных протоколов между клиентом и сервером, а также различных персистентных данных. Опциями gcc можно указать, чтобы размер wchar_t при компиляции был тоже 2 байта, но тогда об использовании стандартной библиотеки от компилятора можно позабыть, т.к. она использует glibc, а та в свою очередь скомпилирована под 4-байтный wchar_t. Другими причинами были более качественная реализация стандартных классов, поддержка хеш-таблиц и даже эмуляция семантики перемещения внутри контейнеров, которой мы активно пользовались. И еще одной причиной, как говорится last but not least, была производительность строк. У нас был свой класс для строк, т.к. у нас в силу специфики нашего софта строковые операции используются очень широко и для нас это критично.

    Наша строка основана на идеях оптимизации строк, высказанных ещё в начале 2000-х Андреем Александреску. Позднее, когда Александреску работал в Facebook, с его подачи в движке Facebook была использована строка, работающая на схожих принципах (см. библиотеку folly).

    В нашей строке использовались две основные технологии оптимизации:

    1. Для коротких значений используется внутренний буфер в самом объекте строки (не требующий дополнительной аллокации памяти).
    2. Для всех остальных используется механика Copy On Write. Значение строки хранится в одном месте, при присвоении/модификации используется счетчик ссылок.

    Чтобы ускорить компиляцию платформы, мы исключили из своего варианта STLPort реализацию stream (который мы не использовали), это дало нам ускорение компиляции примерно на 20%. Впоследствии нам пришлось ограниченно использовать Boost. Boost активно использует stream, в частности, в своих сервисных API (например, для логирования), поэтому нам приходилось модифицировать его, исключая из него использование stream. Это, в свою очередь, затрудняло нам переход на новые версии Boost.

    Третий путь


    При переходе на стандарт C++14 мы рассматривали такие варианты:

    1. Поднимать модифицированный нами STLPort на стандарт C++14. Опция очень непростая, т.к. поддержка STLPort была прекращена в 2010 году, и поднимать весь его код нам пришлось бы самостоятельно.
    2. Переход на другую реализацию STL, совместимую с C++14. Крайне желательно, чтобы эта реализация была под Windows и Linux.
    3. Использовать при компиляции под каждую ОС встроенную в соответствующий компилятор библиотеку.

    Первый вариант был отвергнут сразу из-за слишком большого объема работ.

    Мы некоторое время думали над вторым вариантом; в качестве кандидата рассматривали libc++, но он на тот момент не работал под Windows. Чтобы портировать libc++ на Windows, пришлось бы проделать немало работы — например, писать самим всё, что связано с потоками, синхронизацией потоков и атомарностью, поскольку в libc++ в этих областях использовалось POSIX API.

    И мы выбрали третий путь.

    Переход


    Итак, нам предстояло заменить использование STLPort на библиотеки соответствующих компиляторов (Visual Studio 2015 для Windows, gcc 7 для Linux, clang 8 для macOS).

    К счастью, наш код писался в основном по гайдлайнам и не использовал всяческие хитрые трюки, так что миграция на новые библиотеки протекала сравнительно гладко, с помощью скриптов, заменяющих в исходных файлах имена типов, классов, неймспейсов и инклюдов. Миграция затронула 10 000 исходных файлов (из 14 000). wchar_t заменялся на char16_t; мы решили отказаться от использования wchar_t, т.к. char16_t на всех ОС занимает 2 байта и не портит совместимость кода между Windows и Linux.

    Не обошлось без небольших приключений. Например, в STLPort итератор можно было неявно скастить к указателю на элемент, и в некоторых местах нашего кода это использовалось. В новых библиотеках так делать было уже нельзя, и эти места приходилось анализировать и переписывать вручную.

    Итак, миграция кода закончена, код компилируется для всех ОС. Настало время тестов.

    Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.

    Также вскрылась интересная особенность реализации контейнеров во встраиваемых библиотеках: пустые (без элементов) std::map и std::set из встроенных библиотек аллоцируют память. А у нас в силу особенностей реализации в некоторых местах кода создается довольно много пустых контейнеров этого типа. Аллоцируют стандартные контейнеры памяти немного, для одного корневого элемента, но для нас это оказалось критичным – на ряде сценариев у нас ощутимо упала производительность и выросло потребление памяти (по сравнению с STLPort). Поэтому мы заменили в нашем коде эти два типа контейнеров из встроенных библиотек на их реализацию от Boost, где эти контейнеры не имели такой особенности, и это решило проблему с замедлением и повышенным потреблением памяти.

    Как часто бывает после масштабных изменений в больших проектах, первая итерация исходников работала не без проблем, и тут нам сильно пригодились, в частности, поддержка отладочных итераторов в Windows-реализации. Шаг за шагом мы двигались вперед, и к весне 2017 (версия 8.3.11 1С:Предприятия) миграция была завершена.

    Итоги


    Переход на стандарт С++14 занял у нас около 6 месяцев. БОльшую часть времени над проектом работал один (но очень высококвалифицированный) разработчик, а на финальной стадии подключились представители команд, ответственных за конкретные области — UI, кластер серверов, средства разработки и администрирования и т.д.

    Переход сильно упростил нам работу по миграции на новейшие версии стандарта. Так, версия 1С:Предприятие 8.3.14 (в разработке, релиз запланирован на начало следующего года) уже переведена на стандарт С++17.

    После миграции у разработчиков появилось больше возможностей. Если раньше у нас была своя доработанная версия STL и один неймспейс std, то теперь у нас в неймспейсе std находятся стандартные классы из встроенных библиотек компилятора, в неймспейсе stdx – наши, оптимизированные для наших задач строки и контейнеры, в boost – свежая версия boost. И разработчик использует те классы, которые оптимально подходят для решения его задач.

    Помогает в разработке также и «родная» реализация конструкторов перемещения (move constructors) для ряда классов. Если у класса есть конструктор перемещения и этот класс помещается в контейнер, то STL оптимизирует копирование элементов внутри контейнера (например, когда контейнер расширяется и надо изменить capacity и реаллоцировать память).

    Ложка дегтя


    Самое, пожалуй, неприятное (но не критичное) последствие миграции — мы столкнулись с увеличением объема obj-файлов, и полный результат билда со всеми промежуточными файлами стал занимать по 60 – 70 Гб. Такое поведение связано с особенностями современных стандартных библиотек, ставших менее критично относиться к объему генерируемых служебных файлов. Это не влияет на работу скомпилированного приложения, но доставляет ряд неудобств в разработке, в частности, увеличивает время компиляции. Повышаются также требования к свободному месту на диске на билдовых серверах и на машинах разработчиков. Наши разработчики параллельно работают над несколькими версиями платформы, и сотни гигабайт промежуточных файлов иногда создают трудности в работе. Проблема неприятная, но не критичная, ее решение мы пока отложили. Как один из вариантов ее решения рассматриваем технику unity build (ее, в частности, использует Google при разработке браузера Chrome).

    54,00

    Мы делаем средства разработки бизнес-приложений

    Поделиться публикацией

    Похожие публикации

    Комментарии 171
      –14
      А какой смысл в переводе всего кода проекта на новый стандарт?
        +23

        Начиная от использования новых возможностей языка, заканчивая нежеланием разработчиков всю жизнь возиться с языком (и костылями) двадцатилетней давности

          +2
          Атом углерода вообще устроен по принципам чёрт знает скольки летней давности, но вы же не пытаетесь слезть с углеродной жизни.
            +17

            Ну так вариантов-то нету, апдейтов миллиарды лет не было

              0
              Иногда мержится в гелий.
              +2
              А ты ж поди разбери весь этот легаси.
                +4
                Уж несколько десятилетий медленно, но упорно ползём на кремний.
                  +6
                  Еду, вполне себе сделанную из того же углерода, вы, однако, не захотите есть после истечения срока годности.
                    +6
                    Атом углерода работает на bleeding edge квантовой физики. Как только выпускают обновление квантовой физики, он автоматически на неё переходит.

                    После того, как релизнут теорию струн, он автоматически спортируется на теорию струн (это show-stopper для теории струн).
                      0

                      .

                      +1
                      сначала бы разобраться, что такое время…
                      по идее нету там никаких миллиардов
                        0
                        Было бы интересно, что вы порекомендуете почитать на этот счёт.
                        0
                        Двоичное представление всего в компах, тоже осталось неизменным со времён рождения. И да, с этой конструкции тоже никто слезть не может
                      +4
                      В процессе переписывания можно кучу багов наплодить. Не всё так однозначно, всё же.
                        +3

                        А можно ещё и отловить много старых и пофиксить.

                    +4
                    В статье мы старались описать — почему и зачем переводили.
                    Возможно, не вполне удачно?

                    Переход на новый стандарт, как мы предполагали, позволил бы нам писать многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода.

                    И мы не ошиблись.

                    См. также раздел «Итоги» статьи, в частности
                    После миграции у разработчиков появилось больше возможностей. Если раньше у нас была своя доработанная версия STL и один неймспейс std, то теперь у нас в неймспейсе std находятся стандартные классы из встроенных библиотек компилятора, в неймспейсе stdx – наши, оптимизированные для наших задач строки и контейнеры, в boost – свежая версия boost. И разработчик использует те классы, которые оптимально подходят для решения его задач.

                      0
                      А если старый код остаётся в неизменном виде, но его изменение при поддержке и доработке производятся с применением новых возможностей? Приводит ли такой подход к каким-то затруднениям?
                        +6
                        Да, приводит — новые версии компиляторов могут перестать (и перестают) компилировать код, написанный по старым стандартам :(
                        Использовать новые возможности, имея часть кода в старом стандарте, часто очень затруднительно, а иногда просто невозможно.
                          0
                          Да, приводит — новые версии компиляторов могут перестать (и перестают) компилировать код, написанный по старым стандартам :(

                          Вы всерьёз с этим сталкивались?


                          Не, я тоже могу с этим столкнуться, если очень захочу, но в среднем комитет по стандартизации очень успешно решает проблему обратной совместимости.

                            +2
                            Не знаю, как там у 1с, но когда я переводил один свой проект (наука, консольное приложение), то переключение на c++11 привело к ошибкам при компиляции старого кода, потребовались исправления, прежде чем оно завелось. И, хуже того, если я не путаю, были места, которые компилировались, но привели к другому поведению.
                            С другой стороны, после того, как оно завелось, дало сразу процентов 20 прироста производительности.
                              0
                              Дабы точно уточнить: вы взяли тот же компилятор той же версии, но просто поменяли флаг стандарта, или это было параллельно со сменой компилятора?
                                +1
                                Компилятор той же версии.
                                Или даже несколько компиляторов той же версии (зависит от машины)
                                Сейчас уже не восстановлю детали, но ломалось именно из-за флага стандарта.
                                  +2
                                  Жаль, что восстановить не удастся, мне было бы действительно очень интересно столкнуться с подобным в реальном коде.
                                0
                                И, хуже того, если я не путаю, были места, которые компилировались, но привели к другому поведению.
                                Вот тут важный вопрос: они привели к другому поведению из-за изменения стандарта, или там изначально было undefined behavior, и то что оно раньше работало лишь результат чистого везения?
                                  0
                                  Пытался сейчас найти по логу коммитов. Наверное, все-таки undefined. Но не в привычном смысле «работает или крашится», а в том, что там изменялся порядок разрешения некоторых соотношений, что в определенных примерах привело к провалу производительности, и пришлось вводить уже конкретику.
                        0

                        Я уже 100 лет не писал на C++, но вот такой вопрос: использование char16_t не добавит головной боли пользователям, если вдруг им понадобится вбивать имена или названия на китайском, лаосском, кхмерском и прочих экзотических алфавитах?

                          +2
                          Не добавит, у нас уже есть внедрения на языках, которые не влезают в 2 байта (китайский, вьетнамский).
                            +2
                            И что в этом случае происходит? Нельзя ввести символ, или символ занимает два char16_t?
                              +2
                              Символ занимает два char16_t, как и положено по стандарту unicode для utf-16.
                                0
                                А почему решили не переходить на UTF-8?
                                  0
                                  Видимо, по той же причине, почему и Microsoft в свое время выбрала UTF-16 для большинства внутренних представлений строк.

                                  UTF-8 дает универсальность, а UTF-16 — скорость обработки. Для 1С скорость обработки оказалась в приоритете.
                                    0
                                    Универсальность дают обе кодировки, а скорость обработки латинских символов у UTF-8 выше. Сказался тут, видимо, целевой рынок. Основной массив текстов в самом 1С (и его базах) — на русском и обработка русского языка в UTF-16 и правда будет быстрее. Что двигало майкрософтом — черт его знает, точно не то, что Linux-миром.
                                      +1
                                      Сказалась история. Когда «гранды» (MS, IBM и т.д.) переходили на юникод, он вмещался в 16 бит. А потом стало поздно.
                            0
                            Китайский алфавит в основном влезает в 2 байта. Больше 2 байт требует всякая экзотика, исторические виды письменности, а также эмотиконы. Вот с ними у 1С могут быть проблемы, если она не поддерживает суррогатные пары (кодирование символа в виде пары 2-байтных «символов» UTF-16).
                            +1
                            Две вещи выглядят не логично:
                            1. Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.
                            2. Если вы уже пришли к использованию компилятора GCC для Linux, то как же вас угораздило продолжить компилировать в VS2005 под Win?? Вы же могли компилировать под обе платформы используя одну версию GCC. Сколько головной боли ушло бы с упразднением третьего компилятора, 2 против 3.
                              +9
                              1. 4 байт на один символ это слишком большой оверхид для наших приложений. У нас очень много строк живут в памяти и они могут занимать существенный процент от общего потребления
                              2. Visual C++ это до сих пор наилучший выбор при компиляции под Windows. GCC не обеспечивает инфраструктуру для продуктивной и комфортной работы под Windows.
                                +1
                                1. Возможно… здесь вам точно виднее.
                                2. Я, разумеется, снимаю шляпу перед вашим профессионализмом, и вашего главного специалиста по С++, которого вы упомянули вначале статьи, но, по-моему, тут имеет место заблуждение…

                                В IDE Visual Studio (как инфраструктуре для продуктивной и комфортной работы) вы можете использовать любой компилятор, и CLang и GCC и MSVC.
                                Но начиная с C++11 GCC "превосходит любую доступную версию MSVC по качеству сгенерированного кода", это очевидная аксиома… Плюс именно своевременная и грамотная поддержка новых стандартов C++ и является главной вишенкой на GCC, как не парадоксально это бы ни звучало (мол как сам Microsoft может запаздывать со своим же компилятором!? Вот так и может и завидно регулярно.).

                                Но тут, разумеется, вопрос не в убеждениях. Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC, да еще для такого мега-кроссплатформенного национального проекта… как-то это не современно, на мой взгляд.
                                  +7
                                  Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC

                                  А где в статье сказано про веру? ;)
                                  MSVC был выбран по объективным причинам.
                                  Одна из основных причин — отладочная информация и отладчик. GCC не умеет генерировать полноценные pdb чтобы использовать отладчик из Visual Studio или WinDBG. И при этом не имеет отладчика под Windows. Далее, все остальные инструменты под Windows, профилировщики и прочее работают только с pdb.

                                  То же самое относится и к clang.

                                  Качество сгенерированного кода msvc нас устраивает более чем, для нашей кодовой базы оно даже в каких-то случаях лучше, нежели в gcc под Linux.
                                    +1
                                    Вот тут ответ ваш не понятен, очень хотелось бы поподробнее.
                                    В чем именно неполноценность генерации pdb в GCC? Если может помните на вскидку, вот прямо пример, что такого вам не выгрузил в pdb GCC 7?

                                    Насколько я помню, время проприетарного PDB от Microsoft и форматов STABS или DWARF-2 от GNU tools прошло году эдак в 2010.
                                    Сейчас GCC выдает стандартный PDB, а для любых сред, кроме Win, по сути дела всегда применяется отладчик GDB.

                                    Для VisualStudio, пожалуйста, используйте WinGDB, уже стало классикой, по-моему.
                                    У JetBrains свой встроенный GUI для GDB.

                                    Из таблицы хорошо видно, что если закрыть глаза на CLang (тут я, увы, не специалист), то вы могли вообще для всех сред использовать одну единственную среду разработки с одним компилятором и отладчиком. Да вы просто могли поднять уровень разработки на уровень БОГ! в плане унификации))
                                    image
                                    И если в очередном C++, например, меняется реализация std::map, и единственный компилятор GCC начинает с ключом оптимизации __attribute__((optimize(«O3»))) аллоцировать память, а без ключа — нет, то это поведение становится ПРЕДСКАЗУЕМО для всех платформ, под которые вы работаете.
                                      +9
                                      PDB до сих пор закрытый формат Microsoft (без документации) и его в полном объеме не умеет генерировать ни gcc, ни clang, насколько нам известно. Хотя подвижки есть, и Microsoft выкладывала хедера по структуре PDB файлов на github.

                                      Отладчик Visual Studio является основным инструментом под Windows для нас и тут мы наталкиваемся на проблемы с поддержкой pdb.

                                      Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.
                                        0
                                        Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.

                                        смотря что называть под средой. IDE — да, реально. Весь тулкит (включая отладчики/компиляторы) — вряд ли, но ситуация уже лучше, чем 10-20 лет назад.
                                        +2
                                        Gcc генерирует отладочную информацию в формате DWARF. Майкрософтовские инструменты, включая VisualStudio, WinDBG, DrWatson (хрень, которая показывается при падении программы и предлагает отправить отчет об ошибке) используют формат CodeView в контейнере PDB.

                                        Хорошая новость — в clang сделали пробную версию генератора PDB, не без помощи Майкрософт, открывшей информацию по PDB. Но все это пока на ранней стадии.

                                        Мне конечно использование gcc/mingw тоже нравится больше. Ими можно компилировать из-под линукса, из разных автоматизированных систем, итд.

                                        Если у вас есть много свободного времени, вы можете расковырять генератор PDB от clang и прикрутить его к gcc для решения проблемы отладки.
                                          +7
                                          Если у вас есть много свободного времени, вы можете расковырять генератор PDB от clang и прикрутить его к gcc для решения проблемы отладки.

                                          А можно просто компилировать под MSVC и свободное время потратить на что-то более приятное :) Что, видимо, 1С и делает.

                                          0
                                          При такой унификации есть риск слишком сильно привязаться к особенностям конкретного компилятора. А потом, при переходе на новую версию компилятора (или на другой компилятор), могут возникнуть проблемы.
                                          Лучше с самого начала не закладываться на особенности компилятора, не создавать технический долг, который рано или поздно придётся выплачивать.
                                          0
                                          есть конвертер из dwarf в pdb:
                                          github.com/rainers/cv2pdb
                                          уже давно использую его чтобы выводить красивый стектрейс через dbghelp
                                          +2
                                          Плюс именно своевременная и грамотная поддержка новых стандартов C++ и является главной вишенкой на GCC

                                          По части своевременной (хотя это сейчас более-менее выровнялось) и, что самое главное, грамотной поддержки clang всё-таки опережает. По крайней мере, я на баги в реализации стандартов в gcc натыкался существенно чаще, чем в clang.

                                        0
                                        Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.

                                        Использование wchar_t не означает автоматически правильную обработку строк без каких-либо усилий со стороны программиста. При работе со строками нельзя забывать, в какой кодировке они находятся.


                                        Если взять Юникод, то один даже четырёхбайтовый wchar_t не способен представить все графемы таким образом, чтобы не оставить возможностей для ошибки. Как минимум, популярные ныне эмоджи могут требовать нескольких code points.


                                        Поэтому при прочих равных лучше уж взять тип данных, размер и семантика которого не зависит от платформы, под которую собирается код.

                                          0
                                          Символы юникода и их размер это прямо классика. Вот эталонная статья Спольски от 2003 года еще.
                                            +1
                                            В 2018 году использование НЕ Юникода? это преступление против человечности… абсурд просто.
                                              +1

                                              Реальный мир часто абсурден. Хотя лично я тоже убеждённый сторонник повсеместного использования Юникода для представления текстов, но есть некоторые вещи, которые Юникод представить не в состоянии. Вроде некоторых имён. Однако, это не технический вопрос об устройстве стандарта, а больше вопрос администрирования консорциума, который отказывается добавлять в стандарт редко используемые или «повторяющиеся» символы.


                                              Также с не-Юникодом точно придётся контактировать на границах системы, за которыми бушуют океаны легаси-кодировок, будь то файлы в КОИ-8 или HTTP, который по умолчанию использует Latin-1.

                                              0
                                              Если взять Юникод, то один даже четырёхбайтовый wchar_t не способен представить все графемы таким образом, чтобы не оставить возможностей для ошибки. Как минимум, популярные ныне эмоджи могут требовать нескольких code points.

                                              4 байта (UTF-32) как раз полностью покрывает весь Unicode. Выбор размера char влияет лишь на способ представления, но не на сами символы, поэтому в UTF-16 приходится использовать суррогатную пару. Более того, использование UTF-32 как раз лишает программиста головной боли связанной с обработкой текста, как набора Unicode символов, поскольку в таком случае у тебя в памяти лежит массив char'ов, где каждый char — это конкретный символ Unicode.

                                              Все неприятности начинаются уже при работе непосредственно с самим Unicode.
                                              Если опустить проблемы связанные с поддержкой новых версий стандарта, когда твоя библиотека тупо может не знать о существовании каких-нибудь новых диапазонов, то всплывает, например, проблема комбинирования символов.

                                              С одной стороны, не так может оказаться страшно, если комбинацию нескольких символов можно с помощью алгоритмов нормализации привести к одному символу того же Unicode. Как в примере с википедии:
                                              й й — первая буква состоит из 1 unicode символа, а вторая — из 2. (можете скопировать в блокнот, сохранить в UTF-16 и посмотреть в HEX)

                                              Но вот уже проблемой становится, когда попадается нестандартные комбинации, типа «белая женщина-врач», являющейся комбинацией символов «женщина» (U+1F469), «модификатора — белый цвет» (U+1F3FB), «символ медицины» (U+2695) и zero-width joiner (U+200D) между ними. Такая комбинация вообще не декларируется стандартом и эмодзи такого в Unicode нет по понятным причинам.
                                                0
                                                Более того, использование UTF-32 как раз лишает программиста головной боли связанной с обработкой текста, как набора Unicode символов, поскольку в таком случае у тебя в памяти лежит массив char'ов, где каждый char — это конкретный символ Unicode.

                                                Вот именно что не решает. Как раз из-за комбинаций, образующих одну визуальную единицу. Когда я выделяю в текстовом поле «‍⚕️» — а что вы видите в своём браузере? что хабраредактор сделал с моим текстом? — и копирую этот символ, то обычно ожидается, что скопируются все четыре code points, из которых он состоит:


                                                • U+1F469 WOMAN
                                                • U+200D ZERO WIDTH JOINER
                                                • U+2695 STAFF OF AESCULAPIUS
                                                • U+FE0F VARIATION SELECTOR-16

                                                Не один wchar_t, а четыре. Откуда-то текстовое поле должно знать, что в этом конкретном случае надо поступать именно так. Здесь, правда, ситуация немного натянутая: текстовое поле как бы занимается отображением текста, так что оно-то и так в курсе, сколько визуального места занимает каждая последовательность байтов, кодирующая тот или иной текст.


                                                Программист здесь может ошибиться, например, в операции «взять первый символ» в строке, реализовав её как string[0]. Если используется UTF-8, то эта операция вернёт некорректный UTF-8 текст из одного байта 0xF0. Если используется UTF-32, то эта операция даст технически корректный текст, но будет семантически неверной, так как потеряет все пришлёпнутые сзади модификаторы.


                                                Юникод — это фундаментально кодировка с переменной длиной графем. Работать с текстом в основном надо либо на визуальном уровне графем (иногда их частей) для отображения и редактирования, либо на уровне байтов для передачи и хранения. Формат представления никак не помогает правильно работать с графемами: что в UTF-32, что в UTF-8 надо знать отдельные правила их обработки. В любом случае для обработки графем придётся жить с тем, что один условный char в массиве не соответствует одной графеме.


                                                Для передачи и хранения вообще удобнее работать как раз с массивом байтов, так как длина массива байтов в байтах и порядок байтов в байте не зависит от операционной системы, архитектуры процессора и компилятора. С этой точки зрения UTF-8 является идеальным форматом. У UTF-16 есть преимущество в компактности для текстов на языках, символы которых в UTF-8 кодируются тремя байтами. (Плюс, есть исторически сложившиеся API, принимающие именно UTF-16.) У UTF-32… есть много лишнего места, разве что. Это удобное промежуточное представление для преобразований между форматами, но для хранения и обработки UTF-32 подходит не очень.

                                                  0
                                                  Насчет экспертизы UTF-32 — полностью согласен. Не понимаю, зачем тратить в два раза больше места, если можно все кодировать в UTF-16. UTF-8 скорее всего смысла не имеет именно потому что кириллица в нем не может быть отражена одим байтом…
                                                    0
                                                    Я и не говорю, что UTF-32 решает проблему вывода графем, но то, что с ним не легче работать, чем с UTF-16 или UTF-8…

                                                    Юникод — это же в первую очередь таблица «индекс — символ», а проблема вывода лежит в области обработки массива таких индексов.

                                                    Согласитесь, что проще оперировать голыми int'ами, как в случае той же «женщины-врача» — это по сути конкретная последовательность {0x1F469, 0x200D, 0x2695, 0x200D, 0xFE0F}. При обработке, в таком случае, нас ждёт всего одна операция — поиск такой последовательности в массиве. В случае же работы с каким-нибудь UTF-8 перед тем, как искать последовательность потребуется перекодировать данные для получения опять же набора int'ов.

                                                    Только не подумайте, что я топлю за использование 4 байтов. Накладные расходы на хранение таких данных, особенно при работе с большим количеством строк, как тут — это слишком.
                                                      +3
                                                      В случае UTF-8 поиск и замена выполняется настолько же просто. Только у вас массив байтов и искать там надо последовательность {0xF0, 0x9F, 0x91, 0xA9, 0xE2, 0x80, 0x8D, 0xE2, 0x9A, 0x95, 0xE2, 0x80, 0x8D, 0xEF, 0xB8, 0x8F}. Что так искать последовательность, что эдак.

                                                      Только когда приходит время отправлять текст в сеть или записывать его на диск — а они работают только с байтами — в случае UTF-32 приходится выбирать, записать U+1F469 как {0x00, 0x01, 0xF4, 0x69} или как {0x69, 0xF4, 0x01, 0x00}, аналогично для UTF-16 — {0xD8, 0x3D, 0xDC, 0x69} или {0x3D, 0xD8, 0x69, 0xDC}, тогда как в UTF-8 вариант только один: {0xF0, 0x9F, 0x91, 0xA9}.
                                                        0
                                                        Ну вот, вместо понятной последовательности индексов используем массив «каких-то» байт. А ведь при выводе помимо такой замены проводится ещё и нормализация, которая проводится через преобразование в UTF-32 и обратно. Во всяком случае в тех реализациях, что я видел — это так.

                                                        А ещё можно вот какой финт сделать в UTF-32:
                                                        1) Нормализуем.
                                                        2) Заменяем все нестандартные последовательности на свои индексы из пользовательских диапазонов.
                                                        3) Теперь с таким массивом действительно можно работать, как с массивом визуальных единиц не боясь повредить данные.

                                                        И я понимаю, что проблема порядка байт остаётся, но я же говорю не о проблеме хранения и передачи, а об удобстве обработки таких данных.
                                                          +1
                                                          С точки зрения алгоритма поиска между последовательностью индексов и последовательностью байтов разницы особой нет же. Оба вида последовательностей получаются из других строк текста, а не составляются вручную программистом. И для ренормализации строки после замены достаточно затронуть только несколько соседних символов, всю строку в UTF-32 преобразовывать не надо.

                                                          Идея с использованием неиспользуемых значений в UTF-32 интересная. В 4 байта же действительно можно разместить ещё 4096 дополнительных Юникодов, если использовать лишние битики. Не знаю, будет ли какой-то существенный выигрыш в производительности от такой замены и нестандартного представления, но идея однозначно интересная! Спасибо.
                                                +4

                                                По поводу второго пункта — очень странная идея использовать gcc везде, я бы еще понял, если бы вы clang предложили, но gcc после ухода с него андроида постепенно уходит в легаси. Симбиан и Маемо в 2018 году никому не нужны, ios — clang, андроид — clang, win — msvc или clang, linux — gcc или clang.


                                                Ну и под вин ничего лучше msvc все же нет, несмотря на усилия clang (а не gcc) в этом плане. Как и лучше IDE, чем Visual Studio, при всем уважении к CLion. И по части стандартов msvc сильно подтянулся, хотя до clang не дотягивает.

                                                  –1
                                                  Если рассматривать микропроцессоры как еще одну платформу, а это по истине гигантский рынок, то там все-таки преобладает GCC и перемен в строну CLang не ожидается. А вот переход на более изящный синтаксис C++ имеется, чипы растут в производительности и там, где раньше приходилось виртуозить на Си, периодически переходя на Асм, можно уже безболезненно использовать стандартные контейнеры из std.
                                                  Т.е. в плане унификации, сейчас GCC все же более удобен.
                                                  СLang — будем посмотреть))
                                                    +1

                                                    Ну так как 1C на микроконтроллерах не работает и вряд ли будет, то это к теме поста отношения не имеет. Соглашусь, что в embedded gcc может быть и сильнее — не сильно погружен, не могу всерьез комментировать — но игнорировать iOS и Android тоже нельзя — а там gcc (уже) нет. Так что с тезисом про унификацию согласиться не могу.


                                                    При этом ее полезность тоже не стоит переоценивать — у нас в компании легко собирается продукт под gcc разных версий, clang разных версий и MSVC разных версий — наверное, 6 вариантов суммарно — и не могу сказать, чтобы это было как-то так уж сложно сейчас. Основные проблемы в АПИ платформы, а тут никакой компилятор не поможет.

                                                +6
                                                И еще один момент, многие наработки из Boost для работы с контейнерами перекочевывают в C++17. Вам имеет смысл потом снова проверить аллокацию памяти для std::map|set, возможно проблема будет пофиксина (как минимум в GCC) и удастся снова вернуться к стандартным контейнерам.
                                                  +3
                                                  Да, в этом есть смысл, спасибо!
                                                  +3
                                                  Спасибо. Стало понятнее что случилось со стабильностью релизов Платформы после 8.3.10 (так пока и сидим на нем из-за критичного бага со внешними источниками в режиме совместимости 8.2.13).

                                                  Даже демо платформы ( platform.demo.1c.ru/demo83 ) до сих пор не переведено на типа актуальную 8.3.13, а остается на 8.3.12.

                                                  Остается надеяться, что 1С в ближайшее время таки справится с проблемами, связанными с таким серьезным переходом.
                                                    +2
                                                    Зря человеку карму подпортили. Мы недавно пробовали перейти на 8.3.13 (конфигурации — управляемые приложения). Поплевались, психанули и откатились на 8.3.11.3034. Динамические списки ведут себя неадекватно, колонки съезжают. Веб-клиент (понимаю, что написан не на С++) постоянно ошибки выдает.
                                                      +1
                                                      А в каких именно конфигурациях проблемы?
                                                      В типовых или в самописных?
                                                        +1
                                                        Самостоятельно разработанные конфигурации. Но по стандартам и методикам 1С, с нормализованной схемой БД.

                                                        Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.
                                                          +1
                                                          Самостоятельно разработанные конфигурации.
                                                          Но по стандартам и методикам 1С,

                                                          При выходе новых версий платформы 1С публикует изменения стандартов.
                                                          Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.

                                                          с нормализованной схемой БД.

                                                          А это про что, можете пояснить?
                                                          В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.

                                                          Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.

                                                          Если не сложно — сделайте пожалуйста.
                                                          Воспроизведутся проблемы — шлите конфигурацию, будем чинить.
                                                            0
                                                            При выходе новых версий платформы 1С публикует изменения стандартов.
                                                            Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.

                                                            Мы это учитывает.

                                                            А это про что, можете пояснить?
                                                            В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.


                                                            В работу платформы на уровне SQL не лезем. Чтобы писать запросы, нужно понимать что из себя представляет БД 1С. А мы знаем, что это таблицы в СУБД. Поэтому при проектировании структуры объектов конфигурации оперируем понятием «таблица», но с использованием тонкостей 1С (периодичность регистров сведений, регистры остатков, оборотов и т.п.). Соответственно, приводим схему данных в такое состояние, когда у нас нету избыточности. Или нехватки данных (статья на ИТС про самодостаточность регистров).

                                                            Если не сложно — сделайте пожалуйста.
                                                            Воспроизведутся проблемы — шлите конфигурацию, будем чинить.


                                                            Хорошо. Результаты лучше в личку?
                                                              0
                                                              Спасибо за разъяснения!

                                                              Результаты лучше в личку?

                                                              Да.
                                                    –14
                                                    Как вообще в проекте такой сложности и тяжести можно додуматься использовать стандартные контейнеры и потоки, которые мягко говоря, не оптимизированы? Ну разве что легаси. Но у меня бы в первую очередь это бы вызвало вопросы к коду, раз уж не жаль 6 месяцев работы сеньора на перевод на стандарт.
                                                      +16
                                                      У меня бы к такому синьору, который сразу хочет выбросить стандартные контейнеры и потоки, тоже были бы вопросы. Например, попросил бы результат ы профилирования, которые демонстрируют, что именно в стандартных вещах узкое горлышко.
                                                        +4
                                                        Таки если вы читали статью — в них-то и узкое горлышко. Если у вас есть лишние люди, конечно, можно в проектах такого уровня зависеть от чужих либ в таких базовых вещах, но выглядит это странно. Я, разумеется, не стал бы переписывать библиотеку работы со звуком или чтения каких-то мудреных чужих форматов, но в игровых проектах я столько «изящной архитектуры и изящных конструкций» насмотрелся, которые надо оптимизировать тупо через массивы или переопределять new, чтобы хоть как-то работало. Так что перекопать базу и твердо на ней стоять — маст хэф. Праада на сях давно не писал, может std и правда стало мастерписом, но в мое время это был странный перешаблонированный и мешающий отладке монстр, к тому же скорее академический, чем для реального использования в хевилоаде.
                                                          +3
                                                          Праада на сях давно не писал, может std и правда стало мастерписом

                                                          И за изменениями в новых стандартах и STL не следите? Если так, то претензии ещё более необоснованные. Для начала стоит актуализировать собственные знания.
                                                            0
                                                            Говорю же, давно не писал на сях и более ко мне stl:: не применим, к тому же давно потерял веру в человечество, а после бардака с многократным переворотом парадигмы мультипоточного кода у мелкософта, и вовсе стараюсь изо всех сил, где это аозможно, обходить зависимости от чужого кода или протоколов, если у проекта запланировано жизни более 2 лет.

                                                            Вообще, это наверное, с молодостью проходит — восторженныая радость при слежении за обновлениями и переворотом в технологиях. Со временем обновления ОС, IDE, библиотек и сервисов вызывают лишь чувство досады, иногда тревоги, иногда — испанского стыда, но больше просто легкое раздражение, что опять придетмя ковырять то, что давно в продакшне.
                                                        +3
                                                        Это неверное утверждение, особенно в отношении контейнеров, для чего-то другого — возможно.
                                                        Как раз сейчас в С++ контейнеры особенно модернизируются. Например, для того, чтобы эффективно работала в С++17 вот какая изящная конструкция множественной итерации.
                                                        for (auto [x,y,z] : zip( xs, ys, zs )) {
                                                            // ...
                                                        }

                                                        Сейчас вы вынужденны применять для этой задачи все тот же сторонний Boost (реализация которого иногда тяжеловата, т.к. он опирается на существующие контейнеры, создавая над ними обертки)
                                                        for(auto&& t : zip_range(contA, contB)) {
                                                            t.get<0>(items) = t.get<1>(items);
                                                        }

                                                        И, кстати, для окончательного отказа от указателей, в пользу новых интеллектуальных указателей или модернизированных ссылок (С++17) также придется оптимизировать/переписать реализацию всего, где происходят итерации по массивам.
                                                        +1
                                                        А обновленные шаблоны native ВК в связи с переходом на новый стандарт стоит ждать?
                                                          +1
                                                          Рассматриваем этот вопрос.
                                                          NativeAPI завязывается также на работу в браузере, а многие промышленные дистрибутивы Linux не спешат переходить на новые стандарты в используемых компиляторах. И, соответственно, ВК подключенная в браузере в таком дистрибутиве, может быть неработоспособна.
                                                          0
                                                          В итоге-то новая версия стала работать быстрее или медленнее, что с памятью стало? Победили все первоначальные проблемы?
                                                            0
                                                            В итоге-то новая версия стала работать быстрее или медленнее, что с памятью стало?

                                                            Новая версия платформы на типовых сценариях работает не медленнее старой.
                                                            И потребляет при этом не больше памяти, чем старая.
                                                              +2
                                                              И потребляет при этом не больше памяти, чем старая.

                                                              Коллеги на проф. форуме неоднократно описывали обратное. Например:
                                                              partners.v8.1c.ru/forum/t/1723890/m/1747082
                                                                +1
                                                                Новая версия платформы на типовых сценариях работает не медленнее старой.
                                                                И потребляет при этом не больше памяти, чем старая.

                                                                Перед релизом мы тестируем на типовых сценариях.
                                                                Когда нам присылают сценарии, на которых есть деградация по производительности/памяти — мы, по мере возможности, фиксим платформу и исправляем ситуацию.
                                                                Все возможные сценарии, как вы понимаете, перебрать в принципе невозможно.
                                                            0
                                                            И попутно угробили работоспособность конфигурации 1С: ЖКХ. И, вероятно, не только ее. Молодцы, что сказать. Про общую скорость работы я вообще промолчу, она все хуже и хуже.
                                                              +1
                                                              И попутно угробили работоспособность конфигурации 1С: ЖКХ

                                                              А что случилось с 1С:ЖКХ на новой платформе?

                                                              Про общую скорость работы я вообще промолчу, она все хуже и хуже

                                                              На каких сценариях она все хуже и хуже?
                                                                0
                                                                1. Функционал связанный с подъездами и квартирами (может еще где, я не выискивал) полностью отвалился.
                                                                Ошибки:
                                                                {ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EObjectNotFound) Object «СЗК_ЗащищеннаяОбработка» is not found
                                                                {ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EBadFileFormat) Bad file format
                                                                Вылетает при попытке доступа к Зданиям при создании или редактировании.
                                                                2. Бухгалтера с каждым новым обновлением платформы поднимают вонь что так работать невозможно, что тормозит ужасно. Мне сравнивать не с чем, я так, по сути немного помогаю по мелочи, но и сам тыкаясь по разделам ощущаю что оно довольно медленно ворочается даже на почти пустой базе под ЖКХ, особенно при сохранении данных. При этом сервер на котором стоит платформа, БД и работают тонкие клиенты даже не напрягается. БД — SQL Server.
                                                                  +1
                                                                  А можете ссылку кинуть на конкретную конфигурацию на сайте производителя конфигурации?
                                                                  Это что-нибудь из вот этого комплекса?
                                                                  Или речь совсем о другом?
                                                                  Конфигурация, насколько понимаю, не от 1С.
                                                                    0
                                                                    Вот эта: vgkh.ru/jsk/jkh/capabilities.php
                                                                    Перестала работать после обновления платформы до последней версии. Не помню, правда, какая то версия была. Сами разработчики конфигурации говорят что работает стабильно на 12й версии, а 13я глючная (это с их же слов). При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.
                                                                      +5
                                                                      Вот эта: vgkh.ru/jsk/jkh/capabilities.php

                                                                      Тут вопросы к разработчикам конфигурации.
                                                                      Они декларировали совместимость конфигурации с той платформой, на которой появляются проблемы?

                                                                      При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.

                                                                      Насколько знаю — можно поставить разные версии платформы даже на один сервер и разные конфигурации запускать под разными версиями платформы. Или у вас не та ситуация?
                                                                        0
                                                                        Да кто ж его разберет теперь декларировали или нет. Проблема в том, что новый функционал по хорошему не должен убивать уже существующий как произошло в данном случае. И ладно бы версии были сильно разными, так нет же. С версией 2х-месячной давности оно работало, а с версией 3-4х недельной давности уже нет. Я не могу сказать какая была до этого версия, но знаю что обновления платформы ставятся подрядчиками оперативно. На сколько помню апдейт был в августе (на нем работало) и в октябре (уже не работает).

                                                                        Вариант с разными версиями прекрасен во всей своей костыльности.

                                                                        Все это звучит прямо как «мы тут что-то сломали, но это не наша проблема».

                                                                        Вот реально платишь хренову тучу денег за гемор с лицензиями, с обновлениями, с сопровождением, с переносом данных и т.д. и т.п.
                                                                        Я к этому всему имею немного косвенное отношение т.к. моя задача была перенести данные из существующей системы в 1С и потом это все интегрировать в кабинет пользователя. И понеслось…
                                                                          +2
                                                                          Да кто ж его разберет теперь декларировали или нет
                                                                          Дак тот, кто обновлял — тот и разберёт)
                                                                            +1

                                                                            Где туча денег? Если не обновлять конфигурации, то можно ничего не платить. Если обновлять то можно покупать итс.техно за 12500 в год. Это примерно 1 МРОТ. А для базовых версий обновления бесплатны. Вы уверены, что это туча денег?

                                                                              0
                                                                              Я про весь комплект включая лицензии на пользователей, конфигурацию, итс на платформу, итс на конфигурацию, лицензию на SQL Server. Еще приходится оплачивать услуги подрядчиков чтобы не иметь головняка с процессом обновления.
                                                                              Про не обновлять конфигурацию, я надеюсь, вы пошутили… Конечно, можно в целях крайней экономии к этому варианту прийти, но тогда уж проще и дешевле использовать аналогичные продукты, если такие имеются на рынке.
                                                                                0

                                                                                ИТС на локальную сеть нужен один. Остальные лицензии — это разовые затраты, компьютер же бесплатно никто не дает? Обновление типовых конфигураций с появлением расширений можно доверить роботу, да расширения бывают отваливаются, но для меня это не критично. Не обновляться вообще? Легко на вмененке или упрощенке.

                                                                –2
                                                                Затраты на переписывания кода для получения новых проблем окупились?
                                                                Я так понял что основная проблема была «угловые скобки у нас были разделены пробелами». Зато теперь модно, молодёжно:
                                                                — увеличили потребление памяти (всеобщий тренд)
                                                                — стало требовать свежее железо для сборки (наконец-то можно обновить пакр)
                                                                — winxp в пролёте
                                                                — теперь нужны более дорогие специалисты для поддержки кодовой базы (а то лезут тут всякие)
                                                                — тесты стали тоже требовать больше ресурсов
                                                                — функционал тот же но исполняемый файл солиднее и капризней
                                                                — зато теперь можно использовать свежий boost (а не эти костыли)

                                                                «Небыло печали купила баба порося»: Кодовая база стала меньше? Время сборки уменьшилось? Время на устранение багов сократилось или стало более предсказуемым? Или просто доработать чтобы компилировалось и проходило тесты? В чем огромный плюс проведённо титанической работы особенно для клиента?

                                                                В целом ваш высококвалифицированный разработчик просто красавчик. Его плюсы затмевают ваши минусы. Предлагаю повысить ему зарплату.
                                                                  +12
                                                                  — увеличили потребление памяти (всеобщий тренд)
                                                                  Разработчики прямым текстом здесь сказали, что после окончания работ потребление памяти на типовых сценариях не увеличилось, остальные моменты они фиксят при обнаружении.
                                                                  — winxp в пролёте
                                                                  ОС, первая версия в семестве которой вышла 17 лет назад, последняя (SP3) 10 лет назад, и официально снятая с поддержки производителем 4 года назад?
                                                                  Не говоря уж о том, что современный MSVC прекрасно компилирует бинари под xp вне зависимости от стандарта языка, нужно просто соответствующий тулчейн выбрать.
                                                                  — теперь нужны более дорогие специалисты для поддержки кодовой базы (а то лезут тут всякие)
                                                                  Разработчик-плюсовик, засевший в 90-х годах и ничего не слышавший и не желающий слышать про актуальные стандарты его основного языка — это не «более дешевый» специалист, это просто плохой специалист.
                                                                    0
                                                                    MSVC прекрасно компилирует бинари под xp вне зависимости от стандарта языка, нужно просто соответствующий тулчейн выбрать.
                                                                    Собирать то он собирает, но работать не будет. И никто с этим заморачиваться не захочет.
                                                                    это не «более дешевый» специалист, это просто плохой специалист
                                                                    Дело не в плохой/хороший. Сравните объём ненужного в новом стандарте, объём знаний который надо запихать в студента за ограниченное время. Думаете качество знаний в таких условиях тоже будет расти? Так что затраты на обучение новых специалистов будут непрерывно расти пока не придёт понимание что дорогонах.
                                                                    Сделали бы уже новый С++ явно не совместимым со старым вместо того что-бы регулярно собирается и выдумывать как еще фишку прикрутить к 38 летнему старью, оставив старьём.
                                                                    Ведь по факту получаем что каждый раз нужна работа по переводу кода на новый стандарт C++ разве это не странно при наличии обратной совместимости?
                                                                      –1
                                                                      Насчёт выкинуть с++ на свалку истории — полностью согласен.
                                                                      сейчас набежит школота и скажет, что я ниосилятор. Да, признаю, просто невозможно успевать за развитием с++.
                                                                      Просто есть баланс: латать по-чуть-чуть и прямо сейчас (получают маленькие проблемы, которые потихоньку можно править). Или переписать все, например, на той же Джава. И сколько человеко-часов единомоментно тогда придется потратить? К тому же, простого пути миграции с одной экосистемы языка на другую нет. Поэтому технический долг нарастает.
                                                                        +1
                                                                        Сравните объём ненужного в новом стандарте, объём знаний который надо запихать в студента за ограниченное время.

                                                                        Это что, например, ненужное? Кроме std::launder.

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

                                                                            Чтобы написать всё аккуратно, мне придётся снова примерно полчаса читать стандарт, чего делать не очень хочется.
                                                                            0
                                                                            std::launder это очередной костыль, который помогает бороться очередным UB, который вызван новым стандартом, который позволяет компилятору использовать не обоснованную логику, которая используется при оптимизации в тех ситуациях где она нафиг не нужна (в доме который построил Страуструп)
                                                                            Вообще это печально постоянно жертвуют здравым смыслом ради непонятно чего. И потом тыкают лозунгом мы не хотим платить за то что не используем. Зато потом за это платят все остальные.
                                                                              +2
                                                                              Так я ж спросил, что кроме него ненужно-то.
                                                                            +1
                                                                            >Собирать то он собирает, но работать не будет. И никто с этим заморачиваться не захочет.

                                                                            И пример ситуации, когда v141_xp генерирует нерабочий бинарь, вы конечно привести сможете.
                                                                              0
                                                                              Например 1, 2, 3
                                                                                0
                                                                                Например 1, [2](http://qaru.site/questions/847528/vs2017-and-missing-api-ms-win-core-rtlsupport-l1-2-0dll-on-win7xp), 3

                                                                                Чисто из любопытства, зачем вы заходите на помоечные сайты типа qaru?
                                                                                Все материалы там взяты cо StackOverflow и подвергнуты автоматическому переводу.
                                                                                К примеру, вот оригинал второй ссылки на SO: https://stackoverflow.com/questions/45745336/vs2017-and-missing-api-ms-win-core-rtlsupport-l1-2-0-dll-on-win7-xp

                                                                                  0
                                                                                  1. Согласен, сходу не работает.

                                                                                  2. Косяк разработчика: почему-то
                                                                                  — он взял не те библиотеки (onecore вместо x86)
                                                                                  — не воспользовался статической линковкой
                                                                                  — не воспользовался Redist

                                                                                  3. Проблема не сколько с MSVC, сколько с Windows SDK.
                                                                                  Работа семейства функций _stat исправлена ещё в Universal C Runtime 10.0.10586 (плюс ещё одна причина использовать Redist, вместо того, чтобы таскать всю эту пачку из 40+ библиотек с собой)
                                                                          +3
                                                                          интересная статья. Спасибо. Вопросы
                                                                          1. делали ли код-фриз на время переноса? Если нет, то не было потом проблем со слиянием багфиксов предыдущих релизов и крайней версии, перенесенной на новый тулинг С++?
                                                                          2. Используете ли техники статического анализа кода? Например, продукт PVS Studio www.viva64.com/ru/pvs-studio
                                                                          3. Не появилось ли проблем у пользователей при миграции между версиями? Т.к. бинарные данные изменили формат/layout или еще что-нибудь
                                                                            +5
                                                                            Спасибо, мы старались!

                                                                            1. Код-фриз не делали, работы над стволом и новым стандартом велись параллельно. После обновления, в некоторых случаях, конечно, есть проблемы переноса исправлений в старые версии платформы (без поддержки стандарта C++14).

                                                                            2. Конечно используем на постоянной основе. PVS Studio основной инструмент.

                                                                            3. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.
                                                                            0
                                                                            Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.

                                                                            Любопытно. Если бы у Вас не было альтернативной реализации строки под рукой, то Вы бы никогда и не провели такой тест, верно?

                                                                            Если это только отдельные места, где производительность просела до 20-30%, то может надо было эти места оптимизировать или даже (крамола!) кое-где забить на это? Всё-таки отказ от стандартной строки это серьёзный шаг.
                                                                              +3
                                                                              Всё-таки отказ от стандартной строки это серьёзный шаг.

                                                                              Мы этот шаг сделали довольно давно :)
                                                                              По моему опыту, любые проекты, много работающие со строками, используют свою реализацию строк, по ряду причин, не последняя из которых — быстродействие. Из того что видел сам — платформы двух больших западных ERP (это даже частично сам писал), и вот еще 1С. Из того, про что слышал — уже упомянутый Facebook, например.
                                                                                0
                                                                                А Вы не могли бы немного подробнее рассказать, на чём именно теряется быстродействие и память в Вашем случае? Конкретно интересует следующее: теоретически семантика перемещения при правильном применении в большинстве случаев должна свести на нет преимущества от COW. Но это сработает только если переписать код в соответствующем стиле. Можно предположить что переписывать код было слишком трудоёмко и поэтому было принято решение вернуться обратно к реализации на COW. Но возможно решающую роль сыграла оптимизация хранения коротких строк? Расскажите подробней, пожалуйста.
                                                                                  0
                                                                                  В нашем коде много мест, где происходит явное копирование строк и семантика перемещения там не сработает. Только COW. Но в других случаях, при работе с контейнерами, перемещение здорово помогает.
                                                                              –1
                                                                              А когда обновления нормально ставится будут? А то достало уже стандартную базу обновлять через конфигуратор. Обновления выходят чуть ли не раз в месяц. Оно еще и адски долго запускается.
                                                                              Когда запуск ускорите? А то получается, как с MS Offise и LibreOffice. Первый запускается вечность, а второй на той же конфигурации раза в три быстрее при первом запуске и раз в 20 при повторном. Только вот у вас к сожалению конкурентов нет.
                                                                                +1
                                                                                Раз уж используете свои строки, почему не UTF-8? Вроде сейчас это стандарт де-факто. На многих строках снизите потребление памяти.
                                                                                  0
                                                                                  Пока автор отвечает, предположу что исторически так сложилось. Изначально основной платформой был Виндос, поэтому когда-то был выбран UCS-16. Сегодня переходить на другую кодировку мучительно больно — ведь нужно сохранять совместимость с предыдущими версиями, при этом заранее оценить величину выигрыша/проигрыша затруднительно.
                                                                                    0
                                                                                    Для преимущественно англоязычных данных UTF-8 имеет смысл, в нашем случае профит будет небольшой.
                                                                                    И потом, переход на UTF-8 может оказаться несравнимо тяжелее, нежели переход на новый стандарт, ситуацию нужно тщательно анализировать, учесть все возможные выигрыши и потери.
                                                                                    –3
                                                                                    10 миллионов строк
                                                                                    Это безумно большая цифра для программного кода, с таким объёмом он уже должен обрести собственное сознание…
                                                                                    Возможно имелось в виду общее количество строк?
                                                                                    Вместе с пустыми хидерами со стандартной шапкой, отсутствием кода и смысла. Почти любой проект содержит 99% подобного мусора, кроме самых мелких — для них ещё всё впереди.
                                                                                    В этом случае можно достичь большей оптимизации — просто удалив воду. Алгоритм при этом не пострадает, я уверен в этом.
                                                                                      0
                                                                                      Да, мне тоже интересно, откуда в одинэске набралось столько кода.
                                                                                        +1
                                                                                        Почитайте хотя бы этот блог чтобы примерное представление о платформе сложилось. Возможно это поможет ответить на ваш вопрос.
                                                                                        Вкратце — она много чего умеет и очень кроссплатформенная.
                                                                                        +1
                                                                                        Это безумно большая цифра для программного кода

                                                                                        Чем же эта цифра пугает. 10 миллионов строк. В половине строк по одному символу ({ и }), еще четверть строк (если не больше) — комментарии и т.д.
                                                                                        Посмотрите на код Firefox или что-то в этом духе. А вы говорите "безумно большая цифра".


                                                                                        А вся статья изложена в заголовке:


                                                                                        Как мы перевели 10 миллионов строк кода C++ на стандарт C++14 (а потом и на C++17)
                                                                                          0
                                                                                          Судя по инфографике — 10 миллионов не так уж и много
                                                                                          www.visualcapitalist.com/millions-lines-of-code
                                                                                          –1
                                                                                          не хотите слезть со своих бинарных протоколов, зашитых на размер wchar_t, на кросплатформенные (protobuf, например)?
                                                                                            +4

                                                                                            Огромный респект вашему высококвалифицированному плюсовику. Берегите его!

                                                                                              0
                                                                                              Спасибо, мы ему передали!
                                                                                              +1
                                                                                              Вопрос от чайника. Правильно ли я понял, что теперь фичи новых Xeon/Core будут наконец задействованы? Или флаги компиляции так и остались на «Pentium-4»?
                                                                                                0
                                                                                                Да, кстати, интересный вопрос.
                                                                                                Используются ли дополнительные инструкции процессора в коде, или вся надежда на компилятор, что он верно сам увидит и соптимизирует.
                                                                                                  +1
                                                                                                  К сожалению, мы не можем так просто задействовать фичи новых процессоров у себя в платформе. Некоторое время назад мы пытались банально включить поддержку SSE2 при компиляции 32-битной платформы (в x64 процессорах она уже есть по умолчанию) и сразу получили несколько проблем от внедренцев, т.к. у клиентов до сих пор используются компьютеры, не поддерживающие SSE2.
                                                                                                    +1
                                                                                                    Печально. Так и будем гоняться по «помойкам» за старыми Xeon На 3.2 ГГц для серверов 1С?

                                                                                                    Вариант выпуска нескольких наборов бинарников, условно «под старые процессоры» / «под новые процессоры» хотя бы для Windows платформы не рассматривался?
                                                                                                      0
                                                                                                      Речь шла о клиентских компьютерах и, соответственно, процессорах. С серверными такой проблемы нет.
                                                                                                      По поводу двух редакций — сейчас фактически так и есть, 32-битная платформа для старого железа и ОС, 64-битная платформа — для современных. В том числе для этого мы сделали 64-битный клиент и Конфигуратор.
                                                                                                        +1
                                                                                                        Речь шла о клиентских компьютерах и, соответственно, процессорах. С серверными такой проблемы нет.
                                                                                                        — с какого момента с серверными бинарниками нет проблемы, простите?
                                                                                                        Если приходится выискивать древние высокочастотные Xeon для того, чтобы оно быстрее работало, а новые не дают прироста скорости от слова совсем.
                                                                                                        Серверные бинарники компилируются и оптимизируются под какую версию CPU сейчас?
                                                                                                          +1
                                                                                                          У нас нет разделения на серверные бинарники и не серверные. Есть разделение на 32-битные и 64-битные.

                                                                                                          Высокая частота и новые инструкции в процессорах не должны коррелировать.

                                                                                                          64-битные бинарники собираются с generic x64 инструкциями, включающими в себя, например, sse2 и cmov. AVX не используется, да и мест в платформе таких практически нет, где бы от них был явный выигрыш.
                                                                                                            +1
                                                                                                            Проблема в том, что новые ядра, в целом, более низкочастотные. Поэтому и приходится искать старые сервера. Тогда ещё не думали об энергоэффективности.
                                                                                                              +1
                                                                                                              Вот именно!
                                                                                                              И вот, что странно. На новых Xeon те же приложения IIS почему-то работают заметно быстрее, а вот 1С — нет. Даже медленнее.
                                                                                                              Нет оптимизации или «специфика вычислений» сказывается?
                                                                                                                0
                                                                                                                IIS или не cpu bound, или хорошо параллелится (а тренд на увеличение количества ядер), или сказывается бОльший кэш у новых процов.
                                                                                                                А 1С, видимо, чисто упирается в производительность ядра (а она в прямой зависимости от частоты).
                                                                                                                  0
                                                                                                                  ..1С, видимо, чисто упирается в производительность ядра (а она в прямой зависимости от частоты).
                                                                                                                  — и я о том, же.
                                                                                                                  Т.е. это всё же неоптимальный код или неоптимальная компилляция?
                                                                                                        +1
                                                                                                        я не вижу проблемы сделать при старте платформы определение списка поддерживаемых инструкций и выбирать нужную ветку программы. Так делает любой профессиональный пакет типа Photoshop/autocad. Либо действительно тащить разные бинари и запускать нужный.
                                                                                                    0
                                                                                                    У нас был свой класс для строк, т.к. у нас в силу специфики нашего софта строковые операции используются очень широко и для нас это критично

                                                                                                    и при этом нет нормальной возможности использовать регулярки…
                                                                                                      +1
                                                                                                      Проблемы в проекте начинаются после слов программиста «О! Я знаю, как сделать это на регулярных выражениях!» (ц)
                                                                                                      Ну а если серьезно — мы периодически возвращаемся к этому вопросу, но окончательного решения пока так и не приняли. Регулярные выражения — это «веревка достаточной длины чтобы выстрелить себе в ногу». Введение ее в платформу, развитие и поддержка — очень серьезная задача, влекущая за собой, помимо вложения в нее ресурсов, как плюсы, так и минусы.
                                                                                                      Чего будет больше — вопрос очень непростой.
                                                                                                        0
                                                                                                        Я прекрасно осознаю, что некоторым программистам нельзя давать в руки спички, а не то что допускать к клавиатуре. Но грести всех под одну гребенку и лишать мощного и гибкого инструмента — это тоже перебор. Поддержка регулярных выражений имеется в каждом уважающем себя языке и мир из-за этого еще не рухнул (вне зависимости от уровня подготовки пишущих на них программистов).
                                                                                                        А ресурсы… Я не C++ программист, но думаю задействовать стандартную библиотеку особого труда не составит.
                                                                                                          0
                                                                                                          задействовать стандартную библиотеку особого труда не составит.

                                                                                                          А какую считать стандартной?
                                                                                                          Далее, после выбора стандарта, надо документировать, обучать, поддерживать работу на разных ОС и т.д. и т.п.
                                                                                                          Т.е. все это — весьма серьезная активность. Плюсы реализации которой, как я уже говорил, неочевидны. А не просто задействовать стандартную библиотеку.
                                                                                                            0
                                                                                                            Но ведь в XDTO есть ограниченная поддержка регулярных выражений…
                                                                                                              0
                                                                                                              В случае XDTO это, скорее, побочный эффект (причем, насколько помню, недокументированный).
                                                                                                              Осознанного решения по введению рег. выражений мы, повторюсь, пока не приняли.
                                                                                                      0
                                                                                                      А вот Вы не пробовали потом свои наработки оптимизайций по строкам отправить обратно для включения в boost, stl и иже с ними? Чтоб не только в будущем можно было меньше своих «костылей» лелеять внутри проекта, но и чтоб другие тоже могли воспользоваться?
                                                                                                        0
                                                                                                        Нам кажется, в этом нет особого смысла.
                                                                                                        Для решения generic задач стандартная строка вполне подходит.
                                                                                                        Для решения задач частных, по моему опыту, каждый большой проект пишет строку для себя, под свои потребности и специфику, либо с нуля, либо беря за основу ту же Facebook-строку из folly например.
                                                                                                        Т.е. польза для комьюнити от вливания нашей строки в стандарт будет, мягко говоря, спорной — наша строка хороша для наших задач, и не факт, что оптимально подойдет для других проектов.
                                                                                                        Классов строк в open-source библиотеках немало (и в стандарт они не вошли!), и добавление нашей реализации ничего нового не привнесет.
                                                                                                          0
                                                                                                          Проблема в том, что далеко не всем нужны оптимизации SSO и Copy-On-Write. Иногда от них больше вреда, чем пользы. Да и семантика типа сильно меняется.
                                                                                                            0
                                                                                                            Copy-on-write раньше был в STL у GCC, например, но потом его оттуда выпилили, т.к. такая реализация противоречит стандарту языка, поскольку в определенных случаях инвалидирует итераторы/ссылки, что как раз именно для этих случаев явно запрещено стандартом :)

                                                                                                            Например, в стадарте C++ в пункте 21.4.1 p6 написано:
                                                                                                            ...invalidation of iterators/references is only allowed for
                                                                                                            — as an argument to any standard library function taking a reference to non-const basic_string as an argument.
                                                                                                            — Calling non-const member functions, except operator[], at, front, back, begin, rbegin, end, and rend.
                                                                                                            а неконстантный оператор [] для COW-строки вызывает операцию копирования и как раз инвалидирует итераторы.

                                                                                                            В современных плюсах для экономии ресурсов и избегания лишнего копирования строк рекомендуют использовать std::string_view. Но и подход к работе с ними, соответственно, меняется.
                                                                                                            +1
                                                                                                            Уважаемый PeterG, Есть два вопроса.
                                                                                                            1. В связи с переходом на стандарт C++17 в платформе 14 планируется ли нативная поддержка регулярных выражений?
                                                                                                            2. Планируется ли развитие Механизма анализа данных в сторону ML (machine learning)?
                                                                                                            Прокомментируйте пожалуйста, если это не секрет.
                                                                                                              0
                                                                                                              1. В связи с переходом на стандарт C++17 в платформе 14 планируется ли нативная поддержка регулярных выражений?

                                                                                                              Пока не планируется.

                                                                                                              2. Планируется ли развитие Механизма анализа данных в сторону ML (machine learning)?
                                                                                                              Прокомментируйте пожалуйста, если это не секрет.

                                                                                                              Секрет :)
                                                                                                                0
                                                                                                                В смысле секрет? Объявлялось же недавно что планируется добавить возможности работы с машинным обучением. Вроде уже где то даже обкатывается.
                                                                                                                  0
                                                                                                                  Объявлялось же недавно что планируется добавить возможности работы с машинным обучением. Вроде уже где то даже обкатывается.


                                                                                                                  Хм, а ссылку можно?
                                                                                                                    0
                                                                                                                    Кажется это было в докладе на ERP форуме
                                                                                                                    «Фирма „1С“. Состояние дел, стратегия и развитие корпоративного направления» Нуралиев Борис, директор, «1С»

                                                                                                                    но запись трансляции целиком я почему то не смог найти, хотя смотрел интересующие меня вещи в ней, а по ссылке почему то записи именно этого доклада нет.
                                                                                                                      +1
                                                                                                                      А, понял.
                                                                                                                      Детали реализации разгласить пока не можем, к сожалению.
                                                                                                                      А с ML работаем, конечно, куда сейчас без него.
                                                                                                              0
                                                                                                              Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.

                                                                                                              Из написанного не до конца понятно производительность вернулась на прежний уровень или нет после изменений?
                                                                                                                0
                                                                                                                Да, вернулась.
                                                                                                                0
                                                                                                                Не совсем касается статьи, но некоторые пожелания по развитию платформы:
                                                                                                                1) Сделайте в конфигураторе, возможность группировать те же общие модули (хотя бы их) либо по подсистемам (про отбор по подсистемам я в курсе), либо (что лучше) вообще сделать возможность создания произвольных групп. Например создать группу «Работа с подключаемым оборудованием» или «Мои модули», а то в современных конфигурациях написанных на базе БСП и БПО, такое большое количество модулей, что становится тяжело с ними работать. При этом можно (и наверное даже нужно), чтобы эта иерархия была прозрачная для кода (тогда ничего не придется существенно изменять).
                                                                                                                2) Для динамических списков, не хватает возможности выборки временной таблицы, бывает что есть достаточно большой объём тяжелой «статичной» информации, которую и дорого считывать постоянно, да и нет особой необходимости. Я понимаю, что это вступает в конфликт с «Динамическим считыванием», но можно же как-то разделить части запроса, какие считываются один раз, а какие данные обновляются динамически?
                                                                                                                3) При работе с внешними источниками данных, не хватает возможности создания произвольных запросов к базе на её диалекте. Бывают ситуации, когда оптимально написать прямой запрос к базе, имея все возможности базы данных, а не только те, которые предоставляет 1С. Да, есть функции, но опять же, их нельзя создать средствами ВИД.
                                                                                                                4) В некоторых ситуациях, в целях оптимизации дорогого вызова сервера (особенно на медленных сетях), очень не хватает событий вроде «ПередВызовомСервераНаКлиенте», «ПриВызовеСервераСКлиента», «ПередЗавершениемВызоваСервераСКлиента», «ПриЗавершенииВызоваСервераНаКлиенте». Ибо есть необходимость, каких-то периодических обращений к серверу, для получения «команд», информации и пр., при этом нет «срочности» получения информации, было бы удобно, перед вызовом сервера (как из кода, так и внутренние потребности 1С, например обновление динамического списка и пр.), в событии «ПередВызовомСервераНаКлиенте» сформировать некую произвольную структуру необходимой информации, в событии «ПриВызовеСервераСКлиента» получать её с клиента и обрабатывать ну и в событии «ПриЗавершенииВызоваСервераНаКлиенте» получать запрошенные данные с сервера. Это бы позволило минимизировать обмен с сервером и формировать некие «пакеты» на запрос к серверу. А так несколько обработчиков которым периодически нужно вызывать сервер, в разных местах + потребность платформы в вызовах сервера = Излишние обращения к серверу, которые на медленных сетях порой очень дорогие! (интернет же не везде хороший)
                                                                                                                5) Ну и упоминавшаяся уже в комментариях, необходимость в регулярных выражениях, ибо технически, платформа умеет с ними работать (проверка типа в XDTO), но прямого доступа из кода нет. Лично для меня, это уже вторично, в некоторых местах, использую хак проверки через XDTO, хотя этот способ как мне кажется, достаточно дорог в отличии от нативной поддержки.
                                                                                                                6) Возможность расчета контрольной суммы (Хеширование) на клиенте. Как-то не логично передавать 5 гиговый файл на сервер, только для того чтобы узнать его контрольную сумму, в данный момент приходится использовать консольные программы для этого.
                                                                                                                7) Сделайте возможность deflate упаковки строк, сама платформа активно использует этот алгоритм в тех или иных местах, однако, разработчику данный механизм не доступен (если не рассматривать хаки через ZIP файл)
                                                                                                                Что-то было ещё, но уже забыл. В целом мне очень нравится курс, который вы взяли начиная с 8.3.9, добавляя всё больше и больше, очень вкусных возможностей, в том числе которые «казалось бы» не нужны в «бухгалтерской» программе.

                                                                                                                Спасибо!
                                                                                                                  0
                                                                                                                  Пожелания записал, постараюсь донести до руководства разработкой.
                                                                                                                    0
                                                                                                                    Спасибо!
                                                                                                                  0
                                                                                                                  А 10 мегастрок, это сколько мегабайт исходников?
                                                                                                                  А то я в последнее время приобрёл привычку сжимать исходник, чтобы колёсико мышки меньше изнашивалось.
                                                                                                                  Раньше делал так:
                                                                                                                  if(condition)
                                                                                                                  {
                                                                                                                      code
                                                                                                                  }
                                                                                                                  else
                                                                                                                  {
                                                                                                                      code
                                                                                                                  }

                                                                                                                  А теперь делаю так:
                                                                                                                  if(condition){
                                                                                                                      code
                                                                                                                  }else{
                                                                                                                      code
                                                                                                                  }
                                                                                                                    +2
                                                                                                                    А 10 мегастрок, это сколько мегабайт исходников?

                                                                                                                    > 600 Мб

                                                                                                                    А то я в последнее время приобрёл привычку сжимать исходник

                                                                                                                    Ну тут дело вкуса.
                                                                                                                    Что до меня — я готов увеличить размер исходника, но получить лучше читаемый код, мне открывающие фигурные скобки на новой строке глаз радуют :)
                                                                                                                    0
                                                                                                                    PeterG

                                                                                                                    многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода


                                                                                                                    Спрошу публично. Учитывая что в заголовке заявлена указанная цель перехода, можно ли сказать что ситуация с 8.4 редакцией улучшится? В публикации и в комментариях все ссылаются на 8.3.XXXX.

                                                                                                                    На последнем Хайлоаде++ в целом и у многих клиентов все чаще мы видим кластера Kubernetes, мы вынуждены использовать собственные образа docker с 8.3 на борту, которая не сильно для таких развертываний предназначена. Я уже не говорю про OpenShift — там идет еще тяжелей.
                                                                                                                      +2
                                                                                                                      Алексей,
                                                                                                                      8.4 не готов сейчас публично обсуждать.
                                                                                                                      –3
                                                                                                                      А я думаю — почему же это после обновления платформы до самой свежей всё стало жутко тормозить?
                                                                                                                      А вишь оно как… П == Прогресс.
                                                                                                                      PS. нагрузочные тесты? Не, не слышал.
                                                                                                                        +1
                                                                                                                        А во обще странно, почему тормозит. Я недавно тестировал компиляторы VS C++ 2010 и VS C++ 2017, да к новый компилятор генерирует более оптимальный код, 5-10% можно получить быстродействия, и это простой перекомпиляцией. Ну а если вдруг проект стал тормозить значит, значит к проекту прилипла что-то тормозящие, в смысле библиотека.
                                                                                                                          +1
                                                                                                                          Ну а если вдруг проект стал тормозить значит, значит к проекту прилипла что-то тормозящие, в смысле библиотека.
                                                                                                                          Либо система начала тормозить из-за чего-то совершенно другого, а не из-за перевода на другой стандарт языка или замены компилятора.
                                                                                                                          +1
                                                                                                                          Как у вас так получается? До какой самой свежей вы обновились — конкретную версию пожалуйста озвучьте. Версию PostgreSQL также желательно высказать. Может вы взяли ванильную неофициальную и вручную попытались патчи наложить. Также платформа 1С не работает в вакууме — вопрос в конфигурации которую вы используете. У любой конфигурации есть режим совместимости, соответственно исходя из режима совместимости конфигурации вы можете получить хоть какое-то представление о тормозах и их причинах. Если они конечно не кроются в коде написанным приходящим программистом 1С — который внезапно что-то намудрил с 256-тью таблицами.
                                                                                                                            –1
                                                                                                                            Легко и непринужденно:
                                                                                                                            * берем крайнюю версию платформы (8.3.13.1513, если склероз не изменяет)
                                                                                                                            * берем крайнюю версию Бухгалтерии (3.0.65.сколькототам)
                                                                                                                            * запускаем 10 штук баз одновременно (файловых, на не самом поганом немецком хостинге, на честно купленной Windows Server 2008 R2)
                                                                                                                            * сидим и курим ЧАС, пока оно взлетит
                                                                                                                            Загрузка процессора (всех четырех ядер) — 5-10%
                                                                                                                            Никаких тюнингов и выпендриваний — всё by default.

                                                                                                                            Вот как так вот?
                                                                                                                            Я такое кунг-фу не умею.
                                                                                                                            Чтобы так убить работу — я не умею.

                                                                                                                            PS. TPC говорит, что лучше, чем на этом сервере — технически существовать не может.
                                                                                                                            Шутка, конечно, но тем не менее.
                                                                                                                          0
                                                                                                                          PeterG Добрый день,
                                                                                                                          можете пожалуйста рассказать какой % кода написан на C++, а какой на других языках (без учета веб клиента, сервера взаимодейстивия, EDT и прочих явно написанных на других языках элементов инфраструктуры 1С). Надеюсь это не какая-то тайна, можно очень примерно (90 на 10, 80 на 20 и тд). Особенно интересно сколько места в платформе занимает Java и есть ли она там вообще. Если всё же Java там есть было бы супер услышать несколько примеров какие блоки на ней реализованы. Спасибо!
                                                                                                                            +1
                                                                                                                            Добрый день!
                                                                                                                            Я сейчас не в офисе, с разработчиками проконсультироваться не могу. Но, насколько помню, если отбросить все вами перечисленное — С++ занимает 97%-99%. Несколько визуальных контролов (точно помню про планировщик и форматированный документ) написаны с применением JavaScript.
                                                                                                                            Java, насколько помню, применяется только в EDT и Сервере Взаимодействия. Возможно еще где-то в утилитах администрирования, но 100% не уверен.
                                                                                                                            +1
                                                                                                                            Уж коли пошла такая вечеринка — обращусь сюда.
                                                                                                                            Я сам бОльшую часть своего рабочего времени занимаюсь оптимизацией производительности баз 1С, не смотря на то что сертификата Эксперт у меня нет, потому что руки не доходят.
                                                                                                                            Что хотелось бы и не понятно почему в 1С разработчики это упорно игнорируют, хотя те же преподаватели на курсах говорят что было бы здорово если бы это было:
                                                                                                                            1) Конструктор Индексов объектов баз данных.
                                                                                                                            Поясню — не я проектирую справочники\ документы с 20-80 реквизитами и не я автор РЛС на несколько реквизитов в одной таблице. Эту проблему можно было бы достаточно малой кровью, но сейчас 3 пути решения, которые озвучиваются на том же обучении:
                                                                                                                            N1 Ничего не делать.
                                                                                                                            N2 Реализовать через вспомогательные объекты (как правило Регистры сведений), но делать 10-15 регистров сведений к тому же справочнику номенклатуры не очень здорово + требуется большая переработка существующего функционала. Да это работает, но иногда чудовищные затраты по времени.
                                                                                                                            N3 Нарушить лицензионное соглашение и добавить индексы на уровне БД и поосле реструктуризации следить за ними, потому что платформа скидывает индексы в по дефолту. Так себе решение, мало кто может это позволить, ибо решение N2 дорого сейчас, а решение N3 дорого всегда.
                                                                                                                            А бОльший пул проблем можно часто решить просто добавлением 1-2 соответствующих индексов.
                                                                                                                            2) Нет человеческого инструмента анализа логов.
                                                                                                                            Объясню: ЦУП — долго, не качественно. На том же обучении — из 5ти попыток только одна смогла проанализировать логи. Для софта за 100 000 с намеком на энтерпрайз по моему плохо.
                                                                                                                            — Скрипты на perl — неплохое решение, из рекомендуемого gitBash — чтение идет в 1 поток и скорость неудовлетворительна. У одного заказчика установка любого софта запрещена, и я еле еле вынес логи на флешке для анализа, тот же GitBash мне не поставили.
                                                                                                                            — Самописки. Каждый ваяет как может. Я написал нормализатор на Python и загружаю в SQL.
                                                                                                                            — Кто то ипользует ELK.
                                                                                                                            Но есть ситуации когда заказчик ультимативно требует только инструменты Вендора.
                                                                                                                            Не понятно почему нельзя выпустить инструмент и продавать его за деньги, если он будет лишен недостатков ЦУП — спрос будет, я сам куплю его на свои в первый же день выхода. Тем более для держателей формата тех журнала и тех кто знает основные проблемы это задача не несподъемная.
                                                                                                                            Просто по своему опыту — 30 гб логов ТЖ нормализуются в CSV на достаточно посредственной машине с HDD диском за 5-15 минут, все зависит от загруженности диска другими задачами.
                                                                                                                            Тот же Сергей Старых aka TormozIT сделал очень неплохой и достаточно быстрый анализатор логов ТЖ на 1С в инструментах разработчика, но том из — за того что данные после разбора хранятся на форме — не получится анализировать что то большое.
                                                                                                                            Большое спасибо за внимание.
                                                                                                                              0
                                                                                                                              Постараюсь донести ваше мнение до руководства разработки.
                                                                                                                                0
                                                                                                                                Заранее благодарен.

                                                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                            Самое читаемое