После этого можно подняться от «отключенного» узла к корню, попутно удаляя все узлы которые являются листьями, однако экономия памяти в данном случае не существенна, а для эффективного определения того, является ли узел листом потребуется вводить дополнительную характеристику узла.
Думается, можно не вводить дополнительную характеристику, а просто удалять при подъёме пустые узлы до первого непустого.
Получается, что нельзя, к примеру, определить для человека и камина общий базовый класс «Штука с температурой», который позволяет просто хранить и менять температуру, т.к. у него совсем нет никакого предусловия на изменение температуры…
И ещё. Если попробовать сделать наоборот, «Камин» подтипом «Человека», то в принципе можно использовать камины вместо людей, т.к. предусловие у каминов слабее. Но не должен ли тогда камин соблюдать предусловия человека? Если он IS-A человек, то его нельзя нагревать выше 45.
main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
Юзаю CppUnit. Библиотека не громоздкая. Для запуска тестов не требуется препроцессинга, только простая сборка бинарника-тестера.
Для него в Eclipse есть плагин ECUT, который визуализирует результаты тестирования. В сочетании с ним в Эклипсе всё выглядит точь-в-точь как JUnit для Java.
Спасибо ;) Я в свое время остановился на Jena, т.к. нужно было срочно, а она первая попалась под руку. Вот теперь интересно, может не надо было спешить.
Кроме того, помню были у меня проблемы с подгрузкой доп. правил вывода в Jena. Т.е. очень долго строилась модель, если ризонеру подсунуть пару доп. правил. Не помню сейчас подробностей, позже уточню. Все это к тому, что интересно также, как с этим обстоит у других фреймворков.
API рассматриваемых фреймворков. Можно, например, реализовать программно приведённые Вами запросы. Ну или что-нибудь попроще, вроде listIndividuals() или getPropertyValue() с транзитивным выводом (не знаю, как это делается в OWL API, привел примеры в терминах Jena).
Не очень показательным получился тест SPARQL-запросов. Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
1. Зачем преобразование к Container*?
2. Согласен насчёт нарушения гарантий, но что же делать, если библиотека не даёт гарантий там, где должна бы? Конечно, не однозначный вопрос, что должна библиотека, а что нет. Однако, const-корректность библиотеки делает её более удобной. Короче говоря, лучше уж аккуратно сделать const_cast в одном изолированном месте, чем отказываться от ключевого слова const вообще.
Не даст вызвать не-const Container::count() из Container::count() const.
Есть вот такой вариант:
// Библиотека
class Container
{
public:
unsigned count (); // не const
};
// MyModule.cpp
class MyContainer : public Container
{
public:
void process () const
{
for (unsigned i = 0;
i < (const_cast<MyContainer*>(this))->count (); // Приводим this к не-const типу
++i)
{...}
}
};
Возможно, -Xmn на рисунке — это опечатка, и должно значиться -Xms?
Думается, можно не вводить дополнительную характеристику, а просто удалять при подъёме пустые узлы до первого непустого.
И ещё. Если попробовать сделать наоборот, «Камин» подтипом «Человека», то в принципе можно использовать камины вместо людей, т.к. предусловие у каминов слабее. Но не должен ли тогда камин соблюдать предусловия человека? Если он IS-A человек, то его нельзя нагревать выше 45.
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
Для него в Eclipse есть плагин ECUT, который визуализирует результаты тестирования. В сочетании с ним в Эклипсе всё выглядит точь-в-точь как JUnit для Java.
Кроме того, помню были у меня проблемы с подгрузкой доп. правил вывода в Jena. Т.е. очень долго строилась модель, если ризонеру подсунуть пару доп. правил. Не помню сейчас подробностей, позже уточню. Все это к тому, что интересно также, как с этим обстоит у других фреймворков.
поскольку преобразование типа к базовому классу не отменяет полиморфизма.
2. Согласен насчёт нарушения гарантий, но что же делать, если библиотека не даёт гарантий там, где должна бы? Конечно, не однозначный вопрос, что должна библиотека, а что нет. Однако, const-корректность библиотеки делает её более удобной. Короче говоря, лучше уж аккуратно сделать const_cast в одном изолированном месте, чем отказываться от ключевого слова const вообще.
Есть вот такой вариант:
// Библиотека class Container { public: unsigned count (); // не const }; // MyModule.cpp class MyContainer : public Container { public: void process () const { for (unsigned i = 0; i < (const_cast<MyContainer*>(this))->count (); // Приводим this к не-const типу ++i) {...} } };