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

CS>1) А зачем там полиморфизм?
Если честно, то я с System.Drawing еще вообще не разбирался (отсюда и глупые ошибки). Поэтому не могу сказать, насколько там оправдан полиморфизм.

S>>Тут возникает такой занятный вопрос — а как добиться в твоем коде эффекта, аналогичного, к примеру, LinearGradientBrush?
S>>Тут одним static class Color не обойдешься.
CS>Посмотри на список конструкторов.
Посмотрел.
CS>В моем случае это
CS>будет простой набор методов
CS>Graphics.setGradientBrush(...) Это если оно надо.
А, то есть ты предлагаешь сделать в Graphics по методу на каждый конструктор одного из потомков кисти? Может быть, оно и оправдано. Хотя я не уверен: дело в том, насколько удобно это будет в применении. У тебя не будет возможности в одном месте решить, какой кистью закрашивать, а в другом — какую фигуру нарисовать. Так бы ты сделал метод DrawRectangle, принимающий параметры прямоугольника и кисть, которая взята откуда-то снаружи (из преференсов пользователя, к примеру). И он бы работал для всех кистей, независимо от того, в каком порядке что вызывалось. А при твоем способе нужно следить за тем, чтобы ненароком не испортить состояние Graphics лишним вызовом setXXX().
CS>Полиморфизм вещь хорошая, но там где он нужен. Все — в меру. Как всегда.
Верно.

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

CS>Вот такие вот мои мысли в слух если они кому интересны.

Мысли интересны, но не кажется ли тебе, что это можно выразить короче ? А именно — для достаточно часто выполняемых коротких операций не надо дергать кучу , если это возможно и не противоречит высшим идеям При этом неважно, управляемая она или нет. Твой пример можно вполне на неуправляемый С++ перевести, и он там будет так же точно выглядеть, только явный вызов delete добавится. И эффекты будут те же — по скорости.

У меня, кстати, этот вопрос постоянно с моими студентами возникает. То и дело вижу у них такое

POINT* pPoint = new POINT[3]; // именно константа

и я уже устал объяснять им, что проще

POINT Point[3];

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

CS>И я о том. А зачем собственно. Говоря о brush, кому-нибудь нужна эта самая brush как объект с атрибутами?

Ну... если речь о slid-brush, то да. А если о PathGradientBrush, да еще и с Blend/ColorBlend + TransformationMatrix, то аттрибутов много. Учитывая, что Brush — это все-таки абстракция GDI (св-ва заливки), то все простые и сложные случаи выделили в один класс. Pen — тоже самое. И его можно создавать на основе Brush в т.ч..

IT>> Ну запустится GC не три раза за время работы программы, а четыре

CS>При отработке события WM_PAINT jsmile-demo.exe вообще ничего не аллоцирует в Java коде ибо не требуется.

В Java есть своя изюминка. "Маленькие" объекты, область видимости которых не выходит за локальный контекст, JavaVM частенько располагает прямо на стеке. Жаль, что .Net VM пока не умеет аналогичное.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У меня, кстати, этот вопрос постоянно с моими студентами возникает. То и дело вижу у них такое
PD>POINT* pPoint = new POINT[3]; // именно константа
PD>и я уже устал объяснять им, что проще
PD>POINT Point[3];
PD>
Ну это не то чтобы проще. Я в свое время помнится старался тщательно объяснить студентам основные паттерны освобождения памяти с точки зрения времени жизни. Типа идея в том, что чем больше мы отдадим RTL информации о порядке освобождения наших ресурсов, тем лучше он станет работать:
— статические объекты, которые вообще не надо освобождать.
— автоматические объекты, которые освобождаются всегда в порядке, обратном выделению
— динамические объекты, которые освобождаются в произвольном порядке.
(есть и другие паттерны, но я их сам никогда не пользовал )
С этой точки зрения, дело не столько в том, что поинты маленькие и им будет хорошо на стеке, сколько в том, что они не нужны сразу по выходу из текущего скоупа.
Т.е. POINT Point[3] — не проще, а точнее.
Принудительное размещение таких объектов в динамической памяти не дает шанса схитрить на их освобождении. Есть примеры библиотечных классов, которые принимают решение о размещении на стеке либо в хипе в зависимости от параметров конструктора.

З.Ы. К сожалению, не везде можно быть столь оптимистичным. Я вот помню свою первую программу на С++. Я там попытался сохранить содержимое текстового экрана для восстановления при выходе из программы, и тут же нарвался на переполнение стека. Я уж и не помню, какая там была модель памяти, но 4 килобайта на стеке ее моментально убили . Преподаватель мне тогда накрепко сказал, что в стеке можно выделять только что-нибудь крошечное. Если бы я только знал про полноценные библиотеки в те времена...

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

S>Ну это не то чтобы проще. Я в свое время помнится старался тщательно объяснить студентам основные паттерны освобождения памяти с точки зрения времени жизни. Типа идея в том, что чем больше мы отдадим RTL информации о порядке освобождения наших ресурсов, тем лучше он станет работать:

