Здравствуйте, Cyberax, Вы писали:
C>Ээээ... А в чем проблема? Я сейчас использую Hoard C>(http://www.hoard.org) — он прозрачно заменяет malloc/free и new/delete.
Нет, я не говорю, что это в принципе невозможно. Я говорю о другом вместо того чтобы скачивать и настраивать десяток-другой расширений C++, не лучше ли сделать C++ Run-Time которая будет всё это поддерживать и ещё много чего другого.
adontz wrote:
> C>Ээээ... А в чем проблема? Я сейчас использую Hoard > C>(http://www.hoard.org) — он прозрачно заменяет malloc/free и new/delete. > Нет, я не говорю, что это в принципе невозможно. Я говорю о другом > вместо того чтобы скачивать и настраивать десяток-другой расширений > C++, не лучше ли сделать C++ Run-Time которая будет всё это > поддерживать и ещё много чего другого.
90% того, что мне надо — есть в boost. Остальное давно скачано.
Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е вам
все равно не получится. А привязка к компилятору — вообще убивает весь
смысл затеи. Использовали тогда бы уж лучше GCCXML.
Здравствуйте, Cyberax, Вы писали:
C>90% того, что мне надо — есть в boost. Остальное давно скачано. C>Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е вам C>все равно не получится. А привязка к компилятору — вообще убивает весь C>смысл затеи. Использовали тогда бы уж лучше GCCXML.
Во-первых я и не предлагал писать свои контейнеры. Во-вторых, GCCXML крайне нестабильная вешь.
В-третьих, те задачи которые я хочу решить без кодогенератора или поддержки со стороны компилятора решить просто нельзя.
Здравствуйте, Cyberax, Вы писали:
C>90% того, что мне надо — есть в boost
про boost adontz уже сказал... "И хотите послать меня в boost, etc то остановитесь и подумайте"
C>Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е вам C>все равно не получится.
Да причем тут лучше. Зато свое, оно, понимаешь, всегда теплей и приятней...
Кстати, можешь добавить "gui лучше чем mfc/vcl/qt/vxwidgets/etc... — на выбор"
C>смысл затеи. Использовали тогда бы уж лучше GCCXML.
А как он с visual studio соотносится? идея же я так понимаю под винды писать.
Здравствуйте, eao197, Вы писали:
A>>Во-вторых, GCCXML крайне нестабильная вешь. E>Так может лучше GCCXML помочь?
Плохая идея. Разбирать PDBшки и Code DOM это гораздо быстрее, потому что нет необходимости дважды делать синтаксический разбор кода. Кода, который GCCXML часто просто не понимает.
Зачем усложнять задачу и писать (дописывать) компилятор, когда можно использовать возможность расширения уже существующего.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, eao197, Вы писали:
A>>>Во-вторых, GCCXML крайне нестабильная вешь. E>>Так может лучше GCCXML помочь?
A>Плохая идея.
A> Разбирать PDBшки и Code DOM это гораздо быстрее, потому что нет необходимости дважды делать синтаксический разбор кода. Кода, который GCCXML часто просто не понимает.
Я так понимаю, что в случае GCCXML тебе придется разбирать не код, а XML после работы gccxml.
A>Зачем усложнять задачу и писать (дописывать) компилятор, когда можно использовать возможность расширения уже существующего.
Существующего только на одной платформе, я бы дополнил. А с учетом того, что у Microsoft большой уклон в .Net и C++/CLI, то может статся, что нормальный C++ продолжит существовать на Unix-ах. Где существующим как раз является GCC.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
adontz wrote:
> Плохая идея. Разбирать PDBшки и Code DOM это гораздо быстрее, потому > что нет необходимости дважды делать синтаксический разбор кода. Кода, > который GCCXML часто просто не понимает. > Зачем усложнять задачу и писать (дописывать) компилятор, когда можно > использовать возможность расширения уже существующего.
А зачем делать очередную некроссплатформенную поделку, заточенную только
под Студию?
Во-первых скорость. Основной хинт это то, что скорость компиляции если и возрастает, то незначительно.
A>> Разбирать PDBшки и Code DOM это гораздо быстрее, потому что нет необходимости дважды делать синтаксический разбор кода. Кода, который GCCXML часто просто не понимает. E>Я так понимаю, что в случае GCCXML тебе придется разбирать не код, а XML после работы gccxml.
Да, но тогда код разбирается компилятором, а потом ещё раз разбирается GCCXML. В результате скорость компиляции падает где-то в два раза. Чего ради?
Потом VG это не просто stand-alone утилитка. Это вcтраиваемость в VS. Не просто создание и генерирование файлов, но и правка проектов, чтобы эти файлы адекватно обрабатывались.
Для GUI библиотеки однозначно нужен Forms Designer. Такая простая вешь как автоматическая расстановка порядка табуляции до сих пор нигде не автоматизированна, хотя правила (сверху вниз, слева направо (для азиатов справа налево)) просты. Далее скажем локализация. Покажи мне редактор, который умеет экспортировать все строки и импортировать их, чтобы отдать переводчику txt файл и потом его импортировать. Нету такого.
Если в русской версии диалога есть кнопка которой нет в английской, то понять это можно только запустив программу. Я хочу, чтобы на уровне редактора кнопка, будучи однажды созданой была во всех языковых версиях, но возможно имела разный текст и координаты.
Элементы управления обычно предлагается расставлять либо на глаз, либо по сетке. Тоже глупость, нужно ни то, ни другое, нужно делать вокруг элемента управления рамочку (для groupbox ещё и внутри) и не давать приближатся ближе чем эта рамочка. Дальше тоже не стоит, значит рамочка должна быть липучей.
Для сериализации некоторый нужен Format Designer.
Простая задача котору мне задали. Есть структура vector< pair<int,int> > Если файл имеет версию 2, то счтитывать оба компонента pair, файл версии 1 содержит только второй компонент, а первому присваивать 0. Как просто сделать две разметки для разных версий и читать вроде archive.deserialize<1>(variable) или archive.deserialize<2>(variable)
Можно структуру
struct
{
int x;
int y;
}
считывать из файла где y записан раньше x. И так далее. В принципе ничто не мешает делать и вычисляемые поля. Чтобы скажем для прямоугольника width и height читать из файла, а area считать на лету, но только для версии 1, потому что в версии 2 area записан. Для кодогенератора пара пустяков, без него решение превращается в кучу малоструктурированного кода в котором легко ошибится.
E>Существующего только на одной платформе, я бы дополнил. А с учетом того, что у Microsoft большой уклон в .Net и C++/CLI, то может статся, что нормальный C++ продолжит существовать на Unix-ах. Где существующим как раз является GCC.
Ну я не думаю, что Unmanaged C++ Compiler будет убит в обозримом будущем. С другой стороны, что мешает иметь VC++ только как основной компилятор? Ведь можно все эти сгенерированные файлы потом чем угодно перекомпилировать — проблем нет. Разработчики Mozilla AFAIK используют в качестве основного компилятора именно VC.
adontz wrote:
> C>90% того, что мне надо — есть в boost. Остальное давно скачано. > C>Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е вам > C>все равно не получится. А привязка к компилятору — вообще убивает весь > C>смысл затеи. Использовали тогда бы уж лучше GCCXML. > Во-первых я и не предлагал писать свои контейнеры. Во-вторых, GCCXML > крайне нестабильная вешь.
Ну так стабилизируйте его. Хотя какая-то польза от вас тогда будет...
> В-третьих, те задачи которые я хочу решить без кодогенератора или > поддержки со стороны компилятора решить просто нельзя.
Antikrot wrote:
> C>смысл затеи. Использовали тогда бы уж лучше GCCXML. > А как он с visual studio соотносится? идея же я так понимаю под винды > писать.
Нормально, в нем даже есть поддержка расширений MSовского компилятора
(всякие __declspec'и).
adontz wrote:
> Можно структуру > >struct >{ > int x; > int y; >} > > > считывать из файла где y записан раньше x. И так далее. В принципе > ничто не мешает делать и вычисляемые поля. Чтобы скажем для > прямоугольника width и height читать из файла, а area считать на лету, > но только для версии 1, потому что в версии 2 area записан. Для > кодогенератора пара пустяков, без него решение превращается в кучу > малоструктурированного кода в котором легко ошибится.
Это все без особых проблем делается существующими средствами С++.
Кодогенерация помогла бы кое-где, но она далеко не критична.
Вот и все (#include'ы бустовских исходников пропущены для краткости).
Причем все будет работать, если x и y — это тоже структуры (для которых
определена сериализация). То есть единственное место, где нужна
генерация кода — это создание метода serialize, а это уже совсем некритично.
> E>Существующего только на одной платформе, я бы дополнил. А с учетом > того, что у Microsoft большой уклон в .Net и C++/CLI, то может статся, > что нормальный C++ продолжит существовать на Unix-ах. Где существующим > как раз является GCC. > Ну я не думаю, что Unmanaged C++ Compiler будет убит в обозримом > будущем. С другой стороны, что мешает иметь VC++ только как основной > компилятор? Ведь можно все эти сгенерированные файлы потом чем угодно > перекомпилировать — проблем нет.
А __attribute__'ы GCCшные он понимает? А export templates из Como/ICC?
> Разработчики Mozilla AFAIK используют в качестве основного компилятора > именно VC.
Нет, они используют MinGW и хотят переползти на IntelC++.
SchweinDeBurg wrote:
> C>Я сейчас использую Hoard > C>(http://www.hoard.org) — он прозрачно заменяет malloc/free и new/delete. > А можно чуточку комментариев?..
Это такой крутой аллокатор для многотредовых приложений, с огромной
кучей оптимизаций, с неблокирующим malloc/free и т.п.. Очень часто в
разы быстрее стандартных аллокаторов.
> Хотелось бы услышать что-то такое "человеческое", "личностное"... > Скажем, с VC 7.*0* эта штука дружит?
Даже с VC6 дружит, он прозрачно заменяет CRTшные вызовы. В коде просто
надо вставить:
adontz,
> Я сам сейчас пишу на C#, и у этого языка есть свои большие достоинства, но нет много такого что есть в Си++. Суть в том, что если поднатужится, то Си++ можно дотянуть до C#.
Если я правильно понимаю, речь идет о Reflection и т.п. Но это не есть свойства C#, это возможности платформы. Соответственно, почему бы, если хочется получить эти возможности, сохранив возможности C++, не попробовать C++/CLI, именно для этого и предназначенный?..
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Если говорить серьезно, то больше всего меня смущает глобальность такого замысла. Буч, по-моему, сказал: "Любая большая работающая система неизбежно получается путем эволюции маленькой работающей системы". Так вот, за полгода моего активного участия в форумах RSDN это уже второй твой громкий прожект с замахом на глобальность. Но при этом хотелось бы увидеть маленький работающий фрагмент всего этого дела, который бы смог эволюционировать со временем в то, что ты описал.
Ну а если брать отдельные части, то здесь так же есть масса возражений. По поводу замены C-шной RTL очень здорово высказался MaximE: Re: Проект Visual Generator
Ну а я позволю себе дать несколько банальных комментариев.
A>Для GUI библиотеки однозначно нужен Forms Designer. Такая простая вешь как автоматическая расстановка порядка табуляции до сих пор нигде не автоматизированна, хотя правила (сверху вниз, слева направо (для азиатов справа налево)) просты. Далее скажем локализация. Покажи мне редактор, который умеет экспортировать все строки и импортировать их, чтобы отдать переводчику txt файл и потом его импортировать. Нету такого. A>Если в русской версии диалога есть кнопка которой нет в английской, то понять это можно только запустив программу. Я хочу, чтобы на уровне редактора кнопка, будучи однажды созданой была во всех языковых версиях, но возможно имела разный текст и координаты. A>Элементы управления обычно предлагается расставлять либо на глаз, либо по сетке. Тоже глупость, нужно ни то, ни другое, нужно делать вокруг элемента управления рамочку (для groupbox ещё и внутри) и не давать приближатся ближе чем эта рамочка. Дальше тоже не стоит, значит рамочка должна быть липучей.
Сдается мне, что ты не сталкивался с такой штукой, как Qt. Там и проблема локализации давно решена, промышленным причем способом, даже редактор специальный был -- Qt Linguist. А уж как там классно все с расположением контролов все сделано, layout-ы всякие, size-политики. А уж контролы spacer-ы чего стоят! MFC и Visual Studio просто отдыхают.
A>Для сериализации некоторый нужен Format Designer. A>Простая задача котору мне задали. Есть структура vector< pair<int,int> > Если файл имеет версию 2, то счтитывать оба компонента pair, файл версии 1 содержит только второй компонент, а первому присваивать 0. Как просто сделать две разметки для разных версий и читать вроде archive.deserialize<1>(variable) или archive.deserialize<2>(variable) A>Можно структуру A>
A>struct
A>{
A> int x;
A> int y;
A>}
A>
A>считывать из файла где y записан раньше x. И так далее. В принципе ничто не мешает делать и вычисляемые поля. Чтобы скажем для прямоугольника width и height читать из файла, а area считать на лету, но только для версии 1, потому что в версии 2 area записан. Для кодогенератора пара пустяков, без него решение превращается в кучу малоструктурированного кода в котором легко ошибится.
Мой скромный опыт в разработке средств сериализации и поверхностное знакомство с Asn1 подсказывает мне, что в таких случаях самое главное -- это идея. Важен механизм, которым ты будешь связывать значения атрибутов с их сериализованными представлениями (особенно, если потребуется поддерживать разные форматы). А уже как ты этому механизму скажешь, какие именно атрибуты подлежат сериализации -- это уже даже не второй вопрос. И помощь со стороны транслятора C++ здесь нужна будет только для получения списка атрибутов. А уже написание кодогенератора для выбранного механизма с трансляцией C++ текста совсем никак не связана.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> Сдается мне, что ты не сталкивался с такой штукой, как Qt. Там и > проблема локализации давно решена, промышленным причем способом, даже > редактор специальный был -- Qt Linguist. А уж как там классно все с > расположением контролов все сделано, layout-ы всякие, size-политики. А > уж контролы spacer-ы чего стоят! MFC и Visual Studio просто отдыхают.
Угу, обожаю лэйауты! Я на Swing'е в Java пишу код с лэйаутами для
интерфейса _быстрее_, чем дельфисты кидают контролы на формочки
(сравнивали).
К сожалению, так пока и не нашел нормальной С++ной GUIшной либы, которая
имела бы такие же возможности. QT почти все нужное умеет, но все же
чуть-чуть не дотягивает.
Пытался писать свои велосипеды для WTL — они работают, но хочется
чего-нибудь получше еще сделать. Только вот времени все нет...
Здравствуйте, Cyberax, Вы писали:
C>Это все без особых проблем делается существующими средствами С++. C>Кодогенерация помогла бы кое-где, но она далеко не критична. C>