mingw vs msvc

Jeśli twój zleceniodawca (o ile jest) nie naciska na jakieś mocne integracje z flakami Windowsa to spokojnie można obejść się z GCC. Nie musisz przecież używać czegokolwiek Windows-only, żeby program działał dobrze. Jest przecież mnóstwo przenośnych programów o świetnej funkcjonalności, więc i twój może taki być.

ATSD:
Nie zastanawiałeś się nad wybraniem platformy Java (tzn niekoniecznie język Java, są też inne popularne języki na JVM)? Do aplikacji typowo biznesowych Java nadaje się dużo bardziej niż C++.

Nie ukrywam że kierowałem się szybkością działania i prostotą we wdrażaniu, bez instalowania czegokolwiek innego, tylko app + dllki. Chociaż nie ukrywam że wiele rzeczy miałbym podane na tacy, jak np. SOAP albo kryptografię...

Czego dokładnie używasz z gsoap? Niektóre elementy są tylko pod GPL v2, co może utrudnić sprzedawanie twojej aplikacji różnym firmom (jak nie kupisz na to innej licencji). Dodatkowo mam nadzieje, że nie zaszalałeś z domową kryptografią (tzn. wszystko, co nie jest prostym wrapperem do zewnętrznej biblioteki, może być podatne na atak). Jeżeli twoja aplikacja kompiluje się na obydwu kompilatorach, to ja bym wybrał msvc, testując używając także gcc. Mimo bycia zwolennikiem Linuksa, to muszę przyznać, że Microsoft ma najlepsze narzędzia programistyczne do C++.

Poza tym, nie wiem czy akurat wydajność jest najważniejszą rzeczą w aplikacji biznesowej (szczególnie jeżeli większość pracy programu to czekanie na zewnętrzną bazę danych, czy nawet zewnętrzny serwer), zwróciłbym uwagę bardziej na bezpieczeństwo, dostępność bibliotek czy łatwość modyfikowania (ale na to już za późno). Zawsze trudne obliczeniowo zadania można oddelegować do własnoręcznie napisanej natywnej biblioteki.

Wtyczka obsługująca SOAP za pomocą gSOAP jest napisana na GPL (udostępniam kod samej wtyczki), także wykorzystuję bibliotekę legalnie... Co do kompilacji, to na msvc mam problem z sqlcipher, ale myślę że jakoś sobie poradzę. Co do aplikacji, zależy również na szybkości działania samego interfejsu użytkownika i minimalnego obciążenia kompa, dlatego boje się wszelkich jvm czy net frameworków . Chociaż ta kwestia tak naprawdę jeszcze nie jest całkiem zamknięta. . .

Mianowicie nie wiem czy użyć MSVC 2010 czy gcc (MinGW).
Od strony technicznej na jedno wychodzi.
Bardziej się zastanów nad IDE: czy wolisz Visual Studio, czy Qt Creator? Bo do tego różnica się właściwie sprowadza.

Qt Creator ma lepszą integrację z Qt (co zrozumiałe), ale to środowisko jest… inne, co nie każdemu się podoba.

Jeśli jednak piszesz w Notatniku i odpalasz make, to i ta różnica tobie znika..

Korzystam z QtCreator.

Wątpię czy możesz używać pluginu GPL w programie nie GPL bez wyjątku w licencji, a nie możesz tego wyjątku dodać, ze względu na licencję gSOAP. Gdyby to było możliwe, to GPL nie miałoby za dużego sensu, bo każdą bibliotekę można by użyć jako plugin.

JVM, czy .net poza uruchomieniem nie są takie wolne. W przypadku aplikacji biznesowej nie masz dużego obciążenia procesora i aplikacja napisana powiedzmy w C# będzie pod względem szybkości nierozróżnialna od tej napisanej w C++. C++ ma swoje miejsce trochę niżej w hierarchii abstrakcji, twój program nie będzie działał na farmie serwerowej, gdzie dwukrotna różnica szybkości może spowodować duże oszczędności, lub na komórce, tylko na normalnym komputerze, która przez 95 % czasu nie będzie nic robi. Jak gdzieś będzie problem z wydajnością, to prędzej na IO.

