Mergiraf — новый движок разрешения конфликтов в коде

vsdiffmerge

А как она в сравнении с тем, что встроено в VS Code? Там тоже удобно UI сделан для разруливания кофликтов, не помню правда, умет ли оно самостоятельно часть кофликтов разруливать.

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

Простите, а с какими языками это не так? В паскале фигурные скобки - комментарии, в питоне двоеточие не означает лейбл для перехода, в испанском j не читается как «дж». Вообще не аргумент, учите язык, прежде чем читать или писать на нём.

беготнёй туда-сюда с попыткой понять куда там какой лайфтайм прописанный руками поехал

Вы много кода на расте рефакторили, чтобы часто сталкиваться с этим? Я за последние 10 лет с растом не имел проблем из-за синтаксиса лайфтаймов, тем более что в коде они не так и часто встречаются.

Идиотская абсолютно идея выдавать ошибку в качестве ответа.

Если ошибка - возможный результат вызова, то просто отлично, если это будет прописано в типе функции, разве нет? Иначе получается, что часть контракта существует где-то в параллельной реальности, не отражённой в сигнатуре.

потеряный result не видно

Вы что-то путаете, это потерянное исключение не видно, а на Result варнинг.

ты получил UB на ровном месте.

Ложь. В safe подмножестве нет уб.

В зависимостях зависимостей может быть одна и та-же библиотека разных версий

… и с разным апи. Какое альтернативное решение в этом случае можете предложить вы?

никак не можешь контроллировать версии зависимостей полностью

Конечно же, можешь. Cargo.lock, локальный репозиторий и прочие инструменты.

даже в С++ есть уже очень давно

Но не энфорсится компилятором.

Да, уровня runtime, а не compiletime

Да и ещё и в ущерб производительности.

Не согласуется моим опытом. Работал и продолжаю работать с Qt, начиная с 4.0, и всеми промежуточными версиями по сей день.

для каждой программы использовать свой яп

Да. Универсальных инструментов не бывает.

Я не про это. Я про то, что в Си есть специальные правила для знаковых чисел, которых нет для беззнаковых. К ассемблеру это отношения не имеет, это целиком сишная шиза.

И что? К чему это? Я не говорю, что Си это тот же асм…

Какому именно стандарту-то?

Разным… В чем проблема? (там на одной руке можно пересчитать действительно важные стандарты за все время)

Как часто новые ISA появляются? Что-то ты гонишь, чувачок.

Ты сейчас, чувачок, шину сравнил с ядром cortex-m4+ или что? Гонит тот кто тебя убедил, что ты в железку умеешь… Да и обилие компиляторов Си с добавлением поддержки ранее отсутствуещего функционала впринципе типа куда, шейдеры и т.п. не намекает тебе на то, что компилятор - это не «один раз создал и будет работать», да и многие делают свои компиляторы для своих железок, например техас-инструментс, интел и т.д.

Ты сейчас хочешь сказать, что на ПК не бывает проблем синхронизации? Потому что это примерно 20-30% багов в софте на ПК. Т.е. те что не переполнение буферов и прочий просёр памяти.

Я вообще-то про синхранизацию не намекал даже, там ошибка для знающего элементарная: при высокой степени оптимизации по размеру прошивки может выйти так что ты залетишь в цикл вайл, где в условие выхода переменная фактически константным значением залетает и ты хоть сколько в обработчике прерывания меняй ее - это бесполезно… Спасает volatile - явное указание, что данная переменная может часто меняться…

Что твое «переполнение буферов» по сравнению с «кончился стек»…?

Спасает

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

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

Не шаришь от слова «совсем», если не согласен, то представь мне код, где выход из вайла по переменной равной допустим 1 и измени переменную на 1, и чтоб этот код был некорректной программой и не работал (не выходил ты из вайл), а также, чтоб исправлялся volitile… У тебя вечность впереди, дерзай…

Не шаришь от слова «совсем»

Не стоит так безапелляционно утверждать. Ведь это ты плохо представляешь что делает volatile.

Я не пробовал из vscode возможности. Не могу сказать. На онтопике я kdiff3 использую, а на офтопике vsdiffmerge.

Просвети, а то может и правда не знаю…

https://habr.com/ru/articles/673428/

Нафига? Продолжай читать хабр вместо стандартов.

