Будущее g++

Но нам нужны операции, которые учитывают ещё и семантику.

Например? Какой-то конкретный пример кроме переименования члена/переменной. Ну чтобы понять, мне такие операции вроде и даром не нужны были.

Ты когда скрины покажешь? Я поставил говновим - открыл это дерьмо - ничего не работает.

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

Например?

Ну например ввод текста, редактирование текста, навигация, выделение текста.

Какой-то конкретный пример кроме переименования члена/переменной.

А чего ты так быстро то обделался. Ты же сам придумал пример и тут же начал мазаться.

Ну чтобы понять, мне такие операции вроде и даром не нужны были.

Поэтому я сразу сказал, что ты нихрена не знаешь. Человек, который хоть что-то знает и понимает - херни не несёт.

Хлебая всю жизнь баланду - ты всех и себя будет убеждать в том, что всё круто и ничего другого тебе не нужно.

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

Всеми этими вопросами должна заниматься иде и как она будет реализовывать это монолитно внутри себя или через lsp + клиент который просто занимается отображением текста это уже личные проблемы иде дельцов.

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

Ты пойми, мне в принципе фиолетово - собственная аст в редакторе или костыли в clangd. Может по-твоему даже лучше было бы, запилить некую универсальную либу со стандартным интерфейсом для крестов, например, и подключать ко всем редакторам. Я ведь тебе о чём сказал? У меня семантическая посветка работает, я не обсуждал архитектурную правильность решения. Скрин позже сделаю (возможно), нет времени сейчас.

Проблема шланга в том, что он такой же компилятор. И если gcc был и есть компилятором, то на шланг решили навешать ещё и всякие семантические возможности.

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

Шланг не инкрементальный, в нём нет никакой поддержки слияний/разделения ast. ast в нём говно, в нём слишком мало семантической информации. Оно создано только для одного - для преобразования в ir.

Автодополнение реализовано просто убогой лапшой прикрученной к парсеру. Сам парсер задизайнен парсить весь код tu. Привет на каждый вывоз комплита - секунды парсинга. Для C++ это неприемлемо.

Всё это пытаются латать костылями. Замена инклюдов на pch в кишках ide/clangd, внедрения в парсер всяких всяких убогих режимов частичного парсинга, который не работает для C++ - там инстанцирование шаблонов может менять глобальный контекст. От того оно там не работает нормально.

В С++20 начнётся жара. Там можно сделать так, чтобы каждый вызов функции порождал новый тип, новое инстанцирование. Но шланге это до сих пор не реализовано. А что будет когда принесут рефлексию.

В связи с этим шланг как источник семантической информации в ide говно не потому, что он компилятор. А лишь потому, что шланг.

Нормальному «компилятору» ничего не мешает быть источником этой информации, никак не мешая, а даже помогая, ide.

Ты пойми, мне в принципе фиолетово - собственная аст в редакторе или костыли в clangd.

Изначально ты утверждал другое. Ты рассказывал, что твоё говновим умеет в семантику. А теперь оказалось, что в этом умеет clangd, который никого отношения к твоему говновиму не имеет?

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

Обсуждал. Я не про какую подцветку не говорил. Про неё начал говорить ты. Я сказал про понимание семантики редактором. Просто ты не знаешь что это такое и начал спорить о том, что где-то в интернете видел.

Скрин позже сделаю (возможно), нет времени сейч

Ты можешь мне дать vim, который работает. Чтобы я открыл это говно бездарное и оно мне всё раскрасило. Сейчас же я открываю этот мусор и он не работает.

Хотя что-то писать в этом бездарном дерьме в принципе невозможно.

Но можешь сделать и скрин.

Изначально ты утверждал другое. Ты рассказывал, что твоё говновим умеет в семантику. А теперь оказалось, что в этом умеет clangd, который никого отношения к твоему говновиму не имеет?

Я говорил про раскраску изначально, перечитай. А зачем ещё редактору понимать семантику? Раскраска + какой-то рефакторинг, последнее и clangd умеет.

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

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

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

Привет.

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

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

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

Я говорил про раскраску изначально, перечитай.

Я не говорил.

А зачем ещё редактору понимать семантику?

За всем.

