Wypowiedzi
-
Nigdy w Delphi :)
-
Piotr F.:
No dobra, ale nadal nie widzę tego konkretu :-)
Nie chcę tutaj forsować między wierszami jakiejś teorii jakie to obiekty są super /* bo są ;) */ ale serio liczę na jakiś choćby nawet kawałek kodu z opisem dlaczego akurat w tym rozwiązaniu obiekt nie ma racji bytu.
Nie będę doszukiwał się przykładów na siłę. :) -
Piotr F.:
Piotr Podgórski:
Jednak co tu dużo pisać, nie wszystko da się programować obiektowo, czasem jest lepiej zrobić to w inny sposób.
Jakiś konkretny przykład?
edit po ponad 2 tygodniach:
Tak to czasem bywa, na proste pytanie najtrudniej znaleźć odpowiedź... :->Piotr F. edytował(a) ten post dnia 27.01.08 o godzinie 22:16
Np. Pisanie niskopoziomowych sterowników. Oczywiście da się, ale ile nieepickich słów przy tym poleci, to już sam autor będzie wiedział. -
Generalnie korzystam z:
Visual Studio 6.0 - do kompilacji bibliotek użytkowych
Visual Studio 2005 - do pracy
Visual Studio 2008 - do prywatnego użytku
Turbo Delphi 2006 - do pracy
Wcześniej pisałem w RHIDE wpod DJGPP i Trubo Pascalu.
Próbowałem wielu IDE po Windows: Dev-C++, Code::Blocks i inne, których nazw już nie pamiętam.
Dla mnie zawsze wygrywało Visual Studio głównie poprzez czytelność projektów. Jest łatwo konfigurowalne, czego nie da się zrobić przez GUI można osiągnąć przez ręczną edycję projektu. Ma on oczywiście swoje wady (np. brak kompatybilności wstecz, brak możliwości kompilacji ze starszymi bibliotekami msvcrt), co jednak nie przeszkadza tak bardzo.
Dobrze wspominam jeszcze RHIDE, też dzięki utrzymywaniu porządku w projekach i nie przeszkadzaniu w pracy. Debug zawsze działał, żadne cuda się nie działy.
Delphi to już inna bajka, tu czasem trzeba nawet restartować środowisko, aby poprawnie móc debugować DLL'ki. Lubi opluć programistę z nienacka jakimś wyjątkiem, jednak używać się da.
Do Linuxowego środowiska kompilacji nigdy się nie przekonałem. Kiedy pusty projekt składał się z kilkunastu plików - zwątpiłem. Liczyłem bardzo na powstanie środowiska autorstwa Yann Lee pisanego w oparciu o Visual Studio, niestety projekt padł przez niechęć środowiska open-source (nie chcieli dzielić się źródłami).
W tej chwili to tyle. :) -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy DirectX
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Microsoft Visual C plus plus
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Microsoft Visual C plus plus
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy OpenGL
-
http://thedmd.deviantart.com/Michał Cichoń edytował(a) ten post dnia 03.07.07 o godzinie 11:21
-
Piotr F.:
Fakt, ale przeciążenie operatorów też jest - od Delphi 8.
We FreePascalu było chyba od początku.
Faktycznie to prawda. Nie zauważyłem przeskakując z wersji 7 na BDS2006.
Szablony są, niestety jednak tylko dla wersji .NET. -
Piotr F.:
Overload (osobiścię wolę określenie "przeciążenie") był już na pewno w Delphi 4, więc od prawie 10 lat?... ;)
Sam wolę termin "przeładowanie", "przeciążene" kojarzy mi się z wagą/masą. Co kto woli, te terminy określają tą samą właściwość.
Zgadza się, w Delphi jest słówko kluczowe 'overload'. Pozwala na przeładowanie funkcji, ale tylko funkcji. Nie ma nigdzie mowy o operatorach.
Piotr F.:
http://www.dummzeuch.de/delphi/object_pascal_templates...
Używamy tego rodzaju szablonów od dłuższego czasu. Nie ma jednak wsparcia dla faktycznych szablonów. To co tutaj jest wymaga definiowania osobnego modułu dla każdego szablonu. Co leniwemu programiście jest strasznie nie na rękę. :P
Ja mówię o szablonach, które stanowiły by część składni Object Pascala.Michał Cichoń edytował(a) ten post dnia 17.06.07 o godzinie 12:13 -
Karol A. Z.:
Znam programistę Delphi, który z tym językiem potrafi czynić cuuuda.
<ciach>
Teraz chciałbym by - dla opozycji - ktoś pokazał mi zalety języka. I kto dzisiaj pisze w Delphi i dlaczego.
To co napisze odnosi się do całego fragmentu, który nieco przyciąłem.
Zgodzę się z przedmówcą co do kwestii Pascala, to język wykorzystywany do celów edukacyjnych. Mówię tutaj o wersji 6.0, dokładnie Trubo Pascal. Kojarzycie to dosowe środowisko? A "Run-Time error 200"? ;)
Wiele osób zaczynało od wstukiwania żółtych literek na niebieskim tle. Pascal był trzecim językiem jaki poznawałem równolegle z C/C++. Najważniejszy wniosek jaki mogę wyciągnąć z tamtego okresu, to taki, że w zasadzie Pascal i C to samo. Bardzo często kod wyglądał bardzo podobnie. Rzadko ówczas przekraczało się wyznaczone 64kB.
Prostota i ścisła struktura programów w Pascalu wpływały na jego wartość edukacyjną. Opisowy kod stawał się bardziej jasny dla początkujących. Dzięki temu, że ludzie nauczyli się go jako pierwszego tworzyli w nim projekty zarówno małe i duże. Bardzo pomagała im w tym biblioteka TurboVision.
Język C był kolejną rzeczą, której ludzie się uczyli. Tak to jest np. teraz na informatyce w Politechnice Śląskiej. Studenci stwierdzają, że C to właściwie to samo, tylko krócej się wszystko zapisuje (bo zamienia się begin/end na klamerki). ;)
Po drugim etapie nauki zazwyczaj zapomina się tego pierwszego. Sam również zapomniałem wiele z tego co umiałem zrobić w Pascalu.
Jakie są zalety Pascala? Największą jest ścisła struktura kodu. Dla początkujących to dobra rzecz, nie muszą się troszczyć o wszystko i takie "ograniczenie" jest im na rękę. Łatwiej zapamiętać co ma być gdzie i jak poukładać, żeby działało. To czyni Pascala prostszym od C, gdzie jest (prawie) absolutna dowolność pisania kodu.
To tyle o historii. :)
Wojciech P.:
często bawi mnie krytyka Delphi pt. "toto pochodzi od pascala, kiepsko" padająca z ust(palców?) osób, które nie próbowały nawet zrealizować ambitniejszych projektów na "wymierającej" technologii.
Często takie słowa to żart. Podobne frazesy padają w kierunku C++. Jeżeli ktoś to mówi na poważnie, zazwyczaj nie ma podstaw to wydawania takich osądów. Z tego prosty wniosek, że nie warto się takim delikwentem przejmować.
Chyba nie zdążyłeś ochonąć. :)
na koniec: zarzucanie środowisku "edukacyjności" (w domyśle prostoty w nauce) jako _wady_ , uważam za błąd, cechę właściwą użytkownikom C++, języka, którego nawet jego twórcy nie ogarniają w 30%.
Każdy kto ma trochę rozumu nie będzie się spierał o wyższość jednego języka na drugim. Jak już gdzieś zostało wspomniane, co za różnica jakiego młotka używasz do wbijania gwoździ skoro efekt jest taki sam, a sam wcale bardziej się nie zmęczyłeś?
Karol A. Z.:
Chodzi o przyzwyczajenie.
Jesli cale zycie tluklem w C a Pascal byl przeze mnie kojarzony okolo Basica to bede korzystal wlasnie z C.
A co do jakosci kodu sie nie wypowiem, nie sprawdzalem, ale przy najblizszej okazji. :>
Stawianie Pascala obok Basica to lekka przesada. :) W mojej prywatnej opinni powinno się o tym ostatnim zapomnieć i pozwolić osiąść na kartach historii inżynierii oprogramowania. Odnoszę wrażenie, że jest on utrzymywany na siłę (mowa o Visual Basec).
Kod generowany przez Delphi i kompilatory C++ nie różni się bardzo wydajnościowo. Można się kłucić o milisekundy, kiedy progam działa kilka minut tylko po co?
Pisałem całkiem sporo w Delphi, znacznie więcej w C++. Jedyne co mogę powiedzieć to, że wygodniej mi używać tego drugiego. Abstrahując od C++, Delphi jest wygodne. Nawet nie korzystając z elemntów wizualnych dobrze się nim pisze. Często jednak to środowisko jest kojarzone z 'wklikiwaniem' programu, co jest niesłuszne bo przygotowanie interfejsu powinno być jedną z ostatnich czynności przy pisaniu aplikacji, szczególnie bardziej złożonej niż edytor tekstu sklejony z domyślnych komponentów. Nie można odmówić temu językowi ogromnej ilości bibliotek (lub wrapperów na nie) i jeszcze większego zasobu komponentów dla VCL. Możliwości ogranicza tylko wyobraźnia programisty.
Trudno jednak nie odczuć braku szablonów i przeładowania operatorów, czszczególnie jeśłi pisało się wcześniej w C++. Ponoć takie rozszerzenia już niedługo będą (lub już są) dostępne.Michał Cichoń edytował(a) ten post dnia 16.06.07 o godzinie 03:21 -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Microsoft Visual C plus plus