IPC: сокеты против именованных каналов

Понимаю, что некропост, но мне очень интересно.

Я вообще то думал, что Вы вспомните libaio — и уже собирался понасмехаться, но не судьба :-)

А можно не насмехаться, а нормально рассказать в чем проявляются его недостатки и почему такое критическое мнение насчет этого?
Спрашиваю совершенно серьезно.

Тестируем VoCore в хакспейсе — микро-компьютер с WiFi на Linux/OpenWrt

А зачем вам миниатюрность и низкое энергопотребление для теплицы и соленоидных вентилей? Там же и места должно быть полно и электричество будет. Всяко соленоиды будут жрать больше центральной микросхемы

Ну там далеко не теплица — обычный участок.
Электричество есть, но может и пропасть (такое бывает). Если не будет электричества не будет и воды (смысл держать вентили автономными отпадает), так что питать автономно надо только сам компьютер — для того, чтобы сообщить о перебоях в питании (тоже по СМС). Тогда нужно будет придти и полить вручную.
Насчет миниатюрности, все просто: мелкое проще спрятать. Не нужно будет искать большой погодозащищенный корпус, а потом думать куда его деть, чтобы никто не спер. Вообще конечно миниатюрность не главный критерий, но она была бы плюсом.

В-главных, слишком мелкая, даже дырочки «половинного» шага, надо будет паять проводочки.

Это не проблема. Во-первых у меня есть штырьковые разъемы для такого шага. Во-вторых ничего страшного, если придется паять.

Во-вторых, не видно 1-wire, I2C и прочих протоколов, не понятно есть ли аналоговые входы (входы с АЦП). Термометры на 1-wire очень популярны.

Это все не нужно. Нужно только замыкать и размыкать цепь. GPIO с этим справится вполне. Единственное что нужно будет дополнительно — это датчик напора воды.

Тестируем VoCore в хакспейсе — микро-компьютер с WiFi на Linux/OpenWrt

Давно вынашиваю идею сделать автоматизированную систему полива в оранжерее и на дачном участке, с удаленным управлением по СМС и собственным автоматическим расписанием (которое можно было бы редактировать через веб-интерфейс). Учитывая малые размеры, достаточную производительность, наличие GPIO (для управления соленоидными вентилями) и похоже достаточно низкое энергопотребление, данный девайс как раз подошел бы в качестве мозга всей системы. Вообще именно отсутствие приемлемого вычислителя для этой задачи и останавливало. А тут, стало быть, такой хороший, на мой взгляд, вариант.

Логирование сообщений с Easylogging++

только один раз при первом вхождении

Он говорил про разные translation unit, а не про множественные включения в один.

Сравнение Rust и С++ на примерах

Visual Studio не поддерживает

Поправлюсь, не поддерживала до версии 2012, насколько я могу судить. Однако все еще работает не корректно в некоторых случаях.

Например в таком

template<typename T>
struct Base
{
    template<typename U>
    struct InnerBase
    {};
};
template<typename T, typename U>
struct Derived : public Base<T>
{
    struct InnerDerived : public Base<T>::template InnerBase<U>
    {};
};

int main()
{
    Derived<int, int>::InnerDerived foo;
}

Сорри за оффтоп :)

Сравнение Rust и С++ на примерах

Я не спорю с тем, что диагностика в С++ может проигрывать другим языкам. Однако это

всё, что связано с аргументами шаблона, проверяется только на второй фазе

не совсем так. Скажем, частично проверка аргументов производится при специализации, и в некоторых других случаях.

template <typename T1, typename T2>
struct A
{
};
template <typename T1>
struct A<T1, 2>
{
};

Ну да ладно, собственно это не важно. Rust хороший язык, надеюсь найдется время познакомиться с ним поближе.

Сравнение Rust и С++ на примерах

Шаблоны в Rust проверяются на корректность до их инстанцирования...

В С++ тоже. Это называется two-phase name lookup. Не смотря на то, что Visual Studio не поддерживает его, он все еще остается требованием стандарта.
womble.decadent.org.uk/c++/template-faq.html#two-phase

Динамическое программирование в шаблонах

Я имел ввиду вынесение 1 << ((x << 2) + y)) за скобки.

Динамическое программирование в шаблонах

Можно было бы убрать повторяющиеся вычисления и сделать код немного короче.

История в картах

Не доказали.

Интервью с Бьерном Страуструпом о языке C++

