Эмулятор УКНЦ - UKNCBTL

[Patron]

Тогда и незачем особо использовать классы

Конструкторы - это просто песня. Т.к. в C++ все типы данных являются классами - конструктор можно задать для чего угодно. У меня почти все "обычные" структуры имеют конструкторы с пустым телом - просто устанавливающие для членов значения по умолчанию.

Например:

struct Point {
	int X;
	int Y;
	Point():
	X(0),
	Y(0)
	{}
};

В подобной ситуации становится абсолютно невозможно создать экземпляр такой структуры с неинициализированными членами.

Если хочется дополнительно иметь возможноcть явно задавать начальные значения членов при создании структуры - можно сделать так:

struct Point {
	int X;
	int Y;
	Point( int X0 = 0, int Y0 = 0 ):
	X(X0),
	Y(Y0)
	{}
};

и создавать экземпляры, например, так:

Point A;
Point B(1,1);

[Titus]

У меня почти все "обычные" структуры имеют конструкторы с пустым телом - просто устанавливающие для членов значения по умолчанию.

Лично для меня все это лишнее. Мне нагляднее, когда без классов - простые функции и простые данные. Без всяких указаний классов, зон паблик не паблик, конструкторов и т.д.

[Patron]

Мне нагляднее, когда без классов - простые функции и простые данные.

C++ - это и есть практически "чистый ассемблер" в том виде, в котором он должен быть. Использовать все его возможности в полном объёме или не использовать - зависит от потребностей. По мере роста потребностей - растёт и объём используемых возможностей.

Важно лишь с самого начала понимать, что все без исключения возможности С++ - это практически всё тот же "чистый ассемблер" без каких-либо "наворотов".

[Titus]

Важно лишь с самого начала понимать, что все без исключения возможности С++ - это практически всё тот же "чистый ассемблер" без каких-либо "наворотов".

Я так не считаю)
Программировал и на С++ с классами когда-то, и на чистом Си, и для меня просто Си очень дружественный, а ООП - нет.

[Patron]

для меня просто Си очень дружественный, а ООП - нет.

То, что повсюду называют ООП - на мой взгляд - просто вывих мозга. Как можно писать в таком стиле я представить себе не могу. Именно безумный стиль "ООП" многие (как я понимаю) путают с сутью объектного подхода.

На самом деле программа, использующая объекты - это лишь упрощённый вариант программы без объектов.

Вот пример класса LockVarType, создающего объекты быстрой межпоточной синхронизации размером в одно слово:

#define DWORD_ALIGN    __declspec(align(4))
#define LOCK_VAR_TYPE  DWORD_ALIGN LONG volatile

class LockVarType {
public:
	LockVarType():dwLockVar(0){}
	inline dword IsLocked(){ return dwLockVar; }
	inline void  Lock( int nSleepMS = 0 )
	{
		while( InterlockedCompareExchange( &dwLockVar, 1, 0 ) ) { Sleep( nSleepMS ); }
	}
	inline void  UnLock() { dwLockVar = 0; }
	inline bool  TimedLock( dword uTimeOut_MS, int nSleepMS = 0 ) 
	{
		dword  uTC = GetTickCount();
		while( InterlockedCompareExchange( &dwLockVar, 1, 0 ) ) 
		{
			if( GetTickCount() - uTC >= uTimeOut_MS ) { return false; }
			Sleep( nSleepMS );
		}
		return true;
	}
	inline bool TryLock() { return !InterlockedCompareExchange( &dwLockVar, 1, 0 ); }

protected:
	LOCK_VAR_TYPE  dwLockVar;
	
};

Этот объект имеет после компиляции размер в одно слово.
Сделать межпоточную синхронизацию легче и проще вряд ли реально.

[Titus]

Этот объект имеет после компиляции размер в одно слово.
Сделать межпоточную синхронизацию легче и проще вряд ли реально.

Эм... точно одно слово? Я вижу какие-то функции)

[Patron]

Эм... точно одно слово? Я вижу какие-то функции)

Это макросы, которые подставляются в код программы в тех местах, где пользователь хочет как-то использовать объект.

Например, чтобы включить, а потом выключить межпоточную блокировку пользователь пишет:

LockVar.Lock();
................
LockVar.UnLock();

А в код программы вставляется:

while( InterlockedCompareExchange( &dwLockVar, 1, 0 ) ) { Sleep(0); }
................
dwLockVar = 0;

[Titus]

Например, чтобы включить, а потом выключить межпоточную блокировку пользователь пишет:

LockVar.Lock();
................
LockVar.UnLock();

На простом Си я напишу LockVar() или UnlockVar()

[Patron]

На простом Си я напишу LockVar() или UnlockVar()

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

---------- Post added at 16:26 ---------- Previous post was at 16:23 ----------

Вот и получается, что разница между LockVar( &dwLockVar ) и LockVar.Lock() только в том, что при переносе кода из одного проекта в другой - не надо думать, что относится к блокировке, а что нет - всё необходимое уже "упаковано" в описание объекта.

---------- Post added at 16:41 ---------- Previous post was at 16:26 ----------

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

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

А можно в ANSI C задавать переменную цикла прямо в операторе for ?

for( int i = 0 ; i < 100 ; i++ )

[Titus]

А можно в ANSI C задавать переменную цикла прямо в операторе for ?

for( int i = 0 ; i < 100 ; i++ )

Да, это возможность удобная, и сам ее иногда использую. Хотя, стараюсь не злоупотреблять, чтобы не раскидывать обьявления по коду.
Так же в Си++ удобно, что можно писать преобразование типов, скажем, не k = (long)i, а k = long(i). Для наглядности иногда удобней.

Вот и все, чем я пользуюсь из Си++ )