Здравствуйте, Disappear, Вы писали:
D> Понятно конечно, что можно снова городить кучу dummy классов, но более человечнее будет выглядеть код на языке с поддержкой finally.
Пиши на BCB — там finally есть
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Disappear, Вы писали:
D>Здравствуйте, Mirrorer, Вы писали:
M>>Здравствуйте, Disappear, Вы писали:
M>>Теперь берем те же программу, переносим на Pentium IV. M>>Внимание вопрос. Сможет ли с++ программа скомпилированная под 486 использовать фишки четвертого пня для ускорения работы ? M>>А та же дотнетовская программа сможет. Потому что JIT сгенерирует native код для той платформы на которой он будет выполнятся.
И к тому же в догонку. Разве кто-то мешает отдельно скомпилировать программу для 586, x64 и во все что угодно, что компилятор позволяет...
Тут получается вопрос только в развертывании приложения, не более того.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.
Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста. M>Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.
Windows — это очень узкий круг вычислительных устройств.
Здравствуйте, Mirrorer, Вы писали:
ДГ>>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста. M>Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.
Хм. Означает ли это, что вне пределов .NET для Nemerle нет никакой перспективы?
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Disappear, Вы писали:
D>>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ? D>>Разве мы не заслужили
M>А от нас что-то зависит? Оно то может и пора, но пока непонятно, за счет чего может осуществится такой переход. Финансовых магнатов за этим языком не M>наблюдается. Весомых козырей тоже нет. Удобство при проектировании и разработке в общем-то фоска, так как проще обходить старые грабли, чем решать с M>нуля нетривиальное бизнес-требование, такое как GUI,
GUI библиотеки есть на D. Например DFL http://www.dprogramming.com/dfl.php
M>кроссплатворменность, работа с БД, работа с COM, распределенное приложение, и т. д. Для примера, насколько просто написать на D элементарное M>приложение с использованием, например, библиотеки wxWidgets?
Существует мост также и для wxWidgets http://wxd.sourceforge.net/
M>Что-то мне кажется, что на этом пути можно встретить очень много проблем, начиная прямо
Безусловно, но это только в начале пути. Главное чтобы эти проблемы не происходили на всем пути.
M>от макросов DECLARE_CCLASS, IMPLEMENT_CCLASS, BEGIN_EVENT_TABLE. Думаю, что тривиальным фасадом тут обойтись будет проблематично.А как дела обстоят с M>использованием STL? Остается надежда на энтузиастов,
Практика программирования уже успела многое сказать о пригодности интерфейса STL Включать что-то подобное в D, мне кажется, не было смысла.
А такие же инструменты, и даже более расширенных их набор в D есть.
M>большей частью студентов, которым еще предстоит создать средства для этого. Но... что-то мне M>кажется, что сейчас студенты больше интересуются не тем, чтобы самому реализовывать свою можель велосипедае (иногда более совершенную, иногда менее), M>а тем, чтобы осваивать коммерчески успешные продукты, которые впоследтвие предоставят им возможность заработать больше денег.
Среди людей иногда попадаются энтузиасты. В том числе среди студентов.
Здравствуйте, Disappear, Вы писали:
D>Windows — это очень узкий круг вычислительных устройств.
Вообще я отвечал на один конкретный пункт — относительно интероперабельности между шарпом и немерле. Но тем не менее отвечу.
Есть еще Mono для Linux. Собственно под ним и ведется основная разработка Nemerle, насколько я знаю. Да, Моно это не совсем .Net, у него есть свои ограничения.
Но тем не менее он есть. И Немерле на нем работает. Я ответил на вопрос ?
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, Disappear, Вы писали:
D>Пока на тестах никто нам не смог показать что такие программы работают действительно быстрее. Причем именно работают быстрее, а не вычисляют факториал быстрее или выделяют миллион однобайтовых сегментов на хипе быстрее...
Ок. Давай сделаем так. Ты приводишь пример теста, который тебя удовлетворит, методику тестирования, критерии приемки, реализацию на с++. А со своей стороны обещаю сделать реализацию под .NET. И поглядим.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>1. Что слышно насчет реализаций под линукс, и/или свободных реализаций? Когда ожидать?
Вообще то, он изначально разрабатывается под Mono (свободная реализация .net, есть и под Линукс, Винду, МакОС). Существует уже достаточно давно.
ДГ>2. И во что дело упирается — в нормальную VM? Не верю. Что им мешает в натив компилять?
А зачем в натив? Выбор .net вполне разумен, получаем нахаляву всю FCL и все остальные плюсы .net'а.
Если бы в натив компилявили, то все библиотеки пришлось бы писать самим с нуля, бек-енд для кучи разных платформ, а так, только IL.
ДГ>3. Поддержка со стороны IDE, кроме VS + твоей интеграции?
MonoDevelop — кроссплатформенно.
ДГ>4. Вообще, какова текущая ситуация? Что куда компилируется и где это 'куда' может работать?
Насколько мне известно дело уже близится к релизу первой версии.
Все компилириуется в IL.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Disappear, Вы писали:
D>>Windows — это очень узкий круг вычислительных устройств.
... M>Но тем не менее он есть. И Немерле на нем работает. Я ответил на вопрос ?
Думаю да.
Т.е. у нас есть Windows и кусочек Linux, это хорошо.
Здравствуйте, Disappear, Вы писали:
D>Практика программирования уже успела многое сказать о пригодности интерфейса STL
Что именно? Что приходится думать больше чем собственно надо? Зато можно передавать заказчику исходный текст качественно написанной программы не опасаясь, что для сопровождения он наймет кого-нибудь подешевле. И вообще, круто и не для средних умов.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>>>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста. M>>Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.
ДГ>Хм. Означает ли это, что вне пределов .NET для Nemerle нет никакой перспективы?
На текущий момент — да. Теоритически не исключена возможность прикручивания других бэкендов.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Disappear, Вы писали:
D>>Практика программирования уже успела многое сказать о пригодности интерфейса STL
I>Что именно? Что приходится думать больше чем собственно надо? Зато можно передавать заказчику исходный текст качественно написанной программы не опасаясь, что для сопровождения он наймет кого-нибудь подешевле. И вообще, круто и не для средних умов.
Здравствуйте, Disappear, Вы писали:
D>Минусы VM: D>- Это всегда ряд ограничений при сближении с платформой. Все зависит от VM, но в хорошей VM этих ограничений должно быть больше.
Каких например? Это бессмысленный набор слов. D>- Прерывания, порты ввода вывода, управление памятью и другая жизненная реальность — все это скрыто под занавесом виртуальной машины.
Не факт, что это минусы. D>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить.
А можно показать конкретно, какие законы математики обеспечивают медленность VM по сравнению с нативным кодом? Я с такими законами не знаком. D>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.
Как ни странно, большинство С++ программистов, бравировавших при мне своими привычками "ощущать" работу программы, исповедовали богатый набор заблуждений совершенно религиозного характера. Некоторые из них до сих пор оперируют познаниями, которые они получили при дизассемблировании результатов компиляции под 80286. "Ощущение" работы программы — признак хорошего программиста. Оно слабо связано с языком, зато сильно связано с опытом. Можно ощущать работу JVM и NET Runtime не намного хуже, чем работу С++ программы. Можно ощущать работу запроса в MS SQL. Можно ощущать работу x86 кода в современных процессорах Intel. Если, конечно, как следует разобраться в его конвеерах, ядрах и прочих подробностях. Я лично давненько не видал людей, способных, бегло глянув на ASM код, сказать, что там спаривается, а что будет выполняться последовательно.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Disappear, Вы писали:
D>>Минусы VM: D>>- Это всегда ряд ограничений при сближении с платформой. Все зависит от VM, но в хорошей VM этих ограничений должно быть больше. S>Каких например? Это бессмысленный набор слов. D>>- Прерывания, порты ввода вывода, управление памятью и другая жизненная реальность — все это скрыто под занавесом виртуальной машины. S>Не факт, что это минусы.
Это был ответ на предыдущий вопрос. Это недостаток "мощи"
D>>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить. S>А можно показать конкретно, какие законы математики обеспечивают медленность VM по сравнению с нативным кодом? Я с такими законами не знаком.
Xn = Y
Xv = V + Y
Xn != Xv ->
X != V + Y
V > 0 ->
Xn < Xy
Xn — общее время выполнения native приложения
Xv — общее время выполнения managed приложения
Y — время выполнения кода приложения
V — время выполнения функций VM
D>>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.
S>Как ни странно, большинство С++ программистов, бравировавших при мне своими привычками "ощущать" работу программы, исповедовали богатый набор заблуждений совершенно религиозного характера. Некоторые из них до сих пор оперируют познаниями, которые они получили при дизассемблировании результатов компиляции под 80286. "Ощущение" работы программы — признак хорошего программиста. Оно слабо связано с языком, зато сильно связано с опытом. Можно ощущать работу JVM и NET Runtime не намного хуже, чем работу С++ программы. Можно ощущать работу запроса в MS SQL. Можно ощущать работу x86 кода в современных процессорах Intel. Если, конечно, как следует разобраться в его конвеерах, ядрах и прочих подробностях. Я лично давненько не видал людей, способных, бегло глянув на ASM код, сказать, что там спаривается, а что будет выполняться последовательно.
Никие ощущения VM вам не помогут, когда дело дойдет до отладки системных API.
Здравствуйте, Disappear, Вы писали:
D>Здравствуйте, Tilir, Вы писали:
D>
D>template factorial(int n : 1)
D>
Интересный пример. Но задача вычисления факториала может быть решена даже не на C++, а на чистом C и существенно проще. Я просил от вас демонстрацию актуальной задачи, подразумевающей, что на C++ нет решения или оно кривое.
Для того, чтобы вы лучше поняли что я хочу увидеть,я приведу вам "пример наоборот". Всего два коротких куска кода, один из которых активно использует макросы (карты сообщений MFC)
Второй пример — активно использует множественное наследование (фрагмент реального ActiveX-контрола на ATL)
class ATL_NO_VTABLE CExtPanel :
public CComObjectRootEx<CComSingleThreadModel>,
public CStockPropImpl<CExtPanel, IExtPanel>,
public IPersistStreamInitImpl<CExtPanel>,
public IOleControlImpl<CExtPanel>,
public IOleObjectImpl<CExtPanel>,
public IOleInPlaceActiveObjectImpl<CExtPanel>,
public IViewObjectExImpl<CExtPanel>,
public IOleInPlaceObjectWindowlessImpl<CExtPanel>,
public ISupportErrorInfo,
public IConnectionPointContainerImpl<CExtPanel>,
public CProxy_IExtPanelEvents<CExtPanel>,
public IPersistStorageImpl<CExtPanel>,
public ISpecifyPropertyPagesImpl<CExtPanel>,
public IQuickActivateImpl<CExtPanel>,
#ifndef _WIN32_WCE
public IDataObjectImpl<CExtPanel>,
#endif
public IProvideClassInfo2Impl<&CLSID_ExtPanel, &__uuidof(_IExtPanelEvents), &LIBID_AtlPanel3Lib>,
public IPropertyNotifySinkCP<CExtPanel>,
#ifdef _WIN32_WCE // IObjectSafety is required on Windows CE for the control to be loaded correctlypublic IObjectSafetyImpl<CExtPanel, INTERFACESAFE_FOR_UNTRUSTED_CALLER>,
#endif
public CComCoClass<CExtPanel, &CLSID_ExtPanel>,
public CComControl<CExtPanel>
{
...
}
Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?
Здравствуйте, Tilir, Вы писали:
T>Здравствуйте, Disappear, Вы писали:
D>>Здравствуйте, Tilir, Вы писали:
D>>
D>>template factorial(int n : 1)
D>>
T>Интересный пример. Но задача вычисления факториала может быть решена даже не на C++, а на чистом C и существенно проще. Я просил от вас демонстрацию актуальной задачи, подразумевающей, что на C++ нет решения или оно кривое.
T>Для того, чтобы вы лучше поняли что я хочу увидеть,я приведу вам "пример наоборот". Всего два коротких куска кода, один из которых активно использует макросы (карты сообщений MFC)
T>
T>Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?
Вопрос поставлен неправильно. Правильно он звучит так.
Зачем нам такое г@вно на D?
Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.
T>Или вы предлагаете хором перейти на VCL?
Нет, для MFC пожалуй не стоит использовать D.