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

I>>Ты все время жаждешь перескочить на обсуждение непойми чего. Про финаайзеры в этой ветке я нигде не касался.

V>Ды ну? В стандартном паттерне реализации IDisposable обязательно есть сценарий вокруг финализации. На этом, собсно, и строится вся "надежность" дотнета относительно ресурсов. Иначе бы вообще не о чем было с вами разговаривать.

Ну вот тебя и прорвало таки, только почему ты упомянул только финализаторы, но забыл про GCHandle ?

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

В финализаторе, согласно той же книге, где описан паттерн, не может быть никакой логики. Максимум — воскрешение объекта.
Например Dispose в финализаторе не имеет права вызывать эвент, ибо не ясно разрушен ли тот объект или нет. Это недетерминировано. По этой причине диспоз унутре финалайзера должен делать толко освобождение неуправяемого ресурса и вся инфа для этого должна быть в самом инстанце.

Итого — ни дефолтный, ни правильно написаный финализатор никак на задачу ниже не влияет и никакого отношения к ей соответвенно не имеет.

I>>Если ты не согласен, покажи мне где в этом коде или каком другом от меня, где там хотябы определение финалайзера, н говоря о том, что финалайзер должен бросать исключение

I>>

I>>var o = new Something();
I>> o.onBegin +=  () => {}
I>> o.onEnd +=  () => {}

I>>o.run();
I>>

V>Ну очередная двойка, чо.
V>Финалайзер расписан в том объекте, вокруг которого ты делал using унутри своего подразумеваемого фреймворка.

Ай, срезал ! Дефолтный, генеренный компилером !!!!

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

_>О, кстати, и не только медленнее... У Жабки же ещё есть свой "весёлый" стиль создания программных интерфейсов. Недавно наблюдал это. Коллеге тут надо было добавить криптографичекую мелочь в проекте на Жабке. Он взял их родную и самую модную библиотеку криптографии. Так вот для самых тривиальных вещей там надо было чуть ли не пару страниц кода писать. Когда я ему показал что буквально тоже самое делается ровно одним вызовом функции из OpenSSL он прямо в шоке был. А я в общем то не сильно удивился — жабовский стиль "наплодить кучу ненужных классов и интерфейсов" известен очень давно. ))) Про скорость там речи уже даже не шло, хотя думаю расклад и так понятен.

Это старая джава. В новой джаве это не нужно. Правда либы все еще старые

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

V>>Не убежишь. Это самые ортогональные на свете вещи относительно спора.
I>Это все про то же.

Оно ортогонально, потому что реализуемо фактически одинаково что там, что там. Т.е. смысла обсуждать это нет вообще. Степень автоматизации по-прежнему никакая. по-сути, ты сэкономил лишь на конструкции using, и никак не избавился от ручного слежения за ресурсами в случае агрегирования некоего middleware в прикладных объектах.

V>>Да пофиг. Вся эта подветка родилась из обсуждения уровня автоматизации RAII в плюсах и практически полного отсутствия её в дотнетах.

I>RAII нужен только в С++, и то выходит полу-решение какое то

Паттерн реализации IDisposable с тобой не согласен.

V>>Дык, это для дотнета нужен счетчик ссылок там, где на плюсах он не нужен вовсе. ))
I>Для дотнета он вовсе не нужен.

Есть сценарии где это, таки, самый эффективный и при этом всё еще безопасный сценарий вокруг ресурсов. Да посмотри, хотя бы, на работу с SafeHandle из наследников CriticalFinalizerObject (гони 200 баксов).
Та же самая семантика достижима и без счетчика ссылок, уже говорил на чем (хе-хе), но будет тормознее.

V>>Мне не надо счетчик ссылок на случай, если я владею переменной по-значению. А для уменьшения косвенности я могу протягивать ссылку (слабую) на эту переменную непосредственно потребителям.
I>Этим и занимается di/ioc — протягивает нужную ссылку непосредтсвенно потребителям

Спасибо!!! Я, как потребитель, не желаю специально следить за ресурсами. Я просто объявляю переменную в поле моего класса в С++, а дальше все происходит само. Собно, вернулись к началу. ))


V>>Да и вообще весело выходит. Из-за того, что конструкция finally (и using-сахар над ней) заведомо ограничена областью видимости локального блока кода, вы тут начинаете парить нам о необходимости исключительно "локального" подхода к владению ресурсами.

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


>>Какая святая наивность, немедленно разбивающаяся об IEnumerator<T>::Dispose(). Походу, это опять порт С++ программы?
I>Dispose можно использовать не только для ресурсов.

Пофиг.
Тем более, что это единственный способ валидно раскрутить using в генерируемом через yield автомате-енумераторе, который, упс, живет намного дольше, чем описанная в теле "область видимости".

