Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 09:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Зачем публиковать? Мой сериализатор может сериализовать приватные поля.

S>Дельфийский тоже. Для этого оставлен ровно такой же выход — можно перегрузить некий метод, и в нем сделать все, что захочется. Именно так сериализуются всякие штуки типа картинок, у которых нет публичных свойств, отвечающих за контент. Просто часть работы уже берет на себя компилятор.
Ага! Это получается в общем случае для каждого приватного поля (а в нормальных архитектурах все поля приватные) свой паблишед метод. Этож работы будет больше чем на С++ + тормоза...

WH>> Аналогично можно добавить сериализацию любого контейнера лаже не существовавшего в момент написания библиотеки.

S>Ну естественно. Ведь контейнер — это класс
Дельфевые контейнеры это отдельная песня заслужившая очень много мата.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Пример того как
От: WolfHound  
Дата: 11.09.03 09:24
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Ну, например, используя TCollection и TCollectionItem.

Ага! Через задницу.
A>Делаем свой итем, если не нужно бОльшей функциональности, а для примера — не нужно, то коллекцию не трогаем.
А если нужно?
A>
A>type
A>    TMyItem = class(TCollectionItem)
A>    ...
A>    end;
A>

Ага. Это каждай объект который я хочу хранить я коллекции должен быть наследником TCollectionItem
A>теперь создаём, и так далее...
Если мне не изменяет скалероз то так
A>
A>var
A>    C: TCollection;
A>    Item: TMyItem;
A>begin
A>    C := TCollection.Create(TMyItem);
A>    Item := C.Add as TMyItem; // Создаём и добавляем
A>    with Item do
A>    begin
A>        // Модифицируем
A>    end;
A>    C.Clear; // Удаляем с гарантией корректности
A>    for i := 0 to C.Count - 1 do
A>        with C.Items[i] as TMyItem do
A>        begin
A>            // Перебираем
A>        end;
A>

Те каждый раз происходит ДИНАМИЧЕСКОЕ привидение тапа

Дельфевые коллекции это пародии на коллекции. Тормозные не типизированые...
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 09:56
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Ага! Это получается в общем случае для каждого приватного поля (а в нормальных архитектурах все поля приватные) свой паблишед метод. Этож работы будет больше чем на С++ + тормоза...
Для этого сделан специальный способ замапить проперть прямо на поле, минуя метод. Да, это сделано из-за ограничений на автоinlining. В большинстве случаев плюсовый компилятор сам бы просек, что к чему, но у него есть возможность "видеть" исходный код этих методов.
WH>Дельфевые контейнеры это отдельная песня заслужившая очень много мата.
Я бы сказал — штука специфическая. С другой стороны, это проблемы VCL. Можно сделать их намного приятнее. Хотя для value-типов в общем случае это все приводит к Copy-Paste из-за отсутствия template. В общем, не будем о них. Хреновые там контейнеры.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 11:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Ага! Это получается в общем случае для каждого приватного поля (а в нормальных архитектурах все поля приватные) свой паблишед метод. Этож работы будет больше чем на С++ + тормоза...

S>Для этого сделан специальный способ замапить проперть прямо на поле, минуя метод.
S>Да, это сделано из-за ограничений на автоinlining. В большинстве случаев плюсовый компилятор сам бы просек, что к чему, но у него есть возможность "видеть" исходный код этих методов.

ЧДТ на реальных иерархиях от дельфевого сериализатора толу нет.(в смысле по сравнению в плюсовым не дает преймуществ)
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 11:14
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>ЧДТ на реальных иерархиях от дельфевого сериализатора толу нет.(в смысле по сравнению в плюсовым не дает преймуществ)

