Подскажите, как наиболее красиво рандомизировать вызов функций

во-первых у вас тут непростительное цпп, а во-вторых первый(то есть четвёртый, я тогда просто прослоупочил) пост смотри.

 

Comer_, для решения таких задач я с конечными автоматами и графами работаю, а ты jmp предлагаешь. На обычных jmp сложную "логику" не запрограммишь или это будет выглядеть криво. Ну может для этой задачи и пойдёт.

А я вот цпп простил и ничего так, неплохо получается.

 

W4FhLF

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

 

qqwe, какие команды асма? Ты весь generic programming в 20-30 команд собрался запихать? Покажи мне.

 

W4FhLF

бамбарбия киргуду

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

"все познается в сравнении" (с)

 

qqwe, да я в #19 уже показал.

 

W4FhLF

хокей. условия задачи ставятся по вашему примеру.

вообще тут два подхода
1) допускать произвольное количество и произвольные типы входных и выходных в случайно группируемых функциях
2) организовать некий буфер/структуру ссыль на который передавать во все функции. а какими параметрами там пользоваться и какие менять - решит функция сама.

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

приведеный пример записан в стиле варианта 1. следую ему.

Код (Text):

1. szHello db "Hello", 0
2. .data
3. d12_0     dq 12.0
4.  
5. pf0   dd 3, 11, offset szHello, offset f0,  ; handlers.push_back(boost::bind(&f0, "Hello", 11));
6. pf1   dd 3, 1, offset d12_0, offset f1,     ; handlers.push_back(boost::bind(&f1, 12.0, true));
7.    ...
8. pf10 dd n+1, offset pn, ... , offset p1, offset f10 ; handlers.push_back(boost::bind(&f10, p1, ..., pn));
9.  
10. tab dd offset pf0, ... , offset pf10, 0
11.  
12. .code
13. foo:
14. ...
15.  
16.    push offset finish_point
17.    mov esi,offset tab
18.    mov ecx,10
19. random_loop:
20.    mov ebx,[esi]
21.  
22.    rdtsc
23.    xor edx,edx
24.    bswap eax
25.    div ecx
26.    xchg ebx,[esi + 4*edx]
27.  
28.      mov edx,ecx
29.    mov ecx,[ebx]
30. push_loop:
31.    add ebx,4
32.    push dword [ebx]
33.    loop push_loop
34.      mov ecx,edx
35.  
36.    add esi,4
37.    loop random_loop
38.  
39. ...
40.   ret
41. finish_point:
42. ...

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

вариант 2 будет гороздо проще, короче и лучше

 

Вообще то std::vector<> это динамический массив и более общее решение. На асме написан аналог static boost::array<>

По каким критериям? Если над софтом работает больше одного человека, чем меньше "what the fuck?" при ревью, тем код качественнее и проще в поддержке.

 

J0E
не ко мне, не ко мне
..
ко мне

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

 

Ревью кода делает не автор, так что твое мнение не засчитывается

 

J0E

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

 

Я видел код Дэна и Вольфа на предыдущей странице. Но, пожалуй, соглашусь, твой код вызовет меньше WTF/min, потому что на ревью нужно потратить больше времени ))

 

J0E

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

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

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

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

 

WTF/min это кол-во "что за *****?" в минуту (о, а вот и add esi, 4 )

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

 

J0E

не спорю, что код можно сократить на пару-тройку команд. писал на колене. сразу как прочел предложение о

да кто спорит? только на питоне или луа будет еще проще. например не понадобится уродливых ++во-темплатных деклараторов. тут вопрос в допусках. например сильно сомневаюсь в

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

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

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

чето подумал - а где вы в этом коде увидели необходимость в потоках и синхронизации???

вот вот. с этого все глюки и начинаются. никто ни за что не отвечает. сплошной футбол.

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


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

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

 

Я не это имел ввиду. Что бы понять, как код рандомизирует вызовы, нужно увидеть и эту команду.

Ты сбиваешь предсказатель возвратов командами push/ret, против одного виртуального вызова в function::operator(). Который кстати обеспечивает полиморфность (у тебя полиморфизм статический, подобное обеспечивается более легким функтором).

