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

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

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

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

вполне верю что где-то выскочит SOE, но, думаю, это будет лечится -Xss10m да и рекурсия в наше время весьма редкий зверь все-таки...

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

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

Он таки резиновый, хотя, естественно, и ограничен доступной памятью, в языках, в которых стек это деталь реализации. Например, кадры активации в ST, могут для скорости работы мапится на стек, а при исчерпании такового, "материализоваться" в полноценные объекты и переезжать в кучу, освобождая стековое пространство.

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

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

N>>в общем да — ну так рантайм знает в точности сколько что занимает и совершенно свободно посчитает сколько туда можно пихать.
WH>Вот только может возникнуть проблема с рекурсивными алгоритмами которые безпроблем выполнялись на предыдущем рантайме, а в новом будут вываливаться по StackOverflowException.
WH>Вобщем тут не все так однозначно.
Я подозреваю, что в современном мире вызвать StackOverflowException можно только по ошибке. Уж очень там лимит зверский стоит.

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

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

IT>>Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.

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

При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.

Sinclair wrote:
>
> N>>в общем да — ну так рантайм знает в точности сколько что занимает и
> совершенно свободно посчитает сколько туда можно пихать.
> WH>Вот только может возникнуть проблема с рекурсивными алгоритмами
> которые безпроблем выполнялись на предыдущем рантайме, а в новом будут
> вываливаться по StackOverflowException.
> WH>Вобщем тут не все так однозначно.
> Я подозреваю, что в современном мире вызвать StackOverflowException
> можно только по ошибке. Уж очень там лимит зверский стоит.

В линухе, если используются потоки, то каждый поток по умолчанию
получает 10 MB стека.

Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем
более, что в форточках 1) процесс обычно имеет 2 GB адресного
пространства, а не 3, как в линухе 2) в форточках потоками принято
пользоваться активно.

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

PD>Конечно, это можно и сейчас сделать, вынеся код в отдельную функцию и вызывая его в первый раз из конструктора, а потом просто так. Но ИМХО это было бы логичнее. Т.е. я пересоздаю объект без перевыделения памяти.

Я вот другого не пойму. Что же вы все так за бедолагу GC переживаете?

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

IT>Я вот другого не пойму. Что же вы все так за бедолагу GC переживаете?

Жалко его. Столько раз на него собак вешали

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

S>Я думаю, потому, что это нарушит ссылочную целостность. У нас уже есть ссылки в других объектах на этот объект. И эти другие объекты будут крайне удивлены внезапной смерти того объекта и возникновению нового. У меня сейчас сильнейшее дежа вю, т.к. данная тема уже точно поднималась.

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

C c = new C(...);
// use
c.prop1 = ...;
c.prop2 = ...;
// etc.

а это ничем не отличается от повторного вызова ctor в конечном счете. Я ведь не имею в виду, что объект заново размещается, а только изменяет свое состояние так, как если бы все его поля "исчезли" и были установлены заново.


S>Выделение памяти в управляемой среде — сверхестественно дешевая операция, сравнимая со стоимостью выделения памяти на стеке в C++. Не там воду ищешь.

Выделение — да. Но не сжатие кучи. А вот там сжимать пришлось бы меньше. Представь себе. что тебе нужно по ходу действия создать десяток кистей. Сейчас для каждой new, потом их всех уберет GC. В моем варианте new будет один, так что и ему придется лишь один объект убрать.

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

S>

S>Brush br = new Brush(Color(0,0,255));
S>br.Init(Color(0,0,255));

S>

Согласен, конечно. Но с конструктором было бы элегантнее.

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

IT>При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.

во-первых само наличие финалайзера это кривые руки программера, таких классов очень мало (по крайней мере в Жабе, думаю 1/10000), и для них просто оптимизация запрещена.

PD>а это ничем не отличается от повторного вызова ctor в конечном счете. Я ведь не имею в виду, что объект заново размещается, а только изменяет свое состояние так, как если бы все его поля "исчезли" и были установлены заново.

Павел, откровенно говоря, я лично не понимаю смысла в такой "оптимизации".

Ок, пусть у вас есть объект. У него 20 внутренних полей. Вы переаллоцируете основной объект, сохраняя для него изначальную ссылку. Но при этом все эти 20 внутренних полей устанавливаются в изначальное значение (ссылки меняются).

По сути — из 21 объекта вы меняете ссылки не 21 объекту, а 20. Вот такая вот "оптимизация"

IT>Я вот другого не пойму. Что же вы все так за бедолагу GC переживаете?

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

Pavel Dvorkin,

> ПК>Почему?
>
> Я имел в виду без вызова деструктора.

В общем случае без соответствующего аналога, вызова Dispose, это нельзя сделать и в managed.

N>во-первых само наличие финалайзера это кривые руки программера, таких классов очень мало (по крайней мере в Жабе, думаю 1/10000), и для них просто оптимизация запрещена.

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

Alxndr,

> ПК>

> ПК>C* c = new C(1);
> ПК>. . .
> c->>~C();
> ПК>new (c) C(2);
> ПК>. . .
> ПК>delete c;
> ПК>

>
> Вопрос терминологический, но по-моему, здесь не происходит повторного вызова конструктора
> Конструктор чего вызывается повторно? Ведь объект, на который указывает c не существует после вызова соответствующего деструктора

В таком случае в данном примере и в первый раз конструкторы "не вызывались": до исполнения конструктора объект не существует.

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

_>это не кривые руки программера, а производственная необходимость. Количество классов тут ни при чем.

да ну? это парадигма в дотнете чтоли такая — заставим ЖЦ подольше работать (даже concurrent коллектору иногда надо останавливать всю систему) выполняя финалайзеры? тогда понятно почему тут народ так заботится о ЖЦ.

в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?

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

>Более того, ИМХО это вообще верно — чтобы качественно программировать на уровне N, надо понимать, что делается на уровне N-1. Уметь самому программировать на уровне N-1 не обязательно.

N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?

Ссылка на файл, ссылка на соединение и т.п. вещи. Их нужно закрывать после закрытия работы приложения (к примеру), правильно ведь?

vitaly_spb,

> N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?
>
> Ссылка на файл, ссылка на соединение и т.п. вещи. Их нужно закрывать после закрытия работы приложения (к примеру), правильно ведь?

Что характерно, зачастую -- задолго до.

ПК>Что характерно, зачастую -- задолго до.

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