Vim это хорошо, конечно... Однако, мне показалось или ты действительно передаёшь вектор по значению??? Сурово.

Хорошая ИДЕ, для тех, у кого нет Visual SlickEdit

Нормальный вим в сто раз лучше!!! гвим - ацтой!

А как VIM парсит файлы C++, нормально? (я имею в виду быстрый переход на функцию или прототип из дерева). Я использую Emacs и он это, честно говоря, делает не очень умно :-( Хотя я эту фичу и не использую практически ;-)

>Хорошая ИДЕ, для тех, у кого нет Visual SlickEdit

Не могу не согласиться :)

А что это за Visual SlickEdit?? Мож скриншот кто пришлет?? А то в емаксе немного надоело ф-ции отлавливать без наглядного представления структуры класса тоже плоховато...

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

Наглядное представление есть, называется Speedbar

На левом сплите, это что? Это как?
>> Нормальный вим в сто раз лучше!!! гвим - ацтой!
Это чем? Простите...

На левом сплите, это что? Это как?
>> Нормальный вим в сто раз лучше!!! гвим - ацтой!
Это чем? Простите...

А скрещивал ли кто-то taglist.vim с Project.vim?

2TaSSaDaR

>>А что это за Visual SlickEdit?? Мож скриншот кто пришлет??

Я поставил в очередь скрин с моего текущего десктопа - если
админы не удалят - увидиш ;)

Я там правда немного прогнал в комментарии про обновления

вышла версия 7.0x смотреть тут http://www.slickedit.com

там дают триал версии ...

> Однако, мне показалось или ты действительно передаёшь вектор по
> значению??? Сурово.

Если вектор реализован нормально - то в чем проблема? Накладных расходов - увеличить-уменьшить счетчик ссылок.

>Если вектор реализован нормально - то в чем проблема? Накладных расходов - увеличить-уменьшить счетчик ссылок.

А не фигню ли Вы порете, уважаемый anonymous? :)))

>Если вектор реализован нормально - то в чем проблема? Накладных расходов - увеличить-уменьшить счетчик ссылок.

Да проблемы нет, даже если передавать мегабайты при каждом вызове функции, современное железо и не такое сожрёт :))). Неаккуратно это, как минимум.

Расскажите, как vim настроить так красиво... может где-нибудь дока есть подходящая? Спасибо...

Про вектора

2 hbee

Дык этот вектор - это ж не std::vector<чего-то-там> Это некоторая простейшая реализация вектора в стандартном D-мерном пространстве Минковского,по сути - GiNaC::ex и GiNaC::varidx с со всеми общепринятыми в линейной алгебре операциями.

Писалось это под такую задачу. Есть у меня выражение с матрицами Дирака:

\hat{k_1} \gamma_\mu \gamma_\rho \hat{k_2} % и еще штук 10

+ % еще несколько десятков таких слагаемых, где гамма-матрицы

% расставлены в другом порядке

Надо преобразовать к максимально простому виду. Но писать каждый раз

indexed(k+k1,varidx mu(D,sym_mu("mu")))

мне лень, поэтому я быстренько написал класс.

2 anonymous (*) (2002-08-23 16:44:28.659)

> Если вектор реализован нормально - то в чем проблема? Накладных

> расходов - увеличить-уменьшить счетчик ссылок.

Если я не ошибаюсь, то при передаче по значению создается временный объект, куда все копируется. Так что для более сложной задачи надо бы по ссылке передавать. Моего lorentz_vector это тоже касается, так как количество слагаемых в sym_rep ограничено только физическими ресурсами машины

2 anonymous (*) (2002-08-23 14:18:10.921)

> Хорошая ИДЕ, для тех, у кого нет Visual SlickEdit

А ctags или что-то подобное там есть? И вставить в него свою схему подсветки синтаксиса можно?

А подсветка синаксиса для LaTeX, FORTRAN, Form, скриптов,конфигов имеется?

2 anonymous (*) (2002-08-23 14:33:09.489) Дак парсит-то не vim, а ctags.

2 sS > там дают триал версии ...

Дак оно еще мне мозги парить будет, чтоб я за него денег заплатил?! "Зина, там на тумбочке книга лежит, переписка Энгельса с этим, как его черта... не важно. В печку ее, в печку!" (C) проф. Преображенский.

все клево тока как сделано то что в левом сплите??????

Как настроить vim

Предварительные требования: (g)vim и ctags-exuberant

Часть 1:

прописать в gtkrc "правильные" шрифты. Это обсуждалось, например, здесь http://www.linux.org.ru/jump-message.jsp?msgid=217310

