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

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

E__>>Я чего-то не понимаю, на кой вообще битмапу(который, по сути, тупо массив байт, вполне себе менеджед, а значит, подвластен GC(или в шарпе это не так? Я только про джаву знаю достоверно)) Release? Не нужен — просто обнуляешь все ссылки на него, пусть сборщик сам разбирается, он прекрасно увидит, что есть крупный массив байт, и на него нету ссылок ни у одного из потоков, и соберет его, когда память начнет кончаться. Зачем вообще эти пляски с бубном?
MK>Ключевое выделено. Парням из банды С++ хочется, чтобы объект собрался не когда память начнет кончаться, а именно когда не будет ссылок.

А смысл?

MK>И еще такой момент: текущая реализации битмапа в Windows Forms — это таки нативный хэндл ОС, в котором GC не властен.

А вот это меняет дело. Я никогда в шарпе с картинками не работал, потому не в курсе. В жабе классы-контейнеры изображений полностью managed, там такой проблемы нет(имеется ввиду стандартный Swing, не SWT).

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

Q>Здравствуйте, -MyXa-, Вы писали:

MX>>Под владением я понимаю — "кто последний, тот и убирает". А если функция владеет объектом, это значит, что она это право может и передать. Или вот, например, если составные части объекта передают, якобы, на "посмотреть" в функцию, то, возможно, они ещё и переживут своего хозяина:
MX>>[Code skipped.]
MX>>В С# есть другие варианты?

Q>Здесь нет ни передачи владения, ни его разделения. Здесь на одну почку ссылаются два человека. Если любой из них умрёт и вызовет Dispose() для себя и подобъектов, то у другого будет невалидная почка.

К чему Вы тут говорите про Dispose? Я код привёл полностью, где Вы его там видите?. _Просто_ "ссылаются два человека" и ни один не владеет? ЗдОрово! Ну-ка, покажите мне — как уничтожить, в таком случае, почку по полной программе (и я опять не имею в виду Dispose, потому, что он — не уничтожение)? Короче, нет никакого способа в C# передать поле (вообще объект) в метод, не передав владения. Так и запишем.

Q>>>Инкремент/декремент на каждый вызов происходит.
MX>>Да, но за то мы получаем возможность не знать когда именно объект уничтожится.

Q>Если ты передаёшь boost::shared_ptr по ссылке, то ты тоже этого не знаешь, и при этом у тебя лишний инкремент/декремент не произойдёт. В который раз я это уже повторяю?

Инкремент/декремент не может быть лишним.
Я не знаю, зачем вы это повторяете. Я никогда boost::shared_ptr по ссылке не передаю. А Вы?

Q>>>>>

void foo(shared_ptr<bitmap> const& b);

MX>>>>Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае...
Q>>>Кому здесь передаётся владение?
MX>>Мало ли кому. Нам же отсюда не видно реализацию. Может foo их складирует куда-то.

Q>При передаче shared_ptr'а по значению создаётся ещё один совладелец — локальный параметр функции. Вызывается копиктор и инкремент для shared_ptr'а, о чём недвусмысленно свидетельствует use_count(). Здесь же — передача shared_ptr'а по ссылке, дополнительных совладельцев не создаётся, владение не шарится. Так-то.

И где экономия?

void foo(shared_ptr<bitmap> const& b)
{
   shared_ptr<bitmap> b_ = b;
   ...
}

MX>>>>Правильно?
Q>>>Нет. Либо в Foo есть и using, и hugeBitmap.Clone(), либо ни того, ни другого, что вероятнее. Для использования ресурса не обязательно разделять владение им.
MX>>Извините, не понимаю — к чему Ваше "Нет", если дальше Вы пишете "Либо в Foo есть и using, и hugeBitmap.Clone()". Я Вам столько букв, а Вы мне — всего три (ну, спасибо, что хоть такие). Где я ошибся — ткните пальцем.

Q>