Э-э, парень. Вот тут ты не прав. Сериализатор чего угодно в XML на дельфи пишется за один день. При этом ни строчки пользовательского кода править не надо. Преимущество — скорость разработки. Код, который ты привел, научить сериализовать в XML невозможно (в хуман-ридабле, ессно. в СDATA, ясен хрен, ты запихаешь и не такое
А сейчас, увы, рулит Time To Market.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 11:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>ЧДТ на реальных иерархиях от дельфевого сериализатора толу нет.(в смысле по сравнению в плюсовым не дает преймуществ)

S>Э-э, парень. Вот тут ты не прав. Сериализатор чего угодно в XML на дельфи пишется за один день. При этом ни строчки пользовательского кода править не надо. Преимущество — скорость разработки. Код, который ты привел, научить сериализовать в XML невозможно (в хуман-ридабле, ессно. в СDATA, ясен хрен, ты запихаешь и не такое
S>А сейчас, увы, рулит Time To Market.
struct some_type
{
    std::string name;
    std::vector<std::string> vec_str;
    std::vector<int> vec_int;
    std::vector<std::vector<std::string> > vec_vec_str;
    XML_SERIALIZE()
    {
        serializer
        .version(1)
            serialize(name)
            serialize(vec_str)
        .version(2)
            serialize(vec_int)
            serialize(vec_vec_str)
        ;
    }
};

Это хуман ридебел? Если да то за день легко.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 11:34
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>
WH>struct some_type
WH>{
WH>    std::string name;
WH>    std::vector<std::string> vec_str;
WH>    std::vector<int> vec_int;
WH>    std::vector<std::vector<std::string> > vec_vec_str;
WH>    XML_SERIALIZE(some_type)
WH>    {
WH>        serializer
WH>        .version(1)
WH>            serialize(name)
WH>            serialize(vec_str)
WH>        .version(2)
WH>            serialize(vec_int)
WH>            serialize(vec_vec_str)
WH>        ;
WH>    }
WH>};
WH>

WH>Это хуман ридебел? Если да то за день легко.
И получаем что-то типа
<some_type>
    <string name="name">
        asdasd
    </string>
    <vector name="vec_str">
        <string>
            asdasd
        </string>
        <string>
            asdasd
        </string>
    </vector>
    <vector name="vec_int">
        <int val=123/>
        <int val=123/>
        <int val=123/>
    </vector>
    <vector name="vec_vec_str">
        <vector>
            <string>
                asdasd
            </string>
            <string>
                asdasd
            </string>
            <string>
                asdasd
            </string>
        </vector>
        <vector>
            <string>
                asdasd
            </string>
            <string>
                asdasd
            </string>
        </vector>
    </vector>
</some_type>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 12:42
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>если верить фирме борланд, то начиная с 7 версии делфи — это язык ...


Это раньше на неё молиться можно было, а сейчас... Не верим мы ей. После того, как она шкуру сменить на Инпри-изе (произносится с чувством, с которым произносится пИ-Иво братьями из-за границы за окном в одноимённом анекдоте) пыталась, мы осторожничаем.

Всё это маркетинговые ходы менеджеров...
... << RSDN@Home 1.1 beta 3 >>
Идём дальше
От: akasoft Россия  
Дата: 11.09.03 12:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

Ну, хорошо. Три вопроса...

Скажи, практика использования инструмента "Дельфи" у тебя большая?

А оная, связанная с "C++"?

С чем из этих двух ты познакомился раньше?

Очень хочется тебя поближе (произносится, как Каа обезьянам третий раз) узнать, потому и спрашиваю. Не для стёба.

A>Ну, например, используя TCollection и TCollectionItem.

WH>Ага! Через задницу.

Для меня это естественно (Естественно, что естественно не "...Через задницу", а использовать TCollection и TCollectionItem). Более того, наглядно понятно. ООП. А запись шаблона смотрится, как на китайском языке. Но это потому, что я с ними не знаком, не пользовал ещё в практике...

A>>Делаем свой итем, если не нужно бОльшей функциональности, а для примера — не нужно, то коллекцию не трогаем.

WH>А если нужно?

Наследуем и добавляем функционал.

WH>Ага. Это каждай объект который я хочу хранить в коллекции должен быть наследником TCollectionItem ...


Ну да. Ты, похоже иерархию не прочувствовал. Всё наследуется от одной базы. Не нравится что? То, что это именно Коллекция, заточенная под ИДЕ? Так нет проблем, по аналогии клепаем свой базовый класс итемов и коллекций, и работаем. Это же 2 мин копи-пастом, где 1,5 мин. марафет наводить и комментарии писать. Чем это хуже? Копи-паст сакс — не аргумент никакой.

Или не нравится, что от одной базы? Ну так, меняем инструмент... Или осваиваем, проникаемся, и понятия "нравится-не нравится, люблю-не навижу" уходят на восьмой план... Появляется "пофигу"...

WH>Те каждый раз происходит ДИНАМИЧЕСКОЕ привидение тапа ...


Не нравится, значит, как я код изложил. Так моей целью была не оптимизация, а демонстрация. Давай так.

Посмотрим-ка, что нам окошечко CPU да и выдаст...

На

    Item := Add as TMyItem; // Создаём и добавляем


mov    eax, [ebp-$0c]
call    TCollection.Add
mov    edx, [$00467204]
call    @AsClass
mov    [ebp-$08], eax


а вот на

    Item := TMyItem(Add); // Создаём и добавляем


уже

mov    eax, [ebp-$0c]
call    TCollection.Add
mov    [ebp-$08], eax


Второй способ использования насчитывает больше лет практики, когда is и as не было.

Я уже не говорю о разработке собственной пары классов, заточенной под мои нужды. Один раз разрабатываю, много раз юзаю. Шаблоны кто-то тоже разрабатывал. Не 10 сек.

WH>Дельфевые коллекции это пародии на коллекции...


Опять же, почему? Это инструмент для работы в Инспекторе. Я, объявив published свойство (или поле) в классе, без никаких доп. затрат получаю возможность редактировать его в дизайн-тайме. Цель, которая ставилась перед инструментом, достигнута.

WH>... Тормозные не типизированые...


И в чём тормоза, см. код на асме выше. Не типизированность отметаем, мы объявляли

var
    Item: TXItem;
    C: TCollection;


типы указаны.
... << RSDN@Home 1.1 beta 3 >>
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 11.09.03 13:17
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Сразу некоторые ответы на вопросы, возникшие в этом
Автор: DOOM
Дата: 26.08.03
топике.


DOO>Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:

DOO>TAbstractClass = class ....
DOO>TClass1 = class(TAbstractClass)...
DOO>TClass2 = class(TAbstractClass)...
DOO>Я хочу создать массив, в котором будут и TClass1 и TClass2 — понятно, что надо создать массив TAbstractClass. В С это можно решить только используя указатели на класс, а в Дельфи есть только указатели на класс, просто это все неявно. И при их организации ООП это единственный способ. Поэтому-то мне и интересно как это сделано в С. К сожалению сейчас у меня нет времени покопаться в VS-ке и погладет как на asm'е все это выглядит.

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++. Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).



DOO>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.


DOO>По поводу библиотек — MFC vs VCL. VCL — действительно объектная библиотека, в которой обработка событий инкапсулированна в объект, а не реализуется посредством вставляемых куда-то макросов и т.п.


DOO>Теперь ваща очередь...


помоему вы равняете вещи котрые сравнивать не надо...
1. Делфи без своей библиотеки VCL как язык вообще не рассматриваеться!
2. если и говорить то о Паскале и С++... а сравниваться смешно... потому как просто языки под разные темы заточенны! С++ — алгоритмистика, память, скорость, близость к машинному уровню
Delphi — абстракция, начальная алгоритмистика.

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

с++ — вглубь
Delphi — вширь
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 16:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

Круто, если это и вправду возможно. А как это будет работать? Откуда сериализатор возьмет имена для тэгов?
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 18:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Круто, если это и вправду возможно. А как это будет работать? Откуда сериализатор возьмет имена для тэгов?

Имена типов добавим в
template<class Type, class Allocator>
struct serialize_save_load<std::vector<Type, Allocator> >
{
        typedef std::vector<Type, Allocator>    container;
        typedef typename container::size_type    size_type;
        template<class T>
        static void save(T& st, const container& cont)
        {
...
        }
        template<class T>
        static void load(T& st, container& cont)
        {
...
        }
        //Что-то вроде
        static const char* get_type_name()
        {
            return "vector";
        }
};

А имена полей можно получить используя препроцессор
#define serialize(name).record(#name, name)

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

Примерно так. Мне сейчас не до того. Потом возможно сделаю.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 18:58
Оценка:
Здравствуйте, AlexK, Вы писали:

Сразу оговорюсь, что считаю, что есть только язык OP, а Дельфи — это одно из его воплощений.

AK>1. Делфи без своей библиотеки VCL как язык вообще не рассматриваеться!


OP существует независимо от VCL. Что мы теряем, убирая VCL? Быструю визуальную разработку? Ну и шут с ней. Зачем нам не нужна VCL? Большая и не поворотливая, куча лишнего функционала?.. Замечательно. Берём за основу Class TObject и пишем свою иерархию, свою реализацию, всё своё. А-а-а, не хватает визуальности. Тогда разбираемся и пишем эксперта, который будет помогать нам с помощью драг-энд-дропа двигать мышкой уже наши классы.

Пример: KOL. Не так уж это и трудно. Был бы смысл, и можно сделать RSDNL...

AK>... потому как просто языки под разные темы заточенны!


Истинно так! У каждого своя ниша.

AK>Delphi — абстракция, начальная алгоритмистика.


+ близость к человеческой (английской) речи, та же алгоритмистика, прикладные программы...

AK>... язык придумал только для обучения студентов.


Вот, кстати, интересно, как так получилось, что Борланд его подхватил и довёл до сегодняшнего состояния?..
Чего он его подхватил, тянул бы лямку C/++, как все...
... << RSDN@Home 1.1 beta 3 >>
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 11.09.03 19:35
Оценка: :)
Здравствуйте, AlexK, Вы писали:
автор Паскаля сказал что свой язык придумал только для обучения студентов.

