QtCreator и Eclipse

Ты сказал «интерпретация», так что не нужно отмазок.

Ну ка расскажи, что происходит во время just-in-time компиляции? Байткод транслируется в машинный код, что по сути та же интерпретация (выполнять все равно нужно), только сбоку.

Я плакал.

Поплачь поплачь, иногда помогает

автокомплит Эклипс сосет по сравнению с шланговым в емаксе. Пруфы будут?

Не пользуюсь шланговым автокомплитом в Emacs (он у меня только как текстовый редактор), но тоже интересно было бы сравнить. По идее достаточно на взять любой корректный код, где CDT находит unresolved symbol и проверить.

Байткод транслируется в машинный код, что по сути та же интерпретация (выполнять все равно нужно), только сбоку.

Хватит уже доказывать, что ты разбираешься в своей профессии. Это всем очевидно.

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

А пример этого правильно реализованного JIT, выхлоп хоторого хотя бы не отстает по скорости от выхлопа оптимизирующего C или C++ компилятора есть? А необходимость пожирания процессорного времени впустую (трансляции) при запуске - это преимущество? А пожирание памяти по отношению к аналогичной программе на C или C++ это тоже преимущество?

Ппц. Программист, разбирающийся в своей профессии, никогда не слышал о JIT.

Ппц, комментатор, делающий выводы исходя из своих предположений.

У Java не такой уж низкий порог вхождения :)

Здесь я конечно перегнул палку, но отсутствие необходимости ручного управлениея памяти уже подразумевает меньшую сложность, по отношению к тому же C. ;-)

Хватит уже доказывать, что ты разбираешься в своей профессии. Это всем очевидно.

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

Ну ка расскажи, что происходит во время just-in-time компиляции? Байткод транслируется в машинный код, что по сути та же интерпретация (выполнять все равно нужно), только сбоку.

http://ru.wikipedia.org/wiki/Интерпретатор

http://ru.wikipedia.org/wiki/JIT

Почитай. Узнаешь много нового.

Хватит уже доказывать, что ты разбираешься в своей профессии. Это всем очевидно.

Ты бы хоть рассказал свое правильное понимание.

Правдивое понимание - Java-код компилируется в нативный при старте или первом обращении к участку кода (зависит от режима запуска виртуальной машины). Нет там интерпретации. И нет, Эклипс не тормозит, по крайней мере, по сравнению с KDevelop.

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

И нет, Эклипс не тормозит, по крайней мере, по сравнению с KDevelop.

Да да, я слукавил, признаю. Эклипс по сравнению с KDevelop/чем-либо еще не тормозит во время самой работы, только при запуске.

А пример этого правильно реализованного JIT, выхлоп хоторого хотя бы не отстает по скорости от выхлопа оптимизирующего C или C++ компилятора есть?

ВНЕЗАПНО LLVM. И другие регистровые машины.

А необходимость пожирания процессорного времени впустую (трансляции) при запуске - это преимущество?

Для десктопных приложений это не имеет никакого значения.

А пожирание памяти по отношению к аналогичной программе на C или C++ это тоже преимущество?

Проблема преувеличена. На сам JIT памяти немного тратится, а Java прожорлива по совершенно другим причинам.

Ппц, комментатор, делающий выводы исходя из своих предположений.

Какие такие выводы я сделал из своих предположений?

Здесь я конечно перегнул палку, но отсутствие необходимости ручного управлениея памяти уже подразумевает меньшую сложность, по отношению к тому же C. ;-)

В сравнении с C и C++ порог лишь чуть ниже.

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

QtCreator и Eclipse (комментарий)

Зачем ты себе этим всем жизнь усложняешь? Есть же Вим.

Для десктопных приложений это не имеет никакого значения.

Т.е. с фактом, что java программа расходует лишнее процессорное время по отношению к нативной программе (а следовательно она уже априори медленнее) ты согласен?

Проблема преувеличена. На сам JIT памяти немного тратится, а Java прожорлива по совершенно другим причинам.

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

Какие такие выводы я сделал из своих предположений?

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

Эту работу все равно надо выполнять. )

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

Обычная плюсовая IDE про сигналы/стлоты в Qt ничего не знает

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

Не работает. А очень полезно, когда IDE тебе подсказывает сигналы/слоты, да еще с учетом совместимости параметров слота с параметрами сигнала.

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

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

Тогда JIT-компиляция + выполнение кода всегда займет больше процессорного времени, чем просто выполнение кода. Это же очевидно

