Интуитивное программирование

Облако тэгов

2010-12-31T22:06:00.001+02:00

В процессе блуждания по интернету набрел на http://www.wordle.net/ - сервис, который позволяет генерировать облако тегов в соответствии с заданными данными.
Пришла в голову мысль, что с помощью облака тегов гораздо проще рассказывать о чем-либо: о частоте, продолжительности, силе.

Для примера составил облако своего профессионального опыта=)

Подсветка синтаксиса материалов в Ogre3D

2010-12-19T14:42:00.000+02:00

В последнее время я постоянно стараюсь узнавать про vim что-то новое. Одним из такого нового для меня стали синтаксические файлы, позволяющий описать, как собственный код будет подсвечен.

Я решил попрактиковаться и сделал подсветку для файлов материалов Ogre3D. Итоговый результат получился размером на 530 строк зато может подсвечивать некоторые ошибки!

Итоговый результат доступен здесь.

Autocomplete

2010-12-13T22:50:00.000+02:00

На днях принял решение значительным образом сократить использование autocomplete. Вызвано это было следующими причинами:

обнаружил, что после дня использования autocomplete-а серьезно сокращается скорость ввода английского текста и руки некоторое время приходится приучать заново. :)
периодически "умный" механизм подсказки ошибается и подставляет на место уже практически набранного слова полный бред; ужасно бесит. Позвольте пользователям самим совершать ошибки!
автоматически всплывающая подсказка переводит (да, это так) внимание с текущей мысли на выбор нужного варианта.
код, на мой взгляд, запоминается куда как хуже, когда работаешь не своими руками, а пользуешься виртуальным помощником.

В разумных количествах autocomplete - несомненное добро, но то, к чему приводит VS2010 + VAssist с максимальным уровнем подсказок - точно перебор.

Наследование в C!

2010-12-12T14:36:00.001+02:00

Как реализовать наследование в C? Скажете, там и классов-то нет!

Разбираюсь с GTK+ - кроссплатформенным набором инструментов для создания GUI. Там достаточно часто встречается код подобного вида

GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_signal_connect( GTK_OBJECT(window), "delete_event", GTK_SIGNAL_FUNC(delete_event), NULL );

где GTK_OBJECT - фактически макрос приведения указателя на структуру GtkWidget к указателю на структуру GtkObject.

Так вот. Идея заключается в том, что если GtkWidget имеет вид

struct GtkWidget
{
  GtkObject innerObject;
};

то такое приведение действительно будет работать в C, а это значит, что одиночное наследование реализуется достаточно просто.

P.S. Следует учитывать, что в самом GTK макрос кроме непосредственно приведения указателей выполняет еще и проверку типов, так что будьте внимательны!

Paged Geometry или почему я не люблю STL streams, а также как их правильно готовить.

2010-12-10T00:38:00.000+02:00

Небольшое вступление, не совсем в тему, зато весьма поучительное и отражающее основную суть вопроса.

File copy circa 1975:

#include <stdio.h>
int main() {
int c;
while ((c = getchar()) != EOF)
    putchar(c);
    return errno != 0;
}

Fast forward 20 years, and...

#include <iostream>
#include <algorithm>
#include <iterator>
#include <string>
using namespace std;
int main() {
    // (forgot the try/catch around main)
    copy(istream_iterator<string>(cin),
    istream_iterator<string>(),
    ostream_iterator<string>(cout,"\n"));
}

Something, somewhere, went terribly wrong.

Andrei Alexandrescu.

Я помню, как еще шесть с половиной лет назад, начиная изучать C++ я читал о потоках в STL и думал "Как это круто! Они так неожиданно и здорово перегрузили оператор <<". Однако время идет, а ореола очарования постепенно сошел на нет.

Первая проблема. They are too verbose! (В них чересчур много буков).
Пример из реально работающего кода.

        std::cout << std::setw(2) << std::setfill('0') << (pTime->tm_mon + 1)
            << std::setw(2) << std::setfill('0') << pTime->tm_mday
            << std::setw(2) << std::setfill('0') << (pTime->tm_year + 1900)
            << "_" << std::setw(2) << std::setfill('0') << pTime->tm_hour
            << std::setw(2) << std::setfill('0') << pTime->tm_min
            << std::setw(2) << std::setfill('0') << pTime->tm_sec
            << std::setw(3) << std::setfill('0') << (mTimer->getMilliseconds() % 1000);

В C-стиле это будет выглядеть как

printf( "%02d%02d%02d_%02d%02d%02d%03d", 
        (pTime->tm_mon + 1),
        pTime->tm_mday,
        (pTime->tm_year + 1900),
        pTime->tm_hour,
        pTime->tm_min,
        pTime->tm_sec,
        (mTimer->getMilliseconds() % 1000 
);

Как по мне, так второй код читается лучше, а пишется короче. Так почему же "something has gone wrong?"

Вторая причина. Работаем мы с open-source движком Ogre3D, таким большим, толстым с очень длинными именами классов навроде Ogre::HardwareVertexBufferSharedPtr и достаточно интенсивным использованием строк.

Делаем в проекте рендеринг огромных массивов растительности (бескрайний лес:)), используя PagedGeometry - плагин к огру; как раз подошла необходимость заняться оптимизацией. Проблема заключается в том, что у нас единовременно подгружаются достаточно большие участки леса и при этом наблюдается заметный лаг.