Кто тебе напел глупости то такие, я пример привел, что даже там «о чудо» данное явление известно, сам в шоке…

По делу можешь что сказать? Если нет, то отойди и не мешайся…

По делу можешь что сказать?

• Ты путаешь Industry Standard Architecture и Instruction Set Architecture
• volatile не спасает программу. Он делает её корректной.

volatile не спасает программу. Он делает её корректной.

Это чистая вкусовщина, да и ты мне в коде не покажешь где точно нужен volatile, а где нет, ты его скорее всего поставишь по причине «сомнительное место», т.к. еще раз говорю, что бывает и без волатайла похожие вещи работают, а некорректность программы тут не при чем, иначе бы об этом был ворнинг от компилятора, компилятор молчит, значит программа корректна…

Ты путаешь Industry Standard Architecture и Instruction Set Architecture

тем более тогда, набор команд разнится от железки к железке и говорить, что он особо не меняется опрометчиво (при условии существования даже в пределах ПК более 5-6 разных современных процессоров, а в мире микроконтроллеров и того интересней ибо там от ядра к ядру разный набор поддерживаемого пула команд, да и архитектуры разные бывают)…

На онтопике я kdiff3

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

аналог Qt пилят, кутешники же и пилят если чё.

Можно подробнее, откуда дровишки?

Недавно бисектил баг в qt5.
Примерно до 5.6 всё нормально собиралось. Потом каждая версия роняла сборку по совершенно разной причине. Какие-то не могли распарсить версию компилятора из вывода gcc, какие-то жаловались что нет STL (вообще, требование STL в библиотеке, которая сама реализует подобные утилиты - полнейший nonsense, но STL разумеется был и вполне рабочий), какие-то не собирались из-за несогласований внутренних конфигураций (например один модуль выключил поддержку dbus, а а другой почему-то не собирается без включённой поддержки dbus в этом модуле).
Боольшая часть проблем была связана с тем, что скрипты сборки и конфигурации сделаны криво и часто не детектят то, что есть (то есть неправильные конфтесты). Ну и «доламывало» его то, что собираемость qt в конфигурации кроме «всё включено» никто не проверяет, однако конфигуратор может молча отключить эти опции.
Qt в диапозоне от 5.7 до 5.13 современными компиляторами собрать невозможно без правок. С мелкими правками и комплектом из 3 разных версий компиляторов мне удалось собрать около 50% тегов в этом диапозоне - чего было достаточно для поиска регрессии.
Требование STL и наличие STLовых объектов в API тоже нехорошо т.к автоматом делает сборки плохо переносимыми (увы, качество реализации STL, по крайней мере у GNU не позволяет больше им пользоваться), но это скорее придирки. Если бы тесты были написаны нормально - я бы едва ли обратил на это внимание.
Из qt6 выпилили полноценное API для скриптинга, из-за чего даже при наличии скриптового движка в QML, проекты на qt вынуждены тащить ещё один скриптовый движок туда и прикручивать на костылях, вот пример (v8 был притащен в связи с планом обновления на qt6):
https://github.com/overte-org/overte/tree/master/libraries/script-engine/src/v8
Я уже действительно сомневаюсь в будущем проекта qt и не стал бы использовать его для чего-то сложнее гуя из одного-двух небольших окошек, который легко можно было бы переписать на что-то другое

запретить алисинг - это не решить проблемы алиасинга

из плюсов там взяли самые неудачные решения вроде ::

Там ещё пара недостатков: сложная стандартная библиотека и cargo, без которого собирать код не рекомендуется

давно ли стек кончался у Вашего приложения

вчера

Хотя про «проглотил» аргумент валидный, потому что куча растовых библиотек любят делать .unwrap() и у тебя нет возможности ничего сделать, кроме как патчить библиотеку. Другой вопрос, что, наверное, таким говнокодом просто не надо пользоваться.

Только вот почему-то сколько раз я сталкивался с проектами на rust, сталкивался именно с этим...
Наверно где-то в мире, где полно единорогов и проекты на rust другие

И что? К чему это? Я не говорю, что Си это тот же асм…

Ты утверждаешь, что «Си близок к асму». Что такое близок, в таком случае?

Ты сейчас, чувачок, шину сравнил с ядром cortex-m4+ или что?

лол

Я вообще-то про синхранизацию не намекал даже

Спасает volatile - явное указание, что данная переменная может часто меняться…