Раскраска + какой-то рефакторинг, последнее и clangd умеет.

И ты опять сел в лужу. Получается, что не только раскраска?

К тому же, что за нелепую херню ты несёшь? Причём тут clangd? Он умеет в неё потому, что твоё дерьмо не умеет. Т.е. он редактирует код, а не твой редактор.

Это примерно как кукарекать «мой редактор умеет!!» - «покажи» - «вот там другой редактор умеет» - «но ты же кукарекал, что умеет твой, а не другой?».

К тому же, я тебе уже сообщал зачем редактору уметь в семантику. Редактирование, форматирование, ввод текста, дополнение, навигация и прочее.

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

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

игра не стоит свеч

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

или тех кто проповедует воссоздание в рамках иде семантического поведения языка.

Подобного варианта в С++ нет.

И с чем тут можно не справиться клиент-серверу?

там нет противоречия в том что клиент-сервер не справится с этим, если противоречие в том что в этом нет особого смысла.

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

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

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

Кстати еще будет интересно узнать с какой версии кдевелоп начал вообще понимать какую-то семантику и как они это делают.

Ну если считать худые отображатели текста

я не понимаю что значит «худой отображатель текста»

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

зачем нужен vim или emacs пояснить?

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

А чему там тормозить-то? Да, нужно будет держать дополнительную копию сорсов в памяти. Нет причин полагать, что на практике этот минус будет сколько-либо значим.

Но которая существует из-за того, что не один туллинг сет пока не способен на то, о чем толкует ваш оппонент

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

Логика редактирования семантических единиц, как я понял? И с чем тут можно не справиться клиент-серверу?

Не клиент-сервер, а клиент-сервер говна. К тому же зачем он нужен, если он всё усложняет и ненужен. К тому же увеличивает задержки, не является предсказуемым.

Иди посмотри сколько костылей в clangd из-за ассионхронности. И это он ещё ничего не умеет.

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

Нет, подобного профита нет. Даже в рамках lsp подобного не существует нигде. А когда lsp разовьётся до уровня вменяемого - смысла в редакторе не будет. lsp-сервис сам станет редактором. А все редакторы сдохнут, потому как не смогут его поддерживать, а если смогут - уже не будут редакторами.

зачем нужен vim или emacs пояснить?

Да, зачем они нужны как попытка быть иде. Ведь понятно что они не иде, а просто редакторы.

А чему там тормозить-то?

Потеря на пересылке между клиентом и сервером это очевидно.

Да, нужно будет держать дополнительную копию сорсов в памяти. Нет причин полагать, что на практике этот минус будет сколько-либо значим.

Это уже кэширование и попытка обойти узкое место клиент-сервера.

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

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

Ну это как посмотреть

А без разницы. Язык такой. Любой язык, а не скриптуху, распарсить без компилятора невозможно.

Не отрицаю того факта что в цлионе это патченый цлангд

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

Но их затея провалилась. Написать компилятор для С++ они были не в состоянии. Поэтому переехали на clangd.

что в кдевелопе я вообще не знаю.

libclang как источник семантической информации. А kdevelop сам по себе «семантический».

Кстати по поводу цлиона интересно будет если вы предоставите ссылки где жб раскрывают эту тему, я никогда этим специально не интересовался.

Да сомневаюсь, что они они особо где-то об этом говорили. По крайней мере я не особо интересовался и не понимаю.

Кстати еще будет интересно узнать с какой версии кдевелоп начал вообще понимать какую-то семантику и как они это делают.

Очень просто. С изначальной. Как понимает - очень просто. У него есть свой «ast» в котором лежит вся семантическая информация. И когда происходит какое-то выделение или навигация - оно ездит по ней. Она в том числе и раскрашивает код.

Так же в рамках kdevelop построен свой фреймворк для написания парсеров. Он генерировал напрямую ast для кдевелопа. И до libclang использовался он.

kdevelop - это единственная ide, которая могла в C++ тогда. Ничего более в С++ не могло. Но потом С++ начал развиваться и распарсить его стало невозможно подобными методами.

Я проглядел, или до сих пор никто не назвал истинную причину?

Это GPL, конечно.

