обработка Exceptions внутри DLL советника - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
memory leak'ов - это от кривых рук программиста может быть. Не слышал, чтобы malloc/free приводили к утечкам памяти. Или нет?
Ну вот простейший пример утечек, которые наверняка есть в ваших программах - это когда вы выделяете память с malloc/free, а потом случайное или не случайное исключение пробрасывает поток исполнения мимо её освобождения.
Те же векторы и хороши в первую очередь потому, что юзер вектора изолируется от забот о памяти - что бы не случилось, в векторе память всегда будет освобождена, потому что при раскручивании стека при обработке исключения будут вызваны все деструкторы созданных объектов.
А как максимум вектор позитивен потому, что хранит понятие "массив" как одну сущность, один единый неделимый объект. С обычным массивом вам надо периодически геморроиться передавая в функцию указатель на массив и длину массива, а с вектором такого нет. Вектор - это и массив, и ассоциированные с ним данные, типа длины. А это в свою очередь позволяет перегрузить операции индексации массива и в дебужном билде отлавливать обращения за пределы массива на лету прямо сразу же, не дожидаясь, пока они затрут что-нить нужное и важное. Таким образом вы получаете не голую последовательность байт неизвестной длины, а объект, который знает и о типе данных, и об их количестве, и о том, как эти данные безопасно освободить, и как безопасно организовать к ним доступ (итераторы), и т.д. и т.п. Раньше вам всё это надо было держать в голове самому, а теперь всё это делает за вас компилятор.
Плюс, поскольку у вектора стандартный интерфейс при необходимости его можно правкой одного только определения объекта заменить на другой контейнер, например, на boost::circular_buffer.
Где-то читал, когда искал готовые классы для контейнеров... Может здесь... http://habrahabr.ru/blogs/cpp/112826/
Хорошо читали? Цитата оттуда:
Это при том, что там огромное количество векторов, бОльшая часть которых пустая, что весьма важно в контексте.
Не верю, что в 2 МБ кода нет ошибок!
Ну вот простейший пример утечек, которые наверняка есть в ваших программах - это когда вы выделяете память с malloc/free, а потом случайное или не случайное исключение пробрасывает поток исполнения мимо её освобождения.
Ещё добавьте требование что в функции должен быть один return на функцию
и прибитая к нему гвоздями секция деинициализации :-).
Ну вот простейший пример утечек, которые наверняка есть в ваших программах - это когда вы выделяете память с malloc/free, а потом случайное или не случайное исключение пробрасывает поток исполнения мимо её освобождения.
В программе не используются исключения. Выделенная память ВСЕГДА освобождается. Единственный шанс обратного - ошибка в деструкторе, но такое исключено.
Gorinych:Те же векторы и хороши в первую очередь потому, что юзер вектора изолируется от забот о памяти - что бы не случилось, в векторе память всегда будет освобождена, потому что при раскручивании стека при обработке исключения будут вызваны все деструкторы созданных объектов.
Мои массивы работают по тому же принципу - освобождение памяти осуществляется целиком всем блоком сразу в не зависимости от того, что там творилось внутри.
Gorinych:
А как максимум вектор позитивен потому, что хранит понятие "массив" как одну сущность, один единый неделимый объект. С обычным массивом вам надо периодически геморроиться передавая в функцию указатель на массив и длину массива, а с вектором такого нет. Вектор - это и массив, и ассоциированные с ним данные, типа длины. А это в свою очередь позволяет перегрузить операции индексации массива и в дебужном билде отлавливать обращения за пределы массива на лету прямо сразу же, не дожидаясь, пока они затрут что-нить нужное и важное. Таким образом вы получаете не голую последовательность байт неизвестной длины, а объект, который знает и о типе данных, и об их количестве, и о том, как эти данные безопасно освободить, и как безопасно организовать к ним доступ (итераторы), и т.д. и т.п. Раньше вам всё это надо было держать в голове самому, а теперь всё это делает за вас компилятор.
В моих классах все так и есть. Один массив - одна сущность, один неделимый блок памяти. Все облачено в классы, никаких доп.параметров передавать не надо. Все очень просто и прозрачно.
Gorinych:
И это есть. Более того, есть интерфейсный класс, предлагающий унифицированный интерфейс доступа как к индикаторному буферу, так и к буферу таймсерий, передаваемому по ссылке из терминала. Реализованы даже функции терминала типа iHighest, iLowest.
В общем, в чистом виде массивы естественно не используются. Они облачены в классы, классы представляют собой очень четкую структуру, работает все быстро, прозрачно, структура классов по сути эмулирует работу терминала. Хоть я и не работаю с векторами, но реализация массивов у меня не хуже. Конечно, можно было бы использовать вектора, но я профессионально не занимаюсь программированием и когда полез искать на чем бы реализовать динамические массивы, то примеры реализации на векторах мне не понравились (особенно по отзывам), разбираться глубоко я не стал, в итоге сделал сам проще и нагляднее.
Я уже давно не занимаюсь программированием, но за годы, потраченные ранее на "игры в программирование" я научился писать программы без ошибок. Просто нужно понимать, что происходит при выполнении обычных команд ... Те, кто писал на ассемблере меня поймут.
Ггг....
Ещё добавьте требование что в функции должен быть один return на функцию
и прибитая к нему гвоздями секция деинициализации :-).
Это как раз признак дурного тона - делать такие функции, что они создают и убивают объекты. Создание объектов должно быть в конструкторе, а уничтожение - в деструкторе и тогда про деинициализацию не придется беспокоиться. Как я уже писал - утечки памяти от кривых рук... Ну может еще и от непонимания принципа работы программы... Это лечится только изучением языка более низкого уровня. К сожалению, сейчас это "не модно".
Ну вот простейший пример утечек, которые наверняка есть в ваших программах - это когда вы выделяете память с malloc/free, а потом случайное или не случайное исключение пробрасывает поток исполнения мимо её освобождения.
Кстати, информация к размышлению - SEH не позволяет экранировать куски кода, выделяющие память (вложенные функции не в счет). Видимо, не случайно это - чтобы не было утечек памяти.