Здравствуйте, alex_public, Вы писали:

...
_>В итоге так и остался лидером Netbeans...

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

Можно вопрос что именно вы делаете с С++ что у вас обычная VS без помидоров тормозит?

Там где я сейчас старая версия софта использовавшая кутэ интелисенс убивала — факт. Но выкинули кутэ и все пучком . И это хорошо согласуется с моими наблюдениями что проще устранить то что мешает VS работать чем пытаться искать счастья на стороне.

Здравствуйте, Kswapd, Вы писали:

K>Предупреждал . CEDET — неюзабельная хрень. Даже забавно, сколько лет его разрабатывают, а не поймут, что парсить надо не ELisp'ом, а чем-то более быстрым.

Кстати, дело как раз не в самом парсинге, а в реакции. Т.е. я допустим согласен что бы оно парсило сложные библиотеки хоть несколько часов — всё равно это один раз. Но вот что бы по нажатию . или -> или ctrl+пробел срабатывало вообще без задержек, мгновенно. И вот как раз тут cedit ужасно себя проявил. В том же Нетбинсе задержка чувствуется, но как бы не мешающая работать, а только чуть раздражающая...

Здравствуйте, SleepyDrago, Вы писали:

SD>у меня есть нездоровые сомнения в том что программисты на java будут писать редактор заточенный на С++ и делать это регулярно обновляя его под все более сложные фичи.

Нуу например парсинг C++11 конструкций уже прикрутили, как раз в последнем релизе. Что меня очень порадовало, т.к. я уже перешёл на использование auto и т.п., а предыдущая версия подчёркивала это всё. )))

SD>Можно вопрос что именно вы делаете с С++ что у вас обычная VS без помидоров тормозит?

Эммм, а где я писал что VS тормозит? Как раз VS никогда у меня не тормозила, в том числе и вместе с VA. Меня не удовлетворяет функциональность их парсера/редактора. Т.е. даже VS+VA слабее чем редактор Нетбинса.

SD>Там где я сейчас старая версия софта использовавшая кутэ интелисенс убивала — факт. Но выкинули кутэ и все пучком . И это хорошо согласуется с моими наблюдениями что проще устранить то что мешает VS работать чем пытаться искать счастья на стороне.

Кстати, про QT не знаю точно — там же у них ещё своя надстройка над языком... Не знаю как сторонние редакторы к ней относятся. Но в любом случае у них в резерве есть QTCreator.

А мне для начал надо что бы Boost мог прожеваться. )))

Здравствуйте, Kswapd, Вы писали:

K>Но вот отсутствие в Eclipse возможности задать простой клавиатурный макрос — очень удивило.

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

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

И если даже введут ынтерпрайз-макросы, то можно будет повеситься: необходимо будет оформить километровую простыню из XML, реализовать свою фабрику макросов от AbstractMacroFactory (c разными вариантами политик управления макросами, причём для каждой work-директории своя фабрика), сам макрос должен быть наследован от AbstractMacro с реализацией не одного интерфейса. Макросом можно будет пользоваться только после прохождения unit-тестирования. Да, и не забыть про JavaDoc-документацию, она обязательно будет гармонично интегрироваться в общую документацию эклипса.
И при первом запуске макроса после нажатия шорката можно смело идти заваривать кофе.

Всё это конечно шутка, но доля плачевной правды в этом есть

Ты просто не открывал при помощи Нетбинса действительно большой проект. Я как то подбирал в чем же мне открывать огроменный проект в Mac OS X. Так вот, Нетбинс просто падал в процессе парсинга, Eclipse подтормаживал слегка, но работал, а SlickEdit летал, все парсил и вообще отлично работал. Но т.к. денег на лицензию мне было жалко, я писал в Vim.

Здравствуйте, kaa.python, Вы писали:

KP>Ты просто не открывал при помощи Нетбинса действительно большой проект.
Причём тут размер проекта? Пускай для начала хотя бы инклуды отпарсит нормально. Сам C++ с WinAPI (допустим) — это уже мегов 100 заголовков. Добавляем Boost, ещё пару библиотек — ещё мегов 50 добавляется, причём намного сложнее чем в WSDK. Вот если это всё нормально проанализируется, то значит парсер хороший. А что бы размер проекта существенно влиял на ситуацию, это он должен быть уже совсем огромный, за сотню мегов.

KP>Я как то подбирал в чем же мне открывать огроменный проект в Mac OS X. Так вот, Нетбинс просто падал в процессе парсинга, Eclipse подтормаживал слегка, но работал, а SlickEdit летал, все парсил и вообще отлично работал. Но т.к. денег на лицензию мне было жалко, я писал в Vim.

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