Q>void foo(RefCounter<HugeBitmap h)
Q>{
Q>  using (h)
Q>  {
Q>    // Использование h.
Q>  }
Q>}
Q>...
Q>foo(hugeBitmap.Clone());
Q>

Q>Такого в природе не бывает. Это всё равно что в плюсовую функцию передать «new int(42)» и внутри сделать «delete p».

А какие проблемы с этим?

MX>>Что значит "вероятнее"?

Q>

Q>void foo(RefCounter<HugeBitmap h)
Q>{
Q>  // Использование h, быть может даже клонирование при необходимости.
Q>}
Q>

"Может быть даже клонирование"! Потрясающе! И чему будет равен стётчик? В каком случае необходимость клонирования?

Имея:

string DecodeCAPTCHA(RefCounter<HugeBitmap> h) // От Вашего варианта отличается только отсутствием опечатки, именем метода и возвращаемым значением.
{
  // Использование h, быть может даже клонирование при необходимости.
}

Нельзя написать так:

string s = DecodeCAPTCHA(new RefCounter<HugeBitmap>(new HugeBitmap("...")));

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

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, -MyXa-, Вы писали:

MX>>Почему-же? Создаём hugeBitmap, счётчик = 1.

MX>>в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using, который уменьшает счётчик; при выходе из foo счётчик = 1; using (внутри которого битмап создавался) вызывает Dispose, счётчик уменьшается до 0, убивается объект.

MX>>во втором случае: счётчик = 1; передаём в foo; в foo свой using, который уменьшает счётчик до 0, убивается объект; при выходе из foo счётчик = 0; пытаемся дальше работать с битмапом, а он не живой — пора палочкой его тыкать.

MX>>Правильно?

КБ>Ну уже если навешивать оберток так навешивать Х)

КБ>

КБ>void foo(RefCounter<HugeBitmap> hugeBitmap)
КБ>{
КБ>    ...
КБ>    using (RefCounterScope scope = new RefCounterScope(hugeBitmap)) // Здесь счетчик увеличивается
КБ>    {
КБ>       ...
КБ>    } // Здесь уменьшается
КБ>    ...
КБ>}
КБ>

Дык, об чём прямая речь! Другой способ есть?

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

E__>Здравствуйте, MxKazan, Вы писали:
MK>>Здравствуйте, Eugeny__, Вы писали:
E__>>>Я чего-то не понимаю, на кой вообще битмапу(который, по сути, тупо массив байт, вполне себе менеджед, а значит, подвластен GC(или в шарпе это не так? Я только про джаву знаю достоверно)) Release? Не нужен — просто обнуляешь все ссылки на него, пусть сборщик сам разбирается, он прекрасно увидит, что есть крупный массив байт, и на него нету ссылок ни у одного из потоков, и соберет его, когда память начнет кончаться. Зачем вообще эти пляски с бубном?
MK>>Ключевое выделено. Парням из банды С++ хочется, чтобы объект собрался не когда память начнет кончаться, а именно когда не будет ссылок.
E__>А смысл?
Привычка

MK>>И еще такой момент: текущая реализации битмапа в Windows Forms — это таки нативный хэндл ОС, в котором GC не властен.
E__>А вот это меняет дело. Я никогда в шарпе с картинками не работал, потому не в курсе. В жабе классы-контейнеры изображений полностью managed, там такой проблемы нет(имеется ввиду стандартный Swing, не SWT).
Сейчас в WPF тоже появился свой битмап, управляемый. А по поводу битмапов в WinForms вопрос интересный. Анализирует ли сборщик объем памяти в целом для процесса, неважно как выделенную, или же только свою управляемую кучу? В первом случае всё ништяк, во втором наверное, придется подождать... Но я точно не скажу, не силен в этом вопросе.

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

MX>Дык, об чём прямая речь! Другой способ есть?
А, об чём? Я вот читаю и всё никак понять не могу: какую задачу то решаем?

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

