"сделанную по образу и подобию Microsoft Visual Studio"

Только вот вижуал студио с тех пор ушел ДАЛЕКО вперед. :0)

ага, ушел далеко вперед по количеству глюков, багов и прочего идиотизма :-)

2 random: Нет, вот тут как раз KDevelop даст фору ЛЮБОМУ коммерческому продукту.

Примеры - в студию. Только, пожалуйста, для версии 2.0. А выкрики типа "а я вот год назад юзал 1.4. такое гамно!!!" - это не аргумент. Я смотрю, тут все любят судить о том, чего не знают. Даже не удосужившись посмотреть и _плотно поработать_ с тем, что охаивают.

2 Trickster: Слушайте, если я начну сравнивать его с Visual Studio.NET с которым я "плотно работаю" сейчас, то KDevelop - это один сплошной design flaw. :0) Вообще любопытно, что линуксоиды гордятся тем, что достигли ЧАСТИ функциональности Visual Studio 4 в 2001 году.

2Bluezman: Хорошо, вы "плотно работаете" с Visual Studio.NET. А KDEVELOP 2.0 вы собрали? Попробовали? Хоть один проект в нем сделали? Или как и в случае с KDE 2.2 - "не буду возиться, лучше послушаю, что другие скажут..." (это я Вас цитирую). Извините, в своем подходе вы необьективны.

2 Trickster: Это вы не меня цитируете, а того мудака, который подписывался моим именем. Я зарегистрировался, чтоб в дальнейшем избавить вас от участи комментировать его словесный понос. Теперь по делу. Что касается фич и функциональности, то на http://www.kdevelop.org/index.html?filename=features.html достаточно подробно расписано то, мягко говоря, немногое, что умеет делать KDevelop. Что касается багов, то в более ранних версиях их было предостаточно. Грубо говоря, было непонятно, зачем нужен КДевелоп, если он для работы непригоден. Посмотреть, наверное, в ближайшее время не удастся. Гитару я себе купил новую. Плющит меня от нее и колбасит. Не до Линукса. Если вдруг затесались тут гитаристы, обратите пристальное внимание на Ibanez RG3120. Она стоит того.

да ну это 2.0
откуда он? на KDE CVS разработка 2.0 уже давно не идет
а идет 3.0
скоро будет =)

2 Bluezman: А чего такого особенного умеет Visual Studio? Может быть, в ней таки появился нормальный project manager? Или стало возможным 'подцепить' к ней другой компилятор? Или в ней появились вдруг нормальные средства для анализа исходников? А может быть, её 'визуальность' теперь не ограничивается редактором диалогов, и она (VS) стала напоминать, ну например, VisualAge?
Заметим, это я не в защиту KDevelop, которуй, действительно, так себе, а к тому, что Visual Studio -- не совсем верх совершенства...

2учитель музыки
>Нет, вот тут как раз KDevelop даст фору ЛЮБОМУ коммерческому продукту.

У вас, наверное, с логикой туговато или со знанием русского литературного. Я имею в виду именно это: KDevelop даст фору ЛЮБОМУ коммерческому продукту, т.е. остальным еще нагонять и нагонять.
а по поводу багов, это я про ВижувалВСтудии (для тех кто на бронепоезде)

2AC: "А чего такого особенного умеет Visual Studio"
Нормальный автокомплишен, в кдеволп кажется вообще ни какого нет. Хотя я где-то читал, что для кдевелоп плагин существует, но он просто запускает компиляцию и из map файла пытается сделать комплишен.
Потом еще умеет делать свертывание тела функции (кажется в новом vim такое тоже будет).
"Или стало возможным 'подцепить' к ней другой компилятор?"
Другой компилятор там всегда можно было подцепить, пример тому Интеловский С компилятор.

2 Ogr:
>Другой компилятор там всегда можно было подцепить, пример тому Интеловский С компилятор.

А borland-овский, или g++?:) Про Интел-овский компилятор я в курсе. Вопрос был в другом -- легко ли это сделать _самому_ и _быстро_. Мне почему-то кажется, что не совсем...

Да уж. [GNU/X] emacs давно умеет то, чему всяким MSVS да KDevelop ещё лет 10 учиться. Так за каким хреном такую парашу тогда пользовать? Сразу надо за Emacs браться.

Да уж. Более удобной связки, чем SourceNavigator + emacs, человечество ещё не придумало...:)

2Antichrist. А вот я замечательно пользую и Emacs и MSVC. Emacs вещь конечно хорошая, но зачем же стулья ломать? Крикун вы батенька.

2AC: "А borland-овский, или g++?:) Про Интел-овский компилятор я в курсе. Вопрос был в другом -- легко ли это сделать _самому_ и _быстро_."
Раз интел сделал, значит можно сделать с любым компилятором. Самый быстрый способ поставить интелевский и посмотреть какие значения в режестри меняются. Дел минут на 10 максимум.