Однако на паскале писали популярные операционные системы...
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 12.09.03 06:25
Оценка:
Здравствуйте, AndrewJD, Вы писали:

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

AJD> автор Паскаля сказал что свой язык придумал только для обучения студентов.

AJD>Однако на паскале писали популярные операционные системы...


честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 06:58
Оценка:
Здравствуйте, AlexK, Вы писали:

AJD>>Однако на паскале писали популярные операционные системы...

AK>честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?
Он наверно про ту байку что винду начинали писать на паскале.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Идём дальше
От: WolfHound  
Дата: 12.09.03 07:33
Оценка: 6 (1)
Здравствуйте, akasoft, Вы писали:

A>Скажи, практика использования инструмента "Дельфи" у тебя большая?

Больше года
A>А оная, связанная с "C++"?
Гда четыре
A>С чем из этих двух ты познакомился раньше?
С дельфей, а еще раньше с турбо паскакалем

A>Для меня это естественно (Естественно, что естественно не "...Через задницу", а использовать TCollection и TCollectionItem). Более того, наглядно понятно. ООП. А запись шаблона смотрится, как на китайском языке. Но это потому, что я с ними не знаком, не пользовал ещё в практике...

В программах на С++ классы делятся на
1)Помошники(как правило шаблоны)
Делают всю грязную работу типа захват/освобождение ресурса причем полностью автоматически
В подовляющем большинстве на дельфе не реализуемы
2)Синглетоны
3)Логика(самые многочисленые)
Их специфика такова что их объекта путешествуют из функции в функцию, хранятся в коллекциях а то и в нескольких.
И что их всех теперь наследовать от TCollectionItem? И как реализовать хранение в нескольких коллекциях одного объекта?
Я делаю посто встроеный рефкаунтинг и дальше смартпоинтеры ведут объект пока он нужен. Причем все строго типизировано.
delete в программе на С++ это дурной тон.

