Здравствуйте, gandjustas, Вы писали:
g> H>Как я уже сказал, для ценителей есть реализации (я бы их использовать не стал, но я не ценитель)
g> Без поддержки языка скорее всего фигня.
Отчего же, делается все то же самое только сторонними средствами.
g> g>> да, только события его ни разу не поддерживают. g> g>> Это должно быть в языке чтобы красиво выглядело и работало, одними библиотеками тут не отделаешься.
g> H>Средства языка позволяют все сделать красиво, уж ты поверь
g> Я писал на делфи, на C#, на F#. С уверенностью могу утверждать что на делфи красиво не выйдет.
Выйдет. Ты судя по всему уже давно не смотрел на дельфю.
g> g>> Кстати как там у лямбд с замыканием на локальные переменные?
g> H>Все в порядке.
g> Конкретнее?
g>
g> Func<int> A(int x)
g> {
g> var y = x*2;
g> Func<int> r = () => y;
g> y++;
g> return r;
g> }
g>
g> Такое можно написать?
Можно.
Function Func(X : Integer) : Integer;
Var
Y : Integer;
R : TFunc<Integer>;
Begin
Y := X * 2;
R := Function : Integer Begin Result := Y; End;
Inc(Y);
Result := R;
End;
WriteLn(Func(2)); // выведет 5
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Это должно быть в языке чтобы красиво выглядело и работало, одними библиотеками тут не отделаешься.
НС>RX демонстрирует, что можно отделаться и библиотеками, причем результат будет даже лучше.
Двойственная ситуация: чем мощнее язык, тем больше можно сделать библиотеками. См хаскелл, там вообще все описывается библиотеками.
Здравствуйте, gandjustas, Вы писали:
G>Ты снова неправ, потому что думаешь "только и всего". С помощью yield return можно делать coroutines, можно писать асинхронный код в линейном виде.
Это как ?
Материал из Википедии — свободной энциклопедии, -_*
-_*>Здравствуйте, gandjustas, Вы писали:
G>>Ты снова неправ, потому что думаешь "только и всего". С помощью yield return можно делать coroutines, можно писать асинхронный код в линейном виде.
-_*>Это как ?
например так:
public static IObservable<Unit> ReadExact(this Stream stream, byte[] buffer, int offset, int count)
{
return Observable.Iterate(() => ReadExactInternal(stream, buffer, offset, count));
}
public static IEnumerable<IObservable<object>> ReadExactInternal(Stream stream, byte[] buffer, int offset, int count)
{
var read = Observable.FromAsyncPattern<byte[], int, int, int>(stream.BeginRead, stream.EndRead);
while(count>0)
{
var result = read(buffer, offset, count).Start();
yield return result; //Вот тут выполнение прервется пока не выполнится асинхронная операция чтения.
count -= result[0];
offset += result[0];
}
}
Здравствуйте, slava_phirsov, Вы писали:
_>Года полтора назад был на собеседовании в одной конторке... Ребята писали (в 2009-м!!!) на D7 (хорошо хоть, не на D5), изобретали библиотеку компонентов GUI Ну, типа, свой свечной заводик... (цитата) "с поддержкой юникода" (и при этом не могли толком объяснить, что же именно они там поддерживают: UTF8? UCS2? Whatever?) А еще в этом GUI была — я не шучу — утиная типизация, основанная на интерфейсах. То есть перед использованием нужно под try/except попытаться привести экземпляр TComponent к ожидаемому интерфейсному типу, и, если получилось — работать с ним, а нет — ну, типа, не судьба. Так что, как у классика
В 2009 юникод вроде как уже из коробки был. А до 2009 (или может 2008 — не помню) были tnt компоненты с поддержкой юникода. Для D7 они вполне подходили. Так что на кой было делать руками — это очень интересный вопрос.
Насчет приведения под try/except — ну есть же сахар в виде as, is — работа с интерфейсами в дельфях вполне удобна, компилер много чего делает сам — подсчет ссылок, QueryInterface, GUID и т.д.
Все это говорит не о проблемах дельфи, а о проблемах в мозгах у ребят
Здравствуйте, gandjustas, Вы писали:
H>>yield'а нет. Видел пару ручных реализаций, но они не для серьезного применения. Да, без него несколько усложняется логика перечислителя, но только и всего. G>Ты снова неправ, потому что думаешь "только и всего". С помощью yield return можно делать coroutines, можно писать асинхронный код в линейном виде.
А кстати, в питоне например yield можно сделать только из самой функции, а вот из функции, которую она вызвала уже нельзя
def f():
yield 1
yield 2
def f2():
f() # так работать не будетyield 3
Если в шарпе тоже так, то с корутинами уже не шибко удобно получается
Здравствуйте, gandjustas, Вы писали:
G>Вот тебе пример для раздумия: поток событий движения мыши, сколько он ресурсов захавает с Rx и сколько с рукопашной реализацией очереди (учитывая что кто-то должен складывать в очередь, а кто-то обрабатывать).
И в чем проблема? Ловим событие мыши, кидаем в очередь, зовем функцию сверки с образцом или серию таких функций. Совпало с чем-то — удаляем совпадение, делаем действие по данному совпадению, продолжаем. Не совпало ни с чем — продолжаем ловить. Не подходит ни под оидн образец — удаляем первый элемент, повторяем проверку.
Можно сделать оптимизацию — сверять не сразу, а через некоторое время после посл события или при достижении некоторого размера.
Написать такую штуку элементарно. Жрать ресурсов будет в зависимости от длины образцов.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Вот тебе пример для раздумия: поток событий движения мыши, сколько он ресурсов захавает с Rx и сколько с рукопашной реализацией очереди (учитывая что кто-то должен складывать в очередь, а кто-то обрабатывать).
E>И в чем проблема? Ловим событие мыши, кидаем в очередь, зовем функцию сверки с образцом или серию таких функций. Совпало с чем-то — удаляем совпадение, делаем действие по данному совпадению, продолжаем. Не совпало ни с чем — продолжаем ловить. Не подходит ни под оидн образец — удаляем первый элемент, повторяем проверку.
Так у тебя все образцы будут в одной функции. Не пойдет.
E>Можно сделать оптимизацию — сверять не сразу, а через некоторое время после посл события или при достижении некоторого размера.
Какого размера?
А если потенциально бесконечные последовательности будут?
Например сначала 1, а потом любое число не равное 1, а событие у тебя одни единицы гонит.
E>Написать такую штуку элементарно. Жрать ресурсов будет в зависимости от длины образцов.
Дьявол в деталях. Когда начнешь более менее универсальный фреймворк писать — увидишь.
Здравствуйте, gandjustas, Вы писали:
E>>До меня все еще никак не дойдет, что такого интересного в этом "фреймворке"? На с++ поверх boost::asio — порядка 800 строк. На с++ поверх аппаратных прерываний — чуток поменьше. На дельфи поверх компонента — тоже ничего сложного нет. Совершенно тупой неинтересный код G>Именно этот кусок меня и интересует.
Ну кидать сюда 800 строк, + чистить их от зависимостей — мне лень, извини. Если интересует все же что-то конкретное, скажи, приведу примеры.
E>>Его задачи E>>- передать байты в порт E>>- принять байты из порта, проконтролировать разные таймауты, в нужные моменты вызвать протокольно-специфичную функцию анализа G>Эти две задачи можно решать настолько разными способами, что можно получить в сотни раз отличающиеся потребления ресурсов компьютеров и человека.
ЧОЧО? Любую задачу можно решить разными путями, но чтобы байты из ком-порта тормознуто читать, эт надо хорошо постараться...
Здравствуйте, gandjustas, Вы писали:
G>>>Вот тебе пример для раздумия: поток событий движения мыши, сколько он ресурсов захавает с Rx и сколько с рукопашной реализацией очереди (учитывая что кто-то должен складывать в очередь, а кто-то обрабатывать).
E>>И в чем проблема? Ловим событие мыши, кидаем в очередь, зовем функцию сверки с образцом или серию таких функций. Совпало с чем-то — удаляем совпадение, делаем действие по данному совпадению, продолжаем. Не совпало ни с чем — продолжаем ловить. Не подходит ни под оидн образец — удаляем первый элемент, повторяем проверку. G>Так у тебя все образцы будут в одной функции. Не пойдет.
Читай внимательней "или серию таких функций"
E>>Можно сделать оптимизацию — сверять не сразу, а через некоторое время после посл события или при достижении некоторого размера. G>Какого размера?
Размер — в зависимости от размеров образцов. Для каждого образца задаем функцию проверки + размер + действие. Фреймворк на основе этой инфы может определить, при каком размере очереди событий чего дергать. Если извернуться, то размер можно явно не задавать, а вычислять динамически на основе тех действий, которые делает функция проверки, но имхо, оно того не стоит.
G>А если потенциально бесконечные последовательности будут? G>Например сначала 1, а потом любое число не равное 1, а событие у тебя одни единицы гонит.
"Не подходит ни под один образец — удаляем первый элемент, повторяем проверку" — поймали две единицы — поняли, что не подходит, убили первую единицу и т.д.
E>>Написать такую штуку элементарно. Жрать ресурсов будет в зависимости от длины образцов. G>Дьявол в деталях. Когда начнешь более менее универсальный фреймворк писать — увидишь.
Ну дык написал его уже. Занимается байтами полученными из разных источников (посл порт, udp\tcp, еще кое-что), на выходе дает пакеты различных протоколов обмена.
Ясно, что написать в общем виде сложнее. Круто, что в Нет это уже есть. Хотя, имхо, довольно специфичная задача — зачем тянуть ее в фреймворк? Распространяли бы отдельными сборками...
Здравствуйте, gandjustas, Вы писали:
HA>>Еще не сдаюсь HA>>Оценка сложности DFS O(N+E), N — число вершин, E — число связей. HA>>E может быть от 0 до O(N^2) HA>>То есть какие-то патологические ситуации все-таки возможны.
G>Еще раз. Все вершины проходятся максимум один раз. G>Количество связей значение не имеет.
Ты серьезно? Придется по разу пройтись по каждому ребру графа. Другое дело, если на конце ребра видим помеченную вершину, то останавливаемся
Здравствуйте, enji, Вы писали:
E>И в чем проблема? Ловим событие мыши, кидаем в очередь, зовем функцию сверки с образцом или серию таких функций. Совпало с чем-то — удаляем совпадение, делаем действие по данному совпадению, продолжаем. Не совпало ни с чем — продолжаем ловить. Не подходит ни под оидн образец — удаляем первый элемент, повторяем проверку.
Это устаревший, низкоуровневый подход. Можно вот так
Серия эвентов преобразуется в последовательность координат. Это + еще кое что есть распознавание мышиных жестов. В нативном подходе, с очередями, совпадениями, надо было писать килобайты ифов, свичей, обработчиков и трястись над различными флагами.
E>Написать такую штуку элементарно. Жрать ресурсов будет в зависимости от длины образцов.
Расширение вроде RX написать на коленке ?
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, enji, Вы писали:
E>>Развитость языка — а какие именно возможности языка были бы полезны в этом случае?
НС>К примеру, для работы с СОМ-портом можно использовать Reactive Framework. В Дельфи аналог есть? Для асинхронности все тот же Rx или PLinq. В Дельфи аналог последнего есть?
Здравствуйте, swame, Вы писали:
НС>>К примеру, для работы с СОМ-портом можно использовать Reactive Framework. В Дельфи аналог есть? Для асинхронности все тот же Rx или PLinq. В Дельфи аналог последнего есть?
S>http://sourceforge.net/projects/tpapro/
Это никакой не аналог RX а просто либа для асинхронщины.
Материал из Википедии — свободной энциклопедии, -_*
Embarcadero® Delphi® XE is the fastest way to deliver ultra-rich, ultra-fast Windows applications. Dramatically reduce coding time and create applications 5x faster with component-based development and a fully visual two-way RAD IDE.
Тут
Слоган на странице продукта вообще отличный — "Be Amazing"
В общем пока все возятся со всякими Java/C#/C++, в мире Дельфи уже наступило светлое будущее (пока 32-х битное правда)!