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

I>>Шо, и базу со всеми таблицами и файл со всем контентом — все это в локальную переменную ? А ты, непростой !

V>А в чем проблема? Вы тут выступали за фукциональщину, то бишь за функциональную декомпозицию. Вам даже async/await для этого подогнали, чтобы объекты-автоматы не пилить вручную. Теперь же всё легко. Блесните воображением, как грится.

Где надо, уже блеснули. Ты покажи как решать проблемы, которые я показал.

V>Это у новичков разве что. Там такая же дотнетная асинхронность как была в первом дотнете. НИЧЕГО не поменялось. Кто раньше её не умел, тот и сейчас не сумеет.
V>Кароч, дальше локальных переменных и явно передаваемых контекстов не ходи и будет тебе счастье.

И в базу не писать, и файлы не трогать, а проект закрыть ?

I>>И всю базу данных поместить в эту локальную переменную ?

V>База сама умеет разные уровни изоляции.

И в локальную переменную влазит.

V>Кароч, про избитость задачи мне не втирай. Давай лучше конкретную боевую, оно разруливается на раз.

Это конкретно боевая, только упрощенная до предела.

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

V>>>Скользкий ты... Десятый раз уже убежал...
I>>Нет кода — нечего обсуждать.

V>Ну так дай свой код.

Мой код и так работает. Был поинт, что все классно без счетчиков ссылок. Вот и покажи, как это сделать.

I>>Я показал АПИ и дал все нужные объяснения.

V>Я задавал конкретный список вопросов — в ответ полный ноль объяснений.
V>Своё "АПИ" можешь запихать себе куда подальше, тут достаточно было упоминания вида обертки. Договорились об управляемой среде. Дальше-то чего ты морозишься? Мне тебя долго пинать надо, пока ты разродишься пояснениями, откуда ты берешь эти свои бесконечные счетчики ссылок???

Откуда я их беру — не важно. Покажи как у тебя будет работать без единого счетчика ссылок.


I>>Очевидно — ты не в теме, но пытаешься по привычки рассказать, что лучше всех все знаешь.
V>Ну так развей наши сомненья!!! Покажи или расскажи, где, в какой момент твои счетчики щелкают.

При присваивании, что очевидно.

I>>

I>>a.b1 = CreateB()
I>>a.b2 = a.b
I>>a.b3 = a.b
I>>...
I>>a.b4 = a.b
I>>

I>>Теперь фокус — зануляем все ссылки a.b* и нативный объект должен быть разрушен автоматически.
I>>От тебя требуется показать, как это делается без счетчика ссылок.

