Скачать MetaTrader 5
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Пользуйся поиском на MQL5.community. Это просто!
Алексей
63
Алексей 2011.05.02 22:33  
andreybs:

memory leak'ов - это от кривых рук программиста может быть. Не слышал, чтобы malloc/free приводили к утечкам памяти. Или нет?

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

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

А как максимум вектор позитивен потому, что хранит понятие "массив" как одну сущность, один единый неделимый объект. С обычным массивом вам надо периодически геморроиться передавая в функцию указатель на массив и длину массива, а с вектором такого нет. Вектор - это и массив, и ассоциированные с ним данные, типа длины. А это в свою очередь позволяет перегрузить операции индексации массива и в дебужном билде отлавливать обращения за пределы массива на лету прямо сразу же, не дожидаясь, пока они затрут что-нить нужное и важное. Таким образом вы получаете не голую последовательность байт неизвестной длины, а объект, который знает и о типе данных, и об их количестве, и о том, как эти данные безопасно освободить, и как безопасно организовать к ним доступ (итераторы), и т.д. и т.п. Раньше вам всё это надо было держать в голове самому, а теперь всё это делает за вас компилятор.

Плюс, поскольку у вектора стандартный интерфейс при необходимости его можно правкой одного только определения объекта заменить на другой контейнер, например, на boost::circular_buffer.

Комбинатор
15763
Комбинатор 2011.05.02 22:46  
andreybs:

Где-то читал, когда искал готовые классы для контейнеров... Может здесь... http://habrahabr.ru/blogs/cpp/112826/

Хорошо читали? Цитата оттуда:

Производительность немного повысилась, примерно на 1%.

Это при том, что там огромное количество векторов, бОльшая часть которых пустая, что весьма важно в контексте.

Mathemat:

Не верю, что в 2 МБ кода нет ошибок!

+, я тоже почти не верю. Ребятам просто хочется похвастаться.
Андрей
1890
Андрей 2011.05.02 22:58  
Gorinych:

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

Ггг....
Ещё добавьте требование что в функции должен быть один return на функцию
и прибитая к нему гвоздями секция деинициализации :-).
andreybs
609
andreybs 2011.05.03 11:22  
Gorinych:

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

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

Gorinych:

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

Мои массивы работают по тому же принципу - освобождение памяти осуществляется целиком всем блоком сразу в не зависимости от того, что там творилось внутри.

Gorinych:

А как максимум вектор позитивен потому, что хранит понятие "массив" как одну сущность, один единый неделимый объект. С обычным массивом вам надо периодически геморроиться передавая в функцию указатель на массив и длину массива, а с вектором такого нет. Вектор - это и массив, и ассоциированные с ним данные, типа длины. А это в свою очередь позволяет перегрузить операции индексации массива и в дебужном билде отлавливать обращения за пределы массива на лету прямо сразу же, не дожидаясь, пока они затрут что-нить нужное и важное. Таким образом вы получаете не голую последовательность байт неизвестной длины, а объект, который знает и о типе данных, и об их количестве, и о том, как эти данные безопасно освободить, и как безопасно организовать к ним доступ (итераторы), и т.д. и т.п. Раньше вам всё это надо было держать в голове самому, а теперь всё это делает за вас компилятор.

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

Gorinych:

Плюс, поскольку у вектора стандартный интерфейс при необходимости его можно правкой одного только определения объекта заменить на другой контейнер, например, на boost::circular_buffer.

И это есть. Более того, есть интерфейсный класс, предлагающий унифицированный интерфейс доступа как к индикаторному буферу, так и к буферу таймсерий, передаваемому по ссылке из терминала. Реализованы даже функции терминала типа iHighest, iLowest.

В общем, в чистом виде массивы естественно не используются. Они облачены в классы, классы представляют собой очень четкую структуру, работает все быстро, прозрачно, структура классов по сути эмулирует работу терминала. Хоть я и не работаю с векторами, но реализация массивов у меня не хуже. Конечно, можно было бы использовать вектора, но я профессионально не занимаюсь программированием и когда полез искать на чем бы реализовать динамические массивы, то примеры реализации на векторах мне не понравились (особенно по отзывам), разбираться глубоко я не стал, в итоге сделал сам проще и нагляднее.

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

andreybs
609
andreybs 2011.05.03 11:26  
jartmailru:
Ггг....
Ещё добавьте требование что в функции должен быть один return на функцию
и прибитая к нему гвоздями секция деинициализации :-).

Это как раз признак дурного тона - делать такие функции, что они создают и убивают объекты. Создание объектов должно быть в конструкторе, а уничтожение - в деструкторе и тогда про деинициализацию не придется беспокоиться. Как я уже писал - утечки памяти от кривых рук... Ну может еще и от непонимания принципа работы программы... Это лечится только изучением языка более низкого уровня. К сожалению, сейчас это "не модно".
andreybs
609
andreybs 2011.05.03 11:36  
Gorinych:

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


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