Delphi i C++ dobre combo?

Cześć,

Sorrki jeśli zły dział - whałem się między Newbie vs obecny, ale do rzeczy.
Co ogólnie sądzicie o pisaniu aplikacji używając dwóch języków,
np Delphi do GUI, oraz pomocniczych funkcji np w C++ jako dll'e.

Dlaczego tak?
Nic nie zastąpi VCL'a do szybkiej budowy nawet skomplikowanych interfejsów, tanie komponenty wizualne i inne.
C++, np jakiś darmowy kompilator który wykonuje funkcje bardziej zasobochłonne gdzie np trzeba zrobić coś dużo szybciej na większej ilości danych.

Takie połączenie sprawia, że program może działać niemal tak samo jak pisany w całości w C++ i samego Visual Studio, ale mamy nieporównywalnie większą produktywność i efektywność, chyba że ktoś mi jest w stanie wskazać lepszą alternatywę na łatwiejsze tworzenie funkcjonalnych GUI do programów.

Emrarcadero C++ w RAD studio odpada, gdzieś czytałem kiedyś (nie mogę znaleźć teraz) że kod jest wyraźnie wolniejszy w C++ innych kompilatorów np. Visual C++ od MS.

To jest w zasadzie moje drugie pytanie tego tematu, ma ktoś porównanie jakieś benchmark działań matematycznych operacji na bazach danych, sortowania itp pierdoły jak wypada C++ od Embarcadero na tle DevC++ czy VS szczególnie najnowsze wersje XE4, XE5, XE6

Pozdr

szybkość C++ vs Delphi to w obecnej chwili mit. Jeśli już coś jest kluczowe i ma działać szybko to pisze się to jako wstawkę asemblerową. Jednak trzeba mieć świadomość, że źle napisana wstawka może działać wolniej niż napisanie tego samego w języku wysokiego poziomu i pozwolenie zoptymalizowania kompilatorowi

Upierdliwość takiego rozwiązania przeważa nad wszelkimi ewentualnymi zyskami.

Wiesz, takie rozwiązanie miało by sens kiedy byś miał zespół który pracuje na Delphi a jedna osoba klepie w C++ za grosze ew na odwrót. Teraz wystarczy dobrze rozplanować typy zmiennych i algorytm.

Pierwszy raz widzę takie kombinacje; Jaki niby jest z tego zysk? Tworzenie zewnętrznych bibliotek nie ma najmniejszego sensu w tym przypadku, bo nawet jeśli zyskasz nieco na czasie, to będzie trzeba ciągle linkować biblioteki żeby czegoś użyć; Więcej się umordujesz, niż zyskasz;

Biblioteki mogły by się przydać, gdyby funkcje i inne jej zasoby miały być uniwersalne - jedna biblioteka możliwa do wykorzystania w wielu projektach, uniezależniona od języka, w którym dana aplikacja powstaje; Osobiście nie widzę sensu w tworzeniu programu w ten sposób.

do zwyklego projektu nie ma sensu.

A jakie sa te niezwykle? A no np. SKYPE, GUI w Delphi, a warstwa komunikacyjna w C++, wtedy mozna sie zastanawiac nad takim czyms.

Do C++ też masz biblioteki w których można budować GUI - Qt, Gtkmm, WxWidgets, Ultimate więc nie widzę sensu aby łączyć go z Delphi.

@furious programming nie zgodzę się, co to za wysiłek? Satyczne ładowanie i wywoływanie.
Niestety wydajność Delphi w niektórych operacjach może być przeszkodą, typowe matematyczne operacje działają 30-200% szybciej w C++ niż w Delphi, ja uważam że to całkiem sensowne rozwiązanie.
Poza tym nie chodzi o sam interfejs, przecież można pisać wiele funkcji znacznie prościej za pomocą Delphi a zewnętrzenie korzystać tylko z tych, gdzie wydajność ma znaczenie i robi różnicę. Wciąż jest produktywność wyższa niż zabawa z tworzeniem wszystkiego w VS, poza tym jest jeszcze jedna zaleta, program działa śmiało bez żadnych .netów itp, jeden exe ew jedna dwie biblioteki zew ładnie czysto i praktycznie tak samo szybko jak w przypadku samego VS przy czym w przypadku większego programu można znacznie skrócić czas developmentu i tym samym koszt.

