Тут нада чота умное напейсать! Шоб сказал, как отрезал! Но чота ничо не приходит вголову, сцуко (( :D
Сначала про Кубик. осторожно, многа букафВот, к примеру, решили мы построить дерево состояний. Сколько начальных (и конечных) состояний у кубика? Наивный четатель сразу скажет - одно! Когда все грани одного цвета! И частично попадёт пальцем в небо. Потому что количество состояний зависит от точки зрения. Если, к примеру, кубик представить, скажем, массивом из квадратиков на каждой грани, то таких состояний окажется 24. Ну, например, одна грань может смотреть в шесть сторон, а 4 прилегающие грани будут ориентированы 4 способами. Итого 6х4=24. Для нас это важно, т.к. допустим, база состояний может занимать 24Гб и та же самая база может быть 1Гб! Разница очевидна. Чтобы сократить базу, надо зафиксировать кубик в пространстве и рассматривать перемещения граней только относительно самого кубика. Раньше я думал, что это можно сделать только для кубика 3х3, т.к. у него есть центральные квадратики, которые типа неподвижны, а в 2х2 таковых не имеется. Но в пятницу на меня снизошло озарение! Если представить любой элемент кубика неподвижным, то остальные крутятся вокруг него. Количество "ходов" в этом случае для кубика 2х2 сокращается с 12 до 6. Для 3х3 с 18 до 12. Что и приводит, по идее, к сокращению базы в 24 раза. Но это ещё не всё! Поскольку этот зафиксированный элемент всегда на одном месте, то можно не кодировать его местоположение в описании состояния кубика. Таким образом, если в кубике 2х2 имеем 24 квадратика 6 цветов, это по 3 бита на цвет. Каждый из 8 подвижных элементов кубика имеет 3 квадратика цвета, саатвецтвина, если мы кодируем 24, то 24х3=72 бита, а (24-1)х3=63 бита, а это, в свою очередь позволяет нам упаковать 1 состояние в 64-битное длинное целое (или как оно там называется) с которыми современные процессоры давно работают. Таким образом, два разных состояния кубика можно сравнить всего за одну операцию! Это здорово упрощает реализацию дерева состояний и поиска в нём.
Правда, несмотря на такие серьёзные прорывы в теории, к появлению алгоритма построения дерева это до сих пор не привело. Но работы ведуцца! )))
Теперь про второй проект. осторожно, ещё больше букафВ принципе, я его почти закончил. Но вот это блядское "почти", наверное, будет преследовать меня всю жизнь. Потому что всегда есть что-то доделать и никогда не знаешь, когда стоит остановиться. Но опыт растёт. Вот, значицца, несколько случаев из практики праграмиста.
Там у меня есть с десяток параметров - масштаб по Х и У, цветность, два вида ширины и формат вывода - я расщедрился, аж 16 флажков - что печатать, а что нет. Ну, хрен знает, чо там этому пользователю в голову взбредёт. На всё есть умолчания, но если они тебе не подходят, и при запуске надо каждый раз настраиваться - это заёбывает. Решил применить проверенное решение - .ini файл. Раньше я получал каталог, откуда запущена программа, добавлял туда имя программы в виде ...+"AppName.ini\0", открывал этот файл, если он открывался и не парился. Но сейчас я смекнул, что это не очень правильно, во-вторых - слишком сложно. Дотёмкал, что возможно это имя файла где-то уже есть. Скорее всего, в объекте Приложения. И, о чудо! Оно действительно там есть. Причём, не только имя exe файла, но ещё и имя ini файла. Не знаю, по каким критериям оно там ращитывается и чем отличается, у меня оба этих имени были одинаковы. И строку ".ini\0" всё равно пришлось прибавлять. И каталог получать. Но всё равно - так правильнее.
Дальше есть функция - GetPrivateProfileString, которая находит и читает строку из ini файла. Решил подробнее про это прочитать, а то какой-то ебаторий - найди файл, открой, прочитай строку, преобразуй в число. Посмотрел сначала объект Приложения. В нём есть функции GetProfileBinary, GetProfileString, GetProfileInt, которые считывают параметры из реестра или ini файла. Но примеры почему-то только с реестром. Это нам не подходит.
Смотрим LoadPrivateProfileString. Вот те на! Написано, что функция устарела не рекомендуется и используется только для старых 16-битных Win98-приложений. И ini файлы тоже устарели, щас рекомендуется пользоваться реестром. У меня внутренний конфликт. С одной стороны - это правильно. Реестр всегда в памяти, чо там прога будет дрочить жёсткий диск, считывать при каждом запуске 10 параметров, открывать-закрывать ini-файл, в то время как она может не только читать из реестра, но и писать в реестр, сохранять своё состояние. Пользователь настроил прогу, закрыл, открыл, а она всё помнит. Круто же! НО!
1) От админов я наслушался всяких страшных историй про криворукие программы, которые лезут в реестр, гадят там, в итоге реестр засирается, и его приходится чистить, а уж если там сломается что, то и Винду переустанавливать. И вообще - чем меньше туда лазишь, тем лучше оно работает.
2) Чтобы прога имела свой раздел в реестре, это надо делать полноценный инсталлятор, полноценное удаление. Стоит ли так задрачиваться из-за проги в 40Кб? Скопировал на диск, запустил, не понравилась - удалил. Никакого гемора.
Оставил пока .ini файл. Зато обнаружил ещё функцию GetPrivateProfileInt, которая тоже устарела, но мне не надо строку в число превращать - она сразу число считывает.
По идее, ini файл надо считывать в объекте Приложения. Но вот незадача - в основном переменные у меня из объекта Вида, а объект Вида из объекта приложения почему-то оказывается недоступен, хотя я пытаюсь к нему достучаться уже после макроса RUNTIME_CLASS, который эти объекты, типа, создаёт. Поэтому я, не долго думая, загрузил инишник прямо в конструкторе Вида. Уж там-то Вид доступен. И ещё одну функцию хотел реализовать, но переменная для неё оказалась из объекта Документа. Это ж чо, подумал я - надо щас или доступ к Документу получать, но это не очень правильно, и если он создан, то поздно переменную инициализировать, а если не создан, то хрен инициализируешь. Второй способ прочитать её в конструкторе Документа. Это ж чо, бля - опять проходить там этот ебаторий с открытием .ini файла? Из-за одной переменной? Нее, на хер, на хер! И не стал эту функцию делать.
Но это ещё не всё. Дело было вечером. Решил я, млин, переименовать своё приложение. Но так, чтобы старое название нигде не осталось с гарантией. А это не так просто, как кажется. Раньше как было? Пишешь компилятору или компоновщику другое имя выходного файла и готово. А тут же ini файл как-то называется, названия классов, ресурсов. Где-нибудь обязательно дерьмо да вылезет. Решил переименовать проект. Ну там, все классы и само приложение. Ооо, это то ещё шоу! В VC++ 6.0, оказывается, нельзя просто так взять и переименовать целый проект. Выручает то, что все эти их dsp, dsw просто текстовые файлы и их можно редактировать. НО! Во всех файлах сразу он заменять не умеет. Искать может, заменять только в одном. Пришлось по одному файлу фигачить. А поскольку файлы переименовываются тоже, а я не отключился от системы контроля версий или как оно там называется SVN или VSS, в общем, он видит, файлы изчезли, вместо них какие-то новые, по содержимому подозрительно похожие на старые, частично это запомнил. Я вижу такое дело, создал новый проект с новым именем, загрузил туда старые файлы и подключил к VSS. А VSS чо-то не ведётся, видит, что это старые файлы. Надо было создать новый проект, подключить его к VSS, а потом уже загрузить новое старое файло и сделать check in. Так я в конце концов и сделал. Но много ругался, хотя, в общем. сам виноват.
Начал читать тут книжку 55 полезных советов для С++. В оглавлении был совет проверить operator= на равенство самому себе. Ну, типа когда присваивание а=а. Я подумал и ввёл у себя такую проверку. Потом ещё подумал - в моём случае ничего особо страшного бы не было. Ну скопировал бы он сам в себя, ну и чо. Но всё равно замечание полезное.
Чо ещё - до хрена времени отнимает это программирование. Некогда становится ни в дайрик писать, ни тырнет читать, ни много чего ещё. Но у тебя будет С++. Он заменит тебе всё. Ко мне подруга приезжает, а у меня класс не дописан или функция ошибку выдаёт. И я весь вечер об этом думаю. Хотя ей не говорю, конечно. Я ей про свои мегапрограммы даже не говорил ещё, просто сказал, мол, читаю про программирование.
Правда, несмотря на такие серьёзные прорывы в теории, к появлению алгоритма построения дерева это до сих пор не привело. Но работы ведуцца! )))
Теперь про второй проект. осторожно, ещё больше букафВ принципе, я его почти закончил. Но вот это блядское "почти", наверное, будет преследовать меня всю жизнь. Потому что всегда есть что-то доделать и никогда не знаешь, когда стоит остановиться. Но опыт растёт. Вот, значицца, несколько случаев из практики праграмиста.
Там у меня есть с десяток параметров - масштаб по Х и У, цветность, два вида ширины и формат вывода - я расщедрился, аж 16 флажков - что печатать, а что нет. Ну, хрен знает, чо там этому пользователю в голову взбредёт. На всё есть умолчания, но если они тебе не подходят, и при запуске надо каждый раз настраиваться - это заёбывает. Решил применить проверенное решение - .ini файл. Раньше я получал каталог, откуда запущена программа, добавлял туда имя программы в виде ...+"AppName.ini\0", открывал этот файл, если он открывался и не парился. Но сейчас я смекнул, что это не очень правильно, во-вторых - слишком сложно. Дотёмкал, что возможно это имя файла где-то уже есть. Скорее всего, в объекте Приложения. И, о чудо! Оно действительно там есть. Причём, не только имя exe файла, но ещё и имя ini файла. Не знаю, по каким критериям оно там ращитывается и чем отличается, у меня оба этих имени были одинаковы. И строку ".ini\0" всё равно пришлось прибавлять. И каталог получать. Но всё равно - так правильнее.
Дальше есть функция - GetPrivateProfileString, которая находит и читает строку из ini файла. Решил подробнее про это прочитать, а то какой-то ебаторий - найди файл, открой, прочитай строку, преобразуй в число. Посмотрел сначала объект Приложения. В нём есть функции GetProfileBinary, GetProfileString, GetProfileInt, которые считывают параметры из реестра или ini файла. Но примеры почему-то только с реестром. Это нам не подходит.
Смотрим LoadPrivateProfileString. Вот те на! Написано, что функция устарела не рекомендуется и используется только для старых 16-битных Win98-приложений. И ini файлы тоже устарели, щас рекомендуется пользоваться реестром. У меня внутренний конфликт. С одной стороны - это правильно. Реестр всегда в памяти, чо там прога будет дрочить жёсткий диск, считывать при каждом запуске 10 параметров, открывать-закрывать ini-файл, в то время как она может не только читать из реестра, но и писать в реестр, сохранять своё состояние. Пользователь настроил прогу, закрыл, открыл, а она всё помнит. Круто же! НО!
1) От админов я наслушался всяких страшных историй про криворукие программы, которые лезут в реестр, гадят там, в итоге реестр засирается, и его приходится чистить, а уж если там сломается что, то и Винду переустанавливать. И вообще - чем меньше туда лазишь, тем лучше оно работает.
2) Чтобы прога имела свой раздел в реестре, это надо делать полноценный инсталлятор, полноценное удаление. Стоит ли так задрачиваться из-за проги в 40Кб? Скопировал на диск, запустил, не понравилась - удалил. Никакого гемора.
Оставил пока .ini файл. Зато обнаружил ещё функцию GetPrivateProfileInt, которая тоже устарела, но мне не надо строку в число превращать - она сразу число считывает.
По идее, ini файл надо считывать в объекте Приложения. Но вот незадача - в основном переменные у меня из объекта Вида, а объект Вида из объекта приложения почему-то оказывается недоступен, хотя я пытаюсь к нему достучаться уже после макроса RUNTIME_CLASS, который эти объекты, типа, создаёт. Поэтому я, не долго думая, загрузил инишник прямо в конструкторе Вида. Уж там-то Вид доступен. И ещё одну функцию хотел реализовать, но переменная для неё оказалась из объекта Документа. Это ж чо, подумал я - надо щас или доступ к Документу получать, но это не очень правильно, и если он создан, то поздно переменную инициализировать, а если не создан, то хрен инициализируешь. Второй способ прочитать её в конструкторе Документа. Это ж чо, бля - опять проходить там этот ебаторий с открытием .ini файла? Из-за одной переменной? Нее, на хер, на хер! И не стал эту функцию делать.
Но это ещё не всё. Дело было вечером. Решил я, млин, переименовать своё приложение. Но так, чтобы старое название нигде не осталось с гарантией. А это не так просто, как кажется. Раньше как было? Пишешь компилятору или компоновщику другое имя выходного файла и готово. А тут же ini файл как-то называется, названия классов, ресурсов. Где-нибудь обязательно дерьмо да вылезет. Решил переименовать проект. Ну там, все классы и само приложение. Ооо, это то ещё шоу! В VC++ 6.0, оказывается, нельзя просто так взять и переименовать целый проект. Выручает то, что все эти их dsp, dsw просто текстовые файлы и их можно редактировать. НО! Во всех файлах сразу он заменять не умеет. Искать может, заменять только в одном. Пришлось по одному файлу фигачить. А поскольку файлы переименовываются тоже, а я не отключился от системы контроля версий или как оно там называется SVN или VSS, в общем, он видит, файлы изчезли, вместо них какие-то новые, по содержимому подозрительно похожие на старые, частично это запомнил. Я вижу такое дело, создал новый проект с новым именем, загрузил туда старые файлы и подключил к VSS. А VSS чо-то не ведётся, видит, что это старые файлы. Надо было создать новый проект, подключить его к VSS, а потом уже загрузить новое старое файло и сделать check in. Так я в конце концов и сделал. Но много ругался, хотя, в общем. сам виноват.
Начал читать тут книжку 55 полезных советов для С++. В оглавлении был совет проверить operator= на равенство самому себе. Ну, типа когда присваивание а=а. Я подумал и ввёл у себя такую проверку. Потом ещё подумал - в моём случае ничего особо страшного бы не было. Ну скопировал бы он сам в себя, ну и чо. Но всё равно замечание полезное.
Чо ещё - до хрена времени отнимает это программирование. Некогда становится ни в дайрик писать, ни тырнет читать, ни много чего ещё. Но у тебя будет С++. Он заменит тебе всё. Ко мне подруга приезжает, а у меня класс не дописан или функция ошибку выдаёт. И я весь вечер об этом думаю. Хотя ей не говорю, конечно. Я ей про свои мегапрограммы даже не говорил ещё, просто сказал, мол, читаю про программирование.
@темы: программирование