Проект Visual Generator
От: adontz Грузия http://adontz.wordpress.com/
Дата: 07.07.05 19:26
Оценка: 51 (6) -1 :))) :)))
Просьба модератору и любителям автомодерирования НЕ переносить данное сообщение по крайней мере какое-то время (пара дней), чтобы его увидело максимальное количество народа.

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

--------------------------------
Проект Visual Generator
--------------------------------

--------------------------------
Ограничения
--------------------------------
Язык: Си++
Компилятор: Microsoft Visual C++ 7.1 (и 8.0 когда будет релиз)
Среда разработки: Microsoft Visual Studio

Если это вам не подходит, смело ставьте мне минус и не читайте дальше. Хотя нет, минус лучше не ставьте

--------------------------------
Введение
--------------------------------
Итак, что это и зачем нужно? Начну издалека.
Последнее время слышно всё больше упрёков в адрес Си++ со стороны людей использующих другие языки программирования. Несмотря на то, что некоторые упрёки можно смело проигнорировать, есть такие, которые заставляются задуматься. Вот всё то, что заставило задуматься меня
  1. Возможность использовать конструкции языка Си, делающие код менее надёжным.
  2. Отсутствие поддерживаемых языком свойств и событий.
  3. Отсутствие стандартной библиотеки для создания пользовательского интерфейса.
  4. Отсутствие средств сериализации.
  5. Отсутствие метапрограммирования и их замена малопонятными и трудноотлаживаемыми конструкциями из шаблонов и макросов.
  6. Отсутсвие СОМ Interop
Практически любой программист на Си++ скажет на всё это – “ну и что”? Как избавиться от наследия Си или добавить метапрограммирование? Это ведь значит менять язык…
Не всё так безнадёжно. У любой проблемы есть решения…

