[C++?] Серьезный вопрос.

В общем всё сходится. Я тестировал queue.h и tree.h несколько лет назад на древнем компиляторе, там сишные контейнеры позорно сливали. А сейчас значит оптимизацию улучшили и время получается примерно одинаковым.

>> нет, это долго и нудно

> иными словами - не можешь. ну, трепаться тоже дело полезное, глядишь в менеджеры возьмут :)

:)

>> кланяйся

> может ещё сплясать, а?

давай

>давай

тролли очень любят хумппу (c)

> дай другой test case и совершенный код на С

другой тест кейс:

сравнить производительность std::list с самописным списком заточенным под конкретную задачу, конкретный тип данных, и т.п. причем желательно сравнивать не только скорость, но и расход памяти, количество аллокаций, и т.п. и пофигу, на C или C++.

(я не собираюсь доказывать, что переписав std::list на C откуда-то возьмется прирост скорости. дураку понятно, что будет одинаково)

>> давай

> тролли очень любят хумппу (c)

не томи, танцуй ! :)

>> дай другой test case и совершенный код на С

>
другой тест кейс:

сравнить производительность std::list с самописным списком заточенным под конкретную задачу, конкретный тип данных, и т.п. причем желательно сравнивать не только скорость, но и расход памяти, количество аллокаций, и т.п. и пофигу, на C или C++.

(я не собираюсь доказывать, что переписав std::list на C откуда-то возьмется прирост скорости. дураку понятно, что будет одинаково)

--
есть у меня такое, но тебе не дам :), да там самописное быстрее, наверное, но и функционал там, совсем не такой :), да и мальчика не было.
То, что ты предложил, это - сравнить дяденьку и тетеньку - кто лучше.
кому как, кому как ;)

>не совсем так, в плюсах можно сделать так, что-бы треть объектов управлялось подсчетом ссылок,

Саттер советует всегда юзать shared_ptr и не пыжиться. Если бы shared_ptr был на уровне языка, скажем был бы счетчик ссылок в MCB или были бы две неявные виртуальные функции типа _Add_ref и _Release вдобавок к виртуальному деструктору, то этот совет сократился бы до просто "не пыжиться".

>треть могла перемещатся

Кури Стандарт.

>а треть управлялось по местоположению

http://yosefk.com/c++fqa/dtor.html#fqa-11.14

Мне добавить нечего.

>>типичная rt задача это кодирование видео, например. Количество ОЗУ необходимого для кодирования видео всегда обусловлено алгоритмом и известно наперед.

>а если раздавать его в сеть ? ;)

Что там с сетью? IGMP чтоли?

топикстартеру: изучать С++ стоит, равно как и другие языки. Чтобы понять их ограничения, и разные способы решения задач, ограничения технологии.
Язык С++ имеет много подводных камней, фактически сочетая три языка в одном: классический С, не самую гибкую объектную модель, язык шаблонов. С++ акцентирует внимание на синтаксисе и различных тонкостях, которые надо знать, чтобы обходить их ограничения.
Для понимания семантики, ограничения способа С++ решать задачи и его ограниченой семантики стоит изучать другие языки и их способы решать аналогичные задачи.

> а там самописное быстрее, наверное, но и функционал там, совсем не такой

функционал достаточный? работает быстрее? какие еще могут быть вопросы?

я как бы не утверждал, что c++ медленнее/быстрее чем c. они одинаковые по сути. везде можно одинаково быстро написать. речь за stl была.

>>не совсем так, в плюсах можно сделать так, что-бы треть объектов управлялось подсчетом ссылок,

>Саттер советует всегда юзать shared_ptr и не пыжиться. Если бы shared_ptr был на уровне языка, скажем был бы счетчик ссылок в MCB или были бы две неявные виртуальные функции типа _Add_ref и _Release вдобавок к виртуальному деструктору, то этот совет сократился бы до просто "не пыжиться".

:) Ленин был великим человеком :)

>> треть могла перемещатся

> Кури Стандарт.

