Koniec żartów z Delphi - White House poleca

Koniec żartów z Delphi - White House poleca
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0
Yarilo napisał(a):

Lol stary, GC to jest ułatwienie które pozwala oszczędzić czas nie tylko przy wyciekach pamięci ale też eliminuje zbędny kod przy czyszczeniu zasobów, co za tym idzie szybszy maintance i wdróżenie na produkcje.

Lol stary, dokładnie o tym rozmawialiśmy i dokładnie o tym sam wcześniej napisałem. Jednocześnie nigdzie nie napisałem, że technologie takie jak C# czy Java są dla tumanów, więc swoją wypowiedzią i niepoprawną analogią manipulujesz czytelnikami tego wątku (dwóch już zmanipulowałeś, tych, którzy zaplusowali twój post).

Tu nie chodzi o to, że GC jest złe (bo nie jest), a o to, że praca w technologii, która go nie posiada (np. Delphi), tworzenie wycieków pamięci i obwinianie o nie język a nie siebie, to skill-issue. Myślę, że teraz wszystko jest klarowne.

Jeśli pracujesz w technologii, którą nie potrafisz się posługiwać (i tworzysz wycieki, np. w C czy Delphi), to masz dwa rozwiązania i żadnym z nich nie jest obwinianie języka o brak GC. Możesz albo nauczyć się zarządzać pamięcią, albo zmienić pracę i dostosować ją do własnych umiejętności/preferencji.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 5x, ostatnio: flowCRANE
Yarilo
Przecież tak napisałeś, nawet zacytowałem twoją odpowiedź :/
flowCRANE
„Źle zrobiłem, że użyłem słowa potrzebować, bo jest mało precyzyjne — powinienem użyć słowa wymagać. Potrzebować (GC) można z różnego powodu, a wymagać tylko z braku możliwości obejścia się bez niego.” (źródło).
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0

Ciekawy przypadek miałem ostatnio. Miałem wyciek pamięci (jeden blok, 260 bajtów), który był raportowany, a który jednocześnie istniał i nie istniał — wyciek Schrödingera. Mimo że destruktor tego bloku był wywoływany (co potwierdziłem pod debuggerem) to i tak był raportowany jako wyciek.

To są zdecydowanie ciekawsze, rzadkie przypadki — zwykłe wycieki to bzdety, takie się łata w 10 sekund.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 1x, ostatnio: flowCRANE
woolfik
  • Rejestracja:ponad 17 lat
  • Ostatnio:około 21 godzin
  • Postów:1598
1

Z ciekawostek to przejrzalem oryginal dokumentu nsa i tam o delphi nie ma slowa

MI
  • Rejestracja:około 7 lat
  • Ostatnio:dzień
  • Postów:43
1
woolfik napisał(a):

Z ciekawostek to przejrzalem oryginal dokumentu nsa i tam o delphi nie ma slowa

Ależ jest: https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY_V1.1.PDF

MI
  • Rejestracja:około 7 lat
  • Ostatnio:dzień
  • Postów:43
1

Język Object Pascal (mam na myśli FreePascal) posiada kilka cech, które utrudniają programiście strzelenie sobie w stopę:

  • brak preprocesora
  • silne typowanie
  • możliwość sprawdzenia przekroczenia zakresu (indeksu tablicy, typu wyliczeniowego...)
  • możliwość sprawdzenia nadmiaru przy operacjach na liczbach całkowitych
  • możliwość sprawdzenia poprawności rzutowania klasy i sprawdzenie poprawności tablicy VMT przed wywołaniem metody
  • zarządzane typy (zliczanie referencji): łańcuchy, tablice dynamiczne i rekordy
  • łańcuchy, których używanie nie boli (AnsiString, UnicodeString)
  • tablice dynamiczne, których zawartość (przydzielona pamięć) jest obligatoryjnie zerowana
  • interfejs typu "COM", który posiada zliczanie referencji (wbrew nazwie działa na wszystkich systemach operacyjnych i platformach, dodatkowo dostępny interfejs typu "CORBA", bez zliczania referencji)

Porównanie języka Object Pascal do .net lub javy (chociaż FreePascal potrafi kompilować do java bytecode) mija się z celem - to jak anglosaskie porównywanie jabłek do pomarańczy. Bardziej adekwatne jest porównanie do C/C++. FPC kompiluje do postaci binarnej, nie potrzebuje środowiska uruchomieniowego, generuje kod na różne platformy, np 8bit AVR albo wbudowany ARM, Xtensa (bare metal, FreeRTOS).

flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0