--------------------------------
Некоторые факты
--------------------------------
  • Для нормальной работы Си++ кода достаточно поддерживать механизм обработки исключений, RTTI и операторы new/delete.
  • Любой компилятор Microsoft (даже компиляторы управляемых языков), в том числе и Си++ компилятор, при компиляции создаёт PDB (Program DataBase) файл. В этом файле есть помимо прочего вся информация обо всех использовавшихся типах.
  • IDE Visual Studio предоставляет много информации об иерархии классов в отдельно взятом файле ещё до компиляции.
  • Можно использовать кодогенератор для обработки информации полученной из PDB файла и от VS IDE.

    --------------------------------
    Решение проблемы №1
    --------------------------------
    Решение простое как топор . Просто надо избавится от CRT. Никто конечно не сможет запретить писать процедурно, но malloc и fopen умрут как категория. По большому счёту разве они ещё кому-то нужны? Реализовать же CRT полностью поддерживающую Си++ код не составляет большой проблемы. Фактически единственная не решённая пока мною задача это symbol demangling (undecoration), но и то больше от нехватки времени, чем из-за объективных проблем. Более того, хотелось бы перекрыть и прямой доступ к WinAPI и вообще к любому C-API. Это работа скорее объёмная, чем сложная. Да и не так страшен чёрт как его малюют. Современные заголовочные файлы Windows Platform SDK минимум на треть состоят из уже устаревших описаний.

    --------------------------------
    Решение проблемы №2
    --------------------------------
    Давайте рассмотрим одну из популярных реализаций свойств
    class propABC_type
    {
    public:
        parent_type * _parent()
        {
            return (parent_type *)(((long)this) - ((long)&((( parent_type *)0)->propABC)));
        }
    
        template <typename _type_value>
        propABC_type & operator = (_type_value _value)
        {
            _parent()->propABC_put(_value);
            return *this;
        }
        operator prop_type()
        {
            return _parent()->propABC_get();
        }
    } propABC;

    Данный класс, часто оформляют в ввиде макроса.
    #define PROPERTY(PARENT_CLASS, PROPERTY_NAME, PROPERTY_TYPE, FUNCTION_GET, FUNCTION_PUT) \
    class PROPERTY_NAME##_type \
    { \
    public: \
        PARENT_CLASS * _parent() \
        { \
            return (PARENT_CLASS *)(((long)this) - ((long)&(((PARENT_CLASS *)0)->PROPERTY_NAME))); \
        } \
    
        template <typename _type_value> \
        PROPERTY_NAME##_type & operator = (_type_value dataInit) \
        { \
            _parent()->FUNCTION_PUT(dataInit); \
            return *this; \
        } \
        operator PROPERTY_TYPE() \
        {
            return _parent()->FUNCTION_GET(); \
        } \
    } PROPERTY_NAME;

    Он создаёт нечто, что ведёт себя как свойство с именем PROPERTY_NAME и типом PROPERTY_TYPE. Однако у него и всех ему подобных классов есть серьёзные недостатки:
    1. Описание и функциональность свойства размазаны по классу и двум функциям.
    2. Синтаксис не удобный и не понятный. Описывая своство надо указать класс-контейнер.
    Что же делать? По идее такой синтаксис
    property(int, my_prop)
    {
        get
        {
            return _internal_variable;
        }
    
        set
        {
            _internal_variable = value;
        }
    }

    хотя конечно и не идеален, но гораздо предпочительнее. Но указанных данных компилятору просто мало чтобы создать работоспособный код. Компилятору да, а нам? С помошью кодогенератора использование такого (или подобного) синтаксиса может стать реальностью.
    Аналогично и события можно реализовать удобно и эффективно.
    --------------------------------
    Решение проблемы №3
    --------------------------------
    Имея механизм событий и свойств можно реализовать очень прозрачную GUI библиотеку. А кодогенераторы позволят избавится от явной подписки на события
    Например так
    class MyWindow : public Window
    {
        bool OnMove(const message<MOVE> & msg)
        {
            return false;
        }
    }

    Код подписки OnMove на сообщение MOVE будет сгенерирован автоматически. Кроме того есть идея создания библиотеки элементов управления с расширяемых извне наподобие Office CommandBars.

    --------------------------------
    Решение проблемы №4
    --------------------------------
    Что нужно чтобы сериализовать структуру A с помошью кодогенератора?
    Нужно написать
    struct A
    {
    serializable;
    int x;
    int y;
    }
    собственно всё Особенности записи данной структуры в файл можно настраивать и в design time, хотя стандартные схемы скорее всего будут устраивать в 99% случаев.

    --------------------------------
    Решение проблемы №5
    --------------------------------
    Я уже говорил про кодогенераторы?

    --------------------------------
    Решение проблемы №6
    --------------------------------
    Именно Interop а не Support.
    Итак, что надо? Проблем как таковых две. Во-первых, неудобно использовать IDispatch. Invoke это не очень удобно. Во-вторых, написание СОМ серверов всегда жёстко завязано на аттрибуты ATL или мучительно из-за необходимости использования IDL. Что же делать?
    Я думаю ничто не мешает генерировать класс-обёртку (на лету или по запросу) для dispatch_ptr<IInterface>.
    Что касается создания СОМ серверов тут тут всегда было два камня перткновения. Реализация методов AddRef/Release для коклассов и DllGetClassObject (да и самого class object). И та и другая проблема с лёгкостью решаются кодогенератором.

    --------------------------------
    Как всё это будет выглядеть
    --------------------------------
    Всё это будет выглядеть как Visual Studio Add-in, который по ходу дела будет сам генерировать и добавлять в проект нужные файлы.

    --------------------------------
    Если вы дочитали до конца
    --------------------------------
    И хотите послать меня в boost, etc то остановитесь и подумайте — я заранее понимал что эти идеи не могли понравится всем подряд. Если вы хотите покритиковать по мелочи, то помните что это всего лишь идея, а не продукт который я вам пытаюсь продать. Стоит ли цеплятся? Хотите упрекнуть меня в том что я привязываю межплатформенный язык Си++ к далеко не самому хорошему компилятору? Это мой выбор, тут уж ничего не поделать.Переубеждать меня бессмысленно

    Но если вы разделяете мои взгляды, если у вас тоже есть какое-то наработки которыми вы хотите поделится, то добро пожаловать.

    11.07.05 23:26: Перенесено модератором из 'C/C++' — Павел Кузнецов
  • A journey of a thousand miles must begin with a single step © Lau Tsu
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.