Нет, мы планируем периодически обновляться. Естественно, с учетом возможностей той же 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. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.
Новая версия платформы на типовых сценариях работает не медленнее старой.
И потребляет при этом не больше памяти, чем старая.
Перед релизом мы тестируем на типовых сценариях.
Когда нам присылают сценарии, на которых есть деградация по производительности/памяти — мы, по мере возможности, фиксим платформу и исправляем ситуацию.
Все возможные сценарии, как вы понимаете, перебрать в принципе невозможно.
А можете ссылку кинуть на конкретную конфигурацию на сайте производителя конфигурации?
Это что-нибудь из вот этого комплекса?
Или речь совсем о другом?
Конфигурация, насколько понимаю, не от 1С.
Рассматриваем этот вопрос.
NativeAPI завязывается также на работу в браузере, а многие промышленные дистрибутивы Linux не спешат переходить на новые стандарты в используемых компиляторах. И, соответственно, ВК подключенная в браузере в таком дистрибутиве, может быть неработоспособна.
Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC
А где в статье сказано про веру? ;)
MSVC был выбран по объективным причинам.
Одна из основных причин — отладочная информация и отладчик. GCC не умеет генерировать полноценные pdb чтобы использовать отладчик из Visual Studio или WinDBG. И при этом не имеет отладчика под Windows. Далее, все остальные инструменты под Windows, профилировщики и прочее работают только с pdb.
То же самое относится и к clang.
Качество сгенерированного кода msvc нас устраивает более чем, для нашей кодовой базы оно даже в каких-то случаях лучше, нежели в gcc под Linux.
Пока не планируется.
Секрет :)
По поводу двух редакций — сейчас фактически так и есть, 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. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.
Перед релизом мы тестируем на типовых сценариях.
Когда нам присылают сценарии, на которых есть деградация по производительности/памяти — мы, по мере возможности, фиксим платформу и исправляем ситуацию.
Все возможные сценарии, как вы понимаете, перебрать в принципе невозможно.
Это что-нибудь из вот этого комплекса?
Или речь совсем о другом?
Конфигурация, насколько понимаю, не от 1С.
А что случилось с 1С:ЖКХ на новой платформе?
На каких сценариях она все хуже и хуже?
Новая версия платформы на типовых сценариях работает не медленнее старой.
И потребляет при этом не больше памяти, чем старая.
NativeAPI завязывается также на работу в браузере, а многие промышленные дистрибутивы Linux не спешат переходить на новые стандарты в используемых компиляторах. И, соответственно, ВК подключенная в браузере в таком дистрибутиве, может быть неработоспособна.
А где в статье сказано про веру? ;)
MSVC был выбран по объективным причинам.
Одна из основных причин — отладочная информация и отладчик. GCC не умеет генерировать полноценные pdb чтобы использовать отладчик из Visual Studio или WinDBG. И при этом не имеет отладчика под Windows. Далее, все остальные инструменты под Windows, профилировщики и прочее работают только с pdb.
То же самое относится и к clang.
Качество сгенерированного кода msvc нас устраивает более чем, для нашей кодовой базы оно даже в каких-то случаях лучше, нежели в gcc под Linux.