Здравствуйте, Head Ache, Вы писали:

HA>>foreach(Item item in GetNextItem())
HA>>{
HA>>// бесконечный цикл создания объектов
HA>>// со "структурами" на это памяти не хватит
HA>>}
Я что-то не понял. Ты согласен с тем, что "со структурами на это памяти не хватит"?

HA>зы: а потом другой умник не глядя втыкает подобную хрень в какой-нибудь многопоточный обработчик...
Выглядит устрашающе. Что такое "многопоточный обработчик"?

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, Head Ache, Вы писали:

HA>>>foreach(Item item in GetNextItem())
HA>>>{
HA>>>// бесконечный цикл создания объектов
HA>>>// со "структурами" на это памяти не хватит
HA>>>}
MM>Я что-то не понял. Ты согласен с тем, что "со структурами на это памяти не хватит"?

Конечно, согласен. Просто не понимаю, почему нужно делать именно так

HA>>зы: а потом другой умник не глядя втыкает подобную хрень в какой-нибудь многопоточный обработчик...
MM>Выглядит устрашающе. Что такое "многопоточный обработчик"?

Хмм... gc вроде как стопорит все потоки на время сборки мусора...
Да и "проблема O(N)" какой-то неопределенной становится

Здравствуйте, MxMsk, Вы писали:

MM> HA>>foreach(Item item in GetNextItem())
MM> HA>>{
MM> HA>>// бесконечный цикл создания объектов
MM> HA>>// со "структурами" на это памяти не хватит
MM> HA>>}

MM> Я что-то не понял. Ты согласен с тем, что "со структурами на это памяти не хватит"?

Я вообще не понял что это значит

Здравствуйте, Head Ache, Вы писали:

E__>>Есть примеры фреймворка, который создает ссылки "все ко всем" между объектами?

HA>Не появляются ли неявно, где-то внутри связи типа не "все ко всем", а "один ко многим".

Можно поподробнее, что ты имеешь ввиду? Лучше на примере.

Здравствуйте, Head Ache, Вы писали:

HA>>>>foreach(Item item in GetNextItem())
HA>>>>{
HA>>>>// бесконечный цикл создания объектов
HA>>>>// со "структурами" на это памяти не хватит
HA>>>>}
MM>>Я что-то не понял. Ты согласен с тем, что "со структурами на это памяти не хватит"?
HA>Конечно, согласен. Просто не понимаю, почему нужно делать именно так
Переменная то всего одна. Как там может не хватить памяти?

HA>>>зы: а потом другой умник не глядя втыкает подобную хрень в какой-нибудь многопоточный обработчик...
MM>>Выглядит устрашающе. Что такое "многопоточный обработчик"?
HA>Хмм... gc вроде как стопорит все потоки на время сборки мусора...
Хмм.. И что?

HA>Да и "проблема O(N)" какой-то неопределенной становится
Ну, в этом споре я не участвую, т.к. не особо вдавался в подробности работы GC.

Здравствуйте, Head Ache, Вы писали:


E__>>Если в коде такое количество связей, и объекты друг на друга ссылаются, то проблема со скоростью GC уходит даже не на второй план, а сильно дальше, потому как самая главная проблема в днк писавшего такой код.

HA>Ну что вас заставляет писать ВОТ ЭТО, да еще и хвастаться:

Ты уверен, что тому человеку вопрос задаешь?

Здравствуйте, Eugeny__, Вы писали:

E>>На самом деле может быть даже больше N^2

E__>Если в коде такое количество связей, и объекты друг на друга ссылаются, то проблема со скоростью GC уходит даже не на второй план, а сильно дальше, потому как самая главная проблема в днк писавшего такой код.

Или же предметная область этого требует.

Здравствуйте, Head Ache, Вы писали:

HA>Здравствуйте, Eugeny__, Вы писали:

E__>>Если в коде такое количество связей, и объекты друг на друга ссылаются, то проблема со скоростью GC уходит даже не на второй план, а сильно дальше, потому как самая главная проблема в днк писавшего такой код.

HA>Ну что вас заставляет писать ВОТ ЭТО, да еще и хвастаться:

