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

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

> Все перечисленное тобой замечательно "подтекает"

Не верю.

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

Это из-за того, что очки нашла мартышка.

> boost::function и boost::bind тоже попортили немало крови, когда некоторые особо фанатичные плюсовики херачили их куда ни попадя. В итоге получалось идеологически клево: логика разорвана в клочья и разбросана по разным областям исходного кода, зато удалось натянуть задачу на какой-нибудь клевый паттерн, вычитанный кодером прошлой ночью. Буээээ...

См. выше. Такая ситуация возникает, когда малограмотные фоннаты крестов начинают штудировать boost.org на предмет, чего бы ещё такого заюзать. Нормальные разработчики, с опытом использования более продвинутых языков за плечами, знают, откуда у этих абстракций растут уши, и как и где их надо использовать (а также, как и где не надо).

> Бустовые пулы и регэкспы я вообще никогда и ни за что пользовать не собираюсь, потому как на моих глазах эти вещи приводили к падению многопоточных приложений под нагрузкой в версии 1.33. Я понимаю, что же 1.40 на дворе, но неприятный осадок остался, так что я за regex.h или за ppcre, если можно.

Я версий точно не помню, 1.31 и/или 1.32, что ли, были...

> Это без bind, function чтоли? Без них замечательно проживем, чай не лисп какой. asio? Я больше доверяю рукописным приблудам на libevent/libev.

Пока занимаешься рукоблудством, образованные люди уже всё напишут и сдадут. На прошлом месте работы у нашей системы, обрабатывавшей видео, было примерно 1k5 инсталляций на не очень мощном железе. Буста там очень много. Конечно, не совсем Лисп получался, но на безрыбье и рак - рыба. Если бы текла память, багрепортов каждый день по несколько десятков приходило бы. Но ничего не приходило. Valgrind тоже изъянов не находил. По-видимому, конторе просто повезло, что очки не мартышка нашла...

> Тебе указали, что в STL тоже происходит выделение динамической памяти (и в RBtree, и в list -- grep _List_node).

речь, вроде, шла о том, что без stl выделения (дополнительной) динамической памяти можно избежать.

> это те которые используют stl, кучу шаблонов, смарт-пойнтеров, и т.п.

Сдаётся мне, это те, которые не тестируют толком ;)

> Сдаётся мне, это те, которые не тестируют толком ;)

да они тестируют.. просто этот хлам уже никакое тестирование не может спасти.

> Слушай, ты ныл, что std::map/std::set медленный.

Я ныл? Я констатировал факт, что даже в тепличных условиях stl не быстрее самой тупой в лоб реализации двусвязных списков/деревьев на макросах в С. Списки начинают сливать при минорном усложнении задачи, к тому же.

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

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

> Тебе указали, что в STL тоже происходит выделение динамической памяти

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

> Кроме отговорок, подмены понятий и откровенного нежелания вести конструктивный диалог, ты еще на что-нибудь способен?

Ты опять всё о себе?

> речь, вроде, шла о том, что без stl выделения (дополнительной) динамической памяти можно избежать.

Именно.

>Такая ситуация возникает, когда малограмотные фоннаты крестов начинают штудировать boost.org на предмет, чего бы ещё такого заюзать.

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

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

libev* настолько просты и интуитивно понятны, что человек, не знакомый с asio и libevent, напишет код с использованием libevent раньше, чем дочитает и осознает ман по asio. Проверено на себе.

>Если бы текла память, багрепортов каждый день по несколько десятков приходило бы. Но ничего не приходило. Valgrind тоже изъянов не находил.

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

>речь, вроде, шла о том, что без stl выделения (дополнительной) динамической памяти можно избежать.

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

>А чем так плох STL?

настраивается плохо

>И что используют вместо него?

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

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

ее все равно придется выделить. неважно каким словом ты это назовешь. будет структура с твоими данными (malloc #1, который делаешь ты сам), и внутренняя структура контейнера (malloc #2, который делает stl)
даже если сделать собственный аллокатор - все равно будет 2 структура вместо 1й. это дает некислый оверхед в итоге. особенно когда много мелких объектов.

> Ну я и пытаюсь сказать, что приходилось видеть лишь фанатское использование этой бяки. Обоснованного применения bind'ов и function'ов я что-то не видел. Наверное, таковые встречаются, но там, где они применимы, можно обойтись и без этой ненужной функциональщины, как мне думается.

Это не функциональщина. bind/function - это слёзы крестофилов по поводу отсутствия в языке функций, как объектов.

> libev* настолько просты и интуитивно понятны, что человек, не знакомый с asio и libevent, напишет код с использованием libevent раньше, чем дочитает и осознает ман по asio. Проверено на себе.

Адепт средства А, не знакомый со средством Б, на А напишет код раньше, чем дочитает и осознает ман по Б. Вместо А и Б подставить названия по желанию.

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

Поймать coredump и в gdb постмортем посмотреть, что стряслось, не пробовали? А так, единственное плохое, что с вашим софтом происходит - его раз в сутки просто так, на всякий случай, мочат ;)

