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

VD>Дык вокруг него такой ореол создали, что несколько лет назад плохое слово в сторону дизайна С++ сразу выливалось в анафему высказавшему эту мысль.

Если человек только начал изучать С++ и ему уже C++ больше нравится чем C# значит он только этот ореол и видел. По тому что на поверхностном уровне между этими языками практически никакой разницы.
Или "логическим" путем вывел : если на C++ писать сложнее => значит он круче.

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

O>>> ну посмейся, может в процессе придет понимание того, что в с++ есть возможность сделать то, чего нет в других языках, и есть возможность сделать подобие того, чего в нем изначально не было, и есть в других.
G>>Ну тогда в студию GC, с такими же performance характеристиками, как в managed.
O> нахрен он нужен если есть шаред птр? чтобы морочить себе голову вызовом принудительной сборки для попытки освободить ресурс в прогнозируемое время
шаред птр — дополнительные тормоза на каждой операции присваивания и каждом выходе из блока. .NETовский GC порвет релизацию работы с динмамической памятью на shared_ptr как тузик грелку.

O>>>И это при том, что в нем можно работать как в менеджед, так и в анменеджед,
G>>Это не является преимуществом.
G>>У unmanaged вообще говоря достаточно мало преимуществ.
O>ты совсем ляпнулся или как ? Код по работе из менеджед с МАПИ? (даже не пытайся, по твоим суждения видно что ты не доганяешь принципиальной разницы диспатч саппортинга )
А нахрен он нужен в .NET?

O>>>Сравнивать же менеджед и анменеджед — изначально бредово, т.к. если идет сравнение возможностей, то последние молчат при необходимости работы с МАПИ и библиотеками с ансаппортным диспатч и т.д.
G>>.NET умеет работать с COM.
O> : насмешил мои тапочки очередной раз ..ну подними IUnknown
А зачем? .NET отлично работает с com без вникания в детали реализации этого COM. Не нужно знать про IUnknown, AddRef и Release, про CoCreateInstance и прочее/
То что ты считаеь крутостью является на самом деле ненужной шелухой.

G>>Ты неверное в другом мире живешь.
G>>Сколько я проектов сделал на .NET необходимость в вызовах нативных методов возникала раза два.
G>>Неверное это от твоего незнания библиотеки.
O>Ха, какой библиотеки если есть области для которых менеджед код не имеет библиотек, МАПИ — это лишь одна — совсем малая из них. Ты что до сих пор не понял, роль менеджед Си?
Да нахрен не нужен MAPI, .NET и без него почту слать умеет.

G>>Делегаты можно считать навороченным "указателем на функцию", так как в .NET сам методы не являются FCO.
G>>А в C++ не было ни делегатов и ФВП, были только указатели на функцию, которые как и все указатели наделены родовыми травмами.
G>>Перегрузка скобок дает возможность делать что-то издалека похоже на делегаты .NET или ФВП, в остальном такая перегрузка нафиг не нужна.
O> Да нифига, си благодаря своей гибкости () позволяет реализовать то, что есть в других языках без изменения самого Си , функторы появились зодолго до делегатов, — , которые в принципе ничем не отличаются от указателя на функцию, кроме оверкодинга в декларации.
O> идиома mem_fun и bind это гораздо более широкое понятие, чем делегаты именно благодаря позднему связыванию, когда
O>декларации вида:
O>

//нечитаемая фигня опущена

O>с возможностью биндить как аргументы, так и владельцев
А в чем крутость если тоже самое достигается передачей объекта как параметра?

O>>>>>т.к. хочется сделать красиво, а не можется
G>>>>Красиво это как? Нафигачить шаблоков?
G>>>>И как на плюсах сделать красиво IoC-контейнер?
O>>> да запросто, причем реализовывается с ограничение депенденси, при превышении даже собираться не будет
G>>Ну код в студию.
O> денег давай будет — а пока можешь уже готовые решения посмотреть , а они есть ..
Зачем тебе денег? Все контейнеры бесплатные. Нормальных решений для С++ нету.
Слив засчитан.

G>>Если каждый начнет "имплементить реализации" (шибанутое словосочетание) модифицирющие синтаксис, то будет попа. Код станет абсолютно нечитаемым.
O> на этой попе, простите, сидит весь NET
Примеры покажешь как весь .NET сидит на модификации синтаксиса?

