Любовь к C++. Как бороться с собственной невнимательностью.

Три раза думаю перед тем, как использовать где-либо ссылку.

++

за годы математики в универе выработалась специфичная внимательность

Я там ссылку не хотел. «&» попал как-то случайно. Смысл то во всем это как раз и было утащить QList<CrShare> со стека в кучу, чтоб можно было выйти из функи.

Обратил бы сразу внимание на то, что там ссылка - исправил бы за 5 сек.

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

Ну вообще валгринд валит эти места на раз: получишь invalid read и дальше стек вызова с указанием файлов исходников и номеров строк.

s/валит/палит/

значит ты ошибся два раза - «забыл» const для параметра, а это уже не просто невнимательность

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

Вот не надо. Щас пришел на работу, помедитировал 5 минут, потом глянул еще раз, увидел, что нет const, подумал, не пил ли я вчера (вроде нет), добавил его и сразу же компилятор сругался.

Но могло быть так, что мне там понадобился бы константный член, и тогда это не помогло бы

> Но могло быть так, что мне там понадобился бы константный член, и тогда это не помогло бы

зачем тебе мог понадобится «const QList<CrShare>» как член класса?

Если CrShare — твой класс, то возможно поможет запрет конструктора копирования в нём

class CrShare
{
  ...
private:
   CrShare (const CrShare &);
}

Всего лишь из-за одного лишнего символа

появился &

Это не просто символ какой-то там. ;-)

> А как вы ловите такие ошибки? Кроме долгого вхождения в ДЗЕН

git bisect

> зачем тебе мог понадобится «const QList<CrShare>» как член класса?

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

и чем он поможет?

Не нравится С++ — не пользуйся С++. Меняй работу и так далее. А то развелось плюсовых мазохистов. Ненавидят С++, но пишут и пишут на С++, пишут и пишут на С++, как будто товарищ Бьярн его мёдом намазал.

Я же озаглавил тему - любовь :)

Метод основан на на чтении своего собсвенного кода. git bisect находит коммит, в котором твой баг, а потом просто смотришь diff и думаешь. В лучшем случае часы могли бы сократится до минут.

Хотя это всё зависит от многого. На сколько большой коммит например, или сложность воспроизведения бага. И т.д. Хороший, годный метод.

Весь кусок - 70 строк. коммит - это как раз весь кусок (по отдельности он не имеет смысл)

Тем более я знаю, когда появился баг. В общем-то не плохой метод, если баг появился после некоторого времени работы

покажет номер коммита в котором баг. внимательно смотришь diff - видишь строчку с ошибкой.

ну тогда bisect тут не поможет.

вижу подрят 70 строчек :) я и без него знаю, что ошибка в этих 70

тогда только тренировать внимательность.

> Я там ссылку не хотел. «&» попал как-то случайно.

QList<CrShare>& a_shares

QList<CrShare>& m_shares

Как вариант защиты от подобных ошибок - отключи в редакторе функции copy и paste

Зачем @brief каждый раз писать? Там же можно настроить, чтобы первое предложение само делалось brief'ом.

> А как вы ловите такие ошибки?

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

> супер-мега производительность

Имелась в виду скорость работы программы.

это фигня быстро замечается самые сложные это «тихие» перезаписи за пределами буферов а потом вылеты совсем в других местах вот где посидеть приходится

Именно об этом я всегда говорил. Мощь плюсов направлена в разные стороны, в т.е. против программиста.

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

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

хорошо что я уже не пишу на этом кошмаре.

Common Lisp в связке с C выносят сабжевый недоязычек в гумно.

> как будто товарищ Бьярн его мёдом намазал

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

unittesting (f.ex. googletest)

Зачем @brief каждый раз писать? Там же можно настроить, чтобы первое предложение само делалось brief'ом.

и второй @brief достоин пера К.О., как минимум

требования заказчика

да я ошибку поймал. в чем она?

да не хотел я его использовать. поставил случайно &

эм, задумался про гном, немного недописал: TDD (не test-first и не test-last) во все поля, мне весьма здорово помогает сохранять контроль, не панацея конечно, но процентов 70 ошибок позволяет избежать

Указатели в принимающей функции надо всегда (!) проверять на валидность, чего не требуют ссылки.

> да не хотел я его использовать. поставил случайно &

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

Указатели в принимающей функции надо всегда (!) проверять на валидность, чего не требуют ссылки.

#define srt(PTR) if(!(PTR)){ throw std::exception(#PTR); }

или типа того, с вас не убудет, если вы напишите srt(p1 && p2 /*... */); в начале функции

убудет. ибо это проверка в runtime

Проверка с нулем ЕМНИП самая быстрая проверка, не?

>#define srt(PTR) if(!(PTR)){ throw std::exception(#PTR); }

Для этого существует assert

> Там, где не нужна супер-мега производительность, этот метод вполне себя окупает. http://www.linux.org.ru/forum/development/6120632?lastmod=1302179312954#comme...

>#define

C++

:(

Ну, замути шаблон, в одну строчку, если ты такой умный.

> Проверка с нулем ЕМНИП самая быстрая проверка, не?

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