АПХАХАХАХАХАХАХАХАХАХАХАХАХ ГОСПОДИ ОТКУДА ЖЕ ТЫ ВЫЛЕЗ-ТО

/me тихо рыдает в тряпочку.

Volatile делает совершенно другое, к тому как «часто» меняется объект отношение не особо имеющее.

Цитата из стандарта:

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.

A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be ‘‘optimized out’’ by an implementation or reordered except as permitted by the rules for evaluating expressions

Только вот почему-то сколько раз я сталкивался с проектами на rust, сталкивался именно с этим…

Ну, да. Говнокод бывает на любом языке. Сорян, никто не обещал, что на Rust будут программировать какие-то особые программисты. Всё, что делает Rust, это минимизирует ущерб от этих криворуких обезьян, потому что паника куда легче чинится, чем «ой у нас тут память засрана говном что же делать».

Требование STL и наличие STLовых объектов в API тоже нехорошо

Это как это вообще? STL - это часть языка C++. Как может быть «нехорошо» пользоваться возможностями языка?

даже при наличии скриптового движка в QML, проекты на qt вынуждены тащить ещё один скриптовый движок туда и прикручивать на костылях

В смысле - вынуждены? QML должно хватать. Qt Script как раз выпилили, чтобы не тащить два разных языка. А уж какой там скриптинг хотят всякие проекты - их дело, хоть луа, не?

не стал бы использовать его для чего-то сложнее гуя из одного-двух небольших окошек

Хозяин - барин. Но лучшего кроссплатформенного тулкита нет.

код, где выход из вайла по переменной равной допустим 1 и измени переменную на 1, и чтоб этот код был некорректной программой и не работал (не выходил ты из вайл), а также, чтоб исправлялся volitile

Очередной сишник, не читавший стандарт и считающий работающую в каких-то условиях программу корректной, скукотища…

Это как это вообще? STL - это часть языка C++. Как может быть «нехорошо» пользоваться возможностями языка?

А вот так вот: софт с активным использованим STL, скомпилированный 11м gcc при запуске на системе с 14м может вызвать неплохое UB с heap buffer overflow, при этом даже не приводящее к сегфолту (молча портятся данные).
Это последняя пробелма, которую помню, обнаружилась где-то неделю назад.
Проблемы уровня «собрали библиотеку, обновили компилятор, теперь не линкуется» встречаются везде и всюду, но по сравнению с тихим UB это ещё цветочки.
Да, в rust такого не будет т.к стдлиба тащится с собой. Крейты решили этот класс проблем.

В смысле - вынуждены? QML должно хватать.

Нет, не хватает. и опять же в qt всё равно есть скриптовй движок, просто его спрятали из API.
А неудачникам, решившим воспользоваться API ещё в далёком 2012м с горя пришлось втащить v8 потому что скриптинг был на js. Грустно и точка. Я кстати хотел втащить туда другие языки, но из-за бесперспективности кутей в целом не хочется много времени уделтяь проекту, у которого на qt не только интерфейс, а весь движок, сеть и всё, что только можно.

Но лучшего кроссплатформенного тулкита нет.

Возможно. Но ИМХО, лет 10 назад qt подавал куда больше надежд, чем сейчас. Это был тулкит умеющий всё от windows mobile/ce и прочего эмбеддеда до новомодной декларативщины и qml. А сейчас возможностей и гибкости там не прибавилось, а вот потребление несколько возрасло.

rules of the abstract machine

Наблюдение: ембеддщики катастрофически не понимают, что такое абстрактная машина. Соответственно, не понимают самый фундамент стандартов. Которые, впрочем, и так редко читают, а язык учат методом тыка. Профдеформация, видимо.

увы, качество реализации STL, по крайней мере у GNU не позволяет больше им пользоваться

А можно чуть подробнее? Или речь про несовместимость версий?

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

А какие есть альтернативы? Чтобы работало на Win/osX/Linux, было можно делать UI любой сложности и фантазии дизайнера, имело встроенную поддержку юникод строк, функционала для локализации, работы с базами с прозрачным преобразованием строк, работы с сетью, регулярки по юникодным строкам, работы с файловой системой, многопоточка и т.п.

Из qt6 выпилили полноценное API для скриптинга, из-за чего даже при наличии скриптового движка в QML, проекты на qt вынуждены тащить ещё один скриптовый движок туда