O>>> Ком нужен для определенной специфики, чтобы мегатяжелые менеджед грабли таки могли получить быстро работающий код, или код, который может дернуть то, чего ну никак не дернуть из менеджед , или просто попытаться избавить себя от гемороя мегатомных импортов. А для реализации прослоек используется менеджед си.
G>>Это ты сам себе придумал? Из C# отлично дергаются нативные методы, да нужны они очень редко, а работа с комом происходит гораздо проще.
O>Опять смешишь тапочки, ? создай в шарпе натив экземпляр и вызови от него метод.
Натив экземпляр чего?

Здравствуйте, gandjustas, Вы писали:
В общем то резюм я понял, твоя стратегия проста — все что преимущество (я даже преимуществом это не назову потому, что для каждой платформы свои задачи) С++ — для нета не нужно. Читай между строк.

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

G>шаред птр — дополнительные тормоза на каждой операции присваивания и каждом выходе из блока. .NETовский GC порвет релизацию работы с динмамической памятью на shared_ptr как тузик грелку.
весьма самоуверенное и между тем необъективное заявление. Достаточно для проверки провести небольшой тест, создаем определенное количество объектов, в си, и дот нете, и считаем время какое ушло на создание — очистку ссылок. Ок Там и посмотри что тузик, а что грелка ..

O>>>>И это при том, что в нем можно работать как в менеджед, так и в анменеджед,
G>>>Это нты е является преимуществом.
G>>>У unmanaged вообще говоря достаточно мало преимуществ.
O>>ты совсем ляпнулся или как ? Код по работе из менеджед с МАПИ? (даже не пытайся, по твоим суждения видно что ты не доганяешь принципиальной разницы диспатч саппортинга )
G>А нахрен он нужен в .NET?
Знаешь на скольких проектах хотели бы считать так-же как и ты? И не только про мапи, а про весь ком без поддержки диспатча (т.е. те ком объекты которые в принципе не могут использоваться в нете, уже бы пора тебе заметить мой намек)

G>То что ты считаеь крутостью является на самом деле ненужной шелухой.
да хватит, я уже понял. Ну не беда, это сейчас, пару раз столкнешься с необходмостью эту "шелуху" просаппортить в нет, и понимание придет.

G>Да нахрен не нужен MAPI, .NET и без него почту слать умеет.
Это какую если не секрет

O>>

//именно по этому тебе бесполезно , чтото говорить, бо суть того о чем тебе говорят вот уже который пост, ты элементарно не доганяешь
G>

O>>с возможностью биндить как аргументы, так и владельцев
G>А в чем крутость если тоже самое достигается передачей объекта как параметра?
Я же говорю нет — расхолаживает

G>Зачем тебе денег? Все контейнеры бесплатные. Нормальных решений для С++ нету.
G>Слив засчитан.
Согласен, согласен, только вот критерий нормальности у нас вряд ли с тобой совпадают.

G>>>Если каждый начнет "имплементить реализации" (шибанутое словосочетание) модифицирющие синтаксис, то будет попа. Код станет абсолютно нечитаемым.
O>> на этой попе, простите, сидит весь NET
G>Примеры покажешь как весь .NET сидит на модификации синтаксиса?
Как только ты покажешь мне возможность работы с комом без диспатч, так и сразу

O>>>> Ком нужен для определенной специфики, чтобы мегатяжелые менеджед грабли таки могли получить быстро работающий код, или код, который может дернуть то, чего ну никак не дернуть из менеджед , или просто попытаться избавить себя от гемороя мегатомных импортов. А для реализации прослоек используется менеджед си.
G>>>Это ты сам себе придумал? Из C# отлично дергаются нативные методы, да нужны они очень редко, а работа с комом происходит гораздо проще.
O>>Опять смешишь тапочки, ? создай в шарпе натив экземпляр и вызови от него метод.
G>Натив экземпляр чего?
экземпляр анменеджед объекта, — еще одну (хоть какую-то, кривую, не кривую, любую иллюстрацию)

o> идиома mem_fun и bind это гораздо более широкое понятие, чем делегаты именно благодаря позднему связыванию, когда
o> декларации вида:

o>

o> class _1call
o> {
o>   public:
o>   tempate <typename T>
o>      void m(T val) {}
o> };