Preprocessor to akurat by mi się przydał — trochę szkoda, że go nie ma. Silne typowanie jest jak najbardziej w porządku, bo daje spore bezpieczeństwo, ale znów — czasem staje się to uciążliwe, bo wymaga ciągłego rzutowania lub zmiennych pomocniczych. Ale to dotyczy bardziej specyficznych przypadków.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
Manna5
  • Rejestracja:około 6 lat
  • Ostatnio:2 minuty
  • Lokalizacja:Kraków
  • Postów:641
1

Dużą wadą Pascala jest to, że jeśli weźmiemy za standard języka jego pierwotny opis N. Wirtha to jest to język bardzo okrojony bez wielu przydatnych elementów. Oczywiście twórcy kompilatorów rozszerzają Pascala czyniąc go praktycznym, ale to są rozszerzenia kompilatorów nieprzenośne między nimi. Nie ma jednego standardu, który byłby jednocześnie kompletny w sensie użyteczności, jak ma to miejsce w przypadku C.


flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0

No tylko że kogo obchodzi standard sprzed 54 lat.

Manna5 napisał(a):

Oczywiście twórcy kompilatorów rozszerzają Pascala czyniąc go praktycznym, ale to są rozszerzenia kompilatorów nieprzenośne między nimi.

O jakie rozszerzenia chodzi? Delphi i Free Pascal to osobne dialekty — równie dobrze można stwierdzić, że osobne języki.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 2x, ostatnio: flowCRANE
ID
  • Rejestracja:około 4 lata
  • Ostatnio:5 dni
  • Postów:43
0

myślałem że chodzi o firmę aptiv zwaną wcześniej delphi

KamilAdam
Ci co zwolnili teraz ludzi?
KamilAdam
aaa, byłem tam kiedyś na wycieczcie
ID
kiedyś na jakimś meetup, wyglądali legitnie, choć mówili że poprzednią nazwę im z dnia na dzień zmienili
Manna5
  • Rejestracja:około 6 lat
  • Ostatnio:2 minuty
  • Lokalizacja:Kraków
  • Postów:641
1

No tylko że kogo obchodzi standard sprzed 54 lat.

W każdym razie standaryzuje on kompletny zestaw funkcjonalności języka, tak, że nie trzeba powszechnie polegać na rozszerzeniach kompilatorów. Może wyjątkiem są pragmy, ale to jest tak naprawdę przekazywanie ustawień kompilacji w pliku z kodem a nie logika programu, albo w bardzo niskopoziomowych programach wstawki asemblerowe, co czasem bywa nieuniknione. I obie te rzeczy jak najbardziej występują w Pascalu. A dodatkowo w Pascalu m. in. unie to już nieprzenośna funkcjonalność dodatkowa kompilatora.


edytowany 1x, ostatnio: flowCRANE
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
1
Manna5 napisał(a):

W każdym razie standaryzuje on kompletny zestaw funkcjonalności języka, tak, że nie trzeba powszechnie polegać na rozszerzeniach kompilatorów.

Pamiętaj, że jeden słuszny standard Pascala nie istnieje. Ten oryginalny standard, opracowany przez N. Wirtha, wyszedł z użytku dziesiątki lat temu i nikt nie będzie się do niego stosował, bo jest zbyt stary i zbyt prymitywny.

Od tamtego czasu wykształciło się ich kilka, wszystkie na bazie pierwowzoru — Turbo Pascal, Mac Pascal, ISO Pascal, Free Pascal i Delphi. Wszystkie stosują się do pierwotnych zasad i zapewniają to, czego się od Pascali oczekuje. Nieistotne który dialekt weźmiesz, każdy jest oficjalny, udokumentowany i zapewnia odpowiednie bezpieczeństwo (oraz wybrany zestaw wodotrysków, pasujących do nowoczesnych języków).

Może wyjątkiem są pragmy, ale to jest tak naprawdę przekazywanie ustawień kompilacji w pliku z kodem a nie logika programu, albo w bardzo niskopoziomowych programach wstawki asemblerowe, co czasem bywa nieuniknione. I obie te rzeczy jak najbardziej występują w Pascalu.

Pragmy są zbędne, bo Pascale wspierają modularyzację, w odróżnieniu od C.

A dodatkowo w Pascalu m. in. unie to już nieprzenośna funkcjonalność dodatkowa kompilatora.

