Здравствуйте, 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.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, 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 соотносится? идея же я так понимаю под винды писать.

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

A>Во-вторых, GCCXML крайне нестабильная вешь.

Так может лучше GCCXML помочь?

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

A>>Во-вторых, GCCXML крайне нестабильная вешь.
E>Так может лучше GCCXML помочь?

Плохая идея. Разбирать PDBшки и Code DOM это гораздо быстрее, потому что нет необходимости дважды делать синтаксический разбор кода. Кода, который GCCXML часто просто не понимает.
Зачем усложнять задачу и писать (дописывать) компилятор, когда можно использовать возможность расширения уже существующего.

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

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

A>>>Во-вторых, GCCXML крайне нестабильная вешь.
E>>Так может лучше GCCXML помочь?

A>Плохая идея.

Не многим хуже чем Проект Visual Generator

Автор: adontz
Дата: 07.07.05

A> Разбирать PDBшки и Code DOM это гораздо быстрее, потому что нет необходимости дважды делать синтаксический разбор кода. Кода, который GCCXML часто просто не понимает.

Я так понимаю, что в случае GCCXML тебе придется разбирать не код, а XML после работы gccxml.

A>Зачем усложнять задачу и писать (дописывать) компилятор, когда можно использовать возможность расширения уже существующего.

Существующего только на одной платформе, я бы дополнил. А с учетом того, что у Microsoft большой уклон в .Net и C++/CLI, то может статся, что нормальный C++ продолжит существовать на Unix-ах. Где существующим как раз является GCC.

adontz wrote:

> Плохая идея. Разбирать PDBшки и Code DOM это гораздо быстрее, потому
> что нет необходимости дважды делать синтаксический разбор кода. Кода,
> который GCCXML часто просто не понимает.
> Зачем усложнять задачу и писать (дописывать) компилятор, когда можно
> использовать возможность расширения уже существующего.

А зачем делать очередную некроссплатформенную поделку, заточенную только
под Студию?

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>А зачем делать очередную некроссплатформенную поделку, заточенную только под Студию?

Потому что это мой выбор и переубеждать меня бессмысленно

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

A>>Плохая идея.
E>Не многим хуже чем Проект Visual Generator

Автор: adontz
Дата: 07.07.05

Во-первых скорость. Основной хинт это то, что скорость компиляции если и возрастает, то незначительно.

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.

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

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

А можно чуточку комментариев?.. Хотелось бы услышать что-то такое "человеческое", "личностное"... Скажем, с VC 7.0 эта штука дружит?

adontz wrote:

> C>90% того, что мне надо — есть в boost. Остальное давно скачано.
> C>Написать аллокатор лучше Hoard'а, контейнеры лучше чем в STLPort'е вам
> C>все равно не получится. А привязка к компилятору — вообще убивает весь
> C>смысл затеи. Использовали тогда бы уж лучше GCCXML.
> Во-первых я и не предлагал писать свои контейнеры. Во-вторых, GCCXML
> крайне нестабильная вешь.

Ну так стабилизируйте его. Хотя какая-то польза от вас тогда будет...

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

Ну так делайте кодогенератор на основе GCCXML.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Antikrot wrote:

> C>смысл затеи. Использовали тогда бы уж лучше GCCXML.
> А как он с visual studio соотносится? идея же я так понимаю под винды
> писать.