o> class _2call
o> {
o>   public:
o>   tempate <typename T>
o>      void m(T val) {}
o> };
o> ...
o> task<_1call, task<_2call > > t (bind(&_1call::m<dyadya_vasya>), task<_2call, task<_3call >... >... );

o> //вызовется в последствии
o> _1call owner;
o>   t(owner)(dyadya_vasya);
o>

o> с возможностью биндить как аргументы, так и владельцев, так и чуваков

А можноо объяснить на пальцах, что здесь происходит? По-моему, тут написана какая-то реально нечитаемая фигня, в которой сам автор не разберется уже через полгода

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

ГВ>>>>И как это опровергает сказанное мной? Что если фича реализована средствами языка — это не недостаток самого языка?
G>>>Если фича востребована, а реализация делается через непонятно что. причем за много лет в самом языке это не было исправлено, то это однозначно свидетельствует о недостатке языка.
ГВ>>В лучшем случае, это свидетельствует о недостатках процесса управления разработкой языка.
G>Наличие надостатков в управлении разработкой веде к недостаткам в самом языке.

А ещё это может свидетельствовать о неправильном применении языка, о чрезмерной концентрации на Syntax Sugar и ещё много о чём, вплоть до недостатков, присущих правительству Шарля Де Голля. Тут вопрос в другом: удалось реализовать фичу X средствами самого языка ("понятно какими" или "непонятно какими" — совершенно не важно) или нет. Если не удалось — значит возможностей языка для этой фичи не хватает. Если удалось, то относить сей факт к "недостаткам" можно, ИМХО, только по каким-то очень вычурным соображениям вроде очередного "миллиона индусов, которые завалят нас багами".

ГВ>>Мало ли какие фичи могут оказаться востребованными?
G>Есть другие языки, достаточно смотреть по сторонам и думать головой.
G>Кстати разработчики C# сейчас демонстрируют обратный паттерн поведения, и мне реально иногда становится страшно за будущее шарпа.

Дык! Об этом заговорили аккурат в том же 2002-м, если мне не изменяет память.

ГВ>>Кстати, заморочки с переносом кода между .Net и Mono, AFAIK, имеют место быть.
G>Не имеют, надо только уметь готовить.
G>Специально поставил второй моно, написал на нем Winforms прогу, не используя mono-scecific библиотеки, и она запустилась под .NET без перекомпиляции.

Значит, слухи лживые.

G>Если хочется переносимости — надо использовать переносимое подмножество библиотек, это аксиома для любого языка.

Да. Ровно то же самое относится и к C++-библиотекам, с той поправкой, что по сути компиляторы разных производителей представляют собой разные модификации C++ (собственно, для обеспечения согласованности и нужна стандартизация, в том числе и ABI).

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

O> В общем то резюм я понял, твоя стратегия проста — все что преимущество (я даже преимуществом это не назову потому, что для каждой платформы свои задачи) С++ — для нета не нужно. Читай между строк.
А ты преимуществ то и не привел.
Сможешь объяснить в чем "премущества" С++ заключаются?
В том что на нем можно сделать что-то сильно системное? Так тоже самое можно сделать на С без всей мощи абстрактных шаблонов, а потом вызывать из высокоуровневого кода.
В том что можно на шаблонах делать фигню, которая типа меняет синтасис? Так это сильно сомнительное преимущество, код нечитаемый становится.
То что можно перегрузить скобки? Это просто смешно, в нормальных языках нету необходимости перегружать скобкию

G>>шаред птр — дополнительные тормоза на каждой операции присваивания и каждом выходе из блока. .NETовский GC порвет релизацию работы с динмамической памятью на shared_ptr как тузик грелку.
O> весьма самоуверенное и между тем необъективное заявление. Достаточно для проверки провести небольшой тест, создаем определенное количество объектов, в си, и дот нете, и считаем время какое ушло на создание — очистку ссылок. Ок Там и посмотри что тузик, а что грелка ..
Я писал такой тест в этой теме, смотри выше, C++ слил в 3-6 раз. Это без шаред птр
А потом прибежали другие и начали рассказывать что они динамическую память не выделяют и создают все на стеке

