Я был на дне открытых дверей Экономического Факультета СПБ ГУ года 3 назад. Действие происходило в наверно одной из самых дальних аудиторий, без досок и проекторов, но это не так важно. Важно то, что все выступающие, т.е. зав кафедрами, выходили и ВСЕ начинали свою речь с того сколько у них кандидатов наук и докторов, попутно сравнивая данный показатель с предущим выступающим. Дальше были опять сухие цифры про какие то часы аудиторных занятий и сколько книжек было написано. При личной беседе меня заинтересовать тоже ничем не смогли (может это я такой). Я понимаю что наука, все дела, но надо быть ближе к реальности. Был очень разочарован, и для себя решил, что это то место где я точно не хочу учиться.
Изменения делать можно (и сортировать при этом), но выигрыш получается только если количество поисков значительно больше операций изменения контейнера.
EuroElessar в общем прав — random в glibc в наиболее простом алгоритме (а такой и был выбран) реализован вот так:
val = ((state[0] * 1103515245) + 12345) & 0x7fffffff;
Вызывал operator[], но разница не столь значима (я делал эксперименты с set, в который добавлял через insert — разница была в пределах 5-7%). Двукратного оверхеда нету, так как основная часть времени уходит на поиск элемента (если их много), а он и в insert и в operator[] делается единожды.
В случае изменений данных vector проиграет, так как вставка, а тем более удаление в нем дорогие. Тут как раз ситуация, когда изменений данных мало, в этом случае вектор может выигрывать, причем значительно.
random() не принимает параметров, Вас наверно смутила цифра 3 — это я хотел сказать что это стандартная функция Си.
С кучей тоже нужно будет делать сортировку, иначе как в ней эффективно искать.
Кое-что прояснилось. При аттаче к процессу ему посылается сигнал SIGSTOP и процесс трассировщик ждет уведомления получения с помощью waitpid(). Обработка сигналов происходит после перехода в соответствующий user space, т.е. например после обработки syscall. Соответственно первый PTRACE_SYSCALL сработает только на входе в syscall. Если я не прав, пожалуйста поправьте.
А можете привести подтверждение, что это может случиться? Если это действительно так, как различить вход это в syscall или выход? Я читаю код ядра, и попутно gdb и strace, но этот момент неясен пока. Может Вы быстрее подскажите?
ptrace(PTRACE_SYSCALL, pid, 0, 0) срабатывает и на входе и на выходе из syscall. Мы делаем PTRACE_ATTACH к существующему процессу, может ли получиться что первый вызов с PTRACE_SYSCALL будет на выходе из syscall?
Накручивать номер ревизии тому что не менялось — это уж SVN так работает. Вручную не нужно, просто нужно запретить пользователям делать update части проекта, а только целиком. Думаю это можно сделать программным способом.
Если Вы знаете какой-то более простой способ для SVN, поделитесь, интересно будет узнать.
Глобальный номер ревизии — Вы выкатили весь проект какой-то ревизии, собрали и потом можете получить по этой ревизии то, из чего собирали, чем он неудобен? В SVN это может не работать, как Вы правильно заметили, если обновить к примеру только часть исходных кодов. Но если делать svn up в корне проекта, так чтобы обновлялся весь проект целиком, ты мы получим актуальную версию ревизии.
val = ((state[0] * 1103515245) + 12345) & 0x7fffffff;
random() не принимает параметров, Вас наверно смутила цифра 3 — это я хотел сказать что это стандартная функция Си.
С кучей тоже нужно будет делать сортировку, иначе как в ней эффективно искать.
Если Вы знаете какой-то более простой способ для SVN, поделитесь, интересно будет узнать.