V>Я тут это... Кароч, тут в редакторе постов видно [c#]некий код[/c#]
V>Т.е. речь о нейтивной обертки для управляемой среды, пральна?

Речь о поддержке скриптов в приложении, навроде того, как это MS Office и тд сделано. Я привел код этого скрипта. CreateB создает некоторый объект, а дальше идет N присваиваний свойствам. Если все свойства занулить, объект должен быть разрушен.

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

V>Какой нафик Invalidate???
V>Речь об обновлении св-в в дизайнере.

Принудительная отрисовка контрола заставит проперти обновить ? Да ты сказочник.

V>И да, в обычной прорисовке тоже часто пользуются Refresh, например для hover-эффектов или сопровождающих рисунков для drug&drop. В общем, оба раза мимо.

Чем пользуются раки и олени, рассказывать не надо. Я за несколько лет выпилил контрол который чуть боле чем весь состоит из hover, drag&drop и подобных вещей и все это обновлялось дизайнере и тд и тд. И вот как ни то разу не приходось refresh использовать. Чудеса !

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

V>Ты там как обычно. Боевую задачу формулировать отказался. А при попытке упростить выплеснул с водой ребенка.

Там боевую задачу ты сам привел И ребенка сам же выплеснул.

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

V>>Представь, что народ давно этим всем пользуется, еще до async/await. Без проблем.
I>Ну вот и покажи решение.

Пффф... Еще раз. Медленно.

Проблему в твоем коде я НЕ вижу. Не вижу по той банальной причине, что в нем описана не задача, а её решение, про которое известно лишь, что оно неправильное.
Офигенная постановка задачи!

Давай боевую задачку. Не решение, а именно задачу. Решение я предоставлю в терминах паттерна IAsyncResult и эквивалентного ему варианта на async/await.

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

V>Проблему в твоем коде я НЕ вижу. Не вижу по той банальной причине, что в нем описана не задача, а её решение, про которое известно лишь, что оно неправильное.
V>Офигенная постановка задачи!

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

V>Давай боевую задачку. Не решение, а именно задачу. Решение я предоставлю в терминах паттерна IAsyncResult и эквивалентного ему варианта на async/await.

Это и есть боевая задача. Все что есть у ресурса, это две операции — Read, асинхронный, и Write, так же асинхронный. Что за ресурс — совершенно не важно, аналог это БД или файл. Специфика работы с этим ресурсом такая — прочитать значение, вычислить следующее состояние, записать. Read сделан так, что переключает внутренне состояние ресурса, примерно как view в MMF и возвращает некоторое значение. Write модифицирует текущее состояние. Смена состояния — снова асинхронная операция, ничем особо от Read не отличается и основная причина такого решения это слишком дорогое переключение состояния.

Решение от тебя требуется на тех хвалёных stackfull короутинах с аццким yield, раз на них всё шоколадно, ажно асинхронщина на раз в десятки строчек да любым студентом.
Решение на авайтах я сам уже привел в этом форуме ссылкой + решение на колбеках так же ссылкой. Если тебе сказать нечего — будем считать что stackfull короутины на таких простых задачах это отстой.

Вобщем ты дашь решение на авайтах, то это ни о чем, тебя не поймут — stackfull круты аки яйцы, но решение на авайтах

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

I>Проблема показана — когда код синхронный один результат, когда код асинхронный — другой. В обоих случаях он должен быть одинаковый.

С какой радости???

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

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

Сериализованное обращение к ресурсу решается сериализацией. Всё!
Надеюсь, что твоя "задача" состоит таки не в этом.


V>>Давай боевую задачку. Не решение, а именно задачу. Решение я предоставлю в терминах паттерна IAsyncResult и эквивалентного ему варианта на async/await.

I>Это и есть боевая задача. Все что есть у ресурса, это две операции — Read, асинхронный, и Write, так же асинхронный. Что за ресурс — совершенно не важно, аналог это БД или файл. Специфика работы с этим ресурсом такая — прочитать значение, вычислить следующее состояние, записать. Read сделан так, что переключает внутренне состояние ресурса, примерно как view в MMF и возвращает некоторое значение. Write модифицирует текущее состояние. Смена состояния — снова асинхронная операция, ничем особо от Read не отличается и основная причина такого решения это слишком дорогое переключение состояния.

Та блин... Никогда не работай даже тим-лидом. Это ж издевательство над психикой. )))

Без описания требуемого поведения подойдет ПРОИЗВОЛЬНАЯ реализация, в т.ч. и такая, которую ты заведомо назвал неправильной.
Ты ж пока поставил условие Read и Write. Что еще тебе надо, чтобы было "правильно"???

Давай use case для хотя бы двух конкурентных потоков. Что на входе, что на выходе у каждого? Какие ограничения тебе нужны?


I>Решение от тебя требуется на тех хвалёных stackfull короутинах с аццким yield, раз на них всё шоколадно, ажно асинхронщина на раз в десятки строчек да любым студентом.

Позволь мне самому разобраться, как решать задачу... После того как ты хотя бы СУМЕЕШЬ её внятно сформулировать.

