Цитата(Любитель @  24.10.2006,  16:21 )

Кстати, так никто и не сказал, про дебаг не MinGW в C::B

Мда ребяты! IDE действительно неплохая. Смахивает на SlickEdit.
Хотелось чтоб вы затестили SlickEdit. Так как он ветеран в этой области. 
Уверен что "он" вам понравиться.

Ну, пока, видать... плагин дебага написан пока только для GDB..., насколько я понимаю...

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

В принципе написать плагиснкий фронт-энд не такая проблема. Можно задать вопрос по другому - есть ли бесплатные (виндовые) дебаггеры (про C++ конечно речь) не для MinGW? Правда, всё равно не вижу преимуществ перед студией (кроме, безусловно, небольшой    разнице в цене   )

Любитель,
Ну может, на Visual Assist и не катит...
Но...

В какой еще среде ты можешь сделать подстветку части ключевых слов С++ и (опциально) своих выделить другим цветом?
Мне, например, такая возможность очень понравилась 

Кроме того, последний Nightly Build ( напр. 23.10.2006 ) очень прибавил по сравнению с RC2:
Добавилась куча полезных опций, улучшился внешний вид и т.д.

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

Не поверишь - к примеру, VS.   

Лично я считаю, что настоящей IDE, написаный сипипишниками для их самих не будет, пока не будет доделан стандарт. Объективно, говоря, он не доделан. Понятия бинарных библиотек как такового нет, тем более динамических. Необходимо понятия на уровне компилятора и компоновщика (который тоже желательно во многом стандартизировать) проекта. Нечто вроде сборок в дотнете. Взаимодействие нескольких комплеров сегодня нормально невозможно - как минимум все по-разному декоратят имена функций, это необходимо стандартизировать. Многие упорно считают выходом extern "c", но это и близко не похоже на выход - это извращенье. Мы же пишем на плюсах! В идеале, хотелось бы стандартизировать формат дебаг-данных (хотя бы, чтобы каждый компилер поддерживал стандартный и опционально свой). Нету так же стандартного ГУИ. Знаю, что меня будут жестоко пинать - но его стандартизация объективно необходима. Это не обязывает вас его юзать, это обязывает разработчиков компилеров включать его в стандартную библиотеку. Как говорит сам Бьярни, если вы отказываетесь от стандартного ГУИ, то почему вас устраивает стандартизация контейнеров. Может она тоже не нужна? Ведь в своё время (до официального стандарта) почти каждая библиотека для C++ (особено речь о ГУИ-фреймворках) считала своим логам дать програмисту контейнеры. Причём разные... Не гуд. В плане библиотек огромные надежды вселяет буст - разговоры о Boost.GUI ведутся там частенько. Есть кстати предложение написать затем Boost IDE, с wave-препроцессором (опционально), bjam-билдингом (всё-таки я требую понятия проектов, сборок или чего-то в этом роде - т. е. конечной цели билдинга нескольких файлов) и пр. Это интересно. Но, повторюсь, для качественной реализации всего этого необходима гораздо более тщательная стандартизация языка (буст-девелоперы с этим согласны). Что ж, поживём - увидим.

Поверю... Только вот при этом занимает ли VS 12 Мб?
Установится ли она на Windows 95?

На предполагаем вопрос - "Зачем и кто сейчас работает на Windows95?" отвечаю:

Например, у нас в универе, на факультете прикладной математики... На этом г...е мы сдаем не только лабораторные работы, но еще и полноценные курсовые проекты...   

А теперь вопрос: кто угадает, в какой среде мы по-умолчанию изучаем великий и могучий язык С++?
Ответ: на Borland C++ 3.1 ( выход - 1989-1990 г. )

Какая еще более-менее нормальная среда туда станет?
VS, Builder, Eclipse, SlickEdit?   

Знаете, сколько оперативки на этих компах? - 32 Мб.
Затрата ресурсов по памяти у CB явно меньше...

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



P.S. Да, есть у нас компы и получше... Но эти-то никто не отменял...

Добавлено @ 16:05 
Любитель, 
А насчет стандартизации контейнеров ты не прав...

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

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

А если ты не в IDE работаешь? Ты просто пишешь проект, использующий ГУИ. Приносишь куды-нибудь.. ан-нет, твоей библиотечки тут нету. Не следует равнять IDE и GUI-библиотеку. Ещё раз подчеркну - это не только моё мнение, это мнение очень авторитетных сиплюплюсников.