GPL wymaga, żeby cały program był wydany na GPL.
LGPL wymaga tego samego, chyba, że dołączymy program LGPLowy jako wtyczkę (czyli coś co można dowolnie podmienić już w wersji skompilowanej programu) i opublikujemy wszelkie zmiany do kodu LGPLowego.

W przypadku gSOAP jednak jest więcej opcji niż GPL albo licencja płatna:

The gSOAP Public License
The gSOAP Public License 1.3 is based on MPL1.1 (Mozilla Public License 1.1).

The license allows for commercial and non-commercial use of limited parts of gSOAP without fees or royalties. It also allows products to be built on top and distributed under any license (including commercial). Products developed with gSOAP should include a notice of copyright and a disclaimer of warranty in the product's documentation (License Exhibit B).

The gSOAP public license requires modifications that are distributed as part of an open source product based on gSOAP to be submitted back to us.

Note that the soapcpp2 and wsdl2h tools, UDDI code, Web server, and sample applications are NOT covered by the gSOAP public license. These are offered under a choice of GPL or commercial licensing.

A Java raczej nie stworzy żadnych problemów. Nawet ktoś z kontem gościa może sobie zainstalować Javę na komputerze (jestem prawie pewien, że .NETa nie da się tak zainstalować) i odpalić program Javowy.

Jeśli program stałby się hitem i zacząłbyś go masowo sprzedawać to mógłbyś się nawet wtedy pokusić o licencję na http://www.excelsior-usa.com/store/jet.html który kompiluje Javowe programy do samodzielnych exeków i pakuje je w instalatory. Ale myślę, że to raczej nie będzie potrzebne.

Jednak będę się upierał przy tym, że projektując wtyczkę w odpowiedni sposób, mogę uniknąć publikowania kodu głównej aplikacji. . . Zresztą pisze o tym na stronie www.gnu.org .

A jakiś konkret, wycinek z licencji?

http://www.gnu.org/licenses/gpl-faq.pl.html#NFUseGPLPlugins

Wypas. W takim razie będziesz musiał skonstruować sobie protokół do IPC (inter process communication) żeby komunikować się z gSOAPem, a SOAP sam w sobie jest pewną formą IPC.

Zamiast kopać się z takimi pierdołami wybierz Javę i jakieś libki na niewirusowych licencjach.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Borderline case czyli dozwolone czy nie?

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

A więc zostaje chyba tylko wymiana wiadomości (jak np w MPI) pomiędzy programami, choć w sumie nawet tego nie jestem pewien.

Mam zamiar wykorzystać zwykłego pipe'a, którego tylko zaszyfruję. I mam nadzieję, że to wystarczy ... Przesiadka na Jave, czy C# mi się nie uśmiecha, bo dość dużo już napisałem, a wiem że np. w C# taki SOAP to 2 kliknięcia myszką.

Dużo czyli ile? Nawet jak przewidujesz, że jesteś w połowie, to warto się przesiąść na Javę, bo zwykle programiści są zbyt optymistyczni, jeśli chodzi o własne możliwości. A pisanie aplikacji typowo biznesowych w C++ to masochizm, żeby nie powiedzieć głupota.

Wibowit napisał(a)

A pisanie aplikacji typowo biznesowych w C++ to masochizm, żeby nie powiedzieć głupota.

Autor pisze w Qt, a nie w samym C++. Jeśli nie pisałeś nigdy nic z użyciem tego frameworka nie pisz, że jego użycie do głupota. Pisząc desktopa (obojętnie czy to aplikacja biznesowa czy jakaś inna aplikacja dedykowana) szybciej wybiorę Qt niż javę. Sam interfejs tworzy się dużo szybciej niż w swingu no i mechanizm sygnałów i slotów daje więcej swobody. Teraz możecie mnie hejtować....

@topic
To raczej nie ma znaczenia. Mingw generuje więcej wynikowego kodu ale pewnie i tak będziesz binarki czymś kompresował więc doesn't matter.

(edit literówki)

Sam interfejs tworzy się dużo szybciej niż w swingu

Tzn szybciej niż metodą wyklikiwania GUI?

no i mechanizm sygnałów i slotów daje więcej swobody