I>Надо же, ты взял себя в руки и ни разу не упомянул финализаторы и GCHandle

Вот еще! Конечно упомянул. Для меня IDisposable не отделимо от финализатора. ))
А твои попытки закрывать глаза на эту фундаментальную для дотнета штуку просто смешны.
Я понимаю, что оно мешает тебе спорить. Дык, не спорь.

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

I>Это что же, с++ не годится для числодробилок ?

Полноценное решение на C++ будет на пару процентов быстрее чем Фортран/С решение и на порядок красивее по виду кода. Но для его написания учёному понадобится или нанять профи или же лет на 5 отвлечься от основной работы на настоящее изучение C++. Ну и как показала практика никто не готов на такие жертвы ради красоты кода и капли производительности. Так что C++ проникает в научные вычисления очень медленно, в основном на энтузиазме отдельных специалистов, которые понемногу самостоятельно развиваются по направлению C->C++.

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

V>Я уже говорил: клей и есть. Раньше перл для этого был.
V>(собсно, не был, а есть, почти все либы перла — это обертки над нейтивными вычислениями... просто хомячки выбрали в итоге питон)

И правильно сделали, перл — отстой.

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

I>>Это что же, с++ не годится для числодробилок ?

V>Странно... почему с появленим Матлаба никто так не говорил, хотя он на многих задачах рвет любые питоны с любыми либами.

Оставляю тебе поиск ответа в качестве усиления навыков чтеня.

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

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

Коль речь шла о надежном автоматическом освобождении ресурсов — то это часть схемы. Не напишешь правильно финализатор — твои ресурсы могут утечь.


V>>Ну очередная двойка, чо.
V>>Финалайзер расписан в том объекте, вокруг которого ты делал using унутри своего подразумеваемого фреймворка.

I>Ай, срезал ! Дефолтный, генеренный компилером !!!!

Да какой, блин, дефолтный??? Это твоё творение? Вот это:

Retval F(Func<Resource, Retval> operation)
{
  using(var x = new Resource())
  {
    return operation(x);
  }
}

У твоего Resource должен присутствовать правильно расписанный финализатор, если речь о действительно ресурсах, а не об объектах дотнета. Иначе такой тип только на мусорку.

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

I>И правильно сделали, перл — отстой.

Питон тоже сливает в плане последовательности дизайна многим скриптовым.

Кста, раз ты здесь, не объяснишь, почему хомячки любят питон и не любят руби? У меня к этим языкам, при одинаковом вложенном в них времени, совершенно противоположные эмоции. Отличный по дизайну ruby и несерьезный/непоследовательный Питон.

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

I>>>Это что же, с++ не годится для числодробилок ?
V>>Странно... почему с появленим Матлаба никто так не говорил, хотя он на многих задачах рвет любые питоны с любыми либами.
I>Оставляю тебе поиск ответа в качестве усиления навыков чтеня.

Дык, ответ на поверхности. Ты опять намек не понял?
Потому что предположить исходное в цитированнии мог только ты.
Я ж грю,

Хреновый из тебя защитник дотнета. )))

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

I>>>>Это что же, с++ не годится для числодробилок ?
V>>>Странно... почему с появленим Матлаба никто так не говорил, хотя он на многих задачах рвет любые питоны с любыми либами.
I>>Оставляю тебе поиск ответа в качестве усиления навыков чтеня.

V>Дык, ответ на поверхности. Ты опять намек не понял?

Правильно, ответ на поверхности — я утверждаю, что С++ есть в HPC. Надеюсь, ты понял намёк ?

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

V>Кста, раз ты здесь, не объяснишь, почему хомячки любят питон и не любят руби? У меня к этим языкам, при одинаковом вложенном в них времени, совершенно противоположные эмоции. Отличный по дизайну ruby и несерьезный/непоследовательный Питон.

По той же причине, по которой любят питон, джаву и C# и не любят C++

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

I>Это старая джава. В новой джаве это не нужно. Правда либы все еще старые

А что за новая джава? Я как бы не слежу за ней внимательно, так что не в курсе... )

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

V>Коль речь шла о надежном автоматическом освобождении ресурсов — то это часть схемы. Не напишешь правильно финализатор — твои ресурсы могут утечь.

"А посоны то и не знают " @

V>>>Ну очередная двойка, чо.
V>>>Финалайзер расписан в том объекте, вокруг которого ты делал using унутри своего подразумеваемого фреймворка.

I>>Ай, срезал ! Дефолтный, генеренный компилером !!!!

V>Да какой, блин, дефолтный??? Это твоё творение? Вот это:

Это другая задача из другой ветки и наличие финализатора ровно ничего не изменяет.

V>У твоего Resource должен присутствовать правильно расписанный финализатор, если речь о действительно ресурсах, а не об объектах дотнета. Иначе такой тип только на мусорку.

