| ← Август 2006 → | ||||||
|
1
|
2
|
3
|
4
|
5
|
6
|
|
|---|---|---|---|---|---|---|
|
7
|
8
|
9
|
12
|
13
|
||
|
17
|
18
|
19
|
||||
|
21
|
24
|
25
|
26
|
27
|
||
|
28
|
29
|
30
|
31
|
|||
За последние 60 дней ни разу не выходила
Сайт листа:
http://codeguru.ru
Открыт:
21-09-2003
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.prog.prog-list@subscribe.ru
Адрес
модератора: comp.soft.prog.prog-owner@subscribe.ru
Доброго времени суток, всем!!
Постановка задачи: Решил написать программулину, напоминающую мозаику,
т.е. должно быть графическое поле и панелька с фигурками, из которых я
собираю, что хочу, перетаскивая их на это поле (полный драг энд дроп
:)), и в БД храню координаты каждой фигуры и как они там между собой
состыковываются. Надеюсь объяснил......
А что собственно мне нужно??: хочу услышать ваши идеи :)
Hello Andrey,
Thursday, August 10, 2006, 3:25:57 PM, you wrote:
Спасибо за совет, собственно, изначальная идея у меня и была "в лоб",
хотелось чего-нить "экзотическое", может изучить, испытать какие-нить
новые алгоритмы.
Хм...на самом деле реализация уже второй этап, и, в принципе, не так
существенно на чем писать, я извиняюсь, что так криво объяснил, но
хотелось бы попытать вас именно по "алгоритмике" графической части.
Вообще разработка любого более менее серьезного приложения "слишком
большая тягомотина и геморрой", особливо, этап тестирования и отладки
:)))
З.Ы.: планирую писать на С++ (СР С++B 6)
Здравствуйте, Аюпов.
Тогда может быть заказать это тем, для кого разработка сложного
приложения - увлекательное занятие?
Hello Andrey,
Friday, August 11, 2006, 4:04:29 PM, you wrote:
Спасибо за рац.предложение к ТЗ, еще одно подтверждение тому, что
"Никогда не беспокой другого тем, что ты можешь сделать сам" (великий
всем известный).
Уважаемый Аюпов Роман Шамильевич пишет:
Сначала нужно позадавать себе много "глупых" вопросов: на "чем" писать
(имеется в виду язык и оболочка); как, собственно, будет выглядеть
картинка (интерфейс); раз Вы уже решили, что требуется БД - решите,
какую БД строить и какую структуру данных разрабатывать. Могут быть еще
вопросы, но я, лицо непосвященное в причины возникновения такой задачи,
своим непросвещенным умом их не охвачу. Потом нужно выбрать технологию
разработки. Сам я более-менее знаком и обычно использую нисходящую
разработку со структурным подходом. То есть я бы сначала в достаточно
сжатом виде сформулировал бы задачу, затем составил формулировки
составляющих ее отдельных относительно независимых задач, а потом то же
самое делал бы с этими самыми вновь сформулированными задачами меньшего
масштаба и т. д. Получается такая себе древовидная структура ("корешком
вверх"). (При случае отмечу, что в серьезных больших делах она,
называемая "схемой структуры иерархии", позволяет "чужому
дяде-заказчику" контролировать ход выполнения работы.) Потом мне бы
пришлось разработать структуру данных для БД и для программы, а также
построить псевдокод для каждого блока схемы структуры иерархии.
Псевдокод - это "естественноязыковое" текстовое описание
соответствующего модуля программы, построенного в соответствии с
определенной дисциплиной. Крайне вульгарно, но невероятно точно можно
сказать, что псевдокод - переведенный, например, на русский язык
исходный код указанного модуля на языке Python, изображенный графически
с сохранением формата, принятого в языке Python. Ну а затем я должен был
бы посоставлять уже на настоящем выбранном языке программирования
заглушки на все такие модули, кроме корневого, "вызывающего". Заглушка -
это такая "игрушечная" подпрограмма - простенькая "карикатура" на
требующийся модуль. Потом нужно писать исходный код на все выделенные
таким образом модули, причем делать это в порядке, определяемом
следованием соответствующих блоков в схеме структуры иерархии. При этом
нереализованные пока модули подменяются заглушками. Это дает возможность
отлаживать программу одновременно с ее написанием, не увеличивая
чрезмерно уровня сложности. Должен отметить, что это - довольно старая
технология. Блокам схемы структуры иерархии на начальных, "верхних"
уровнях могут соответствовать на модули, а формы с виджетами,
соответствующими вызываемым задачам ближайшего "нижнего" уровня. Когда
очередной модуль отлажен на "заглушках", можно кодировать и отлаживать
модуль, соответствующий какой-либо из этих заглушек. Если Вам кажется,
что все, что я тут изложил - слишком большая тягомотина и геморрой -
обратитесь к новейшим "метОдам", например, UML. Искренне Ваш, Приходько.
Милейший господин Николаев написал:
Сколько бреда в одном письме.. Не лень было писать? :)
Отвечаю:
учите Дж.Хьюз и Дж.Мичтом "Структурный подход к программиррованию", Мир,1980
и, будь я уверен в адекватности Вашей "необъектной" ориентации, пожелал бы
Вам поцеловать меня в одно место. Содержательно: могу "через колено" слепить
программку в "аксесе" с сопровождающей документацией. Я человек занятый, но,
наверное составлю и отлажу ее быстрее "среднепотолочного" Николаева. Прошу
господина Модератора извинить за тон. Приходько.
Приветствую, Paul.
Роман Шамильевич спрашивал, что ему нужно. А вот вы написали то, что
ему совершенно не нужно. Не думаю, что кто-то сомневается в вашей
программисткой гениальности - тут кто на что горазд, вот только ваше
большое письмо ни черта не дает означенному Роману Шамильевичу. Ну не
нужно ему подходить к решению такой задачи столь глобальным методом.
Подходить такой метОдой, что стрелять из пушки по воробьям. Роман
Шамильевич хотел просто практических идей.
Например, структуру БД. Таблицы, поля. Или каким образом хранить
данные, чтобы можно было определить - правильно ли складывают два
фрагмента или неверно. И так далее. Идеи реализации компьютерной игры
Pazzle нужны, а не глобалистские подходы к разработке программ.
Бред, не бред, а всё-таки же человеку надо с чего-то начинать...
Да и остальным тоже может быть интересно и поучительно наблюдать за
созданием программ...
Вот только термины бы по понятнее
Сердолик
Скажите пожалуйста для чего нужен квалификатор volatile.
Мне нужно чтобы переменная длинной 32 разряда корректно обрабатывалась
на 8 разрядном процессоре.
поможет ли при этом квалификатор volatile?
например:
long volatile val;
__interrupt void int(void)
{
val = 0x12345678;
}
void main()
{
val+=5;
}
корректный пример без volatile:
long val;
__interrupt void int(void)
{
val = 0x12345678;
}
void main()
{
__disable_interrupt(); //Запретить модификацию переменной функцией-прерыванием
val+=5;
__enable_interrupt();
}
Нет, не поможет. Скорее даже наоборот -- он запрещает компилятору
делать к-либо предположения о том, что переменная остаётся постоянной.
(volatile применяется к регистрам портов ввода, которые могут меняться
"снаружи", вне зависимости от действий программы).
Предназначен для подавления "агрессивной" оптимизации.
М.
Уважаемый, Роман Шамильевич!
Во первых строках своего письма, спешу заметить, что - хотя возможно я
что-то пропустил - не обнаружил я в данной переписке "практических идей" и
того "что Вам нужно". На мой взгляд, это произошло по тому, что Вы не
достаточно чётко определили, ту самую задачу - не очень ясно, что же должно
в итоге получиться.
Уважаемый, господин Приходько!
RE: Сначала нужно позадавать себе много "глупых" вопросов
В Вашем случае нужно позадавать немного вопросов господину Аюпову, потом уже
позадавать немного вопросов СЕБЕ: "какова цель Вашего письма" и уж потом
"через колено"(с) браться за перо.
RE: Сам я более-менее знаком и обычно использую нисходящую разработку со
структурным подходом.
Уж не знаю с чем Вы там знакомы, но Вы напоминаете мне лектора.. (тут мысль
прервалась - СЛОВ НЕТ !!!)...
Я бы Вам посоветовал использовать разработку по оси Z с подходом с тыла и
внедрением по касательной.
Извините Вы меня, но я сам преподаватель, и когда на вопрос "как лучше
приготовить рыбу?" отвечают размышлениями философа-химика-теоретика 18 века
о методологии исследований в области термической обработки йодсодержащих
продуктов, у меня возникает животное желание рукоприкладства. Ещё раз прошу
прощения - ничего личного!
PS Хотя возможно это господа Дж. виноваты.
Уважаемый, Роман Шамильевич!
Извините, что отвлёкся. Так вот, если это простая мозаика - я так понимаю
рисунок разбитый на части, который нужно собрать - то здесь действительно
всё можно решить практически "в лоб".
Я бы реализовал каждый кусок мозаики, как объект (а тем более, что Вы
собираетесь писать на С++), который, при инициализации получает кусок
исходного изображения (например из графического файла). Место, на котором он
должен оказаться путём тривиальных вычислений, и также является свойством
объекта - при этом никакая БД не нужна. Когда кусок мозаики (в унисон с
"программулиной" назовём его пазлиной), после перетаскивания отпускается, то
если он находится в "графическом поле", он автоматически притягивается к
воображаемой сетке. Когда у всех пазлин совпадут координаты текущие и
нужные - мозаика собрана.
Хотя это моё решение обрисованной мною в моём мозгу задачи. Судя, по тому,
что "в БД <УЖЕ> храните координаты каждой фигуры и как они там между собой
состыковываются" задача может сильно отличаться от представленной мною.
Хотя, если "фигурки" не вращаются, то мне трудно представить, что это за
информация о том, "как они там между собой состыковываются". Что то Вы от
нас утаиваете. Впрочем, дело Ваше. Желаю успехов и удачи!
С уважением,
Артур Голубев
Артур Голубев пишет:
господин голубеев! Я до некоторой степени удовлетворен, что вы помянули
мою скромную персону. Печально, что упоминаемое Вами мое сообщение
вызвало у Вас лишь желание энергически высказаться. Однако, раз тема
сама по себе интересна, предложу свое решение. Конкретно: сейчас
составляю сопровождающую документацию (я прикинул: по объему это
вложится в одно письмо), затем составлю соответствующую "оболочку" в
Access (- Роман Шамильевич со всей определенностью сказал: "база
данных") и выложу для "дегустации". Хочу еще раз обратить внимание:
кроме названия почти ничего не указывало на специфику задачи, например,
ничего не указывает на то, какие могут быть края у фрагментов, можно ли
их переворачивать или только поворачивать и еще БОГ ЗНАЕТ ЧТО. Одно
сейчас могу сказать со всей определенностью: в этой задаче
программистских проблем нет. Будоражить тут объектный подход и сипипи
можно лишь по сильной любви к искусству. Итак, время для меня пошло, а
потому в ближайшее время всякие выказывания по своему поводу буду
игнорировать. Пока. Приходько.
Hello Paul,
Sunday, August 20, 2006, 9:50:57 PM, you wrote:
Может Вы будете выяснять свои личные отношения в личной переписке.
К Модератору: куды он подевался?
Уважаемый Victor V. Vakchturov пишет:
Поддерживаю, случилось "свободное" время - сделал половину того, что
обещал. Чтобы не перегружать незаинтересованных лиц структуру и
псевдокоды выложил в файлообменник. Держать обещают только 7 дней.
Ссылка и реквизиты:
*webfile.ru/1086580* <http://webfile.ru/1086580>
Имя файла - *mozaikaD.txt* , размер 10 Кбайт. Файлу присвоен номер
*1086580*, он будет доступен до 09.09.2006 15:53.
Так что приятного аппетита, Ганнибал Лектор (Приходько)
Здравствуйте, Аюпов.
Вы писали 10 августа 2006 г., 12:13:27:
А в чём проблема-то? Бери да делай.
Какие тут могут быть идеи? По-моему, всё решается "в лоб".