WH>>Ага. Это каждай объект который я хочу хранить в коллекции должен быть наследником TCollectionItem ...

A>Ну да. Ты, похоже иерархию не прочувствовал. Всё наследуется от одной базы. Не нравится что? То, что это именно Коллекция, заточенная под ИДЕ? Так нет проблем, по аналогии клепаем свой базовый класс итемов и коллекций, и работаем. Это же 2 мин копи-пастом, где 1,5 мин. марафет наводить и комментарии писать. Чем это хуже? Копи-паст сакс — не аргумент никакой.
Да все я прочувствовал. И что КАЖДЫЙ объект должен тащить кучу ЛИШНЕЙ функциональности и то что хоть ты тресни но коллекция одна(в С++ есть std::map, std::set, set::list. std::vector, std::deque,... и все строго типизированые) причем полиморфная...

A>Не нравится, значит, как я код изложил. Так моей целью была не оптимизация, а демонстрация. Давай так.

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

A>Я уже не говорю о разработке собственной пары классов, заточенной под мои нужды. Один раз разрабатываю, много раз юзаю. Шаблоны кто-то тоже разрабатывал. Не 10 сек.

Вот только шаблоны приходиться писать много реже и пользовать много дольше.

WH>>Дельфевые коллекции это пародии на коллекции...

