Цитата

Интересно, а как ты на STL кодил без них?

А контейнер из стандартных умных указателей(auto_ptr ) вообще лучше не создавать(читать Мейерса), а то там семантика такая, что при присваивании указателя, меняется владелец.

Вот так и кодил.
А выражение

Цитата

std::auto_ptr<Buffer> m_buffer;

Встречал,но ни разу не пользовался

Добавлено @ 21:16
Я ввобще шаблонами редко пользуюсь
Все что надо есть в МФС.А динамичексого массива и списка хвтает с головой.
Но если столкнусь,всегда смогу заглянуть в книгу
Добавлено @ 21:18
Кстати.Еще вот вопросик.
А как лучше пользоваться времеными обьектами(вспомагательными)-обьявлять в классе и хранить до конца проги или в функции,и использовать только когда она работает?

Это сообщение отредактировал(а) Coocky - 18.3.2005, 21:13

Цитата(DENNN @ 18.3.2005, 00:15)

Гораздо интересней как на STL вместе с ними кодить можно? smile Там ведь в контейнерах произвольно могут объекты в новые участки памяти копироваться и умные указатели работать перестают.

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

Цитата

Для этого делаются контейнеры умных указателей

Ну и понеслись в лес
Хорошо таким в консоли баловаться.А когда 10-12 классов в проге,да и МФС,забываешь о всех премудростях
Добавлено @ 21:25
А на вопросик-то еще не ответили,про обьекты.А ведь тоже память жрут,хоть и разок при открытии

Цитата(Coocky @ 18.3.2005, 10:24)

Хорошо таким в консоли баловаться.А когда 10-12 классов в проге,да и МФС,забываешь о всех премудростях smile

Как раз наоборот.
Добавлено @ 21:37

Цитата(Coocky @ 18.3.2005, 10:12)

А как лучше пользоваться времеными обьектами(вспомагательными)-обьявлять в классе и хранить до конца проги или в функции,и использовать только когда она работает? smile

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

chipset

Цитата

Зависит от того - нужен ли он тебе в течении всей жизни программы, или только на короткий срок, сам понимаешь

А если их много,и нужны они на протяжении жизни проги,но не всегда
chipset

Цитата

Как раз наоборот

Пример ?

Цитата(Coocky @ 18.3.2005, 10:40)

Пример ? smile

В сложных программах - больше классов - больше память замусоривается при неправильном использовании..
Добавлено @ 21:46

Цитата(Coocky @ 18.3.2005, 10:40)

А если их много,и нужны они на протяжении жизни проги,но не всегда smile

Зависит от конкретной задачи.

chipset

Цитата

В сложных программах - больше классов - больше память замусоривается при неправильном использовании..

Это намек на шаблоны?
А не легче ли через поиск все new найти,и сопоставить им соответсвующие delete ?

Цитата(Coocky @ 18.3.2005, 10:51)

А не легче ли через поиск все new найти,и сопоставить им соответсвующие delete smile ?

Не забывай что после того как ты сделаешь delete, другой класс может рассказать тебе про Access Violation.

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

Coocky, не всё так страшно.. Просто надо правильно проектировать програму и выявлять области жизни обьектов

Это сообщение отредактировал(а) chipset - 18.3.2005, 22:10

chipset

Цитата

Просто надо правильно проектировать програму

Короче,завязали с темой
А то уже наговорили про меня целую кучу
Кстати,а нет ли литературы(опять же в электронке) как правильно делать проги(не программировать ).
А то начинаю с интерфейса под ключ.затем пишу код для одного действия.затем понимаю,что что-то упустил,кидаюсь туда.забывая зачем делала первое.Ну а в конце свожу все к обновлению кнопок на тулбаре

Цитата(Coocky @ 18.3.2005, 11:15)

Кстати,а нет ли литературы(опять же в электронке) как правильно делать проги(не программировать smile ). А то начинаю с интерфейса под ключ.затем пишу код для одного действия.затем понимаю,что что-то упустил,кидаюсь туда.забывая зачем делала первое.Ну а в конце свожу все к обновлению кнопок на тулбаре smile

Вкратце:
1) Требования - определяешь что тебе надо будет от программы, конкретно.
2) Спецификация - разбиваешь требования на отдельные, логические модули.
3) Проектирование - на бумажке или в UML, по спецификации строишь иеархию обьектов и то как они пересекаются.
4) Кодинг - запускаешь студию и начинаешь лениво набивать классы, в промежутках играя в Quake3:Arena.
5) Переделывание проекта нахрен - после того как ты понимаешь что третья часть была полным бредом и всё надо делать 100% наоборот, переделываешь её вышеуказанным методом.
6) Интерфейс - ваяешь сам, или заставляешь дизайнеров сваяивать интерфейс и прибиндить его к событиям твоего кода.
7) Переделывание интерфейса
8) Тестирование - мучаешь свою программу, используя изощренные садистские методы, пока не добьешься стабильной работы.
9) Можно называть программу pre-alpha 0.01 и начинать тестирование на живых людях (до-поры до -времени).

Это сообщение отредактировал(а) chipset - 18.3.2005, 22:25

И так по твои пунктам делаю-
1.Заказчики добавляют каждый раз новое
2.Не делаю.Но может в уме
3.Да у меня и ручки-то нет
4.Делаю.Надо поставить еще QUAKE
5.Переделывю после того,как понимаю,что 70%-бред.
6.Единственое,что хорошо получается
7.Неа сразу и под ключ
8.Что-то всегда зупускаю все равно,потому и бегаю потом к заказчикам и храню сорцы
9.Да.Обычно типа Демо-версия
Ну а если серьезно?

Цитата(Coocky @ 18.3.2005, 11:36)

Ну а если серьезно?

Я на полном серьёзе, если выкинуть Quake.

Цитата(Coocky @ 18.3.2005, 11:36)

1.Заказчики добавляют каждый раз новое smile

Значит надо делать гибкую структуру и драть с заказчиков деньги.

Добавлено @ 22:48

М	Завязываем с оффтопом или я буду разделять тему.