Citat:
Tvoj primer nije upotrebljiv u njegovom slucaju jer covek koristi BCB, a uz BCB ne dolazi MFC pa samim time ni CCriticalSection.
Jednostavno zameni CCriticalSection sa CRITICAL_SECTION strukturom
a Lock i Unlock zameni EnterCriticalSection i LeaveCriticalSection api pozivima ...
a to sve moze da wrapuje u jednu malu klasu ..
Code:
class CSync
{
public:
CSync() { InitializeCriticalSection(&m_CriticalSection); }
~CSync() { DeleteCriticalSection(&m_CriticalSection); }
void Acquire() { EnterCriticalSection(&m_CriticalSection); }
void Release() { LeaveCriticalSection(&m_CriticalSection); }
private:
CRITICAL_SECTION m_CriticalSection;
};
class CLock
{
public:
CLock(CSync &refSync) : m_refSync(refSync) { }
~CLock() {}
void Lock() { m_refSync.Acquire(); }
void Unlock() { m_refSync.Release(); }
private:
CSync &m_refSync;
CLock(const CLock& refcSource);
CLock&operator=(const CLock& refcSource);
};
Ne vidim sto ne bi ovo radilo po Borlandom ..
Citat:
S druge strane ne mislim da ce mu trebati thread safe singleton jer ako se radi o standardnoj GUI aplikaciji sa verovatnocom od 90% mozemo da pretpostavimo da nece biti vise threadova, zato sam namerno poslao ovaj barebone primer.
Naravno ..ne mislim da mu sad treba zbog tredova ..vec sam samo bacio akcenat
na template jer je u principu "uiniverzalan" za svaki tip ...
Ovako treba da ponovo pise singleton za svaku klasu posebno, ako bude imao potrebu ...
Pozdrav!!
Viva lollapalooza