Здравствуйте.
Представляю свою библиотеку, написанную 3 года назад, и пока развивающуюся.
Библиотека позволяет создавать в консоли "подконсоли", называемые виджетами.
В этих "подконсолях" ведется работа, как в обычно консоли, с некоторыми отличиями.
Одно из важнейших — прорисовка. Для этого используется двойная буферизация, что позволяет
очень просто писать программы, в которых необходимо быстрое обновление "окошка".
Например с помощью этой библиотеки я написал Гонки.
P.S. в примерах их пока нет в следствие сложной оптимизации.
Я не претендую на оригинальность. И просьба не писать что-нибудь вроде "лучше в графике все делать".
Я понимаю, я умею писать графику. Но не все люди сразу узнают графику. Для этого надо много учиться.
И эта библиотека может им помочь написать что-то действительно стоящее в консоли, не тратя много времени
на функции прорисовки.
Файл приложен к этому сообщению. Инструкции там же.
Так же вот ссылка на narod.ru: http://narod.yandex.ru/disk/23201221001/ConsoleGraph.rar
Библиотека обновлена с версии 1.9 до 1.9.1
Появилось некое подобие API.
Так же в нем описана следующие предполагаемые действия.
Отличия от версии 1.9 beta:
1) Появилась функция получение версии движка
2) Ускорена работа с виджетами
3) Теперь виджетов можно не 100, а сколько захочет пользователь.
Здравствуйте, Харч, Вы писали:
Х>Библиотека обновлена с версии 1.9 до 1.9.1 Х>Появилось некое подобие API.
Отлично.
А до этого библиотека была без интерфейса?
Х>Так же в нем описана следующие предполагаемые действия.
В чем "в нем"? В твой библиотек?
Х>Отличия от версии 1.9 beta: Х>1) Появилась функция получение версии движка
std::string GetVersionEngine(); - получить версию движка прорисовки.
Офигенно полезно.
Скажите, уважаемый автор, а нахрена она, такая функция?
Вообще-то основная цель "функции получения версии" библиотеки — это чтобы можно было проверить, не подсунули ли при сборке враги более старую версию библиотеки.
Вот надо мне, чтобы библиотека была версии не меньше 1.9.12 — и как прикажете применить вашу мега-полезную функцию ДайВерсионныйДвижок()? Мне что, ручками парсить строчку прикажете, переводить ее в номера major, minor, patch и сравнивать?
Х>2) Ускорена работа с виджетами
Это как? Теперь для работы с виджетами надо написать не пиисят строчек кода, а сорок пять?
Х>3) Теперь виджетов можно не 100, а сколько захочет пользователь.
По порядочку:
1. Библиотека идет в скомпилированном виде. Использовать твою библиотеку с компилятором, отличным от твоего, будет сильно проблематично. Она у тебя что, с закрытым исходным кодом?
2. Виджет — это Widget. Запиши на бумажке, приклей на стенку и учи перед сном. Первая буква — W.
3. Нахрена нужны "карты" экрана и виджета — непонятно. Если это обязательно — почему это не делается автоматически в конструкторе? Вообще непонятно, что за карты и зачем они нужны.
4. Виджет, выходящий за пределы экрана, вызывает segfault? Круто. Обработка ошибок на высоте, да...
5. Непонятна целевая платформа. Под чистым ДОСом будет работать? Под Win9x? А если я в виндовом оконном приложении твою библиотеку подключу и "экран" создам, консолька на экране появится?
6. Если половина функций в документации "пока не реализована", почему мне вдруг может захотеться включить твою недоделанную библиотеку в свой проект? Я лучше подожду, пока все устаканится.
Отлично.
А до этого библиотека была без интерфейса?
Я может что-то не так понимаю, но API (в моем понимании) это есть описание функций движка
В чем "в нем"? В твой библиотек?
В API. Ну раз это описание функций движка, то в нем и может быть описаны предполагаемые действия...
Офигенно полезно.
Скажите, уважаемый автор, а нахрена она, такая функция?
Вообще-то основная цель "функции получения версии" библиотеки — это чтобы можно было проверить, не подсунули ли при сборке враги более старую версию библиотеки.
Вот надо мне, чтобы библиотека была версии не меньше 1.9.12 — и как прикажете применить вашу мега-полезную функцию ДайВерсионныйДвижок()? Мне что, ручками парсить строчку прикажете, переводить ее в номера major, minor, patch и сравнивать?
Она возвращает в строку версию движка.
А смысла второго абзаца не очень понял. Вы хотите функцию сличения данной вами версии и текущей?
Это как? Теперь для работы с виджетами надо написать не пиисят строчек кода, а сорок пять?
Странный вопрос, разумеется нет. Изменена архитектура работы с виджетами внутри движка и теперь обращение к ним происходит на порядок быстрее. Что кстати на самом деле на малом количестве виджетов незаметно.
Афигеть...
Было 100. Потому что начинал я эту библиотеку еще в школе. А там мне было важно просто как-то решить проблему с количеством виджетов. И я не знал многих возможностей C++.
Открыл, посмотрел.
Смеялсо.
Чему именно?
По порядочку:
1. Библиотека идет в скомпилированном виде. Использовать твою библиотеку с компилятором, отличным от твоего, будет сильно проблематично. Она у тебя что, с закрытым исходным кодом?
2. Виджет — это Widget. Запиши на бумажке, приклей на стенку и учи перед сном. Первая буква — W.
3. Нахрена нужны "карты" экрана и виджета — непонятно. Если это обязательно — почему это не делается автоматически в конструкторе? Вообще непонятно, что за карты и зачем они нужны.
4. Виджет, выходящий за пределы экрана, вызывает segfault? Круто. Обработка ошибок на высоте, да...
5. Непонятна целевая платформа. Под чистым ДОСом будет работать? Под Win9x? А если я в виндовом оконном приложении твою библиотеку подключу и "экран" создам, консолька на экране появится?
6. Если половина функций в документации "пока не реализована", почему мне вдруг может захотеться включить твою недоделанную библиотеку в свой проект? Я лучше подожду, пока все устаканится.
1. Нет, не с закрытым. Он будет открыт с версии 2.0 (окончательной "школьной" версии)
2. Я знаю. Повторяю — я начал писать в школе, а английский я тогда не знал. Вот и получилось "Vidget". Это будет исправлено к версии 2.X
3. Если бы был открыт исходный код — поняли бы.
Объясню:
При создании экрана или виджета всего лишь происходит нанесение их рамок. При создании карты — выделение памяти.
Так можно в начале программы для удобства создать все необходимые виджеты, а в процессе при необходимости создавать карту.
4. Да. Интересно, а какой такой странный человек будет рисовать виджет за границами экрана?
P.S. если не поняли — не за границами экрана монитора, а за границами экрана, созданного AddScreen****()
5. Пока нет. Будет введено в версию 2.X (так как для цветов используется функции Windows).
6. Какая половина?? 5 функций из 25 где-то, причем 4 из них связаны с записью ВИДЕО из виджета в формате этой библиотеки, что в связи с отсутствием плеера НИКОМУ сейчас не нужно. А одна еще — печатать в виджет с клавиатуры, это тоже не смертельно. Что не так-то?
И еще, уж простите за бестактный вопрос, откуда столько сарказма? Я просил конструктивной критики, которая появилась только в конце, а до этого был сарказм.
Здравствуйте, Харч, Вы писали:
Х>Начну по порядку:
Ога.
Х>Я может что-то не так понимаю, но API (в моем понимании) это есть описание функций движка
API в понимании всего остального человечества — это Application Programming Interface.
Это интерфейс для работы с твоей библиотекой.
Использовать API как синоним словосочетания "документация к интерфейсу", как это делаешь ты, нельзя.
Х>
Х>В чем "в нем"? В твой библиотек?
Х>В API. Ну раз это описание функций движка, то в нем и может быть описаны предполагаемые действия...
API не является синонимом к слову "документация". "Недокументированные API Windows" — знакомо такое выражение?
Х>
Х>Офигенно полезно.
Х>Скажите, уважаемый автор, а нахрена она, такая функция?
Х>Вообще-то основная цель "функции получения версии" библиотеки — это чтобы можно было проверить, не подсунули ли при сборке враги более старую версию библиотеки.
Х>Вот надо мне, чтобы библиотека была версии не меньше 1.9.12 — и как прикажете применить вашу мега-полезную функцию ДайВерсионныйДвижок()? Мне что, ручками парсить строчку прикажете, переводить ее в номера major, minor, patch и сравнивать?
Х>Она возвращает в строку версию движка.
Спасибо, кэп.
Х>А смысла второго абзаца не очень понял. Вы хотите функцию сличения данной вами версии и текущей?
Нет, я не хочу иметь для этого еще одну функцию с труднозапоминаемым именем.
Я хочу, чтобы информация о версии программы была легко и просто обработана в программе. Например, мне нужна библиотека версии 1.9.12 или лучше — значит, мне нужно сравнить версию библиотеки на "больше или равно". Со строками это немножко затруднительно ("1.9.5" будет больше, чем "1.9.12", хотя казалось бы).
В нормальных библиотеках можно получить версию библиотеки как в виде строки (для показа пользователю), так и в виде числа (целого) — для сравнений. К примеру, 1.9.1 можно закодировать как число 0x00010901 — по байту на каждый компонент. В этом случае сравнение номеров версий тривиально.
А еще желательно предоставить пользователю #define с номером версии в хедерах библиотеки, чтобы его можно было проверить в процессе компиляции. Тогда при несоответствии версии библиотеки будет не обломинго при запуске программы, а внятное сообщение во время компиляции.
Х>
Х>Это как? Теперь для работы с виджетами надо написать не пиисят строчек кода, а сорок пять?
Х>Странный вопрос, разумеется нет. Изменена архитектура работы с виджетами внутри движка и теперь обращение к ним происходит на порядок быстрее. Что кстати на самом деле на малом количестве виджетов незаметно.
"Ускорена работа с виджетами" — ваши слова?
Так вот, с виджетами работает кто? Правильно, пользователь твоей библиотеки. Именно он вызывает функции библиотеки для создания виджетов и прочих действий. Посему фраза об ускорении работы с виджетами звучит странно — вот и вопросы возникают странные.
Х>
Х>Афигеть...
Х>Было 100. Потому что начинал я эту библиотеку еще в школе. А там мне было важно просто как-то решить проблему с количеством виджетов. И я не знал многих возможностей C++.
Я бы — хммм — такие — хммм — "достижения" из описания библиотеки удалял. Во избежание.
Любой серьезный заказчик, увидев ограничение в 100 виджетов в описании библиотеки, сделает страшное лицо и скажет "на юх, на юх такое счастье!". И для него будет уже не важно, в каком контексте эти 100 виджетов там упоминаются.
Х>
Х>Открыл, посмотрел.
Х>Смеялсо.
Х>Чему именно?
Далее по тексту по порядочку это расписано.
Х>
Х>По порядочку:
Х>1. Библиотека идет в скомпилированном виде. Использовать твою библиотеку с компилятором, отличным от твоего, будет сильно проблематично. Она у тебя что, с закрытым исходным кодом?
Х>2. Виджет — это Widget. Запиши на бумажке, приклей на стенку и учи перед сном. Первая буква — W.
Х>3. Нахрена нужны "карты" экрана и виджета — непонятно. Если это обязательно — почему это не делается автоматически в конструкторе? Вообще непонятно, что за карты и зачем они нужны.
Х>4. Виджет, выходящий за пределы экрана, вызывает segfault? Круто. Обработка ошибок на высоте, да...
Х>5. Непонятна целевая платформа. Под чистым ДОСом будет работать? Под Win9x? А если я в виндовом оконном приложении твою библиотеку подключу и "экран" создам, консолька на экране появится?
Х>6. Если половина функций в документации "пока не реализована", почему мне вдруг может захотеться включить твою недоделанную библиотеку в свой проект? Я лучше подожду, пока все устаканится.
Х>1. Нет, не с закрытым. Он будет открыт с версии 2.0 (окончательной "школьной" версии)
То есть сейчас он таки закрытый.
Х>2. Я знаю. Повторяю — я начал писать в школе, а английский я тогда не знал. Вот и получилось "Vidget". Это будет исправлено к версии 2.X
Почему не сейчас? Автозамена в редакторе доступна всем.
Х>3. Если бы был открыт исходный код — поняли бы.
Вот тут мы с тобой сделаем небольшую остановку и поговорим на отвлеченные темы.
Ты хочешь, чтобы твоей библиотекой начали пользоваться, так?
В таком случае ее интерфейс должен быть как можно более простым и очевидным. Если у тебя в интерфейсе присутствуют какие-то неочевидные вещи типа "карт", без которых ничего не будет работать — ты или убираешь эти вещи "под капот" (чтобы пользователь библиотеки о них даже не догадывался), или хорошенько описываешь в документации, на кой ляд они нужны и какие будут от их использования плюшки.
Если у тебя наружу торчат всякие малопонятные рычаги, за которые надо обязательно дернуть "чтобы все заработало", серьезный разработчик с тобой сотрудничать не будет.
Х>Объясню: Х>При создании экрана или виджета всего лишь происходит нанесение их рамок. При создании карты — выделение памяти. Х>Так можно в начале программы для удобства создать все необходимые виджеты, а в процессе при необходимости создавать карту.
Выделение памяти подо что? Зачем мне виджет, которым невозможно пользоваться? Почему нельзя было сделать отдельный виджет-рамку?
Вообще, архитектура библиотеки непонятна и запутанна.
Х>4. Да. Интересно, а какой такой странный человек будет рисовать виджет за границами экрана?
Хех.
Мало ли ситуаций.
К примеру, я хочу сделать красивое "влетающее из-за экрана" сообщение в рамочке. Или просто хочу переместить виджет временно в сторонку.
Как бы я это сделал в нормальной системе?
Создаю виджет где-нибудь в области отрицательных координат, пишу на нем текст, а потом в цикле вывожу его на экран, меняя координаты.
В твоей библиотеке мне придется ручками рисовать все промежуточные состояния виджета в разных стадиях "обрезанности".
Х>P.S. если не поняли — не за границами экрана монитора, а за границами экрана, созданного AddScreen****()
Не понял.
Потому что документация к библиотеке практически отсутствует. Есть краткое описание API без намеков на то, как все это счастье работает.
Х>5. Пока нет. Будет введено в версию 2.X (так как для цветов используется функции Windows).
А нужна ли она, версия 2.х?
Х>6. Какая половина?? 5 функций из 25 где-то, причем 4 из них связаны с записью ВИДЕО из виджета в формате этой библиотеки, что в связи с отсутствием плеера НИКОМУ сейчас не нужно. А одна еще — печатать в виджет с клавиатуры, это тоже не смертельно. Что не так-то?
"Не так" то, что наличие таких функций свидетельствует о недоделанности библиотеки.
В хорошо вызревшей библиотеке такого счастья нет и быть не должно. Могут быть устаревшие функции.
И вновь возвратимся к отвлеченным темам.
Библиотека — она для кого? Она для разработчиков.
Это тебе прикольно ковыряться с ней, править функции, улучшать и переделывать.
Разработчику использовать нестабильный API — хуже смерти. А если при этом еще и непонятно, как оно все работает и что половина из функций делает — ваще не комильфо. Я бы в свой проект такую библиотеку потянул только в том случае, если задача очень сложная и других альтернатив нет.
Х>И еще, уж простите за бестактный вопрос, откуда столько сарказма? Я просил конструктивной критики, которая появилась только в конце, а до этого был сарказм.
Тут, понимаешь ли, сарказм — это способ заставить тебя посмотреть на свое творение немножко более критично.
Ведь по сути — что представляет из себя твоя библиотека? Некие бинари (хрен подключишь — я в студии даже примеры собрать не могу, чтобы посмотреть). Без внятной документации. С обилием таинственных, только автору понятных функций. С неясными целями и задачами ("рисовать виджеты в консоли" — это какое-то очень размытое описание функционала библиотеки). С явными следами недоделок (нереализованные функции) и какими-то неясными ограничениями.
Пользоваться этим без риска нарваться на грабли невозможно. Строить серьезный проект с использованием этой библиотеки — безумие. Создавать тестовые приложения для осваивания библиотеки — бессмысленно, потому что проще и продуктивнее будет написать своё, чем разбираться методом проб и ошибок в чужих потемках.
В крайнем случае — есть уже готовые библиотеки для работы с консолью (сурпрайз!). Например, ncurses — там есть практически все, что нужно. Оттестированный, многоплатформенный, хорошо документированный код. И даже под виндовс порт есть, кажися.
Тем не менее ты грозен и бесстрашен — выпускаешь новые версии (как будто старыми кто-то пользуется), бодро рапортуешь о каких-то улучшениях, ссылаешься на версию 2.х... Выглядит это как бурная деятельность по пиару какого-то полуфабриката, интересного пока только автору.
Гораздо конструктивнее, по моему личному мнению, было бы начать с анализа уже имеющихся библиотек. Что нравится в них, что не нравится. Что хотелось бы. Обсуждаем все это, намечаем пути реализации. Накидываем прототипчик. Проверяем, как оно работает и компилится под разными платформами. Расширяем функционал, потихоньку портируем под другие платформы (если надо). Без шума и помпы, без громогласных объявлений о выходе "новой супер-пупер-бета-версии noOneCaresAboutConsoleLib 1.9.33 с новой, улучшенной функцией создания хренаций для виджетов! Теперь хренаций у виджета может быть две, причем одна из них — активная, а другая — разноцветная!".
Х>Я может что-то не так понимаю, но API (в моем понимании) это есть описание функций движка
API в понимании всего остального человечества — это Application Programming Interface.
Это интерфейс для работы с твоей библиотекой.
Использовать API как синоним словосочетания "документация к интерфейсу", как это делаешь ты, нельзя.
Х>
Х>В чем "в нем"? В твой библиотек?
Х>В API. Ну раз это описание функций движка, то в нем и может быть описаны предполагаемые действия...
API не является синонимом к слову "документация". "Недокументированные API Windows" — знакомо такое выражение?
Понял, спасибо. Просто например документация к графическому движку Irrlicht называется API, вот я и подумал...
Нет, я не хочу иметь для этого еще одну функцию с труднозапоминаемым именем.
Я хочу, чтобы информация о версии программы была легко и просто обработана в программе. Например, мне нужна библиотека версии 1.9.12 или лучше — значит, мне нужно сравнить версию библиотеки на "больше или равно". Со строками это немножко затруднительно ("1.9.5" будет больше, чем "1.9.12", хотя казалось бы).
В нормальных библиотеках можно получить версию библиотеки как в виде строки (для показа пользователю), так и в виде числа (целого) — для сравнений. К примеру, 1.9.1 можно закодировать как число 0x00010901 — по байту на каждый компонент. В этом случае сравнение номеров версий тривиально.
А еще желательно предоставить пользователю #define с номером версии в хедерах библиотеки, чтобы его можно было проверить в процессе компиляции. Тогда при несоответствии версии библиотеки будет не обломинго при запуске программы, а внятное сообщение во время компиляции.
Спасибо, сделаю еще функцию (позже, когда с остальным разберусь).
"Ускорена работа с виджетами" — ваши слова?
Так вот, с виджетами работает кто? Правильно, пользователь твоей библиотеки. Именно он вызывает функции библиотеки для создания виджетов и прочих действий. Посему фраза об ускорении работы с виджетами звучит странно — вот и вопросы возникают странные.
Ладно, тут может я действительно неправильно выразился
Я бы — хммм — такие — хммм — "достижения" из описания библиотеки удалял. Во избежание.
Любой серьезный заказчик, увидев ограничение в 100 виджетов в описании библиотеки, сделает страшное лицо и скажет "на юх, на юх такое счастье!". И для него будет уже не важно, в каком контексте эти 100 виджетов там упоминаются.
Спасибо. Наверное уберу.
То есть сейчас он таки закрытый.
да нет, могу выложить — только там везде Vidgets а не Widgets — поэтому и не выкладывал.
Почему не сейчас? Автозамена в редакторе доступна всем.
Тогда придется переписывать еще 5 программ
Вот тут мы с тобой сделаем небольшую остановку и поговорим на отвлеченные темы.
Ты хочешь, чтобы твоей библиотекой начали пользоваться, так?
В таком случае ее интерфейс должен быть как можно более простым и очевидным. Если у тебя в интерфейсе присутствуют какие-то неочевидные вещи типа "карт", без которых ничего не будет работать — ты или убираешь эти вещи "под капот" (чтобы пользователь библиотеки о них даже не догадывался), или хорошенько описываешь в документации, на кой ляд они нужны и какие будут от их использования плюшки.
Если у тебя наружу торчат всякие малопонятные рычаги, за которые надо обязательно дернуть "чтобы все заработало", серьезный разработчик с тобой сотрудничать не будет.
Да, документации пока нет — то что есть, это небольшие пояснения.
Выделение памяти подо что? Зачем мне виджет, которым невозможно пользоваться? Почему нельзя было сделать отдельный виджет-рамку?
Вообще, архитектура библиотеки непонятна и запутанна.
Гм... Вот Вы наверняка знакомы с z-Буферами и двойной буферизацией в графике.
У меня примерно так же. Память выделяется под два буфера, которые в себе фактически хранят то, что на экране.
Весь вывод идет во второй буфер. При вызове UpdateScreen() происходит сравнение двух карт и там, где есть отличие — вывод на экран. И кстати функция FullUpdateScreen() полностью перерисовывает каждый виджет и вторую карту копирует в первую. А на эти карты нужны массивы. Теперь представим что у нас около 1000 виджетов, если на них всех сразу выделить память — то программа заберет прилично оперативной памяти (да, я понимаю что современные компьютеры сильные, но все же).
Хех.
Мало ли ситуаций.
К примеру, я хочу сделать красивое "влетающее из-за экрана" сообщение в рамочке. Или просто хочу переместить виджет временно в сторонку.
Как бы я это сделал в нормальной системе?
Создаю виджет где-нибудь в области отрицательных координат, пишу на нем текст, а потом в цикле вывожу его на экран, меняя координаты.
В твоей библиотеке мне придется ручками рисовать все промежуточные состояния виджета в разных стадиях "обрезанности".
Нет, движение виджетов невозможно. Это все я хочу сделать в библиотеке 2.X
Конечно через спину это можно сделать — создал виджет, заполнил, прорисовал, удалил, создал чуть в стороне, заполнил, прорисовал, удалил — но это все сложно и все-таки побольше процессорного времени заберет. Да, и в 2.X я хочу сделать возможность виджета в виджете — вот тут это как раз и будет нужно, потому что если делать как я написал выше — виджет будет перерисовываться полностью, а во втором случае — намного быстрее (так как виджет будет в другом виджете, а виджет прорисовывается оптимально).
Не понял.
Потому что документация к библиотеке практически отсутствует. Есть краткое описание API без намеков на то, как все это счастье работает.
Да, ее нет.
А нужна ли она, версия 2.х?
Ну, если честно, мне — нужна. ncurses, насколько я ее изучал, не дает того, что дает моя библиотека.
P.S. так Вам выложить исходники для компиляции в студии?
P.P.S. и тогда после сборки, пожалуйста, можете мне кинуть скомпилированные в студии библиотеки для Debug и для Release?
"Не так" то, что наличие таких функций свидетельствует о недоделанности библиотеки.
В хорошо вызревшей библиотеке такого счастья нет и быть не должно. Могут быть устаревшие функции.
И вновь возвратимся к отвлеченным темам.
Библиотека — она для кого? Она для разработчиков.
Это тебе прикольно ковыряться с ней, править функции, улучшать и переделывать.
Разработчику использовать нестабильный API — хуже смерти. А если при этом еще и непонятно, как оно все работает и что половина из функций делает — ваще не комильфо. Я бы в свой проект такую библиотеку потянул только в том случае, если задача очень сложная и других альтернатив нет.
Они вообще-то реализованы (кроме одной "пустой"), но чисто экспериментальны. А функция печатания с клавиатуры просто закомментирована и никак не описана.
Тут, понимаешь ли, сарказм — это способ заставить тебя посмотреть на свое творение немножко более критично.
Ведь по сути — что представляет из себя твоя библиотека? Некие бинари (хрен подключишь — я в студии даже примеры собрать не могу, чтобы посмотреть). Без внятной документации. С обилием таинственных, только автору понятных функций. С неясными целями и задачами ("рисовать виджеты в консоли" — это какое-то очень размытое описание функционала библиотеки). С явными следами недоделок (нереализованные функции) и какими-то неясными ограничениями.
Пользоваться этим без риска нарваться на грабли невозможно. Строить серьезный проект с использованием этой библиотеки — безумие. Создавать тестовые приложения для осваивания библиотеки — бессмысленно, потому что проще и продуктивнее будет написать своё, чем разбираться методом проб и ошибок в чужих потемках.
В крайнем случае — есть уже готовые библиотеки для работы с консолью (сурпрайз!). Например, ncurses — там есть практически все, что нужно. Оттестированный, многоплатформенный, хорошо документированный код. И даже под виндовс порт есть, кажися.
Тем не менее ты грозен и бесстрашен — выпускаешь новые версии (как будто старыми кто-то пользуется), бодро рапортуешь о каких-то улучшениях, ссылаешься на версию 2.х... Выглядит это как бурная деятельность по пиару какого-то полуфабриката, интересного пока только автору.
Гораздо конструктивнее, по моему личному мнению, было бы начать с анализа уже имеющихся библиотек. Что нравится в них, что не нравится. Что хотелось бы. Обсуждаем все это, намечаем пути реализации. Накидываем прототипчик. Проверяем, как оно работает и компилится под разными платформами. Расширяем функционал, потихоньку портируем под другие платформы (если надо). Без шума и помпы, без громогласных объявлений о выходе "новой супер-пупер-бета-версии noOneCaresAboutConsoleLib 1.9.33 с новой, улучшенной функцией создания хренаций для виджетов! Теперь хренаций у виджета может быть две, причем одна из них — активная, а другая — разноцветная!".
Если честно, изначально я писал библиотеку чисто для себя и своих нужд. Потому что не нашел ничего (и ncurses тоже!), что могло бы реализоваться мои мысли. Всегда у меня было мучение с прорисовкой в консоли и в каждой новой программе я заново и ужасно писал код, который это делал. Ну я и решил написать эту библиотеку. А сейчас решил просто показать другим, что у меня есть. Мало ли, вдруг кто-то сталкивается с такими же проблемами. И эта библиотека их решит.
Чтобы увидеть функционал надо скомпилировать примеры. Например тот же текстовый редактор. Благодаря этой библиотеки его прорисовка свелась к небольшой функции, а так там была огроменная функция, и все мигало и дергалось.
Так что могу выложить исходники.
P.S. только не забудьте прислать мне откомпилированную под студию библиотеку
Здравствуйте, Харч, Вы писали:
Х>Понял, спасибо. Просто например документация к графическому движку Irrlicht называется API, вот я и подумал...
Это не сама документация так называется — это так называется то, что она документирует.
Х>
Х>Почему не сейчас? Автозамена в редакторе доступна всем.
Х>Тогда придется переписывать еще 5 программ
Хинт: автозамена сработает и для 5 программ тоже.
Х>
Х>Выделение памяти подо что? Зачем мне виджет, которым невозможно пользоваться? Почему нельзя было сделать отдельный виджет-рамку?
Х>Вообще, архитектура библиотеки непонятна и запутанна.
Х>Гм... Вот Вы наверняка знакомы с z-Буферами и двойной буферизацией в графике. Х>У меня примерно так же. Память выделяется под два буфера, которые в себе фактически хранят то, что на экране. Х>Весь вывод идет во второй буфер. При вызове UpdateScreen() происходит сравнение двух карт и там, где есть отличие — вывод на экран. И кстати функция FullUpdateScreen() полностью перерисовывает каждый виджет и вторую карту копирует в первую. А на эти карты нужны массивы. Теперь представим что у нас около 1000 виджетов, если на них всех сразу выделить память — то программа заберет прилично оперативной памяти (да, я понимаю что современные компьютеры сильные, но все же).
Во-от. Вот с этого и надо начинать. С обсуждения архитектуры.
Сначала ты выкладываешь исходники, описываешь, что это и как оно работает. Огребаешь шуточек и смехуечков по поводу именования функций, форматирования, неструктурированности кода и т. п. — желающих высказаться по этому поводу всегда в достатке. Код слегка причесывается (там, где явные косяки), остальные замечания игнорируются.
А вот потом начинается самое интересное — начинается обсуждение общей архитектуры.
Если в результате обсуждения рисуется хорошая, логичная, надежная, простая в использовании архитектура — имеет смысл вообще выкинуть старый код и написать все заново. "По мотивам". В результате получится — теоретически — неплохой продукт.
Лично мне идея с двумя буферами кажется симпатичной, но немножко непродуманной. По сути ты сравниваешь два состояния одного и того же виджета для того, чтобы вывести на экран "дельту". Это ускорение никак не поможет отследить взаимодействие между виджетами (перекрытие одного другим, например).
Можно посмотреть в сторону подхода, реализованный в ncurses: там изображение буферизуется для всего экрана: один буфер содержит "слепок" экрана, второй — текущий. При отрисовке буфера синхронизируются, дельта попадает на экран.
Когда-то давно я тоже писал нечто подобное для работы с окошками в текстовом режиме. Называлось оно Boxes (потому как про виджеты я тогда не слышал), состояло из двух библиотек (просто Boxes и HiBoxes). В первой библиотеке были примитивы для создания и отрисовки окошек с разными рамочками, цветами, скроллинга текста в них, ввода-вывода строк и т. п. Во второй были высокоуровневые виджеты — мессаджбоксы, диалоги ввода строк и паролей, диалоги выбора файлов и т. п. Так вот, там был у каждого бокса свой буфер для хранения изображения, поверх которого бокс расположен. Это позволяло, например, отрисовать мессаджбокс (он сам центровался на экране и рассчитывал нужную для себя ширину и высоту), а потом при нажатии на Ок он уходил с экрана и изображение восстанавливалось.
К сожалению, там использовался прямой доступ к видеопамяти, посему работало все это только в ДОСе.
Х>
Х>А нужна ли она, версия 2.х?
Х>Ну, если честно, мне — нужна. ncurses, насколько я ее изучал, не дает того, что дает моя библиотека. Х>P.S. так Вам выложить исходники для компиляции в студии?
Выложи, чо.
Х>P.P.S. и тогда после сборки, пожалуйста, можете мне кинуть скомпилированные в студии библиотеки для Debug и для Release?
А зачем они тебе? Для коллекции?
Х>Если честно, изначально я писал библиотеку чисто для себя и своих нужд. Потому что не нашел ничего (и ncurses тоже!), что могло бы реализоваться мои мысли.
Так практически все проекты начинаются.
Другое дело, что большинство проектов так и заканчивается.
Х> Всегда у меня было мучение с прорисовкой в консоли и в каждой новой программе я заново и ужасно писал код, который это делал. Ну я и решил написать эту библиотеку. А сейчас решил просто показать другим, что у меня есть. Мало ли, вдруг кто-то сталкивается с такими же проблемами. И эта библиотека их решит.
Пока библиотека создает больше проблем, чем их решает, потому что не описана и не продумана.
Х>Так что могу выложить исходники. Х>P.S. только не забудьте прислать мне откомпилированную под студию библиотеку
Собственно, с выкладывания исходников и надо было начинать.
Это не сама документация так называется — это так называется то, что она документирует.
Спасибо, теперь знаю
Хинт: автозамена сработает и для 5 программ тоже.
Я понимаю, но было как-то боязно в программе из 2000 строк делать автозамену :D психология :D
Во-от. Вот с этого и надо начинать. С обсуждения архитектуры.
Сначала ты выкладываешь исходники, описываешь, что это и как оно работает. Огребаешь шуточек и смехуечков по поводу именования функций, форматирования, неструктурированности кода и т. п. — желающих высказаться по этому поводу всегда в достатке. Код слегка причесывается (там, где явные косяки), остальные замечания игнорируются.
А вот потом начинается самое интересное — начинается обсуждение общей архитектуры.
Если в результате обсуждения рисуется хорошая, логичная, надежная, простая в использовании архитектура — имеет смысл вообще выкинуть старый код и написать все заново. "По мотивам". В результате получится — теоретически — неплохой продукт.
Лично мне идея с двумя буферами кажется симпатичной, но немножко непродуманной. По сути ты сравниваешь два состояния одного и того же виджета для того, чтобы вывести на экран "дельту". Это ускорение никак не поможет отследить взаимодействие между виджетами (перекрытие одного другим, например).
Можно посмотреть в сторону подхода, реализованный в ncurses: там изображение буферизуется для всего экрана: один буфер содержит "слепок" экрана, второй — текущий. При отрисовке буфера синхронизируются, дельта попадает на экран.
Когда-то давно я тоже писал нечто подобное для работы с окошками в текстовом режиме. Называлось оно Boxes (потому как про виджеты я тогда не слышал), состояло из двух библиотек (просто Boxes и HiBoxes). В первой библиотеке были примитивы для создания и отрисовки окошек с разными рамочками, цветами, скроллинга текста в них, ввода-вывода строк и т. п. Во второй были высокоуровневые виджеты — мессаджбоксы, диалоги ввода строк и паролей, диалоги выбора файлов и т. п. Так вот, там был у каждого бокса свой буфер для хранения изображения, поверх которого бокс расположен. Это позволяло, например, отрисовать мессаджбокс (он сам центровался на экране и рассчитывал нужную для себя ширину и высоту), а потом при нажатии на Ок он уходил с экрана и изображение восстанавливалось.
К сожалению, там использовался прямой доступ к видеопамяти, посему работало все это только в ДОСе.
Да, я так и собираюсь сделать. По мотивам А вот идеи про создании буфера всего экрана не было, спасибо! Это сразу решает проблемы взаимодействия виджетов
P.S. я думал это решить созданием виджета в виджете, но как Вы сказали — намного симпатичнее .
А не сделал я этого потому, что всегда от балды создавал экран 1000 на 1000, и рисовал в консоли абсолютно не заботясь о границах, потому что 1000 намного вылазит за пределы консоли А кстати, как Вы считаете, лучше сделать виджет самостоятельной единицей (как писал выше в сообщениях), или все же оставить обращение по имени?
Да, я тоже хотел потом написать ConsoleWindow, с поддержкой "графических" окошек и так далее Но пока перепишу ConsoleGraph.
А Вы на чем писали Boxes?
P.S. оказывается не я один встречал проблемы с отрисовкой в консоли
Да, я понимаю все насчет использования map<> и так далее, я хотел сделать доступ по ключу — имя виджета, но поленился :D
Это можно не обсуждать
Да, кстати спасибо за конструктивную критику и полезные советы
Здравствуйте, Харч, Вы писали:
Х> А кстати, как Вы считаете, лучше сделать виджет самостоятельной единицей (как писал выше в сообщениях), или все же оставить обращение по имени?
Я бы сделал все по-взрослому. Виджет — это отдельный объект. Как там его пользователь обзовет и куда будет помещать — дело самого пользователя. Например, захочет он виджеты в список запихать — пусть себе запихивает (только не сам объект, а указатель — чтобы не было операций копирования).
Обращение по именам — это излишество нехорошее. Возьмем ситуацию, когда пользователь (библиотеки) опечатался и пытается обратиться к виджету, которого нет. Если он опечатался в имени объекта — компилятор ему не даст совершить святотатство и скажет, что нету такого. А вот если опечатка — в строке, то кирдык придет уже во время выполнения программы, что не есть хорошо.
Х>А Вы на чем писали Boxes?
На С. Впрочем, сишным компилятором оно не собиралось, потому что использовались кое-какие плюсовые фишечки типа объявления переменных в середине тела функции.
В то время я был уверен, что пишу на С++.
Хмм... Приятно прям вспомнить.
Подход был чисто сишный: сначала вызывалась функция для создания бокса (ей передавались размеры и тип рамочки — одинарная, двойная, с тенью кажися тоже были). Функция возвращала хэндл созданного бокса.
Далее этот хэндл (на самом деле это был int, или даже short) передавался всем остальным функциям.
Внутри библиотеки был список хэндлов, причем, кажется, односвязный. Хэндлы отводились сначала по счетчику, который инкрементился после создания каждого нового бокса, а потом (когда счетчик переполнялся) — тупым поиском первого свободного хэндла.
Внутри Boxes были примитивы для работы с окнами через эти вот хэндлы, ну и всякая вспомогальщина: константы для задания цветов, функции для чтения с клавиатуры, для проверки того, не нажата ли на клавиатуре кнопка, ну и т. п.
HiBoxes внутри, естественно, использовали Boxes для работы с окнами. Их задача была рисовать высокоуровневые окошки для взаимодействия с пользователем — ну, я уже писал.
В общем и целом оно работало и было даже в чем-то красиво. Единственное, что я так и не осилил, это сделать правильный диалог выбора файла: у меня файлы располагались на экране не столбиками, а по строчкам. Ну и, естественно, никакой поддержки мыши не было.
Если бы я это писал сейчас, я бы писал совсем по-другому: вместо россыпи функций были бы объекты и их методы, никаких хэндлов. Внутри бы пришлось, конечно, ввести какую-нибудь буферизацию — консольные функции в виндовсе медленные, это вам не в ДОСе в видеопамять байтики писать. Опять же, в виндовсе консолька может быть не только 80х25, как в ДОСе, поэтому надо ввести функции для определения размера экрана. Поддержка мышки была бы неплоха.
А если бы еще сделать библиотеку кроссплатформенной — ей бы вообще цены не было (в юниксовых консольках рисовать без ncurses — это мечта). Тут, правда, есть большой затык: termcap частенько врет, да и парсить его запарисся.
Да, и еще для виндовсовской библиотеки обязательно надо предусмотреть перекодирование ANSI->OEM и обратно, чтобы строчки в виндовой кодировке не портились при выводе на консоль. А еще лучше было бы ввести полную поддержку юникода — тогда все строчки можно было бы задавать в UTF8 и не париться.
Х>P.S. оказывается не я один встречал проблемы с отрисовкой в консоли
Их встречали многие. Поэтому велосипедов масса, а толку чуть.
Х>Ну да, просто некоторые люди не умеют делать сборки библиотек (o_O) и просят меня им прислать (знакомые люди).
Тю.
Таким дать сорцы — пусть их в свой проект добавят и не парятся. Все равно криворукие, вреда не причинят.
Кстати по исходникам: краем глаза посмотрел в них и ужаснулся.
Ни одного комментария не заметил, везде какие-то вложенные циклы... Ппц.
Кстати, у тебя с именами виджетов ровно та же ситуация, что у меня в свое время была с хэндлами: ты держишь внутри библиотеки список виджетов. Только вот обрабатываешь ты его по-китайски: вместо того, чтобы сделать по-нормальному map<string, Widget> и искать виджеты по имени напрямую, ты в цикле перебираешь некие целочисленные идентификаторы. Мало того, что это лишний цикл, так ты в этом цикле еще и строки сравниваешь каждый раз. Забавно будет наблюдать, как феерично твоя библиотека будет тормозить при работе с большим количеством виджетов.
Функцию GetVersionEngine() надо сделать статической — или у тебя в разных экземплярах класса screen могут быть разные версии библиотеки?
Функция SetInfoParamEngine() вообще не нужна. GetVersionEngine() должна тупо возвращать литерал, задефайненный где-нибудь в хедере.
Я бы сделал все по-взрослому. Виджет — это отдельный объект. Как там его пользователь обзовет и куда будет помещать — дело самого пользователя. Например, захочет он виджеты в список запихать — пусть себе запихивает (только не сам объект, а указатель — чтобы не было операций копирования).
Обращение по именам — это излишество нехорошее. Возьмем ситуацию, когда пользователь (библиотеки) опечатался и пытается обратиться к виджету, которого нет. Если он опечатался в имени объекта — компилятор ему не даст совершить святотатство и скажет, что нету такого. А вот если опечатка — в строке, то кирдык придет уже во время выполнения программы, что не есть хорошо.
Хорошо, но разве не лучше уже иметь переменную, которая работает со всеми виджетами, сама их сортирует, считает и так далее? Занимается стиранием их с экрана, прорисовкой?
На С. Впрочем, сишным компилятором оно не собиралось, потому что использовались кое-какие плюсовые фишечки типа объявления переменных в середине тела функции.
В то время я был уверен, что пишу на С++.
Хмм... Приятно прям вспомнить.
Подход был чисто сишный: сначала вызывалась функция для создания бокса (ей передавались размеры и тип рамочки — одинарная, двойная, с тенью кажися тоже были). Функция возвращала хэндл созданного бокса.
Далее этот хэндл (на самом деле это был int, или даже short) передавался всем остальным функциям.
Внутри библиотеки был список хэндлов, причем, кажется, односвязный. Хэндлы отводились сначала по счетчику, который инкрементился после создания каждого нового бокса, а потом (когда счетчик переполнялся) — тупым поиском первого свободного хэндла.
Внутри Boxes были примитивы для работы с окнами через эти вот хэндлы, ну и всякая вспомогальщина: константы для задания цветов, функции для чтения с клавиатуры, для проверки того, не нажата ли на клавиатуре кнопка, ну и т. п.
HiBoxes внутри, естественно, использовали Boxes для работы с окнами. Их задача была рисовать высокоуровневые окошки для взаимодействия с пользователем — ну, я уже писал.
В общем и целом оно работало и было даже в чем-то красиво. Единственное, что я так и не осилил, это сделать правильный диалог выбора файла: у меня файлы располагались на экране не столбиками, а по строчкам. Ну и, естественно, никакой поддержки мыши не было.
Если бы я это писал сейчас, я бы писал совсем по-другому: вместо россыпи функций были бы объекты и их методы, никаких хэндлов. Внутри бы пришлось, конечно, ввести какую-нибудь буферизацию — консольные функции в виндовсе медленные, это вам не в ДОСе в видеопамять байтики писать. Опять же, в виндовсе консолька может быть не только 80х25, как в ДОСе, поэтому надо ввести функции для определения размера экрана. Поддержка мышки была бы неплоха.
А если бы еще сделать библиотеку кроссплатформенной — ей бы вообще цены не было (в юниксовых консольках рисовать без ncurses — это мечта). Тут, правда, есть большой затык: termcap частенько врет, да и парсить его запарисся.
Да, и еще для виндовсовской библиотеки обязательно надо предусмотреть перекодирование ANSI->OEM и обратно, чтобы строчки в виндовой кодировке не портились при выводе на консоль. А еще лучше было бы ввести полную поддержку юникода — тогда все строчки можно было бы задавать в UTF8 и не париться.
Интересно... Да, сделаю тогда кроссплатформенной, тем более что я знаю как в юникс-консоли рисовать цвета, правда в cygwin не получится наверное так, придется виртуалку ставить, но ладно. Функции перекодировки есть, тоже хотел встроить, но о поддержке UTF8 не думал, там проблема с двойной Я вроде
Их встречали многие. Поэтому велосипедов масса, а толку чуть.
Все-таки хотелось бы иметь универсальное решение, не такой громоздкое как ncurses
Тю.
Таким дать сорцы — пусть их в свой проект добавят и не парятся. Все равно криворукие, вреда не причинят.
Лады, дам им ашники
Кстати по исходникам: краем глаза посмотрел в них и ужаснулся.
Ни одного комментария не заметил, везде какие-то вложенные циклы... Ппц.
Кстати, у тебя с именами виджетов ровно та же ситуация, что у меня в свое время была с хэндлами: ты держишь внутри библиотеки список виджетов. Только вот обрабатываешь ты его по-китайски: вместо того, чтобы сделать по-нормальному map<string, Widget> и искать виджеты по имени напрямую, ты в цикле перебираешь некие целочисленные идентификаторы. Мало того, что это лишний цикл, так ты в этом цикле еще и строки сравниваешь каждый раз. Забавно будет наблюдать, как феерично твоя библиотека будет тормозить при работе с большим количеством виджетов.
Да, я сам ужасаюсь, поэтому все и буду переписывать, благо знания сейчас раз 100 лучше
Школа все-таки то была
Функцию GetVersionEngine() надо сделать статической — или у тебя в разных экземплярах класса screen могут быть разные версии библиотеки?
Функция SetInfoParamEngine() вообще не нужна. GetVersionEngine() должна тупо возвращать литерал, задефайненный где-нибудь в хедере.
Здравствуйте, Харч, Вы писали:
Х>Хорошо, но разве не лучше уже иметь переменную, которая работает со всеми виджетами, сама их сортирует, считает и так далее? Занимается стиранием их с экрана, прорисовкой?
Виджет не рисует себя сам по себе. Виджет рисуется где-то. Например, на экране, или внутри другого виджета (если захочется, например, реализовать диалоговые окна, такая возможность может понадобиться).
Посему делаем разделение: есть виджеты, есть то, что их содержит и где они отображаются (контейнеры).
Х>Интересно... Да, сделаю тогда кроссплатформенной, тем более что я знаю как в юникс-консоли рисовать цвета, правда в cygwin не получится наверное так, придется виртуалку ставить, но ладно. Функции перекодировки есть, тоже хотел встроить, но о поддержке UTF8 не думал, там проблема с двойной Я вроде
Насчет цигвина — он тоже умеет рисовать в консоли, только для этого надо ANSI.SYS подключить. Впрочем, могу ошибаться.
Проблема с двойной Я? Не слышал. Надо будет проверить.
Х>
Х>Их встречали многие. Поэтому велосипедов масса, а толку чуть.
Х>Все-таки хотелось бы иметь универсальное решение, не такой громоздкое как ncurses
Надо помнить, что ncurses изначально разрабатывался для Юниксов, неоднократно менялся, имеет кучу устаревших функций, и вообще написан на С.
Правильно спроектированная иерархия классов на С++ будет гораздо удобнее в использовании. И можно отказаться от поддержки всяких экзотических терминалов под юниксами (в нкурсес много прыжков делается именно вокруг экзотического барахла) — сейчас практически все терминалы отображают цвет и имеют поддержку мыши.
Насчет цигвина — он тоже умеет рисовать в консоли, только для этого надо ANSI.SYS подключить. Впрочем, могу ошибаться.
Проблема с двойной Я? Не слышал. Надо будет проверить.
Да, сталкивался когда писал эту кодировку для своего MUD.
Надо помнить, что ncurses изначально разрабатывался для Юниксов, неоднократно менялся, имеет кучу устаревших функций, и вообще написан на С.
Правильно спроектированная иерархия классов на С++ будет гораздо удобнее в использовании. И можно отказаться от поддержки всяких экзотических терминалов под юниксами (в нкурсес много прыжков делается именно вокруг экзотического барахла) — сейчас практически все терминалы отображают цвет и имеют поддержку мыши.
Да, понятно.
Вообщем спасибо, я в общих чертах пока понял, куда надо идти Пойду, буду тут выкладывать версии. И слушать замечания (ну и шуточки конечно ). Сейчас началась учеба, так что думаю следующая версия будет в январе (с полностью измененной архитектурой) (в январе-феврале каникулы ).
Доброго времени суток!
Очень интересная работа, когда то и сам сталкивался с "проблемой графитизации игры". Новичкам в с++, даст возможность, а не вешать нос от нехватки знаний для реализации идей. Поскольку торможение в "неизбежном", очень часто губит задатки хороших проектов (а 3д, рано или поздно выучится). Известная Ancient Domains of Mystery ( или ADOM) имела ряд поклонников уж точно не из-за красивой графики, А сия библиотека, как раз и дает возможность сделать упор на логику, реализацию игрового мира и многие другие вещи (главное дает возможность написать и посмотреть как оно работает).
Так что тут самое главное, знать на кого и для каких зада рассчитан этот проект и не останавливаться на достигнутом. Код лучше переведи в статус "открытого", сделай сайт проекта, думаю так будет некая популярность. Да и поможешь многим начинающим игроделам.
Здравствуйте, Andrey, Вы писали:
A>Доброго времени суток! A>Очень интересная работа, когда то и сам сталкивался с "проблемой графитизации игры". Новичкам в с++, даст возможность, а не вешать нос от нехватки знаний для реализации идей. Поскольку торможение в "неизбежном", очень часто губит задатки хороших проектов (а 3д, рано или поздно выучится). Известная Ancient Domains of Mystery ( или ADOM) имела ряд поклонников уж точно не из-за красивой графики, А сия библиотека, как раз и дает возможность сделать упор на логику, реализацию игрового мира и многие другие вещи (главное дает возможность написать и посмотреть как оно работает).
A>Так что тут самое главное, знать на кого и для каких зада рассчитан этот проект и не останавливаться на достигнутом. Код лучше переведи в статус "открытого", сделай сайт проекта, думаю так будет некая популярность. Да и поможешь многим начинающим игроделам.
Спасибо, именно для этого я и писал эту библиотеку. Сейчас, оценив все данные мне советы, решил написать библиотеку заново, но, разумеется, все будет намного быстрее, так как почти все функции реализованы. Изменится только архитектура. Будет нормальное управление классам, указатели на виджеты, работа с виджетами не по именам, а через указатели на них.
Так же возникла такая идея. Вот я думал, ну, написал я эту штуку, все отлично работает. А дальше я хочу например ввести окошки, мышку (точнее, ее некое подобие, управляется с клавиатуры, но можно и перехватывать события мыши), и так далее. В библиотеку я этого вносить, понятное дело, не буду. Это будет уже лишнее для минималистичности и понимаемости библиотеки. Но для тех кто хочет — должно же быть. И возникла идея сделать поддержку модулей для библиотеки. Например хочешь написать модуль — наследуешь класс от какого-нибудь ModulClassConsoleGraphicEngine и пишешь свои функции, плюс ко всему сделать возможность создавать свои классы на основе того же класса виджета. Например мы хотим создать что-то вроде такого:
Screen *s = new Screen(0,0,100,100);
Widget* a = new Widget(0,0,100,100); s->registerWidget(a); a->addWindow(10,10,50,50);
но функции addWindow нет у класса Widget. Поэтому создается класс уже в модуле, наследуемый от Widget, например w_Widget и тогда уже пишем:
Screen *s = new Screen(0,0,100,100);
w_Widget* a = new w_Widget(0,0,100,100); s->registerWidget( (Widget*)a ); a->addWindow(10,10,50,50);
И тогда уже все будет нормально работать. Вот тут я хочу услышать советы, если можно. Вообще, есть ли возможность полностью перегрузить класс, то есть чтобы не создавать нового w_Widget, а использовать старый Widget, но с новыми функциями, или нет? Сам о таком вообще не слышал. Лично мне кажется, что такого нет и быть не может...
Спасибо за помощь!
P.S. насчет сайта проекта — хочу узнать, зачем. Вроде и темы достаточно Все равно это же не шедевр
Здравствуйте, Харч, Вы писали:
Х> Так же возникла такая идея. Вот я думал, ну, написал я эту штуку, все отлично работает. А дальше я хочу например ввести окошки, мышку (точнее, ее некое подобие, управляется с клавиатуры, но можно и перехватывать события мыши), и так далее. В библиотеку я этого вносить, понятное дело, не буду. Это будет уже лишнее для минималистичности и понимаемости библиотеки. Но для тех кто хочет — должно же быть.
Делаешь две библиотеки — низкоуровневую (базовые виджеты, работа с экраном и мышой/тачскрином, рисование линий и рамок) и высокоуровневую (диалоги, мессаджбоксы, и т.п.). Высокоуровневая, соответственно, использует низкоуровневую библиотеку.
Заодно от теории перейдешь к практике, когда в боевых условиях начнешь свои консольные примитивы использовать и комбинировать.
Х> И возникла идея сделать поддержку модулей для библиотеки. Например хочешь написать модуль — наследуешь класс от какого-нибудь ModulClassConsoleGraphicEngine и пишешь свои функции, плюс ко всему сделать возможность создавать свои классы на основе того же класса виджета.
Слишком сложно и ненужно.
Сложно потому, что для написания такого вот модуля нужно разобраться с библиотеке досконально. Большинству народа неохота ковыряться в чужом коде, особенно если это библиотека. Так что никто не будет заморачиваться никакими модулями, будут юзать то, что есть. Ну или просто выкинут и напишут свой лисапет с нуля.
Х>Например мы хотим создать что-то вроде такого: Х>Screen *s = new Screen(0,0,100,100); Х>Widget* a = new Widget(0,0,100,100); Х>s->>registerWidget(a); Х>a->>addWindow(10,10,50,50);
Х>но функции addWindow нет у класса Widget. Поэтому создается класс уже в модуле, наследуемый от Widget, например w_Widget и тогда уже пишем: Х>Screen *s = new Screen(0,0,100,100); Х>w_Widget* a = new w_Widget(0,0,100,100); Х>s->>registerWidget( (Widget*)a ); // здесь не нужен каст к указателю на предка — он автоматический в С++. Х>a->>addWindow(10,10,50,50);
Все так же непонятно, зачем нужен объект Screen, попахивает странным дизайном. Ну да ладно.
Х>И тогда уже все будет нормально работать. Вот тут я хочу услышать советы, если можно. Вообще, есть ли возможность полностью перегрузить класс, то есть чтобы не создавать нового w_Widget, а использовать старый Widget, но с новыми функциями, или нет? Сам о таком вообще не слышал. Лично мне кажется, что такого нет и быть не может...
Если какие-то функции уникальны для производного класса, то да, ты не сможешь вызвать их по указателю на базовый класс.
Или придется добавить пустышку в базовый класс, или делать каст (или использовать паттерн visitor).
Сие справедливо для С++. В ObjectiveC другая философия работы с объектами, там можно вызвать функцию, отсутствующую в базовом классе (правда, там это называется "отсылкой мессаджа", если я правильно помню).
Х>Спасибо за помощь!
Не за что.
Х>P.S. насчет сайта проекта — хочу узнать, зачем. Вроде и темы достаточно Все равно это же не шедевр
Отдельный сайт можно добавить в закладки, а значит, народу легче будет найти твою библиотеку. А больше народу — больше комьюнити, глядишь, кто-нибудь надоумит сделать чего умного или поможет граблю какую обойти.
На сорсфорж хотя бы выложи.