Часть 2: скачать vim-scripts

taglist vim:

http://vim.sourceforge.net/script.php?script_id=273

ls.vim:

http://vim.sourceforge.net/script.php?script_id=17

и еще можно bufexplorer:

http://vim.sourceforge.net/script.php?script_id=42

Часть 3:

Почитать прилагаемые к скриптам доки - и вперед!

Happy VIMing!

2 DSelect & hbee

Если объект передается по значению для него вызывается конструктор копии. Все. Ни больше ни меньнше.
Конечно может найтись идиот, который реализует вектор таким образом, что при этом будут копироваться все данные - но это клинический случай.
Приличные люди, как правило, такие вещи реализуют через подсчет ссылок. Т.е. при вызове конструктора копии лишь увеличивается счетчик ссылок на данные, а настоящее копирование происходит (или не происходит) позже при вызове к.н. модификатора (нет вызова - нет лишней работы). Эта техника, в частности, позволяет и возвращать объекты, как результат функции. Класс string (и его различные вариации) таким образом реализуют с доисторических времен.
Конечно корректней передавать const ссылку на объект, но в данном случае это не принципиально.

Уважаемый anonimous, порящий фигню.

2Deselect:

Cходи по ссылке на их сайт да посмотри ... все там есть + такое про
что другие IDE могут только мечтать ... если лень - вот ссылка на мой шот
http://www.linux.org.ru/gallery/big7j3vTN.png

>Если объект передается по значению для него вызывается конструктор копии.

Кто-то утверждал обратное? Но получается, что автор функции должен делать какие-то предположения о реализации передаваемых объектов, что неправильно со всех философских точек зрения :)))

За "фигню" прошу прощения. Я был неправ.

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

да и вообще сама идея счетчика ссылок в векторе мне представляется как-то оч-чень сомнительной. вектор это вектор. если нужно счетчик ссылок организовать - заворачивай вектор в boost::shared_ptr и т.п.

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

Если нету - значит реализация ненормальная. (Точнее сказать чудовищная)

> да и вообще сама идея счетчика ссылок в векторе мне представляется
> как-то оч-чень сомнительной. вектор это вектор. если нужно счетчик
> ссылок организовать - заворачивай вектор в boost::shared_ptr и т.п.

Ага - значит интерфейс внутри, а реализация снаружи? Браво.
Вектор должен выполнять определенный набор операций. Как он их будет делать - его проблемы, но он должен их делать максимально эффективно. От того что в его реализации будет подсчет ссылок или еще какая-нибудь фигня, operator [] (int index) ведь не пропадет?

2 motus

>ага, счетчик ссылок, щаз. :) для этого как минимум нужно констркуктор

>копирования соответствующий написать. которого нету, кстати :)

Есть, еще как! Только он спрятан в

GINAC_IMPLEMENT_REGISTERED_CLASS(lorentz_vector,basic)

И copy at use тоже есть - сегодня я порылся в GiNaC'-овых header'-ах и выяснил это. Так что в данном случае все равно как передавать.

еще раз про векторы и про IDE

2 hbee

>Но получается, что автор функции должен делать какие-то предположения

> о реализации передаваемых объектов, что неправильно со всех

> философских точек зрения :)))

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

Хотя в моем случае это не существенно - мре просто надо быстренько посчитать одну вещь, да и все. А maxima и Form с ней не справились, вот я по быстрому наваял программку.

2 anonymous (*) (2002-08-23 20:22:30.614)

Да нету у этого вектора никаких operator[](int) ! Говорю же - это не std::vector<...>! Это тот вектор, который в линейной алгебре и в теории относительности - лоренцев вектор, он и называется так.

2 sS

Размалевано-то как... А по существу - тот же cscope. Кстати, и к нему есть в vim plugin.

Да все это есть и в Kdevelop, и в anjuta. Только там редактор шибко неудобный - комбинации клавиш там придумал какой-то представитель сексуальных меньшинств. Ежели б в Kdevelop или anjuta был в качестве редактора vim, их можно было бы использовать. А так - "...В печку ее, в печку".

Все эти slickedit, Kdevelop, anjuta,... работают только под X'-ами и занимают весьма немало места. vim работает и в консоли.

В адрес Kdevelop и anjuta могу еще вот что сказать: на кой мне нужны Qt designer или Glade?! Все, что я пишу, в консоли работает ( зачем счетной программе GUI?)

>> да и вообще сама идея счетчика ссылок в векторе мне представляется
>> как-то оч-чень сомнительной. вектор это вектор. если нужно счетчик
>> ссылок организовать - заворачивай вектор в boost::shared_ptr и
>> т.п.