@emacs nie ma co porównywać nawet, proste operacje i budowa GUI jest wciąż 5x szybsza i wygodniejsza w Delphi.

Combo wg mnie ma jak najbardziej sens.

Co do C++ od Embarcadero kiedyś to porównywałem chyba kiepski jest wolniejszy od Visual C++ ich kompilator a wydajność na poziomie Delphi albo niewiele wyższa....

@up najszybciej rozwiążesz dany problem w technologi która lubisz i którą znasz najlepiej.

Kod pisany przez nas powinien być w całości napisany w jednym języku.
Biblioteki, których używamy, niech sobie będą pisane w czymkolwiek - nie mamy na to wielkiego wpływu.

Przypadkiem pośrednim może być, gdy napisaliśmy już bibliotekę (np. w C++) wszystko działa, jest gotowe, ale zachciało nam się dorobić GUI - no to ewentualnie można zrobić to w Delphi. Ale to gdy już mamy sporo kodu, którego nie będziemy przepisywać od nowa.
W dopiero zaczynanym projekcie mieszanie języków to głupi pomysł.

W pełni zgadzam się z poprzednikiem - jeden program, pisany w całości przez nas, powinien być w jednym języku;

gronkowietz napisał(a)

nie zgodzę się, co to za wysiłek? Satyczne ładowanie i wywoływanie.

Podałeś pierwszą nadmiarowość - linkowanie bibliotek; Na dodatek jeszcze statyczne, które sensu nie ma, bo to samo możesz mieć od razu w jednym programie, bez martwienia się choćby o istnienie biblioteki na dysku (to osobny plik);

gronkowietz napisał(a)

Niestety wydajność Delphi w niektórych operacjach może być przeszkodą, typowe matematyczne operacje działają 30-200% szybciej w C++ niż w Delphi, ja uważam że to całkiem sensowne rozwiązanie.

Jeżeli algorytmy obliczeniowe działają aż o 200% wolniej, to znaczy że trzeba je zoptymalizować, bo są słabo napisane;

Jeżeli chcesz się dowiedzieć czy to ma sens, to po prostu upewnij się, że pomimo wszelkich optymalizacyjnych zabiegów, kod napisany np. w C++ będzie o wiele szybszy, co przełoży się na większe zyski czasowe, niż 5 sekund; Przetestuj różne rozwiązania, a będzie wiadomo co lepiej będzie wykorzystać; Sam oceń, czy taki rozkład będzie się opłacał, czy nie, a jeśli będzie się opłacał (bo mocno przyspieszy działanie obliczeń/programu), to czy nie zwiększy znacznie nakładu pracy;

Możesz kombinować, nikt Ci przecież nie zabroni - to po prostu inne podejście do projektowania aplikacji; Ja tam nie jestem przekonany do takiego podejścia; Jednak opłacać się to będzie jedynie w przypadku, gdy czas wykonania algorytmów ma kluczowe znaczenie, a zysk będzie znaczący, nie wpływając znacznie na nakład pracy.

WinHex słynny jest tak mniej więcej napisany :)

jakiśtamnick napisał(a):

WinHex słynny jest tak mniej więcej napisany :)

Chociaż nie pomyłka tam większość w c plus borlanda starym i tylko pomocnicze w dev c++ lib, ale gdzieś kiedyś widziałem takie rozwiązanie w całkiem znanym programie...

Cóż ta za pomysły... Builder C++ ma przecież VCL, no i C++ chyba też. :)

fur napisał(a):

Cóż ta za pomysły... Builder C++ ma przecież VCL, no i C++ chyba też. :)

Kompilator Builder c++ jest wyraźnie wolniejszy od innych, stąd ten pomysł. Druga sprawa to Delphi nadal jest prostrzy o wiele to mniej skomplikowanych funkcji w których szybkość działania nie ma żadnego znaczenia.

jakiśtamnick napisał(a):

Kompilator Builder c++ jest wyraźnie wolniejszy od innych, stąd ten pomysł. Druga sprawa to Delphi nadal jest prostrzy o wiele to mniej skomplikowanych funkcji w których szybkość działania nie ma żadnego znaczenia.

