gamecreator Wrote:Efrit, т.е. ты предлагаешь реализовать систему грейдов через наследование? а если система грейдов не является деревом?

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

Не, я предлагаю намного проще:

- ввести в классе "башня" unsigned-переменную "уровень";
- тело конструктора этого класса сделать таким: { Init(...); }, где Init - это публичная функция инициализации объекта класса;
- в функцию Init среди параметров передавать этот "уровень"; (чтобы можно было создавать башню с заданным уровнем развития)
- когда нужно "улучшить" или "ухудшить" башню - просто вызываем Init с новыми параметрами, и всё.

P.S. Разумеется, Init должна содержать в себе "прорисовку башни" и прочие необходимые операции.

(07.04.2012 21:08)packa Wrote:  Не только, вот лазерный прицел например - целая функция по отрисовке

для одноуровневых грейдов можно хранить наличие

Слишком много массивов(
Из за чего я не могу поймать ячейку с багом. Из-за чего просто не понимаю чем он вызван)
Например условие
if (a!=b){}
else{Label1->Caption=a;Label2->Caption=b}
после чего получаю а = 100 b = 500 (грубо говоря...) Ну невозможно же!
   
и Лейблы тоже почти не спасают в поиске багов - они перетираются другими значениями. (это не взаимоисключающий параграф)

Как дальше быть? Как искать баги в этой ситуации?
P.S. На одиночных переменных все работало (1 враг, 1 выстрел, 1 башня... )

(10.04.2012 22:24)packa Wrote:  Например условие
if (a!=b){}
else{Label1->Caption=a;Label2->Caption=b}
после чего получаю а = 100 b = 500 (грубо говоря...) Ну невозможно же!

у тебя лейблы перетираются, можно получить вообще что угодно. а чтобы знать чем они перетираются - всегда пиши что именно за значение ты выводишь: лейбл="значение а="+а

(10.04.2012 22:24)packa Wrote:  и Лейблы тоже почти не спасают в поиске багов - они перетираются другими значениями.

так один лейбл - один вывод. или лейбл+=вывод

(10.04.2012 22:24)packa Wrote:  Как дальше быть? Как искать баги в этой ситуации?

изучай искусство дебага. и вообще, у тебя однопоточное приложение!

(10.04.2012 22:24)packa Wrote:  1 враг, 1 выстрел, 1 башня

TD пишешь?

Quote:так один лейбл - один вывод

Циклов много, самое интересное внутри

Quote:лейбл+=вывод

Там таймер на полсекунды =(
Если увеличить, то слишком долго ждать нужной ситуации

Quote:TD пишешь?

Больше всего на ТД походит) А так не совсем ее собирался делать, но вылилось в это

и вообще, какие еще лейблы? мессаджбокс же!

еще можно писать в файл

Quote:мессаджбокс же!

Это который как справка появляется окном? нее...
Я со многими параметрами одновременно работаю, да и в случае с += он ведь не проканает - стопит процесс

Quote:еще можно писать в файл

А вот это хорошая мысль.

(11.04.2012 00:49)packa Wrote:  в случае с += он ведь не проканает

ээ... причем тут += ?

Ну я к тому, что месседж бокс то подходит только для одного значения. Если нужен именно полная строка изменений,то он не подойдет.
for(int i=0,; i<5, i++){
massiv[i]+=5;
MessageBox(massiv[i]);
}
В результате чего мы получим по 1 значению.после каждого нажатия на ок.(цикл ведь не будет дальше двигаться?..)
А как "накапливать" в него я не знаю, да и зачем, в лабел или файл удобнее с этой точки зрения (только вот в метку похоже не влезет.)"

в чем проблема собирать текст в строку и после цикла вывести его?

Ура! Начал писать блок-схему и отловил один из багов
А вы рисуете ее? Что думаете, нужная штука?

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

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

не говоря о uml

Quote:для программирования есть более адекватные способы записи.

Не слышал...

Quote:Ни разу не рисовал. По мне, сам код выглядит куда нагляднее, если его, конечно, хорошо писать, т. е. не пренебрегать правилами оформления, подробно комментировать, максимально разбивать на функции и т. д. Да и если плохо - всё равно по мне проще всё в голове держать.

Ну наверное я для такого еще слишком низкого уровня. Вот глянул на схемку, сразу видно в какой ветке может быть ошибка.
А в самой программе как то все нагромождено слишком
Хотя стараюсь писать по правилам, по крайней мере по тем, которые я знаю)

Пакка, я видел твою ПМ-ку, но посмотреть как следует всё никак не могу - некогда Через неделю отпуск, тогда уж точно гляну (а может, и раньше).
Пока лишь бросилась в глаза пара нюансов:

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

- объявление переменных. На кой чёрт они объявлены внутри h-файла, когда больше никаких cpp-шников у тебя нету? Ты ведь явно не библиотеку пишешь. А то я при чтении основного исходника никак не мог понять, что же значит та или иная переменная... Не говоря уже про то, что глобальные переменные сами по себе не есть гут.

- утечки памяти. Твоя программа вылетает через десяток-другой секунд после запуска, всё увеличивая размер выделяемой для себя памяти. Глянул код - и точно, в нём в четырёх местах используется new, но нету ни одного delete...