На первый взгляд впечатляюще. Вот интересно под линухом оно через что отрисовку делает?

Ё, как много на ЛОРЕ товарищей, покусаных баранами !

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

>На первый взгляд впечатляюще. Вот интересно под линухом оно через что отрисовку делает? Вроде через gtk ... при сборке видно: -I/usr/local/include/gtk-2.0

Попробовал. Примеры идущие со средой нормально собираются только со статикой и при этом получающееся приложение занимает 3-4 мегабайта. SDLExample потребовал переставить местами либы SDL и SDLMain.

> Поясните, что такое инкрементальная компиляция. Это что-то из времён доса и ускорения компилятора? :)

очень просто: инкрементальная компиляция -- это то, что обычно не работает в перегруженном шаблонами и макросами С++ коде :))

> Это почти наверняка всегда ухудшает оптимизацию.

не спорю. Но оптимизировать обычно надо 1 раз, когда выкладываешь релиз. А в промежуточные моменты нужен быстрый Code-fix-code-fix-code-fix и обновление создаваемой системы "на лету". Хоть тот же лисповый REPL.

> Что такое инкрементальный редактор связей - вообще тайна покрытая мраком, и маркетинговым бредом производителей RAD :)

э, причем тут RADость ? тот же D/Digital Mars C++/OpenWatcom емнип с инкрементальным линкером.

что это за чудо и почему не брать сразу что-то вроде LD_PRELOAD=new.o .. в более других системах, это отдельный вопрос :))

>> И как МС могла его закопать?

>Легко и непринужденно. Надо всего лишь свою версию студии выпускать, вместе с новыми библиотеками и пачкой рекламы

ещё полезно перед этим сманить к себе ведущих разработчиков, Хейсельбергов там всяких.

>> Поясните, что такое инкрементальная компиляция.

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

эээ... не понял связи. Скорее, автодополнение - приятный побочный эффект и не компилляции, а анализа сорсов.

Насколько я понимаю, достаточно изменить ОДИН символ (в каком-нть #define), чтобы вся эта "инкрементация" слетела. Или поменять "всего лишь одну строчку", где идут открывающие-закрывающие скобки. :)

Вобщем, фигня всё это. Насколько я знаю, D не имеет никаких "инкрементаций". Тем не менее, компилляция проходит мгновенно. Вопрос: чё парить мозги мелкомягким маркетингом?

> это видимо то, благодаря чему у некоторых есть правильное автодополнение кода, и то из-за чего его пока нет в emacs,

есть в емаксе "инкрементальная компиляция". Для лиспа, в SLIME :)
M-x slime code-fix-code-fix C-c C-c в нужной функции.
И автодополнение по прототипам функций там есть.
То, что оно для С++ толком (не) работает, (хотя есть CEDET) это отдельный вопрос :)

просто "PE next-gen", видимо, имелся ввиду ;) где все прилинкованное и собранное - расположено, сообразно сырцам ;-)

> эээ... не понял связи. Скорее, автодополнение - приятный побочный эффект и не компилляции, а анализа сорсов.

это тот анализ семантики, который составляет половину компиляции (без кодогенератора). В автодополнении обычно ещё тип подсказывается. Хотя вот в VIM вообще нет анализа, просто построчно -- и тоже работает. Иногда.

Например, в отключеном #if 0 .. #endif коде, что должно дополнять?
Или, template<.. <template<.. <template< .. >>>

> Насколько я знаю, D не имеет никаких "инкрементаций".

это фича скорее IDE чем языка. Инкрементальную компиляцию для D сделать можно, компилятор выдаёт нормальную таблицу символов. То есть ему можно искусственно выдавать функцию целиком в отдельном файле и в фоне .exe перелинковывать-обновлять из новой таблицы символов ( с новым символом)

Кажется, в какой-то IDE для D работает и автодополнение и инкрементальная компиляция.

>Тем не менее, компилляция проходит мгновенно