Я бы сказал, что программисту на любом языке полезно изучать другие технологии, в том числе те, которые применяются в других областях индустрии. Это выводит уровень решения задач на принципиально новый.

Интервью с Бьерном Страуструпом о языке C++

Знаете как это все выглядит?

— Совковая лопата говно, я весь участок штыковой перекопал, очень удобно! 5 лет до этого копал совковой, ну и извращенцы же ее придумали!

Заканчивайте с этим, короче. Эмоции в инженерии — лишнее дело.

Два парадокса в программах на языке C

Минусуют за то, что не различаете компилятор и IDE.
И это, в CodeBlocks используется GCC. А значит сам редактор тут не при чем.
PS. я минусов не ставил.

Qt: шаблон для корректной работы с потоками

1) Это да. Передача через event`ы эту проблему решает.
2) Я не считаю это проблемой, все равно интерфейс, определенный в MyThread будет привязан к конкретной задаче. Класс на практике называться будет соответственно этой задаче (а не MyThread). С другой стороны этот способ точно так же довольно просто поддаётся шаблонизации. Поэтому, если уже очень хочется, можно придумать нечто обобщённое на этой базе.

К слову сказать с более ранних версиях Qt event based межпоточное взаимодействие было основным способом. Т.к. во-первых поток не имел своей встроенной очереди сообщений, как в Qt4-Qt5, а во-вторых система сигналов не поддерживала межпоточные соединения. Приходилось делать свою очередь сообщений внутри run и проектировать систему событий для потока. Зато можно было передавать в основной поток события с помощью функции postEvent (собственно сейчас так тоже можно).

Qt: шаблон для корректной работы с потоками

В журнале DrDobbs помню статью (к сожалению ссылку найти не могу), в которой показывались приемы работы с многопоточностью в Qt.
Одна из концепций такова (демонстрационный пример):

class MyThreadImpl
    : public QObject
{
    Q_OBJECT
public:
    MyThreadImpl();

public slots:
    void doStuff()
    {
        // impl...
        emit onSomeStuff();
        // impl
    }

signals:
    void onSomeStuff();
};

class MyThread
    : public QThread
{
    Q_OBJECT
public:
    void doStuff()
    {
        emit doStuffImpl();
    }

signals:
// external
    void onSomeStuff();

// internal
    void onStuffImpl();

private:

    void run()
    {
        MyThreadImpl threadImpl;

        // signal to thread
        connect(this, SIGNAL(onStuffImpl()), &threadImpl, SLOT(doStuff()));

        // signal from thread 
        connect(&threadImpl, SIGNAL(onSomeStuff()), this, SIGNAL(onSomeStuff()));

        exec();
    }
};

Со своей стороны нахожу данный подход одним из самых удачных для Qt и всем его рекомендую. Функции типа moveToThread считаю костылями, призванными исправлять существующие архитектурные косяки в проекте. Использовать их для новых решений ИМХО не стоит.
Аналогичный, более классический пример с использованием QEvent, который несколько более многословен, однако дает лучшую производительность.

Что быстрее while (true) или for (;;)?

while и for помимо своей цикличности вносят еще и область видимости. Это особенно важно для С++. Поэтому если и использовать goto, то с фигурными скобками:

int main ()
{
    loop:
    {
        printf("1\n");
    }
    goto loop;
}

Получается даже немного длинее. Нет, все-таки в этом случае право большинство: for и while — лучше.

Электровелосипед своими руками

Хрень говорил. Геморрой — суть болезнь от плохого кровообращения. То есть сидишь ты весь день на заднице, застой крови образуется — как следствие — геморрой. У велосипедистов такого быть не может — ибо мышцы ягодичные всегда в тонусе. Да и массаж от седла неплохой.

Обратные вызовы и исключения С++

Даже если я это сделаю — она (си-библиотека) же не написана с учетом exception-safety.

Обратные вызовы и исключения С++

Как раз таки не через Си-код. А в обход его. Задача во-первых не допустить попадания в Си-код исключений и нарушения контракта. Во-вторых оставить для пользователя библиотеки возможность их генерировать (в моем случае неизбежно, потому что код уже написан).

Смысл «протаскивания» в том, что обработка исключения должна быть в том месте, где это нужно. Если переносить всю обработку в код враппера — это будет прямое нарушение инкапсуляции. Враппер просто не может знать об особенностях клиентского кода.

Обратные вызовы и исключения С++

Так он это и делает вообще-то. Вы статью читали?