Koniec żartów z Delphi - White House poleca

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.

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.

1

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

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

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).

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.

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.

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.

0

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

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.

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.

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?

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

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. 🤣

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.

0

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

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…).

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.

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.

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.

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.

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?

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.

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++ :)

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):

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):

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:

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

ani od tego:

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.

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?

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.

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ą.

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.

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...

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