Ну пиздец -- я еще в регистри ни лазил.

Пользую иногда 1.4 только в качестве редактора. Ввсе остальное приходится делать руками. Надеюсь 2.0 лучше :))

To Ogr:
>аз интел сделал, значит можно сделать с любым компилятором. Самый быстрый способ поставить интелевский и посмотреть какие значения в режестри меняются. Дел минут на 10 максимум.

Da-da-da, kak zhe... Vi, prezhde chem govorit', hotya bi na etot Intel'ovskii kompilyator posmotreli, i na to, _kak_ on integrirovan -- togda bi ne govorili, chto eto delo na 10 minut, i chto integration zavisit tol'ko ot kluchei v registry...

Да KDevelip действительно от нотепада недалеко ушел. Зато даром. А за очень дешево стоит посмотреть на CodeForge.

KDevelop нужно сравнивать скорее с Borland C++ 3.x, а не с VC++.

Назови хоть одну фичу в MSVC, которой не было бы в Emacs. И объясни, как ты умудряешься "работать" в MSVC, делая руками всё то, что любой умный и ленивый человек напрочь заавтоматизирует? Или вы, батенька, из той породы, что "не фиг думать, трясти надо!"?

А для emacsа нормальный completion появился? Единственное, что я видел на эту тему - нечто под названием X-Ref.

(Да, под нормальным completion я понимаю что-нибудь подобное реализованному в VisualSlick 6).

В МСВЦ удобный отладчик. А emacs+gdb/dbx в этом отношении сосет безмерно.

Отладчиков вообще не должно быть. Это лучший способ генерации новых багов.

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

Сама идеология итерационной отладки - глубоко порочна. Так что это даже хорошо, что под юниксы нет достаточно полнофункционального отладчика. Кстати, в MSVC его тоже нет - он там - всего лишь неуправляемая ГУЁвая параша, единственное преимущество коей - способность работать в многотредовом окружении.

P.S. А комплишены в Emacs таки есть. И не только XRef.

2 Antichrist: Что по-вашему "автоматизирует" Emacs и не автоматизирует MSVS?

2Antichrist.

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

Теперь про отладчик. Любой инструмент надо уметь использовать.

Я пишу сложную математику для CAD и CAM. Вы, уважаемый, как я понимаю при университете ошиваетсь, чистой наукой занимаетесь. Написал програмку, посчитал, построил графичек и конец. Не совпало - подогнал. В отличии от Ваших Микки-Маусовых поделок промышленная математика должна работать *надежно*. Я полагаю, Вам все-таки знакомы проблемы численных методов, связанные с плавающей точкой. Так вот, по моему опыту, почти любая процедура из книжки, написанная "учеными" вроде Вас загибается на файле с данными ~50Mb. Например, SVD (сингулярное разложение) из Linpacka сходится не всегда (а все другие версии дерут у них).

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

Пишется куча тестов: сравнение результатов с более простыми методами, особые случаи исходных данных, прогон больших объемов исходных данных (ночью). Программа наполнена ASSERT ами, и если ассерт срабатывает, то программа выпадает в отладчик, где можно посмотреть переменные. MSVC кстати очень прилично конфигурируется для представления структур в удобном виде, например три координаты вектора в одну строчку. Затем, можно переставить текущее место исполнения наверх и пройти подозрительную процедуру пошагово, или запустить ее с другими входными данными - очень ускоряет работу. Также в отладочном билде я люблю выводить во временные файлы всякую полезную информацию - разные промежуточные геометрические обьекты для изучения. Файлы постоянно перезаписываются, и двигаясь по брейкпойнтам удобно их последовательно просматривать.

Без отладчика понять *причину* проблем с плавающей точкой практически невозможно. Не использование отладчика приводит к тому, что люди сначала забивают код тысячами печатей, по сто раз пересобирают и в результате от отчаяния исправляют не причину ошибки, а фиксят результат (сроки поджимают!).

Еще важная фича. К чести МСВЦ, программа очень надежная и переносит мой глумеж весьма стойко. Только код с *очень* большим количеством STL откровенно плохо дебужится. Вероятно из-за ограничения на длину символа 256. DDD и КДевелоп (когда я их пробовал в прошлый раз) валились в моих руках на раз. Но на Кдевелоп я продолжаю посматривать с интересом. Года 4 назад я по служебной необходимости юзал всякие коммерческие среды и отладчики под PC Solaris, Irix и HP, но это были просто слезы.

К МСВЦ Емакс кстати неплохо цепляется. Есть всякие макросы, и т.д.

О чем это я все это? А, вспомнил! Скромнее надо быть, г-н Аньтихристь. IMHO.

> Написал програмку, посчитал, построил графичек и конец. Не совпало -
> подогнал. 

 Вот именно это и есть дебаговый подход, супротиво коего я выступаю.
