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

Что-нить вроде такого, например:

static void foo();

struct method_exists {
    void foo();
};

struct method_not_exists {
    void foo();
};

template <typename T>
void call_foo(T * ptr);

Где call_foo в зависимости от существования в определении класса T метода foo вызвала бы этот метод, либо глобальную реализацию static void foo.

Вот такой я извращенец, дооааааа

---

Скоро будет ОНО.

---

Пора бы написать, что я об этом думаю

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

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

Анонимность - это маска. Маска, скрывающая личность. А раз она скрывает личность - то неизвестно, кому принадлежит авторство. Что, в свою очередь, означает относительную безнаказанность говорить или делать (в дайрах - только говорить) все, что угодно. Помните притчу о потерянном рае? Да-да, ту самую библейскую притчу об Эдеме, Адаме, Еве и Первородном Грехе? Так вот раз есть возможность говорить, что угодно, то с какой стати кто-то будет пренебрегать этой возможностью? Не спорю, разумные единицы среди анонимусов есть, но в том-то и дело, что это только единицы! А раз большинство скорее всего не будет считать с "границами дозволеного" (троллинг на дваче тому пример) - значит, надо принимать защитные меры превентивного характера.

Но и это только половина. Вторая половина становится видна, если посмотреть на ситуацию со стороны "разговаривающего с анонимусом", но тут мне придется потерять объективность и говорить совсем от себя. Анонимус в силу своего статуса может говорить все, что угодно. С моей точки зрения, анонимус - человек для меня совершенно чужой и незнакомый, "человек из толпы". Отсюда возникает вопрос: с какой стати я должен делать для него какие-то поблажки и терпеть то, что я стал бы терпеть, скажем, от моего брата Тимура, от моих друзей Вовы, Крафта, Мехи - да кого угодно из моих близких, этот список можно продолжать очень долго. Это примерно то же самое, как позволять совершенно незнакомому прохожему на улице отпускать едкие шутки в стиле того же Вовы (нет, ничем он мне не насолил - просто пример яркий ), а юмор у него бывает оч едким, порой даже слишком. И если я согласен на такие шутки с его стороны, то это только потому, что мы - друзья и я знаю, что это именно юмор, а не проявление агрессии, чего я не могу сказать про анонимусов.

Анонимус по-умолчанию воспринимается "чужим". Это значит, что отношение к нему по-умолчанию "нейтральное". А с учетом "относительной вседозволенности" и огромного соблазна "троллить" - отношение сдвигается на "вооруженно-нейтральное".
Раз отношение "вооруженно-нейтральное" - то все, что похоже на агрессию в той или иной форме - расценивается как агрессия в той или иной форме. А на агрессию надо отвечать.

Отсюда и превентивный сарказм, мои "дорогие" анонимусы.

@музыка: Infected Mushroom - The Beauty and the Beat

@темы: личное

---

Меня подсадили на доктора Хауса. Теперь я ищу трость и жру викодин ириски.

ЗЫ: Добро пожаловать, Абель Найтроуд

---

Вот вам еще жирчику!

Итак, продолжение предыдущего поста.

Собственно, сам адаптер

template <class inner_iface, class outer_class>
class Adapter : public inner_iface {
  private:
    typedef Adapter<inner_iface, outer_class> This_Adapter;
    struct list {
      void ** const ptr;
      list * const next;
      
      list(list * & list_head, void **elem) : ptr(elem), next(list_head) { list_head = this; }
      ~list() { *ptr = 0; }
      
      static void clear_list(list * &list_head) {
        while (list * cur = list_head) {
          list_head = cur->next;
          delete cur;
        }
        list_head = 0;
      }
    };
  
  protected:
    
    class Adaptive : public outer_class {
      friend class Adapter<inner_iface, outer_class>;
      private:
        bool adapter_killed;
        list * adaptive_list_head;
        
      protected:
        Adapter * const _adapter;
        
      public:
        Adaptive (Adapter * const ptr) : _adapter(ptr), adapter_killed(false), adaptive_list_head(0) { }
        virtual ~Adaptive () {
          if (!adapter_killed) {
            _adapter->adaptive_killed = true;
            delete _adapter;
          }
          list::clear_list(adaptive_list_head);
        }
        
        // framework interface implementations and delegations
    };
    
