Здравствуйте, Cyberax, Вы писали:
C>adontz wrote:
>> C>Ээээ... А в чем проблема? Я сейчас использую Hoard >> C>(http://www.hoard.org) — он прозрачно заменяет malloc/free и new/delete. >> Нет, я не говорю, что это в принципе невозможно. Я говорю о другом >> вместо того чтобы скачивать и настраивать десяток-другой расширений >> C++, не лучше ли сделать C++ Run-Time которая будет всё это >> поддерживать и ещё много чего другого.
C>90% того, что мне надо — есть в boost. Остальное давно скачано.
C>Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е вам C>все равно не получится. А привязка к компилятору — вообще убивает весь C>смысл затеи. Использовали тогда бы уж лучше GCCXML.
Отучаемся говорить за других.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, c-smile, Вы писали:
CS>>Также оказалаcь полезной "фича" MSPACES в аллокаторе Doug Lea
SDB>А скажи мне, брат Smile — в MFC-шных приложениях она будет так же "полезна"?
Скажу тебе брат Schwein как на духу — хрен его знает.
В моем случае мне нужно было локализовать аллокации пассивных
объектов DOMa (struct) внутри одной сущности — некоего document.
И чтобы потом не заморачиваться с удалением оных я удалял весь
memory pool скопом. Писался крутой Word Processor. К тому же фрагментация
памяти и все такое.
На конкретных задачах можно получить выигрыш, иногда немалый.
Короче, memory allocators штука индивидуальная. В Harmonia
например весь HTML DOM аллоцируется в одном массиве путем дописывания
в конец. Такой вот аллокатор для бедных. Там это можно так как
динамическое изменение сценарием пока не предусмотретно.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, Cyberax, Вы писали:
C>>adontz wrote:
>>> C>Ээээ... А в чем проблема? Я сейчас использую Hoard >>> C>(http://www.hoard.org) — он прозрачно заменяет malloc/free и new/delete. >>> Нет, я не говорю, что это в принципе невозможно. Я говорю о другом >>> вместо того чтобы скачивать и настраивать десяток-другой расширений >>> C++, не лучше ли сделать C++ Run-Time которая будет всё это >>> поддерживать и ещё много чего другого.
C>>90% того, что мне надо — есть в boost. Остальное давно скачано.
C>>Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е вам C>>все равно не получится. А привязка к компилятору — вообще убивает весь C>>смысл затеи. Использовали тогда бы уж лучше GCCXML.
Ш>Отучаемся говорить за других.
Так их, дядько Шахтер.
Еще можно говорить "убей в себе раба!"
Здравствуйте, Cyberax, Вы писали:
C>eao197 wrote:
>> C>Угу, обожаю лэйауты! Я на Swing'е в Java пишу код с лэйаутами для >> C>интерфейса _быстрее_, чем дельфисты кидают контролы на формочки >> C>(сравнивали). >> Не, имхо, в Qt, особенно в паре с Qt Designer, layout-ы удобнее будут. >> Хотя Swing-овых я уже года четыре как не брал в руки
C>Жаль что у Qt лицензия — GPL, иначе бы использовал его во всех проектах. C>Коммерческие лицензии больно уж дорогие у них.
Угу.
А на 4.0 еще дороже.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Cyberax, Вы писали:
C>>К сожалению, так пока и не нашел нормальной С++ной GUIшной либы, которая C>>имела бы такие же возможности. QT почти все нужное умеет, но все же C>>чуть-чуть не дотягивает.
A>Так может поможешь писать GUI библиотеку, а не будешь всё хаять ?
Вот здесь: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
перечисленна масса OpenSource GUI библиотек (есть даже специально под Windows заточенные). Почему бы тебе, вместо создания еще одной, не присоединится к разработке одной из них. Вот у FLTK никак релиз второй версии не выйдет, почему бы не помочь?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, adontz, Вы писали:
A>>>Я могу прямо сейчас дать тебе полностью работающую С++ Run-Time написанную с нуля (ну за исключением memmove и тому подобных вещей). Кроме того я практически полностью (за исключением некоторых классов-политик) реализовал строковый класс поддерживающий Unicode 4.1.
E>>А с какими стандартами она соотносится?
A>Кто? Run-Time? На реализацию Run-Time нет стандарта. Есть стандарт на некоторый набор функциональности который должен поддерживаться. Я из него выкинул всё, что касается Си.
Т.е. написанные для ANSI C и ANSI C++ программы, использующие strlen, strcat, memmove, memcpy и иже с ними, тихоничко идут лесом?
А оно нам надо? Если я перестану заботится об уже написанном мной C/C++ коде, то мне проще будет уйти в Java/C#, а лучше в Smalltalk/Python/Ruby, чем на доморощенный, урезанный, привязанный к VC диалект C++.
A> Остались new/delete, RTTI, exceptions. В RTTI не доделан type_info::name() потому что способ декорирования имён компилятором VC нигде не документирован, хотя и есть пара статей с изысканиями + исходники WINE, которые впрочем тоже не полностью реализуют задачу. Но немного поработав над этим вопросом я пришёл к выводу, что задача вполне разрешима — бывали и посложнее.
Например?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ну, во-первых, там нет предожений о том, как будет организованна сериализация/десериализации.
И, во-вторых, можешь нарисовать картинку, как должен выглядеть FormatDesigner для случая 40-ка полей и 17-ти версий?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Т.е. написанные для ANSI C и ANSI C++ программы, использующие strlen, strcat, memmove, memcpy и иже с ними, тихоничко идут лесом? E>А оно нам надо? Если я перестану заботится об уже написанном мной C/C++ коде, то мне проще будет уйти в Java/C#, а лучше в Smalltalk/Python/Ruby, чем на доморощенный, урезанный, привязанный к VC диалект C++.
Нет, почему, их можно прилинковать. Ты же не используешь исходники Borland C++ Builder пропахшие VCL в VC++ напрямую, но можешь создать DLL'ку. Здесь тоже самое, только ситуация немного лучше. Можно прилинковывать не только DLL, но и LIB файлы, потому что компилятор фактически один. Старый код выкидывать не объязательно.
A>> Остались new/delete, RTTI, exceptions. В RTTI не доделан type_info::name() потому что способ декорирования имён компилятором VC нигде не документирован, хотя и есть пара статей с изысканиями + исходники WINE, которые впрочем тоже не полностью реализуют задачу. Но немного поработав над этим вопросом я пришёл к выводу, что задача вполне разрешима — бывали и посложнее.
E>Например?
Например реализовать поддержку Си++/SEH исключений оказалось очень сложно, фактически задача свелась с дизассемблированию и разбору ассемблерного кода и нагенерированных компилятором структур данных, не все поля которых как выяснилось используются. Фактически в Интернете не оказалось ни одного нормального описания как это всё работает, знаменитая статья на codeproject полная лажа, а статья Matt Pietrek больше касалась SEH. Правда я на этой задаче получил большой опыт. Честно говоря мне в какой-то момент казалось, что я вообще никогда не закончу. 2 раза всё бросал и начинал заново, но в конце концов добил. Система потом тестировалась на множестве разных случаев и ведёт себя в точности как родная.
Здравствуйте, eao197, Вы писали:
E>Вот здесь: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html E>перечисленна масса OpenSource GUI библиотек (есть даже специально под Windows заточенные). Почему бы тебе, вместо создания еще одной, не присоединится к разработке одной из них. Вот у FLTK никак релиз второй версии не выйдет, почему бы не помочь?
У меня есть идеи, которые не реализовать без кодогенерации. Например не нужны message maps или event subscribing.
Вместо кода вида
class Window : public WindowBase
{
public:
void OnSize(SIZE sizeOld, SIZE sizeNew);
}
BEGIN_MESSAGE_MAP(Window)
ON_MESSAGE(SIZE, OnSize)
END_MESSAGE_MAP
Будет
class Window : public WindowBase
{
public:
void OnSize(const message_data<SIZE> & msgdata);
}
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, eao197, Вы писали:
E>>Вот здесь: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html E>>перечисленна масса OpenSource GUI библиотек (есть даже специально под Windows заточенные). Почему бы тебе, вместо создания еще одной, не присоединится к разработке одной из них. Вот у FLTK никак релиз второй версии не выйдет, почему бы не помочь?
A>Будет A>
A>class Window : public WindowBase
A>{
A> public:
A> void OnSize(const message_data<SIZE> & msgdata);
A>}
A>
A>Такое без генератора просто не возможно.
Пока вопрос генератора оставим в стороне. Что для данного случая будет в message_data<SIZE>?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, eao197, Вы писали:
E>>Вот здесь: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html E>>перечисленна масса OpenSource GUI библиотек (есть даже специально под Windows заточенные). Почему бы тебе, вместо создания еще одной, не присоединится к разработке одной из них. Вот у FLTK никак релиз второй версии не выйдет, почему бы не помочь?
A>У меня есть идеи, которые не реализовать без кодогенерации. Например не нужны message maps или event subscribing.
Ну хорошо, сделаешь ты возможность указывать обработчики сообщений без message maps (кстати в той же Qt он уже есть). Ну а дальше что? В написании GUI прописывание message maps (event subscribing) занимает совершенно мизерный процент времени. Ну выиграешь ты этот процент, а дальше? Откуда брать остальной функционал? А ведь в других библиотеках он уже есть.
Может лучше скрестить какую-нибудь готовую GUI библиотеку с gccxml для того чтобы message maps не руками прописывать, а автоматом генерить? Тогда и сам от лишней работы избавишься, и какому-нибудь сущестующему GUI проекту поможешь.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
adontz wrote:
> Генерация кода сама по себе не поможет, потожет Format Designer. > Выберешь скажем в списке версию с которой хочешь работать и будешь > перемещать поля вверх-вниз указывая их порядок следования, а > checkbox'ами их наличие.
Так он еще и графический будет? Нет, такого счастья точно не надо.
Кстати, почему вы думаете, что при выборе галочек в формочках сложнее
ошибиться, особенно если их будет 40 штук?
Мы работали с одной OR-mapping системой на Java, где отображение
задавалось именно так — с помощью красивого графического редактора. При
первой же возможности мы заменили эту систему на Hibernate
(http://www.hibernate.org), в которой для задания отображения
используется нормальный человеческий XML-файл.
Шахтер wrote:
> C>*Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е > вам ** > C>все равно не получится.* А привязка к компилятору — вообще убивает весь > C>смысл затеи. Использовали тогда бы уж лучше GCCXML. > Отучаемся говорить за других.
В тот же Hoard вложено несколько человеко-лет труда (в том числе на
исследования). Сделать лучше — конечно можно, но это потребует
сопоставимого времени.
Для конкретных частных случаев можно написать более крутой аллокатор, но
для общего — вряд ли.
Здравствуйте, Cyberax, Вы писали:
C>Так он еще и графический будет? Нет, такого счастья точно не надо. C>Кстати, почему вы думаете, что при выборе галочек в формочках сложнее C>ошибиться, особенно если их будет 40 штук?
Ошибится так же просто, но вот визуально найти оишбку гораздо проще.
C>Мы работали с одной OR-mapping системой на Java, где отображение C>задавалось именно так — с помощью красивого графического редактора. При C>первой же возможности мы заменили эту систему на Hibernate C>(http://www.hibernate.org), в которой для задания отображения C>используется нормальный человеческий XML-файл.
Что мешает настроки Format Designer хранить в XML?
Почему ты вечно придумываешь несуществующие проблемы?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, eao197, Вы писали:
E>>Пока вопрос генератора оставим в стороне. Что для данного случая будет в message_data<SIZE>?
A>Ну например старый и новый размер. Что-то специфичное для сообщения.
Ну и чем куча таких специализаций message_data будет лучше методов с конкретными прототипами, настройка на которые происходит автоматически в message_map?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Cyberax, Вы писали:
C>>Так он еще и графический будет? Нет, такого счастья точно не надо. C>>Кстати, почему вы думаете, что при выборе галочек в формочках сложнее C>>ошибиться, особенно если их будет 40 штук?
A>Ошибится так же просто, но вот визуально найти оишбку гораздо проще.
На 17-ти закладках с 40-ка чекбоксами на каждой! Ой-ли?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
A>>Ошибится так же просто, но вот визуально найти оишбку гораздо проще. E>На 17-ти закладках с 40-ка чекбоксами на каждой! Ой-ли?
adontz wrote:
> Будет > >class Window : public WindowBase >{ > public: > void OnSize(const message_data<SIZE> & msgdata); >} > > Такое без генератора просто не возможно.
А это еще хуже — появляются "магические" имена функций, назначение
которых непонятно без знания фич оконной библиотеки. Что-то типа:
class Window : public WindowBase
{
public:
[msg_handler:WM_SIZE] void OnSize(const message_data<SIZE> & msgdata);
}
Будет намного лучше (и без проблем делается с помощью GCCXML).
?
Если я перестану заботится об уже написанном мной C/C++ коде, то мне проще будет уйти в Java/C#, а лучше в Smalltalk/Python/Ruby, чем на доморощенный, урезанный, привязанный к VC диалект C++. 
