[C++] CRITICAL_SECTION niet gevonden?

[CU2morO]

Voor een projectje wil ik een Critical Section gebruiken om threaded asynch communicatie met een USB device te synchroniseren.

Op internet heb ik wat voorbeelden gevonden voor Win32 implementaties, en moet ik windows.h includen en vervolgens een CRITICAL_SECTION datatype object aanmaken, die ik vervolgens kan initializen en locken etc met de bijbehorende functies zoals hier beschreven:
MSDN: Using Critical Section Objects (Windows)

Echter wordt CRITICAL_SECTION type nergens herkend door mijn compiler. Het gaat om een CLR C++ applicatie in Visual Studio 2010 (VS11 beta ook geprobeerd)

Wat mis ik hier? Het is vast iets heel simpels omdat er niets over te vinden is op internet.

[Soultaker]

Wat is de foutmelding die je krijgt?

Waarschijnlijk ben je vergeten windows.h te includen of target je een verkeerde versie van Windows (zie Using The Windows Headers), hoewel dat laatste zelden het probleem is.

[ Voor 12% gewijzigd door Soultaker op 20-05-2012 15:33 ]

[CU2morO]

windows.h zit gewoon netjes in mn stdafx.h vermeld.

code:

ref class ServoControl
{
private:
    Usc^ _device;
    bool _connected;

    CRITICAL_SECTION _cs;

    void tryToConnect();
    void setUpUSC();

    void setTarget(unsigned char, unsigned short);
public:
    ServoControl(void);
    
};

Error:
Error 25 error C4368: cannot define '_cs' as a member of managed 'ServoControl': mixed types are not supported d:\projects\automarker\automarker\ServoControl.h 14 1 ProjectTest (Visual Studio 2010)

[Soultaker]

Ah, je bent met een CLR project bezig. Je kunt een critical section (of überhaupt native structs?) niet in een CLR-managed object stoppen, concludeer ik uit die foutmelding.

Een LPCRITICAL_SECTION kan wel, vermoed ik? Dan alloceer je dat ding gewoon op de heap. (Maar eerlijk gezegd weet ik niet precies hoe managed C++ werkt).

Als je meer van dit soort velden nodig hebt is het waarschijnlijk handig om je klasse op te spliten in een native en een managed deel zoals hier beschreven wordt (waarbij de managed class als proxy werkt).

[ Voor 48% gewijzigd door Soultaker op 20-05-2012 17:59 ]

[CU2morO]

Hmmm... twijfel twijfel... Zit dus met het volgende dilemma:


- De servo controller driver die ik wil aansturen is beschikbaar voor Managed C++ en C#
- Het liefst schrijf ik alles simpelweg in C#
- De servo controller wil ik (later) gaan aansturen via image processing met de OpenCV library (Unmanaged C++)
- EMGU is een beschikbare C# port van deze OpenCV library, maar de gratis versie heeft zijn beperkingen.
- Alternatief kan ik met de algemene libusb library de servo controller native gaan aanspreken via Unmanaged C++.
- De reden dat ik crit sects en thread wil gebruiken is om te pollen of een servo al een bepaalde positie heeft bereikt zonder dat de applicatie blocked.

Het lijkt er nu dus op dat Managed C++ het niet gaat worden, omdat dat straks toch niet kan interfacen met de Unmanaged C++ variant van OpenCV.

2 keuzes om het project overnieuw op te zetten:
- Unmanaged C++, en dan maar de generieke libUSB library te implementeren voor de communicatie. Volledige controle over threads, crit sects en goede integratie met de OpenCV library.
- C# met de meegeleverde servo controller driver, volledige controle over crit sects, threads, etc, en een beperktere (tragere?) implementatie van de OpenCV library....

Ik denk dat met deze informatie de laatste keuze het beste is. Wat lees in het artikel dat jij linkt en soortgelijke vragen is dat het wel kán om managed en unmanaged te combineren, maar dat het beter is om het te vermijden om vreemde constructies te voorkomen.

Input wordt gewaardeerd

[SKiLLa]

Ik zou voor C# gaan, meest toegankelijk en dan je kan makkelijk een background thread maken zonder dat je je druk hoeft te maken over de low-level afhandeling ervan; eventueel kun je lock(myObject) gebruiken voor critical sections en in een later stadium altijd ook nog unmanaged Win32 API / library calls indien echt noodzakelijk.

[.oisyn]

Even zeuren, maar dat wat jij "managed C++" noemt heet eigenlijk C++/CLI. De echte managed C++ (die uit Visual Studio 2003) is deprecated

[farlane]

Je project schreeuwt low level, dus C++ lijkt me een zinnige keus; helemaal als je wilt gaan interfacen met externe (C) libraries.

Multithreaded code in C++ is niet veel moeilijker dan in C#: De complexiteit zit em niet in de taal.