Критика моего кода

[BDA]

ROD, не знаю, по каким причинам отговаривает _Bers, но у нас, например, дефайны запрещены по кодстайлу:

5.2. Для определения констант целых типов не разрешается использовать ни директиву #define, ни квалификатор const. Все целые константы должны определяться с помощью ключевого слова enum и иметь осмысленные имена.



4.2. Перечислимые типы

Определения перечислимых типов оформляются следующим образом:

enum Colours
{
    RED,
    GREEN
};

или следующим образом:

typedef enum Colours
{
    RED,
    GREEN
} Colours;

Допускается использование анонимных перечислений:

enum
{
    READY_BIT = 0x1,
    ERROR_BIT = 0x2
};

Если определяется единственная константа, допускается запись анонимного перечисление в одной строке:

enum { BUFFER_SIZE = 1024 };

[MihalNik]

Если определяется единственная константа, допускается запись анонимного перечисление в одной строке

А вот это уже маразм

Куча дублирующих литералов, куча ветвлений (switch'и не многим лучше if'ов).
Почему в кейсах столько одинакового кода?
Требуется декомпозиция (возможно, выделение небольших функций).
Еще неплохо было бы освоить массивы (в т.ч. массивы строк и функций).
А по какому принципу расставлены endl'ы и \n'ы? Чем они отличаются и что лучше?

[_Bers]

Сообщение от ROD

А, если не секрет, по чему?

Дефайны не дают типо-защиты, и не предохраняют от конфликтов имет.

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

Если мне не требуются переменные типа енума, то я использую безымянные енумы.

[ROD]

Сообщение от MihalNik

А вот это уже маразм
А по какому принципу расставлены endl'ы и \n'ы? Чем они отличаются и что лучше?

endl осуществляет перевод на новую строку так, как это нужно в данной системе.

Т.е. в одном случае endl это "\n", в другом это "\r\n".

[_Bers]

Сообщение от ROD

endl осуществляет перевод на новую строку так, как это нужно в данной системе.

Т.е. в одном случае endl это "\n", в другом это "\r\n".

А я всегда думал, что нет никакой разницы между:

cout<< '\n';

и

cout<< endl;

И что за сигнал, что нужно перевести каретку на новую строку отвечает символ перевода каретки на новую строку: '\n'
А о том, как это правильно сделать в рамках конкретной системы, отвечает реализация стрима этой системы.

[BDA]

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

[ROD]

Пардонте, я перепутал символы местами...
Правильно будет "\n\r" (это, к стати, в Widnows).

[_Bers]

Сообщение от ROD

Пардонте, я перепутал символы местами...
Правильно будет "\n\r" (это, к стати, в Widnows).

Для студийной версии функция имеет вид:

_CRTIMP2_PURE inline basic_ostream<char, char_traits<char> >&
	__CLRCALL_OR_CDECL endl(basic_ostream<char, char_traits<char> >& _Ostr)
	{	// insert newline and flush byte stream
	_Ostr.put('\n');
	_Ostr.flush();
	return (_Ostr);
	}

Из чего я делаю вывод, что единственное различие между endl и '\n' только в том, что endl флюшит стримовский rdbuf:

_Myt& __CLR_OR_THIS_CALL flush()
		{	// flush output stream
		ios_base::iostate _State = ios_base::goodbit;
		if (!ios_base::fail() && _Myios::rdbuf()->pubsync() == -1)
			_State |= ios_base::badbit;	// sync failed
		_Myios::setstate(_State);
		return (*this);
		}

[waleri]

Сообщение от _Bers

Дефайны не дают типо-защиты,

#define NAME (type(value))
Вот вам и типозащита.
enum удобно использовать там, где нужен один аргумент из всех. Если же надо делать битмаску из нескольких, enum мгновенно преващается в int и все теряется. Если нужна такая типозащита, тогда нужно не enum а собственный класс.

[_Bers]

Сообщение от waleri

#define NAME (type(value))
Вот вам и типозащита.
enum удобно использовать там, где нужен один аргумент из всех. Если же надо делать битмаску из нескольких, enum мгновенно преващается в int и все теряется. Если нужна такая типозащита, тогда нужно не enum а собственный класс.

Нефига ничего не понял. Что это за дефайн такой? И как его использовать? И нафига он вообще нужен?

Единственное, что я понял из такого дефайна, это что любое упоминание
NAME у меня заменится на непонятное (type(value)) что приведет к ошибке компиляции.

Кстати, я использую иенно енумы для задания многочисленных флагов состояний:

enum eSTATE
{
   eHIDE  = 1<<0,
   eMOVE  = 1<<1,
   eBLINK = 1<<2,
}
 ....

CFlag flags(eHIDE|eMOVE );
...

if(flags == eHIDE) std::cout<<"объект невидим\n";
if(flags == eMOVE ) std::cout<<"объект двигается\n";
if(flags == eBLINK ) std::cout<<"объект мигает\n";

...

flags.SetFlag(eBLINK ); //поджигаем ещё один флаг
flags.UnSetFlag(eHIDE|eBLINK ); //тушим указанные флаги

...

CFlag упаковывает входящие константы в обычный беззнаковый int
Что позволяет запоминать до 32 возможных комбинаций флагов.

Как бы ничего революционно сложного, зато очень удобно и читабельно получается.
А ещё, енумы гарантированно не потребляют память. И такие константы можно эксплуатировать в шаблоном метапрограммировании