Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>Одна из самых сложных вещей в программировании -- делать именно то, что нужно заказчику. А логика в этом деле далеко не помошник.
AF>Логика — отличный помощник, чтобы подумать и за себя, и за тупого заказчика. Главное, не забыть взять за это деньги.
Ладно бы вы меня тупым считали, я уже привык, это даже выгодно.
Но если вы и своих заказчиков тупыми считаете... А ведь это люди, которые смогли своим умом заработать деньги на многое, в том числе, чтобы и заказать у вас ПО.
Проблема с заказчиками в том, что они хотят настолько много всего, что не знают точно, что именно они хотят в первую очередь (ну кроме "чтобы все работало").
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei F., Вы писали:
AF>Это один-единственный сценарий интеропа, в котором C++/CLI предлагает примерно такое же плохое решение, как и D. Что может доказать одно исключение? Ничего.
Для вас это исключение, для меня такие сценарии -- это повседневная реальность.
AF>Если ты хочешь реально что-то доказать — приведи список наиболее типичных задач, которые решаются интеропом
С удовольствием посмотрел бы на ваш вариант этого списка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ладно бы вы меня тупым считали, я уже привык, это даже выгодно.
Ну я бы так не сказал. Скорее — яркий представитель ультра-консервативного течения среди девелоперов.
E>Но если вы и своих заказчиков тупыми считаете... А ведь это люди, которые смогли своим умом заработать деньги на многое, в том числе, чтобы и заказать у вас ПО.
Далеко не все заказчики тупые. Но те, которые не могут внятно объяснить, чего они хотят — точно тупые.
И кто сказал, что они заработали деньги "своим умом"? Кто-то родился у богатых родителей, кто-то в богатой стране, кто-то просто хорошо умеет задницы лизать... э, пардон, имеет большие навыки в области дипломатии.
Те, кто добились всего своим умом — они как раз четко знают, чего хотят и в каком порядке.
Здравствуйте, eao197, Вы писали:
E>С удовольствием посмотрел бы на ваш вариант этого списка.
Для меня основная задача интеропа — возможность вызывать legacy-код из моего кода. В C++/CLI эта задача решена хорошо. Таким образом, по этому пункту — серьезное преимущество у C++/CLI, а по обратной задаче (вызов нового кода из legacy-кода) мы имеем паритет.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>С удовольствием посмотрел бы на ваш вариант этого списка.
AF>Для меня основная задача интеропа — возможность вызывать legacy-код из моего кода. В C++/CLI эта задача решена хорошо. Таким образом, по этому пункту — серьезное преимущество у C++/CLI, а по обратной задаче (вызов нового кода из legacy-кода) мы имеем паритет.
Выделенное является слишком расплывчатой формулировкой.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>С удовольствием посмотрел бы на ваш вариант этого списка.
AF>Для меня основная задача интеропа — возможность вызывать legacy-код из моего кода. В C++/CLI эта задача решена хорошо. Таким образом, по этому пункту — серьезное преимущество у C++/CLI, а по обратной задаче (вызов нового кода из legacy-кода) мы имеем паритет.
Кстати, связка С++ + Python (при помощи Boost.Python) работает весьма хорошо в обе стороны, если не касаться шаблонов, естественно (ибо их не существует в рантайме). Т.е. нет проблем нагенерить иерархий классов С++, потом продолжить эти иерархии классами в Python, и затем звать их друг из друга почти как угодно (т.е. без извратов типа сравнения typeid) и в Питоне, и в С++ (и даже пробрасывать исключения, представляющие классы в Питоне, из одного питовского класса в другой, при том что оба отнаследованы от сишных классов)
Здравствуйте, VladD2, Вы писали:
ANS>>Тебе кучу раз приводили continuation-сервера. Ну, не делается оно полноценно на фиберах.
VD>Что не делается? Только без мозго...ства. Кокретный простой пример... и плиз чтобы он не был ради себя самого.
Судя по смайлику, пример не последует. Так и запишем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ANS>>>Тебе кучу раз приводили continuation-сервера. Ну, не делается оно полноценно на фиберах.
VD>>Что не делается? Только без мозго...ства. Кокретный простой пример... и плиз чтобы он не был ради себя самого.
VD>Судя по смайлику, пример не последует. Так и запишем.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>Выделенное является слишком расплывчатой формулировкой.
AF>Если тебе не нравится моя формулировка — предлагай свою.
Дело не в формулировках, дело в конкретных примерах. Вызов методов crypto++ из D это одно, использование ACE_Reactor -- другое, а размещение на формочке в VB ActiveX элемента -- третье. Хотя везде legacy-код и везде интероперабильность. Так что примеры хотелось бы услышать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Eiffel же стоит столько, что в бывшем Союзе мало кто может себе его позволить использовать в разработках. Так что же ты хотел на русскоязычном форуме?
VD>Ага. За Студию по $10 000 на одно раб.место платят, а Эйфиль позволить не моут. Слишком крут видмо он.
Ах да, я забыл. Ведь все разработчики учавствуют в проектах со сметой от $10M, работают на VS за $10K и получают от $5K в месяц. Совсем из головы вылетело.
E>>Я задавал вопросы по Eiffel здесь: eiffel_software -- отвечали достаточно грамотно и оперативно. Хотя и фанатики типа тебя, там так же встречались.
VD>Ты меня путашь с кем-то. Я реалист. А вот ты сказочник. Даже не сказочник, а сказочный герой. Придумал себе мир и недоволен, что другие в него не верят.
Ну да я понял. Проекты объемом в 2M строк и продажами в десятки тысяч копий для Nemerle не нужны. Ну вообще. Масштаб не тот. Мировым господством не пахнет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>2)Эта штука будет различать static и instance методы? WH>3)А можно таки посмотреть на этот самый шаблон memoize?
Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать):
import std.stdio;
R delegate(U) memoize(R, U...)( R function(U) gd )
{
struct Key {
U m_u;
}
static R[Key] memory;
R inner( U u )
{
Key k;
foreach( i, a; u )
k.m_u[ i ] = u[ i ];
R * p = (k in memory);
if( p !is null )
return *p;
else
{
R r = gd(u);
memory[ k ] = r;
return r;
}
}
return &inner;
}
int sum( int a, int b )
{
writefln( "a=", a, ",b=", b );
return a + b;
}
void main()
{
auto m = memoize( &sum );
writefln( m( 1, 2 ) );
writefln( m( 1, 2 ) );
writefln( m( 3, 2 ) );
writefln( m( 2, 1 ) );
writefln( m( 2, 1 ) );
writefln( m( 1, 2 ) );
writefln( m( 3, 2 ) );
}
При запуске выдает:
a=1,b=2
3
3
a=3,b=2
5
a=2,b=1
3
3
3
5
Небольшие замечания по коду:
— static memory объявлено только для простоты. По хорошему надо бы иметь асоциативный вектор созданных делегатов, в котором ключем будет аргумент dg. Ну и защитить его семафором для поддержки многопоточности;
— корявый код с использованием структуры Key и foreach-а для заполнения объекта k нужен из-за особенностей реализации D-шных туплов. Объявить тупл в качестве типа ключа в ассоциативном массиве в D можно, а вот задействовать реально его в качестве ключа у меня не получилось. Тут либо я идиот, либо действительно лыжи не едут;
— ну и, наверное, потребуется продублировать вариант memoize для случая, когда dg является не функцией, а делегатом. Но здесь, возможно, дублирование можно будет сделать через mixin-ы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать): Надеюсь ты сам понимаешь насколько это решение ущербно по сравнению с оригинальным макросом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, eao197, Вы писали:
E>>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать): WH> Надеюсь ты сам понимаешь насколько это решение ущербно по сравнению с оригинальным макросом.
А где ты видел решение? Это просто доказательство того, что memoize на D2.0 сделать можно. Более того, и решение твоей задачки 192 с его помощью получится.
Так что, принципиальная возможность есть, а дальше, если кому-то понадобиться, можно доводить до ума. Ты же так про DesignByContract в Nemerle говорил (возвращаясь к контрактам -- вряд ли Nemerle их в нормальном виде получит когда-нибудь).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>- static memory объявлено только для простоты. По хорошему надо бы иметь асоциативный вектор созданных делегатов, в котором ключем будет аргумент dg. Ну и защитить его семафором для поддержки многопоточности;
Так убери статик, замыкания же теперь нормально подерживаются
E>- корявый код с использованием структуры Key и foreach-а для заполнения объекта k нужен из-за особенностей реализации D-шных туплов. Объявить тупл в качестве типа ключа в ассоциативном массиве в D можно, а вот задействовать реально его в качестве ключа у меня не получилось. Тут либо я идиот, либо действительно лыжи не едут;
Угу, туплы корявы и слабоваты, их лучше бы на уровне языка подержать, а ни как сейчас, плюс добавить легкое получение аргументов функций в виде тупла.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, eao197, Вы писали:
E>>- static memory объявлено только для простоты. По хорошему надо бы иметь асоциативный вектор созданных делегатов, в котором ключем будет аргумент dg. Ну и защитить его семафором для поддержки многопоточности;
FR>Так убери статик, замыкания же теперь нормально подерживаются
А ведь точно! Спасибо,
E>>- корявый код с использованием структуры Key и foreach-а для заполнения объекта k нужен из-за особенностей реализации D-шных туплов. Объявить тупл в качестве типа ключа в ассоциативном массиве в D можно, а вот задействовать реально его в качестве ключа у меня не получилось. Тут либо я идиот, либо действительно лыжи не едут;
FR>Угу, туплы корявы и слабоваты, их лучше бы на уровне языка подержать, а ни как сейчас, плюс добавить легкое получение аргументов функций в виде тупла.
Так легкое получение аргументо в виде тупла и сейчас есть в шаблонах. Или ты о другом?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
FR>>Угу, туплы корявы и слабоваты, их лучше бы на уровне языка подержать, а ни как сейчас, плюс добавить легкое получение аргументов функций в виде тупла.
E>Так легкое получение аргументо в виде тупла и сейчас есть в шаблонах. Или ты о другом?
Было бы удобно если бы каждая функция имела неявную переменную arguments в виде тупла (примерно как в функциях с переменным числом аргументов).
Здравствуйте, eao197, Вы писали:
E>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать):
Здравствуйте, WolfHound, Вы писали:
E>>Вот, надоело сегодня целый день документацию писать, решил душу отвести. В самом примитивном виде memoize на D2.0 выглядит так (наверное, что-то похожее можно и на D1.0 сделать): WH> Надеюсь ты сам понимаешь насколько это решение ущербно по сравнению с оригинальным макросом.
Кстати Немерлевсий макрос тоже коряв по сравнению с реализацией того же memoize на питоне например.
Но похоже для статически типизированного языка (правда не уверен насчет хаскеля) такое и вправду только на макросах можно соорудить. Кстати на D тоже это возможно, на текстовых миксинах которые по сути тоже макросы.
Здравствуйте, eao197, Вы писали:
E>Дело не в формулировках, дело в конкретных примерах. Вызов методов crypto++ из D это одно, использование ACE_Reactor -- другое, а размещение на формочке в VB ActiveX элемента -- третье. Хотя везде legacy-код и везде интероперабильность. Так что примеры хотелось бы услышать.
Конкретные примеры есть в MSDN, с подробным описанием что можно сделать и как. Что еще нужно?
Надеюсь ты сам понимаешь насколько это решение ущербно по сравнению с оригинальным макросом.
В общем нужно копать в сторону виртуальных функций http://gzip.rsdn.ru/Forum/Message.aspx?mid=2831064&only=1