Включаю профайлер и что же я вижу? (Обратите внимание на Forests::BatchedGeometry::SubBatch::build/)

Функция которая должна вызываться не чаще, чем раз в 10 кадров пятая по времени среди "горячих точек"!

Копаем дальше! Это результаты еще одной сессии профилирования, где BatchedGeometry::build заняло в целом около 1.4 с. времени.

Ничего себе. В коде генерации деревьев больше половины времени занимают операции со строками!

Как только код c

String BatchedGeometry::getFormatString(SubEntity *ent)
{
 StringUtil::StrStreamType str;
 
 str << ent->getMaterialName() << "|";
 str << ent->getSubMesh()->indexData->indexBuffer->getType() << "|";
 
 const VertexDeclaration::VertexElementList &elemList = ent->getSubMesh()->vertexData->vertexDeclaration->getElements();
 VertexDeclaration::VertexElementList::const_iterator i;
 for (i = elemList.begin(); i != elemList.end(); ++i)
 {
  const VertexElement &element = *i;
  str << element.getSource() << "|";
  str << element.getSemantic() << "|";
  str << element.getType() << "|";
 }
 
 return str.str();
}

был заменен на

String BatchedGeometry::getFormatString(SubEntity *ent)
{
   const int BufSize = 1024;
   char buf[BufSize];


   int countWritten = 
         _snprintf_s( buf, BufSize,
               "%s|%d",
                ent->getMaterialName().c_str(), 
                ent->getSubMesh()->indexData->indexBuffer->getType() 
         );

   const VertexDeclaration::VertexElementList &elemList = ent->getSubMesh()->vertexData->vertexDeclaration->getElements();
   VertexDeclaration::VertexElementList::const_iterator i;
   for (i = elemList.begin(); i != elemList.end(); ++i)
   {
      const VertexElement &element = *i;
      countWritten += _snprintf_s( buf + countWritten, BufSize - countWritten, BufSize - countWritten,
                         "|%d|%d|%d",
                          element.getSource(),
                          element.getSemantic(),
                          element.getType()
                        );
   }

   return buf;
}

Время генерации деревьев сократилась в 2-2.2(!!!!!!) раза: вместо средних 4.8-5.6 мс на один вызов стало 2.2-2.8. Не знаю, ругаться на разработчиков PagedGeometry или на реализацию стримов у Майкрософта?

Такая низкая скорость работы объясняется тем, что

сами потоки - объекты, которые любят выделять память, в частности на создании и удалении;
реализация STL от майкрософта по умолчанию вставляет локи на работу с потоками, если проект собирается, как multithreaded.

Итак, они медленные.

Так что я буду по-прежнему использовать printf или класс StringFormatter и пусть меня убеждают и дальше о пользе некоторых абстракций STL. :)

P.S. Между прочим у Александреску есть отличная статья на тему типо-безопасного printf-а!

Dynamic vs. pregenerated content

2010-12-08T00:15:00.001+02:00

Вот что странно. За всю свою историю путешествий по интернету я НИ РАЗУ не встречал рассказа о том, как организована система сборки в том или ином игровом проекте (мультимедиа проекте; проекте, связанном с 3D графикой - нужное подчеркнуть).
А интересных тем там будет немало:

как храним код и файлы ресурсов?
какую make систему использовать?
как копируем файлы?
как делаем препроцессинг ресурсов? много утилит или одна со множеством плагинов?
должны ли все утилиты быть отправлены в систему контроля версий или каждый разработчик самостоятельно ставит себе, все, что надо?
как, в конце концов, интегрируем эту систему с нашим любимым супер навороченным редактором/IDE?

Все эти вопросы начинают занимать голову, когда билд приходит в неуправляемое состояние.

В следующем посте я постараюсь рассказать о том, как это все сделано у нас, а пока что...

Я до сих пор очень люблю pre-generated content(PreGC), то есть все данные, которые генерируется до запуска приложения. Это, по сути дела, чем-то похоже на конфиг файлы, куда можно все записать заранее, проверить(что очень важно!) отдельно, а потом использовать. В результате получаем отдельный модуль, который не нужно доводить до 100% оптимального состояния: алгоритмы в офлайне можно использовать самые простые и быстрые для написания.

У динамического контента(DynGC) те же недостатки, что и преимущества у заранее сгенерированного:

код приложения усложняется, могут понадобиться различные изощренные оптимизации;
модульность куда как сложнее организовать;
данные проверить становится уже сложно, потому что не всякий разработчик DynGC озаботится модульностью (к сожалению, это так!).

Так что второй вариант выбирать логичнее в случае либо его излишней простоты, либо когда объем данных становится излишне большим.

Хотя вообще спор на эту тему напоминает некий холивар, в котором побеждает тот, у кого больше звездочек на погонах. :)

Vim. Чем же он так хорош?