потому что шаблоны нормально сделаны. Просто тупо с секундомером (или ./configure .. && time make && time makeinstall) замерь время сборки того же перегруженного шаблонами С++ кода, Qt например или KDE. И для сравнения, lisp/smalltalk/plain c(без кодогенераторов)/pascal кода.

опа.. "инкрементальная компиляция для GCC" :
http://www.spindazzle.org/greenblog/index.php?/archives/74-Interview-GCC-as-a...

р, спасибо за линк

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

Re^2: Ultimate++ 2008.1 (Default)

> А за QT надо платить больше, чем за Builder.

еще один проприетарщик вылез...

> А eclipse cdt как-то обходится без этих примочек, а автодополнение у него правильнее чем у MSVS2k8.

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

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

еслиб это мог делать сам компилятор - то всё тоже самое было бы доступно в любой IDE или редакторе. но для этого имхо компилятор должен уметь обрабатывать "только изменения". иначе для С++ всё будет дико медленно, хотя... если проект хорошо разбит на файлы - make отработает довольно быстро :) Но тогда остаётся вопрос "API для доступа к тому что он построил" - сейчас его нет, а если бы была инкрементальная компиляция - то был бы например формат файлов с её промежуточным результатом.

ps: авторы gcc кстати против API %) так как тогда будет возможность использовать gcc в качестве frontend для проприетарных компиляторов...

>> Поясните, что такое инкрементальная компиляция.

> это видимо то, благодаря чему у некоторых есть правильное автодополнение кода, и то из-за чего его пока нет в emacs, vim и т.п. (и видимо не будет, пока в gcc не будет инкрементальной компиляции :) )

Для C/C++. eclim вполне нормально автокомплитит для Java без инкрементальной компиляции.

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

Чем же не угодили их контейнеры?

http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

Особо советую обратить внимание на комментарий перед кодом. Про standard library.

Админы, $ в URL допустимый символ.

> тот же D/Digital Mars C++/... емнип с инкрементальным линкером.

Нет. optlink просто в 200 раз быстрее ld, но он не инкрементальный.

> Насколько я знаю, D не имеет никаких "инкрементаций". Тем не менее, компилляция проходит мгновенно.

Ты не видел DWT или Hybrid. :) Но всё-равно на порядок быстрее, чем C/C++.

> Кажется, в какой-то IDE для D работает и автодополнение и инкрементальная компиляция.

Семантическое автодополнение есть только в Descent и инкрементальной компиляции там нет. Там вообще пока нет билдера. Но что-то аналогичное по функциональности ecj планируется.

> реализовать свой собственный парсер-полукомпилятор для С++ - это достойно уважения, но имхо это не правильный путь.

ээ.. а как по-другому? Если я тупо напишу
1)
#include <windows.h>
2)
#define LEAN_AND_MEAN_WIN32
#include <windows.h>

и при этом определится разное?

>но для этого имхо компилятор должен уметь обрабатывать "только изменения". иначе для С++ всё будет дико медленно, хотя.

1. так и делают с clang в llvm
2. по ссылке про "инкрементальный GCC-сервер" есть ссылка на проект Harmony (Беркли), там много публикаций про инкрементальные парсеры, на лету, только изменения

>Админы, $ в URL допустимый символ.

до кучи, : тоже. Например, ссылки из google cache "saved version" ломаются.

> eclim вполне нормально автокомплитит для Java без инкрементальной компиляции.

Вру. eclim использует eclipse с ecj, а ecj - инкрементальный.

Видел компилятор gcc с выхлопом в xml.

> Видел компилятор gcc с выхлопом в xml.

угу. www.gccxml.org но он точно так же как и оригинальный компилирует целиком. изменили один символ - надо всё перекомпилировать, возможности перекомпилировать только одну функцию или меньше и обновить по результату AST дерево в нём нет. + насколько я помню - нет поддержки шаблонов, то есть он их конечно компилирует, но если не было инстанцирования - в выводе их тоже не будет. и т.п.