Выглядит так, как будто ты задаешь вопрос мне. И я не понял где ты увидел хвастовство, будь добр, цитатой ?
Что заставляет писать код — лень. Пять строчек в одном методе лучше чем целый класс автомата реализующий 5 интерфейсов.

HA>public Item GetNextItem()
HA>{
HA> return new Item();
HA>}

...

Здравствуйте, Head Ache, Вы писали:

HA>>foreach(Item item in GetNextItem())
HA>>{
HA>>// бесконечный цикл создания объектов
HA>>// со "структурами" на это памяти не хватит
HA>>}

HA>зы: а потом другой умник не глядя втыкает подобную хрень в какой-нибудь многопоточный обработчик...

Запросто и при этом побочных эффектов нет и ожидать не приходится

Здравствуйте, Head Ache, Вы писали:


HA>Хмм... gc вроде как стопорит все потоки на время сборки мусора...

Только при сборке нулевого поколения. При правильной разработке такого может вообще и не случаться.

Здравствуйте, Head Ache, Вы писали:

HA>Боюсь, что в сложных вариантах с циклами, (т.е. когда собственно и нужен полный dfs),
HA>число итераций может расти с факториальной скоростью.

mark'n sweep:
mark :
DFS из каждой вершы рута — P*(V+E)
sweep :
scan в heap — V
расход доп памяти : V*ref_size
P — кол.во вершин в руте, V — объектов, E — связей между объектами , ref_size — размер ссылки
Циклы этому алгоритму по барабану и никакой факториальной зависимости нет и быть не может. Очевидно, P*(V+E) есть ни что иное, как O(V+E).

Здравствуйте, -_*, Вы писали:


E__>>Если в коде такое количество связей, и объекты друг на друга ссылаются, то проблема со скоростью GC уходит даже не на второй план, а сильно дальше, потому как самая главная проблема в днк писавшего такой код.

-_*>Или же предметная область этого требует.

Пример такой области — в студию.

Здравствуйте, -_*, Вы писали:

E>>Ну так на все случаи и не надо Надо только на конкретные случаи. Причем где-то надо именно либу, а где то хватит обычного "одноразового" кода, который решает задачу. Запись событий мышки — типичный пример такого кода, который очень прост и элементарно пишется каждый раз с учетом потребностей.

-_*>Такой код слишком прост что бы писать его каждый раз.

Ну дык сложный код пишем 1 раз, простой — много раз

-_*>Rx это просто фреймворк который можно приспособить куда угодно, в т.ч. для обработки мыши.

>>Насколько я все это понимаю, достаточно записать посл движений и сравнить с образцом. Алгоритм сравнения — это уже интересный вопрос. В институте на нейронных сетях делал какое-то распознавание...

-_*>RX позволяет свести это исключительно к алгоритму распознавания.

Дело в том, что распознавание НАМНОГО сложнее записи. Запись делается очень быстро без всяких проблем где угодно. Для распознавания надо уже курить теорию, пробовать и т.д. Именно распознавание — основная проблема в жестах. от того, что вы заюзаете Rx эта проблема не решится, поэтому нет особого преимущества в Rx в данном конкретном случае — на языке без Rx придется потратить на час больше времени, при этом возможно получится быстрее.

Здравствуйте, enji, Вы писали:

E>Ну дык сложный код пишем 1 раз, простой — много раз

Простой код как правило вообще не пишется. Он или генерируется или уходит во всякие фреймворки. В плохом фреймворке тривиальный код нужно писать руками на любой чих.

E>-_*>RX позволяет свести это исключительно к алгоритму распознавания.

E>Дело в том, что распознавание НАМНОГО сложнее записи. Запись делается очень быстро без всяких проблем где угодно.

Тривиальный код в правильных инструментах писать не нужно. Все это берет на себя фреймворк. Представь, нет никакой проблемы в Asp.Net или EF создавать проперти вручную. Все умеют писать проперти, не правда ли ? Но и Asp.Net и EF генерируют код что бы ты мог сосредоточиться только на основной задаче. Открой любой дизайнер хоть в WPF, SL или Winforms — тривиальнейший код и писать его не надо.
Собственно сбор координат точно такой же тривиальнейший код.