У меня здесь не особо есть что показывать, но, допустим вот из недавнего. vsговнокод с clangd не осиливает метки.

Базовая фича, которую я просил с адепта.

Он просто заложник С++ который бы уже по хорошему надо было давно закопать, но заменить его нечем

FPC уже давным давно существует — люди просто не могут поверить, что миллион строк может компилироваться и линковаться за полминуты с нуля. А учитывая то, насколько известен паскаль, насколько развиты его компиляторы и IDE, и насколько при этом он невостребован — остальные претенденты и вовсе не имеют шансов. Ну может еще какой-то Swift подойдет для чего-то высокоуровневого (то есть, не ОС/драйвера/высокопроизводительные числодробилки).

Хотя можно осознанно например не пользоваться всем стеком возможностей которые приводят к такого рода разбуханию по оперативке во время компиляции

И в итоге скатиться чуть ли не к чистому Си. Потому что классы с наследованием являются безусловным злом, но если мы их выкидываем, то остаются перегрузка и шаблоны. Проблема компиляции шаблонов заключается в том, что кол-во сочетаний параметров имеет свойство расти по степенным и показательным функциям, то есть, очень быстро. Чтобы избежать этого, нужно ограничивать использование шаблонов, как то не включать шаблоны в другие шаблоны, не применять никаких бибилотек шиблонов, помимо STL — и вот мы уже вплотную подходим к стилю Си.

https://www.youtube.com/watch?v=d1vRLfuF-wM

Вопрос - зачем нужен g++, если рядом должен быть установлен Шланг?

Кому должен? Не устанавливай =)

Зачем вообще gcc тратит силы на g++, может лучше вообще забросить и отдать кресты в руки шланга?

А кто у шланга плюсы отнял? Пусть пилят или ты думаешь что ребята из гцц побегут разрабатывать шланг? =)

да ещё и бессмысленное учитывая то, что g++ без шланга неполноценен.

Что за бред ты сейчас сказал? https://www.youtube.com/watch?v=KTITw8X2368

О чём они там в ГЦЦ думают?

О разработчике крутых и по настоящему свободных штук =) Как обычно в общем.

А так gnu collection compiler активизировался ровно тогда когда шланги стали более взрослыми и начали составлять хоть какую то конкуренцию.

Пусть будет альтернатива, зачем тебе 1 компилятор без выбора?

И как там сказал анон «Чаще не gcc портируют под систему, а систему портируют под gcc =)»

А без разницы. Язык такой. Любой язык, а не скриптуху, распарсить без компилятора невозможно.

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

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

Да сомневаюсь, что они они особо где-то об этом говорили. По крайней мере я не особо интересовался и не понимаю.

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

Так же в рамках kdevelop построен свой фреймворк для написания парсеров. Он генерировал напрямую ast для кдевелопа. И до libclang использовался он.

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

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

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

Спорно

Нет.

все зависит от того какая именно детализация семантического поведения и информации нужна для иде.

А неважно. Из С++ никакую информацию не получить.

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

Ну примеры приведи.

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

Что значит частичной? Никакой частичной нет.

В общем тут какие-то явные проблемы с пониманием темы. Семантическая информация и есть ast. Оно в любом случае будет.

Тогда получается что ваши слова относительно патчинга цлангд не совсем достоверны раз пруф на это получить не выйдет.

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

Я знаю чем является clangd и я знаю что именно использует clion. И он не использует дефолтный clangd.

Но примем это как предположение на основе коммитов в проект от жб.

Нет.

Ну тогда еще такой вопрос хотелось бы прояснить так как вы явно пользуетесь кдевелоп, насколько либцланг в рамка кдевелопа хорошо справляется именно с gcc специфичным кодом, ведь между цланг реализацией и реализацией гцц для языка с++ имеются некоторые отличия, всегда ли происходит семантически верное поведение иде + раскраска?

clang Не является реализацией C++ - он является реализацией gnu++. Тех частей gnuc/++, которые clang не поддерживает - он не распаршивает, очевидно. А те, что распаршивает - работают так, как должны.

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

Какая разница? Вопрос не имеет смысла - не важно какой там парсер. Он отличается от парсера gcc. Он может мочь то, чего не может гцц, а может не мочь то, что гцц может.