Эклипс тоже не вылетал сам, но иногда подвисал на сложных библиотеках, так что приходилось убивать. Причём как-то странно — иногда подвисал, а иногда нет. И когда отрабатывал, то показывал уже всё корректно.

SlickEdit я проверял — он парсит некорректно. Наверное тоже ctags внутри или что-то такое.

_>Причём тут размер проекта? Пускай для начала хотя бы инклуды отпарсит нормально. Сам C++ с WinAPI (допустим) — это уже мегов 100 заголовков. Добавляем Boost, ещё пару библиотек — ещё мегов 50 добавляется, причём намного сложнее чем в WSDK. Вот если это всё нормально проанализируется, то значит парсер хороший. А что бы размер проекта существенно влиял на ситуацию, это он должен быть уже совсем огромный, за сотню мегов.
А... я понял Мне просто для мелких проектиков за глаза хватает Vim-а и Grep, не говоря уж о cscope
_>Нетбинс у меня никогда не вылетал, только тормозил немного. Правда у меня стоит какой-то там тюнинг настроек JVM взяты по рекомендациям с их сайта.
К сожалению, на проекте размером в 2 гига, он встал в нехорошую позу
_>SlickEdit я проверял — он парсит некорректно. Наверное тоже ctags внутри или что-то такое.
Там своя парсилка, отлично работающая. Ну и 2 гига он в состоянии распарсить и потом по ним обеспечить навигацию без особых проблем. Кстати, а что ты там за ошибку парсинга нашел? Я им лет 5 назад активно пользовался и он все отлично парсил.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, jazzer, Вы писали:

J>>У него там то же самый ctags

_>В каком смысле тот же самый? ) Ну и кстати ctags же только создаёт базу. А вот как в ней искать... Т.е. в этой области важен именно момент подсказки (бесит когда тормозит тут), а парсить исходники оно сколько угодно может, не жалко)))

Я поступил просто. Написал мелкую-мелкую утилитку, которая делает следующее:
1) От текущего каталога, спускается к корню диска и ищет ctags-овскую базу.
2) Найдя ее, ищет в ней все совпадающие теги и печатает их на stdout. Формат вывода совпадает с форматом сообщений об ошибках компилятора VC

Как эта штука используется:
— в корне проекта командой "ctags -R" создается база тегов.
— утилита вешается на горячую кнопку как custom tool и вываливает теги в окно вывода.

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

Вот как выгдядит output:

> "d:\tools\ftag.exe" coroutine
D:\prj\libs\corlib\coroutine.hpp:280: function public coroutine::coroutine()
    /^    coroutine()$/
    language=C++;class=coroutine;access=public;signature=()
D:\prj\libs\corlib\coroutine.hpp:348: function public coroutine::coroutine(Function PXT_RREF f, std::size_t stack=0)
    /^    coroutine(Function PXT_RREF f, std::size_t stack=0)$/
    language=C++;class=coroutine;access=public;signature=(Function PXT_RREF f, std::size_t stack=0)
D:\prj\libs\corlib\coroutine.hpp:301: function public coroutine::coroutine(coroutine const& rhs)
    /^    coroutine(coroutine const& rhs)$/
    language=C++;class=coroutine;access=public;signature=(coroutine const& rhs)
D:\prj\libs\corlib\coroutine.hpp:307: function public coroutine::coroutine(coroutine& rhs)
    /^    coroutine(coroutine& rhs)$/
    language=C++;class=coroutine;access=public;signature=(coroutine& rhs)
D:\prj\libs\corlib\coroutine.hpp:312: function public coroutine::coroutine(coroutine&& rhs)
    /^    coroutine(coroutine&& rhs)$/
    language=C++;class=coroutine;access=public;signature=(coroutine&& rhs)
D:\prj\libs\corlib\coroutine.hpp:238: class coroutine
    /^class coroutine$/
    language=C++;inherits=impl_coroutine::coroutine_value

> Process Exit Code: 0
> Time Taken: 00:00

Ну, и исходники самой тулзины (надо, чтобы исходники ctags валялись где-то рядом)

//CC VC-10
//G++-FLAGS -O0 -g -- -lboost_filesystem-mgw45-mt-1_44 -lboost_system-mgw45-mt-1_44
//VC-FLAGS -MT -O2 -EHsc
#include <string.h>
#include <iostream>
#include <boost/filesystem.hpp>
#include "../3rdparty/ctags-5.8/readtags.h"

namespace fs = boost::filesystem;
using fs::path;