>>Такая ситуация возникает, когда малограмотные фоннаты крестов начинают штудировать boost.org на предмет, чего бы ещё такого заюзать.

>Ну я и пытаюсь сказать, что приходилось видеть лишь фанатское использование этой бяки. Обоснованного применения bind'ов и function'ов я что-то не видел. Наверное, таковые встречаются, но там, где они применимы, можно обойтись и без этой ненужной функциональщины, как мне думается.

У Скотта Мейерса в "Effective STL" наоборот приведены несколько простых циклов с совершенно неожиданными сегфолтами и указано почему с std::transform + boost::lambda их бы не было. Саттер и Александреску высказывают ту же точку зрения в "Стандартах программирования на С++", в главе 84.

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

ну так это не в boost проблема, а в уровне программистов. дай обезьяне в руки гранату...

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

>Я больше доверяю рукописным приблудам на libevent/libev.

:)

забавно
у меня для списка 3000000

std::list - 76.2
bsd::list - 75.4

разницу в 1% можно занести на счет погрешности измерения
36 строк на bsd, 5 строк на std

в общем, "эффективность" С vs C++ сильно преувеличена

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

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

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

>bind/function - это слёзы крестофилов по поводу отсутствия в языке функций, как объектов.

...которые нужны только, если нам захотелось операций навроде map, reduce, получения новых функций путем композиции существующих.

>Адепт средства А, не знакомый со средством Б, на А напишет код раньше, чем дочитает и осознает ман по Б. Вместо А и Б подставить названия по желанию.

А кто тебе сказал, что я до этого имел дело с libevent и не сталкивался с бустом?

>Поймать coredump и в gdb постмортем посмотреть, что стряслось, не пробовали?

Проблема в том, что gdb ведет себя не очень адекватно с плюсовыми приложениями, изобилующими шаблонами. В случае, когда размер core переваливает за 2GB ситуация ни капельки не улучшается -- лишний раз нажал на TAB, и gdb можно прибивать.

Если софтину не мочить раз в сутки, она уйдет в неадекват (перестанет реагировать на внешние раздражители, загонит систему в swap).

> Если софтину не мочить раз в сутки, она уйдет в неадекват (перестанет реагировать на внешние раздражители, загонит систему в swap).

Понятно, ещё и админа грамотного нет...

>...которые нужны только, если нам захотелось операций навроде map, reduce, получения новых функций путем композиции существующих.

Нормальные указатели на функции пришлись бы очень кстати чтобы не раздувать зависимости в интерфейсах. В С++ это важно чтобы хоть как-то ускорить компиляцию.

Слил, толстенький? Вот и сиди тихо.

интересно, а топикстартер в этот тред придёт или нет?

> Это чистый C. Так считается это контейнером/коллекцией?

Я вижу, ты хотел ответить, но потом тебя что-то остановило :)

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

Открываю описание класса QVector. Вижу, что класс соответствует (??) контракту STL-вского контейнера, поскольку имеет схожее поведение на ряде функций. Отсюда заключаю, что QVector можно рассматривать и как STL-вский контейнер тоже. Кажется, именно принцип "ведет подобно" является одним из главных в STL.

В общем, это был пример в пользу STL.

при использовании чего, то более полезного чем int для эдлементов списка, С очень культурненько слил:

std::list - 50
bsd::list - 54

в общем, Дейкстра как всегда прав - преждевременная оптимизация (чего избежать в С сложнее чем в С++) - зло

>В общем, это был пример в пользу STL.

не был. почитай у троллей аргументацию введения собственной библиотеки контейнеров

>Вижу, что класс соответствует (??) контракту STL-вского контейнера, поскольку имеет схожее поведение на ряде функций

ключевые в этой фразе - (??) и "схожее...на ряде". я видел немало проектов, в которых использование STL было запрещено в пользу собственных библиотек контейнеров, и в каждом случае имелось какое-то (вполне внятное) обоснование

