Обсуждаем языки программирования

Windows

Вот именно. Всегда когда есть возможность надо применять библиотеки. Кстати, С++ имеет смысл только ради STL и Boost.

Думаю, что нынешнюю версию Греки я в турнир выставлять не буду.
Вот если к осени напишу новую версию, там посмотрим.
Кстати, по итогам наших тут бесед решил попробовать написать её на чистом C; если что случится с моим рассудком - прошу во всём винить atoku

Windows 3.1: mostly assembly language, some supplied applications coded in C.

Windows 9x/ME: the 16 bit subsystem was salvaged from DOS and Win 3.1 and therefore was written in assembly language; the rest was a combination of assembler and C. Win 9x was designed to work well on suboptimal, older hardware (486s and such), therefore needed the speed advantage of assembly language. Remember that Win 95 was originally packaged as an upgrade from Windows 3.1.

Windows NT (which implies Windows 2000 and XP): mostly C, with some assembly language at the kernel and device driver level. The design goal of NT was said to be potential portability, and assembly language efficiency was a secondary concern. The portions in C were designed to be ported to other CPUs and platforms such as Alpha.

(http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=28914)

учитывая, что первая винда появилась раньше чем С++, то... это, может, на ядре NT пошел С++. и вообще, как можно на С++ написать API - в 95 году вроде MFC еще не было.

Ну, даже если Винда написана не целиком на C, есть ещё всякие коммерческие Юниксы.

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

На С тоже можно и нужно писать объектно-ориентированно.

А вот у меня как раз идея возникла написать все потом на O'Caml. Все равно второй раз придется с чистого листа переписывать!

Правда, писать на ANSI C у меня духу, наверное, не хватит
Так что будет С99.

А чем хорош O'Caml?

C99 я тоже пишу. Только С99 это стандарт ANSI

O'Caml - это промышленный функциональный язык с ООП и возможностью обычного программирования. Очень мощная разработка и черезвычайно быстрый код генерится. Подробности http://en.wikipedia.org/wiki/Ocaml

Переносимый на большинство ОС, GPL * свободный

Я имел в виду предыдущую версию стандарта, 89-го года.
Т.е. то, что gcc понимает как -ansi, в отличие от -std=c99.

Кстати, говорят MS Visual Studio до сих пор не знает ничего о С99... Им не выгодно

Написал на Си генератор ходов, по тому же алгоритму, что и в Греке. Выигрыш по скорости на разных тестовых позициях составляет от 5 до 15% (это пока без тщательной оптимизации). Выигрыш по размеру исполняемого файла - от 5 до 10 раз

gcc / MinGW 3.4.4

Даром время не теряешь ! Здорово. А я ведь вроде видел предыдущий код Греки, там почти C. Плюсов у него мало...

—-

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

Кстати, ход везде кодируется 16 битами. Может и зря

Да, из плюсов там практически только std::string активно используется (эх, пришлось-таки вспомнить, с чем char* едят - сто лет такими строками не пользовался), да std::vector для хранения списков ходов и найденных вариантов - ну, тут замена на массив ещё более простая. А ходы я сейчас тоже в 16-битные short-переменные упаковал.
Заодно понял, что для игры помещать в ход какие-то дополнительные флаги, коды ходившей и взятой фигур и пр. - расточительство. ПОТОМУ ЧТО БОЛЬШАЯ ЧАСТЬ СГЕНЕРЁННЫХ ХОДОВ ПРОСТО НЕ БУДЕТ РАССМОТРЕНА ИЗ-ЗА ОТСЕЧЕНИЙ

Мой тебе совет - когда будешь писать генератор ходов, с первых же версий встрой команду perft для тестирования легальности генератора. См. http://mypage.bluewin.ch/romanhartmann/perft.html

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

Что-то мне припоминается, что современные компиляторы на 32-битных платформах 16-битные числа всё равно кодируют в 32 бита... Так что выигрыша/проигрыша может и не быть.

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

16 бит будет быстрее. За счет того, что из памяти будут забираться конвеером по несколько штук. И конечно, больше будет памяти для хэш таблицы.

Что касается моего хода, то там кодируется кто ходил, с какого поля на какое, если промоушен, то в кого превратился еще. Ну и нулевой ход туда же. Все влезает и еще есть место в 16 битах. Ну и рокировки тоже, ясное дело. Для Фишера остается место для положения ладей и короля. Я использую int16_t из С99

WinPooh, спасибо за ссылку!

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

# x-mas 2003, start to write a move generator
...
# august 2004, move generator works fine up to ply 5
# septembre 2004, fixed an ep-bug, move generator seems to work fine now
# july/august 2005, fixed several bugs (promotion bugs)
...
# February 2006, fixed some bugs in the movegenerator

А куда спешить-то?

А я вот стал думать как делать unmove и стало неясно, как обходиться без кода взятой фигуры! :/

После доработки кода напильником удалось достичь скорости в полтора раза большей, чем в текущей C++ версии Греки. Но это пока только генератор ходов и make/unmake. Надеюсь, в поиске тоже что-то удастся оптимизировать.

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