std::string
tagfile_find(path curdir = fs::current_path<path>())
{
    static const char* tagfile_names[] = {
        "tags", ".tags", "ctagsdb", ".ctagsdb", 0
    };
over:
    if( curdir.empty() )
        return std::string();
    for(int i=0; tagfile_names[i]; ++i)
    {
        path f = curdir / tagfile_names[i];
        if( fs::is_regular_file(f) )
            return f.file_string();
    }
    curdir = curdir.parent_path();
    goto over;
}

std::string
lookup_field(tagEntry const& entry, const char* name)
{
    for(int f=0;  f < entry.fields.count;  ++f)
    {
        if( 0 == strcmp(entry.fields.list[f].key, name) )
            return entry.fields.list[f].value;
    }
    return std::string();
}

std::string
build_name(tagEntry const& entry)
{
    const char *scope_delimiter = "::";

    std::string access    = lookup_field(entry, "access");
    std::string namesp    = lookup_field(entry, "namespace");
    std::string scope1    = lookup_field(entry, "class");
    std::string scope2    = lookup_field(entry, "struct");
    std::string signature = lookup_field(entry, "signature");

    std::string name      = std::string(entry.name) + signature;

    if( !access.empty() )
        access += ' ';
    if( !namesp.empty() )
        namesp += scope_delimiter;
    if( !scope1.empty() )
        scope1 += scope_delimiter;
    if( !scope2.empty() )
        scope2 += scope_delimiter;

    return access + namesp + scope1 + scope2 + name;
}

int main(int argc, char **argv)
{
    std::string tagfile_name = tagfile_find();
    if( tagfile_name.empty() ) {
        std::cerr << "tag file not found" << std::endl;
        return -1;
    }

    std::vector<std::string> tags;
    path basepath = path(tagfile_name).parent_path();

    int options = 0;
    for(int i=1; i<argc; ++i)
    {
        if( '-' == argv[i][0] ) {
            if( 0 == strcmp(argv[i]+1, "i") ) {
                options |= TAG_IGNORECASE;
            } else
            if( 0 == strcmp(argv[i]+1, "p") ) {
                options |= TAG_PARTIALMATCH;
            }
        } else
            tags.push_back(argv[i]);
    }

    if( !tags.size() )
        return 0;

    tagFileInfo info;
    tagFile *const file = tagsOpen (tagfile_name.c_str(), &info);
    if( !file )    {
        std::cerr << "cannot open tag file " << tagfile_name << std::endl;
        return -1;
    }

    for(int i=0; i<tags.size(); ++i) {
        tagEntry entry;
        if( TagSuccess != tagsFind(file, &entry, tags[i].c_str(), options))
            continue;
        do {
            std::string fname = fs::system_complete(basepath / entry.file).file_string();

            std::cout
                << fname << ':' << entry.address.lineNumber << ':' << ' ' << entry.kind
                    << ' ' << build_name(entry) << std::endl
                << '\t' << entry.address.pattern << std::endl;
            if( entry.fields.count )
                std::cout << '\t';
            for(int f=0;  f < entry.fields.count;  ++f) {
                std::cout
                    << entry.fields.list[f].key << '=' << entry.fields.list[f].value
                    << (f < entry.fields.count-1 ? ';' : '\n');
            }

        } while(TagSuccess == tagsFindNext(file, &entry));
    }
}

#include "../3rdparty/ctags-5.8/readtags.c"

PSV>Здравствуйте, Kswapd, Вы писали:

K>>Но вот отсутствие в Eclipse возможности задать простой клавиатурный макрос — очень удивило.

Дополню юмор.

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

В других IDE ситуация не на много лучше. Общая тормознутость и прожорливость системы, неудобство среды в плане и пользовательского интерфейса, и в принципах управления средой (на фоне вима/эмакса) — напрочь отбивают желание что-то "совершенствовать".

И вопросик по делу.

Я пользовался плагином KeySnail для firefox — некий вимператор в стиле эмакса (кстати весьма рекомендую как эмаксоводу). Он может коннектиться к эмаксу из фокса для правки текста. Здесь на форуме вспомнился eclim. Я его руками не щупал, но похоже такие техники взаимодействия имеют рациональные зерна. Я как-то пытался найти нечто похожее для JEdit (он тоже может работать в режимах клиент/сервер как эмакс), но ничего не нашёл, что не удивительно. А для эмакса какой-нибудь "eclim" попадался на глаза?

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, SleepyDrago, Вы писали:

...
SD>>Можно вопрос что именно вы делаете с С++ что у вас обычная VS без помидоров тормозит?