    Adapter(Adaptive * adaptive) : _adaptive(adaptive), adaptive_killed(false), adapter_list_head(0) { }
    
  private:
    friend class Adaptive;
    
    list * adapter_list_head;
    
    Adaptive * _adaptive;
    bool adaptive_killed;
    
    outer_class * const get_adaptive() const {
      return (outer_class * const) _adaptive;
    }
    
    Adapter * & operator & ();
  
  public:
    
    virtual ~Adapter() {
      if (!adaptive_killed) {
        _adaptive->adapter_killed = true;
        delete _adaptive;
      }
      list::clear_list(adapter_list_head);
    }
    
    void get_registered_adaptive(void** pointer) {
      *pointer = (void *)get_adaptive();
      new list(_adaptive->adaptive_list_head, pointer);
    }
    
    void get_registered_adapter(void** pointer) {
      *pointer = (void*)this;
      new list(adapter_list_head, pointer);
    }
    
    // framework realizations
};

Пример использования

struct Interface_framework {
  virtual void framework_foo() = 0;
  virtual ~Interface_framework () { }
};

struct Interface_inner {
  virtual void inner_foo() = 0;
  virtual ~Interface_inner () { }
};

#include "adapter.h"

using namespace std;

// class from framework
class Framework_class : public Interface_framework {
  public:
    void framework_id() { cout << "Framework_class" << endl; }
};

// adapter framework -> local
class Concrete_adapter : public Adapter<Interface_inner, Framework_class> {
  
  private:
    typedef Adapter<Interface_inner, Framework_class> Parent_adapter;
    
    class Adaptive : public Parent_adapter::Adaptive
    {
      public:
        void framework_foo() { _adapter->inner_foo(); }  // delegate
        Adaptive(Concrete_adapter * const ptr) : Parent_adapter::Adaptive(ptr) { }
    };
    
  public:
    Concrete_adapter() : Parent_adapter(new Adaptive (this)) { }
    
    void inner_foo() { cout << "Adapter_class::inner_foo" << endl; }
};

// -------------------------------------------------------------------------------------------------------

// int main (int argc, char *argv[])
  // inner code
  Concrete_adapter * obj_ptr = new Concrete_adapter;
  obj_ptr->inner_foo();
  
  // framework code
  Interface_framework * ptr;
  obj_ptr->get_registered_adaptive((void**)&ptr);
  ptr->framework_foo();
  ((Framework_class *) ptr)->framework_id();
  
  Concrete_adapter * adapter_ptr_test;
  obj_ptr->get_registered_adapter((void**)&adapter_ptr_test);
  
  // адаптер удаляется вместе с внутренним классом
  // adapter_ptr_test = 0; 
  delete ptr;

Я опубликовал, а вы раскуривайте.

@темы: программистское, личное

---

Хы! И вот снова!

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

Пример ситуации

class Parent {
public:
    virtual void visible () = 0;
    virtual void hidden () = 0;
};

class Child : public Parent {
public:
    virtual void visible () { /*...*/ }
private:
    virtual void hidden () { /*...*/ }
};

Child child;
Parent & parent = child;

parent.visible();  // ОК
child.visible();  // ОК
parent.hidden();  // ОК
child.hidden();  // BOOM!!! Unaccessible!

Можно попробовать в некотором классе иерархии (не корневом, т.к. надо только на 1 подкласс) обьявить скрываемый метод невиртуальным, но толку от этого все равно не будет, если в корневом классе метод объявлен виртуальным.

В результате народилась следующая идея:

Идея, надо отметить, совершенно не новая. Адаптер в его чистом виде. Скрываемые вызовы перехватываются в классе Adaptive, остальные - банально делегируются классу Adapter, где они при необходимости уходят в реализацию классов-наследников вроде Concrete_adapter.
Adaptive сделан внутренним классом, чтоб никто до него не достучался извне, ибо его задача - исключительно делегировать вызовы по виртуальным методам.

@темы: программистское, работа

---

18.09.2009 в 02:25

Пишет  Крафт:

17.09.2009 в 23:47

Пишет  Крафт:

После долгого затишья...
...буря!

А именно, концерт, посвященный дню рождения группы.
Состоится он 11 октября в Клубе FM.
Начало концерта в 18.30.
Стоимость билета - 300 рублей.
Адрес клуба и схему проезда можно посмотреть здесь.