Wolniejszy od czego?
VS C++ jest chyba z 10 razy wolniejszy... od krowy.

Natomiast Delphi jest obiektowo kompletnie do d**y;
przecież tam nie ma nawet automatycznych destruktorów, tz. gdy tworzysz np. TFile, wówczas sam musisz to jawnie czyścić, poprzez jakieś afile.done, co w c++ samo się robi.

Jedyna przewaga Delphi nad C++ to ta instrukcja with, która pozwala unikać ciągłego pisania pełnych nazw obiektów... C# to chyba dodano, no ale to skrypciarski język, jak ta Java, czy nawet javascript w html, i inne takie zabawki.

fur napisał(a)

Natomiast Delphi jest obiektowo kompletnie do d**y;
przecież tam nie ma nawet automatycznych destruktorów, tz. gdy tworzysz np. TFile, wówczas sam musisz to jawnie czyścić, poprzez jakieś afile.done, co w c++ samo się robi.

Ja jednak polecałbym powstrzymać się od wypowiadania na temat, o którym raczej nie masz bladego pojęcia; Nie stosuje się czegoś takiego jak done - jest Free i Destroy; A w C++ nic "samo się robi" - do tego istnieją skomplikowane mechanizmy;

Delphi (przynajmniej jego starsze wersje, nowych nie znam), podobnie jak najpopularniejsze implementacje czystego Pascala czy Object Pascala, nie wspierają GC (masz tutaj link do opisu - zapoznaj się z tym tematem), więc programista w wielu przypadkach musi sam po sobie sprzątać (ja wiem, w dzisiejszych czasach to takie nienaturalne...);

Naturalną koleją rzeczy jest to, że jeśli się dynamicznie alokuje pamięć - należy ją także zwolnić; Nie dotyczy to oczywiście typów prostych, łańcuchów, rekordów i wielu innych typów danych, a także komponentów, które automatycznie zwalnia klasa formularza w swoim destruktorze; Są jeszcze inne ciekawe przypadki, jednak nie będę ich wszystkich wymieniać, żeby nie odebrać Ci tej przyjemności - sam przeczytaj jakiś sensowny kurs;

Garbage Collection z jednej strony zapobiega tworzeniu dziurawego kodu, powodującego wycieki pamięci, ale z drugiej strony mimowolnie "uczy" niedbałości, która później obiawia się gigantycznymi memleakami, po przeniesieniu na inny język programowania, w którym nie ma "sprzątaczki"; Oczywiście to dotyczy tych programistów, którzy przenoszą swoje nawyki bez zapoznania się dokumentacją, objaśniającą wykorzystywanie zasobów pamięci;

fur napisał(a)

Jedyna przewaga Delphi nad C++ to ta instrukcja with, która pozwala unikać ciągłego pisania pełnych nazw obiektów...

Instrukcja wiążąca With to nie jest lekarstwo na wszystko; Kolejna rzecz, o której wspominasz, jednak bez jakichkolwiek sensownych "za" i "przeciw";

Pewnie jeszcze nie wiesz, że instrukcja wiążąca owszem, służy do zwolnienia programisty z powtarzania tego samego elementu kodu (to raczej nie powinno podlegać pod zasadę DRY), a ponadto może nawet przyczynić się do zoptymalizowania kodu; Zoptymalizowania połowicznego, dlatego że większość takich optymalizacji można ominąć, przez wykorzystanie zmiennej do zapisania referencji np. do jakiegoś obiektu, aby nie pobierać go za każdym razem;

Oczywiście skoro mowa o plusach, także należy wspomnieć o minusach; Nieumiejętne posługiwanie się instrukcją wiążącą doprowadza w dużej ilości przypadków do pogorszenia eketywności kodu, co można zaobserwować podglądając stan stosu; Można sobie stosować tę instrukcję dowolnie, ale trzeba mieć na uwadze, że albo używamy ją dla przyspieszenia pracy kodu (jeśli wiemy jak ją użyć), albo dla skrócenia zapisu instrukcji (co wiązać się może ze spowolnieniem wykonywania danego kodu);

Istnieje wiele technik optymalizacji kodu, z którymi każdy prędzej czy później powinien się zapoznać; Tobie zaś polecam zapoznanie się z tym artykułem, który zawiera kilka cennych wskazówek, które można wykorzystać zarówno w strukturalnym Pascalu, jak i w Delphi czy Object Pascalu;