Да, это очевидно. Так же очевидно, что 1) это не интерпретация 2) десятки секунд, размазанные на несколько часов среднего сеанса работы, просто незаметны (если всё делается при старте, мы получаем медленный старт, но не более).

Такой метод кажется применяется в llvm при определенных её настройках.

автодополнение кода в QtCreator куда лучше, чем где-либо и т.д.

Автодополнение QtCreator - полное авно после KDevelop (юзаю первый на работе, второй дома).

Скрин Какого он показывает в списке всё, что угодно (b типа int, который не присвоишь std::string, a типа QApplication и т.д.), а не переменные типов, уместных в данном контексте?

круто, может всё же синтаксический?

Отстал от жизни:)

JIT - не панацея. Оптимизированный машинный код гораздо эффективнее этого дерьма.

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

И где ты этот «Правильно реализованный JIT» видел?

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

Т.е. с фактом, что java программа расходует лишнее процессорное время по отношению к нативной программе (а следовательно она уже априори медленнее) ты согласен?

Есть утилиты для компиляции жабы в нативный код (это вроде даже банальный GCJ умеет). Только вот профит от этого нулевой.

А я и не от JIT в данном случае говорю.

Почитай историю разговора. В медленности Java ты обвинял интерпретацию, а потом - JIT.

Программа на Java жрет больше памяти, чем нативная - это факт.

Факт. И это вина жабы с ее системой работы с памятью и сборки мусора, а не JIT или интерпретации.

Что я не имею представления о JIT.

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

программа на Java не может быть так же эффективна по всем параметрам, как нативная.

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

Я может чего-то не понимаю, но зачем автодополнять присваевание?

Скрин Какого он показывает в списке всё, что угодно (b типа int, который не присвоишь std::string, a типа QApplication и т.д.), а не переменные типов, уместных в данном контексте?

Собственно пример того, как надо.

Я может чего-то не понимаю, но зачем автодополнять присваевание?

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

Собственно пример того, как надо.

Черт мне подери! Неудивительно, что оно тормозит (если верить шизе).

Тогда JIT-компиляция + выполнение кода всегда займет больше процессорного времени, чем просто выполнение кода. Это же очевидно.

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

За тем же, зачем и всё остальное.

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

И где ты этот «Правильно реализованный JIT» видел?

LLVM, не? И жабо- и дотнетожит тоже не настолько плохие.

Не настолько?

А _насколько_ они плохие? Сейчас процессоры быстрее не становятся, и скорость важна.

Черт мне подери! Неудивительно, что оно тормозит (если верить шизе).

У KDevelop медленный парсер, но это проявляется только при начальном парсинге, и только в мегапроектах типа ядра. В процессе работы ничего не тормозит.

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

А как же присваивание переменной результата функции? Что лучше, список методов, что возвращают типы, подходящие std::string или, как в QtCreator, список всего (включая члены базовых классов), да еще и отсортированного по алфавиту (а не по глубине), да еще и без указания типов, параметров и возвращаемых значений?

Неудивительно, что оно тормозит (если верить шизе).

Оно не тормозит, оно просто не быстрее Эклипса.

Оно не тормозит, оно просто не быстрее Эклипса.

хорошая шутка

Почитай историю разговора. В медленности Java ты обвинял интерпретацию, а потом - JIT.

Хорошо, будем считать что я неправильно употреблял слово «интерпретация» в обобщенном выражении «интерпретируемое говно» и проводящим абстрактные аналогии выражении «та же интерпретация, только сбоку». А вот то, что JIT тормозит запуск программы - это опять же факт. Вопросы существенности опустим, мы (как минимум я) вроде бы говорим о том, что Java программа не может работать так же быстро как нативная вообще, а не после трансляции в частности. Так что да, я обвинил JIT в медлительности Java, пусть и в несущественной ее части.

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

Фраза

Ппц. Программист, разбирающийся в своей профессии, никогда не слышал о JIT.

при ответе на мой же комментарий

JIT - не панацея. Оптимизированный машинный код гораздо эффективнее этого дерьма.

Как я мог не слышать о JIT если сам про него пишу?

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

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

А как же присваивание переменной результата функции?

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

Попробуй как-то на досуге KDevelop - я сам не из фанатизма на нем сижу. Удобно иметь такое автодополнение и семантическую подсветку кода (не как в QtCreator, а настоящую - все переменные по возможности разными цветами).

Нет, именно семантический.

тогда не парсер, а анализатор

Плюсую KDevelop.

долго сидел на эклипсе + cdt
недавно попробовал криатор и пока остался на нем
еклипса будет удобна для чего то другого - java, например, или для разработки на c под arm

QtCreator и для голых плюсов вполне себе торт.