Blackened
0
Делал ассемблер для простенького PIC-микроконтроллера. lex-ы, yacc-и не использовал. Очень помогла быстро сориентироваться в задаче вот эта книга.
Blackened
0
Размер задается параметрами -Xms и -Xmx.

Возможно, -Xmn на рисунке — это опечатка, и должно значиться -Xms?
Blackened
0
Да, согласен.
Blackened
0
После этого можно подняться от «отключенного» узла к корню, попутно удаляя все узлы которые являются листьями, однако экономия памяти в данном случае не существенна, а для эффективного определения того, является ли узел листом потребуется вводить дополнительную характеристику узла.

Думается, можно не вводить дополнительную характеристику, а просто удалять при подъёме пустые узлы до первого непустого.
Blackened
0
Извиняюсь, дубль…
Blackened
0
main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.

Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
Blackened
0
main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.

Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
Blackened
+2
Юзаю CppUnit. Библиотека не громоздкая. Для запуска тестов не требуется препроцессинга, только простая сборка бинарника-тестера.

Для него в Eclipse есть плагин ECUT, который визуализирует результаты тестирования. В сочетании с ним в Эклипсе всё выглядит точь-в-точь как JUnit для Java.
Blackened
0
Почему же не в блог «Lisp»?
Blackened
0
Спасибо ;) Я в свое время остановился на Jena, т.к. нужно было срочно, а она первая попалась под руку. Вот теперь интересно, может не надо было спешить.

Кроме того, помню были у меня проблемы с подгрузкой доп. правил вывода в Jena. Т.е. очень долго строилась модель, если ризонеру подсунуть пару доп. правил. Не помню сейчас подробностей, позже уточню. Все это к тому, что интересно также, как с этим обстоит у других фреймворков.
Blackened
0
API рассматриваемых фреймворков. Можно, например, реализовать программно приведённые Вами запросы. Ну или что-нибудь попроще, вроде listIndividuals() или getPropertyValue() с транзитивным выводом (не знаю, как это делается в OWL API, привел примеры в терминах Jena).
Blackened
0
Не очень показательным получился тест SPARQL-запросов. Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
Blackened
0
Это инициализация этих переменных единицами. То же самое, что и const int i = 1; int const j = 1;
Blackened
+2
1. В таком случае нужно сделать так:
const_cast<MyContainer*>(this))->Container::count ()

поскольку преобразование типа к базовому классу не отменяет полиморфизма.
Blackened
+2
1. Зачем преобразование к Container*?
2. Согласен насчёт нарушения гарантий, но что же делать, если библиотека не даёт гарантий там, где должна бы? Конечно, не однозначный вопрос, что должна библиотека, а что нет. Однако, const-корректность библиотеки делает её более удобной. Короче говоря, лучше уж аккуратно сделать const_cast в одном изолированном месте, чем отказываться от ключевого слова const вообще.
Blackened
0
Не даст вызвать не-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)  
        {...} 
    }   
};

Blackened
0
Действительно, сам не додумался :) Спасибо!
Blackened
0
Что же делать, если хочется последовательно, а библиотека вот не даёт?
Blackened
+2
Очень напрягает, когда в библиотеках по сути const-методы таковыми не объявлены. Мешает реализовывать собственную const-логику. Например:

// Библиотека
class Container
{
public:
    unsigned count (); // не const
};

// MyModule.cpp
class MyContainer : public Container
{
public:
    void process () const 
    { 
        for (unsigned i = 0; i < count (); ++i)  // Нельзя использовать не-const count()
        {...} 
    }   
};


А если объявить MyContainer::process() как не-const, то его уж нельзя будет использовать в других const-методах. И никак этот не-const count() не завернёшь в const-метод. Конечно, можно попытаться реализовать собственный метод вроде myCount() и объявить его как const, но это, конечно, не всегда возможно.

Blackened
+1
Герб Саттер, Андрей Александреску. Стандарты программирования на С++. Глава 48: «В конструкторах предпочитайте инициализацию присваиванию»:

В конструкторах использование инициализации вместо присваивания… предохраняет от ненужной работы времени выполнения ...


А инициализация переменных-членов — совсем не редкость. Кроме того:

Эта методика не является преждевременной оптимизацией; это — избежание преждевременной пессимизации


Blackened
+3
Нужен блог «Я пинарюсь» :)
Blackened
+1
Тут еще есть момент оптимизации. Если инициализировать объект в теле конструктора, то будет происходить изменение уже созданного и инициализированного (возможно, по умолчанию) объекта. Т.е. в некоторых случаях возможна даже двойная нагрузка при создании одного объекта. А конструкция типа A(int x): vectorSize(x+1), vector(vectorSize) {} инициализирует vector сразу при выделении под него память.
Blackened
0
Да вроде и не было сказано, что читающие стандарты попадают в 95% и что 95% — мудаки.
Blackened
0
>Если же имеем обрывы связи, файлы с оибками и т.п — то надо заранее это все обрабатывать и куда-то делать эти предпроверки… Эхх если бы среда програмирования сама прятала бы эти проверки

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

> Были бы они в Debug mode в виде assert-ов, но показывались только по желанию.

assert-ы к внешнему миру не применимы, т.к. они помогают удостовериться, что всё идёт так, как предполагает разработчик, а предположения относительно внешнего мира делать трудно.
Blackened
0
Переносим, но только вместе со своими контрактами
Blackened
0
Тем, что нужно исключение(я) ловить и обрабатывать. DBC говорит о том, что если перед вызовом ситуация удовлетворяет предусловию функции, то она выполнится без ошибок и ничего обрабатывать не придётся. И перед вызовом проверять ничего не нужно, т.к. убедиться в выполнении предусловия можно исходя из постусловий и инвариантов предшествующих вызовов. Проверять нужно только внешние данные, от которых нельзя ждать выполнения каких-либо контрактов.
Blackened
0
Именно. Получается, что контракты методов setWidth и setHeight в интерфейсе ИзменяемаяФигура подразумевают только факт (возможного) изменения размера. А Квадрат и Прямоугольник, реализуя эти методы, добавляют к их контрактам собственные дополнительные условия. Аналогия с введением при наследовании собственных полей классов.
Blackened
0
Когда говорят, что квадрат является прямоугольником в математическом смысле, то не предполагается изменения размеров фигур. Поэтому противоречия нет, т.к. setWidth не включается в математический интерфейс. Квадрат является прямоугольником потому, что у него 4 стороны и 4 прямых угла. Класс Квадрат должен унаследовать именно эти инварианты (тут можно как раз избежать дублирования кода).

Теперь положим, что нам все же нужен метод setWidth у Прямоугольника. Введение возможности изменения размера прямоугольника приводит к появлению у него специфического контракта, который не должен переходить Квадрату, имеющему свой контракт изменения размеров. Получается, что эти фигуры имеют как общие, так и различные черты, а это означает, что они должны наследовать от общего абстрактного класса фигуры с 4-мя сторонами и 4-мя прямыми углами, а методы setWidth получать, например, от интерфейса ИзменяемаяФигура и реализовывать независимо.