Программа для создания кроссвордов, Обсуждение программы и кода Опции

[xwicked]

Здравствуйте!

Хочу порадовать Вас тем, что я сделал дополнительный архив исходного кода, для сборки программы в ОС GNU / Linux Debian( / Ubuntu).
Для сборки deb-пакета необходимо наличие установленных пакетов: autotools-dev, dh-make, fakeroot, cdbs, dpkg, dpkg-dev и другие.
Команда сборки:

user@pc:/klest-crossword-0.1.9-deb$ dpkg-buildpackage -rfakeroot

Для проверки правильности соответствия стандартам дистрибутива Debian, используйте пакет Lintian.
0.1.9. Исходный код + сборки

Что нового:

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

[xwicked]

Следующая версия = 0.2.0.

Исходный код + сборки: 0.2.0.

Важное изменение: добавление значков Oxygen. Ещё добавлены 2-а новых словаря: русский на 31 000 слов и английский на 41 000 слов. Теперь программа выглядит вот так -


Произведённые изменения:

- Добавлены значки "Oxygen", распространяемые по лицензии GNU GPL;
- Исправлена ошибка экспорта кроссворда в изображение форматов JPG, JPEG, TIFF;
- Добавлена возможность выбора словаря для составления кроссворда. Возможные варианты: русский и английский;
- Изменена стандартная панель - добавлены несколько новых действий, исправлены ошибки;
- Изменён формат файла свойств программы, в сторону более простого добавления в него будущих свойств.

[Алексей1153]

xwicked,

Структура файла - динамическая.

Изменён формат файла свойств программы, в сторону более простого добавления в него будущих свойств.

я, даже не уточняя формат файла, сразу советую перейти к XML Если, конечно, уже не. Поверь, в случае использования XML процитированный тект не имеет смысла упоминать вообще.

[xwicked]

...я, даже не уточняя формат файла, сразу советую перейти к XML Если, конечно, уже не. Поверь, в случае использования XML процитированный тект не имеет смысла упоминать вообще.

Все форматы файлов двоичные. От XML я отказался и в будущем не буду его использовать вообще.
Аргументы:
1. Громоздкость самого формата;
2. Переносимость моего двоичного формата созданных файлов;
3. Увеличение размера Win и Mac сборок программы, за счёт добавления лишней библиотеки.
Думаю достаточно

[Алексей1153]

xwicked, громоздкость ? Да ерунда. Имена неосновных узлов можно задавать покороче. Всё остальное хорошо сожмётся архиватором

Минусы двоичных форматов:
1. громоздкость самого формата. Давай, сохрани туда вектор или мапу Опупеешь.
2. Непереносимость и трудность переходов между версиями. Байт влево , байт вправо - расстрел на месте. Также нужно постоянно помнить и трястись над тем, чтобы (см п1) содержимое структур можно было бы побайтово копировать, а также чтобы не менялся порядок сохранения данных
3. за счёт чего увеличение ? Например, я сохраняю XML "вручную" (мне так показалось удобнее), а парсю готовым классом с открытыми исходниками. Ну добавит это всё от силы пару килобайт в модуль.

ЗАТО

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

лично я раньше сохранял в двоичные файлы, но когда узнал про XML - теперь никогда такой хренью не страдаю )))

xwicked, ох, а как весело поддерживать программы, где программист вовсю сохранял структурированные данные в двоичные файлы... Я вот сейчас такой проект веду. Как внезапно начинало рушиться - а поразбираешься, вот она, причина. Поменял местами переменные в структуре, а он, гат такой, в двоичные файлы любит записывать, в результате записывается указатель (и читается тоже). Не поленился, потратил два дня на переделывание в XML - теперь полёт нормальный )

Ещё один интересный момент: как думаешь, что сохранится в файл, если запишешь туда переменную типа B ?

Раскрывающийся текст

struct A
{
    int a;

    A():a(0x00)
    {
    }

    A(int a):a(a)
    {
    }

    virtual ~A()
    {
    }
};

struct B:A
{
    A a2;
    int b;

    B():a2(0x11),b(0x22)
    {
    }
};

B b;
int i=sizeof(b); //сколько ?
void* p=&b;      //что там ?

Сообщение отредактировал Алексей1153 - 23.8.2011, 9:04

[Litkevich Yuriy]

1. громоздкость самого формата. Давай, сохрани туда вектор или мапу

это элементарно, по сравнению с XML

Непереносимость и трудность переходов между версиями. Байт влево , байт вправо - расстрел на месте.

это смотря как опишешь формат.

Ещё один интересный момент: как думаешь, что сохранится в файл, если запишешь туда переменную типа B ?

приведи тотже пример только с XML

[Алексей1153]

это элементарно, по сравнению с XML

сравнимо. Плюс в дальнейшей совместимости и поддержке, а также в человекочитаемости контента

это смотря как опишешь формат.

в том и прелесть, что в XML не надо думать, как был описан формат. Главное - не упадёт ничего

приведи тотже пример только с XML

