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

http://www.lrz.land.ru/dowload/libGUI.7z Ошибка найдена и ликвидированна. В обработчике Del and Bacspase был выход как popa ret
И в коде обработки left and right была аналогичная ошибка.

Heavyiron
diamond
OFFTOP
Ага, особенно если учитывать что на тот момент я тянул Колибри практически один, но это было давно и неправда...

/OFFTOP

Heavyiron wrote:Однако размерчик демок без сжатия впечатляет: 460 kb. И это только демки...
PS: Не знаю как под экранной лупой, но тот скриншот, что ты привел - один в один ХР.

Сорее Виста

[offtop]
Heavyiron
Продумывание дизайна и комментирование между собой могут быть не связаны. IMHO В приведённом тобой примере наличие комментариев соответствует не приведению в порядок проводов, а навешивание на каждый проводочек аккуратненькой бирочки с описанием того, что делает этот проводочек, какое напряжение по нему идёт и т.п. Дизайн платы скорее соответствует описанию в отдельном месте, которым может быть как исходник программы, так и мозги автора

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

Если комментарии будут действительно необходимы и разбор кода действительно полезен для многих, первый же разобравшийся может сам эти комментарии добавить... В частности, никто никому не мешает залезть на svn и исправить шапку к vrr_m (кстати, я не смотрел, там ситуация всё такая же?)
Далее, довольно редко программист ставит себе цель, чтобы код программы был понятен и легко модифицируем другими программистами. А при таком подходе достаточно ставить комментарии, по которым сам автор может понять, что происходит. Разумеется, желающему разобраться в таком коде придётся разбираться ив общей архитектуре программы. На примере всё того же vrr_m: автору было совершенно ясно, для чего нужна эта программа, так что в изменении шапки исходника он не нуждался и не проделал это (лень, рассеянность, забывчивость - причины бывают разные).
...Хотя вообще-то вопрос о необходимости комментариев относится к стилю программирования, а попытки убеждения других изменить их стиль довольно-таки безнадёжны. По крайней мере, я ни разу не видел, чтобы спор типа "Си vs Паскаль" (или "FAR vs TC", или "Windows vs Linux") хоть кого-то переубедил.
[/offtop]

diamond

Продумывание дизайна и комментирование между собой могут быть не связаны

Ну да, я немного нелогично сформулировал мысль. Этот пример хотел привести в подтверждение мысли о первичности алгоритма и неважно где он - пусть даже в мозгу разработчика, но только если он способен его держать в памяти и не забыть по прошествию времени. А если бросаться писать код, не имея четкого представления, как он должен работать и додумывать по ходу дела, то это очень похоже на схему на столе с проводками. Перенесли, ее, скажем, на другой стол - что-то опаялось. Тут уж даже грамотным электронщикам лень разбираться будет что и откуда. А если потом эта схема еще усложнится и разрастется?

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

Я не думаю, что тут нужно спорить. Есть ведь гайдлайны (руководства) по написанию кода на разных языках. Существуют они как раз для повышения сопровождаемости кода. И тут же делается оговорка: хочешь участвовать в нашем проекте - изучи документ и пиши так же, как все, чтобы всем было понятно. У нас такого документа нет, потому что никто даже попыток не делает сотрудничать друг с другом, разрабатывать одну программу не в одиночку, а командой. Однако, если бы он был, и описывал бы правила расстановки пробелов, отступов, написания комментариев, именования файлов, переменных и меток, - никто бы и спорить не стал. Просто бы указали на соответствующий пункт правил, и всё. Да, ассемблер отличается от других языков программирования, но всё же. Взять хотя бы ядро, где каждый пишет так, как он хочет - читать невозможно иногда. А такого быть не должно.

Дискуссия возникла по поводу моего кода, но поскольку уже прошло очень много времени с момента появления первой версии GUI компонентов исходный вариант от Maxxxx32 Дата последних изменений: 13.06.06 10:40, уже прошло много времени, изменилось ядро, изменилось вообще многое. Стиль программирования больше напоминает хотелку-реализаловку, т.е. мне хочется что бы у компонента было то - то и то - то, вот я и начинаю реализовывать, проходит время меняются механизмы и снова происходит модернизация кода. Таким образом предсказать дальнейший план развития кода невозможно! Можно только спрогнозировать то или иное.

По поводу руководств по написанию кода я создал тему для обсуждения: http://meos.sysbin.com/viewtopic.php?p=10893

Вчера переписал libGUI под mcall, протестировал с ключом p6, на ноуте P3 900/128/20 Gb. На глаз не заметно быстрее она или медленнее, чем при компиляции с ключом p5.

В случае использования fast syscall-а улучшение(увеличение скорости) будет только для контролов, которые могут рабоать с, так называемыми(я их так назвал), "специализированными сообщениями".Когда нужно, чтобы из всех контролов только некоторые контролы перерисовались, в соответствующих полях контролов выставляются биты (включение ловушки для специализированных сообщений)и посылается сообщение 3(это число означает, что сообщение специализированное).
Специализированные сообщения поддерживают следующие GUI компоненты: ProgresBar(покачто простенький),Image, Text, Number.
<Lrz>, в том архиве, который я тебе услал, демка не посылает специализированных сообщений контролам.Я подумал, что так будет лучше. А то народ подумает, что libGUI тормозная.Хотя естественно, что при непрерывной посылке контролам сообщения 3 , их частая перерисовка загрузит процессор почти на 100%.

Если запустить демку, то примерно 1,5 метра из ОЗУ тратиться. Не пойму почему? В неупакованном виде все занимает 200 кб с библиотекой, в упакованном 17 кб. Куда тратиться ~1,5 мб ОЗУ ?

<Lrz>
Смотри заголовок программы, там прописано 1024*1024+280*280*3+90000 ~ 1.3Mb

Привет всем колибрищикам !

Вышла новая версия библиотеки libGUI(подробная документация прилагается !).

http://www.menuetosgame.narod.ru/programs/libGUI.7z ~416 Kb

Итак, что нового.

1) Полностью переписан движок библиотеки.
Теперь он работает быстрее и стабилен к сбоям и ошибкам.Движок позволяет создавать/удалять
дочерние контролы любой степени вложенности.Проводяться проверки на всевозможные ошибки.
Так что теперь при попытке удалить несуществующий контрол библиотека не вылетит.

2)Конечно же оптимизация кода по скорости и размеру.

3)Доработка дизайна кнопок.

4) Компонент Scroler теперь стал полноценным - у него есть кнопки.

5)Новый компонент ProgresBar.Это красивый, объёмный компонент.

6)Добавлена самая последняя версия EditBox-а от Алексея(<Lrz>).Только там есть один баг,который
я сам устранить не смог, а у автора нет пока времени на Колибри. Поэтому подождём исправления
до появления автора.

7) Закладки теперь корректно изменяют свой размер

Устранение ряда ошибок и недочётов в других компонентах.

9)Для каждого компонента свой пример использования.

10)Документация в нескольких форматах.

11)Статья, в которой на примере компонента ProgresBar показано как нужно писать
GUI компоненты для libGUI.


P.S.
Я пытался сделать документацию на английском. Для этого перевёл Промт-ом документацию
с русского на английский.С большой долей вероятности, переведённая документация содержит
ошибки. Сам я в английском не очень(переводить могу,а вот с написанием проблемы).Поэтому
у меня просьба. Если кто разбирается в английском и располагает некоторым свободным
временем - проверьте документацию на ошибки.