_>Эммм, а где я писал что VS тормозит? Как раз VS никогда у меня не тормозила, в том числе и вместе с VA. Меня не удовлетворяет функциональность их парсера/редактора. Т.е. даже VS+VA слабее чем редактор Нетбинса.

...
_>А мне для начал надо что бы Boost мог прожеваться. )))

Это уже интересно А расскажите-ка пожалуйста простым пользователям VS чего у них нет. Так сказать на личных примерах.

Здравствуйте, alex_public, Вы писали:

_>Эммм, а где я писал что VS тормозит? Как раз VS никогда у меня не тормозила, в том числе и вместе с VA. Меня не удовлетворяет функциональность их парсера/редактора. Т.е. даже VS+VA слабее чем редактор Нетбинса.

Я в С++ не супер-спец, но у меня давно сложился стереотип, который пока не опровергнут — в плане именно IDE для С++ лучше студии пока ничего нет, особенно если смотреть комплексно. Ну, может, про SlickEdit слухи давно ходили, но я его в глаза никогда не видел, не было потребностей.

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

Кстати, почему то про IDEA не вспомнили, у них тоже какой-то плагин есть.

Здравствуйте, kaa.python, Вы писали:

KP>Плюсы он разбирает на порядок лучше эклипса. Твое пожелание разбора плюсов совсем уж просто редакторы из списка альтернатив исключает.
KP>А так, я бы взял Vim+Cscope и не парился, но тебя же такой вариант врятли устроит.

Какие преимущества даёт Cscope перед ctags?

Здравствуйте, monax, Вы писали:

M>Какие преимущества даёт Cscope перед ctags?

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

Здравствуйте, monax, Вы писали:

M>Какие преимущества даёт Cscope перед ctags?

Насколько я понимаю, ключевое отличие Cscope, как и GNU GLOBAL, от ctags это то, что кроме базы идентификаторов они дают инфу по зависимостям: кто кого вызывает. Но С++ они парсят хуже, чем ctags.

Здравствуйте, kaa.python, Вы писали:

KP>К сожалению, на проекте размером в 2 гига, он встал в нехорошую позу

Ого, 2 гига только исходников? Я с такими не работал. ) В моём понимание уже за 100 мегов исходников — это большой проект. А 2 гига... Интересно, что за проект такой...

_>>SlickEdit я проверял — он парсит некорректно. Наверное тоже ctags внутри или что-то такое.
KP>Там своя парсилка, отлично работающая. Ну и 2 гига он в состоянии распарсить и потом по ним обеспечить навигацию без особых проблем. Кстати, а что ты там за ошибку парсинга нашел? Я им лет 5 назад активно пользовался и он все отлично парсил.

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

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Я поступил просто. Написал мелкую-мелкую утилитку, которая делает следующее:
DEA>...

Офигеть. )))

Здравствуйте, SleepyDrago, Вы писали:

SD>Это уже интересно А расскажите-ка пожалуйста простым пользователям VS чего у них нет. Так сказать на личных примерах.

Нууу тут можно много говорить. Для начала хотя бы зайдите в настройки подсветки синтаксиса C++ в VS, Эклипсе и Нетбинсе. И сравните количество сущностей, которым можно назначить разные цвета. Это так сказать простейший пример из самого базового. А дальше там уже много можно говорить про навиагацию, форматирование, автодополнение, рефакторинг...

Здравствуйте, PSV100, Вы писали:

PSV>Я в С++ не супер-спец, но у меня давно сложился стереотип, который пока не опровергнут — в плане именно IDE для С++ лучше студии пока ничего нет, особенно если смотреть комплексно. Ну, может, про SlickEdit слухи давно ходили, но я его в глаза никогда не видел, не было потребностей.

Мммм ну как IDE пожалуй так есть, если рассматривать весь комплекс функций и в интеграции между собой. Но это выходит только если использовать во всём технологии MS. А если вы используете сторонние системы сборки, контроля версии, командной работы, отладчики, редакторы GUI и т.п., то от VS остаётся по сути только редактор кода, а вот как раз он уступает и Эклипсу и Нетбинсу.

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

А вот компилятор мы используем как раз от MS (из WSDK) — он приятнее чем GCC во многом. Разве что модного for'a ещё нет.

Здравствуйте, PSV100, Вы писали:

PSV>Кстати, почему то про IDEA не вспомнили, у них тоже какой-то плагин есть.

Мы пробовали. Всё же IDEA — для Java и это чувствуется. ))) Сейчас уже не помню в деталях почему его отбросили, но вердикт был такой: идеальная среда для Java, но для C++ не то совсем.