Проект 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
    Re: Проект Visual Generator
    От: Аноним  
    Дата: 08.07.05 07:34
    Оценка:
    Здравствуйте, adontz, Вы писали:

    Айда, давайте замутим кодогенератор
    Re: Проект Visual Generator
    От: Antikrot  
    Дата: 08.07.05 08:01
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A> возможно (голубая мечта) формация команды, для работы над проектом

    Поменяй цвет , и я готов присоединиться к команде...

    A>--------------------------------

    A>Проект Visual Generator
    A>--------------------------------
    Написал бы, что будет основным назначением данного проекта... судя по названию, примочка для рисования гуев, или я не прав?

    A>Компилятор: Microsoft Visual C++ 7.1 (и 8.0 когда будет релиз)

    А чем вызвано данное ограничение? Или MSVS не позволяет больше добавлять к себе другие компиляторы?
    Re: Проект Visual Generator
    От: kirban Россия  
    Дата: 08.07.05 08:12
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>

      A>
    1. Возможность использовать конструкции языка Си, делающие код менее надёжным.
      A>
    2. Отсутствие поддерживаемых языком свойств и событий.
      A>
    3. Отсутствие стандартной библиотеки для создания пользовательского интерфейса.
      A>
    4. Отсутствие средств сериализации.
      A>
    5. Отсутствие метапрограммирования и их замена малопонятными и трудноотлаживаемыми конструкциями из шаблонов и макросов.
      A>
    6. Отсутсвие СОМ Interop
      A>

    А почему нельзя использовать управляемые расширения и платформу .NET? Все эти проблемы там решаются.
    Re[2]: Проект Visual Generator
    От: KHeLeKRoN Россия  
    Дата: 08.07.05 08:58
    Оценка:
    Здравствуйте, Antikrot, Вы писали:

    {}
    A>>Компилятор: Microsoft Visual C++ 7.1 (и 8.0 когда будет релиз)
    A>А чем вызвано данное ограничение? Или MSVS не позволяет больше добавлять к себе другие компиляторы?
    BTW а как их добавлять?
    And solder won't keep me together (c)
    Re[3]: Проект Visual Generator
    От: Antikrot  
    Дата: 08.07.05 09:27
    Оценка:
    Здравствуйте, KHeLeKRoN, Вы писали:

    KHL>BTW а как их добавлять?

    Через ж..у Примерно как icl это делает.
    Re[4]: Проект Visual Generator
    От: KHeLeKRoN Россия  
    Дата: 08.07.05 09:30
    Оценка:
    Здравствуйте, Antikrot, Вы писали:

    A>Здравствуйте, KHeLeKRoN, Вы писали:


    KHL>>BTW а как их добавлять?

    A>Через ж..у Примерно как icl это делает.
    Можно чуть подробнее? Че такое ICL?
    And solder won't keep me together (c)
    Re[5]: Проект Visual Generator
    От: Аноним  
    Дата: 08.07.05 09:43
    Оценка:
    Здравствуйте, KHeLeKRoN, Вы писали:

    KHL>Здравствуйте, Antikrot, Вы писали:


    A>>Здравствуйте, KHeLeKRoN, Вы писали:


    KHL>>>BTW а как их добавлять?

    A>>Через ж..у Примерно как icl это делает.
    KHL>Можно чуть подробнее? Че такое ICL?

    intel (?)
    Re[6]: Проект Visual Generator
    От: KHeLeKRoN Россия  
    Дата: 08.07.05 09:46
    Оценка:
    Здравствуйте, Аноним, Вы писали:

    А>Здравствуйте, KHeLeKRoN, Вы писали:


    KHL>>Здравствуйте, Antikrot, Вы писали:


    A>>>Здравствуйте, KHeLeKRoN, Вы писали:


    KHL>>>>BTW а как их добавлять?

    A>>>Через ж..у Примерно как icl это делает.
    KHL>>Можно чуть подробнее? Че такое ICL?

    А>intel (?)

    А как это делает ICL?
    And solder won't keep me together (c)
    Re[2]: Проект Visual Generator
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 08.07.05 10:25
    Оценка:
    Здравствуйте, Antikrot, Вы писали:

    A>>Компилятор: Microsoft Visual C++ 7.1 (и 8.0 когда будет релиз)

    A>А чем вызвано данное ограничение? Или MSVS не позволяет больше добавлять к себе другие компиляторы?

    Позволяет, но зачем писать свой компилятор, когда можно не писать?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[2]: Проект Visual Generator
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 08.07.05 10:26
    Оценка:
    Здравствуйте, kirban, Вы писали:

    K>А почему нельзя использовать управляемые расширения и платформу .NET? Все эти проблемы там решаются.


    Идея в отм, что как разе НЕ использовать .Net
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Проект Visual Generator
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 08.07.05 10:40
    Оценка:
    Здравствуйте, KHeLeKRoN, Вы писали:

    KHL>А как это делает ICL?


    Идём на www.vsipdev.com и скачиваем VSIP SDK
    Потом устанавливаем VSIP SDK и в проектах находим Others\Extensibility\Language Package
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re: Проект Visual Generator
    От: MaximE Великобритания  
    Дата: 08.07.05 10:53
    Оценка: 30 (1) +1 :)
    adontz wrote:

    > --------------------------------

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

    Шутник вы, однако, батенька ))

    --
    Maxim Yegorushkin
    Posted via RSDN NNTP Server 1.9
    Re[3]: Проект Visual Generator
    От: kirban Россия  
    Дата: 08.07.05 11:05
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Здравствуйте, kirban, Вы писали:


    K>>А почему нельзя использовать управляемые расширения и платформу .NET? Все эти проблемы там решаются.


    A>Идея в отм, что как разе НЕ использовать .Net


    То есть написать свой собственный? Я конечно понимаю что велосипедо-строитель сидит в каждом программисте , но мне кажется что все равно придется смотреть в сторону .NET. Уж больно активно microsoft его проталкивает, по крайней мере сейчас.

    PS: Вобще мне интересен этот проект, и могу помочь если надо по мере возможности/знаний
    PSPS: Я не являюсь фанатом .NET, я сторонник решать задачу с использованием тех технологий/языков, с которыми решение будет проще и быстрее
    Re[4]: Проект Visual Generator
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 08.07.05 11:19
    Оценка:
    Здравствуйте, kirban, Вы писали:

    A>>Идея в отм, что как разе НЕ использовать .Net

    K>То есть написать свой собственный?

    Нет. На самом деле .Net тоже не панацея. Та сериализация и та GUI библиотека о которых я думаю .Net даже и не снилась. А остальное единоразовая работа. Это GUI библиотеку можно улучшать, а свойства они либо есть либо нет

    K>PS: Вобще мне интересен этот проект, и могу помочь если надо по мере возможности/знаний

    K>PSPS: Я не являюсь фанатом .NET, я сторонник решать задачу с использованием тех технологий/языков, с которыми решение будет проще и быстрее

    Я сам сейчас пишу на C#, и у этого языка есть свои большие достоинства, но нет много такого что есть в Си++. Суть в том, что если поднатужится, то Си++ можно дотянуть до C#. Можно решать и обратную задачу, улучшать C#. Вот R#'пщики этим и заняты.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[2]: Проект Visual Generator
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 08.07.05 11:22
    Оценка: +1
    Здравствуйте, MaximE, Вы писали:

    ME>Шутник вы, однако, батенька ))


    Почему шутник? У меня уже есть работающая C++ Run-Time котора ятолько demangling не делает, а всё остальное делает.
    К тому же подумай сам какой кайф, если стандартные new/delete удут использовать скажем QuickHeap.

    Не прочувствовал ты, не прочувствовал...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[3]: Проект Visual Generator
    От: Antikrot  
    Дата: 08.07.05 11:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>>>Компилятор: Microsoft Visual C++ 7.1 (и 8.0 когда будет релиз)

    A>>А чем вызвано данное ограничение? Или MSVS не позволяет больше добавлять к себе другие компиляторы?
    A>Позволяет, но зачем писать свой компилятор, когда можно не писать?
    Не, компилятор я писать конечно не собираюсь
    Просто интересно, привязка к MSVS понятна — VS Add-in, но причем здесь привязка на компилятор? Или у тебя есть какие хитрые идеи, завязанные на ms extensions к с++?
    В любом случае, не откажусь поучаствовать в вело-гуи-строении , хоть к моей работе это никаким боком не относится.
    Re[3]: Проект Visual Generator
    От: Tom Россия http://www.RSDN.ru
    Дата: 08.07.05 11:58
    Оценка: :)
    A>Не прочувствовал ты, не прочувствовал...

    -Вас Гондурас не беспокоит?
    -Не чеши, и не будет беспокоить

    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    Народная мудрось
    всем все никому ничего(с).
    Re[4]: Проект Visual Generator
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 08.07.05 12:06
    Оценка:
    Здравствуйте, Antikrot, Вы писали:

    A>Не, компилятор я писать конечно не собираюсь

    A>Просто интересно, привязка к MSVS понятна — VS Add-in, но причем здесь привязка на компилятор? Или у тебя есть какие хитрые идеи, завязанные на ms extensions к с++?

    Просто кодогенератор должен откуда-то получать информацию. В VC++ это сделать очень просто. Есть куча информации и документрированное API для её получения.

    A>В любом случае, не откажусь поучаствовать в вело-гуи-строении , хоть к моей работе это никаким боком не относится.


    Эт хорошо
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[3]: Проект Visual Generator
    От: Cyberax Марс  
    Дата: 08.07.05 13:28
    Оценка: 11 (1)
    adontz wrote:

    > ME>Шутник вы, однако, батенька ))

    > Почему шутник? У меня уже есть работающая C++ Run-Time котора ятолько
    > demangling не делает, а всё остальное делает.
    > К тому же подумай сам какой кайф, если стандартные new/delete удут
    > использовать скажем QuickHeap.

    Ээээ... А в чем проблема? Я сейчас использую Hoard
    (http://www.hoard.org) — он прозрачно заменяет malloc/free и new/delete.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.