Я как-то никогда не задумывался над тем, что лучше использовать BOOL или BOOLEAN? Конечно же, BOOL — это и короче и во всех учебниках по Windows встречается именно BOOL. Как бы не так! Буквально вчера я битый час занимался поиском ошибки там, где ее не должно было быть.

Оказалось, что единственно истинный тип, впрямую связанный с типом bool, который определен стандартами языка С++, это именно BOOLEAN. А BOOL это не что иное, как «typedef int BOOL;» и находится в windows.h (точнее в WinDef.h, но это неважно)

Рассмотрим подробнее исходный код функции, сравнивающий два числа:

#include <stdio.h>
#include <windows.h>

bool CompareInt(int i1, int i2)
{
    if (i1==i2)
        return true; //UPD1: было TRUE
    else
        return false; //UPD1: было FALSE
}

typedef BOOL (*CallBack)(int, int);

void main(void)
{
    CallBack IsEqual = (CallBack)CompareInt;

    if ( !IsEqual(0x1234, 0x5678) )
        printf("Not equals");
    else
        printf("Equals");
}

После компилирования Visual Studio и запуска, имеем: Equals

Тогда поменяем BOOL на BOOLEAN:

typedef BOOLEAN (*CallBack)(int, int);

Компилируем, запускаем, получаем: Not equals (что и должно было получиться с самого начала)

Вывод: никогда не пользуйтесь BOOL, только BOOLEAN.

Решил я, студент, подрабатывающий фрилансером (в основном с РНР и HTML), немного расширить свои знания. Новым пространством для опытов для меня оказался С++. Ранее я ни разу не писал на компилируемых языках, и мысль о том, что понимание того, как это дело работает когда-нибудь мне все таки сгодится, не покидала мою голову. Так же мне не очень хотелось, чтобы первая моя «настоящая программа» была банальным текстом «Привет, мир!» в консоль. В то время я увлекся покером, играл с друзьями, в соцсетях. Что получилось в итоге — смотрите под катом.

После прочтения статьи «Простейший делегат на C++», я понял лишь то, что не понял я абсолютно ничего – наглухо. Может это потому что автор апеллировал в своих мыслях к понятию делегатов в языке C#, который я знаю чуть менее чем никак. Зато я знаю objective C, в котором, делигерование встречается достаточно часто и подход к делигированию там вполне не плохо переностся на C++, а раз у людей на нем пишущих есть потребность в делегатах, то может такой подход им понравится больше. Сразу оговорка – так как в objective C связывание объекта с методом происходит полностью runtime, зделать все так же на плюсах не выйдет, но тут великий Страуструп оставил нам крохотную щель — таблицу виртуальных функций, вот через нее и просочимся.

Для начала потребно разъяснить каков подход к делегированию в objective C.

Итак, по правилам хорошего тона у нас должен быть интерфейс (@interface – некий аналог класса в плюсах, далее назовем его тоже классом), и протокол с объявлением методов-делегатов (@protocol), класс которому нужно установить делегаты должен иметь наследование от этого протокола (говоря языком «кокошников» поддерживать протокол), а класс который вызывает делегаты иметь указатель на класс с методами делегатами и реализованной поддержкой протокола (правда, из-за динамического связывания наследование вовсе не обязательно – просто копипастим имена методов протокола нужному классу, определяем что им делать – компилятор покажет warning, но все работает, а вот на C++ такое неполучится, тут нужно все выше писанное соблюдать ревностно).

В этой небольшой заметке пойдет речь о том, как легко и просто можно убить производительность приложения с помощью библиотеки STL. Охватить всю библиотеку в рамках этого топика не возможно, поэтому будет рассмотрен только один компонент – контейнер std::string. В качестве примера будет показана цена инициализации std::string и, как следствие, продемонстрировано, к чему может привести неоптимальное использование библиотеки. Все нижесказанное особенно остро относится к области gamedev-а.

Для кого эта статья

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

Одной из главных проблем человека, желающего начать изучать языки программирования C/C++, при этом ничего практически о них не зная, может являться отсутствие начальной точки опоры. Эта статья призвана помочь новичкам сделать первые шаги на захватывающем пути освоения этого семейства языков.

Итак, прежде чем ринуться в глубинные просторы интернета в поисках уроков по программированию на C, необходимо подготовить себе хорошую почву — среду программирования. На данный момент существует немалое количество программ, позволяющих писать программы на рассматриваемом языке, осуществлять проверку синтаксиса и компилировать (переводить) исходный код программы в исполняемый файл (с расширением *.exe). Среди них хочется отметить прежде всего Borland C, Borland C++, Dev-C++, Visual Studio, Eclipse, NetBeans, IDEA. Особенно хочется рассмотреть здесь довольно старую, но и по сей день пользующуюся популярностью среду Borland C++ (на примере версии 5.5.1) ввиду наличия некоторых сложностей в ее настройке (однако, лучше конечно же пользоваться более современной и более автоматизированной средой).

Решил написать программу, которая решает задачу о разрешимости хода шахматным конём.

Вход:
— Строка вида "CD-CD", где C — это символ из диапазона [A,H], D — это цифра из диапазона [1,8]. По сути — шахматная клетка, с которой ходят, и клетка, на которую хотят пойти. Дефис тоже обязателен.

Выход:
— Если строка ввода введена не верно — выдать сообщение об ошибке.
— Если строка ввода введена верно, то проверить, является ли данная запись обозначением хода шахматного коня.

"ABC", "Q3-TT" — примеры неправильных данных ввода.
"A1-B3", "A4-H5" — примеры правильных данных ввода.

Ход коня, как известно — это ход на две клетки в одну сторону и на одну клетку вбок. Соответсвенно, "A1-B3" будет являться ходом коня, а "A4-H5" не будет.

Исходный код программы приведён в конце. Язык исполнения — Си.
Решение не столь очевидно, поэтому напишу пояснение.

Вечер добрый
В последние дни оживился блог С++ и появилась масса новых тем и споров по поводу места С++ в нашей жизни, о его будущем и прошлом. Хочу и я кое что сказать по этому поводу. Пишу я в основном на С под всякие железки типа PIC18 от Микрочипа, но и с С++ тоже знаком. И считаю, что рассматривать С++ в отрыве от возможностей С никак нельзя, хотя-бы потому, что все же он проектировался как наследник С.
В связи с этим хотелось бы задать вопрос всем тем, кто говорит о том что С++ умрет и что аналогичные задачи можно с лёгкостью решать на Python/Java/Haskel итд. Покажите как на вашем любимом языке программирования можно получить старший байт 32х разрядного(к примеру) числа за один такт процессора.
Моё решение на С/C++:
int number;
char mByte=*(((char*)&number)+3);

гарантированно компилируется в однотактную инструкцию практически на любом процессоре «а что у Вас»? Добро пожаловать в комментарии.

Рассказывая про 64-битные ошибки, поджидающие программистов при миграции их программ, я часто слышу упреки: «Ну да, этот ваш Windows, он такой… Хорошо, что в Linux с 64-битным кодом проблем да-а-а-авно уже нет».

«А вот и нет, мой любознательный читатель».

Сегодняшний пост про 64-битную ошибку в ядре Linux.