A jeśli uważasz, że Delphi jest "do d**y" tylko dlatego, że nie posiada mechanizmów sprzątających, to najwidoczniej ani Pascal, ani Delphi, ani Object Pascal nie jest dla Ciebie; Pisz więc kod w takich językach jak np. Java, gdzie "sprzątaczka" istnieje i ma się dobrze.

furious programming napisał(a):

Ja jednak polecałbym powstrzymać się od wypowiadania na temat, o którym raczej nie masz bladego pojęcia; Nie stosuje się czegoś takiego jak done - jest Free i Destroy; A w C++ nic "samo się robi" - do tego istnieją skomplikowane mechanizmy;

Free jest zamiennikiem delete z C++, który ma zwalniać dodatkowo te dynamicznie alokowane po... zniszczeniu.

I nie ma nic skomplikowanego w C++ w tej sprawie - destruktory same się wywołują dla obiektów stawianych w kodzie i byle gdzie: w if-ach, forach, w dowolnym bloku, czyli np.:

for(i = 1; i < 20; i++)
{ 
  TFile f(prefix + i, mode); // otwiera/tworzy plik

  // czytamy, zapisujemy...

}

i to już się samo pozamyka, wyczyści, zwolni, itd.

no, gdzie popadnie, w przeciwieństwie do delphi/pasa, w których musisz deklarować to wszystko w var przed begin... chyba tylko w fortranie gorzej jest z tym. :)

furious programming napisał(a):

Delphi (przynajmniej jego starsze wersje, nowych nie znam), podobnie jak najpopularniejsze implementacje czystego Pascala czy Object Pascala, nie wspierają GC (masz tutaj link do opisu - zapoznaj się z tym tematem), więc programista w wielu przypadkach musi sam po sobie sprzątać (ja wiem, w dzisiejszych czasach to takie nienaturalne...);

Nie, w C++ nie ma tego - to jest w tych nowomodnych skrypciarskich 'językach': C#, java, .net, i inne takie myszki-robaczki...

furious programming napisał(a):

Naturalną koleją rzeczy jest to, że jeśli się dynamicznie alokuje pamięć - należy ją także zwolnić; Nie dotyczy to oczywiście typów prostych, łańcuchów, rekordów i wielu innych typów danych, a także komponentów, które automatycznie zwalnia klasa formularza w swoim destruktorze; Są jeszcze inne ciekawe przypadki, jednak nie będę ich wszystkich wymieniać, żeby nie odebrać Ci tej przyjemności - sam przeczytaj jakiś sensowny kurs;

coś chyba cienko znasz c++;
robisz swój class, albo bierzesz gotowy TPinter i on sam się wyczyści... opłucze i wysuszy. :)

furious programming napisał(a):

Instrukcja wiążąca With to nie jest lekarstwo na wszystko; Kolejna rzecz, o której wspominasz, jednak bez jakichkolwiek sensownych "za" i "przeciw";

Pewnie jeszcze nie wiesz, że instrukcja wiążąca owszem, służy do zwolnienia programisty z powtarzania tego samego elementu kodu (to raczej nie powinno podlegać pod zasadę DRY), a ponadto może nawet przyczynić się do zoptymalizowania kodu; Zoptymalizowania połowicznego, dlatego że większość takich optymalizacji można ominąć, przez wykorzystanie zmiennej do zapisania referencji np. do jakiegoś obiektu, aby nie pobierać go za każdym razem;

Oczywiście skoro mowa o plusach, także należy wspomnieć o minusach; Nieumiejętne posługiwanie się instrukcją wiążącą doprowadza w dużej ilości przypadków do pogorszenia eketywności kodu, co można zaobserwować podglądając stan stosu; Można sobie stosować tę instrukcję dowolnie, ale trzeba mieć na uwadze, że albo używamy ją dla przyspieszenia pracy kodu (jeśli wiemy jak ją użyć), albo dla skrócenia zapisu instrukcji (co wiązać się może ze spowolnieniem wykonywania danego kodu);

