Мне тут пришлось вспомнить, как же все таки надо писать на С, хотя работаю С++ программистом. И мне так не хватало классов и методов, что я стал думать, как можно приблизить С к С++. Зачем? Просто так, мозги размять.
Основное пожелание было следующим: хочется, чтобы в С работал примерно такой код:

void print_name( Iface* ptr )
{
    ptr->print_name();
}

void main()
{
    A a;
    B b;

    print_name( &a );    // выдаст "This is A object"
    print_name( &b );    // выдаст "This is B object"
}

По сути, A и В наследуют один и тот же (а может и несколько) интерфейс(ов). При этом можно на этих объектах вызывать виртуальные методы, действующие в зависимости от того, какой указатель был подан.

Кому интересно, что получилось в итоге (а в каком-то виде задача была решена) и кому интересно, как примерно в С++ реализуются виртуальные методы, прошу под кат.

Когда участвуешь в разработке достаточно сложных проектов, то написать неправильно работающий код проще простого. Вся загвоздка заключается в том, что ошибку начинаешь искать в самых темных закоулках проекта, в самых сложных его частях. При этом в голову даже и мысли не приходит, что не работать может самый простой код, основа всего проекта: framework.
В данном посте я опишу две проблемы, с которыми я столкнулся на практике: невозможность создать еще один поток и переименовать файл. Используемый язык программирования: C/C++.

Рассмотрим следующую ситуацию: есть приложение, которое использует AMD GPU для своих вычислений. Как правило, на GPU выносятся самые ресурсоемкие операции. Поэтому если приложение работает быстрее своих конкурентов, то может возникнуть желание узнать, какой же алгоритм реализован в этой программе. Но что делать, если программа является проприетарной и распространяется по лицензии, запрещающей reverse engineering и дизассемблирование?

Чтобы не нарушать лицензии, можно воспользоваться одной маленькой хитростью, оставленной разработчиками AMD APP SDK. Однако чтобы эта хитрость сработала, необходимо выполнение еще одного условия (помимо использования разработчиками приложения указанного SDK): приложение должно использовать OpenCL для вычислений на GPU.

В первой части я рассказал о технологии AMD Intermediate Language (IL). В этой статье, как можно догадаться из заголовка, речь пойдет о второй составляющей: AMD Compute Abstraction Layer (CAL). Эти две технологии являются нераздельными друг от друга: невозможно использовать одну, не используя другую. Поэтому для понимания дальнейшего рекомендую ознакомиться с первой частью.

Я постараюсь осветить основные аспекты работы на верхнем уровне с AMD GPU, опишу ограничения данной технологии и возможные проблемы при работе с ней. Кому интересно, прошу под кат.

ATI Stream SDK было переименовано в AMD Accelerated Parallel Processing (APP) SDK, на смену основного языка программирования GPGPU вычислений Brook+ пришел OpenCL. Однако, не многие догадываются, что писать код для ATI-шных карточек можно при помощи другой технологии: AMD Compute Abstraction Layer (CAL) / Intermediate Language (IL). Технология CAL предназначена для написания кода, взаимодействующего с GPU и выполняющегося на CPU, в то время как технология IL позволяет писать код, который будет выполняться непосредственно на GPU.

В данной статье будет рассмотрена технология IL, ее область применения, ограничения, преимущества по сравнению с OpenCL. Кому интересно, прошу под кат.