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

С указателями же обнаружить подобную ошибку куда сложнее, поскольку их "мусорные" значения ничем на вид не отличаются от остальных - и там, и там какие-то адреса участков памяти в ОЗУ. Плюс, указатели, в отличие от переменных, можно попытаться разыменовать, что также может привести к ошибке...

но компиляторы в таких языках обычно выдают предупреждение (а то и ошибку), если переменная не инициализирована.

Не, далеко не всегда. В конструкторах классов, особенно если в них есть if или switch-ветки - так вообще никогда...

Ну это всё-же проблема компилятора. Не инициализированная переменная должна вызывать warning. С переменными классов в Билдере тоже не должно быть проблем, т.к. TObject инициализирует всё нулями. Вот то, что в классическом с++ при создании объекта он заполнен мусором, мне тоже не нравится. // вообще, интересно, как Борланд "пришили" с++ к Дельфи - как поступили со строками, с виртуальными конструкторами, виртуальными функциями класса, class of...

(15.05.2012 02:53)gamecreator Wrote:  можно. но зачем? потеря двойной буферизации (а значит и жутко медленная отрисовка), стирание при следующем вызове отрисовки, еще что-нибудь вылезет. уже лучше вызвать перерисовку формы через invalidate.

Я на самом деле не знаю, какие там тонкости, просто сам пробовал так рисовать. Было бы интересно почитать детально.

(28.04.2012 19:03)Sav Wrote:  

totkotoriy Wrote:И ещё есть одна идейка насчет того глюка с не прорисовкой альфа канала на поле боя. Попробую в альфа плагин к хуку на прорисовку дефов существ вставить какое нибудь обновление экрана - может поможет.

Да не в этом там проблема. Проблема вообще элементарна - в определённых случаях элементы боя просто рисуются на своём месте несколько раз без стёрки предыдущего изображения. Без альфа-канала это незаметно, а в тех местах, где он или вообще какая-либо прозрачность присутствует после определённого числа наложений изображение, естественно, становится непрозрачным. Это не решается при помощи чёрной магии и не связано с отрисовкой def'ов.

Для двигающихся монстров я такую проблему решал - тень иногда по нескольку раз рисовалась без стирания.
Код для отрисовки с прозрачностью я могу оптимизировать как-нибудь на досуге.

пишу от руки прогу на с++

return 0; нужно писать в конце? как вообще по стандарту? на егэ нужно...

конечно нужно. но многие компиляторы прощают это для main

нужно, я вообще мейн начинаю со слов
int main(void) {
    return 0;
}

А я обычно так пишу:
void main()
{
}

И никаких вам ретурнов!

зато int универсальнее

gcc обижается на попытки сделать main неинтовым

packa, по стандарту можно return в конце main не ставить. Его отсутствие эквивалентно return 0. Причём это верно только для main, с другими функциями так не прокатит.

если main объявлена как int то return быть обязан.

просто во многих компиляторах есть заглушка
int main(...)
{
(void)main(...)
return 0;
}

все процессы ОБЯЗАНЫ возвращать ОС статус завершения.

Может мой вопрос прозвучит глупо, но существуют компиляторы под Симбион S60 ?
Вот новый телефон нокия 6120) хотелось бы везде иметь возможность кодить)

В стандартный состав библиотеки Qt входит порт под Simbian, так что ответ - да.

Вопрос от меня. Можно ли хоть как-нибудь передать среди параметров шаблона тип класса, в котором и идёт эта "передача"?
Понимаю, что сформулировал коряво, поэтому покажу код:


Этот код отлично скомпилируется и будет работать. Но, допустим, я решил переименовать класс Temp в MyFavoriteClass - а это означает, что и тип переменной s2 придётся переименовать...

В C++11 есть удобная штука decltype(X), которая определяет тип X ещё на этапе компиляции. Естественно, что я попробовал сначала написать decltype(*this) - но, увы, "invalid use of 'this' at top level". А вот если написать такую строку внутри какого-то метода Temp, то всё будет работать, поскольку this уже будет существовать...

Вот и как быть? Как мне сказать компилятору, что я хочу передать именно текущий класс Temp как параметр шаблона?