Это свойство любой альтеранативной реализации.

Вопрос ещё более не имеет смысла, потому как никакой «верной» раскраски нет и быть не может. Она всегда верная. Это базовое свойство любого компилятора.

Она именно такая, каким код видит компилятор. Все эта херня про верно/не верно не имеет смысла - это свойства всякого говна, которые кое как парсят код.

Видосик - правда я не знаю что записывать. Я так лениво потыкал.

#include <iostream>
#include <boost/hana.hpp>
#include <boost/spirit/home/x3.hpp>
#include <boost/hana/experimental/printable.hpp>
#include <boost/hana/ext/boost/fusion/deque.hpp>

namespace hana = boost::hana;
namespace x3 = boost::spirit::x3;
using namespace hana::literals;

using x3::lit, x3::uint64, x3::char_, x3::double_, hana::to_tuple;
using hana::zip, hana::transform, hana::_;

auto print = [](auto && x) {
  std::cerr << hana::experimental::print(x) << std::endl;  
};

struct employee {
  uint64_t a;
  std::string sn;
  std::string fn;
  double s;
};

BOOST_HANA_ADAPT_STRUCT(employee, a, sn, fn, s);

template<typename T> void print_fname(T && x) {
  std::cerr << __PRETTY_FUNCTION__ << std::endl;  
}


int main() {
  
  auto quoted_string = '"' >> *(~char_('"')) >> '"';
  
  
  auto start = lit("employee") >> '{' >> uint64 >> ',' >> quoted_string >> ',' >> quoted_string >> ',' >> double_ >> '}';
  
  
  auto parse = [](auto && parser, std::string_view str) {
    return x3::parse(begin(str), end(str), std::forward<decltype(parser)>(parser));
  };
  
  struct target_tag {};
  
  auto make = [](auto & ctx) {
    
    
    print_fname(ctx);
    decltype(auto) values = x3::_attr(ctx);
    
    print_fname(values);
    decltype(auto) target = x3::get<target_tag>(ctx);
    
    print_fname(values);
    
    auto refs = transform(hana::accessors<employee>(), hana::second);
    
    hana::for_each(zip(refs, values), [&target](auto x) {
      x[0_c](target) = x[1_c];
    });
  };
  
  
  auto with_bind = start[make];
  
  employee empl;
  
  auto with_state = x3::with<target_tag>(empl)[with_bind];
  
  auto data = R"(employee{35,"Jane","Street",54321})";
  parse(with_state, data);
  
  auto tuple = to_tuple(empl);
  
  print(tuple);
  
}

Сам код вот.

Нужно подробнее говорить - я запишу. А ещё лучше просто взять и потыкать. Оно всё работает «из коробки», а не как всякое говно.

Да, зачем они нужны как попытка быть иде. Ведь понятно что они не иде, а просто редакторы.

Если бы существовало то о чем идет рчеь, то были бы уже полноценными иде, это очевидно.

Да, зачем они нужны как попытка быть иде.

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

Потеря на пересылке между клиентом и сервером это очевидно.

Потеря - да. Значимая - скорее всего нет.

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

ок, тут я съехал

Ошибка выглядит как-то так, если кому интересно. Хотя это можно и руками посмотреть кому интересно.

Интересно тоже самое в емаксе.

Иди посмотри сколько костылей в clangd из-за ассионхронности

Поверю наслово : D

А когда lsp разовьётся до уровня вменяемого - смысла в редакторе не будет.

Смысл в отдельных редакторах простой. Вот есть у меня настроенный емакс/вим со своими биндами, настройками, плагинами и.т.д. Переход на другой редактор попросту вызывает дискомфорт ниже копчика. Настолько что проще сменить язык. Приходится жить с тем что есть в привычном редакторе. Поэтому нужда в лсп-подобном говне все же будет, что бы поддерживать этот зоопарк редакторов. Ну это конечно если будет востребованность этих редакторов плюсовиками… А что проще сделать - ЛСП-говно или свою васянку, я даже уже и не знаю.

А все редакторы сдохнут, потому как не смогут его поддерживать, а если смогут - уже не будут редакторами.

та не. да и тот же емакс и не редактор никакой, если ты понимаешь о чем я хехе