> Ага - значит интерфейс внутри, а реализация снаружи? Браво.
> Вектор должен выполнять определенный набор операций. Как он их
> будет делать - его проблемы, но он должен их делать максимально
> эффективно. От того что в его реализации будет подсчет ссылок или
> еще какая-нибудь фигня, operator [] (int index) ведь не пропадет?

режьте меня, но не пойму как подсчет ссылок относится к
функциональности вектора. что, без подсчета ссылок и вектор уже не
вектор? не спорю, что для какого-то конкретного случая подсчет ссылок
внутри жирного класса это хорошая идея. точно так же как и
синхронизация доступа к элементам контейнера, например. но в том же
std::vector нет (в известных мне реализациях) ни первого, ни второго,
и никто не жалуется. да и в любом случае, наличие хоть супер-пупер
счетчика ссылок внутри класса не дает повода передавать такой объект
по значению где ни попадя.

ЗЫ а vim рулит, это правда :) нужно и себе такой иде прикрутить
попробовать.

Цветовая схема мне не нравится, у меня лучше. ;-) А вот что это в левом сплите и как это включить?

Эх ребята, жалко мне вас. Вы не работали с Source Insight. Все остальное сурово сосет по сравнению с этой тулзой. Не знаю, правда, есть ли она под Linux.

2 motus

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

В STL вектор реализован по другому? Это проблемы библиотеки.

2 Dselect

operator [] (int index) был приведен для примера, как наиболее характерная операция для вектора.

> ..реализация со счетчиком ссылок или без него не сделает из вектора
> что нибудь другое.
>
> В STL вектор реализован по другому? Это проблемы библиотеки.

это не проблемы библиотеки. в политбюро не дураки сидят. :)

для вектора reference counting не критичен, как, например, для строки,
и я уверен, что найдется масса народу, которым подсчет ссылок в векторе
только мешает. а кому надо - тот вектор завернет в smart pointer и
никаких проблем.

имно не нужно засовывать в объект фичи, которые реально нужны в 1%
случаев. классический пример - джавовские Vector и ArrayList и
синхронизация.

2motus

Естественно это все имхо, а разве бывает иначе?

ВСЕ объекты должны быть дескрипторного типа: с реализацией счетчика ссылок, записи-в-копию и sizeof такой, чтоб влезал в регистр (т.е. всех данных - указатель, даже без vtable ptr). Все, что можно использовать от С++ - это краткость записи + возможность обходиться без макросов, т.е. все методы класса - inline wrappers размером в пару строчек. Вся реальная работа делается в реализации ручками - включая имитацию vtable как надо и т.д. По моему это единственная возможность написать что-нить эффективное на С++.

STL красиво выглядит в книжке Страуструпа, а вот как выглядит код, который gcc выблевывает после компиляции простейщих примеров с ее использованием?

P.S. Даешь perl run-time как либу к С++! ;)

2motus тебе же уже была названа главная (и по моим размышлениям, единственная) причина почему так делают -- нужно возвращать по значению (например из operator+). Никак иначе. Так как предлагаешь ты, базовая структура будет делать лишнее копирование -- и компилятору ОЧЕНЬ сложно сообразить что его можно оптимизировать.

Поэтому там где это нужно -- структуры типа big_int, таких вот "алгебраических" векторов -- реализуют исходно со счетчиком.

2anonymous:

поздравляю с изобретением велосипеда :) ваш "дескрипторный тип" - не
что иное, как pimpl+reference counter. читайте книжки. а насчет
"имитации vtable как надо" вообще умолчу. закат солнца вручную.

а STL не трогайте. во-первых, потому, что с ним имно код пишется и
читается ДЕЙСТВИТЕЛЬНО очень приятно, а во-вторых потому что
темплейты по определению инлайнятся и уже поэтому хорошо поддаются
оптимизации. любимый пример самого Страуструпа, приводимый им почти
на каждой лекции - сишный qsort() супротив алгоритма STL. да и вообще
имно в наше время трудно найти человека, которого не устраивала бы
производительность плюсового кода. по сравнению с джавой все и так
летает :) а кернел, драйвера или DSP какой-нибудь на ++ никто и не
пишет.

2dilmah:

согласен на 100%. если есть операторы и вообще объект предполагается
часто возвращать как результат - все так и должно быть. примеру из
скриншота подсчет ссылок не помешает, да. хотя все равно по значению
передавать const параметр в метод это дурной тон. а реально - много
ли у вас объектов, для которых действительно нужна перегрузка кучи
операторов? у меня - нет :) а если таких методов один-два - зачем
огород городить? например, factory метод возвращает auto_ptr, и все
довольны.