Nie rozumiem co masz na myśli w tym zdaniu. Unie w Pascalach, zwane variant records, to takie same unie jak te występujące w C, choć z tą różnicą, że mają iście debilną, totalnie przekombinowaną składnię. jednak na poziomie bajtowym, są zgodne z uniami z C.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 3x, ostatnio: flowCRANE
Yarilo
  • Rejestracja:około 8 lat
  • Ostatnio:5 miesięcy
  • Postów:50
1

Wy gadu gadu o specyfikacji języka że nie ma Uni albo GC, ale do czego serio się Pascala/Delphi/Lazurusa wykorzystuje? Stworze w nim serwer www, sklep internetowy, aplikacje mobilna, aplikacje na arduino/atmege i inne embedded? Jak sie maja rozwiazania IOT?

A co do spraw czysto kodowych - sa dedykowane narzedzia do tworzenia testów? Jakieś odpowiedniki Junit w Javie albo Jest w JS? A jak wyglada sprawa z testami automatycznymi które wyklikuja aplikacje? Sa jakies odpowiedniki Selenium albo Cypress? Albo czy można tworzyć test containers w Lazurusie?

Zobacz pozostałe 11 komentarzy
RD
Aplikacje desktopowe, bardzo customowe backendy/API (nie typowy sklep, czy forum), aplikacje serwerowe, CLI, gamedev, aplikacje mobilne, integracje.
flowCRANE
@Yarilo: w skrócie — takie samo jak C i C++, czyli bardzo szerokie. Kwestią nie jest to co się da zrobić (bo da się niemal wszystko, relatywnie łatwo), kwestią jest niestety dużo niższa popularność w stosunku do wiodących na rynku technologii, średnia jakość Lazarusa oraz wieloletnia, szkodliwa dla popularności Pascala polityka Embarcadero (to się ciągnie od Borlanda).
flowCRANE
@Manna5: maczeta została zaprojektowana do karczowania haszczy, a częściej używana jest przez kibiców, niż ogrodników. Przyczepiłeś się faktu sprzed 54 lat i trzymasz się go kurczowo, tak jakby to miało jakikolwiek sens.
RD
C zostało stworzone, żeby można było przenosić Unixa na inne architektury i pisać kompilatory dla tooli, a teraz piszą w tym VMy jak JVM czy CLR. JS został stworzony do frontu, a teraz piszą w tym backendy. Cola była lekarstwem, a teraz miesza się ją z wódką. Minoxidil był lekiem na ciśnienie a teraz stosuje się na porost włosów. Podobnie nic nie znaczące fakty. Nie liczy się intencja a fatycznie jakie zadanie obecnie coś spełnia.
PD
  • Rejestracja:ponad 22 lata
  • Ostatnio:20 minut
1
Yarilo napisał(a):

Wy gadu gadu o specyfikacji języka że nie ma Uni albo GC, ale do czego serio się Pascala/Delphi/Lazurusa wykorzystuje? Stworze w nim serwer www,

Tak: Lazarus: indy, synapse, mormot; Delphi: te same komponenty + ICS

sklep internetowy,

można w js, Lazarus: pas2js - transpiler do js, Delphi: komercyjne rozwiązanie TMS WebCore oparte o pas2js

aplikacje mobilna,

tak, Lazarus: LAMW aplikacje na adroida, komplacja dla WinCE, Delphi: android + ios

aplikacje na arduino/atmege i inne embedded?

Lazarus: tak


pozdrawiam
paweld
Yarilo
A sa rozwiazania sklepowe napisane w Pascalu takie jak np Magento w PHP?
PD
Nie ma, przynajmniej nic o tym nie wiem.
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0
Yarilo napisał(a):

A co do spraw czysto kodowych - sa dedykowane narzedzia do tworzenia testów? Jakieś odpowiedniki Junit w Javie albo Jest w JS?

fpcunit, FPTest, Introduction to unit testing with Lazarus — w GitHub też pewnie coś znajdzie.

Przy czym przymknij oko na brzydotę interfejsu — zdaje się, że pascalowcy z natury nie mają gustu, często lubują się w przaśnych kolorkach i ogóle paskudnych oknach. Dobrze, że źródła są otwarte, każdy może sobie pozmieniać co chce i przekompilować te narzędzia. 🤣


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 2x, ostatnio: flowCRANE
Azarien
  • Rejestracja:ponad 21 lat
  • Ostatnio:około 5 godzin
1
woolfik napisał(a):

W każdym języku da się napisać program memory safe i memory unsafe

Chyba nie do końca rozumiesz znaczenie słów safe i unsafe. Można napisać program prawidłowo lub nieprawidłowo zarządzający pamięcią, natomiast jedne języki ułatwiają zrobienie tego prawidłowo, a inne ułatwiają popełnianie błędów – te ostatnie są “unsafe”, co nie znaczy że napisany w jednym z nich program zawiera błędy.

flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0

Są jeszcze języki, które wręcz zachęcają do popełniania błędów — np. C. 😉


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
Azarien
  • Rejestracja:ponad 21 lat
  • Ostatnio:około 5 godzin
5
furious programming napisał(a):

Są jeszcze języki, które wręcz zachęcają do popełniania błędów — np. C. 😉

C jest prosty i widać co w nim się dzieje. To ułatwia analizowanie kodu w kierunku poszukiwania błędów. C++ daje dużo więcej możliwości popełnienia błędu a jego znalezienie nie takie łatwe, bo wszystko może być „nie takie jak ci się wydaje” (bo niestandardowy smart pointer, bo niestandardowe operatory…).

flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0

Zgadzam się, choć prostota C przestaje być widoczna, tak samo jak przepływ sterowania, kiedy zaczyna się haksiorować kod. Już sama post- i preinkrementacja robią ludziom wodę z mózgu i zachęca do obfuskowania kodu, tworzenia jednolinijkowców itd. To samo jeśli chodzi o preprocesor czy przeładowywanie operatorów. Wiadomo, decyzja o tym jak pisać kod należy zawsze do programisty.

Mi wcale nie przeszkadza to, że C pozwala pisać syfiasty kod — jego ficzery są do tego, aby ich używać z głową. Zdecydowanie bardziej wolę czyściutkie C, niż C++ i jego zawiłości. Zresztą, C uważam za jeden z najlepszych języków, w którym wszystko jest łatwe do zrozumienia (zaraz obok Pascala). Na myśli mam przepływ sterowania, kiedy się go nie pochowa za własnymi abstrakcjami.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 4x, ostatnio: flowCRANE
LA
  • Rejestracja:około rok
  • Ostatnio:około rok
  • Postów:27
0

przecież w C++ masz zawarty cały C.

c++ dokłada tylko ekstra te class, czyli obiekty, operatory, itd.

natomiast pascal niewiele się różni od c - tylko troszkę więcej rzutowań wymaga i nie ma tych wszystkich ++, +=... :)

i finalnie:
c++ i obiektowy paskal (w tym typu delphi) - to jest full zgodne, pomijające drobne szczegóły,
np. te automatyczne destruktory:

GigaArray a(1000000000);

i potem ten obiekt sam się zwolni... bez potrzeby pisania w stylu: a.destroy, co chyba delphi wymaga.

edytowany 1x, ostatnio: Law
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
1
Law napisał(a):

c++ dokłada tylko ekstra te class, czyli obiekty, operatory, itd.

Nom, czyli wzięto za podstawę porządny język (trudny i z nie zawsze czytelną składnią) i zrobiono na niego kupę, jeszcze bardziej komplikując całość i ukrywając istotę za szeregiem abstrakcji.

natomiast pascal niewiele się różni od c - tylko troszkę więcej rzutowań wymaga i nie ma tych wszystkich ++, +=... :)

Różni się i to w baaardzo dużym stopniu, ale żeby to wiedzieć, trzeba znać Pascala. Poza tym, we Free Pascalu jest wsparcie operatorów +=, -=, *= i /=, więc kolejna bzdurka. Ba, Delphi od dawna wspiera sposób deklaracji stałych i zmiennych w stylu C, czyli wewnątrz dowolnego bloku kodu. Natomiast pozostałych różnic jest tak wiele, że szkoda nawet próbować je listować — oczywiście różnic dających Pascalom bardzo dużą przewagę nad C.

c++ i obiektowy paskal (w tym typu delphi) - to jest full zgodne, pomijające drobne szczegóły.

Tak, tyle że Pascale nie mają tak zawiłej i przekombinowanej składni, a także tak wielu UB jak C++. W Pascalach można wygodnie pisać wysokopoziomowo (tak jak w C++), ale też niskopoziomowo (tak jak w C), a mimo to nadal mieć wygodę, bezpieczeństwo i wysoką wydajność, praktycznie identyczną jak w C.

np. te automatyczne destruktory:

GigaArray a(1000000000);

i potem ten obiekt sam się zwolni... bez potrzeby pisania w stylu: a.destroy, co chyba delphi wymaga.

Macierze, w tym te o dynamicznym rozmiarze są zarządzane, więc nie wymagają ręcznej dealokacji.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 3x, ostatnio: flowCRANE
LA
  • Rejestracja:około rok
  • Ostatnio:około rok
  • Postów:27