>> а треть управлялось по местоположению
>> http://yosefk.com/c++fqa/dtor.html#fqa-11.14
>> Мне добавить нечего.


:) мда, и похоже, что гениальным человеком :)

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

> топикстартеру: изучать С++ стоит, равно как и другие языки. Чтобы понять их ограничения, и разные способы решения задач, ограничения технологии.
Язык С++ имеет много подводных камней, фактически сочетая три языка в одном: классический С, не самую гибкую объектную модель, язык шаблонов. С++ акцентирует внимание на синтаксисе и различных тонкостях, которые надо знать, чтобы обходить их ограничения.
Для понимания семантики, ограничения способа С++ решать задачи и его ограниченой семантики стоит изучать другие языки и их способы решать аналогичные задачи.

а еще будешь профессионально сратся на лоре :D

>Зато корки в Си исследовать проще. linuxfan оценил бы.

А почему никто не упомянул о сообщениях об ошибке? Имя типа в C++ может превышать 1kb.

>В данной ветке речь идет о применимости динамических коллекций в играх и rt-приложениях.

Я слышал, что существуют аллокаторы, выделяющие память за O(const). Что мешает использовать их?

а еще будешь профессионально сратся на лоре :D

Вот она - ниша С++, которую так долго искали! :)

>> а там самописное быстрее, наверное, но и функционал там, совсем не такой

> функционал достаточный? работает быстрее? какие еще могут быть вопросы?

> я как бы не утверждал, что c++ медленнее/быстрее чем c. они одинаковые по сути. везде можно одинаково быстро написать. речь за stl была.

и там шаблонов немерянно.
стандарт он на то и стандарт, что-бы приемлимо покрыть 80% случаев использования.
в 80% случаев stl ведет себя удовлетворительно.

наркоман штоле? ты чего отвечаешь не на то что цитируешь?

> Я слышал, что существуют аллокаторы, выделяющие память за O(const). Что мешает использовать их?

они не решают проблемы фрагментации.

>я как бы не утверждал, что c++ медленнее/быстрее чем c. они одинаковые по сути. везде можно одинаково быстро написать. речь за stl была.

Как бы можно и на асме писать и получать при этом результат еще на пару % быстрей, только и геморроя побольше будет. А для STL'ных контейнеров есть куча STL'ных алгоритмов, которые позволяют писать быстро, ясно и без страшных проседаний по производительности.

> Я слышал, что существуют аллокаторы, выделяющие память за O(const). Что мешает использовать их?

> они не решают проблемы фрагментации.

а был ли мальчик ?

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

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

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

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

займись продажей хотдогов :)

>> они не решают проблемы фрагментации.

>а был ли мальчик ?

В одном из тредов фигурировала карта памяти фаерфокса посла открытия и закрытия нескольких страниц. Размапить оказалось возможно только две страницы (памяти) размером в 4 кб.

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

Безусловно скрывает. Но знаешь, тем и отличается быдлокодер разумный от быдлокодера неразумного, что знает, что стоит за одними и теми же insert'ами и erase'ами.

Конечно, можно орать, что int fukken_fast_array[MAXSIZE] рвет std::vector<int> slow_stl_shit на добавлении элементов, а можно открыть для себя slow_stl_shit.reserve(MAXSIZE), algorithm и осознать, что контейнеры STL -- чертовски гибкая и удобная штука, которая при всех своих положитеьных качествах к тому же оказывается весьма быстрой.

> займись продажей хотдогов :)

ты идиот? я не использую стл. я говорю что происходит, когда его используют.

> я не использую стл. я говорю что происходит, когда его используют.

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

> Безусловно скрывает. Но знаешь, тем и отличается быдлокодер разумный от быдлокодера неразумного, что знает, что стоит за одними и теми же insert'ами и erase'ами.

на практике, "быдлокодеров неразумных" дохрена в любой крупной компании. и гораздо проще им запретить использовать stl, чем учить их как его правильно использовать (и когда его использовать не стоит).

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

>> займись продажей хотдогов :)

> ты идиот? я не использую стл. я говорю что происходит, когда его используют.

