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

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

Исходники поменять — не проблема. "Уголовное дело — это вам не брюки не с рантом, уголовное дело шьется в пять секунд..." (с) Довлатов. Искренне — овчинка того стоит? Я имею ввиду — в "маленьком" и "среднем" десктопном приложении (если уж совсем нахальничать — сходите на http://zarezky.spb.ru/projects.html и просто прикидочно выскажетесь относительно целесообразности).

Здравствуйте, Павел Кузнецов, Вы писали:

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

Есть вещи которых не хватает в обоих языках.

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

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

Допустим. И что ты предлагаешь с этим делать?

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

C>eao197 wrote:

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

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

Не, имхо, в Qt, особенно в паре с Qt Designer, layout-ы удобнее будут. Хотя Swing-овых я уже года четыре как не брал в руки

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

E>Если говорить серьезно, то больше всего меня смущает глобальность такого замысла.

потому я и не хочу это делать один.

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

Я могу прямо сейчас дать тебе полностью работающую С++ Run-Time написанную с нуля (ну за исключением memmove и тому подобных вещей). Кроме того я практически полностью (за исключением некоторых классов-политик) реализовал строковый класс поддерживающий Unicode 4.1.
Как база на которую можно достраивать ИМХО не плохо. Ну ввод-вывод не то чем можно гордится.

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

Насколько я видел Qt-приложения (может плохо видел?) они выглядят для Windows достаточно инородно.

E>Мой скромный опыт в разработке средств сериализации и поверхностное знакомство с Asn1 подсказывает мне, что в таких случаях самое главное -- это идея. Важен механизм, которым ты будешь связывать значения атрибутов с их сериализованными представлениями (особенно, если потребуется поддерживать разные форматы).

Идея как раз в том, что именно Format Designer и будет определять это. Любой выбор кого-то не удовлетворит. В идеале я хочу сделать так, чтобы любой формат файла после некоторого времени проведённом за Format Designer можно было просто десериализовать с свои структуры — эффективность не последний фактор.

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

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

A>Я могу прямо сейчас дать тебе полностью работающую С++ Run-Time написанную с нуля (ну за исключением memmove и тому подобных вещей). Кроме того я практически полностью (за исключением некоторых классов-политик) реализовал строковый класс поддерживающий Unicode 4.1.
A>Как база на которую можно достраивать ИМХО не плохо. Ну ввод-вывод не то чем можно гордится.

А с какими стандартами она соотносится?

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

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

Так может поможешь писать GUI библиотеку, а не будешь всё хаять ?

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

A>>Я могу прямо сейчас дать тебе полностью работающую С++ Run-Time написанную с нуля (ну за исключением memmove и тому подобных вещей). Кроме того я практически полностью (за исключением некоторых классов-политик) реализовал строковый класс поддерживающий Unicode 4.1.
A>>Как база на которую можно достраивать ИМХО не плохо. Ну ввод-вывод не то чем можно гордится.

E>А с какими стандартами она соотносится?

Кто? Run-Time? На реализацию Run-Time нет стандарта. Есть стандарт на некоторый набор функциональности который должен поддерживаться. Я из него выкинул всё, что касается Си. Остались new/delete, RTTI, exceptions. В RTTI не доделан type_info::name() потому что способ декорирования имён компилятором VC нигде не документирован, хотя и есть пара статей с изысканиями + исходники WINE, которые впрочем тоже не полностью реализуют задачу. Но немного поработав над этим вопросом я пришёл к выводу, что задача вполне разрешима — бывали и посложнее.

SchweinDeBurg wrote:

> C>Как вариант, можно даже с помощью Detours даже без изменений исходников
> C>использовать.
> Исходники поменять — не проблема. "Уголовное дело — это вам не брюки
> не с рантом, уголовное дело шьется в пять секунд..." (с) Довлатов.
> Искренне — овчинка того ст*о*ит? Я имею ввиду — в "маленьком" и
> "среднем" десктопном приложении (если уж совсем нахальничать — сходите
> на http://zarezky.spb.ru/projects.html и просто прикидочно выскажетесь
> относительно целесообразности).

Hoard имеет смысл использовать, если приложение многопоточное — выигрыш
будет заметен на глаз. Для одного потока лучше использовать malloc от
Dough Lea.

Сказать про ваши проекты — сложно. Проще скачать Hoard и посмотреть что
получится. Выигрыш будет, скорее всего, но может быть очень небольшим.

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

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

A>Есть вещи которых не хватает в обоих языках.

[offtop]
И нам всегда нужно много и сразу...
(с) Рыбин
[/offtop]

eao197 wrote:

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

Жаль что у Qt лицензия — GPL, иначе бы использовал его во всех проектах.
Коммерческие лицензии больно уж дорогие у них.

В Swing'е главным оказалось подобрать лучший набор лэйаутов и изучить их
особенности — после этого программирование интерфейсов даже стало
интересным.

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

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

C>Hoard имеет смысл использовать, если приложение многопоточное

ОК, я приму к сведению.

C>Сказать про ваши проекты — сложно.

У меня MT наличествует, но в малом количестве. В любом случае — еще раз спасибо за ссылку, буду экспериментировать.

adontz wrote:

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

Я не буду писать код для OpenSource, привязанный к одной платформе —
неинтересно это.

Я регулярно присматриваюсь к разным фреймворкам типа WxWidgets — все ищу
какой бы из них взять за основу для своей либы. Так что может
когда-нибудь и напишу.

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

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

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

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

SDB>Исходники поменять — не проблема. "Уголовное дело — это вам не брюки не с рантом, уголовное дело шьется в пять секунд..." (с) Довлатов. Искренне — овчинка того стоит? Я имею ввиду — в "маленьком" и "среднем" десктопном приложении (если уж совсем нахальничать — сходите на http://zarezky.spb.ru/projects.html и просто прикидочно выскажетесь относительно целесообразности).

Fast memory allocator for multithreaded applications:
http://www.garret.ru/~knizhnik/threadalloc/readme.html

Также оказалаcь полезной "фича" MSPACES в аллокаторе Doug Lea
для имплементации конструкций типа memory pool:

class document 
{
  memory_pool mp;
  void* alloc( size_t sz ) { return mp.alloc(sz); }
}

adontz wrote:

>
>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 версий.

Ну будет 17 if'ов стоять (точнее в этом случае будет switch)? Ничего
страшного.

Тем более что необходимость поддерживать обратную совместимость на 17
версий назад для объектов с 40 полями — это уже что-то слегка странное.

Кстати, а как в этом случае генерация кода поможет?

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

Если я потом захочу код с помощью GCC скомпилить.

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

"В теории практика не отличается от теории, но на практике — отличается".

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

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

CS>Также оказалаcь полезной "фича" MSPACES в аллокаторе Doug Lea

А скажи мне, брат Smile — в MFC-шных приложениях она будет так же "полезна"?

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

C>Ну будет 17 if'ов стоять (точнее в этом случае будет switch)? Ничего
C>страшного.

C>Тем более что необходимость поддерживать обратную совместимость на 17
C>версий назад для объектов с 40 полями — это уже что-то слегка странное.

C>Кстати, а как в этом случае генерация кода поможет?

Генерация кода сама по себе не поможет, потожет Format Designer. Выберешь скажем в списке версию с которой хочешь работать и будешь перемещать поля вверх-вниз указывая их порядок следования, а checkbox'ами их наличие.
Просто и понятно. Всегда можно увидеть какие поля в какой версии есть, а в какой нету. Значительно меньше вероятность ошибки, легче её исправить.
То есть продолжая пример с прямугольником у теюя будет приблизительно такая картина

  ______________________
 / Version 1 \ Version 2 \
|                         |
| [x] width               |
| [x] height              |
| [_] area                |
|                         |
---------------------------

  ______________________
 / Version 1 / Version 2 \
|                         |
| [x] width               |
| [x] height              |
| [x] area                |
|                         |
---------------------------

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

C>Я не буду писать код для OpenSource, привязанный к одной платформе — неинтересно это.

А мне зачем мешаешь?

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

Обясните не знаящему
что такое demangling ?

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

A>что такое demangling ?
A>

Пусть есть перегруженая функция f

int f(int);
void f(float);
char * f(my_type);

так как компономщик ничего не знает о перегрузке функций, то компилятор не может использовать имя f, нужно три разных имени. Обычно в этих целях имя f снабжают преффиксами и суффиксами, например

int@f@int@
void@f@float@
char@@f@my_class@

такие имена уже уникальны. Их называют декорированными (mangled, decorated). demangling это процеду получения по такому декорированному имени прототипа функции.

Аналогичная операция существует и для типов. Получить декорированное имя типа очень просто это typeid(type).raw_name()