1

kwestia gustu, a może przyzwyczajenia.

w każdym razie ja wolę c/c++, bo to jest bardziej elastyczne od pas tak czy siak;

i mogę przerobić dowolny kod z pas na C i odwrotnie.

edytowany 1x, ostatnio: Law
DA
  • Rejestracja:prawie 3 lata
  • Ostatnio:3 dni
  • Postów:84
0

Swoją drogą, tak z ciekawości czy ktoś pokusił się kiedyś, lub być może tworzy się obecnie w którymś z Pascalów jakiś minimalistyczny system operacyjny?

AU
Tak, github przeszukasz to znajdziesz czuję to w kościach, ja akurat w C pisałem i specjalne operacje procesora robisz wstawkami assemblera. Ale czy minimalistyczny to różnie raczej zawsze jest nigdy nie skończony bo jest bardzo dużo roboty do wykonania. Chodź pewnym osobą się udaje dość daleko zajść.
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0
Law napisał(a):

w każdym razie ja wolę c/c++, bo to jest bardziej elastyczne od pas tak czy siak;

Wytłumaczysz co konkretnie oznacza ta mistyczna elastyczność?

i mogę przerobić dowolny kod z pas na C i odwrotnie.

Dokładnie, w dodatku te języki mogą bez problemu ze sobą rozmawiać, bo ABI jest kompatybilne.


davout napisał(a):

Swoją drogą, tak z ciekawości czy ktoś pokusił się kiedyś, lub być może tworzy się obecnie w którymś z Pascalów jakiś minimalistyczny system operacyjny?

https://github.com/rezgui/fpos
https://wiki.freepascal.org/Operating_Systems_written_in_FPC

Prace chyba zostały ukończone, bo od 3 lat nie wprowadzano zmian. Ale nie znam tego projektu, więc to tyle.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 2x, ostatnio: flowCRANE
LA
  • Rejestracja:około rok
  • Ostatnio:około rok
  • Postów:27
2

w paskalu kod jest dłuższy zwykle, i jest ograniczone pole do działania na wskaźnikach.

np. nie można pisać tak:

p[17] = ...

gdzie p jest wskaźnikiem, do dowolnego typu, np.:
double *p ;

a w c tablice i wskaźniki są tak samo traktowane..

int t[10], *p;

p = t; // tak wolno

a potem:
p++ = 7;

w c jest ten operator ?:, co pozwala skracać kod...

x = (a > b) ? 7 : 9;

a w pas trzeba tu if użyć.

albo takie coś:
y = ((x > pi) ? sin : cos) (x);

i dalej: w pas nie ma #define, co znowu pozwala na lepsze - krótsze kodowanie w c...

w c++ są też te operatory przeładowane, destruktory, i kilka innych rzeczy - dlatego c++ jest lepszy od pas++ :)

flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
2
Law napisał(a):

np. nie można pisać tak:

p[17] = ...

gdzie p jest wskaźnikiem, do dowolnego typu, np.:
double *p ;