A>Опять же, почему? Это инструмент для работы в Инспекторе. Я, объявив published свойство (или поле) в классе, без никаких доп. затрат получаю возможность редактировать его в дизайн-тайме. Цель, которая ставилась перед инструментом, достигнута.
Возвращают TCollectionItem который надо приводить к типу коллекции, не могут хранить объекта разных типов, не могут просто добавить в себя рание созданный объект(только копированием)....

WH>>... Тормозные не типизированые...

A>И в чём тормоза, см. код на асме выше. Не типизированность отметаем, мы объявляли
A>типы указаны.

A>var
A>    C: TCollection;
A>    Item: TMyItem;
A>begin
A>    C := TCollection.Create(TMyItem);

А если в выделеных строчьках не совпадут типы тогда что? И мы не использовали as, is то мы получим не понятные глюки в рантайме
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.03 09:25
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


S>> Но если я захотел изменить (добавить) функциональность для конкрентого типа, которая для других типов не нужна ????? Есть в шаблонах наследование ???


ГВ>Есть, конечно. Надо — пользуйся. Есть и наследование и более экономный механизм — специализация. Конкретную специализацию можно и допилить, если не устраивает обобщённый вариант. Нередко это закладывается ещё при проектировании шаблона.


ГВ>Ну, например:


ГВ>

ГВ>template<typename T>
ГВ>class X
ГВ>{
ГВ>    T m_t;
ГВ>  // ...
ГВ>  public:
ГВ>    void some_operation();
ГВ>};


ГВ>// Это - общая структура операции для всех типов-аргументов T
ГВ>template<typename T>
ГВ>void X<T>::some_operation() { m_t = m_t * 2; }

ГВ>// Теперь сделаем специализацию для some_operation()
ГВ>// для некоего отдельного типа, например int
ГВ>template<>
ГВ>void X<int>::some_operation() { m_t = m_t / 2; }

ГВ>// Всё, теперь для такого экземпляра:
X<int>> x1;
ГВ>// ... в вызове some_operation(), m_t будет делиться на 2, а для таких:

ГВ>X<float> xf; X<double> xd;
ГВ>// m_t будет умножаться на 2