Вот скрин. Очевидно, что раскрашивается с учётом семантики.

Интересно тоже самое в емаксе.

Давненько плюсы не тыкал, но сейчас попробую настроить и вышлю

Видосик

вот не помню, может в youcompleteme какие-то подобные фичи были, но скорее всего тут тупа слив емакса как ни прискорбно это не звучит

И да, и нет) Но читать все сообщения подряд - то еще развлечение, тем более, когда тут целых три царя, если я не ошибся в подсчете

Кому должен? Не устанавливай =)

Он про то, что clang устанавливается зависимостью к QtCreator на том же Linux, или если плагин к VSCode установить, то тоже нужен clangd.

Опять же для vim/emacs как уже показывали выше, тоже нужен clang, для плагинов.

Вот для Visual Studio не нужен clang, там свой собственный intellisense. :)

нет.

Ну я говорил что не сойдемся.

А неважно. Из С++ никакую информацию не получить.

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

Ну примеры приведи.

Вы их уже привели выше сами, в процессе этого обсуждения.

Что значит частичной? Никакой частичной нет.

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

Я знаю чем является clangd и я знаю что именно использует clion. И он не использует дефолтный clangd.

Выше по обсуждению вы сказали что цлион использует патченный слангд.

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

clang Не является реализацией C++ - он является реализацией gnu++. Тех частей gnuc/++, которые clang не поддерживает - он не распаршивает, очевидно. А те, что распаршивает - работают так, как должны.

Тут вернее будет сказать что он не противоречит с++ вне gnu++ если это возможно. Ну получается с какой-то из реализаций с++ этот костыль тоже не справится в том месте где он не противоречит, но и не дополняет. А по какой причине тогда кдевелоп его вообще вкорячил в свою иде, парсеры были еще хуже и не могли справиться с разбухающими как раковая опухоль возможностями языка и количеством разных реализаций? Можно ли сказать что кдевелоп это иде исключительно для gnu кода?

Она именно такая, каким код видит компилятор. Все эта херня про верно/не верно не имеет смысла - это свойства всякого говна, которые кое как парсят код.

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

В моем личном соревновании на моем собственном коде GCC выигрывает немного у Clang при прочих равных условиях. Поэтому для меня смысл в GCC безусловно есть. Из троицы GCC / Clang / MSVC у меня в тестах код, собранный с помощью GCC, оказывается самым быстрым и эффективным.

А такая вещь, как разбор кода - задача утилитарная. Ее автоматизировали, она почти незаметна. Не все ли равно, каким компилятором она обслуживается. Это далеко не единственная область применения компиляторов.

Если бы существовало то о чем идет рчеь, то были бы уже полноценными иде, это очевидно.

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

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

Ну тогда наверное не стоит их приводить как альтернативу, они несостоятельны в этом плане.

Потеря - да. Значимая - скорее всего нет.

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

На самом деле вот тут уже есть куча демок плюсов в емаксе. Особенно можно выделить Semantic который сам все парсит. Но он не очень шустр. И вот еще.

Если интересует интеграция LSP’a то вот как как она выглядит.

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

Я апеллирую к тому, что и сам Си на существующие реалии плохо натягивается, в отличие от жавы/C#/JS. Вот если бы ты сравнил с C++, то я бы согласился, потому что да, кресты еще живы. Так-то сишную либу можно вполне спокойно использовать из паскаля, что активно эксплуатируется, например, при помощи тулзы для автоматической трансляции сишных заголовков в паскаль, которая, в свою очередь, сделана на базе libclang в паскале: https://github.com/neslib/Chet

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

Во первых, разумеется могут и конкурируют. А во вторых, я процитирую твой же ответ царю несколькими сообщениями выше:

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

Определяйся уже.

Ну тогда наверное не стоит их приводить как альтернативу, они несостоятельны в этом плане.

А может это ты не состоятелен в плане увидеть в них альтернативу? Вообще не ясно как эта цитата является ответом на мой аргумент.

не дающая ничего для задачи кроме возможности прикрутить другой редактор

Так я только за возможность прикрутить редактор и спорю же.

Надо было плюсов бахнуть :)

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