"А посоны то и не знают " @

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

I>>Это что же, с++ не годится для числодробилок ?

_>Полноценное решение на C++ будет на пару процентов быстрее чем Фортран/С решение и на порядок красивее по виду кода. Но для его написания учёному понадобится или нанять профи или же лет на 5 отвлечься от основной работы на настоящее изучение C++. Ну и как показала практика никто не готов на такие жертвы ради красоты кода и капли производительности. Так что C++ проникает в научные вычисления очень медленно, в основном на энтузиазме отдельных специалистов, которые понемногу самостоятельно развиваются по направлению C->C++.

Я вижу, ты решил таки со мной согласиться

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

V>Оно ортогонально, потому что реализуемо фактически одинаково что там, что там. Т.е. смысла обсуждать это нет вообще. Степень автоматизации по-прежнему никакая. по-сути, ты сэкономил лишь на конструкции using, и никак не избавился от ручного слежения за ресурсами в случае агрегирования некоего middleware в прикладных объектах.

За ресурсами и нужно следить вручную, т.е. описывать выделение и освобождение ЯВНО, а не полагаться на счетчики ссылок и распихивать по углам.

I>>RAII нужен только в С++, и то выходит полу-решение какое то

V>Паттерн реализации IDisposable с тобой не согласен.

Надо полагать этим свойством несогласия обладает только версия паттерна Vdimas.Disposable, а то скажем в FDG нет никаких счетчиков ссылок

V>Есть сценарии где это, таки, самый эффективный и при этом всё еще безопасный сценарий вокруг ресурсов. Да посмотри, хотя бы, на работу с SafeHandle из наследников CriticalFinalizerObject (гони 200 баксов).

Ты умудрился и интероп притянуть сюда Следующим наверное будет бутстраппер или рефлексия ?

V>Спасибо!!! Я, как потребитель, не желаю специально следить за ресурсами. Я просто объявляю переменную в поле моего класса в С++, а дальше все происходит само. Собно, вернулись к началу. ))

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

V>Пофиг.
V>Тем более, что это единственный способ валидно раскрутить using в генерируемом через yield автомате-енумераторе, который, упс, живет намного дольше, чем описанная в теле "область видимости".

Спасибо, капитан.

I>>Надо же, ты взял себя в руки и ни разу не упомянул финализаторы и GCHandle

V>Вот еще! Конечно упомянул. Для меня IDisposable не отделимо от финализатора. ))

Ты лучше расскажи, что изменит наличие правильного финалайзера в контексте обоих задач ? Тлько внятно, без простыней текста и воплей в духе "Ага, попался ! Я же говорил — я самый умный !!! А ты, двоечник !!!!!111одинодин"

V>А твои попытки закрывать глаза на эту фундаментальную для дотнета штуку просто смешны.

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

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

I>>Это старая джава. В новой джаве это не нужно. Правда либы все еще старые

_>А что за новая джава? Я как бы не слежу за ней внимательно, так что не в курсе... )

Я наверное поторпился. самое интересное вроде как уже в 8й версии будет

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

V>>Кста, раз ты здесь, не объяснишь, почему хомячки любят питон и не любят руби? У меня к этим языкам, при одинаковом вложенном в них времени, совершенно противоположные эмоции. Отличный по дизайну ruby и несерьезный/непоследовательный Питон.

I>По той же причине, по которой любят питон, джаву и C# и не любят C++

Хм... А разве ruby "неуправляемый" язык?

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

I>Это другая задача из другой ветки и наличие финализатора ровно ничего не изменяет.

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

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


V>>Оно ортогонально, потому что реализуемо фактически одинаково что там, что там. Т.е. смысла обсуждать это нет вообще. Степень автоматизации по-прежнему никакая. по-сути, ты сэкономил лишь на конструкции using, и никак не избавился от ручного слежения за ресурсами в случае агрегирования некоего middleware в прикладных объектах.

I>За ресурсами и нужно следить вручную, т.е. описывать выделение и освобождение ЯВНО, а не полагаться на счетчики ссылок и распихивать по углам.

Следуя той же логике, надо все поля в дотнетных классах инициализировать ЯВНО, даже если надо инициализировать нулем/null, а не полагаться на CLR.

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

I>>>RAII нужен только в С++, и то выходит полу-решение какое то
V>>Паттерн реализации IDisposable с тобой не согласен.
I>Надо полагать этим свойством несогласия обладает только версия паттерна Vdimas.Disposable, а то скажем в FDG нет никаких счетчиков ссылок

Жесть. Специально оставляю хронику цитирования для читателей. Пусть попробуют угадать, с помощью каких логических построений именно эта последовательность родила в итоге именно эту пургу.


