2010-10-26 12 views
6

Obecnie chcę utworzyć otwieracz klasę akcesorium w środowisku wielowątkowym. Cel klasy jest prosty - Złap zamek na jego konstrukcji i zwolnij blokadę jego zniszczenia. Poza tym jest identyczny z normalnym wskaźnikiem. Co więcej, chcę uniemożliwić jego utworzenie na obszarze sterty, aby upewnić się, że blokada zostanie ostatecznie zwolniona.Czy w języku C++ możliwa jest tylko zmienna stosu?

Odwrotność jest dość łatwa (prywatny konstruktor z metodą fabryczną), ale nie wiem, że możliwa jest tylko zmienna stosowa. Czy jest jakiś sposób?

+2

Myślę, że takie rzeczy jak te są niepotrzebne. Każdy przyzwoity programista powinien wiedzieć, czy użyć nowego/usunąć na własne ryzyko. Jeśli programista chce tego obiektu na stercie i wyrzuci punkt istnienia klasy, pozwól im. –

+0

To, o co prosisz, jest niemożliwe i niepotrzebne. Jeśli niekompetentny programista użyje twojego kodu, to i tak zdoła złamać własną aplikację *. A jeśli są kompetentne, przydzielą ci obiekt blokady w taki sposób, jak ma to na celu: w kontekście o zasięgu. – jalf

+5

"Chrońmy się przed Murphy, a nie Machiavelli" - Herb Sutter – MSalters

Odpowiedz

12

Cóż, co z tobą przeciążać operator new dla swojej klasy i delcare to prywatne?

+0

Dzięki. Całkowicie zapomniałem o nowym sterowniku do tej pory! Chociaż nie może całkowicie uniemożliwić tworzenia się na obszarze sterty (ponieważ może to być zmienna składowa w obiekcie utworzonym przez operatora new), ale byłoby pomocne, aby zapobiec wielu błędom. – summerlight

+0

@Summerlight: Uważam, że nie można CAŁKOWICIE zapobiec tworzeniu go w czasie kompilacji lub przenośności sterty. –

+4

tak, nawet z prywatnym 'operatorem new', byłoby to coś w rodzaju 5 linii kodu, aby napisać obiekt opakowania, który * zawiera * twój obiekt i który można przydzielić na stercie. Jak zwykle przy pisaniu kodu biblioteki C++, nie możesz dyktować, jak użytkownik * musi * z niego korzystać. Musisz założyć, że użytkownik biblioteki jest przy zdrowych zmysłach i nie będzie próbował złamać własnego programu. A jeśli założysz to założenie, nie * potrzebujesz *, aby uniemożliwić stertowanie obiektu. – jalf

0

Nie rozumiem problemu? Każda zmienna zdefiniowana w ramach funkcji jest tylko stosem.

class Lock { 
public: 
    Lock() { 
     performLock(); 
    } 

    ~Lock() { 
     performUnlock(); 
    } 
} 

void foo() { 
    // ... Code 
    Lock onStackOnly; 
    // ... Code that is locked 
} 


void foo() { 
    // ... Code 
    { 
     Lock onStackOnly; 
     // ... Code that is locked 
    } 

    // This code is unlocked. 
} 
+0

"Chcę zapobiec utworzeniu go na obszarze sterty". Chce, aby 'nowy Lock();' nie był możliwy –

+3

jego pytanie dotyczy tego, jak wymusić zdefiniowanie zmiennej w ramach bloku i zapobieżenie wystąpieniu na stercie. – BatchyX

Powiązane problemy