Я не говорил что С наследие нельзя использовать из других языков, я говорил о том что фпц жертва обстоятельств своего предка, как язык он проиграл С еще тому что был тогда, сейчас он конечно лучше того С которому проиграл паскаль. Но как альтернатива нынешнему С++ он ну такой себе, «почемубынетошный» для петпроектов, и даже возможно и не для пет. Но как поменять сознание людей которые привыкли к С миру не ясно, разве просто больше писать на других языках которые могут справляться не особо хуже с теми же задачами для которых обычно используют С и С++.

Во первых, разумеется могут и конкурируют.

Какая-то вялая конкуренция, не уходящая за задачи покрасочки и иногда автокомплит. Иде может больше.

А во вторых, я процитирую твой же ответ царю несколькими сообщениями выше:

Так хочет то получить он, мне в принципе пока норм текущие иде, но вот редактор + lsp меня не устраивает, меня в принципе мало устраивает отдельная сущность посередине для этой задачи. Я давно определился, просто вы возможно не поняли как именно.

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

А может это ты не состоятелен в плане увидеть в них альтернативу? Вообще не ясно как эта цитата является ответом на мой аргумент.

Ну у вас может быть свое мнение на этот счет, я лишь высказываю свое.

Так я только за возможность прикрутить редактор и спорю же.

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

Да я понял. Но то что компилятор используют как бекенд для комплитера и линтера никак не означает что кланг нужен, а гцц не нужен. Вполне себе вместе живут и делают то что лучше получается и что умеют. Гцц не умеет быть сервером для комплитера, а кланг не умеет в фичи или архитектуры какие. От каждого лучшее взять и норм =)

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

В этом есть доля правды.

А что для тебя вот прям обязательно должно быть в иде (ну основное хотя бы) чего нет в виме/емаксе? Интересно просто.

Я не говорил что С наследие нельзя использовать из других языков, я говорил о том что фпц жертва обстоятельств своего предка, как язык он проиграл С еще тому что был тогда

Если говорить про совсем уж «тогда», то «тогда» писался MS офис на паскале, «тогда» и под маки софт писался на object pascal. Еще в девяностые у паскаля были неплохие позиции и куча компиляторов, а потом внезапно случилось что-то, что мне до конца не понятно — скорее всего тотальное доминирование Turbo Pascal с последующим vendor-lock.

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

IT-индустрия — это инертная сфера. Понимание этого факта позволяет делать поправку на типичные десять лет (плюс-минус две коровы) инерции, которые неустранимы. Даже если паскаль и приобретет популярность, то случится это не раньше, чем через десять лет. Но вряд ли это произойдет просто потому, что сфера скукоживается, потребность писать софт на языках этого уровня снижается, потому на крестах будут писать даже тогда, когда это будет неудобно — просто потому что есть наследие, например, в виде того же Qt.

Это зависит от того для какого языка ты пытаешь из вима и емакса сделать иде. Но в основном реализация у узконаправленной на язык иде лучше чем в редакторе с костылями вокруг него.

И где та макос и виновс на паскале? )

Случился С++ и ООП, случилось то, что все значимые разработки на тот момент это были С разработки, случилось то что Эпл не вывез в написание собственной ОС и просто решил взять ту, что можно было взять без последствий. МС видимо тоже решила не сильно шатать скрепы и перенимать не только опыт написания ОС от юникс, но и перенимать тот язык на котором были написаны все юниксы существовавшие задолго до МС ос.

Люди инертны. Если уж совсем коротко.

И где та макос и виновс на паскале?

Во время разработки первой винды были серьезные планы выпускать MS Pascal, кучу софта у MS было на паскале и язык этот любили. Однако же, не любили они тот факт, что существовал конкурирующий Turbo Pascal. MS-DOS вообще изначально был писан на CP/M, который не си и не паскаль, и позже был портирован на асм. VMS, прародитель Win NT, был изначально писан на асме, а позже портирован на Си. У меня нет пруфов, но с большой долей веростности первая винда была писана именно на асме, никакого Си там не было. Так что да, инертность, в 1985 году положение Си не было таким очевидным.

А ОС-и на паскале есть:
https://wiki.freepascal.org/Operating_Systems_written_in_FPC