C++ i GUI jeszcze raz

0

Cześć, pytanie mam konkretne. Wiem, że temat był poruszany milion razy. Czytałem to. Czytałem też różne rzeczy w necie. Chcę pisać okienkowo w C++, używając Visual Studio. Nastawiam się na pisanie pod Windows. Zależy mi na szybkości. Wiem, że najlepszym rozwiązaniem byłoby pisanie całego GUI w WinApi (wtedy aplikacja działałaby najszybciej i najbardziej natywnie), ale pisanie całego GUI w WinApi ma dwa minusy:

  1. Trzeba się nieźle napocić
  2. Nie można użyć designera.

Mógłbym używać MFC, ale MFC jest ponoć przestarzałe i ciężkie.

Więc pomyślałem - czemu nie użyć .NET? Używam Visual Studio, mam designera i generalnie jest spoko.
Problemy jednak pojawiają się przy łączeniu natywnego C++ z .NET.

I teraz pojawia się kolejne pytanie. Z czym łączyć C++. Z CLI, czy z C#. Wiele osób pisze, że jednak nie poleca CLI. Mówią, żeby importować do C# dllki C++. I to jest zrozumiałe. Tyle, że ciężko jest importować całe klasy (jeśli w ogóle się da). Drugie podejście, jakie znalazłem, to napisanie wrappera w CLI, a potem używanie go w C#. To chwali sobie sporo osób. Trochę mnie to dziwi, bo zastanawia mnie tu szybkość działania. Wg mnie taka kombinacja: C++ + CLI + C# może całkowicie zniweczyć szybkość C++. I z tym pytaniem właśnie uderzam do Was. Jakie podejście jest najlepsze?

Wiem, że jest QT, wxWidgets itd. Ale to trochę jakby uczyć się wszystkiego na nowo, no i to nie współpracuje z Visual Studio. C++ Buildera przetestowałem i dziękuję - nie będę używał.

Więc jakie rady?

(wiem, że teraz mogę się spodziewać odpowiedzi: "sam sprawdź i używaj to, co dla Ciebie bardziej wygodne", ale jak wspomniałem - zależy mi na szybkości działania i liczę tu na Wasze doświadczenie w tej kwestii.

1

Może po prostu WTL

http://sourceforge.net/projects/wtl/

0

Więc jakie rady?
Rady jednoznacznej nie dam, ale w tym co piszesz są pewne nieścisłości:

ale pisanie całego GUI w WinApi ma dwa minusy: [...] 2. Nie można użyć designera.
A to jest akurat nieprawda, Visual ma ten sam designer dialogów pod WinAPI co pod MFC.

Mógłbym używać MFC, ale MFC jest ponoć przestarzałe i ciężkie.
Lżejsze od Qt moim zdaniem, a wyraźnie mniej rzeźbienia niż z WinAPI.

Problemy jednak pojawiają się przy łączeniu natywnego C++ z .NET.
Jakie problemy?

Wiele osób pisze, że jednak nie poleca CLI. Mówią, żeby importować do C# dllki C++. I to jest zrozumiałe.
Po prostu dlatego że łatwiej jest pisać w C# niż w C++/CLI.

Wiem, że jest QT, wxWidgets itd. Ale to trochę jakby uczyć się wszystkiego na nowo, no i to nie współpracuje z Visual Studio.
Nie wiem jak wxWidgets, ale na pewno jest plugin do Visuala dający designer Qt, no i można też pod Qt Creatora podpiąć kompilator Visuala.

0

Wiem, że jest QT, wxWidgets itd. Ale to trochę jakby uczyć się wszystkiego na nowo, no i to nie współpracuje z Visual Studio.

wxWidgets współpracuje z visualem bardzo dobrze. Oczywiście designera zintegrowanego z IDE nie ma, ale tandem VS + wxFormBuilder daje radę.

0

ale pisanie całego GUI w WinApi ma dwa minusy: [...] 2. Nie można użyć designera.
A to jest akurat nieprawda, Visual ma ten sam designer dialogów pod WinAPI co pod MFC.</quote>

A jak się do tego dobrać? Inaczej. Tworzę sobie projekt Win32. I co zrobić dalej, żeby otworzyć designera, który nie jest NETowy? (Visual Studio 2013 Express)

0

W wersji EE nie ma edytora zasobów.

0

Visual Studio 2013 Express
Ściągnij wersję Community. w Express nie ma.

1 użytkowników online, w tym zalogowanych: 0, gości: 1