> при использовании чего, то более полезного чем int для эдлементов списка, С очень культурненько слил:

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

код, полностью как ранее в треде
только в std::list кладется структура из 5 int
а к tailq_entry добавлено 4 int

и ничего более

вообще-то у меня С вариант нигде не выигрывает у плюсового
топчутся они друг вокруг друга

>вообще-то у меня С вариант нигде не выигрывает у плюсового

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

И где твои «печальные» результаты?

$ time -p ./list2 30000000
real 2.63
user 1.66
sys 0.97
$ time -p ./tailq_ex 30000000
real 2.11
user 1.48
sys 0.62

#include <list>
#include <stdlib.h>
#include "complex_type.h"

using namespace std;

struct V
{
        int i;
        ComplexType c;
};

int main(int argc, char ** argv)
{
        int n = atoi(argv[1]);
        list < V > lst;

        for (int i = 0; i < n; ++i) {
                V v; v.i = i;
                lst.push_back(v);
        }
        return 0;
}

struct tailq_entry {
        int value;
        struct ComplexType v;

        /*
         * This holds the pointers to the next and previous entries in
         * the tail queue.
         */
        TAILQ_ENTRY(tailq_entry) entries;
};

...

        /* Add 10 items to the tailq queue. */
        for (i = 0; i < n; i++) {
                /*
                 * Each item we want to add to the tail queue must be
                 * allocated.
                 */
                item = malloc(sizeof(*item));
                if (item == NULL) {
                        perror("malloc failed");
                        exit(EXIT_FAILURE);
                }

                /* Set the value. */
                item->value = i;

                /*
                 * Add our item to the end of tail queue. The first
                 * argument is a pointer to the head of our tail
                 * queue, the second is the item we want to add, and
                 * the third argument is the name of the struct
                 * variable that points to the next and previous items
                 * in the tail queue.
                 */
                TAILQ_INSERT_TAIL(&my_tailq_head, item, entries);
        }
.....

>> вообще-то у меня С вариант нигде не выигрывает у плюсового

> Это вообще непродуктивная ветка в дискуссии, т.к и ежу понятно что и плюсовый и сишный двусвязанный список реализованы одинаково и разворачиваются в тот же код. Возможно, в С++ заинлайнено чего-то что в Си делается через честный call что и дает выигрыш в три процента.

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

> Суть дискуссии том что для реалтаймовых задач и игр динамическая память почти неприменима, т.к не позволяет оценить гарантированное время отклика. Поэтому почти любая реализация связанного списка тут в пролете. Разве что "фортрановский" вариант связанного списка поверх массива фиксированного размера прокатит.

Нет ! :))) суть дискусии - стоит ли изучать с++ :))))) - это раз
а два - в с++ можно использовать динамическую память и для реалтайма и для игр , на этапе разработки хотя-бы :) а потом легким движением руки перестать ее использовать, да еще и оттестировать различные механизмы отдельным образом. В С это __практически__ невозможно.

>С++ дает значительный простор для оптимизации кода как человеком так и компилятором

можно подкрепить это утверждение примерами?

>легким движением руки перестать ее использовать

а вот это - очень мощное утверждение. внушает

> С++ дает значительный простор для оптимизации кода как человеком так и компилятором, с С все значительно сложнее.

4.2

> а потом легким движением руки перестать ее использовать

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

> В С это __практически__ невозможно.

это делается идентично в c и c++.

>> С++ дает значительный простор для оптимизации кода как человеком так и компилятором

> можно подкрепить это утверждение примерами?

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

>>легким движением руки перестать ее использовать

> а вот это - очень мощное утверждение. внушает

кланяйся

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

lol! я бы сказал, выиграли за счет хренового test case и хренового кода на C.

>> С++ дает значительный простор для оптимизации кода как человеком так и компилятором, с С все значительно сложнее.

> 4.2

не умеете програмировать ? я не виноват :)

>> В С это __практически__ невозможно.

> это делается идентично в c и c++.

нет С плохо поддерживает однообразную замену логических единиц в коде.
Макросы, еще кое-как спасают, но у них очень много проблем.

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

> lol! я бы сказал, выиграли за счет хренового test case и хренового кода на C

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

Вот тут печальные результаты:

TAILQ insert: 0.613720 
std::list insert: 0.662492 
TAILQ clear: 0.241838 
std::list clear: 0.241919 