Нормально, в нем даже есть поддержка расширений MSовского компилятора
(всякие __declspec'и).

--
С уважением,
Alex Besogonov (alexy@izh.com)

adontz wrote:

> Можно структуру
>
>struct
>{
> int x;
> int y;
>}
>
>
> считывать из файла где y записан раньше x. И так далее. В принципе
> ничто не мешает делать и вычисляемые поля. Чтобы скажем для
> прямоугольника width и height читать из файла, а area считать на лету,
> но только для версии 1, потому что в версии 2 area записан. Для
> кодогенератора пара пустяков, без него решение превращается в кучу
> малоструктурированного кода в котором легко ошибится.

Это все без особых проблем делается существующими средствами С++.
Кодогенерация помогла бы кое-где, но она далеко не критична.

struct MyStruct{int x,y;};
template<class Archive> void serialize(Archive &ar,MyStruct 
&str,unsigned version)
{
    ar&y&x;
};

Для версии 2:

struct MyStruct{int x,y,area;};
template<> version_tag<MyStruct> {enum version=2;};

template<class Archive> void serialize(Archive &ar,MyStruct 
&str,unsigned version)
{
    ar&y&x;
    if (version==2)
       ar&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++.

--
С уважением,
Alex Besogonov (alexy@izh.com)

SchweinDeBurg wrote:

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

Это такой крутой аллокатор для многотредовых приложений, с огромной
кучей оптимизаций, с неблокирующим malloc/free и т.п.. Очень часто в
разы быстрее стандартных аллокаторов.

> Хотелось бы услышать что-то такое "человеческое", "личностное"...
> Скажем, с VC 7.*0* эта штука дружит?

Даже с VC6 дружит, он прозрачно заменяет CRTшные вызовы. В коде просто
надо вставить:

#if defined(USE_HOARD)
#pragma comment(lib, "libhoard.lib")
#endif

Как вариант, можно даже с помощью Detours даже без изменений исходников
использовать.

--
С уважением,
Alex Besogonov (alexy@izh.com)

adontz,

> Я сам сейчас пишу на C#, и у этого языка есть свои большие достоинства, но нет много такого что есть в Си++. Суть в том, что если поднатужится, то Си++ можно дотянуть до C#.

Если я правильно понимаю, речь идет о Reflection и т.п. Но это не есть свойства C#, это возможности платформы. Соответственно, почему бы, если хочется получить эти возможности, сохранив возможности C++, не попробовать C++/CLI, именно для этого и предназначенный?..

Здравствуйте, adontz

Если говорить серьезно, то больше всего меня смущает глобальность такого замысла. Буч, по-моему, сказал: "Любая большая работающая система неизбежно получается путем эволюции маленькой работающей системы". Так вот, за полгода моего активного участия в форумах RSDN это уже второй твой громкий прожект с замахом на глобальность. Но при этом хотелось бы увидеть маленький работающий фрагмент всего этого дела, который бы смог эволюционировать со временем в то, что ты описал.

Ну а если брать отдельные части, то здесь так же есть масса возражений. По поводу замены C-шной RTL очень здорово высказался MaximE: Re: Проект Visual Generator

Автор: MaximE
Дата: 08.07.05

. Здесь уж не добавишь, ни убавишь.

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

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++ текста совсем никак не связана.

eao197 wrote:

> Сдается мне, что ты не сталкивался с такой штукой, как Qt. Там и
> проблема локализации давно решена, промышленным причем способом, даже
> редактор специальный был -- Qt Linguist. А уж как там классно все с
> расположением контролов все сделано, layout-ы всякие, size-политики. А
> уж контролы spacer-ы чего стоят! MFC и Visual Studio просто отдыхают.

Угу, обожаю лэйауты! Я на Swing'е в Java пишу код с лэйаутами для
интерфейса _быстрее_, чем дельфисты кидают контролы на формочки
(сравнивали).

К сожалению, так пока и не нашел нормальной С++ной GUIшной либы, которая
имела бы такие же возможности. QT почти все нужное умеет, но все же
чуть-чуть не дотягивает.

Пытался писать свои велосипеды для WTL — они работают, но хочется
чего-нибудь получше еще сделать. Только вот времени все нет...

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Это все без особых проблем делается существующими средствами С++.
C>Кодогенерация помогла бы кое-где, но она далеко не критична.
C>

C>struct MyStruct{int x,y;};
C>template<class Archive> void serialize(Archive &ar,MyStruct 
C>&str,unsigned version)
C>{
C>    ar&y&x;
C>};
C>

C>Для версии 2:
C>

C>struct MyStruct{int x,y,area;};
C>template<> version_tag<MyStruct> {enum version=2;};

C>template<class Archive> void serialize(Archive &ar,MyStruct 
C>&str,unsigned version)
C>{
C>    ar&y&x;
C>    if (version==2)
C>       ar&area;
C>};
C>

Чудестно, теперь представь, что у тебя 39 полей и 17 версий.

C>А __attribute__'ы GCCшные он понимает? А export templates из Como/ICC?

Нет, а зачем?


C>Нет, они используют MinGW и хотят переползти на IntelC++.

IntelC++ писался с расчётом на совместимость с VC++.

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

C>Ну так стабилизируйте его.

Я не хочу писать синтаксический парсер. Я хочу использовать уже готовый.

C>Хотя какая-то польза от вас тогда будет...

Ну-ну, не хами.

C>Ну так делайте кодогенератор на основе GCCXML.

Я делаю не только кодогенератор.