23 февраля 2009 г.

Всего понемногу

Ну вот и приехал я с сессии.
Значит сдался нормально, но к 25 мая нагрузили ещё больше чем в предыдущий раз, но ничё, думаю справлюсь.

На данный момент заканчиваю разработку Lolmen Library в которой будет всё, что часто мне необходимо в процессе программирования, но зависимость от кучи "стандартных" *.h'ников мозолит глаз. Туда входят аналогичные stl'ю контейнеры с большей функциональностью и без излишеств. Математическая библиотека, Набор паттернов проектирования. В библиотеке у всех компонентов названия методов говорят сами за себя, не нужно более использовать мелкие функции, например memcpy или sscanf и т.п.
Всё автоматизировано и встроено таким образом, что stdio и другие *.h'ники нетребуются, всё имплементировано с нуля практически на native C++ с шаблонами,
таким образом не нужно тянуть за собой горы глобальных переменных флагов и "мульти" функций 80x годов (пример - проследите цепочку вызовов vsnprintf( ... ) )

В библиотеке всё базируется на удобных классах.

LString str;
str.Format( "%s %d %s", "Players", nActivePlayerCount, "Active" );

Где сам Format и str.Scan( format, ... ); не начинают лезть в stdio.h и далее по цепочке, а лезут в класс за токенами и парсят всё вручную.

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

На этой неделе начну довершать порт мода E32k3 на Source Engine Ep2
проведу пару прогонов, и отдам народу как есть.

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

З.Ы Совсем забыл, с праздничком мужЫки!

3 комментария:

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

    Велосипедостроение - хроническая патология всех вот таких "С++ разработчиков". Тысячи программистов ( каждый из которых, кстати, в миллион раз профессиональнее всех вместе взятых "разработчиков" ) оказывается полные профаны! Ибо один "разработчик" может перечеркнуть своей могучей рукой всю многолетнюю работу даже комитета по стандартизации и сказать "аналогичные stl'ю контейнеры с большей функциональностью и без излишеств". Т.е. комитет делал-делал, а пришел "разработчик" и за пол часа сделал лучше. Просто магия какая-то.

    И девиз всех наших "разработчиков" - если я не умею грамотно ЭТИМ пользоваться, значит ЭТО - плохо. И наши "разработчики" свято верят в то, что программирование - это написание непонятных строчек кода. Наши "разработчики" в большинстве своем не имеют никакого образования, и с уверенностью могут сказать что, например, что критерий Фишера или Фурье-анализ не имеет ничего общего с программированием.

    Все это напоминает слова Страуструпа "с помощью препроцессора вы даже можете создать свой собственный язык! Только вряд-ли кто-то кроме вас сможет им пользоваться". Так и с "разработчиками"... Это как броуновское движение - все частицы тела движутся, но само тело остается неподвижным. Амбиций, телодвижений море, а толку ноль.

    Вот скажи мне, например, чем же ты заменил memcpy? И чем тебе оно так мешало?

    ОтветитьУдалить
  2. А кто говорил, что я не умею грамотно пользоваться STL? В своё время пользовался так, что уже нехватку стал чувствовать. Писать разные екстеншены и потом копипастить из прожекта в прожект стало уморительным занятием.
    Если с отладчиком пройтись по вызовам, можно обомлеть сколько повторных проверок производится на целостность данных, которые можно выполнять за раз. Комитет по стандартизации принял свод правил и к нему я конечно стремлюсь, но вот их гуру походу переборщили с концепциями поддержка ansi, posix, ieee естественно максимально возможно реализована, но только внешне.
    Я не претендую на качество и не стараюсь быть "круче" комитета по стандартизации. Моя цель это аналогия stl, но для геймдева, без exception base конструкторов (exceptions вообще в STL отключаются, но не все гейм девелоперы домашнего пожима знают), без
    умопомрачительной цепочки вызовов (отладить хотябы vprintf ).

    стандартные функции math lib: у меня получился буст по перфомансу +40% на функциях arc(cos,sin,tan) корне, и т.д. Погрешность +/- 0.0002%.

    memcpy мне не угодил подключением h'ника. :)
    заменил его, на аналогию memcpy_s.

    ОтветитьУдалить
  3. "копипастить из прожекта в прожект стало уморительным занятием"
    И это говорит человек, который якобы умеет грамотно пользоваться STL! Я, наверное, сейчас тебе страшный секрет открою, но копипаст - это не единственный способ повторного использования кода.

    "можно обомлеть сколько повторных проверок производится на целостность данных"
    Ну и опять из темы - программисты писали-писали, но вот пришел ОН и оказалось, что программисты полные профаны, и все можно сделать проще. Ты хоть привести пример лишних проверок привести можешь? Или для тебя помещение int a = new int[500] в try блок абсолютно лишнее занятие? Ну тогда о надежности своих программ можешь смело забыть.

    "Моя цель это аналогия stl, но для геймдева"
    Громко сказано... Чем для тебя stl вообще является? Просто библиотекой? stl - это стандартное, переносимое, универсальное, надежное средство быстрого решения большинства типовых задач. И эффективна она ровно на столько, насколько это возможно без ущерба для ее основных характеристик, приведенных выше. И о какой аналогии может идти речь, если ты плюешь на надежность и переносимость, и основным параметром эффективности у тебя есть кол-во вызовов и подключаемых h'ников? К тому же пользователю прийдется ее копипастить в прожект! Смех да и только...

    "умопомрачительной цепочки вызовов (отладить хотябы vprintf )"
    А ты хоть представляешь себе какое влияние на финальную производительность оказывает эта "умопомрачительная цепочка вызовов"? Даже просто вывод на консоль в разы медленнее сотни вызовов! Я для интереса тестик написал, который показал, что 1000000 вызовов без вывода на консоль в 55 раз быстрее 10000 вызовов с выводом. Не стоит искать проблемы там, где их нет! Вот эти неудержные порывы к оптимизации того, что в этой самой оптимизации абсолютно не нуждается - отличительная особенность "разработчиков" (как Кнут говорил: преждевременная оптимизация - корень всех зол). Оптимизация - это не так просто, как ты думаешь...

    "у меня получился буст по перфомансу +40% на функциях arc(cos,sin,tan)"
    Спешу тебя огорчить, но я сполпинка нашел реализацию (http://cgm.computergraphics.ru/content/view/78#_Toc104471663), которая пророчит 18-ти кратное ускорение. Даже если ополовинить это значение, то 600% как-то по привлекательней 40% смотрятся. Еще раз повторяю - оптимизация - это не так просто! Нужно очень глубоко изучать вопрос!

    "memcpy мне не угодил подключением h'ника. :)"
    ХА! труба... А ты думаешь что для memcpy_s h'ник не нужен? Если на твоей платформе необходимый h'ник подключается неявно, то это совсем не обозначает, что так происходить будет и на другой платформе. Как следствие - можешь забыть о переносимости. Мне не веришь, почитай Майерса, 48 совет его книжечки об эффективном использовании STL, как раз этому посвящен.

    И что мы имеем? В первом приближении - непереносимое, ненадежное, не хвастающее высокой производительностью решение. Кому оно нужно? Одумайса...

    ОтветитьУдалить