Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Клуб профессиональных программистов :: Выпуск #4




В этом выпуске мы публикуем отрывок из статьи Михалыча, финальной в серии о присваивании в C++.

Интересные темы на форуме

В данном топике, который возник как естественное расширение темы тестирования, предлагаю обсудить следующие вопросы:

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


Ребяты! Тут мы кое с кем (не будем говорить с кем, хотя это был Альф) посоветовались и подумали, что может быть кому-то из программистов будет интересна тема о тестировании программ и использующихся для этого методах и инструментах? Ну возможно и какой-никакой профессиональный тестировщик забежит.

Пожалуйста, кого занимает подобная тематика, скажите об этом.


Проект со скрипом, но продолжается.


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


operator= Рассмотрим подробно.
Часть 2. Проверка на присваивание самому себе. А зачем?

Итак, продолжим подробное рассмотрение функции operator=. В этот раз разберемся, зачем же нужна проверка на присваивание самому себе.

Когда возникает ситуация с присваиванием самому себе? Ситуация "по определению проблемы" выглядит так:

class Something { … //содержимое класса … };
Something S;
S=S;

Трудно придумать, зачем такая конструкция может понадобиться. Тем не менее, она вполне допустима правилами С++. Более приемлемой выглядит такая запись:

Something &W = S;
S=W;

Несколько менее очевидно, но то же самое. Здесь W – это просто другое обозначение для S. Это ссылка, инициализированная S. То есть объект S просто имеет теперь два разных "имени". Такое совмещение имен может возникнуть в самых разных случаях, поэтому такую возможность просто необходимо учитывать.

Теперь давайте посмотрим, к чему приводит отсутствие проверки на присваивание самому себе.

В статье "Классы. Копирование и присваивание. Часть 4" уже был рассмотрен вопрос, как реализовать копирование через присваивание для объектов производных классов. Там говорилось о том, что оператор присваивания производного класса должен вызывать оператор присваивания своего базового класса. А если базовый класс для него и сам является производным от другого? И такая иерархия очень длинная? В таком случае, если в самом начале оператора присваивания обнаружится ситуация с присваиванием самому себе, можно (и нужно) просто сразу выйти из него, избегая целого ряда ненужных функциональных вызовов. При этом как минимум может повыситься эффективность.

Но не это главное. Вспомните – оператор присваивания перед тем как выделить новый блок памяти, должен для начала освободить ресурсы, выделенные объекту ранее (то есть избавиться от старых значений). При присваивании самому себе освобождение памяти может просто "угробить" старые ресурсы, которые могут понадобиться для создания новых.

Смотрим на примере...


А теперь прощаемся с Вами до следующего выпуска.

                                        С уважением, команда Клуба.




В избранное