Действительно, настолько привык, что не замечаю очевидных ошибок.
Мне подсказали статьи про опенсорс и составление документации. Рассчитываю, что они помогут как минимум с документацией, а как максимум со всем остальным.
Фатальная ошибка для одного класса часто не фатальна для программы. Ошибки часто возникают, когда программа запущена, а меня нет рядом. В такой ситуации лучше, чтобы программа хоть как-то доработала, до того как я смогу ее починить.
Там были свои финты ушами, когда исправлялся каждый класс массива, под свою задачу. С шаблонами так не сделаешь, да и не надо.
Возможно я недостаточно работал с шаблонами и для меня их использование запутывает код. Начал больше писать шаблонные классы и ситуация понемногу исправляется.
К сожалению в шаблонах stl я до сих пор ориентируюсь довольно хреново.
В Boost нет Trie?
Ммм, все зависит от того, что вам нужно. Это достаточно оптимальная, но не самая быстрая реализация. Для ускорения поиска сюда стоит добавить хеш таблицу или lower bound. Так же у меня реализация многоуровнего дерева(одно дерево может содержать другое), сделанная для быстрого поиска по JSON.
Это все нужно обсуждать. И основываясь на понимании логики Boost, которой у меня к сожалению нет, и на задачах, которое должно решать Trie, писать логику. Это для самого шустрого и оптимального варианта. Для остальных, можно взять текущий: https://github.com/mikelsv/opensource/blob/master/msvcore/list/TrieList.h
Требуется. Библиотека раза четыре писалась заново с добавлением кода из прошлой версии. И пятый уже на подходе. По мере сил, возможностей и понимания.
У меня свои подходы и stl принципиально не используется. А иначе половину библиотеки можно выкинуть, а вторую переделывать по принципам stl. Одним словом похоронить.
Автор все-таки надеялся, что библиотекой начнет пользоваться кто-нибудь еще, кроме него.
Признаться, мне показалось, что тут целый пост о том, что она делает. Уместить описание в одну строчку мне к сожалению не удалось.
Это скорее обзорная статья, обо всем и ни о чем. Сказать, что есть такая библиотека, узнать реакцию и узнать, что в ней может быть интересно другим людям. В следующих постах я планирую рассказывать уже о конкретных модулях.
Строки. Хм. У меня тема кодировок тоже хромает. Когда нужно, использую функции преобразования одного формата в другой. Какой-то общей проблемы или задачи я не вижу. С одной стороны тема интересная, с другой, я пока не понимаю, что в итоге требуется получить.
Про парсер C++, возможно мы понимаем разное под парсером. Моя реализация работает как препроцессор, обрабатывает #if #ifdef #define #endif… и разбирает код на части. Насколько я помню у меня нет анализа типов или чего-то большего. В принципе, можно как-нибудь заняться и дописать анализ типов, классов и всего остального.
Этот класс устарел и в следующей версии библиотеки будет заменен. Новый класс написан и тестируется.
Признаться, не использую ASSERT(). Насколько помню, в Windows он вызывает окно и программа встает. Вместо них использую globalerror() которая выведет сообщение в консоль. При фатальной ошибке программа продолжит работать дальше.
В принципе применима. Использую библиотеку почти во всех своих проектах. Скорее ее сложно использовать по ряду очевидных причин, типа отсутствия документации и сложности понимания.
Да, вопрос с лицензией упустил. Исправлюсь, выберу подходящую. Сейчас о лицензии написано только в https://github.com/mikelsv/opensource/blob/master/msvcore/msvcore.cpp:
Лицензия популяризации автора. :]
Вы не должны изменять имя и другую информацию о разработчике и не присваивать авторство себе.
Не продавать и не брать денег за код из данной библиотеки.
Разрешается модифицировать и дорабатывать.
Код предоставлен как есть и автор не отвечает, даже если вы попытаетесь прострелить себе ногу.
Библиотека не собирается, она подключается в проект в виде кода. Пример минимального проекта приведен в посте. (#define USEMSV_GENERALCPP...)
Все проекты в одном репозитории сделаны для удобства переноски и сборки на других машинах. Часто код пишется на одной машине и отлаживается на другой. Обновлять два репозитория дольше, чем один. Не сильно, но при активной разработке это отнимает время. В планах разнести библиотеку и проекты по разным репозиториям.
Да, документация больной вопрос. Хорошая документация требует достаточных сил, которые обычно тратятся на улучшение библиотеки. Постараюсь пересмотреть приоритеты и начать заниматься документацией.
Стиль кода со временем улучшается. Старый код переписывается. Движемся в нужном направлении.
Не очень понятно про опечатки. Можно примеры?
В какой-то момент код начал писаться и в .cpp и в .h. Компиляторам все равно, с людьми сложнее. Вопрос тоже требует рассмотрения и переработки библиотеки.
При обсуждении способов не вспомнили про технологию fuse, через которую можно добавлять соответствующий заголовок ко всем .cpp.
Мне подсказали статьи про опенсорс и составление документации. Рассчитываю, что они помогут как минимум с документацией, а как максимум со всем остальным.
Возможно я недостаточно работал с шаблонами и для меня их использование запутывает код. Начал больше писать шаблонные классы и ситуация понемногу исправляется.
К сожалению в шаблонах stl я до сих пор ориентируюсь довольно хреново.
Ммм, все зависит от того, что вам нужно. Это достаточно оптимальная, но не самая быстрая реализация. Для ускорения поиска сюда стоит добавить хеш таблицу или lower bound. Так же у меня реализация многоуровнего дерева(одно дерево может содержать другое), сделанная для быстрого поиска по JSON.
Это все нужно обсуждать. И основываясь на понимании логики Boost, которой у меня к сожалению нет, и на задачах, которое должно решать Trie, писать логику. Это для самого шустрого и оптимального варианта. Для остальных, можно взять текущий: https://github.com/mikelsv/opensource/blob/master/msvcore/list/TrieList.h
У меня свои подходы и stl принципиально не используется. А иначе половину библиотеки можно выкинуть, а вторую переделывать по принципам stl. Одним словом похоронить.
Признаться, мне показалось, что тут целый пост о том, что она делает. Уместить описание в одну строчку мне к сожалению не удалось.
Строки. Хм. У меня тема кодировок тоже хромает. Когда нужно, использую функции преобразования одного формата в другой. Какой-то общей проблемы или задачи я не вижу. С одной стороны тема интересная, с другой, я пока не понимаю, что в итоге требуется получить.
Про парсер C++, возможно мы понимаем разное под парсером. Моя реализация работает как препроцессор, обрабатывает #if #ifdef #define #endif… и разбирает код на части. Насколько я помню у меня нет анализа типов или чего-то большего. В принципе, можно как-нибудь заняться и дописать анализ типов, классов и всего остального.
Признаться, не использую ASSERT(). Насколько помню, в Windows он вызывает окно и программа встает. Вместо них использую globalerror() которая выведет сообщение в консоль. При фатальной ошибке программа продолжит работать дальше.
Библиотека не собирается, она подключается в проект в виде кода. Пример минимального проекта приведен в посте. (#define USEMSV_GENERALCPP...)
Все проекты в одном репозитории сделаны для удобства переноски и сборки на других машинах. Часто код пишется на одной машине и отлаживается на другой. Обновлять два репозитория дольше, чем один. Не сильно, но при активной разработке это отнимает время. В планах разнести библиотеку и проекты по разным репозиториям.
Да, документация больной вопрос. Хорошая документация требует достаточных сил, которые обычно тратятся на улучшение библиотеки. Постараюсь пересмотреть приоритеты и начать заниматься документацией.
Стиль кода со временем улучшается. Старый код переписывается. Движемся в нужном направлении.
Не очень понятно про опечатки. Можно примеры?
В какой-то момент код начал писаться и в .cpp и в .h. Компиляторам все равно, с людьми сложнее. Вопрос тоже требует рассмотрения и переработки библиотеки.