В экспериментах, с коими я дело имею, как раз абсолютная надёжность
и требуется. ЕДИНСТВЕННЫЙ способ достижения надёжности - СТРОГОЕ
ДОКАЗАТЕЛЬСТВО кода. Дебаггеры тут просто ни в очко, ни в Красную
Армию. 


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

 Бред полнейший. Если известно, на что смотреть - а известно это
всегда в подобных случаях, то делаются ассерты. На то они и
существуют, чтоб срабатывать на НЕВОЗМОЖНЫХ при правильной работе
ситуациях. Как раз так дебильные опечатки и вылавливаются, а вовсе
не глазами.


> Пишется куча тестов: сравнение результатов с более простыми
> методами, особые случаи исходных данных, прогон больших
> объемов исходных данных (ночью).

 Тесты НИКОГДА не покрывают всех возможных неприятностей. Так
что блажь это, коммерсантишками выдуманная, и в серьёзной науке
абсолютно неуместная.

> Программа наполнена ASSERT ами, и если ассерт срабатывает,

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

> то программа выпадает в отладчик, где можно посмотреть переменные. 

 Ёкарный бабай, это ещё зачем?!? Какие переменные? За каким 
их "смотреть"?!? Умирать надо по ассерту - сам этот факт будет
достаточным - зная нарушенное условие, мы с очень большой точностью
знаем и причину ошибки. Естественно, это если ассерты формально
произведены были, а не от балды.

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

 Чушь. Это же математика, тут всё строго, никакой интуитивщины,
никаких итераций не предполагается. 

 Кстати, для укрепления и проверки подобных представлений
есть хорошая задачка:
имеется n-мерный вектор, представленный заведомо корректными машинными
вещественными числами. Требуется перечислить все критические
ситуации при вычислении его длины (которая так же, для упрощения
задачи, заведомо существует в машинном представлении и корректна).
Ручками такую задачу решать - закачаешься. Методами символьной
алгебры - как два пальца об асфальт.

К примеру, генерёжь документации в CWEB-mode, проверку ошибок, написание стандартных конструкций, интерфейс к системам проверки корректности кода, и т.п.

KDevelop

(Как в анекдоте) Алло !!! Это прачечная ? ......

KDevelop

(Как в анекдоте) Алло !!! Это прачечная ? ......

2Antichrist: Пардон что не в тему: посоветуй плз какую нибудь литературу по формальным методам отладки. А как-то пытался поискать, толком ничего подходящего не нашёл. С математикой у меня всё хорошо, только не знаю с какого конца взяться.... можно сюда - alexname@mail.ru

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

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

А чем мне не нравится МСВС -- так это отсутствием в компиляторе 80-битных long double. Иногда (очень редко) действительно нужно, на ассемблере приходится (приходилось, ушел я из Windows). Впрочем это характеристика транслятора а не среды разработки.

Ты что, с дуба упал?
Есть long double.

АAAAAAAAAAAA!!!!!

Пора линять на Линукс - http://www.billparish.com/msftfraudfacts.html

!!!!!

Bluesman

2Havoc sizeof(long double)>=sizeof(double)

для VC version >=4.0 sizeof(long double)=sizeof(double)= 8 b

или я не тупой?

Было много старой (~70 годы) литературы, но в электронном виде мне попадались только вот эти замечательные лекции, где в http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html Читать главу 7, "Proving programs correct".

А вообще всё просто, как паренные грабли: пишем спецификацию требуемых свойств алгоритма в декларативном виде (как набор отношений), пишем реализацию, и потом последовательностью преобразований приводим одно к другому - то есть, в точности как любую математическую теорему доказываем. Тот же самый набор свойств за компанию даёт нам все потребные ассерты.

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

 Садитесь, "неуд" в ведомость. Приходите на пересдачу.
 Приведу пример одной из критических ситуаций: i-я компонента
вектора существует и корректна, норма вектора существует и корректна,
ошибка в пределах машинной точности, но при этом квадрат i-й компоненты
НЕ СУЩЕСТВУЕТ, ибо overflow. Или же другой пример - потеря точности
при сложении квадратов i-й и j-й компонент.


 

2Havoc: sizeof(long double) == sizeof(double)

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

Господа emacs guru... Не сочтите за извращенца... Я xemacs 21.4 собрал с gnome... У меня в списке установленных пэкеджей mule есть, а менюшек егоных нет... Так и должно быть????
И кто-нибудь gtk-xemacs юзал? То, что у меня не всё работает - глюки мои или gtk версии??? (не работает как надо установка пэкэджей через инет, mule прячется)

Кстати, необходимые пэкэджи (mule-base, что-то там для сети) я поставил руками, как было написано на сайте... И xemacs собран с поддержкой mule.