Вот раньше,когда начинал прогать,скурпулезно удалял все указатели.Теперь прог8и выросли и их количество тоже.Надоело..
А ну ка возрадите во мне эту традицию..Приведите примеры,засорения памяти,так как проблем пока не возникало.
Или это все понты,типа "хороший стиль программирования"

Писал както прогу...
она строила бинарное дерево возможных ходов в одной игре , чтобы на ее основе сделать наилучший выбор хода...
и сделал ошибку в вункции VirtuallFree()...
в итоге она не удаляла старые деревья из памяти..
и после минуты игры санимала 1.5 ГБ памяти.. что приводило к нереальным тормозам системы.....

Очень просто. Бегло просмотрев Ваш стиль программирования при таком раскладе ни один разработчик программного обеспечения не возмет Вас на работу. Дело не в памяти, а в стиле кодирования. Если уж программист не в состоянии уследить за своевременным освобождением памяти, то вопрос о качестве решения более сложных вопросов просто не возникнет. К тому же меня настараживает "скурпулезно". Обычно при правильном подходе к делу за этим не требуется особого пригляда. А если для программиста особый пригляд нужен и утомителен, то ... возникают вопросы в его компетентности. При этом можно даже не упоминать о разработке серверных приложений, которые призваны крутиться годами...

Цитата

хороший стиль программирования

, не ну если тебе самому в кайф писать ГЛЮКАЛО, то тогда....

Цитата

Теперь прог8и выросли и их количество тоже

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

Я действую по принципу : "Выделил память - освободи, когда обьект уже не нужен". Причем освобождаю всегда вручную, не надеясь на якобы встроенные средства.

arajan

Цитата

не ну если тебе самому в кайф писать ГЛЮКАЛО, то тогда....

Ну вот хотелось бы увидеть(услышать) пример глюкала

Цитата

большое количество "прог", признак их простоты

Большое количество не прог,а указателей.

Цитата

оверь чуть возмешся за человеческий проект, сразу задашся вопросами эфф. упр. ресурсами

Уже не один за плечами

Цитата

это целая наука, интелектуальные указатели...итд...

А вот это уже интересней.А где можно посмотреть?
LuckLess Пример понятен.Спасибо.

Цитата

Бегло просмотрев Ваш стиль программирования при таком раскладе ни один разработчик программного обеспечения не возмет Вас на работу

Я сам себе директор В однм лице с программистом и менеджером по продаже-фрилансер,одним словом Мне б еще примерчики.Типа как у LuckLess,хотя надо бы самому попробывать Сделаю ка цикл из выделения памяти на 100000 указателей(может больше?)Гляну...

Цитата(Coocky @ 16.3.2005, 23:11)

Цитата это целая наука, интелектуальные указатели...итд... А вот это уже интересней.А где можно посмотреть?

Читай Рихтера, только они умные называются, вроде. RAdmin ссылку на книгу давал в комп. лите.

Цитата(Coocky @ 16.3.2005, 23:11)

Ну вот хотелось бы увидеть(услышать) пример глюкала

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

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

ДА с учетом даже обычного блокнота мне кажеться имеет смысл работь с ресурсами окуратнее....
интелектуальные указатели

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

pablo ? best regals...

Цитата(En_t_end @ 16.3.2005, 20:44)

Я действую по принципу : "Выделил память - освободи, когда обьект уже не нужен". Причем освобождаю всегда вручную, не надеясь на якобы встроенные средства.

Вручную? Зачем? Если есть возможность, то пусть у меня голова болеть не будет

Код

struct Buffer  {        char buf[10000];  }; class Test {   public:   Test():m_buffer(std::auto_ptr<Buffer>(new Buffer)){}   private:   std::auto_ptr<Buffer> m_buffer;  }; void main() {  std::auto_ptr<Test> t(new Test());  }

Сколько памяти здесь утекло?

arajan неплохо.Спасибо.Интересно будет почитать
pablo

Цитата

Не своевремменное освобождение памяти - это не только осточник трудно улавимых ошибок, плохого стиля программирования, но и причина не понимания программирования вообще.

Спасибо
Займусь вышиванием.
Короче спасибо всем,и тем кто подсказал,и тем кто любит измерять время выполнения своих функций,и хвастаться бабушке с мамой,или изобретать свои методы сортировок,думая что он велик,изобревши велосипед,с одним колесом

Цитата(Coocky @ 16.3.2005, 12:11)

А вот это уже интересней.А где можно посмотреть?

Есть такая книга: С++ для настоящих программистов[RUS,1.8MB,PDF], этим умным указателем чуть ли ни вся она посвящена.. Интересно, а как ты на STL кодил без них?
Зайди - http://www.firststeps.ru/theory/c/r.php?2 и ещё по оглавлению поброди..
Если не хочешь освобождать память, тебе прямая дорога в .NET и Java.
.

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

Цитата(chipset @ 18.3.2005, 00:19)

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

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

Цитата

Интересно, а как ты на 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

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

Цитата

Кстати,а нет ли литературы(опять же в электронке) как правильно делать проги(не программировать smile ).

, существует множество методологий управления и ведения проекта, начиная ЭКСТРИМ ПРОГРАММИНГОМ и заканчиваю RUP - ом, но это действительно тема для отдельного разговора... на мой взгляд все эти дела нужно обсуждать тут -> ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ

Цитата

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

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