O>>>ты совсем ляпнулся или как ? Код по работе из менеджед с МАПИ? (даже не пытайся, по твоим суждения видно что ты не доганяешь принципиальной разницы диспатч саппортинга )
G>>А нахрен он нужен в .NET?
O> Знаешь на скольких проектах хотели бы считать так-же как и ты? И не только про мапи, а про весь ком без поддержки диспатча (т.е. те ком объекты которые в принципе не могут использоваться в нете, уже бы пора тебе заметить мой намек)
Ответь на вопрос, нафига MAPI в .NET?

G>>То что ты считаеь крутостью является на самом деле ненужной шелухой.
O> да хватит, я уже понял. Ну не беда, это сейчас, пару раз столкнешься с необходмостью эту "шелуху" просаппортить в нет, и понимание придет.

Она там не нужна, чем больше ты хочешь заниматься ковырянием в реализации, тем больнее .NET тебя будет бить за это по ркуам.

G>>Да нахрен не нужен MAPI, .NET и без него почту слать умеет.
O>Это какую если не секрет
Электронную

O>>>с возможностью биндить как аргументы, так и владельцев
G>>А в чем крутость если тоже самое достигается передачей объекта как параметра?
O> Я же говорю нет — расхолаживает
Ответь на вопрос, в чем крутость такого биндинга, если тоже самое делается передачей параметром?

G>>>>Если каждый начнет "имплементить реализации" (шибанутое словосочетание) модифицирющие синтаксис, то будет попа. Код станет абсолютно нечитаемым.
O>>> на этой попе, простите, сидит весь NET
G>>Примеры покажешь как весь .NET сидит на модификации синтаксиса?
O>Как только ты покажешь мне возможность работы с комом без диспатч, так и сразу
С комом без IDispatch нормально все работает. Берешь Tlbimp, натравливаешь его на idl, получешь interop assembly, дальше работаешь как с обычными классами в .NET.
Если нужен IDispatch, то тогда лучше на VB это писать.

O>>>>> Ком нужен для определенной специфики, чтобы мегатяжелые менеджед грабли таки могли получить быстро работающий код, или код, который может дернуть то, чего ну никак не дернуть из менеджед , или просто попытаться избавить себя от гемороя мегатомных импортов. А для реализации прослоек используется менеджед си.
G>>>>Это ты сам себе придумал? Из C# отлично дергаются нативные методы, да нужны они очень редко, а работа с комом происходит гораздо проще.
O>>>Опять смешишь тапочки, ? создай в шарпе натив экземпляр и вызови от него метод.
G>>Натив экземпляр чего?
O> экземпляр анменеджед объекта, — еще одну (хоть какую-то, кривую, не кривую, любую иллюстрацию)
Какого анменеджед объекта? Нету анменеджед объектов.
Возьми DLL, скомпилированную Intel C++ Compiler и напиши в visual studio код, который создает объект из этой либы — придет понимание.

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

ГВ>>>OK, теперь давай выясним, что такое "красиво". Желательный интерфейс набросаешь кратенько?
G>>Угу. Есть метод Register, который заносит в контейнер пару (тип интерфейса, тип реализации), и метод Resolve, который по заданному типу интерфейса выдает объект нужного типа реализации.
G>>Когда получится можно сделать так чтобы если тип реализации имеет конструктор с параметрами, то при создании объекта в параметры конструктора подсчтавлялись бы объекты полученные через Resolve.

ГВ>OK, сегодня-завтра набросаю. В принципе, сразу можно сказать, что вот такой примерно интерфейс вполне достижим:

ГВ>

ГВ>class IoC_Container
ГВ>{
ГВ>  public:
ГВ>    template<typename I_, typename T_>
ГВ>      void Register(){...}

ГВ>    template<typename I_>
ГВ>      I_ *Resolve(){...}
ГВ>};
ГВ>

Регистрация производится обычно строкой в конфигурационном файле и ее можно менять "на лету". IoC контейнеры спокойно конструируют целое дерево объектов по интерфейсам:

IoC.Resolve<ISomeType>();

где ISomeType это SomeType с конструктором SomeType(ISomeOtherType someOther)
где ISomeOtherType это SomeOtherType с конструктором SomeOtherType(IAnotherType another, IAnotherOtherType anotherOther)
где ...