>Для распознавания надо уже курить теорию, пробовать и т.д. Именно распознавание — основная проблема в жестах.

Потому и нужно сосредоточиться именно на этой задаче, а не писать каждый раз похожий код для сбора координат.

Здравствуйте, enji, Вы писали:

E>В 2009 юникод вроде как уже из коробки был.

Напоминаю: юзали D7, которая появилась эээээ несколько раньше, и там и в самом деле были определенные проблемы с кодировками.

E>А до 2009 (или может 2008 — не помню) были tnt компоненты с поддержкой юникода. Для D7 они вполне подходили. Так что на кой было делать руками — это очень интересный вопрос.

Вы будете смеяться, но я вежливо намекнул ребятам, что можно было бы поискать готовое решение.

E>Все это говорит не о проблемах дельфи, а о проблемах в мозгах у ребят

Я и говорил не о проблемах делфи, а о том, что не все чудо-кодеры ушли на C#

Здравствуйте, slava_phirsov, Вы писали:

s> E>В 2009 юникод вроде как уже из коробки был.

s> Напоминаю: юзали D7, которая появилась эээээ несколько раньше, и там и в самом деле были определенные проблемы с кодировками.

Хм... Какие у WideString + WideCharToMultiByte/MultiByeToWideChar проблемы с кодировками? Или речь о том, что "изкоробочного" решения для Unicode Delphi 7 не обеспечивала?

S>Ну собственно я приблизительно вот такое полдожение дел и имел ввиду.

Не обольщайся. Под линукс это была бы такая же кривая и тормозящая поделка.

Здравствуйте, Eugeny__, Вы писали:

E__>>>Если в коде такое количество связей, и объекты друг на друга ссылаются, то проблема со скоростью GC уходит даже не на второй план, а сильно дальше, потому как самая главная проблема в днк писавшего такой код.

E__>-_*>Или же предметная область этого требует.

E__>Пример такой области — в студию.

Электроника. Достаточно ?

Здравствуйте, LR, Вы писали:

E__>>>>Если в коде такое количество связей, и объекты друг на друга ссылаются, то проблема со скоростью GC уходит даже не на второй план, а сильно дальше, потому как самая главная проблема в днк писавшего такой код.

E__>>-_*>Или же предметная область этого требует.

E__>>Пример такой области — в студию.

LR>Электроника. Достаточно ?

Если честно, то хотелось бы конкретную задачу. Электроника(что под этим подразумевается?) мне не совсем понятно, и тем более, почему это требует связи всех объектов со всеми. Если говорить об embedded, то, во-первых, там манагед явно не лучшее решение, а во вторых, я писал под железяку с 64 килобайтами памяти. Так вот связей "всех со всеми" там и близко не было. Писал, правда, на чистом С, так как я с багажом манагед разработки не потяну плюсы — задолбаюсь с памятью. А С прост как шар: два правила "не возвращать как результат(и не присваивать как ссылку в полученных параметрах) локальные переменные" и "не пользоваться выделением динамической памяти" обеспечили быструю и безглючную разработку.

ЗЫ был один раз и фэйл. Я привык как-то, что char — это двухбайтное беззнаковое число(по крайней мере, при приведению к числу). Ну, на подсознательном уровне. Адаптировал чужой код, там было doSomething(<params>, char length). Доолго я недоумевал, почему у меня длина обрезается при определенных значениях, пока не посчитал, до какого значения обрезается... Матюкать оставалось только себя.

Здравствуйте, Eugeny__, Вы писали:

LR>>Электроника. Достаточно ?

E__>Если честно, то хотелось бы конкретную задачу. Электроника(что под этим подразумевается?) мне не совсем понятно, и тем более, почему это требует связи всех объектов со всеми. Если говорить об embedded, то, во-первых, там манагед явно не лучшее решение, а во вторых, я писал под железяку с 64 килобайтами памяти.

Имеется ввиду моделирование, проектирование, рассчет. Обычно конечно квадратичной зависимости числа связей от числа объектов не будет, но некоторые алгоритмы могут потребовать и квадратичную зависимость.