И не надо пытаться наезжать на короутины. Я рассказывал про вполне специфический бенефит от короутин в кооперативной многозадачности. В дотнете это так же доступно, если помнишь (надеюсь, у тебя, наконец, получилось запустить мой пример?). Если в итоге выяснится, что для решения твоей задачи сей специфический бенефит будет не нужен, то будем считать, что ты так и не понял, в чем он заключается. ))


I>Решение на авайтах я сам уже привел в этом форуме ссылкой

Можно я, чистоты эксперимента ради, покамест проигнорирую любые предложенные ранее решения?

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

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

V>>Ты там как обычно. Боевую задачу формулировать отказался. А при попытке упростить выплеснул с водой ребенка.

I>Там боевую задачу ты сам привел И ребенка сам же выплеснул.

Ты точно освежил происходящее в том топике?

Ты там привел некий код и тест для него. Я же тебе показал, что твой тест ни о чем, т.к. не имеет права называться юнит-тестом по-определению. Ты стал давать некие дополнительные вводные словами, под которые я тебе тут же выкатил сразу несколько решений. Тебе опять не угодили, бо тебе всё еще хотелось не писать полноценный юнит тест. Но это уже не ко мне. Как и тогда предлагаю курить такую вещь, как "тестопригодность".

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

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

I>>Проблема показана — когда код синхронный один результат, когда код асинхронный — другой. В обоих случаях он должен быть одинаковый.

V>С какой радости???

Это очевидно, по моему. Или ты предлгаешь сказать кастомеру: "Мы перешли на асинхронное АПИ, поэтому про старые правильные результаты можно забыть"

V>Без описания требуемого поведения подойдет ПРОИЗВОЛЬНАЯ реализация, в т.ч. и такая, которую ты заведомо назвал неправильной.

Нет, не подойдет.

V>Ты ж пока поставил условие Read и Write. Что еще тебе надо, чтобы было "правильно"???

Что результат был таким, как если Read и Write синхронные. Инвариант сохранить нужно, все просто.

V>Давай use case для хотя бы двух конкурентных потоков. Что на входе, что на выходе у каждого? Какие ограничения тебе нужны?

Все уже дано.

I>>Решение от тебя требуется на тех хвалёных stackfull короутинах с аццким yield, раз на них всё шоколадно, ажно асинхронщина на раз в десятки строчек да любым студентом.

V>Позволь мне самому разобраться, как решать задачу... После того как ты хотя бы СУМЕЕШЬ её внятно сформулировать.

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

I>>Решение на авайтах я сам уже привел в этом форуме ссылкой

V>Можно я, чистоты эксперимента ради, покамест проигнорирую любые предложенные ранее решения?

Это неинтересно. У тебя был поинт, что все просто для любого студента да в десятки строчек. Я пока что не наблюдаю этого.

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

I>>Там боевую задачу ты сам привел И ребенка сам же выплеснул.

V>Ты точно освежил происходящее в том топике?

V>Ты там привел некий код и тест для него. Я же тебе показал, что твой тест ни о чем, т.к. не имеет права называться юнит-тестом по-определению. Ты стал давать некие дополнительные вводные словами, под которые я тебе тут же выкатил сразу несколько решений. Тебе опять не угодили, бо тебе всё еще хотелось не писать полноценный юнит тест. Но это уже не ко мне. Как и тогда предлагаю курить такую вещь, как "тестопригодность".

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

Важно что в этом топике ты намерено соврал, не единожды

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

I>>Проблема показана — когда код синхронный один результат, когда код асинхронный — другой. В обоих случаях он должен быть одинаковый.

V>С какой радости???

Подумай иначе — результат вычислений зависит от того, как долго выполняется каждая из цепочек и пересекаются ли они во времени. Что это за алгоритм такой — мне даже страшно представить.

Вот в синхронном коде все ясно — результат не зависит от того, как долго выполняются цепочки и и пересекаются ли они вообще.