Будет очень интересно посмотреть как Вы это реализуете на С++. Можно даже без конфигурационного файла — так и быть, но должна быть возможность подгрузки имплементации из библиотек (dll, можно COM, если осилите.



Еще интересно было бы увидеть что-то вроде RhinoMocks — библиотеки для мокинга объектов (свойства, методы, события).
И желательно, чтоб код самих тестов получался не хуже по читабельности и лаконичности. Примеры с кодом тут: http://ayende.com/Blog/archive/2008/06/13/The-test-of-fire-Rhino-Mocks-3.5-in-the-real.aspx


ГВ>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил.
Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.

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

Я уже много лет как ушел с С++, и как же я рад этому... Глядя на ЭТО понимаю на сколько правильным оказался мой выбор.

O>task<_1call, task<_2call > > t (bind(&_1call::m<dyadya_vasya>), task<_2call, task<_3call >... >... );

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

O>Сравнивать же менеджед и анменеджед — изначально бредово, т.к. если идет сравнение возможностей, то последние молчат при необходимости работы с МАПИ и библиотеками с ансаппортным диспатч и т.д.
Ну пишите простую COM обертку в качестве медиатора на С++. Делов-то.

O>>>биндинг в плюсах покрывает делегаты, а вот обратного нет, т.к. теже функторы это лишь одно из множества, и не потому, что не хватает, а потому, что еще и так можно.
G>>Это о чем? Какие делегаты, биндинг, функторы? Вывалил все умные словка, которые знаешь?
O> А ты подумай немного, ..как реализовывать late fastening в дотнете ? Когда конструирование аргументов, владельцев методов, и создание каскада вызовов разведено во времени? — никак. а через поздний биндинг это решается.
late fastening это что? late binding?
http://www.codeguru.com/csharp/csharp/cs_syntax/reflection/article.php/c5881 ну вот Вам late binding на .NET. Делается на порядок проще, лаконичнее и читабельнее, чем на С++.

O>>>а при писанине на дотнете после плюсов всегда чувствуешь тормоза, и ограниченность,
G>>
G>>Особенно тормоза
Я правильно понял: Вы осознали свою ограниченность и свои тормоза, перейдя с С++ на дотнет? Так это естественно. Чему тут удивляться?

O> ах в бууст даже запятую перегрузили .. ты меня реально утомил. Плюсы на столько гибкий язык, что позволяет имлементить реализации модифицирующие синтаксис, да еще и чик __asm и ты уже там . А тебя это раздражает Да

С++ позволяет имлементить. Это хорошо сказанно. Запишу себе на память цитату, коли Вы не против...

O> опять за рыбу деньги, — фреймворк внесенный в стандарт становится частью языка.
Глупость.

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


O>>>>> Кроме того, на плюсах вполне реализуемы элементы не родственных стурктур, к примеру итерации for_each, find_if count_if, функторы, придают плюсам оттенки функциональных языков
G>>>>ржунимагу. шаблоны позволяют сделать то что уже есть в других языках
O> ну посмейся, может в процессе придет понимание того, что в с++ есть возможность сделать то, чего нет в других языках,
окончу мысль: ...чего нет в других языках и не надо

Вы кроме Александреску вообще что-то читали? А реальным программированием занимались?

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

C>Регистрация производится обычно строкой в конфигурационном файле и ее можно менять "на лету". IoC контейнеры спокойно конструируют целое дерево объектов по интерфейсам:

C>IoC.Resolve<ISomeType>();

C>где ISomeType это SomeType с конструктором SomeType(ISomeOtherType someOther)
C>где ISomeOtherType это SomeOtherType с конструктором SomeOtherType(IAnotherType another, IAnotherOtherType anotherOther)
C>где ...

Хм. В принципе, приблизительно так тоже можно. Некоторые сложности с правильной регистрацией. Мне интересно, как разрешается ситуация, если SomeType содержит конструкторы вроде таких: SomeType(int, string, ISomeOtherType) и SomeType(ISomeOtherType)?

C>Будет очень интересно посмотреть как Вы это реализуете на С++. Можно даже без конфигурационного файла — так и быть, но должна быть возможность подгрузки имплементации из библиотек (dll, можно COM, если осилите.

А .Net переписать не надо по ходу дела?

C>Еще интересно было бы увидеть что-то вроде RhinoMocks — библиотеки для мокинга объектов (свойства, методы, события).
C>И желательно, чтоб код самих тестов получался не хуже по читабельности и лаконичности. Примеры с кодом тут: http://ayende.com/Blog/archive/2008/06/13/The-test-of-fire-Rhino-Mocks-3.5-in-the-real.aspx

Ну что ж, посмотрим...

ГВ>>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил.
C>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.

Он и на C++ реализуется примерно за то же время. Надо только подождать, чтобы требований накидали.

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

C>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
http://code.google.com/p/pococapsule/
с использованием етой библиотеки реализуется минут за 5-10 опытными программистами на C++

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


C>>Регистрация производится обычно строкой в конфигурационном файле и ее можно менять "на лету". IoC контейнеры спокойно конструируют целое дерево объектов по интерфейсам:

C>>IoC.Resolve<ISomeType>();

C>>где ISomeType это SomeType с конструктором SomeType(ISomeOtherType someOther)
C>>где ISomeOtherType это SomeOtherType с конструктором SomeOtherType(IAnotherType another, IAnotherOtherType anotherOther)
C>>где ...

ГВ>Хм. В принципе, приблизительно так тоже можно. Некоторые сложности с правильной регистрацией. Мне интересно, как разрешается ситуация, если SomeType содержит конструкторы вроде таких: SomeType(int, string, ISomeOtherType) и SomeType(ISomeOtherType)?
Выбирается самый длинный подходящий. То есть если IoC`ку указали значения для аргументов int и string, то сконструирует по первому.

C>>Будет очень интересно посмотреть как Вы это реализуете на С++. Можно даже без конфигурационного файла — так и быть, но должна быть возможность подгрузки имплементации из библиотек (dll, можно COM, если осилите.

ГВ>А .Net переписать не надо по ходу дела?

Так ведь тут нам с пеной у рта доказывают, что на С++ все просто чудесно в плане алгоритмизации. В чем проблема-то? А ведь это далеко не все, что позволяют IoC в дотнет. Например, Castle Windsor, Unity, Spring.NET и другие предоставляют до купы мощный механизм AoP (интерцепторы) — путем генерирования прокси-классов на лету...

ГВ>>>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил.
C>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.

ГВ>Он и на C++ реализуется примерно за то же время. Надо только подождать, чтобы требований накидали.
Ну Вы сделайте для начала то, что уже Вам накидали. Если сделаете — съем свою шляпу, чесслово.

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

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

C>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
Х>http://code.google.com/p/pococapsule/
Х>с использованием етой библиотеки реализуется минут за 5-10 опытными программистами на C++
Вы ведь опытный программист, да? Реализацию в студию.

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

C>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
Х>http://code.google.com/p/pococapsule/
Х>с использованием етой библиотеки реализуется минут за 5-10 опытными программистами на C++

Хех. Оно там уже реализовано. Интересно поиграться "с нуля".

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

Х>>с использованием етой библиотеки реализуется минут за 5-10 опытными программистами на C++
C>Вы ведь опытный программист, да? Реализацию в студию.
реализацию чего? пока по вашим постам я только понял что вы хотите что-то вроде service locator'а, а не IoC контейнера. Лучше опишите задачу, как вы её решаете с помощью вашего фреймворка, и посмотрим что в етом случае делают в С++.

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

ГВ>>Ты уверен, что апелляция к "индусам" в этом контексте выглядит позитивно?

C>Нет, но зато реалистично. Индусы — вездесущи. ;(

Ты называешь шарп языком для индусов ? ну ты счас тут отгребешь ...

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

ГВ>>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил.
G>Удачи.

Посмотри в этот архив. Это я набросал за сегодня. Внешнего конфигурирования, разумеется, нет, но и буст тоже не используется: его не все любят, а для иллюстрации идеи, ИМХО, этого достаточно.

Собирается VS2K5, там собственно IoC.h и IoC_COM.h — реализация контейнера, остальное тесты и примочки. Дальше см. комментарии, если что не понятно — спрашивай здесь.

Для справки: ушло на это всё где-то около 3-х часов чистого времени.

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

C>Ну Вы сделайте для начала то, что уже Вам накидали.

Сабж

Автор: Геннадий Васильев
Дата: 26.04.09

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

ГВ>>>Ты уверен, что апелляция к "индусам" в этом контексте выглядит позитивно?
C>>Нет, но зато реалистично. Индусы — вездесущи. ;(
M>Ты называешь шарп языком для индусов ? ну ты счас тут отгребешь ...

Где? На 25-м уровне вложенности ветки из 900 сообщений, расположенной в КСВ? Отгрести? Только если очень напрашиваться!