Так же - уже традиционно - в преддверии дня рождения, Ignes Fatui объявляет конкурс!
Правила просты как никогда:
- вы рисуете, снимаете фото или клипы, пишете стихи или рассказы (song-фики) по нашим песням;
- присылаете их на нашу почту [email protected] до 7 октября, или приносите в день концерта, если это рисунки/фотографии;
- и получаете приз от любимой группы! Внимание, в каждой номинации вручается только один приз.
- Лучшие работы будут помещены на сайт группы.



Распространение информации приветствуется.

---

Lot of hate

Нервный тик от вида одного ника этого мат-мат-мат так и не прошел.

---

Да, я ж таки пробую рисовать.

---

Итак, "продолжаем продолжать" (с)

Я обещал описать как работает конструкция вот тут. Итак, были объявлены структуры ассоциируемых наборов параметров и обьявлены 2 макроса.
В нужном месте cpp-файла соответствующим макросом обьявляется структура описания, которая сразу же обьявляет свой экземпляр. Так как экземпляр обьявляется статическим, вызывается соответствующий конструктор, добавляющий себя в карту ассоциаций. Т.к. структура обьявлена макросом, то препроцессор генерирует ключ и все нужные параметры.

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

Еще пример для самых упоротых

// где-то, не важно, где:
class Plugin : public Plugin_interface { /*...*/ };

class Complicated_plugin : public Plugin_interface {
public:
    std::string get_condition_value () { /*...*/ }
    /*...*/
};

class Another_complicated_plugin : public Plugin_interface {
public:
    std::string condition;
    /*...*/
};

// в "нашем" коде:
DECLARE_PLUGIN_DESCRIPTION(Plugin, 123);

DECLARE_PLUGIN_DESCRIPTION_CONDITION(Complicated_plugin, 0, 111, get_condition_value());
DECLARE_PLUGIN_DESCRIPTION_CONDITION(Complicated_plugin, 1, 222, get_condition_value());

DECLARE_PLUGIN_DESCRIPTION_CONDITION(Another_complicated_plugin, 2, 333, condition);
DECLARE_PLUGIN_DESCRIPTION_CONDITION(Another_complicated_plugin, 4, 444, condition);

// место, где оно вызывается:
Plugin_interface * plugin;
Abstract_description * desc = GET_DESCRIPTION(plugin);
if (desc != NULL) {
    desc->get_param(plugin);
}

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

@темы: программистское, работа

---

И снова рабочее.

Сегодня столкнулся с интересной задачкой.
Есть сторонняя библиотека, регламентирующая вид своих плагинов. Есть набор плагинов как "вшитых" в код намертво, так и отдельных (часть из них - сторонние).
Требуется прицепить к некоторым классам из плагинов некоторые одинаковые по составу наборы данных, в соответствии один класс к многим. Причем интерфейс классов этого проводить не позволяет и даже больше - некоторые конечные классы в плагинах обьявлены только в cpp-шниках, а значит в основном приложении недоступны. Чтобы стало совсем хорошо - укажем ограничение, что в некоторых из них набор определяется параметром из режима исполнения. Клиентский код работает с объектами исключительно через интерфейсы.
Единственное, что есть у классов - аналог оператора typeid, который позволяет получить строку с именем класса.

Менять интерфейс - плохо, ибо будут проблемы с обновлением, т.к. менять надо чуть ли не в корневых классах иерархии. Строить же в использующем доп. данные коде какие-то адопостроения с различием по классам тоже не хочется, ибо нагромождение и никто не может сказать, сколько кодеков будет дальше. Было решено сделать примерно следующее:

Каждый набор представляем структурой с некоторым интерфейсом, которую будем определять по строковому ключу. Ключ будет представлять собой строчку с именем класса.
Единственное, что представляет проблему - ассоциирование класса и нескольких наборов в зависимости от некоторого условия. Ввиду того, что такая ситуация была обнаружена только во "втроенных" в код плагинах, так что в таких случаях добавляем некий метод, по которому будем различать значения. Ограничение - должна быть возможна конвертация в строку. Я в своем подходе возвращал прямо строки.

Пример для самых упоротых.

// класс-родитель для всех плагинов
class Plugin_interface;

