В нашем коде много мест, где происходит явное копирование строк и семантика перемещения там не сработает. Только COW. Но в других случаях, при работе с контейнерами, перемещение здорово помогает.
Нет, мы планируем периодически обновляться. Естественно, с учетом возможностей той же WinXP; думаю, не все обновления смогут быть применены на WinXP по объективным причинам.
Речь шла о клиентских компьютерах и, соответственно, процессорах. С серверными такой проблемы нет.
По поводу двух редакций — сейчас фактически так и есть, 32-битная платформа для старого железа и ОС, 64-битная платформа — для современных. В том числе для этого мы сделали 64-битный клиент и Конфигуратор.
Проблемы в проекте начинаются после слов программиста «О! Я знаю, как сделать это на регулярных выражениях!» (ц)
Ну а если серьезно — мы периодически возвращаемся к этому вопросу, но окончательного решения пока так и не приняли. Регулярные выражения — это «веревка достаточной длины чтобы выстрелить себе в ногу». Введение ее в платформу, развитие и поддержка — очень серьезная задача, влекущая за собой, помимо вложения в нее ресурсов, как плюсы, так и минусы.
Чего будет больше — вопрос очень непростой.
Нам кажется, в этом нет особого смысла.
Для решения generic задач стандартная строка вполне подходит.
Для решения задач частных, по моему опыту, каждый большой проект пишет строку для себя, под свои потребности и специфику, либо с нуля, либо беря за основу ту же Facebook-строку из folly например.
Т.е. польза для комьюнити от вливания нашей строки в стандарт будет, мягко говоря, спорной — наша строка хороша для наших задач, и не факт, что оптимально подойдет для других проектов.
Классов строк в open-source библиотеках немало (и в стандарт они не вошли!), и добавление нашей реализации ничего нового не привнесет.
К сожалению, мы не можем так просто задействовать фичи новых процессоров у себя в платформе. Некоторое время назад мы пытались банально включить поддержку SSE2 при компиляции 32-битной платформы (в x64 процессорах она уже есть по умолчанию) и сразу получили несколько проблем от внедренцев, т.к. у клиентов до сих пор используются компьютеры, не поддерживающие SSE2.
Самостоятельно разработанные конфигурации.
Но по стандартам и методикам 1С,
При выходе новых версий платформы 1С публикует изменения стандартов.
Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.
с нормализованной схемой БД.
А это про что, можете пояснить?
В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.
Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.
Если не сложно — сделайте пожалуйста.
Воспроизведутся проблемы — шлите конфигурацию, будем чинить.
Тут вопросы к разработчикам конфигурации.
Они декларировали совместимость конфигурации с той платформой, на которой появляются проблемы?
При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.
Насколько знаю — можно поставить разные версии платформы даже на один сервер и разные конфигурации запускать под разными версиями платформы. Или у вас не та ситуация?
PDB до сих пор закрытый формат Microsoft (без документации) и его в полном объеме не умеет генерировать ни gcc, ни clang, насколько нам известно. Хотя подвижки есть, и Microsoft выкладывала хедера по структуре PDB файлов на github.
Отладчик Visual Studio является основным инструментом под Windows для нас и тут мы наталкиваемся на проблемы с поддержкой pdb.
Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.
Всё-таки отказ от стандартной строки это серьёзный шаг.
Мы этот шаг сделали довольно давно :)
По моему опыту, любые проекты, много работающие со строками, используют свою реализацию строк, по ряду причин, не последняя из которых — быстродействие. Из того что видел сам — платформы двух больших западных ERP (это даже частично сам писал), и вот еще 1С. Из того, про что слышал — уже упомянутый Facebook, например.
1. Код-фриз не делали, работы над стволом и новым стандартом велись параллельно. После обновления, в некоторых случаях, конечно, есть проблемы переноса исправлений в старые версии платформы (без поддержки стандарта C++14).
2. Конечно используем на постоянной основе. PVS Studio основной инструмент.
3. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.
8.4 не готов сейчас публично обсуждать.
Детали реализации разгласить пока не можем, к сожалению.
А с ML работаем, конечно, куда сейчас без него.
Хм, а ссылку можно?
Да.
Пока не планируется.
Секрет :)
По поводу двух редакций — сейчас фактически так и есть, 32-битная платформа для старого железа и ОС, 64-битная платформа — для современных. В том числе для этого мы сделали 64-битный клиент и Конфигуратор.
Ну а если серьезно — мы периодически возвращаемся к этому вопросу, но окончательного решения пока так и не приняли. Регулярные выражения — это «веревка достаточной длины чтобы выстрелить себе в ногу». Введение ее в платформу, развитие и поддержка — очень серьезная задача, влекущая за собой, помимо вложения в нее ресурсов, как плюсы, так и минусы.
Чего будет больше — вопрос очень непростой.
Для решения generic задач стандартная строка вполне подходит.
Для решения задач частных, по моему опыту, каждый большой проект пишет строку для себя, под свои потребности и специфику, либо с нуля, либо беря за основу ту же Facebook-строку из folly например.
Т.е. польза для комьюнити от вливания нашей строки в стандарт будет, мягко говоря, спорной — наша строка хороша для наших задач, и не факт, что оптимально подойдет для других проектов.
Классов строк в open-source библиотеках немало (и в стандарт они не вошли!), и добавление нашей реализации ничего нового не привнесет.
При выходе новых версий платформы 1С публикует изменения стандартов.
Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.
А это про что, можете пояснить?
В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.
Если не сложно — сделайте пожалуйста.
Воспроизведутся проблемы — шлите конфигурацию, будем чинить.
Тут вопросы к разработчикам конфигурации.
Они декларировали совместимость конфигурации с той платформой, на которой появляются проблемы?
Насколько знаю — можно поставить разные версии платформы даже на один сервер и разные конфигурации запускать под разными версиями платформы. Или у вас не та ситуация?
Отладчик Visual Studio является основным инструментом под Windows для нас и тут мы наталкиваемся на проблемы с поддержкой pdb.
Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.
В типовых или в самописных?
Мы этот шаг сделали довольно давно :)
По моему опыту, любые проекты, много работающие со строками, используют свою реализацию строк, по ряду причин, не последняя из которых — быстродействие. Из того что видел сам — платформы двух больших западных ERP (это даже частично сам писал), и вот еще 1С. Из того, про что слышал — уже упомянутый Facebook, например.
1. Код-фриз не делали, работы над стволом и новым стандартом велись параллельно. После обновления, в некоторых случаях, конечно, есть проблемы переноса исправлений в старые версии платформы (без поддержки стандарта C++14).
2. Конечно используем на постоянной основе. PVS Studio основной инструмент.
3. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.