ясновидец детектед :D

> вы несете чушь, даже школьникам вроде меня это очевидно

куда уж мне до вас :)

> куда уж мне до вас :)

зря ерничаешь - тебе до меня действительно далеко

>таким как невозможность запустить игру на ритейловой консоли вообще :)

Проблемы владельцев недоPC меня волнуют меньше всего.

> зря ерничаешь - тебе до меня действительно далеко

А мне, а мне? =)

Публично отречься от префиксно-скобочного еретического учения, затем полгода молиться, поститься, слушать лекции Страуструпа, практиковать утреннее и вечернее чтение бытия святых отцов Мейерса и Александреску. И когда твой дух очистится от богохульной метафункциональщины, ты поймешь, что приблизился в своем духовном развитии к дъякону lester'у.

Сможешь ли ты его превзойти -- вопрос исключительно твоей духовной чистоты и внутренней решительности.

>> зря ерничаешь - тебе до меня действительно далеко

> А мне, а мне? =)

Тебе ближе. Где Дания и где Чехия...

>молиться, поститься, слушать лекции Страуструпа

за одну эту фразу готов простить все расхождения во мнениях :)))

> А мне, а мне? =)

далеко, но с другой стороны :)

>Проблемы владельцев недоPC меня волнуют меньше всего.

а что считать недо-, сверх- и просто PC?

чё , помирились ?
может лисп начнем мочить ?

> А мне, а мне? =)

чтоб не думали, что я про себя что-то возомнил, поясню - период написания поделок, вроде тех что у waker в блоге, у меня закончился еще лет 6-7 назад

> может лисп начнем мочить ?

а зачем? он никому не мешает

> чтоб не думали, что я про себя что-то возомнил, поясню - период написания поделок, вроде тех что у waker в блоге, у меня закончился еще лет 6-7 назад

может покажешь какую-нибудь из своих поделок, написанных 6-7 лет назад?

>> А мне, а мне? =)

> чтоб не думали, что я про себя что-то возомнил, поясню - период написания поделок, вроде тех что у waker в блоге, у меня закончился еще лет 6-7 назад

я до сих пор пишу, для себя, прояснить непонятки :)

>> может лисп начнем мочить ?

> а зачем? он никому не мешает

CAML , Haskell ?
хочу священную корову, что-бы убить ее и съесть

хотелось бы сравнить свой уровень с таким гуру как ты - будет на кого равняться

> может покажешь какую-нибудь из своих поделок, написанных 6-7 лет назад?

большая часть благополучно удалена, из того, что осталось на память - файл-менеджер написанный на паскале и "рисовалка формочек" для FLTK на С++ ( я уже постил скриншоты на ЛОРе, если есть желание - гугли )

>может лисп начнем мочить ?

начинай

Не, прикольнее было бы мочить Хаскель. Правда, у меня квалификации не хватает :/

>хочу священную корову, что-бы убить ее и съесть

Scala, Fan, Fortress. о последнем Kuka может много рассказать, что-то там насчёт high programmability

не следует изучать лисп
хотя-бы потому, что его не только __никто_ не знает, но никто и не использует

>Не, прикольнее было бы мочить Хаскель

дык выше по треду уже было. второй заход? ну, я не против если что :)

>Правда, у меня квалификации не хватает :/

не прибедняйся. мы, питонщеги,- огого! ;)

tailgunner:> Не, прикольнее было бы мочить Хаскель. Правда, у меня квалификации не хватает :/

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

jtootf:> Scala, Fan, Fortress. о последнем Kuka может много рассказать, что-то там насчёт high programmability

маленьких не ем

> может лисп начнем мочить ?

Осторожно! Треде присутствуют его неадекватные фоннаты!

>хотя-бы потому, что его не только __никто_ не знает

который из? если схему, то R5RS даже я более-менее знаю - а значит и любой школьник осилит

>никто и не использует

увы, у меня есть контрпримеры из родного города. пишут на CL и Scheme, вполне себе продакшен, на жизнь не жалуются