savaDAN,
> ПК> А ведь можно было вместо этих "приседаний" завести специальный тип указателя, обозначавшего именно эту семантику, и тогда компилятор стоял бы на страже, и комментарии/документация подобного содержания не понадобились бы...
> А давайте вы мне дадите конкретный пример,
Запросто. Только давайте проясним один момент...
> а я покажу вам как вследствие невнимательности/неопытности разработчика можно допустить ошибку в его использовании
Расшифруйте, что такое в вашем понимании "неопытность". Это незнание каких-то вещей, или общее отношение, при котором человек не стремится разобраться в классе/компоненте, которые начинает использовать?
> В общем у меня начинает складываться впечатление, что мы спорим об очевидном, просто ради спора. > Если бы в С++ все было хорошо с управлением памятью никто бы GC не изобретал.
: определения семантики владения объектами. Т.е. кроме освобождения памяти при удалении объекта еще нужно совершать некоторые действия. В C# это делается с помощью Dispose. Попробуйте применить ваши рассуждения к Dispose, чтобы я лучше понял, о чем идет речь...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>N-ный участник форума задает этот вопрос. Тенденция, однако. E>Пора на заставке Януса написать: Использован Jet, поскольку .Net-овского аналога пока нет. Ждем-с.
Вообще-то есть SQL Server-ный вариант. И он вроде как летает.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
VD>>Такое сообщение бывает если параллельно запустить Эксес и открыть в нем БД Януса. Вот только это проблемы джета написанного на С++. CC>Дык нету аксесса. Из офиса стоит только ворд+excel. Все остальное принудительно не ставилось.
Короче, приведи стэк-трэйс и поговорим конкретно. Пока что я склоняюсь к мысли, что ты что-то путашь.
CC>Шож ета такие правильные .нет девелоперы да такой неправильный Jet использовали? Почему не .нет-овское что нить? ась?
Альтернатива? Написать для проекта создающегося в свободное от отдыха иработы время собственную БД?
Кого не устраивает Эксес может попробовать использовать Сиквел. Текущая версия Януса это позволяет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Короче, приведи стэк-трэйс и поговорим конкретно. Пока что я склоняюсь к мысли, что ты что-то путашь.
Как только в очередной раз вывалится — постараюсь не забыть что обещал тебе показать трейс.
Здравствуйте, NotGonnaGetUs, Вы писали:
CS>>Это вот родной код фирмы Sun:
CS>>
CS>>
CS>>Вопрос: означенная фирма до конца ли понимает "назначение управляемых сред"? Как думаешь?
NGG>Проблема с Dimension не в том, что "фирма не понимает". NGG>"Просто" был допущен архитектурный просчёт, пока все ещё были молодые и не опытные
Архитектурный просчет называется "GC он умный, сам все уберет" я так понимаю.
CS>>ПыСы: Там еще кстати замечательное такое слово synchronized используется. "Для знатоков штучка".
NGG>Не скажешь в какой версии jdk ты нашёл этот код? А то я всё перерыл — нет такого
Это из Personal Java сейчас это по-моему J2ME называется.
Первое что попалось под руку.
Вот пример из стандартного набора примеров стандартного SDK
Я выделил те места где в методе on paint аллоцируются новые объеты:
public class BullsEye extends DemoSurface {
public void drawDemo(int w, int h, Graphics2D g2) {
Color reds[] = { Color.red.darker(), Color.red };
for (int N = 0; N < 18; N++) {
float i = (N + 2) / 2.0f;
float x = (float) (5+i*(w/2/10));
float y = (float) (5+i*(h/2/10));
float ew = (w-10)-(i*w/10);
float eh = (h-10)-(i*h/10);
float alpha = (N == 0) ? 0.1f : 1.0f / (19.0f - N);
if ( N >= 16 )
g2.setColor(reds[N-16]);
else
g2.setColor(new Color(0f, 0f, 0f, alpha));
g2.fill(new Ellipse2D.Float(x,y,ew,eh));
}
}
Т.е. приложение ничего не делает но аллокация идет непрерывно.
Вот характерный скриншот: справа — memory monitor.
Видим явную пилу. Провалы — это сборка мусора — приложение застывает.
Извиняюсь но такое решение UI грамотным я называть не могу.
Здравствуйте, c-smile, Вы писали:
CS>Архитектурный просчет называется "GC он умный, сам все уберет" я так понимаю.
Сарказм — это хорошо. Только в просчёт был в другом
CS>Вот пример из стандартного набора примеров стандартного SDK CS>[java] CS>public class BullsEye extends DemoSurface {
Это не библиотеки java — это демки, а в них, хоть это и не красиво, но не фатально писать плохой код.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Конвеер неприменим к разработке дизайна продуктов, каковым является программирование при построении аналогий с производством "материальных" продуктов.
Черт его знает. С одной стороны в плане аналогий ты конечно прав (и вобще меня последнее время дурацкие аналогии софтостроения с автомобилями, зданиями, табуретками и прочей фигней задолбали, а особенно задолбали далеко идущие из этих аналогий выводы). С другой стороны не могу не согласится, что точка приложения интеллектуальных усилий смещается все больше со стороны машинных кодов в сторону проектирования и планирования. В этом отношении весьма показателен подход Team System, когда управление требованиями, разработка архитектур на разных уровнях, написание кода, его тестирование и, наконец, сценарии развертывания объединяются в один непрерывный итеративный процесс, в котором непосредственно написатели кода играют отнюдь не самую главную роль.
AndrewVK,
> С другой стороны не могу не согласится, что точка приложения интеллектуальных усилий смещается все больше со стороны машинных кодов в сторону проектирования и планирования.
Это всегда так было.
> В этом отношении весьма показателен подход Team System, когда управление требованиями, разработка архитектур на разных уровнях, написание кода, его тестирование и, наконец, сценарии развертывания объединяются в один непрерывный итеративный процесс, в котором непосредственно написатели кода играют отнюдь не самую главную роль.
Я отрицательно отношусь к "архитекторам", непосредственно не пишущим код: ИМХО, они достаточно быстро "теряют нюх". Итеративные процессы не являются новинкой, введенной Team System, а существовали уже задолго до, и начались именно с небольших команд, где все что-то делают "руками": Lead Developer/Architect ощутимую часть времени пишет код, Lead QA ощутимую часть времени занят непосредственным исполнением тестов и т.п.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> С другой стороны не могу не согласится, что точка приложения интеллектуальных усилий смещается все больше со стороны машинных кодов в сторону проектирования и планирования.
ПК>Это всегда так было.
Ну вобщем да. Единственное, происходит этот процесс не линейно, а скачками.
ПК>Я отрицательно отношусь к "архитекторам", непосредственно не пишущим код: ИМХО, они достаточно быстро "теряют нюх".
Одно другому не мешает. Архитектор конечно писать код должен, но деньги ему платят совсем за другое.
ПК> Итеративные процессы не являются новинкой, введенной Team System, а существовали уже задолго до,
Дело не в императивности, дело в подходе. Когда нет жестко очерченой границы между разработкой и деплойментом, к примеру.
DAN>Брукс об этом писал за 20 лет до Джоэла, ДеМарко с Листером об этом писали, МкКоннел об этом писал. Лучше бы их в пример привели, чем статьи глубоко уважаемого Джоэла, который по сути колумнист и автор системы багтрекинга.
Привёл его потому как его читал недавно и он быстрее вспомнился. Кроме того в его статьях кратко и с юмором делается квинтессенция из процитированых вами авторов, кроме того с конкретнымы примерами в современных реальных условиях разработки.
DAN>Теперь по теме: Забивать гвозди микроскопом, во-первых, очень дорого, во-вторых, неэффективно, в-третьих, микроскоп сломается и уйдет в другую фирму потому как хочет чтобы им микробов смотрели, а не гвозди забивали.
Ну это уже задача руководства как этот микроскоп удержать.
DAN>Обществу, грубо говоря, важнее 5 млн. табуреток, чем 1 один стул выполненный как произведение искусства, даже не смотря на то, что у табуретки качество куда ниже.
При Союзе вырабатывалось много безполезных вещей, которые тут же шли на свалку, обувь в которой невозможно было ходить, мебли которые без ножовки и молотка нельзя было собрать.
В начале топика автор привёл результат такой идеологии система просто не работает, всегда есть какой-то критерий минимального качества, если им пренебречь то получаем плачевные результаты.
eao197,
> Добавленный в C# unsing уже упрощает работу с ресурсами. Но это не RAII. Нормально сделан RAII в сочетании со сборкой мусора в языке D. Да только D пока в таком состоянии, что очень стремно на нем проекты делать.
Еще в C++/CLI или C++ плюс внешнаяя GC (например, Hans Boehm).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Sinclair,
> Кстати, о птичках. Управление неуправляемыми ресурсами из управляемого кода — та еще песня > Особенно это касается взаимодействия нескольких Disposable-объектов. <...>
C++/CLI поможет отцу русской демократии (ессно, кроме ошибок в .Net Framework)
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
DAN>>Обществу, грубо говоря, важнее 5 млн. табуреток, чем 1 один стул выполненный как произведение искусства, даже не смотря на то, что у табуретки качество куда ниже. S>При Союзе вырабатывалось много безполезных вещей, которые тут же шли на свалку, обувь в которой невозможно было ходить, мебли которые без ножовки и молотка нельзя было собрать.
Аналогии неуместны. Мы в свободном рынке, ПО с недостаточным уровнем качества либо слишком дорогое покупать никто не будет.
S> В начале топика автор привёл результат такой идеологии система просто не работает, всегда есть какой-то критерий минимального качества, если им пренебречь то получаем плачевные результаты.
Приведенный автором код отлично работал там, где он и должен был работать (на клиентской машине), после перетаскивания без адаптации на сервер работать перестал, что логично, т.к. я уверен в требованиях нигде не было написано "должен работать под любой нагрузкой".
И я думаю РМ этого проекта, во-первых, на эту функциональность поставил кого-нить послабей, а, во-вторых, ревью не делал, что в данной ситуации является вполне верным решением.
Да, код не самый лучший, да, более опытный разработчик написал бы его куда оптимальней, но опытных разработчиков надо ставить на наиболее важные задачи, а не разбрасываться этим ресурсом куда попало, иначе стоимость проекта возрастет до заоблачных высот.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я отрицательно отношусь к "архитекторам", непосредственно не пишущим код: ИМХО, они достаточно быстро "теряют нюх". Итеративные процессы не являются новинкой, введенной Team System, а существовали уже задолго до, и начались именно с небольших команд, где все что-то делают "руками": Lead Developer/Architect ощутимую часть времени пишет код, Lead QA ощутимую часть времени занят непосредственным исполнением тестов и т.п.
Именно. Так и работаем. Иначе очень быстро можно от реальности оторваться. А если ты становишься неадекватен как руководитель, то наиболее адекватные работники того, голосуют ногами.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Не, ты мне вот покажи на нашем форуме... Ну, должно же быть такое же засилие вопросов как по ликам в С++?
ПК>Вопросы по GC и управлению временем жизни объектов задают каждые несколько дней:
Ненадо поменять суть вопроса. Вопросы по внутреннему встройсву или поведению могут быть в люой области, ты мне покажи засилие вопросв типа "у меня течет ххх... ничего не помогает... как быть?". Вот в форуме "С++" я тебе их тоннами раною.
Точ то приводишь ты в большинстве слвучае вообще к ликам тоношения не имеет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ты мне покажи засилие вопросв типа "у меня течет ххх... ничего не помогает... как быть?"
Ты вопросы читал?
> Точ то приводишь ты в большинстве слвучае вообще к ликам тоношения не имеет.
Речь не об утечках (кто там против "калек" с английского боролся?), а о тех или иных проблемах с GC и управлении временем жизни объектов. "Утечки" -- одна из разновидностей проблем.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> ты мне покажи засилие вопросв типа "у меня течет ххх... ничего не помогает... как быть?"
ПК>Ты вопросы читал?
Я его писал.
>> Точ то приводишь ты в большинстве слвучае вообще к ликам тоношения не имеет.
ПК>Речь не об утечках (кто там против "калек" с английского боролся?), а о тех или иных проблемах с GC и управлении временем жизни объектов. "Утечки" -- одна из разновидностей проблем.
Так есть пробемы или нет? Если нет, то закроем тему. Если есть, то хотелось бы их видеть. Я вот помню только проблему с событиями синглтонов. Явно редкая проблема. Уж точно ни в какое сравнение с постоянным отслеживанием политик владения объектами не идет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