Для чего вообще нужен асинхронный АПИ ? Для того, что бы утилизовать время. В синхронном варианте 99% времени это ожидание. На инкременте это естественно не заметно, а вот уже с файловой системой будет заметно.

Есть похожая задача, до безобразия, ограничить количество одновременных запросов на сервер до некоторого порога. Естественно, ошибки при превышении порога быть не должно. По такой схеме работает браузер например. XmlHttpRequest, насквозь асинхронный, не думает отваливаться по ошибке, если прокси сервер разрешает юзеру 10 соединений, а страница вдруг пошлет штук 100 таких реквестов.

Разница в решениях обоих задач чисто символическая, в одном случае ограничение до 1, во втором — до N

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

I>Речь о поддержке скриптов в приложении, навроде того, как это MS Office и тд сделано. Я привел код этого скрипта. CreateB создает некоторый объект, а дальше идет N присваиваний свойствам. Если все свойства занулить, объект должен быть разрушен.

А свойства управляемые при этом или нативные?..
Просто, если управляемые, то странное требование. Почему сразу после зануления, а не из финализатора какого-то управляемого объекта?

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

I>>Речь о поддержке скриптов в приложении, навроде того, как это MS Office и тд сделано. Я привел код этого скрипта. CreateB создает некоторый объект, а дальше идет N присваиваний свойствам. Если все свойства занулить, объект должен быть разрушен.

E>А свойства управляемые при этом или нативные?..

И такие и такие. Пока есть хоть одна ссылка, деструктор вызывать нельзя и память освобождать нельзя, нужно дать внятное сообщение об ошибке, что например объект разрушен. Проезд по памяти или access violation плохо подходит для пользователя, который почти не умеет программировать.

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

I>И такие и такие. Пока есть хоть одна ссылка, деструктор вызывать нельзя и память освобождать нельзя, нужно дать внятное сообщение об ошибке, что например объект разрушен.

Ну, так какие у тебя в скрипте-о свойства?

И зачем пользователю, "который почти не умеет программировать"(с) показывать и такие и такие свойства?

И я верно понял, что объект может быть разрушен, если ещё есть ссылки?.. Или такая ситуация не должна возникать?

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

I>>И такие и такие. Пока есть хоть одна ссылка, деструктор вызывать нельзя и память освобождать нельзя, нужно дать внятное сообщение об ошибке, что например объект разрушен.

E>Ну, так какие у тебя в скрипте-о свойства?

Неважно. Пусть это будет свойство x. Чем тебя это спасёт ?

E>И зачем пользователю, "который почти не умеет программировать"(с) показывать и такие и такие свойства?

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

E>И я верно понял, что объект может быть разрушен, если ещё есть ссылки?.. Или такая ситуация не должна возникать?

Это зависит от реализации. В моей разрушение после зануления всех ссылок.

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

V>>База сама умеет разные уровни изоляции.
I>И в локальную переменную влазит.

Легко. Создаешь т.н. "процесс", на верхнем уровне инициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции.

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

I>Очень просто — меньше кода = больше возможностей для улучшения алгоритма. Если ты согласен, будем писать задачу, только хочется код увидеть сначала от тебя.

Я вызвался портировать любой код на С++. Что портировать?

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

V>>Ты там привел некий код и тест для него. Я же тебе показал, что твой тест ни о чем, т.к. не имеет права называться юнит-тестом по-определению. Ты стал давать некие дополнительные вводные словами, под которые я тебе тут же выкатил сразу несколько решений. Тебе опять не угодили, бо тебе всё еще хотелось не писать полноценный юнит тест. Но это уже не ко мне. Как и тогда предлагаю курить такую вещь, как "тестопригодность".

I>Это совершенно не важно, показал ты или нет. С твоим уникальным подходом к терминологии совершенно не ясно что ты хотел показать.

I>Важно что в этом топике ты намерено соврал, не единожды