// интерфейс для набора данных
struct Abstract_description {
    virtual int get_param (Plugin_interface * ptr = 0) = 0;
};

// карта описаний
class Plugin_additional_info_map : public std::map <std::string, Abstract_description *> {
public:
    void add_description (std::string key, Abstract_description * description) {
        insert ( std::pair <std::string, Abstract_description *> ( key, description) );
    }
    Abstract_description * get_description (std::string & key) {
        iterator it = find (key);
        return (it != end()) ? it->second : 0;
    }
};
static info_map;

// макрос, объявляющий описание
#define DECLARE_PLUGIN_DESCRIPTION(class_name, param) \
    static struct class_name##__generic_description { \
        virtual int get_param (Plugin_interface * ptr = 0) { return param; } \
        class_name##__generic_description () { info_map.add_description (#class_name, this); } \
    } class_name##__generic_descriptor

// служебный макрос, ибо запись #macro1##macro2 не работает =^_^=
#define MACRO_TO_STR(macro) #macro

// макрос условного определения. Нужен, если ассоциируемый параметр зависит от некоторого значения
#define DECLARE_PLUGIN_DESCRIPTION_CONDITION(class_name, value, param, value_getter) \
DECLARE_PLUGIN_DESCRIPTION(class_name##_##value, param); \
    static struct class_name##_##value##__condition_description { \
        virtual int get_param (Plugin_interface * ptr) { \
            class_name * cls_ptr = dynamic_cast <class_name *> (ptr); \
            std::string value_str = (cls_ptr != 0) ? cls_ptr->value_getter : ""; \
            std::string class_name_str (#class_name); \
            class_name_str.append ("_"); \
            class_name_str.append (value_str); \
            Plugin_additional_info_map::iterator it = info_map.find (class_name_str); \
            return (it != info_map.end()) ? it->second : 0; \
        } \
        class_name##_##value##__condition_description () { info_map.add_description (MACRO_TO_STR(class_name##_##value), this); } \
    } class_name##_##value##__condition_descriptor

// макрос для получения параметра. Чисто для красоты 
#define GET_DESCRIPTION(class_name) info_map.get_description (#class_name)

Как оно работает - опишу позже.

@темы: программистское, работа

---

И снова рабочее

Целую неделю я парился, чтоб разобраться с подключением этой дллки. А оказалось все просто. Не, код внутри понятен... просто совершенно непонятно было как эту чертову длл вызывать. А оказалось все веселее - нужные объекты создаются автоматически хитрым механизмом, основанным на фабриках.
Точно могу сказать, что я еще не дорос до написания таких хитрых алгоритмов. Но это интересно, ибо необычно.

---

Утром зачем-то читал блог А. А. Лебедева.
В пику: глядя на соки "Я персиковый", "Я ананасовый" с означенными фруктами на упаковке, так и видится сок "Йа креведковый" с соответствующим рисунком на упаковке.

---

Вот такая красотень

Скинули мне тут этот ролик... я прусь.

---

Бу. Вот вам.

13.09.2009 в 23:15

Пишет  redflower:

дракончики

12.09.2009 в 14:29

Пишет  Амун-Ра:

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

10.09.2009 в 17:12

Пишет  Cardis:

Очень понравились

10.09.2009 в 08:53

Пишет  Saharissa:

Dragons by *kerembeyit

---

Раннее субботнее утро... ищу для себя занятие...

---

Ааа! Зомбе отакуе!

Осторожно траф!

И вот вам еще с ютуба:

@настроение: ОМГ!

---

Не, мимо ТАКОГО пройти просто невозможно!

"Техника ведения боя с зомби". Осторожно МНОГОТРАФ!

(С)перто у Гевелла-сама

@настроение: ОМГ!

---

В общем...

В который раз уже мне вдалбливают в голову простую мысль: "Не торопи события, не торопись жить!" Когда я наконец научусь жить и требовать от себя соответственно текущему моменту, а не тому, что будет года через два - правда не знаю. Опять ловлю себя на том, что в этом вопросе я проявляю редкостное твердолобие.

Эхх... надо бы прекращать относиться к этому так ревностно и серьезно.

---

Вот!

11.09.2009 в 10:43

Пишет  SQR_Dragon:

угу!

10.09.2009 в 23:05

Пишет  Shalafi Dragon:

@темы: личное