Здравствуйте, WolfHound, Вы писали: WH>Ну пусть Рихтер покажет как совместить call/cc и любой вид детерминированной финализации.
Я не уверен, что прямо таки call/cc, но вот совместить асинхронный ввод-вывод Рихтеру вполне удается: http://msdn.microsoft.com/ru-ru/magazine/cc546608.aspx WH>А я посмеюсь...
Давай уж вместе
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Ну пусть Рихтер покажет как совместить call/cc и любой вид детерминированной финализации. S>Я не уверен, что прямо таки call/cc, но вот совместить асинхронный ввод-вывод Рихтеру вполне удается: S>http://msdn.microsoft.com/ru-ru/magazine/cc546608.aspx
Это корутины.
Частный случай реализуемый через континюэйшены.
Вобще через континюэйшены можно реализовать любую конструкцию передачи управления. Корутины, исключения....
Но в общем случае континюэйшены несовместимы с детерминированной финализацией.
ЗЫ Больше не давай ссылки на русский перевод.
ЗЗЫ А вобще асинхронный ввод-вывод сам по себе тот еще костыль. Он нужен чисто из-за того что в классических ОС потоки очень тяжолые.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Это корутины. WH>Частный случай реализуемый через континюэйшены.
Ну, а если подумать — чем он так радикально отличается от континьюэйшнов? Ведь у нас фактически начало try выполняется в одном контексте, а finally — в другом. Тем не менее, все гарантии нам предоставлены. Просто совершенно случайно "красивый" синтаксис детерминистической финализации в шарпе оказался совместимым с корутинами. Компилятор делает уличную магию, скукоживая красивый код в стейт машину. В итоге, закрытие блока using (а точнее, того, что выглядит как блок using) происходит совсем в другом блоке finally, чем в "прямолинейном" случае. WH>Но в общем случае континюэйшены несовместимы с детерминированной финализацией.
Почему нельзя добиться того же для continuation? WH>ЗЫ Больше не давай ссылки на русский перевод.
ну я полагал, что любой RSDNщик способен заменить ru-ru на en-us в урле, если не доверяет переводам не от Гоблина. WH>ЗЗЫ А вобще асинхронный ввод-вывод сам по себе тот еще костыль. Он нужен чисто из-за того что в классических ОС потоки очень тяжолые.
Это-то понятно. Но на тех же примитивах строят и просто параллельные алгоритмы, навроде PLinq, где смысл уже не сводится к экономии системных потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Это корутины. WH>>Частный случай реализуемый через континюэйшены. S>Ну, а если подумать — чем он так радикально отличается от континьюэйшнов?
Да вот отличается.
На корутинах ты вот это не сделаешь:
(define theContinuation #f)
(define (test)
(let ((i 0))
; call/cc calls its first function argument, passing
; a continuation variable representing this point in
; the program as the argument to that function.
;
; In this case, the function argument assigns that
; continuation to the variable theContinuation.
;
(call/cc (lambda (k) (set! theContinuation k)))
;
; The next time theContinuation is called, we start here.
(set! i (+ i 1))
i))
> (test)
1
> (theContinuation)
2
> (theContinuation)
3
> (define anotherContinuation theContinuation)
> (test)
1
> (theContinuation)
2
> (anotherContinuation)
4
S>Ведь у нас фактически начало try выполняется в одном контексте, а finally — в другом. Тем не менее, все гарантии нам предоставлены.
Ты гдето запутался.
Не стоит смотреть на то как это реализовано.
Нужно смотреть в корень.
По факту yield просто прерывает поток исполнения после чего можно продолжить с этого места ровно один раз.
В случае с континюэйшеном продолжать можно много раз.
S>Просто совершенно случайно "красивый" синтаксис детерминистической финализации в шарпе оказался совместимым с корутинами.
Не случайно.
Вот тебе простейший код:
Если выделеное условие выполняется то его семантика проста и понятна.
А если нет?
Если yield return может несколько раз вернуть управление?
В каком состоянии будет файл во второй раз?
И ровно эта же проблема будет при любой модели детерминированой финализации.
Ибо смысл детерминированной финализации в том чтобы прибить объект в строго определенной точке кода.
А континюэйшены позволяют попасть в эту точку больше одного раза.
Корутины этой проблемой не страдают. Ибо они по факту просто кооперативная многозадачность.
S>ну я полагал, что любой RSDNщик способен заменить ru-ru на en-us в урле, если не доверяет переводам не от Гоблина.
Да я и заменил.
Просто не сразу догадался.
Ну не часто я бываю на MSDN.
Делать мне там особо нечего...
S>Это-то понятно. Но на тех же примитивах строят и просто параллельные алгоритмы, навроде PLinq, где смысл уже не сводится к экономии системных потоков.
Ну и PLink можно построить на чем угодно...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, DOOM, Вы писали:
C>>>Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути. DOO>>Я имел ввиду, что не сам gcc — как компилятор C++ так делает, а была какая-то отдельная программка (я ее ни разу не смотрел в работе), которая именно переводила C++ в С путем препроцессинга. Вроде она до сих пор имеется в пакете gcc — надо бы поискать. C>Да, была — сfront (на ней ещё куча компиляторов было основано). Но С++98 уже не осиливала.
Разрабатывая Си с классами (позднее Си++), Страуструп также написал программу Cfront, транслятор, перерабатывающий исходный код Си с классами в исходный код простого Си. Новый язык, неожиданно для автора, приобрёл большую популярность среди коллег и вскоре Страуструп уже не мог лично поддерживать его, отвечая на тысячи вопросов.
В 1983 г. произошло переименование языка из Си с классами в Си++ по соображениям маркетинга
интервью с ведущим разработчиком Microsoft — Андерсом Хейлсбергом (Anders Hejlsberg)
В июле, редактор O`Reilly Джон Осборн посетил конференцию профессиональных разработчиков Microsoft, где взял интервью у Андерса Хейлсберга, выдающегося специалиста и ведущего разработчика C#, о платформе Microsoft .NET и языке программирования C#. Андерс Хейлсберг известен как человек, который разрабатывал Turbo Pascal, один из первых языков доступных на PC. Андерс лицензировал Turbo Pascal корпорации Borland и впоследствии возглавил команду, создавшую Delphi, действительно удачное визуальное средство разработки клиент-серверных приложений. Также в интервью принимали участие Тони Гудхью (Tony Goodhew) — Microsoft менеджер C#, и редактор раздела Windows в O`Reilly — Рон Петруша (Ron Petrusha).
Здравствуйте, gandjustas, Вы писали:
G>Класс TThread.
1)Не позволяет узнать завершился ли поток — надо использовать WinAPI.
...execute
begin
try
...
finally
// поток завершился
end
end;
2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал.
В смысле?
TMyThread = class(Thread)
в чём отличие от остальных классов?
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Здравствуйте, siberia2, Вы писали:
DR>>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ.
S>А тот же увалень на C++ сразу пишет высококачественный код. Или ему платят жалование лет 5, но выхода не требуют?
Минимальный "Привет Мир!" на MFC будет нормальной программой. На Дельфи он будет показывать вопросительные знаки в нерусифицированном Windows. Программы на Дельфи сломаны по умолчанию и нужно хорошо разбираться в нём, чтобы обходить грабли даже в простейших проектах.
И че вам так хочется пободаться...
G>>невозможно указать типа указателя в месте использования. S>В смысле? Приведение типа не работает?
В смысле нельзя написать (по крайней мере в 7 версии)
(byte^)(<выражение>)
G>>Класс TThread. S>1)Не позволяет узнать завершился ли поток — надо использовать WinAPI.
S>...execute S>begin S> try S> ... S> finally S> // поток завершился S> end S>end;
А вызывающий код как узнает?
Также куча проблем возникает из за втойства FreeOnTerminate
S>2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал. S>В смысле? S>TMyThread = class(Thread) S>в чём отличие от остальных классов?
В смысле до многих не сразу доходит в каком потоке вызывается какой код.
За месяц работы дважды отлавливал баги с неправильным вызовом методов UI из других потоков.
Прежде чем спорить стоит изучить не только делфи, но и другие языки/технологии.