Заголовочные файлы сами по себе не делают ничего вообще.
Они - просто куски кода, которые компилятор вставляет в то место, где в коде указано #include "этотфайл".
Таким образом, проблема в том виде, как она сформулирована, вообще не имеет смысла.
Хороший класс - это тот, у которого известно, что он делает, но неважно, как он это делает.
Именно для этого нужны интерфейс (чтобы к нему обратиться извне) и приватные поля (чтобы логика работы не торчала наружу).
Если вам нужно обращаться к приватным полям класса извне - это не класс, а скомканные процедуры.
Решений, собственно, два - либо заморачиваться с перекодировками самому, втыкая в код ifdef-ы, либо использовать кроссплатформенную библиотеку, где это кто-то сделал за вас.
Компилятор же тычет носом в строчки, где проблема.
А проблема в том, что программист небрежен и не пользуется IDE, которая ткнула бы его носом более предметно - где он забыл фигурную скобку, где кавычки, а где - упомянуть класс, метод которого вызывает. Вот и все три ужасные ошибки.
Ну, все правильно. Вы же хотите возвращать не итератор, а указатель. Вот тип и не совпадает.
Можно вернуть &(*leftElement);, но если вас угораздит обратиться по этому указателю после того, как с сетом что-нибудь произошло (например, добавлен или удален элемент), вас могут ожидать разные нетривиальные, трудно отлавливаемые сюрпризы.
Сделать класс-обертку с конструктором, принимающим как int, так и строку.
Например, хранящий внутри строку и преобразующий ее при необходимости в целое значение.
MFC - устаревшая библиотека, не имеющая никаких преимуществ перед Qt, например, и при этом прибитая гвоздями к виндам. Забудьте уже о ней. Собственно, в геймдеве ей, по-моему, никто и не пользовался.
COM и ATL могут вам понадобиться в геймдеве только тогда, когда вы полезете в потроха движков. А могут не понадобиться и там. Так что заучивать древние (как сама технология) учебники по ним просто так, на всякий случай, просто глупо.
Вижуал Студии нет нигде, кроме Виндов, и лучше бы и там не было.
Для изучения С++ отсутствие Вижуал Студии - несомненное благо.
Правда, доступный на Маке XCode сделан [censored] для [censored], но он хотя бы не навязывает свой собственный надъязык вместо стандарта. И если вы дорастете до публикации своих приложений, яблочная инфраструктура все равно заставит вас им пользоваться.
Ты не в С++ еще очень зеленый, а в информатике в целом.
Упорно долбишься в принципиально неверно поставленную цель.
Единственный способ, которым ты можешь наглядно отобразить бинарную информацию и ничего не потерять - это hexdump (отображение каждого символа его шестнадцатеричным кодом). Собственно, все так и делают еще с прошлого века.
Аналогично, работа с бинарными данными принципиально отличается от работы со строками. Ты получаешь байты и обрабатываешь байты. Если какой-то кусок этих байтов выстраивается в строку в какой-то кодировке - копируешь этот кусок, присваиваешь его строке, и тогда уже можно использовать библиотеки, перекодирующие из одной кодировки в другую. Но пока у тебя файл, в котором навалено разных данных и служебной информации - разбирать его надо именно побайтово.
Какой смысл лепить бинарные данные в строку?
Чтобы получить пятым символом \0 и при выводе по-сишному строка на этом обрывалась?
Чего сделать-то хотел?
Что такое вообще "раскраски по двум цветам"?
Шестиугольник тупо может быть заскрашен черным или белым, нужны все варианты?
Напрашивается цикл с разбором битовой маски числа от 0000000b до 1111111b.
Сохранить проще вектором - SVG, например, чтобы затратить на минимальные усилия на создание картинки, сконвертировать ее потом в нужный формат - не проблема.
Ключевые слова для поиска, которых вы, возможно, не знаете - "static linking".
Инструкции можно найти в FAQ на офсайте самой библиотеки.
Учтите, что для статической линковки вам практически нужно будет заново собрать всю библиотеку, удовлетворив ее зависимости. Это может оказаться довольно сложным делом, так что, как уже сказано, если вам просто хочется распространять все одним файлом - сделайте установщик.
Const имеет смысл использовать всегда, если вы пишете код, который потом будем многократно использоваться (библиотеку, например).
Использование же const в прикладном коде - это оптимизация. Причем, как правило - преждевременная.
То есть испортить код таким образом вы вряд ли сможете, а вот стоит ли результат потраченных усилий и постоянного переключения с уровня архитектуры на этот низкоуровневый... эм... как это по-русски - grinding?