Если ты не понял, что тебе пишут, это еще не значит, что я соврал. Через интерфейсы или абстрактные классы я предлагал развязаться от 3-rd party для целей тестопригодности юнита на его основе. Это стандартная практика. Недостатков в этом способе ты так и не показал.

Я еще тогда тебе писал, что ты протестировал что не нужно, забыв протестировать что нужно.

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

V>>Какой нафик Invalidate???
V>>Речь об обновлении св-в в дизайнере.

I>Принудительная отрисовка контрола заставит проперти обновить ? Да ты сказочник.

Наоборот, чтобы обновление проперти было отображено в дизайнере студий до 2005-й. Опять и снова это стандартная практика и вопрос был известный, вообще-то. Просто на этом форуме не нашлось кому правильно ответить.

R>В Дизайнере форм не вызывается OnPaint(контрол не рисуется),зато в рабочей программе вызывается и работает..
R>Может забыл что то пометить? или еще что?

попробуй убрать вдойную буферизацию,
и делай Refresh в дизайн тайм при смене св-в или размеров

V>>И да, в обычной прорисовке тоже часто пользуются Refresh, например для hover-эффектов или сопровождающих рисунков для drug&drop. В общем, оба раза мимо.

I>Чем пользуются раки и олени, рассказывать не надо. Я за несколько лет выпилил контрол который чуть боле чем весь состоит из hover, drag&drop и подобных вещей и все это обновлялось дизайнере и тд и тд. И вот как ни то разу не приходось refresh использовать. Чудеса !

Это потому что твой кривой код прощается современной шустрой техникой и внутренности дизайнера WinForms были ПОЛНОСТЬЮ переделаны с выходом 2-го дотнета, специально для криворуких программистов. Стало больше тормозить, зато стало больше прощать.

И да, на первых пнях даже кнопка нормально на простом invalidate не работала, не то, что drag'n'drop.

Кароч, в кач-ве бонуса кормлю твою эрудицию.
Берешь форму с системной кнопкой. Нажимаешь кнопку мышкой и, не отпуская, отводишь мышку за пределы кнопки и возвращаешь обратно в область кнопки. Графическое изображение кнопки при этом меняется. "Унутре" там вызывается UpdateWindow, а вовсе не Invalidate. Даже на самых последних версиях виндов. Почему — курить политику доставки WM_PAINT через общую очередь.

Съел?

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


I>Это зависит от реализации. В моей разрушение после зануления всех ссылок.

ГЦ скрипта пусть подберет Callable Wrapper, а тот в финализаторе пусть тупо удалит нейтивный объект. Без каких-либо счетчиков ссылок.

Это было по второму примеру.

По твоему первому еще проще.
Пусть корень иерархии DOM — сам документ.

Документ при удалении тупо удаляет все подчиненные объекты. Он ими просто ВЛАДЕЕТ безо-всяких счетчиков ссылок.

Сама обертка над любым элементом док-та выглядит как-то так (С++/CLI):

ref class Element {
   Document^ _root;
   NativeElement * _native;
   ...
};

ref class Document {
   NativeDocument * _native;
   ...

   Element^ CreateElement(...) {
      return gcnew Element(this, _native->CreateElement(...));
   };
};

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

Но даже если АПИ позволяет создавать неприаттаченные к док-ту элементы, т.е. если может быть так, что вызван финализатор Element когда _root == nullptr, тогда Element::_native тупо удаляется в финализаторе. Если же элемент приаттачен к документу, то его удалит сам док-т, когда будет удален.

Владение самим нативным док-том может разделяться м/у скриптом и нативной средой (например, в фоне док-т достраивается по мере поступления данных из сети), можно сделать счетчик ссылок для контроля времени его жизни. Но я прогнозирую максимальное его кол-во порядка 2-х. Т.е. одна ссылка со стороны скрипта, а вторая — со стороны нейтивной среды.

Всё.

=========================
Практически все управляемые обертки над нашими же либами у нас строятся примерно так же.