Толстый Лорри

1) C++ - не Си, складывать "биты в байтах" здесь нужно не так часто (без необходимости). Тем более с Qt. Мнений тут достаточно много, порог вхождения здесь все так же высок. Но боязнь самообучения противоестественна для того, кто решил связать жизнь с программированием.

2) JavaSE API во многом доступна в Android, но там еще целый фреймворк по поддержке Android Java API. Изучать Android придется обязательно.
Практически любой язык сам по себе бесполезен без какого-то прикладного API, будь то классы Java SE/EE API, FCL в .Net Framework или Qt/GTK/wxWidgets/MFC в C++ и другие.

Мы имеем сырой поток байт, с помощью спецификаций и описанных структур мы можем определить откуда (с каким смещением и сколько по размеру) и каким образом вытаскивать данные.
Например, BMP-файл состоит из заголовка файла, длинной 14 байт (тип BITMAPFILEHEADER), в нем описан размер файла, его тип (сигнатура) и т.п..

typedef struct tagBITMAPFILEHEADER {
  WORD bfType; 
  DWORD bfSize; 
  WORD bfReserved1; 
  WORD bfReserved2; 
  DWORD bfOffBits; 
} BITMAPFILEHEADER;

за ним заголовок самого изображения BITMAPINFO, содержащий BITMAPINFOHEADER, который уже непосредственно хранит параметры картинки (ширину-высоту, цветовую глубину, признаки сжатия и т.п.)

typedef struct tagBITMAPINFO {
  BITMAPINFOHEADER bmiHeader; // тип описан далее
  RGBQUAD          bmiColors[1];
} BITMAPINFO, *PBITMAPINFO;

typedef struct tagBITMAPINFOHEADER {
  DWORD biSize;
  LONG  biWidth;
  LONG  biHeight;
  WORD  biPlanes;
  WORD  biBitCount;
  DWORD biCompression;
  DWORD biSizeImage;
  LONG  biXPelsPerMeter;
  LONG  biYPelsPerMeter;
  DWORD biClrUsed;
  DWORD biClrImportant;
} BITMAPINFOHEADER, *PBITMAPINFOHEADER;

А, собственно, данные изображения находятся начиная с BITMAPFILEHEADER.bfOffBits, чередуясь по каналам цвета, выравниваясь по границам памяти и т.п. Например, это описано на вики.

Для начала обрати внимание, что BMP-изображения хранятся построчно снизу-вверх (но все-таки слева-направо). Там есть 4х байтное выравнивание. Какая битность у входящего изображения? Есть ли альфа-канал?

Удобнее всего работать с 4х-канальным изображением (RGBA), где на каждый канал - 1 байт. Таким образом выравнивание нас не заботит, можно читать вот такие структуры одна за одной:

struct BmpPixel
{
   unsigned char Blue;
   unsigned char Green;
   unsigned char Red;
   unsigned char Alpha;
};

В bmp-файле идет сначала заголовок файла, затем, заголовок изображения, потом буфер с данными. В первом узнаешь размер всего файла для чтения, во втором - характеристики изображения (как именно читать, сколько каналов, длинна строки и их количество). Это есть на MSDN.

Об остальном уже сказали. От себя могу посоветовать не преводить в грейкейл, а тупо складывать значение каналов (с альфой тоже можно подумать, например, умножить на три и вычесть из суммы каналов).

Как-то так, наверное:

unsigned long long sum = 0;

std::ifstream file( "filePath",  std::ios::binary );

if ( file.is_open() )
{
   char byte;
   while ( file.good() )
   {
      file.read(&byte, sizeof(char) );
      sum += byte;
   }
   file.close();
}

Константа - это сам литерал (с суффиксом). А переменной ты присваиваешь (в данном случае - копируешь) значение константы. Это похоже на такую ситуацию:

const int c = 35;
int var = c;

В var находится значение, скопированное из константы. Но мы же можем менять var?

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

Нет разницы. То же, что и с "абстрактными методами" и "чисто виртуальными функциями-членами". Можно спорить о том, что есть свои кошерные названия, но это больше дань традициям. Проще же в общении с коллегами оперировать общеупотребимыми терминами. Конечно, это только в случае отсутствия каких-либо специфических особенностей!

Вас сейчас могут интересовать лишь два стандарта языка: распространенный С++03 и современный С++11(он же С++x0).
Помимо книжки, необходимо правильно выбрать компилятор, ибо они не все поддерживают стандарты (причем, все по-разному). Поддержку того старого безобразия с обязательными заголовочными файлами с ".h" и без пространств имен (namespaces) обеспечивает олдскульная Microsoft Visual Studio 6. Последующие версии студии - это уже С++03, возможно, с добавками С++11. Лучше всего дело обстоит у свободного компилятора GNU GCC. Информацию можно найти в интернете, например, по повожду С++11:
wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

Книги лучше искать по-новее. Не категорически последние, но все же. Из особо явных различий - это необходимость замены заголовочных файлов из библиотеки С++ на эквиваленты на "без .h" ( iostream.h -> iostream ), а из С-шной библиотеки - также убрать .h, но в начале поставить "с" ( math.h - > cmath ) и обращение к функциям и типам С++-ной стандартной библиотеки через пространство имен std::тип_или_имя_функции. В основах же особых изменений не было.

Проблему решил жестким принудительным инклудом resource.h в заголовочный файл диалога ( Project_nameDlg.h ). Т.к. там константы-дефайны, то коллизии не будет (переопределяться), но я буду уверен, что не словлю

undeclared identifier IDD_PROJECT_NAME_DIALOG

Еще нашел:
stackoverflow.com/questions/20651931/how-to-access...

stackoverflow.com/questions/15453629/use-visual-st...