- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
// Шифровка текста.
char* encryption(char *Text){
int i = 0;
while(Text[i]){
switch(Text[i]){
default:
Text[i] = '.';
break;
case 'a':
Text[i] = ',';
break;
// ...
}
i++;
}
return Text;
}
Follow us!
Что?
Какие? В систему контроля версий добавляешь только питоний скрипт. В сгенеренный файл ничего руками не пишешь, под контроль его не добавляешь (его будет генерить сборочная система). Вот и все, и никаких проблем :)
P.S. Есть только мелкая проблемка - в IDE не сразу будут появляться подсказки по этому файлу. Но это решается банальной сборкой проекта.
Кого?
Кстати, кто-то разработал общий алгоритм синтеза квайна из N шагов. На хабре точно было.
Совершенно верно.
Видел абсолютно безумные цепочки из 10-ти языков.
http://habrahabr.ru/post/74827/
если уж на то пошло, то для этого даже питон не нужен, можно в экселе его нагенерить. мне когда лень грузить данные из экселя в базу через всякие загрузчики, то я там генерю insert скрипты
Имхо оно заменит текст точками и всё.
Да. Порядок меток в свиче не имеет никакого значения. Это же всего лишь метки, по которым управление впрыгивает в большой блок...
Скорее всего первая версия switch'а транслировалась во что-то типа:И эта сишкоблядская деталь реализации до сих пор зияет из сишки, крестов и даже жабы...
Сохронил!
А если метки ведут на участки кода, равномерно отстоящие друг от друга, то можно ли вообще вычислить адрес, а не брать из таблицы?
Видимо
void* a = &&first + (&&second-&&first)*i;
goto *a;
first :
...
second :
Предсказателю переходов и блоку упреждающего исполнения это очень понравится.
Таблицы виртуальных функций и косвенные переходы цп таки как-никак научились ускорять. А "умное" вычисление адреса ставит крест на перфомансе, именно поэтому в интеле такие трудности со сменой eip.
> лишнего перехода перед goto *.
cmov
Да никак ;) Вроде бы для косвенных переходов был тупой кеш на одно последнее значение (предполагаем, что прыгнут в то же самое место). Или там что-то поумнее нынче?
> был тупой кеш на одно последнее значение
Там уже всё гораздо умнее.
Деталей не помню, но кажись еще в core 2 и последующих интелах какую-то оптимизацию придумали. Потом и амд запилила.
3.12 Indirect jumps on older processors Indirect jumps, indirect calls, and returns may go to a different address each time. The prediction method for an indirect jump or indirect call is, in processors older than PM and K10, simply to predict that it will go to the same target as last time it was executed.
Indirect jump prediction An indirect jump or call is a control transfer instruction that has more than two possible targets. A C++ program can generate an indirect jump or call with... a virtual function. An indirect jump or call is generated in assembly by specifying a register or a memory variable or an indexed array as the destination of a jump or call instruction. Many processors make only one BTB entry for an indirect jump or call. This means that it will always be predicted to go to the same target as it did last time. As object oriented programming with polymorphous classes has become more common, there is a growing need for predicting indirect calls with multiple targets. This can be done by assigning a new BTB entry for every new jump target that is encountered. The history buffer and pattern history table must have space for more than one bit of information for each jump incident in order to distinguish more than two possible targets. The PM is the first x86 processor to implement this method. The prediction rule on p. 12 still applies with the modification that the theoretical maximum period that can be predicted perfectly is mn, where m is the number of different targets per indirect jump, because there are mn different possible n-length subsequences. However, this theoretical maximum cannot be reached if it exceeds the size of the BTB or the pattern history table.
Просто от произвольности этих значений зависит сложность формулы выбора.
В общем виде формула смотрится примерно так
f(x) = ((-(x = c)) & (a - c)) + ((-(x = a)) & (b - c)) + c
где a-c, b-c - константы
по сути изменение eip/rip
> участки кода, равномерно отстоящие друг от друга
Только на risc-архитектурах где инструкции имеют фиксированную длину, на x86 с его разношерстными командами такое вряд ли сработает.
>>Скорее всего первая версия switch'а транслировалась во что-то типа
Еще в фортране/бейсике был похожий оператор, только там явно были номера меток.
В лично том бейсике на котором кодил я такой фичи не было, но я слышал про диалекты с оной.
А вот в фортране называлоьс computed goto
http://h21007.www2.hp.com/portal/download/files/unprot/fortran/docs/lrm/lrm0124.htm
Если I не [1,2,3] оно вроде просто проваливалось вниз.
А GOTO X - гццизм.Я раньше всегда мечтал об такой фиче, но в реале никогда не видел
В этом-то и вся фича.
Я сначала не въехал, но как мне объясняли сиё было полезно чтобы вставлять между ними код, а номера не менялись.
Потому метки в олд-бейсик-проги и выглядят:
10
20
30
рефакторинг он такой
Это если бряки присутствуют.