MK>Здравствуйте, -MyXa-, Вы писали:

MX>>Дык, об чём прямая речь! Другой способ есть?
MK>А, об чём? Я вот читаю и всё никак понять не могу: какую задачу то решаем?

Хотим, чтобы сам вызвался какой-нибудь метод (к примеру, Dispose) сразу, как только ссылок на данный объект не останется.

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

MX>Здравствуйте, Константин Б., Вы писали:

КБ>>Здравствуйте, -MyXa-, Вы писали:

MX>>>Почему-же? Создаём hugeBitmap, счётчик = 1.

MX>>>в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using, который уменьшает счётчик; при выходе из foo счётчик = 1; using (внутри которого битмап создавался) вызывает Dispose, счётчик уменьшается до 0, убивается объект.

MX>>>во втором случае: счётчик = 1; передаём в foo; в foo свой using, который уменьшает счётчик до 0, убивается объект; при выходе из foo счётчик = 0; пытаемся дальше работать с битмапом, а он не живой — пора палочкой его тыкать.

MX>>>Правильно?

КБ>>Ну уже если навешивать оберток так навешивать Х)

КБ>>

КБ>>void foo(RefCounter<HugeBitmap> hugeBitmap)
КБ>>{
КБ>>    ...
КБ>>    using (RefCounterScope scope = new RefCounterScope(hugeBitmap)) // Здесь счетчик увеличивается
КБ>>    {
КБ>>       ...
КБ>>    } // Здесь уменьшается
КБ>>    ...
КБ>>}
КБ>>

MX>Дык, об чём прямая речь! Другой способ есть?

Ой, нет, я ошибся. И с Вами не согласен. new — не нужен потому, что

foo(new RefCounter<HugeBitmap>(new HugeBitmap()));

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

S>Здравствуйте, Константин Б., Вы писали:
КБ>>А насколько практичен в этом отношении Reflection.Emit?
S>Ну... На моей тачке регексы компиляются со скоростью около 1E-5 секунды на символ.
S>То есть для типичных регекспов длиной в сотню символов речь идет об 1й миллисекунде задержки.

Ну чтож. Попробую сделать компилятор регекспов на LLVM. Посмотрим сколько оно выдаст.

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

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

PD>>>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.
MK>>Конкретнее, что за ниша?

PD>Операционные системы, драйверы, утилиты. (только ради бога не надо про Сингуларити)
А ты там С++ много видел, особенно в ОС и дровах?

PD>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).
Расскажи это создателям AutoCad.

PD>ПО с серьезными расчетами.
Пока вы будете писать их на С++, вариант на F# уже давно все посчитает.
А есть еще runtime кодогенерация.


PD>Это то,что первым в голову пришло. Подумать — можно еще добавить.

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

PD>>ПО с серьезными расчетами.
G>Пока вы будете писать их на С++, вариант на F# уже давно все посчитает.

Ага, а потом захочется посчитать на каком-нибудь линуксовом мегакластере. Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно

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

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

PD>>>ПО с серьезными расчетами.
G>>Пока вы будете писать их на С++, вариант на F# уже давно все посчитает.

COF>Ага, а потом захочется посчитать на каком-нибудь линуксовом мегакластере.
Уууу, много ты таких видел?

COF>Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно
Мегакластер на плюсах? Плюсов там и не будет, голый C.

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

PD>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).
G>Расскажи это создателям AutoCad.