А что не позволяет использовать QJSEngine/QQmlEngine/QQmlApplicationEngine ?

Кстати да, это частая проблема - при работе с embedded код пишут под конкретную имплементацию конкретной машины, а не абстрактную, потому переучиться с embedded на general разработку бывает не очень просто - привычки мешаются

Да, именно про несовместимость версий. Но такие проблемы несовместимости исключают не только использование STL типов в API, но и вообще использование STL в портативных бинарях, по крайней мере системного. Может, это был редкий баг, но и других проблем с STL хватает. Когда-то я считал непримемлимым использовать boost чисто из-за сложной компиляции связанного с ним кода (часто нехватало памяти), но при этом вполне приветствовал STL, ведь это стандарт и обычно он не приводил к такой тяжёлой компиляции.
А теперь весь этот буст притащили в стандарт со всеми несовместимостями, гигабайтами памяти на сборку. Тем временем буст наоборот стал заметно легче (вероятно из-за выкидывания legacy и использования фич компиляторов).
На самом деле, stl конечно можно использовать довольно безопасно, но я бы здесь ограничился:
1. noexcept функциями
2. type traits
3. string_view и другие header-only прозрачные структуры (но не std::string, который ломали уже кучу раз)
Однако никто не гарантирует что сегодня эта функция генерирует пару инструкций, а в следующем стандарте добавят новое требование и код раздует
При этом если сделать самостоялтельно stl-подобный класс (при этом не выходя за рамки стандарта в реализации), то шанс что он раздуется по коду значительно меньше (хотя шанс ломающих оптимизаций нововведений вроде threadsafe statics всё-таки есть)
В общем стандартная библиотека печалит и даже сильно печалит, но плюсы позволяют (пусть и с небольшими ограничениями) писать без неё

Чтобы работало на Win/osX/Linux, было можно делать UI любой сложности и фантазии дизайнера, имело встроенную поддержку юникод строк, функционала для локализации, работы с базами с прозрачным преобразованием строк, работы с сетью, регулярки по юникодным строкам, работы с файловой системой, многопоточка и т.п.

Если выкинуть отсюда работу с базами, то win32 api :))))

А что не позволяет использовать QJSEngine/QQmlEngine/QQmlApplicationEngine ?

Он очень ограничен по функционалу
Я сильно не вдавался в подробности, со слов разрабов они не могут нормально биндить какие-то сложные объекты. То есть невозможность перенести уже существующую реализацию скриптинга без потерь функционала на qjsengine, притом что в v8 нужный функционал имеется и на v8 всё успешно перенеслось (увеличив время сборки проекта часа на два)

А какие есть альтернативы?

А вот это действительно сложно. Можно разрабатывать на imgui, но в нём сильно фич не хватает и оно плохо подходит для статичных интерфейсов.
Кто-то использует ретроградские fltk, но чаще всего я вижу свой огромный тулкит с нуля (см. любой браузер, игровой движок, аудиоредактор - да почти везде можно найти примеры своих тулкитов). И если бы с qt было всё так радужно - наверно столько самопальных тулкитов бы не существовало, но разрабы, которые не хотят зависеть от решений разрабов qt, как технических, так и политических, понимают что проще чем в какой-то момент прийти к необходимости форкать этот зоопарк - сразу написать с нуля.
А вот крупных проектов на imgui уже довольно много - ведь он простой как пробка и здесь даже в случае проблем с апстримом проекта можно всё поддерживать самостоятельно

Для работы с базами можно использовать mdac. Так что в мире windows всё действительно давно изобретено, как минимум для C++.
А из других технологий кстати - dotnet + windows forms, свежий dotnet + maui
Если нужен именно нативный код и aot не устраивает - delphi/RAD
Ну и на худой конец если нужно кроссплатформенно, открыто и бесплатно - есть Ылектрон
Пользоваться софтом на этих технологиях я конечно не предлагаю, хотя желающие окунуться в винформы могут сделать их кроссплатформенными с помощью этой реализации:
https://github.com/DanielVanNoord/System.Windows.Forms
Нна шестом дотнете работает, после пары правок по крайней мере
P.S оказывается уже даже без правок. разраб недавно обновил репу

Чаво, каво :-) ?! Смешно.