ГВ>


S>> Объясню подробнее. Есть база 1С. На основании метаданных можно построить объекты для прямого доступа к файлам опирающихся на несколько связанных таблиц от базового объекта. Решение через формирование исходников есть http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019.

S>> Как такую проблему можно решить через шаблоны????

ГВ>Можно и исходники сгенерировать, только их скомпилить потом отдельно нужно.


ГВ>Хотя, конечно, можно и не генерировать исходников, а просто воспользоваться чтением описания БД и компоновкой предварительно скомпилированных объектов, обрабатывающих доступ к отдельным полям.


Можно но при этом есть потеря в скорости, т.к. доступ к полю записи нужно стоить через посредника а не напрмую по известеому смещению и типе поля еще на этапе компиляции, да и при загрузке таблици нужно выделять память под посредников. Скорость при это может падать аж в 4 раза. Здесь либо скорость, либо гибкость. Да и если посмотреть на то как в Net генерятся типизированные Table и Bold Soft тоже генерят исходники из схемы базы.

ГВ>Шаблоны могут помочь здесь тем, что позволят или сильно сократить объём генерируемого кода или вообще отказаться от какой-либо генерации дополнительным средством, ограничившись почти что одним только перечислением имён полей и их типов непосредственно в программе на C++, особенно, если воспользоваться ещё и препроцессором... сахара ради...


ГВ>Проблема в другом, в том, что нужно ещё знать: кто и как результатами генерации будет пользоваться. Иначе зачем со всем этим возиться?


ГВ>А потому лучше решать задачу с противоположной стороны. Не "от файлов", а "от программы". Не файлы, а вернее — внешние хранилища данных определяют структуру классов, а структура классов определяет наиболее приемлемые способы их хранения.



ГВ>Поясню подход подробнее. Есть задача. Есть её объектная декомпозиция, сделанная исходя из требований задачи и квалификации проектировщика. Есть некое хранилище, к которому, возможно, надо адаптироваться. Или десяток разных хранилищ, к которым тоже надо адаптироваться. Исходя из декомпозиции строим адаптеры к той или иной БД. Всё!


Так и поступаю. По ссылочке http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019 там есть простенькое Иерархическое хранилище где пляс идет от "программы".

S>> Это не "Понты" а практический вопрос, т.к. по понятной причине не имею с ними практики. Заранее благодарен за ответ.


ГВ>Ну, если помог, то — пожалуйста.


Спасибо. Но перехожу на Net (C#) пока там шаблонов нет, но будут и как появятся буду обязательно использовать.
Но с другой стороны есть возможность генерации и компиляции объектов на лету. Понятно, что шаблоны вещь мощная и не понятно почему они не внедряются в другие языки (не вижу особых проблем, как Inline и смартпоинтеры). Посмотрим, что выдаст Борланд в конце года.
и солнце б утром не вставало, когда бы не было меня
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.03 09:42
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Короче извращаться с нетипизированой памятью можно и на асме для этого не нужен ЯВУ, а дельфя именно на это звание претендует.


Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них. По поводу нетипизированой памяти то не вижу в этом криминала особенно при написании универсальных классов (функций) которые оперируют только размером записи, и писать шаблон нет никакого смысла.
С другой стороны не вижу абсолютно никакого смысла на данном этапе сравнивать умирающие технологии.
Лучше смотреть на Net, особенно когда огромный набор процессоров в том числе и 64 разрядных.
А все лучшие идеи должны использоваться в новых технологиях, в том числе и поизвращаться с нетипизированой памятью и там придется, но с большими трудностями.
и солнце б утром не вставало, когда бы не было меня
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 12.09.03 09:54
Оценка:
Здравствуйте, AlexK, Вы писали:


AK>честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?


MAC OS. Ранние версии были вообще полностю на паскале. Для версий 8.х-9.х конечно много кода написано на С, но API остался паскалевский.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.