А я подумал - что в постановке этой задачи такого, что требует искать решение? Мы же не решаем сколько будет 2+2, а знаем ответ сразу. Зато не знаем, что окажется при изменившихся требованиях через год. Так что это не фантазии, а мысли о более гибкой архитектуре

За конечный продукт отвечает его производитель, для этого продукт проходит тестирование. Если тесты покажут что random_shuffle дает неверный результат (что маловероятно в случае широко используемых библиотек) то отправляется багрепорт и производитель библиотеки исправляет ошибку. Как раз каждый отвечает за свое, ситуации "я скопировал код с форума и теперь не знаю что с ним делать" не должно возникать. Ошибки в стандартной библиотеке кстати находят, это ошибки проектирования. Причем создавалась она не глупыми людьми, изучалась другими, а проблемы всплывают через годы.

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

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

 

J0E

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

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

кроме того, я писал уже, что требования заданные примером #19 годятся только задля спорта. те там записан прямой путь к усиленному дебуженью по причине перманентной глюкавости. причем ни буст, ни темплаты не помогут, да и ни при чем они. тк само требование - запускать в произвольном порядке функции с разным количеством парамеров произвольного типа (и возврат разного типа), если только они работают не с совершенно разными парамтрами, а возвратом друг друга не интересуются, кривое изначально и годится только как упражнение для ума.
для практики сам способ передачи/возврата данных надо соптимизировать

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

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

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

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

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

вы так спешите проект сдать? не тестя? оттого вы, наверно, и веруете, что буст и ++сы гарантируют от ошибок. но вы не отчаивайтесь - вон как китайские туфли идут. до первой лужи

очень хитро спроектирована фраза. ее тоже надо перенести на поддерживаемый язык

 

qqwe, на самом деле J0E во многом прав. То, что ты показал это не аналог моему коду, это какой-то кусок непереносимого, неподдерживаемого, абсолютно негибкого и не масштабируемого, к тому же error-prone (не знаю как на русском) кода. Он и на сотую не прибоизился к тому, что делают boost::bind & boost::any & boost::function. Не веришь почитай доки по последним.

Если мне, например, понадобится вызывать функции по именам я заменю vector<Function> на map<string, Function>, а тебе код придётся переписать.

Да полиморфизм это называется. В 70х ещё придумали. А ты всё категориями 60х мыслишь. В С++ статический на уровне шаблонов, динамический на уровне виртуальных функций и наследования. В принципе и сейчас можно реализовать с boost::bind. Но вот с приходом нового стандарта это станет гораздо проще.

Ничего тут кривого нет. Требование исходит из простой парадигмы обобщённого программирования. Когда лучше написать одну template реализацию, чем 10 specified.

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

Вот тебе и диспетчер задач для асинхронной обработки любого количества любых объектов (3D например) на сцене. Пользователи шлют набор действий, сервак формирует граф обработки для объектов, помещает его в диспетчер задач, который асинхронно и параллельно выполняет эти задачи, сцена рисует объекты.
Вообще половину MMORPG написал тут

 

Да, ещё конечно в граф обработки лучше добавлять не boost::function, а объект типа Task, в котором есть интерфейс для обработки возвращаемого результата и завершённости задания. А потом Task добавлять в TaskManager:

Код (Text):

1. struct Task
2. {
3.    template<class Handler>
4.    Task(Handler handler) : handler_(handler), complete_(false)
5.    {}
6.  
7.    const boost::any& result() const
8.    {
9.       return result_;
10.    }
11.    
12.    bool complete() const
13.    {
14.       return complete_;
15.    }
16.    
17.    void operator()()
18.    {
19.        result_ = handler_();
20.        complete_ = true;
21.    }
22.  
23. private:
24.    boost::any result_;
25.    boost::function<boost::any()> handler_;
26.    bool complete_;
27. };

 

Этот код существует много лет, писался профессионалами и используется десятками тысяч людей. Он безопастнее и качественнее кода, который могут (если смогут) написать 90% программистов. Китайские туфли это скорее то, что создаётся самоучкой с "неполовозрелым максимализмом" (с) Ustus, а stl и boost это фирма и качество.

Так что эти голословные заявления как раз и говорят о незрелости и отсутствии твоего опыта. Все так когда-то рассуждали.