Istnieje wiele technik optymalizacji kodu, z którymi każdy prędzej czy później powinien się zapoznać; Tobie zaś polecam zapoznanie się z tym artykułem, który zawiera kilka cennych wskazówek, które można wykorzystać zarówno w strukturalnym Pascalu, jak i w Delphi czy Object Pascalu;

A jeśli uważasz, że Delphi jest "do d**y" tylko dlatego, że nie posiada mechanizmów sprzątających, to najwidoczniej ani Pascal, ani Delphi, ani Object Pascal nie jest dla Ciebie; Pisz więc kod w takich językach jak np. Java, gdzie "sprzątaczka" istnieje i ma się dobrze.

Oczywiście, że optymalizuje - przyspiesza. Zwłaszcza w 16 bitowym paskalu bez with te same wskaźniki są ładowane z 50 razy zamiast raz... no ale jest tylko ta jedyna przewaga delphi nad c++.

dodanie znacznika <code class="cpp"> - furious programming

fur napisał(a)

to jest w tych nowomodnych skrypciarskich 'językach': C#, java, .net, i inne takie myszki-robaczki

Przestań hejcić, bo czytanie ciebie jest nieprzyjemne.

fur napisał(a)

Nie, w C++ nie ma tego - to jest w tych nowomodnych skrypciarskich 'językach': C#, java, .net, i inne takie myszki-robaczki...

To teraz wskaż miejsce w moim poprzednim poście, w kórym napisałem, że C++ ma Garbage Collection; Napisałem za to o Javie:

furious programming napisał(a)

Pisz więc kod w takich językach jak np. Java, gdzie "sprzątaczka" istnieje i ma się dobrze.

Jeśli więc nic na temat C++ nie napisałem, to po pierwsze nie cytuj i nie komentuj moich słów, bo Twoje odpowiadzie ich nie dotyczą; Po drugie nie wmawiaj mi że coś twierdzę, skoro sam najlepiej wiem co twierdzę;

Poza tym .NET to nie jest język programowania, a platforma programistyczna; Znów podam Ci link do odpowiedniego artykułu, żebyś się o tym mógł przekonać;

fur napisał(a)

coś chyba cienko znasz c++;
robisz swój class, albo bierzesz gotowy TPinter i on sam się wyczyści... opłucze i wysuszy.

To teraz znajdź miejsce w moim poprzednim poście, w którym napisałem po pierwsze - cokolwiek o C++, po drugie - że znam C++; Jeśli więc żadne moje słowa z poprzedniego posta o tym nie świadczą, to bądź łaskaw ich nie komentować, bo Twoje odpowiedzi ich nie dotyczą; Po drugie to sam najlepiej wiem czy znam C++, czy go nie znam;

fur napisał(a)

Oczywiście, że optymalizuje - przyspiesza.

W takim razie zaglądnij jednak do artykułu, do którego link podałem w poprzednim poście, bo jak widać nie zapoznałeś się z ułomnością instrukcji With; Albo kliknij w ten link - prowadzi on bezpośrednio do opisu instrukcji wiążącej; Optymalizacja kodu przez wiązanie wcale nie jest taka klarowna;

Podsumowując - Twoje posty praktycznie nie dotyczą opinii na temat stworzenia aplikacji-hybrydy, napisanej po części w C++, a po części w Delphi; Hejtujesz Delphi tylko dlatego, że jest to język (lub kompilator), który nie ma zamiaru po Tobie sprzątać, a tłumaczenie Ci, że sprzątanie po sobie to dobry nawyk, traktujesz jak obrazę Twojej osoby w najgorszy sposób;

Hejterzy najczęściej umniejszają wartość danej technologii tylko dlatego, że jej nie znają, nie lubią jej lub praca z nią ich przerasta; Mnie w Delphi/Object Pascalu także trochę rzeczy przeszkadza, jednak nic nie stoi na przeszkodzie, aby się do nich po prostu przyzwyczaić i nie żalić się po forach;

W takim razie Panie @fur - jeśli masz coś do powiedzenia w temacie dotyczącym tworzenia aplikacji w dwóch językach - postuj śmiało; Jeżeli natomiast zamierzasz hejtować Delphi, bo zmusza do ręcznego zwalniania dynamicznie zaalokowanej pamięci, to lepiej skończ się wypowiadać; Naprawdę nie do tego celu został ten wątek założony.