Добавлено @ 16:32 
А вот на счёт твоего универа - жестоко, конечно. В нашем в некоторых аудиториях двухъядерники поставили с ЖК-мониторами   
Но все равно, если бы был стандартный ГУИ, поверь производительность его была бы хорошей => можно было даже самим (я вполне серьёзно) написать что-то пригодное для универа, но   используя нормальный компилер. Изучать С++ на доисторическом компилере - это очень неправильно с образовательной точки зрения. Тут дело уже не в IDE, а именно в компилере. Гораздо лучше, если бы вас заставляли писать в текстовых редакторах (благо хороших ноутпадов сейчас валом) и компилить командной строкой. Неудобно? Тогда добавить совсем миниатюрное приложение, которое управляло бы структурой проекта и позволяло одной кнопкой делать билд.

Даже нормальное эффективное консольное приложение необходимо отлаживать... делать это с помощью log'a в файл / на экран - уже отжило. Все-таки в этом плане CodeBlocks - неплохая вещь.

Насчет GUI не под IDE - это что, например? То, что нельзя с собой принести?

Насчет стандартизации GUI - извини, есть куча разных операционок, а также взглядов людей на то, как удобный IDE|GUI должен выглядеть/работать. ИМХО стандартный IDE|GUI - в теории неплохо, а на практике неприменимо.

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


Извини, не понял смсла фразы.


В каком? Как IDE для доисторических компов? Смоневаюсь, что ребята писали его с этой целью.

Кто его стандартизировал и на чем этот ГУИ написан? Запустится ли этот ГУИ в Линухах? FreeBSD?




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

В .NET - нет (извращенья вроде GTK# я не понимаю), в Java - безусловно.




Получаем: если комп нормальный, то ставим гораздо более навороченные VS или Eclipse. Они обладают ужасно богатыми возможностями и расширения (плагины, адд-ины - не всё ли равно?) под них писать естественно и удобно. Т. е. C::B вроде и не нужен. Получается, что главный аргумент в его пользу - эти самые доисторические компы. Или я тебя неправильно понял? Тогда объясни.

Ещё раз подчеркну - один из огромнейших недостатков C::B в слабости (да-да слабости) плагинского АПИ. Почему? Потому что нету:
1. Хорошо спроектированного ГУИ (не говорите мне, что wxWidgets хорошо спроектироdан - в жизни не поверю).
2. Стандарта для помещения классов и пр. в динамические библиотеки. Eclipse легко расширять, потому что в яве это стандартизировано. В плюсах нету - в итоге плагинское АПИ по стуи у C::B сишное (а не плюсовое). Не гуд, совсем не гуд...

Возвращаясь к стандартному ГУИ и кроссплатформенности. ОН должен быть кросплатформен на уровне интерфейса. Реализации без сомнения в разных ОС будут разными (да и то, при хорошем проектировании - лишь на уровне 'ядра' ГУИ). Посмотри на ту же всем известную кутеху. Хотя на стандартный ГУЙ она не потянет. Здесь и лицензионные проблемы и всё-таки то, что она во многом не соответствует духу текущей стандартной библиотеки. Во многом (что скрывать) пахнет той же явой, хотя я не говорю, что это какой-нибудь клон АВТ или Свинга (ни в коем случае), но в некоторых моментах проектирования библиотеки в целом (не конкретных моментов) мне кажется стандартный ГУИ (если бы он был) поступил бы по другому.

Насчёт образования. Почему я призываю вначале работать без IDE? Потому, что тогда обучаемый (я говорю про новичков в програмировании, коих немало, тебе универское обучение, вероятно, мало что способно дать) привыкнет к языку и поймёт язык. А не кнопочки в IDE. Тем не менее после изучения языка, надо научить основам работы с современными IDE. Такие будут:

1. С++: VS, Eclipse
2. .NET (C#, VB .NET): VS, Sharp Develop и (наверно) BDS (C# Builder)
3. Java: Eclipse, IntelliJ IDEA, Net Beans.

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



Мне не понравились ни VS, ни Eclipse... Хотя комп у меня дома стоит далеко не самый слабый - и VS, и Eclispe становились без проблем...
Лично я на ГУИ пишу очень мало ( когда это иногда надо, у меня стоит BDS 2006 Update 2, и вся недолга ). Поэтому меня C::B устраивает...


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

Ещё раз повторюсь, при хорошем подходе к ГУИ либе и проектированию ИДЕ, ГУИ с ИДЕ никак не связаны. Писать ГУИ без ИДе вполне нормально. Лично для меня ГУИ-дизайнеры в ИДЕ абсолютно не важны.

Добавлено @ 17:17 

Почему (оченб хотелось бы услышать конкретные замечания и претензии - действительно интересно)