+1

S>- статические объекты, которые вообще не надо освобождать.
S>- автоматические объекты, которые освобождаются всегда в порядке, обратном выделению
S>- динамические объекты, которые освобождаются в произвольном порядке.
S>(есть и другие паттерны, но я их сам никогда не пользовал )

М-да... Я как-то об этом знал до того, как услышал вообще слово "паттерн" . Впрочем, на Фортране был тогда только первый тип...


S>С этой точки зрения, дело не столько в том, что поинты маленькие и им будет хорошо на стеке, сколько в том, что они не нужны сразу по выходу из текущего скоупа.
S>Т.е. POINT Point[3] — не проще, а точнее.

Эффективнее . Вот тебе простой пример

for(int i = 0; i < 1000; i++)
{
POINT* p = new POINT [3];
// и т.д.
delete [] p;
}

for(int i = 0; i < 1000; i++)
{
POINT p[3];
// и т.д.
}

1000 раз дергать кучу там, где можно и один раз не дергать — хорошая, кстати иллюстрация на тему микрооптимизации, за которую меня некоторые ругали . Вот таким невиинным кодом убивают производительность. А с точки зрения дизайна здесь вообще ничего нет — дизайн здесь близко не лежит.
Конечно, я здесь использую свое знание того, что выделение памяти в стеке произведено будет 1 раз, а не 1000 (кстати, это стандартом ИМХО не определяется, формально ведь память отводится при входе в блок, так ?). Но даже если бы 1000 раз — все равно лучше 1000 раз выполнить что-то вроде add esp,..., чем 1000 раз дергать хип менеджер с его поиском в 2-linked списке.



S>З.Ы. К сожалению, не везде можно быть столь оптимистичным. Я вот помню свою первую программу на С++. Я там попытался сохранить содержимое текстового экрана для восстановления при выходе из программы, и тут же нарвался на переполнение стека. Я уж и не помню, какая там была модель памяти, но 4 килобайта на стеке ее моментально убили . Преподаватель мне тогда накрепко сказал, что в стеке можно выделять только что-нибудь крошечное.

Ну не знаю. Никакой проблемы в этом не было, размер стека в любой модели, (кроме tiny, где все вместе в 64К), был ограничен 64 К. Надо было просто _stklen установить. В конце концов никто на запрещщал же в те времена вот такие описания

void f()
{
char a[4096] ;
//....
}

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

VD>Я вот опробовал другую идею. В Graphics кэшируются реальные ресурсы выделяемые ОС.

Простите, Graphics — это System.Drawing.Graphics?

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

IT>Rect в .NET — это value type. Соответственно GC тут не при чём. Проблема с Brush только одна — его нужно диспозить. Занимаемая ею память на эффективность программы никак не повлияет. Ну запустится GC не три раза за время работы программы, а четыре

Лично меня в дот-нете сильно напрягает нечто другое. Вот придумали они механизм взаимодействия managed-unmanaged. И вот у меня unmanaged объект требует довольно много памяти, а GC об этом ничего не знает и нет никакой возможности ему объяснить, что "этот объект дорогой, его надо подметать ASAP". Приходится явно удалять самому — вызывая Dispose или через using, иначе цикл из 10000 итераций отъедает 100-200 мег. Но это получается тот же ручной malloc/free! За что, спрашивается боролись? Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.

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

MS>... вот у меня unmanaged объект ... ... получается тот же ручной malloc/free!

Для unmanaged объекта ручной malloc/free — очень странно, не правда ли?

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

MS>Лично меня в дот-нете сильно напрягает нечто другое. Вот придумали они механизм взаимодействия managed-unmanaged. И вот у меня unmanaged объект требует довольно много памяти, а GC об этом ничего не знает и нет никакой возможности ему объяснить, что "этот объект дорогой, его надо подметать ASAP". Приходится явно удалять самому — вызывая Dispose или через using, иначе цикл из 10000 итераций отъедает 100-200 мег. Но это получается тот же ручной malloc/free! За что, спрашивается боролись? Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.
Не понял что ты хочешь. unmanaged потому так и называется, потому как не контролируем. Это его сильная сторона. И ты можешь спокойно реализовать свой механизм управления памятью.

С уважением, Gleb.

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

GZ> Не понял что ты хочешь. unmanaged потому так и называется, потому как не контролируем. Это его сильная сторона. И ты можешь спокойно реализовать свой механизм управления памятью.

Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.

Здравствуйте, Сергей Губанов, Вы писали:

MS>>... вот у меня unmanaged объект ... ... получается тот же ручной malloc/free!

СГ>Для unmanaged объекта ручной malloc/free — очень странно, не правда ли?

Не понял сарказма. В своей практике на С++ я уже очень давно не пользуюсь ни malloc/free, ни new/delete. Точнее сказать, пользуюсь, но крайне редко и на самом нижнем уровне. Есть такая парадигма RAII. А дот-нетовский GC в этом плане — это возврат к сишным malloc/free.

MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.

То есть ты по 100-бальной шкале вес объекта готов оценить? Мне кажется, GC это может сделать не хуже.

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

_>То есть ты по 100-бальной шкале вес объекта готов оценить? Мне кажется, GC это может сделать не хуже.

Читай внимательнее. GC не может этого сделать в принципе, поскольку он знает только о managed ресурсах, объем которых близок к нулю. А вот что там кроется в unmanaged — он не знает и знать не может. И нет никакой возможности передать ему это знание.

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

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

_>>То есть ты по 100-бальной шкале вес объекта готов оценить? Мне кажется, GC это может сделать не хуже.

MS>Читай внимательнее. GC не может этого сделать в принципе, поскольку он знает только о managed ресурсах, объем которых близок к нулю. А вот что там кроется в unmanaged — он не знает и знать не может. И нет никакой возможности передать ему это знание.

Ты хочеш, что-то в этом духе? :

2. The GC could/would be triggered by various low-resource memory
notifications by the OS.
/.../
In the process, if resource consumption levels appear high
or a new resource usage threshold is hit, the garbage collector is triggered
to flush the caches.

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

MS>Лично меня в дот-нете сильно напрягает нечто другое. Вот придумали они механизм взаимодействия managed-unmanaged. И вот у меня unmanaged объект требует довольно много памяти, а GC об этом ничего не знает и нет никакой возможности ему объяснить, что "этот объект дорогой, его надо подметать ASAP". Приходится явно удалять самому — вызывая Dispose или через using, иначе цикл из 10000 итераций отъедает 100-200 мег. Но это получается тот же ручной malloc/free! За что, спрашивается боролись? Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.

    public static class GC
    {
        // Summary:
        //     Informs the runtime of a large allocation of unmanaged memory that should
        //     be taken into account when scheduling garbage collection.
        //
        // Parameters:
        //   bytesAllocated:
        //     The incremental amount of unmanaged memory that has been allocated.
        //
        // Exceptions:
        //   System.ArgumentOutOfRangeException:
        //     bytesAllocated is less than or equal to 0.-or-On a 32-bit computer, bytesAllocated
        //     is larger than System.Int32.MaxValue.
        //
        //   System.InvalidOperationException:
        //     The total amount of memory pressure exceeds System.UInt64.MaxValue.
        public static void AddMemoryPressure(long bytesAllocated);
        //
        // Summary:
        //     Informs the runtime that unmanaged memory has been released and no longer
        //     needs to be taken into account when scheduling garbage collection.
        //
        // Parameters:
        //   bytesAllocated:
        //     The amount of unmanaged memory that has been released.
        //
        // Exceptions:
        //   System.ArgumentOutOfRangeException:
        //     bytesAllocated is less than or equal to 0. -or- On a 32-bit computer, bytesAllocated
        //     is larger than System.Int32.MaxValue.
        //
        //   System.InvalidOperationException:
        //     The total amount of memory pressure is less than zero.
        public static void RemoveMemoryPressure(long bytesAllocated);
    }

Ы?

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


MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.

ИМХО, финалайзеры это чрезвычайно дурной стиль. закрытие системных ресурсов надо делать явно вызывая .close() на объекте а не ждать пока ЖЦ его подберет.

в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.

public Point create(int x, int y) { return new Point(x, y); }

public void draw(Point p, Point pp) { Magic.doDrawLine(p.x, p.y, pp.x, pp.y); }

public static void main(String [] args) {
    Point p = create(0, 0), pp = create(100, 100);
    draw(p, pp);
}

будет преобразована в

public static void main(String [] args) {
    Magic.doDrawLine(0, 0, 100, 100);
}

McSeem2,

> Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.

Не уверен, насколько это работает, но многие рекламируют Safe Handles из .Net FW 2.0.

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

MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.
Эээ. Такого и у менеджед нету. А нету по одной простой причине. Для любого GC важно есть объект, или его нет. Жив или мертв. Остальные вопросы неважны. В остальном — объекты для GC это всего-лишь память которую надо обслуживать, да иногда запускать финализатор. Ему наплевать на наискорейшее удаление. Ему важно сколько памяти осталось.
Если можно легко определить на менеджед, живой ли объект, то сделать менеджер памяти по тому же принципу на C++ достаточно легко. Просто проверяешь размер текущего хипа, и если он превышает определенный параметр, то запускаешь стандартный GC.Collect от Net. Который параллельно будет вычищать как менеджед, так и unmanaged на финализаторах.

С уважением, Gleb.

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

WH> public static void AddMemoryPressure(long bytesAllocated);

Спасибо, но это не совсем то. Оно глобальное и работает только с памятью. А прочие ресурсы?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Простите, Graphics — это System.Drawing.Graphics?

В данном случае речь идет о собственном аналоге.