Я начинаю всерьёз сомневаться, что ты там меряешь.

"Значительно более сложный для оптимизации человеком и компилятором С по сравнению с С++" -- это прекрасно. Это почти так же прекрасно, как и утверждения о RBtree в std::list...

>Вот тут печальные результаты:
>TAILQ insert: 0.613720
>std::list insert: 0.662492
>TAILQ clear: 0.241838
>std::list clear: 0.241919
>Я начинаю всерьёз сомневаться, что ты там меряешь.

вообще-то это равны с точностью до погрешности :)))))

У тебя какая-то особенная система и какой-то особенный компилятор. У себя такого воспроизвести не могу.

> "Значительно более сложный для оптимизации человеком и компилятором С по сравнению с С++" -- это прекрасно. Это почти так же прекрасно, как и утверждения о RBtree в std::list...

да, мой дорогой друг :)
не умение тобой программировать, не есть утверждение, что все остальные не умеют :)

>С++ дает значительный простор для оптимизации кода как человеком так и компилятором

С++ обычно неявно подразумевает какое-то одно проектное решение, но сам его не делает. Например, в Си++ нельзя отслеживать время жизни объектов иначе чем через подсчет ссылок, т.к как-то трассировать или перемещать объекты нельзя. Но сам Си++ ссылки не считает. Это канонiчный паттерн принятия решений в комитете по стандартизации С++.

>с С все значительно сложнее.

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

>суть дискусии - стоит ли изучать с++

В данной ветке речь идет о применимости динамических коллекций в играх и rt-приложениях. По мне так всю память можно аллоцировать при загрузке уровня, благо количество "сущностей" на уровне зафиксировано при разработке. Ну, допустим, игроки могут подключаться по ходу игры, поэтому задается максимум - скажем 64 игрока где недостающие слоты пустуют. В rt тоже: типичная rt задача это кодирование видео, например. Количество ОЗУ необходимого для кодирования видео всегда обусловлено алгоритмом и известно наперед.

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

По мне так нет, надо кучу всего переписывать и тестировать заново.

>>С++ дает значительный простор для оптимизации кода как человеком так и компилятором

>можно подкрепить это утверждение примерами?

Напоминает предисловие к книге "Modern C++ Design". В идеале надо перенастроить статические стратегии в файле конфигурации.

> вообще-то это равны с точностью до погрешности :)))))

это среднее по сотне запусков. Погрешность в 10%? Не смешно.

Думал, что у тебя древний gcc, поставил из пакетов gcc-3.3 и вот что получил:

$ time -p ./tailq_ex 30000000
real 2.49
user 1.61
sys 0.88
$ time -p ./list2 30000000
real 1.85
user 1.22
sys 0.64

> не умение тобой программировать, не есть утверждение, что все остальные не умеют :)

До чего лор довели глянцевые мониторы, ужас какой-то... 8))

>Напоминает предисловие к книге "Modern C++ Design"

и это тоже

>В идеале надо перенастроить статические стратегии в файле конфигурации.

мне интересно, какое отношение это имеет к C++?

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

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

>кланяйся

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

>> С++ дает значительный простор для оптимизации кода как человеком так и компилятором

> С++ обычно неявно подразумевает какое-то одно проектное решение, но сам его не делает. Например, в Си++ нельзя отслеживать время жизни объектов иначе чем через подсчет ссылок, т.к как-то трассировать или перемещать объекты нельзя. Но сам Си++ ссылки не считает. Это канонiчный паттерн принятия решений в комитете по стандартизации С++.

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

>> с С все значительно сложнее.

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

Продолжайте работать и вам будет пофиг :)

>>суть дискусии - стоит ли изучать с++

> В данной ветке речь идет о применимости динамических коллекций в играх и rt-приложениях. По мне так всю память можно аллоцировать при загрузке уровня, благо количество "сущностей" на уровне зафиксировано при разработке. Ну, допустим, игроки могут подключаться по ходу игры, поэтому задается максимум - скажем 64 игрока где недостающие слоты пустуют. В rt тоже: типичная rt задача это кодирование видео, например. Количество ОЗУ необходимого для кодирования видео всегда обусловлено алгоритмом и известно наперед.

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

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

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

продолжаете совершеннствоватся, станете мастером :)

>> вообще-то это равны с точностью до погрешности :)))))

> это среднее по сотне запусков. Погрешность в 10%? Не смешно.

да, смеятся не надо, надо головой думать