не понял вопроса

Сообщение отредактировал Алексей1153 - 23.8.2011, 9:55

[xwicked]

xwicked, громоздкость ? Да ерунда. Имена неосновных узлов можно задавать покороче. Всё остальное хорошо сожмётся архиватором

Минусы двоичных форматов:
1. громоздкость самого формата. Давай, сохрани туда вектор или мапу Опупеешь.
2. Непереносимость и трудность переходов между версиями. Байт влево , байт вправо - расстрел на месте. Также нужно постоянно помнить и трястись над тем, чтобы (см п1) содержимое структур можно было бы побайтово копировать, а также чтобы не менялся порядок сохранения данных
3. за счёт чего увеличение ? Например, я сохраняю XML "вручную" (мне так показалось удобнее), а парсю готовым классом с открытыми исходниками. Ну добавит это всё от силы пару килобайт в модуль. ...

Вы немножко не осведомлены в вопросе даваемого Вами совета:
1

# Размер XML-документа существенно больше бинарного представления тех же данных. В грубых оценках величину этого фактора принимают за 1 порядок (в 10 раз).
# Размер XML-документа существенно больше, чем документа в альтернативных текстовых форматах передачи данных (например JSON[4], YAML, Protocol Buffers) и особенно в форматах данных, оптимизированных для конкретного случая использования.
# Избыточность XML может повлиять на эффективность приложения. Возрастает стоимость хранения, обработки и передачи данных.
# XML содержит метаданные (об именах полей, классов, вложенности структур), и одновременно XML позиционируется как язык взаимодействия открытых систем. При передаче между системами большого количества объектов одного типа (одной структуры), передавать метаданные повторно нет смысла, хотя они содержатся в каждом экземпляре XML описания.
# Для большого количества задач не нужна вся мощь синтаксиса XML и можно использовать значительно более простые и производительные решения.

Ссылка на Википедию. Не привожу статьи из журналов, где многие думают о пересмотре стандарта XML и как от него отказываются.
2. Это если речь идёт о структурах и о стандартном C++. Я же сохраняю типы QStringList, QFont и подобные, их сможет загрузить только Qt, который изначально переносимый.
3. Вручную это делать глупо, когда есть интерфейсы DOM и SAX. Увеличение за счёт добавление библиотеки QtXml + библиотека для сжатия этого XML.

ЗЫ: Всё просто

Сообщение отредактировал xwicked - 23.8.2011, 10:17

[Алексей1153]

xwicked, я прекрасно осведомлён о содержимом и устройстве простейшего XML, который использую очень часто

Я не навязываю. К этому сам потом придёшь, когда будешь зарабатывать на жизнь программированием. XML против бинарников - это экономия сил, времени и , соответственно, денег. Я советую именно потому, что всё это прошёл и знаю разницу. Есть выбор:
1) бинарник + малый объём + много гемора при отладке и совместимости версий
2) XML + чуть побольше объём + удобная отладка, поддержка и совместимость


А рост объёма сейчас мало кого волнует - ресурсы машин растут несоизмеримо быстрее.

# Размер XML-документа существенно больше бинарного представления тех же данных. В грубых оценках величину этого фактора принимают за 1 порядок (в 10 раз).
# Размер XML-документа существенно больше, чем документа в альтернативных текстовых форматах передачи данных (например JSON[4], YAML, Protocol Buffers) и особенно в форматах данных, оптимизированных для конкретного случая использования.
# Избыточность XML может повлиять на эффективность приложения. Возрастает стоимость хранения, обработки и передачи данных.
# XML содержит метаданные (об именах полей, классов, вложенности структур), и одновременно XML позиционируется как язык взаимодействия открытых систем. При передаче между системами большого количества объектов одного типа (одной структуры), передавать метаданные повторно нет смысла, хотя они содержатся в каждом экземпляре XML описания.
# Для большого количества задач не нужна вся мощь синтаксиса XML и можно использовать значительно более простые и производительные решения.

глупость. Никто не заставляет постоянно читать и записывать - загрузи в память в любом привычном виде и работай. XML - это хранилище, совместимое во времени с другими версиями программы и между запусками. Метаданные - архиватор спасёт от избыточности .

Вручную это делать глупо

зато эффективно и не делает

3. Увеличение размера Win и Mac сборок программы, за счёт добавления лишней библиотеки.

В общем-то , не хотел "зафлуживать" тему , я дал совет - тебе решать. Я думал, плюсы и так очевидны

xwicked, но всёж-таки, интересно, каков у тебя ответ на вопрос

B b;
int i=sizeof(B ); //сколько ?
void* p=&b; //что там ?

и какова будет реакция деструктора переменной при попытке считывания из файла

Сообщение отредактировал Алексей1153 - 23.8.2011, 11:17

[xwicked]

... когда будешь зарабатывать на жизнь программированием. ...

У меня нет СМИ на подхвате, как у Попова, вопреки светофору - всё будет у меня отлично!!!

ЗЫ: Осторожно, толстый юмор(продолжение)!