Здравствуйте, gandjustas, Вы писали:
DS>>Здравствуйте, snaphold, Вы писали:
DS>>Кто-то тут писал что Delphi медленно работает. Уже месяц пишу интерпретатор языка PHP с нуля на этом языке. Я не преувеличиваю, скорость интерпретатора на уровне оригинального php, ruby и подобных языков. Идите, напишите интерпретатор на C# NET 4.0 даже, настоящий интерпретатор, без зависимости фреймворка. G>А ты Iron Ruby и Iron Python видел? Они какбы быстрее ruby и некоторых интерпретаторов python работают.
Что такое Iron *, это компиляция в байт-код .NET. Ничего удивительного, компилятор можно написать хоть на PHP (утрирую), главное чтобы была платформа на чем байт-код можно было бы быстро выполнить.
DS>>Поддержка freepascal и lazarus, а значит кроссплатформенность. G>Круто, и кому оно нафиг надо? G>Обычно кроссплатформенность ради кроссплатформенности никого не интересует.
DS>>А что-то такое Mono, компания Novell, которая его разрабатывает распродается по частям, так кто умирает? G>Да ты не переживай, где сейчас borland? а inprise? а codegear? кто сейчас delphi занимается?
Codegear разрабатывает делфи и сейчас, она теперь под покровительством embarcadero, и Delphi 2009-2010 вышли под их покровительством.
DS>>Скорее .NET как платформа умрет раньше из-за политики MS, а вот Java будет жить. G>А вот практика показывает обратное. Особенно в свете недавнего отказа apple саппортить java на маках.
Насколько Apple поддерживает .NET платформу? * А вот Freepascal уже есть под Apple. *
Здравствуйте, gandjustas, Вы писали:
I>>Apple отказалась Джаву суппортить, так есть Оракл, который этим скорее всего займется и поверь это будет намного лучше — свято место пусто не бывает.
G>Верующий блин
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
g>> DS>Поддержка freepascal и lazarus, а значит кроссплатформенность.
g>> Круто, и кому оно нафиг надо? g>> Обычно кроссплатформенность ради кроссплатформенности никого не интересует.
H>Линукс идет в массы (да-да, я сам видел), Маки цветут пышным цветом Ты не знал?
И что?
Под пак пишут на Cocoa и Objective-C, под nix KDE или GTK на C\C++, под винду MFC или .NET.
Разве что Qt позволяет писать под все сразу. Но для маков Cocoa все равно остается предпочтительной.
g>> Да ты не переживай, где сейчас borland? а inprise? а codegear? кто сейчас delphi занимается? H>CodeGear сейчас в составе Embarcadero, работают над Delphi (в том числе и кроссплатформенной). Порадуйся.
Круто, вот тебе наглядное доказательство что востребованный продукт всегда найдется кому поддерживать.
Здравствуйте, dim-s, Вы писали:
DS>Здравствуйте, gandjustas, Вы писали:
DS>>>Здравствуйте, snaphold, Вы писали:
DS>>>Кто-то тут писал что Delphi медленно работает. Уже месяц пишу интерпретатор языка PHP с нуля на этом языке. Я не преувеличиваю, скорость интерпретатора на уровне оригинального php, ruby и подобных языков. Идите, напишите интерпретатор на C# NET 4.0 даже, настоящий интерпретатор, без зависимости фреймворка. G>>А ты Iron Ruby и Iron Python видел? Они какбы быстрее ruby и некоторых интерпретаторов python работают.
DS>Что такое Iron *, это компиляция в байт-код .NET. Ничего удивительного, компилятор можно написать хоть на PHP (утрирую), главное чтобы была платформа на чем байт-код можно было бы быстро выполнить.
Ну напиши такую платформу да делфи
DS>>>Скорее .NET как платформа умрет раньше из-за политики MS, а вот Java будет жить. G>>А вот практика показывает обратное. Особенно в свете недавнего отказа apple саппортить java на маках.
DS>Насколько Apple поддерживает .NET платформу? * А вот Freepascal уже есть под Apple. *
Mono.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
g>> А ты Iron Ruby и Iron Python видел? Они какбы быстрее ruby и некоторых интерпретаторов python работают.
H>Другой вопрос, а являются ли они честными интерпретаторами? А может там где чего и джитится?
А в чем разница? Во всех современных интерпретаторах джитится.
Здравствуйте, gandjustas, Вы писали:
g> DS>Что такое Iron *, это компиляция в байт-код .NET. Ничего удивительного, компилятор можно написать хоть на PHP (утрирую), главное чтобы была платформа на чем байт-код можно было бы быстро выполнить.
g> Ну напиши такую платформу да делфи
Уже написана. Называется PaxCompiler. Паскаль код компилит в натив и пускает.
Здравствуйте, gandjustas, Вы писали:
g> g>> DS>Поддержка freepascal и lazarus, а значит кроссплатформенность.
g> g>> Круто, и кому оно нафиг надо? g> g>> Обычно кроссплатформенность ради кроссплатформенности никого не интересует.
g> H>Линукс идет в массы (да-да, я сам видел), Маки цветут пышным цветом Ты не знал?
g> И что? g> Под пак пишут на Cocoa и Objective-C, под nix KDE или GTK на C\C++, под винду MFC или .NET. g> Разве что Qt позволяет писать под все сразу. Но для маков Cocoa все равно остается предпочтительной.
И как это разговор от "нафиг надо" перешел к перечислению библов? К слову, Lazarus умеет использовать, и Win32(CE), и GTK(2), и Qt (и есть наметки для Cocoa).
g> g>> Да ты не переживай, где сейчас borland? а inprise? а codegear? кто сейчас delphi занимается?
g> H>CodeGear сейчас в составе Embarcadero, работают над Delphi (в том числе и кроссплатформенной). Порадуйся.
g> Круто, вот тебе наглядное доказательство что востребованный продукт всегда найдется кому поддерживать.
Здравствуйте, gandjustas, Вы писали:
g> g>> А ты Iron Ruby и Iron Python видел? Они какбы быстрее ruby и некоторых интерпретаторов python работают.
g> H>Другой вопрос, а являются ли они честными интерпретаторами? А может там где чего и джитится?
g> А в чем разница? Во всех современных интерпретаторах джитится.
Дык разница в том, что сравнивать работу джита, и говорить, что он быстрее, с обычной интерпретацией, мягко говоря, неправильно.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Head Ache, Вы писали:
HA>>Немного перебрал HA>>Применение DFS для каждого узла даст в итоге квадратичную сложность, вот
G>Ниугадал. G>Так как объекты помечаются, то больше одного раза по живому объекты не пройдет
Еще не сдаюсь
Оценка сложности DFS O(N+E), N — число вершин, E — число связей.
E может быть от 0 до O(N^2)
То есть какие-то патологические ситуации все-таки возможны.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Head Ache, Вы писали:
HA>>Зачем спрашиваешь, наверно и так ответ заранее знаешь HA>>Если ссылка будет жить дольше объекта — будет плохо и никто такой код не пишет. HA>>Если надо контролировать время жизни — использовать интеллектуальные указатели. HA>>Обратите внимание, подход "не плати за то, чем не пользуешься": четко обозначить проблему и решать именно ее. HA>>То есть если не нужны именно интеллектуальные указатели, они и не будут применяться. HA>>Также есть варианты со статической памятью, глубоким копированием, специализированные аллокаторы. HA>>Никто не мешает и сборщик мусора применять, только почему-то непопулярен этот подход. HA>>Ни с gc, ни с каким-либо другим. MM>Забавно, наверное, потом поддерживать всё это нагромождение разных подходов. Все они в той или иной степени неэффективны, поэтому и взялись за сборщик мусора. Который, конечно, тоже по своему неэффективен, но благо у нас есть выбор. Мне весь этот описанный бардак — то так сошлемся, то сяк, то смарт-поинтеры с самопальными аллокаторами — не нужен.
Бардака нет.
HA>>>>Пример2(классика). Критические секции, когда после Enter() следует гарантировать выполнение Leave() HA>>>>Для C# это настолько сложная проблема, что даже понадобилось вводить новое ключевое слово lock (SyncLock в VB) ! HA>>>>(так же как и using для IDisposable) MM>>>Какие-то у тебя проблемы надуманные. Это все такие мелочи: написать lock или try/finally. HA>>Не мелочи, когда надо обеспечивать строгие гарантии самому. MM>Что-то я не понял, о чем ты. Написать реализацию IDisposable тяжело? Написать using тяжело?
Поймешь меня, когда другие начнут пользоваться твоими либами.
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Head Ache, Вы писали:
HA>>>Немного перебрал HA>>>Применение DFS для каждого узла даст в итоге квадратичную сложность, вот
G>>Ниугадал. G>>Так как объекты помечаются, то больше одного раза по живому объекты не пройдет
HA>Еще не сдаюсь HA>Оценка сложности DFS O(N+E), N — число вершин, E — число связей. HA>E может быть от 0 до O(N^2) HA>То есть какие-то патологические ситуации все-таки возможны.
Еще раз. Все вершины проходятся максимум один раз. Количество связей значение не имеет.
Никаких паталогических ситуаций быть не может.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, enji, Вы писали:
E>>Здравствуйте, gandjustas, Вы писали:
G>>>Вполне может решаться проще. G>>>http://code.msdn.microsoft.com/RxParsers G>>>вот так например
E>>
E>>IObservable<StockAlert> alerts = ticks.Parse(parser =>
E>> from next in parser //Служебный кусок
E>> let ups = next.Where(tick => tick.Change > 0) //Разделение потока событий на положительные
E>> let downs = next.Where(tick => tick.Change < 0)//и отрицательные
E>> select (from up in ups.AtLeast(2) //Если сначала иду как минимум два положительных
E>> from down in downs //Затем отрицательный
E>> where down.Change <= -11 //Когда у отрицательного изменения <= -11
E>> select new StockAlert(up.ToEnumerable(), down)) //Возвращаем StockAlert
E>> .Or //Или
E>> (from down in downs.AtLeast(2) //Сначала как минимум два отрицательных
E>> from up in ups //Потом положительный
E>> where up.Change >= 21 //Со значением более 21
E>> select new StockAlert(down.ToEnumerable(), up))); //Возвращаем StockAlert
E>>
E>>А не могли бы вы вкратце пояснить, что это делает? А то нифига не понятно
G>А чтобы понимать как оно это делает надо изучать continuation, list и parser монады.
Т.е. есть очередь объектов тип Тик. Если начало очереди соответствует одному шаблону, создается один объект, если другому — то второй; в обоих случаях совпадение удаляется из очереди? Если не соответствует никакому — то что? Первый элемент отбрасывается?
Тоже самое на дельфи (кстати, в последних версиях есть лямбды, но синтаксис я не знаю, обойдемся без них):
function filter(q : TTickQueue) : TTick;
function isUp(t : TTick);
begin
Result := t.Change > 0
end;
function isDown(t : TTick);
begin
Result := t.Change < 0
end;
begin
if q.atLeast(2, isUp) and q(2).Change <= -11 then
begin
Result := StockAlert.Create(q[0].ToEnumerable(), down);
q.pop(3);
end
else if q.atLeast(2, isDown) and isUp(q[2]) and q[2].Change > 21 then
begin
Result := StockAlert.Create(q[0].ToEnumerable(), up);
q.pop(3);
end
else
q.pop();
end;
По строчкам примерно тоже самое. И, ИМХО, понятно не только знатокам шарпа, а практически каждому
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, enji, Вы писали:
E>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, enji, Вы писали:
E>>>>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>>>Здравствуйте, enji, Вы писали:
E>>>>>>Развитость языка — а какие именно возможности языка были бы полезны в этом случае?
НС>>>>>К примеру, для работы с СОМ-портом можно использовать Reactive Framework. В Дельфи аналог есть? Для асинхронности все тот же Rx или PLinq. В Дельфи аналог последнего есть?
E>>>>Гм, а зачем? В дельфи есть компонент, у которого есть события — получен символ, переданы данные и т.д. Компонент полностью изолирует порт. Что у него внутрях — я не знаю, может отдельный поток, может порты завершения...
E>>>>На его основе работа с портом пишется весьма просто.
G>>>Датыче? напиши-ка прогу, которая читает из порта пакеты, где в первом байте указана длина пакета, а в последующих сам пакет, в конце CRC. G>>>После принятия валидного пакета его надо отправить на обработку некоторой функции, при этом порт должен продолжать принимать данные.
G>>>А потом сравним вариант с Rx на .NET
E>>На дельфи написать не могу — я забросил дельфи года 3 как. G>выше выделено про компонент делфи.
Ну какая принципиальная разница ? И на дельфи будет примерно такая-же по сложности функция.
G>Это далеко не самое интересное. Самое интересное как раз "фреймворк", который занимается заполнением буфера, а не как потом буфер обрабатывается.
А что в этом такого интересного? Сильно зависящй от платформы и физического уровня класс, который буферизует принятые байты, контролирует таймауты и периодически дергает указанную ему функцию (пример которой я вам и привел), которая формирует из байтов пакеты в соответствии с конкретным протоколом, а также указывает что делать при нарушении таймаутов.
Кстати, хотелось бы посмотреть на такую штуку c Rx на .NET
Заодно давайте чуть усложним пакет:
START STX адрес данные ETX CRC
START может отсутствовать
каждый байт между STX и ETX сопровождается комплиментарным (например: 0x12 0xED 0x47 0xB8 и т.д.)
адрес лежит в диапазоне [0x10, 0x30)
CRC — однобайтовая, сумма всех байт адреса и данных (исключая комплиментарные) по модулю 256
STX не может встретиться внутри пакета, однако может в CRC или как комплиментарный байт
Комплиментарные байты следует проверить на правильность и исключить из пакета
E>>Здесь на макросах реализовано что-то вроде сопроцедур — процедура прерывается, а затем выполняется начиная с точки прерывания. При этом учитывается "тип блока" — передача, обработка ответа и т.д. Подозреваю, что это — упрощенный аналог вашего Reactive Framework G>Всетаки разговор про делфи был. Там и макросов то нет.
Ну в дельфях есть лямбды, можно сделать через массив лямбд. Не знаю конечно как оно будет выглядеть, забросил дельфи раньше, чем они появились... На крайний случай можно прогнать код через сторонний препроцессор, тот же M4
Здравствуйте, enji, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, enji, Вы писали:
E>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Вполне может решаться проще. G>>>>http://code.msdn.microsoft.com/RxParsers G>>>>вот так например
E>>>
E>>>IObservable<StockAlert> alerts = ticks.Parse(parser =>
E>>> from next in parser //Служебный кусок
E>>> let ups = next.Where(tick => tick.Change > 0) //Разделение потока событий на положительные
E>>> let downs = next.Where(tick => tick.Change < 0)//и отрицательные
E>>> select (from up in ups.AtLeast(2) //Если сначала иду как минимум два положительных
E>>> from down in downs //Затем отрицательный
E>>> where down.Change <= -11 //Когда у отрицательного изменения <= -11
E>>> select new StockAlert(up.ToEnumerable(), down)) //Возвращаем StockAlert
E>>> .Or //Или
E>>> (from down in downs.AtLeast(2) //Сначала как минимум два отрицательных
E>>> from up in ups //Потом положительный
E>>> where up.Change >= 21 //Со значением более 21
E>>> select new StockAlert(down.ToEnumerable(), up))); //Возвращаем StockAlert
E>>>
E>>>А не могли бы вы вкратце пояснить, что это делает? А то нифига не понятно
G>>А чтобы понимать как оно это делает надо изучать continuation, list и parser монады.
E>Т.е. есть очередь объектов тип Тик. Если начало очереди соответствует одному шаблону, создается один объект, если другому — то второй; в обоих случаях совпадение удаляется из очереди? Если не соответствует никакому — то что? Первый элемент отбрасывается?
Немного не так. Нету очередей, есть поток событий. Вот если в потоке событий Tick парсер обнаруживает заданный шаблон (два вверх, потом один вниз или наоборот), то выкидывает событие StockAlert. То есть образуется другой поток событий типа StockAlert.
E>Тоже самое на дельфи (кстати, в последних версиях есть лямбды, но синтаксис я не знаю, обойдемся без них):
E>
E>function filter(q : TTickQueue) : TTick;
E> function isUp(t : TTick);
E> begin
E> Result := t.Change > 0
E> end;
E> function isDown(t : TTick);
E> begin
E> Result := t.Change < 0
E> end;
E>begin
E> if q.atLeast(2, isUp) and q(2).Change <= -11 then
E> begin
E> Result := StockAlert.Create(q[0].ToEnumerable(), down);
E> q.pop(3);
E> end
E> else if q.atLeast(2, isDown) and isUp(q[2]) and q[2].Change > 21 then
E> begin
E> Result := StockAlert.Create(q[0].ToEnumerable(), up);
E> q.pop(3);
E> end
E> else
E> q.pop();
E>end;
E>
E>По строчкам примерно тоже самое. И, ИМХО, понятно не только знатокам шарпа, а практически каждому
Неугадал. Коду выше нужна очередь, а кто-то еще будет эту очередь заполнять (читай блокировки, потоки итп). Кроме того функция не образует другой поток событий. А также проблема в том что функция твоя синхронна, а RxParsers работает асинхронно (не блокирует потоки).
Не получится на делфи даже близко повторить такую работу, как в RxParsers, слишком слаб и язык, и библиотека.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, enji, Вы писали:
E>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, enji, Вы писали:
E>>>>>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>>>>Здравствуйте, enji, Вы писали:
E>>>>>>>Развитость языка — а какие именно возможности языка были бы полезны в этом случае?
НС>>>>>>К примеру, для работы с СОМ-портом можно использовать Reactive Framework. В Дельфи аналог есть? Для асинхронности все тот же Rx или PLinq. В Дельфи аналог последнего есть?
E>>>>>Гм, а зачем? В дельфи есть компонент, у которого есть события — получен символ, переданы данные и т.д. Компонент полностью изолирует порт. Что у него внутрях — я не знаю, может отдельный поток, может порты завершения...
E>>>>>На его основе работа с портом пишется весьма просто.
G>>>>Датыче? напиши-ка прогу, которая читает из порта пакеты, где в первом байте указана длина пакета, а в последующих сам пакет, в конце CRC. G>>>>После принятия валидного пакета его надо отправить на обработку некоторой функции, при этом порт должен продолжать принимать данные.
G>>>>А потом сравним вариант с Rx на .NET
E>>>На дельфи написать не могу — я забросил дельфи года 3 как. G>>выше выделено про компонент делфи.
E>Ну какая принципиальная разница ? И на дельфи будет примерно такая-же по сложности функция.
Так ты привел самую неинтересную функцию в данном контексте. Интересует как раз сам фреймворк, который выполняет асинхронное считывание.
G>>Это далеко не самое интересное. Самое интересное как раз "фреймворк", который занимается заполнением буфера, а не как потом буфер обрабатывается. E>А что в этом такого интересного? Сильно зависящй от платформы и физического уровня класс, который буферизует принятые байты, контролирует таймауты и периодически дергает указанную ему функцию (пример которой я вам и привел), которая формирует из байтов пакеты в соответствии с конкретным протоколом, а также указывает что делать при нарушении таймаутов.
E>Кстати, хотелось бы посмотреть на такую штуку c Rx на .NET
E>Заодно давайте чуть усложним пакет:
E>START STX адрес данные ETX CRC
E>START может отсутствовать E>каждый байт между STX и ETX сопровождается комплиментарным (например: 0x12 0xED 0x47 0xB8 и т.д.) E>адрес лежит в диапазоне [0x10, 0x30) E>CRC — однобайтовая, сумма всех байт адреса и данных (исключая комплиментарные) по модулю 256 E>STX не может встретиться внутри пакета, однако может в CRC или как комплиментарный байт E>Комплиментарные байты следует проверить на правильность и исключить из пакета
Вечером сделаю.
Здравствуйте, gandjustas, Вы писали:
E>>Т.е. есть очередь объектов тип Тик. Если начало очереди соответствует одному шаблону, создается один объект, если другому — то второй; в обоих случаях совпадение удаляется из очереди? Если не соответствует никакому — то что? Первый элемент отбрасывается? G>Немного не так. Нету очередей, есть поток событий. Вот если в потоке событий Tick парсер обнаруживает заданный шаблон (два вверх, потом один вниз или наоборот), то выкидывает событие StockAlert. То есть образуется другой поток событий типа StockAlert.
Ну поток событий, очередь событий — какая в принцинципе разница?
G>Неугадал. Коду выше нужна очередь, а кто-то еще будет эту очередь заполнять (читай блокировки, потоки итп). G>Кроме того функция не образует другой поток событий. А также проблема в том что функция твоя синхронна, а RxParsers работает асинхронно (не блокирует потоки).
Эта функция занимается только поиском совпадений. Она вызывается не показанным здесь кодом при обновлении потока событий. Работает она точно также асинхронно, не блокируя потоки — где вы увидели в ней ожидание чего-либо?
G>Не получится на делфи даже близко повторить такую работу, как в RxParsers, слишком слаб и язык, и библиотека.
Конкретно этот мой пример чем не устраивает? Я не ставил своей целью повторить RxParsers, ибо пока слабо представляю себе что это такое. Но конкретный пример анализа потока и генерации каких-то событий при совпадении — повторяется на ура.
Написать обобщенную библиотеку, которая будет предоставлять потоки для любых событий, подозреваю вполне реально. Выглядеть она будет более коряво, потому что в языке меньше сахара, однако работать будет
Здравствуйте, gandjustas, Вы писали:
E>>Ну какая принципиальная разница ? И на дельфи будет примерно такая-же по сложности функция. G>Так ты привел самую неинтересную функцию в данном контексте. Интересует как раз сам фреймворк, который выполняет асинхронное считывание.
До меня все еще никак не дойдет, что такого интересного в этом "фреймворке"? На с++ поверх boost::asio — порядка 800 строк. На с++ поверх аппаратных прерываний — чуток поменьше. На дельфи поверх компонента — тоже ничего сложного нет. Совершенно тупой неинтересный код
Его задачи
— передать байты в порт
— принять байты из порта, проконтролировать разные таймауты, в нужные моменты вызвать протокольно-специфичную функцию анализа
Если ты намекаешь на то, что под Net эти 800 строк не надо писать — так я их один раз написал, отладил, и использую для любых протоколов обмена.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
E>>>Т.е. есть очередь объектов тип Тик. Если начало очереди соответствует одному шаблону, создается один объект, если другому — то второй; в обоих случаях совпадение удаляется из очереди? Если не соответствует никакому — то что? Первый элемент отбрасывается? G>>Немного не так. Нету очередей, есть поток событий. Вот если в потоке событий Tick парсер обнаруживает заданный шаблон (два вверх, потом один вниз или наоборот), то выкидывает событие StockAlert. То есть образуется другой поток событий типа StockAlert.
E>Ну поток событий, очередь событий — какая в принцинципе разница?
Большая, очередь — некоторая структура в памяти, а вот потоки событий — абстракции,структуры не имеющие.
G>>Неугадал. Коду выше нужна очередь, а кто-то еще будет эту очередь заполнять (читай блокировки, потоки итп). G>>Кроме того функция не образует другой поток событий. А также проблема в том что функция твоя синхронна, а RxParsers работает асинхронно (не блокирует потоки). E>Эта функция занимается только поиском совпадений. Она вызывается не показанным здесь кодом при обновлении потока событий. Работает она точно также асинхронно, не блокируя потоки — где вы увидели в ней ожидание чего-либо?
Вот именно не увидел, а это опять таки немаловажная часть решения — заполнение очереди.
G>>Не получится на делфи даже близко повторить такую работу, как в RxParsers, слишком слаб и язык, и библиотека. E>Конкретно этот мой пример чем не устраивает? Я не ставил своей целью повторить RxParsers, ибо пока слабо представляю себе что это такое. Но конкретный пример анализа потока и генерации каких-то событий при совпадении — повторяется на ура.
Ни разу не повторяется, потому что а)неполный б)не такой результат дает на выходе
E>Написать обобщенную библиотеку, которая будет предоставлять потоки для любых событий, подозреваю вполне реально. Выглядеть она будет более коряво, потому что в языке меньше сахара, однако работать будет
Она будет не просто коряво, а очень коряво.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
E>>>Ну какая принципиальная разница ? И на дельфи будет примерно такая-же по сложности функция. G>>Так ты привел самую неинтересную функцию в данном контексте. Интересует как раз сам фреймворк, который выполняет асинхронное считывание.
E>До меня все еще никак не дойдет, что такого интересного в этом "фреймворке"? На с++ поверх boost::asio — порядка 800 строк. На с++ поверх аппаратных прерываний — чуток поменьше. На дельфи поверх компонента — тоже ничего сложного нет. Совершенно тупой неинтересный код
Именно этот кусок меня и интересует.
E>Его задачи E>- передать байты в порт E>- принять байты из порта, проконтролировать разные таймауты, в нужные моменты вызвать протокольно-специфичную функцию анализа
Эти две задачи можно решать настолько разными способами, что можно получить в сотни раз отличающиеся потребления ресурсов компьютеров и человека.