Не, ну надоело уже... Что, правда, кроме WPF-морды Автокада упомянуть больше нечего? Вот незадача то... (ах да, ты еще Paint.NET с Photoshop'ом не сравнил )

Здравствуйте, -MyXa-, Вы писали:
...
MX>Я не знаю, зачем вы это повторяете. Я никогда boost::shared_ptr по ссылке не передаю.

Q>>>>>>

void foo(shared_ptr<bitmap> const& b);

MX>>>>>Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае...
...
MX>И где экономия?
MX>

MX>void foo(shared_ptr<bitmap> const& b)
MX>{
MX>   shared_ptr<bitmap> b_ = b;
MX>   ...
MX>}
MX>

При передаче по значению имеет место быть раздутие кода из-за инлайна. Конкретные цифры и степень важности этого — другой вопрос.

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

PD>Операционные системы, драйверы, утилиты. (только ради бога не надо про Сингуларити)
Надо.

PD>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).
PD>ПО с серьезными расчетами.
Ничему из этого нативность не нужна.
Вообще не нужна.
Тут дело лишь в качестве оптимизатора и ни в чем больше.

PD>Это то,что первым в голову пришло. Подумать — можно еще добавить.
Подумай.
Но ничего кроме соооовсем мелких железок у которых соооовсем мало памяти не придумаешь.
Более того туда лучше форт засовывать, а не С++.
Хотя и туда ВМ можно затолкать. Кросскомпиляцией...

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

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

PD>>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).
G>>Расскажи это создателям AutoCad.

H>Не, ну надоело уже... Что, правда, кроме WPF-морды Автокада упомянуть больше нечего? Вот незадача то... (ах да, ты еще Paint.NET с Photoshop'ом не сравнил )
Да, незадача. Приводили тут списочек прог, да только некоторым пофиг на него, делают вид, что его нет.. Кстати, о Paint.Net. Я тогда искренне поверил, что прога тормознутая. Так как сейчас обильно приходится заниматься дизайном приложения, потребовался редактор покруче Paint, но простой. Скачал Paint.Net Portable, 1.5 мега весом. И прямо вообще офигел. А обещанных тормозов то нет! На моем домашнем компе, который и 3 года назад то был средний и с тех пор не видел ничего нового, кроме винтов, Paint.Net просто летает. Так что, всё больше убеждаюсь, что приставка ".Net" действует на некоторых как красная тряпка для быка, хочется искать тормоза даже когда их нет.

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

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

WH>Тут дело лишь в качестве оптимизатора и ни в чем больше.
Да не только. Дело вообще в контроле над компом...

Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...

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

E>Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...
Ты наверное искренне считаешь, что ХиндиС — это мега-супер-пупер прикол, из-за чего мы все испадстола пишем. Ахха

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

MK>Ты наверное искренне считаешь, что ХиндиС — это мега-супер-пупер прикол, из-за чего мы все испадстола пишем. Ахха

Да нет, набирать просто удобнее...

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

E>Может быть и не нужна, но широко используется...
Можешь назвать причины кроме исторических и личностных?

E>Так что спецы в перечисленных областях делают иной выбор, чем ты...
Апеллирование к личности. Железный аргумент.

WH>>Тут дело лишь в качестве оптимизатора и ни в чем больше.
E>Да не только. Дело вообще в контроле над компом...
И что ты контролировать собрался?

E>Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...
А где я сказал .NET?
Я к этой поделке отношусь весьма отрицательно.
В дизайне этой ВМ слишком много косяков. Но это тема для другого флейма.

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

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

WH>>Ничему из этого нативность не нужна.
WH>>Вообще не нужна.
E>Может быть и не нужна, но широко используется... Так что спецы в перечисленных областях делают иной выбор, чем ты...
А "спецы в перечисленных" областях чтонить кроме С++ знают?

WH>>Тут дело лишь в качестве оптимизатора и ни в чем больше.
E>Да не только. Дело вообще в контроле над компом...
Дело как раз в оптимизаторе.
Мне абсолютно пох будет что там происходит с компом если я на каком либо языке смогу писать код, который в 10 раз быстрее выполняется, чем любой другой, на линейных вычислениях.
И подавляющему большинству программистов тоже.

E>Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...
О ужас, ручками код оптимизировать... как же с этим жить?
Кроме того если и надо оптимизировать, то числомолотильные алгоритмы, в остальном и так .NET быстрее работает.