V>>Есть сценарии где это, таки, самый эффективный и при этом всё еще безопасный сценарий вокруг ресурсов. Да посмотри, хотя бы, на работу с SafeHandle из наследников CriticalFinalizerObject (гони 200 баксов).

I>Ты умудрился и интероп притянуть сюда Следующим наверное будет бутстраппер или рефлексия ?

Ну опять двойка, чо!
Домашнее задание — что вообще есть для дотнета ресурс? А для операционки?
Фишка в том, что почти все т.н. "внешние ресурсы" для дотнета на самом деле сводятся к той же самой памяти, либо юзверской, либо ядерной. Всех делов, что эта память не подбирается GC. Поэтому, любой ресурс дотнета, требующий финализации — ес-но завернут в обертки через интероп. Если тебе надо в твоей программе будет завести еще свой какой-нить ресурс, требующий надежного освобождения, то без интеропа никак. А захочешь сделать это надежно и всё еще эффективно — обложишь счетчиком жестких ссылок. ))


V>>Спасибо!!! Я, как потребитель, не желаю специально следить за ресурсами. Я просто объявляю переменную в поле моего класса в С++, а дальше все происходит само. Собно, вернулись к началу. ))
I>Ога, само. Пока что было много крику и никто не показал правильный аналог моего кода.

Да нет у тебя никакого кода. Код заведомо невалидный, решает невостребованную задачу, бо экономия на одном using при локальном затем вызове целевого замыкания как-то выглядит слабым достижением, бо using итак для этих сценариев заточен, не надо на нем экономить. Вот если бы ты показал как вообще тот код, который помещают в тело Dispose, нафик писать не надо было, я бы проникся. А твои подписывания на события от сего действа никак не освобождают. Переливание из пустого в порожнее.

Вот тебе твои комбинаторы в свободном виде:

Func onBegin(Func target, Task beginCallback) {
  return [target, beginCallback] (Args args) { beginCallback(); return target(args); };
}

Func onEnd(Func target, Task endCallback) {
  return [target, endCallback] (Args args) { auto result = target(args); endCallback(); return result; };
}

Func wrap(Func target, Task beginCallback, Task endCallback, ErrorTask errorCallback) {
  return [target, beginCallback, endCallback, errorCallback] (Args args) { 
    try {
      beginCallback();
      auto result = target(args); 
      endCallback(); 
      return result; 
    } catch(const exception & ex) {
      errorCallback(ex);
    }
  };
}

Заказывай что хошь, кароч. Можно их запихать в некий тип-билдер, как любят в бусте, чтобы в клиентском коде можно было пользоваться не свободными ф-ями, а аналогично твоему примеру:

auto result = makeAspect(someTask)
  .onBegin([]{on begin code})
  .onEnd([]{on end code})
  (args);  // executing of operator()(Args)

Кароч, "правильный аналог" выглядит похоже на любом языке, шарп тут не при чем. Сам подход до невозможности нелеп в рамках С++. Но в рамках дотнета другого и нет. При возможности выбрать другие подходы ты бы эту жалкую хрень не городил.

V>>Пофиг.
V>>Тем более, что это единственный способ валидно раскрутить using в генерируемом через yield автомате-енумераторе, который, упс, живет намного дольше, чем описанная в теле "область видимости".

I>Спасибо, капитан.

Не за что. Жаль, что всегда не с первого раза.

I>>>Надо же, ты взял себя в руки и ни разу не упомянул финализаторы и GCHandle
V>>Вот еще! Конечно упомянул. Для меня IDisposable не отделимо от финализатора. ))

I>Ты лучше расскажи, что изменит наличие правильного финалайзера в контексте обоих задач ? Тлько внятно, без простыней текста и воплей в духе "Ага, попался ! Я же говорил — я самый умный !!! А ты, двоечник !!!!!111одинодин"

С финалайзером я влез аккурат в разгар твоих попыток критиковать практику С++ по невыбрасыванию исключений из деструктора. Чуть более разжеванней здесь: http://www.rsdn.ru/forum/flame.comp/5300784.1

Автор: vdimas
Дата: 18.09.13

V>>А твои попытки закрывать глаза на эту фундаментальную для дотнета штуку просто смешны.
I>Пудозреваю, что у тебя вообще все неотделимо друг от друга, раз ты притянул к простой здаче даже интероп и gchandle, не говоря про финализатор.

ОМГ. Все мои "притягивания" были конкретными ответами на твои конкретные аргументы. А сейчас я могу лишь опять отослать тебя к моей критике твоей способности не следить за контекстом. Я вообще встреваю только когда вижу конкретные высказывания, на которые можно конкретно же ответить.

I>Хорошо хоть бутстраппер оставил в покое.

Кто здесь?

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

CC>>Не рассказывай нам, плюсникам, какая IDE нам же и лучше.
CC>>Мы этих устриц ежедневно жрём.

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