Используем быстрое возведение матриц в степень для написания очень быстрого интерпретатора простого языка программирования

Спасибо за статью. Есть вопрос: можно ли реализовать(имеется ввиду через матричные преобразования) битовые операции: NOT, OR, AND (все операнды — переменные)?

В феврале Microsoft запустит Kinect для Windows

Извините, но OpenKinect уже черт знает сколько работает и на линухе, и на макоси, и на винде.

В феврале Microsoft запустит Kinect для Windows

Хреново он работает на близком растоянии: на карте расстояний все что ближе метра вообще измерено не будет, точнее расстояние там будет указано такое же, как в точках бесконечно удаленных от устройства. Кстати с отражающими поверхностями(окна, зеркала) у кинекта та же проблема, ну оно и понятно. Хотя теоретически можно эти контуры тоже распознавать.

В феврале Microsoft запустит Kinect для Windows

Оригинальный стоит чуть больше сотни, а за версию для Windows — 250, хм… Причем оригинальный и так работает под Windows.

Поля класса доступные по имени с setter и getter в C++

А почему вы Q_PROPERTY не используете? Если уж юзаете Qt…

Поля класса доступные по имени с setter и getter в C++

В принципе, если мне удастся запилить что-то вроде рефлексии — сделать действительно красиво как в шарпе будет не сложно.
Подскажите, может я торможу, но нельзя ли сделать конкатизацию при редекларировании дефайна предыдущего значения с новым:
#define MACRO мясо
#define MACRO есть_##MACRO
Надо чтоб получилось «есть_мясо», а генерится «есть_MACRO»

Поля класса доступные по имени с setter и getter в C++

Признаться честно, именно сериализация и рефлексия в Java меня подтолкнули меня написать это.

Поля класса доступные по имени с setter и getter в C++

Про __VA_ARGS__ я конечно знаю и пробовал применить здесь, но ничего хорошего не вышло. А вообще иногда пригождается.

Поля класса доступные по имени с setter и getter в C++

Нуууу… Может и не напишешь. Сходу я придумал что-то похожее только для доступа по имени из ран-тайма. Заведем в базовом классе (а я считаю, что наследование от базового класса это не плохо) виртуальный метод void _fieldsection(), который будем вызывать из конструктора. Заведем макрос #define fieldsection _fieldsection(). Теперь мы в классе можем написать так:

class Foo
{
    fieldsection
    {
        field(int, a)
        {
            get {...}
            set {...}
        }
    }
...
}

здесь field — макрос, который разворачивается в вызов метода добавление поля в класс, а get и set разворачиваются в лямбда функции, которые сохраняются соответственно текущему полю. Не могу только придумать, как сделать обращение через. или ->.

Поля класса доступные по имени с setter и getter в C++

1) Уже взял на заметку и собираюсь с этим бороться
3) Я думал это фича, но судя по комментариям следует дать возможность программисту самостоятельно описывать методы get и set.
2) Не задумывался об этом, но smartfield + пустой сеттер (или который например кидает эксепшн)
На счет развития идеи — тоже взял на заметку, позже разберусь.
И на счет использования нового стандарта — эта идея мне действительно кажется хорошей и может быть получится сделать действительно пригодную для использования реализацию.

Поля класса доступные по имени с setter и getter в C++

Я тоже сначала хотел сделать по образцу C#, но меня смутил тот факт, что в С++, в отличии от шарпа, принято разделять декларирование и реализацию.

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

Поля класса доступные по имени с setter и getter в C++

Думаю, можно было бы сделать синтаксис такой, чтоб smartfield принимал имена геттера и сеттера в качестве аргументов. Опять же если сделать так то если программист забудет написать один из методов то компилятор выведет что-то страшное, а так как сделано сейчас только то, что такой-то метод не реализован.
На счет макросов на самом деле склонен с вами согласиться, но мне кажется здесь они к месту. Можно было обойтись почти без всех макросов начинающих с "__", они все появились в процессе проб и ошибок и пока я придумывал код использовал такие блоки как детали конструктора.