Да я и не спорю. Просто случай того, что "какая-то переменная стала равна мусору", легко находится мониторингом всех переменных в отладчике - ведь программист, как правило, знает, значения из какого диапазона может принимать каждая его переменная. И всякие неадекватные значения (как правило, "мусорные" значения переменных очень большие) видны сразу.
С указателями же обнаружить подобную ошибку куда сложнее, поскольку их "мусорные" значения ничем на вид не отличаются от остальных - и там, и там какие-то адреса участков памяти в ОЗУ. Плюс, указатели, в отличие от переменных, можно попытаться разыменовать, что также может привести к ошибке...
но компиляторы в таких языках обычно выдают предупреждение (а то и ошибку), если переменная не инициализирована.
Не, далеко не всегда. В конструкторах классов, особенно если в них есть 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()
{
}
И никаких вам ретурнов!
gcc обижается на попытки сделать main неинтовым
packa, по стандарту можно return в конце main не ставить. Его отсутствие эквивалентно return 0. Причём это верно только для main, с другими функциями так не прокатит.
если main объявлена как int то return быть обязан.
просто во многих компиляторах есть заглушка
int main(...)
{
(void)main(...)
return 0;
}
все процессы ОБЯЗАНЫ возвращать ОС статус завершения.
Может мой вопрос прозвучит глупо, но существуют компиляторы под Симбион S60 ?
Вот новый телефон нокия 6120) хотелось бы везде иметь возможность кодить)
В стандартный состав
библиотеки Qt входит порт под Simbian, так что ответ - да.
Вопрос от меня. Можно ли хоть как-нибудь передать среди параметров шаблона тип класса, в котором и идёт эта "передача"?
Понимаю, что сформулировал коряво, поэтому покажу код:
PHP Code:
template <typename T>
class Sub
{
};
//-------------------
class Temp
{
Sub<int> s1;
Sub<Temp> s2;
};
Этот код отлично скомпилируется и будет работать. Но, допустим, я решил переименовать класс
Temp в
MyFavoriteClass - а это означает, что и тип переменной s2 придётся переименовать...
В C++11 есть удобная штука
decltype(X), которая определяет тип
X ещё на этапе компиляции. Естественно, что я попробовал сначала написать
decltype(*this) - но, увы,
"invalid use of 'this' at top level". А вот если написать такую строку внутри какого-то метода
Temp, то всё будет работать, поскольку
this уже будет существовать...
Вот и как быть? Как мне сказать компилятору, что я хочу передать именно
текущий класс
Temp как параметр шаблона?