2010-12-04T00:00:00.002+02:00

Решил изучить Vim, в планах было давно, но все как-то откладывал.

Помню раньше, работая с сервером под Линухой пользовался вимом для редактирования конфигов - и не понимал всей его прелести. Поэтому меня очень удивило, когда в одной презентации от господ Инсомниаков(проекты - раз, два; вики - три ),я увидел скриншот кода, в котором было окошко вима. Это резко изменило мое представление о виме, и я поставил зарубку на память.

Итак, с чего же я начал?

Для начала, я нашел несколько вариантов для работы с вимом под виндой.

gvim - официально-родная графическая оболочка для vim, существует как под виндой, так и под линухой.
VimEmu - плагин для студий версий 2002 и выше, в том числе и 2010. Однако, оказалось, что он платный и не лечится, а отдавать порядка 100$ на что-то, что я еще не изучил...=)
VsVim - плагин для студии 2010. Open Source проект от одного из разработчиков Microsoft; начат в декабре прошлого года, так что находится уже в достаточно зрелом состоянии. Именно на нем я и остановил свой выбор.

Об этом много уже говорилось, но основное преимущество вима - в том, что не надо прыгать руками по всей клавиатуре, чтобы сделать чтов-то и большинство действий можно выполнить не сходя с буквенно-цифровой части клавиатуры.

Как же работает сам редактор? У него есть несколько режимов функционирования:

режим вставки - работает так же, как и ввод текста в "обычном" текстовом редакторе.
командный режим - в нем можно вводить команды: перемещения по тексту и редактирования.
визуальный режим - можно выделять текст и выполнять команды редактирования уже над выделенным текстом.

В командном режиме команда действия частенько может сочетаться с командой перемещения. Так, для того, чтобы удалить слово нужно набрать - <Удалить><Переместиться на слово вперед>, а на клавиатуре - это будет dw. Приятнее, чем Ctrl +Shift + Right -> Del, не так ли? :)

Для начала я выучил основные команды для работы с текстом:

перемещения (h, j, k, l - вниз, влево, вправо, вверх; w,b - на слово вперед и назад)
редактирования текста (d - удалить, p - вставить ) и проч.

И начал пробовать. Первые несколько дней мозг ломало по-страшному. У меня с трудом получалось думать о том, что же именно я пишу, а большую часть времени занимало обдумывание следующего действия, примерно так( "джей-джей-эйч-ди-ви"). До сих иногда начинаю разговаривать с собой, когда использую команду, которая еще не записалась на подкорку.

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

Скорость редактирования действительно увеличивается, но для этого желательно обладать навыками слепой печати. В других текстовых редакторах руки машинально тянутся к Esc и пытаются вставить новую строку над текущей с помощью Shift+o, замечаю, что некоторых функций в них мне уже не хватает - вводить в виме приходится куда как меньше буков. Признаюсь правда, что иногда все-таки использую мышку. На мой взгляд текст ею прокручивать все-таки удобнее)

Еще больше преимущество вима осознал, когда пришлось повозиться с вот этим фрагментом кода:

// Set up root attribute parsers
mRootAttribParsers.insert(AttribParserList::value_type("material", (ATTRIBUTE_PARSER)parseMaterial));
mRootAttribParsers.insert(AttribParserList::value_type("vertex_program", (ATTRIBUTE_PARSER)parseVertexProgram));
mRootAttribParsers.insert(AttribParserList::value_type("geometry_program", (ATTRIBUTE_PARSER)parseGeometryProgram));
mRootAttribParsers.insert(AttribParserList::value_type("fragment_program", (ATTRIBUTE_PARSER)parseFragmentProgram));

//////////////////////////
// a lot of lines of codes
//////////////////////////
mPassAttribParsers.insert(AttribParserList::value_type("polygon_mode", (ATTRIBUTE_PARSER)parsePolygonMode));
mPassAttribParsers.insert(AttribParserList::value_type("polygon_mode_overrideable", (ATTRIBUTE_PARSER)parsePolygonModeOverrideable));

Нужно было извлечь все строки, присутствующие в коде. Не знаю, сколько я бы возился в студии, даже с учетом прямоугольного выделения текста, но в виме это получилось за нажатие порядка 15 клавиш - всего-то записать макрос и воспроизвести его!

Сейчас очень доволен тем, что решил его таки изучить и сделал его своим текстовым редактором по умолчанию. Все - на вим! Хотя бы попробовать, чтобы понять, как работают программисты в другом мире =)

Декларация этого блога!

2010-12-02T00:07:00.001+02:00

1) Заводя этот блог я не претендую на то, что он будет обладать исключительным качествами, полезным эффектом (повышения уровня программинга +10, скорости печати +3 и удовлетворения от чтения +4), но собираюсь наполнять его материалом, интересным мне, а, значит, могущим быть интересным кому-то еще.
2) Заводя этот блог, я надеюсь найти единомышленников, которые будут высказывать свое профессиональное и авторитетное мнение по интересным им вопросам.
3) Я хочу не только получать знания, но и делиться с ними, так как в этом я чувствую сильную потребность.

Вот и все. Поехали!