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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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