2motus

Я согласен, что шутка получилась недостаточно смешная, но к чему так напрягаться? Видимо STL - ваше больное место.

Действительно, STL - лучшая из библиотек, претендовавших на место стандартной, ну и что? Это называется "лучшая из худших"? Почти любой крупный проект начинается с того, что стандартную библиотеку выбрасывают и пишут свою.

STL выглядит попыткой имитировать на С++ какой-то другой язык, но если не нравятся идиомы С++, сложившиеся за 20 лет, то сделай новый язык с нуля, а не уродуй старый. (То что это делает сам автор языка ситуацию не смягчает.) STL в С++ так же чужеродна, как были бы куски lisp, perl, forth и т.д.

Насчет компиляции: вы мне говорите как должно быть, а я вам как есть на самом деле. Можно, конечно, сказать, что это проблемы компилятора, но факт остается фактом - пока нет возможности получать чистый и быстрый код используя STL. Эффективностью в данном случае нельзя пренебрегать, т.к. Страуструп (насколько я понял из Книги) позиционирует STL чуть ли не как замену встроенным типам. Из таких "кирпичей" (круглой формы, весом в полтонны, да еще и на липучках) хрен построишь что-нибудь аккуратное.

P.S. По поводу самоката - я и не претендую на оригинальность, да и пробелы в образовании имеются.

Хуйня всё это !
FTE рулит всё предельно просто и никакого маразма.

> закат солнца вручную
Машнина слушаешь или случайное совпадение?

2Dselect (*)
>2 sS 

>Размалевано-то как... 
Вообще то там все довольно скромно :) это типичная рабочая ситуация
можне действительно сделать "размалевано" просто лень :)

>А по существу - тот же cscope. Кстати, и к нему есть в vim plugin. 

>Да все это есть и в Kdevelop, и в anjuta. Только там редактор шибко неудобный - комбинации клавиш там придумал какой-то представитель сексуальных
>меньшинств. Ежели б в Kdevelop или anjuta был в качестве редактора vim, их можно было бы использовать. А так - "...В печку ее, в печку". 

>Все эти slickedit, Kdevelop, anjuta,... работают только под X'-ами и занимают весьма немало места. vim работает и в консоли. 

>В адрес Kdevelop и anjuta могу еще вот что сказать: на кой мне нужны Qt designer или Glade?! Все, что я пишу, в консоли работает ( зачем счетной программе
>GUI?) 

1) То что там висит в vse тоже счетная задача (под консоль) или точнее библиотека - а для машинок под
счетные задачи какие то там X-ы это вообще не задача а так, баловство ..
так что извини - но СЕЙЧАС IDE под консоль это бред (религиозный)
2) На шоте не видно и 1 % возможностей vse, кстати vse тоже не завязан на конкретную
GUI библиотеку - это именно IDE который можно настроить как угодно
(в комплекте уже идут настройки под 30 языков но можно добавить и свои)
3) Про это вообще не интересно рассказывать это надо ПОПРОБОВАТЬ
по шоту это действительно мало чем отличается от KDevelop или anjuta
шоб понять ЧТО это такое - надо там ПОРАБОТАТЬ ...

сорри за излишнюю эмоциональность в отношении STL :) просто я с ним работаю, и надо признать, что плюсов там больше чем минусов. более того, если что-то можно сделать стандартным способом, то зачем искать другие пути? а чего не хватает в STL, наверняка можно найти в boost или например ACE.

по поводу производительности: если с одной стороны CORBA, а с другой - Oracle, то С++ летает по определению. :) может, у кого-то другие задачи, но я давно уже перестал заморачиваться по поводу того, какой код генерит компилятор. часто простор для оптимизации находится прежде всего в собственном коде :) имно кому нужна оптимизация на уровне ассемблера, тот на С++ не пишет :)

по поводу того, что Страуструп пердлагает STL как замену стандартным типам: стандартных типов не так много, и кроме строки и массива я не вижу ничего что можно было бы заменить. а std::string и std::vector имно вполне достойная им замена.

по поводу чужеродности STL: есть Object-Oriented Programming, а есть Generic Programming. STL построена в основном на втором подходе, и вообще все нынешнее развитие С++ идет больше в направлении GP. нужно это понимать и грамотно сочетать обе идеологии.

> имно кому нужна оптимизация на уровне ассемблера, > тот на С++ не пишет :)

по моему ты просто обижаешь Строструпа. Те люди о которых ты говоришь пишут на С++ скорее случайно, они с равным успехом могли бы писать на других языках.