Nie wiem skąd bierzesz tego typu rewelacje, ale oczywiście, że można (https://ideone.com/33WYnI):

Kopiuj
var
  P: PSingle;
begin
  P[4] := 3.14; // modyfikacja
  Write(P[4]);  // odczyt
end.   

a w c tablice i wskaźniki są tak samo traktowane..

W Pascalu nie ma znaczenia czy ma się tablicę czy typowany pointer, wskaźnik może być używany jako tablica, czyli tak jak w C.

int t[10], *p;

p = t; // tak wolno

Fajna pułapka. Ale pomijając ten fakt, w Pascalu też tak można (https://ideone.com/tMyoeQ):

Kopiuj
var
  T: array [0..9] of Single;
  P: PSingle;
begin
  P := T;       // pozyskanie adresu tablicy
  P[4] := 3.14; // modyfikacja komórki
  Write(P[4]);  // odczyt z komórki
end.

a potem:
p++ = 7;

Pre- i post- inkrementacji i dekrementacji w Pascalu nie ma. Bardzo dobrze — mniej pułapek, większa czytelność i bezpieczeństwo. Gdyby te operatory były to i tak bym ich nie używał, bo nie przepadam za obfuskacją kodu.

w c jest ten operator ?:, co pozwala skracać kod...

x = (a > b) ? 7 : 9;

W Pascalu nie ma, a szkoda — korzystałbym w niektórych przypadkach. Ale zamiast tego jest funkcja IfThen, które pełni podobną rolę — z tą różnicą, że wykonuje pełną ewaluację wszystkich wejściowych argumentów, więc to nie to samo — to zwykła funkcja, nie operator.

albo takie coś:
y = ((x > pi) ? sin : cos) (x);

Kolejna abstrakcja, która tylko obfuskuje kod. Nie różni się to niczym od tego:

Kopiuj
y = x > pi ? sin(x) : cos(x);

ani od tego:

Kopiuj
y := ifthen(x > pi, sin(x), cos(x));

i dalej: w pas nie ma #define, co znowu pozwala na lepsze - krótsze kodowanie w c...

Oczywiście, że jest {$DEFINE}. Jeśli mowa o preprocesorze i makrach, bo tym właśnie są {$DEFINE}, to Free Pascal je wspiera, łącznie z zagnieżdżonymi makrami. Jednak Free Pascal nie posiada wsparcia parametryzowanych makr, aby dbać o czytelność i bezpieczeństwo kodu oraz o łatwość debugowania, dlatego nie da się robić w nim takiego spaghetti jak w C.

w c++ są też te operatory przeładowane, destruktory, i kilka innych rzeczy - dlatego c++ jest lepszy od pas++ :)

Przeładowywanie operatorów jest od dawna dostępne we Free Pascalu, destruktory również (WTF z tymi destruktorami?) i kilka innych rzeczy też — dlatego C/C++ wcale nie mają żadnej realnej przewagi nad współczesnymi Pascalami.


Jeśli chcesz podyskutować o różnicach pomiędzy C/C++ a Pascalem, to zanim wylistujesz kolejne bzdurki (czyli okłamiesz czytelników tego wątku), sugeruję najpierw poznać Pascala (głównie Free Pascala i Delphi), bo najwyraźniej nie masz za bardzo pojęcia o tym, czym jest współczesny Pascal, co wspiera i na co go stać. 😉

Poza tym, inteligentnych ludzi cechuje to, że jeśli czegoś nie wiedzą lub nie są pewni, to zadają pytania, zamiast stawiania (kłamliwych) twierdzeń. Jeśli nie wiesz czy coś jest wspierane w Pascalu, to zapytaj, a z chęcią podam ci szczegóły.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 10x, ostatnio: flowCRANE
LA
  • Rejestracja:około rok
  • Ostatnio:około rok
  • Postów:27
1

freepascal czy inne modyfikacje jadą wciąż w kierunku tego co c++ ma od początku.

po prostu paskal < c++ i tak pozostanie na zawsze.

Paskal jest zwykle wykładany jako ten pierwszy język programowania...
bo to jest podobne do naturalnego języka - angielskiego:

begin, for, repeat, go, ...

natomiast c jest dopiero potem nauczany - po opanowaniu pas, czyli tych intuicyjnych podstaw algorytmiki.

a dalej masz: c++ - to jest już ciężka abstrakcja,
i znacznie cięższa od tego co delphi ogarnia, czy inne obiektowe.

finalnie:
c++ jest nadal full użytecznym językiem programowania, i takim pozostanie na zawsze - bo jest zupełny, kompletny język,
w przeciwieństwie do pas, czy delphi - to zanika stopniowo, traci popularność.

Obecnie najpopularniejsze są chyba java, javascript, ale to są przecież klony c, a nie pas,
takie uproszczone wersje c++ - niedorobione.

Ada ma chyba podobną składnię do pas, albo np. emerald, itp... ale to jest margines - kto w tym programuje?

RD
Chciałem odpisać na te wszystkie bzdury ale po tym, że uważasz Java czy JavaScript za klony C, to nie ma sensu strzępić klawiatury i potęgować efektu cieplarnianego…
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0
Law napisał(a):

freepascal czy inne modyfikacje jadą wciąż w kierunku tego co c++ ma od początku.

Free Pascal stopniowo otrzymuje ficzery, które są przydatne, które pasują do specyfiki tego języka, a nie te, które są w C++ czy jakimkolwiek innym języku (i to bardzo często podkreślają deweloperzy FPC). Jedynym językiem, na którym Free Pascal się wzoruje, jest Delphi, bo ma być z nim kompatybilny.

Paskal jest zwykle wykładany jako ten pierwszy język programowania...

Właśnie dlatego, że nie wygląda jak składniowe wymiociny pokroju C++. Pascal jest prosty, czytelny i bezpieczny, dzięki czemu o wiele łatwiej się w nim programuje niż w C/C++. C++ jest po prostu fatalnym językiem, dlatego nie powinien być w ogóle brany pod uwagę, jeśli chodzi o naukę programowania, tym bardziej jako pierwszy poznawany język.

a dalej masz: c++ - to jest już ciężka abstrakcja,
i znacznie cięższa od tego co delphi ogarnia, czy inne obiektowe.

Nie wiem czy wiesz, ale słowo abstrakcja w przypadku programowania, ma negatywne znaczenie. Im więcej abstrakcji, tym gorzej, bo tym bardziej ukrywa się algorytmiczną istotę za składniowymi zawiłościami. Na tym polu Pascal od zawsze wygrywał z C/C++ i zawsze wygrywać będzie.

c++ jest nadal full użytecznym językiem programowania, i takim pozostanie na zawsze - bo jest zupełny, kompletny język,
w przeciwieństwie do pas, czy delphi - to zanika stopniowo, traci popularność.

Pascale tak samo są full użytecznymi językami programowania i takimi pozostaną na zawsze - bo są zupełnymi, kompletnymi językami, a do tego czytelnymi i bezpiecznymi w przeciwieństwie do C/C++.

A to że ich popularność jest niższa niż C/C++, nijak nie ujmuje im wartości. Choćbyś nie wiem jak bardzo starał się wykazać, że Pascal jest gorszy od C/C++, to nadal nie zmieni to faktu, że można w nich zaprogramować wszystko, w dodatku w sposób czytelny, bezpieczny i wydajny.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 2x, ostatnio: flowCRANE
Zobacz pozostałe 3 komentarze
flowCRANE
Wyjątki to nic innego jak klasyczna obsługa kodów błędów, tyle że w formie long jumpów i cukru składniowego. Nie dają praktycznie niczego, czego nie dałoby się ogarnąć obsługą kodów błędów (jak w Win32 API czy SDL), ale za to ukrywają realny przepływ sterowania i negatywnie odbijają się na wydajności. Kiedy masz funkcję, która zwraca kod błędu, to możesz łatwo go obsłużyć i zawsze wiesz kiedy i jak ten błąd obsłużyć, w dowolnym przypadku. Kod z wyjątkami jest abstrakcją, bo nigdy nie wiadomo czy wywoływana funkcja może rzucić wyjątkiem czy nie (dodać try except czy nie?).
RD
abstrakcja - pogląd lub twierdzenie oderwane od rzeczywistości - według SJP. Czyli abstrakcją jest twór ogólny, który jest oderwany od rzeczy - czyli implementacji. Zatem może to być SDL_CreateWindow które jak zauważyłeś wrappuje czy będzie to interface ISendFrame który ma implementacje PrinterTCPProvider oraz PrinterSerialProvider, natomiast klasa która obsługuje drukarkę jakiś PrinterDriver będzie miało obiekt implementujący ISendFrame oraz IFrameGenerator - separujemy używanie ich od implementacji oraz różne odpowiedzialności klas.
RD
To wszystko jest warstwa abstrakcji, która odrywa warstwy od siebie i od szczegółowej implementacji. Czy to będzie interfejs, klasa abstrakcyjna, wrapper czy konwencja czyli wołanie metod przez refleksje to nie ma znaczenia - to są technikalia. Natomiast cukier składniowy i kod, który jest nieczytelny jest cukrem i nieczytelnym kodem a nie abstrakcją. Równie dobrze, można powiedzieć, że używanie funkcji jest zbyteczną abstrakcją, podobnie jak pętle skoro istnieją skoki warunkowe. Kolekcje i tablice też są niepotrzebne skoro mamy arytmetykę wskaźników.
RD
Może nie używać żadnej warstwy abstrakcji a skonstruować strasznie powiązany między sobą kod, trudny w utrzymaniu i nieczytelny. De facto własnie abstrakcja powala utrzymać kod w czystości. Jeśli mam ISendFrame to o ile nie złamiesz kontraktu to możesz zmieniać cokolwiek w klasach implementujących i nie będzie to wpływało na działanie np generatora ramek. Ba - możesz nawet wymienić warstwę i to się dzieje i to codziennie. Akurat jeśli chodzi o drukarki to de facto implementacja zmienia się w zależności od konfiguracji stacji POS w przypadku o którym piszę.
RD
Co więcej każdy element powstaje niezależnie przez różnych programistów. Może po prostu mamy konflikt z definicją - ja opieram się o branżową definicje abstrakcji tak jak to jest w branży od lat.
SL
  • Rejestracja:około 7 lat
  • Ostatnio:około 7 godzin
  • Postów:902
1
furious programming napisał(a):

Programiści Delphi, pracujący nad rozwiązaniami komercyjnymi, rozwiązują 100% problemów bez GC, bo język go nie zapewnia. GC jest potrzebny tym, którzy nie potrafią programować i potrzebują wymówek, aby móc spojrzeć w lustro.

Zapraszam do jakiegoś złożonego kodu i dodanie nowego ficzera tak, żeby niczego nie popsuć. Można to zrobić bez gc np. używając shared_ptr z C++, ale powoduje to narzut wydajnościowy. Nie bez powodu programiści chroma używają gc https://chromium.googlesource.com/v8/v8/+/main/include/cppgc/README.md . Z tego co pamiętam to największym problelem było ogarnięcie kto ma odpowiadać za cykl życia alokacji, co w tak złożonym projekcie jak przeglądarka może być trudne z uwagi na ogromną skalę projektu i wiele modułów, które dzielą między sobą ogromne ilości danych

Nie uważam, że gc jest koniecznością, ale negowanie przydatności w każdym zastosowaniu jest IMO dziecinadą.

flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 7 godzin
  • Lokalizacja:Tuchów
  • Postów:12175
0
slsy napisał(a):

Można to zrobić bez gc np. używając shared_ptr z C++, ale powoduje to narzut wydajnościowy.

A no można, ale tak czy siak jest to forma GC, ułatwiająca implementację, kosztem wydajności.

Nie bez powodu programiści chroma używają gc https://chromium.googlesource.com/v8/v8/+/main/include/cppgc/README.md .

I nie bez powodu ten silnik ssie.

Z tego co pamiętam to największym problelem było ogarnięcie kto ma odpowiadać za cykl życia alokacji, co w tak złożonym projekcie jak przeglądarka może być trudne z uwagi na ogromną skalę projektu i wiele modułów, które dzielą między sobą ogromne ilości danych

Każda alokacja wykonywana jest ze ściśle określonego powodu, jej czas życia również jest ściśle określony. Jeśli nie wiadomo kiedy i w jakich okolicznościach ma zostać zwolniona, to problemem nie jest sama alokacja, a raczej architektura. IMO GC w takim przypadku jest tylko plastrem.

To że projekt jest wielkoskalowy, wcale nie oznacza, że nie da się panować nad pamięcią. Chromium to pryszcz przy takich molochach jak kernel Linuksa czy Windowsa, a te z GC nie korzystały, bo to czyste C. To że coś jest trudne, nie oznacza, że jest niemożliwe, a używanie GC, bo tak jest łatwiej (kosztem wydajności), jest IMO nienajlepszym rozwiązaniem.

Nie uważam, że gc jest koniecznością, ale negowanie przydatności w każdym zastosowaniu jest IMO dziecinadą.

Przecież to był bait, w dodatku nieprecyzyjny, więc wyluzuj.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
LA
  • Rejestracja:około rok
  • Ostatnio:około rok
  • Postów:27
1

ale takie coś jest chyba nielegalne w paskalu (przynajmniej było):

PDouble p; // czy dowolny wskaźnik, ale z wyjątkiem Pchar :)

i teraz robimy:

p[6] = 80.8;

i nie wolno tego robić, bo to jest przecież sprzeczne z tym 'safe-memory-code'.

kontrola zakresów nie może tu być zastosowana, więc nic nie uratuje gdy to źle policzymy.

albo takie coś:
p[-19] = 77.7;

i co - wolno tak?

w c wolno, bo to jest niskopoziomowy język, czyli z góry zakładamy, że programer wie co robi.

O ile pamiętam ja omijałem te ograniczenia jakimiś makabrycznymi sposobami, np. tak:

p = PDouble((integer(p) + 24));

czyli rzutowaniami.

ewentualne:

inc(Pchar(p), 8*7);

i teraz mam ten p przesunięty, bo incrementacja Pchar była dozwolona (w Borlandzie przynajmniej);
a ta pierwsza wersja jest nie do zatrzymania - to zawsze przejdzie;
no ale to jest kicha...

legalne w pas jest tylko:
p^ := 40.4;

a czy pójdzie: p[0] := ... chyba nie powinno - trzeba się trzymać zasad.
p[7] nigdy nie powinien przejść - to jest kod w stylu c, czyli wysoce niebezpieczny! ;)

a i dalej - mogę w nieskończoność:

  1. w pas nie ma pól bitowych - takie rekordy w c w których mamy zmienne o rozmiarach w bitach
  2. nie ma tamplete
  3. nie ma referencji w kodzie
  4. nie deklaracji parametrów w kodzie, w stylu:
    for(float x = 0; ...

itd. itp...

edytowany 1x, ostatnio: Law

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.