А вот и нет, здесь ситуация такая же как с Portable Executable, который всё ещё является самым портабельным форматом поставки приложений для линупсов

Он очень ограничен по функционалу Я сильно не вдавался в подробности

Все таки очень туманно. Хотелось бы конкретики.

imgui

Мне думается, это просто несопоставимо по возможностям.

свой тулкит

Писать и поддерживать свой gui тулкит - это какая то титаническая и дорогущая затея. И пока что ничего, что дотягивается по уровню до Qt, я не наблюдаю.

Чаво, каво :-) ?! Смешно.

Да нет, на самом деле грустно. Бинарники под венду являются самыми совместимыми в лялексе. Потому что glibc регулярно ломает совместимость, а wine – нет.

Да, выглядит печально. Спасибо.

Видимо, еще очко в пользу раста (и винды/мака).

Все таки очень туманно. Хотелось бы конкретики.

Может быть я гляну после миграции на qt6 и сам разберусь, что с ним не так. Всё равно хотел squirrel и quickjs прикрутить если будет время. Пока что это так со слов разработчика

Мне думается, это просто несопоставимо по возможностям

Он довольно многое умеет, но конечно не современные qml-like GUI. Но в 80% случаев его возможностей уже хватит. Основной недостаток - его реализация неэффективна для статических интерфейсов. Но тем не менее, я использовал его на коре дуба со встройкой и он там вполне справляется даже с довольно сложными гуями

И пока что ничего, что дотягивается по уровню до Qt, я не наблюдаю.

Потому что те, кто пишет свой тулкит хотят не огромного монстра, а что-то что можно самостоятельно поддерживать. И никому не нужен вот прям весь спектр функций qt

С c++ рантаймом и STL на винде тоже танцев с бубном полно, с++ abi - это больная тема, потому rust/go отказались от динамической линковки.
Но в целом в пределах того же itanium abi обычно поломок нет, они чаще в самом коде реализации, когда где-то случайно поменялся размер структуры или сигнатуру метода. поломав совместимость
Говорить же что rust/go эту задачу прямо решили - тоже не совсем корректно, ведь они от неё избавились ценой ограничения динамической линковки. С тем же успехом можно было бы и в c++ всегда линковать рантайм статически (что часто и делают в portable коде). Просто переросшая стандартная библиотека это всегда плохо

С c++ рантаймом и STL на винде тоже танцев с бубном полно

Каких? Мы тащили проект, работавший с семерки по десятку. Емнип, всё сводилось к подкладыванию в каталог нескольких dll типа vccorlib и api-ms-*.dll, да вроде и у всех так.

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

Ну вот как мне его к QtCreator'у приделать? А на онтопике я именно в нем работаю чаще всего.

там в основном проблемы могли быть при линковке с библиотеками, которые зависят от старых msvcrt, особенно статическими. Впрочем, проблем с динамической линковкой сильно меньше чем в линуксе, поскольку в отличие от линукса в одном процессе спокойно уживаются 2-3 версии рантайма

вероятно, через API для плагинов?

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

Про UI любой сложности — преувеличение. Чуть реже, чем всегда, GUI-программе нужны простейшие контролы. И тут Qt дает в разы больше головной боли, чем GDI+winе хоть в снапе, хоть без снапа. А на зиге написать, так вообще не программа, а конфетка!

максимально устраняющие возможности ошибаться

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

Например, если у нас веб-сервис, то 90% запросов могут завершаться за 100мс, а 10% будут завершаться за 500 мс. И начинается борьба, а как именно на эти 10% повлиять

А зачем на них влиять? Это реалтайм веб-сервис с гарантией обработки за 100мс? Я таких не знаю ни одного. Можно пример?

10% будут завершаться за 500 мс

Если у тебя 10% запросов тормозят из-за GC, то ты просто криворукий и не умеешь в правильное распределение нагрузки.

Очередной сишник, не читавший стандарт и считающий работающую в каких-то условиях программу корректной, скукотища…

Ну сошлись на стандарт (ссылку в студию), мне интересно что ты там нового для меня откроешь…

Еще раз тебе говорю, что за Корректностью компилятор следит, а не твое мнение (ворненги и ошибки для этого существуют, а не твое личное мнение)…

Ты не сможешь мне в коде ткнуть в место, где 100% нужен volatile и без него гарантировано неверное поведение кода (тем более не зная флагов компиляции и компилятора)…