Więcej swobody niż co? Że niby do Javy nie ma podobnych rozwiązań (nie wiem dokładnie na czym polega ten mechanizm sygnałów i slotów i jakie ma zastosowania, więc jak na razie nie mam do czego przyrównać, ale np akka.io załatwia sprawę komunikacji na wiele sposobów).

Wibowit napisał(a)

Sam interfejs tworzy się dużo szybciej niż w swingu

Tzn szybciej niż metodą wyklikiwania GUI?
</qoute>

Dobrze, to niech będzie że akurat mi szybciej klika się w narzędziach Qt.

Wibowit napisał(a)

no i mechanizm sygnałów i slotów daje więcej swobody

Więcej swobody niż co? Że niby do Javy nie ma podobnych rozwiązań (nie wiem dokładnie na czym polega ten mechanizm sygnałów i slotów i jakie ma zastosowania, więc jak na razie nie mam do czego przyrównać, ale np akka.io załatwia sprawę komunikacji na wiele sposobów).

Więcej swobody niż implementowanie wirtualnych metod (onPushButtonClicked). Sygnały i sloty to mechanizm, który w prosty sposób pozwala podłączyć jakikolwiek event do jakiejkolwiek metody (oznaczonej jako slot), sygnał (event) można podłączać do kilku slotów, kilka sygnałów do jednego slota, sygnał mogę zestawić do innego sygnału, mogę tworzyć własne sygnały i robić inne cuda jakie tylko przyjdą mi do głowy.

@several ale w Javie mozesz zrobić dokładnie to samo. Różnica jest w ilosci kodu, ale wynika to tylko z tego że QtCreator/QtDesigner sporą cześć informacji generuje sam, albo zapisuje w xmlu. W przypadku Swinga masz wszystko w javowym kodzie ;)

@Shalom
W Qt też masz całe wyklikane w Designerze GUI w postaci kodu C++ kiedy przychodzi do kompilacji.MOC na podstawie XMLa Designera generuje klasę-pojemnik mającą metodę setupUi(QWidget*),w której to metodzie tworzone i pozycjonowane są wszelakie kontrolki z zaprojektowanej formatki,układane są w layoutach itd.Nie ma potem potrzeby grzebania się w tej funkcji samemu.

Jeżeli chodzi ogólnie o kompilatory to ja polecę... DMC! Jest dużo szybszy od GCC(co do generacji kodu), dużo świeższy(mniej więcej tak jak LLVM)

1. Jeśli ma być aplikacja pod Windows to lepiej VC++

• szybsza binarka (w czasie run-time, nie kompilacja)
• bezpośrednie wsparcie dla interfejsów systemowych (nieprawdą jest że można się bez nich obyć - napisanie
  zwykłego demona MUSI korzystać z API, podobnie "schowek", uprawnienia użytkownika, zarządzanie procesami...)

1. Kod na licencji GPL wykluczyłbym z projektu, chyba że chcesz go publikować jako źródła.
   Lepiej wybieraj LGPL, a najlepiej BSD / MIT / Public Domain.

2. SOAP to zdaje się śpiew przeszłości. Do wyboru masz wiele innych rozwiązań:

• Boost.interprocess
• POCO
• PION
• serwis HTTP / REST / JSON (np. Mongoose)
  i pewnie jeszcze pare innych.

1. Aplikacje biznesowe (baza danych, formatki, diagramy, raporty) tzw. "mainstream" robi w Java / C#.
   Ale to nie znaczy że się nie da w C++/Qt czy innym narzędziu (np. C++/wxWidgets, wxPython, Delphi).
   Szybkość tu raczej nie ma znaczenia - chyba że komunikujesz się ze światem zewnętrznym i opóźnienia
   liczone w ms mają znaczenie. A nawet wtedy możesz napisać jeden moduł w C++ a resztę w języku z bardziej
   ludzką twarzą - C#, Java, Python.

Ja osobiście do aplikacji biznesowych wykorzystuje COBOL, więc dla mnie każdy z ww języków jest lepszy :)

Dzięki za wypowiedź. Jeśli chodzi o SOAP to muszę z niego skorzystać, bo bank, z którym mam się komunikować udostępnia api tylko w tym protokole...