On Tue, 2 May 2017 15:23:41 +0200, "HF5BS" <h...@...pl> wrote:
> ułatwia jawna deklaracja w nazwie, np. a=zmienna pojedynczej
precyzji,
> b!=zmienna podwójnej precyzji, c#=zmienna całkowita, d$=zmienna
łańcuchowa.


To można załatwić tzw. węgierską notacją (lpszTitle, cbInput czy
lplphacbFarFarAway).

Ale jest uważane - obecnie - za bardzo szkodliwe. Dlaczego? Gdy np.
masz program w pojedynczej precyzji i chcesz zmienić na podwójną...
musisz zmienić nazwy zmiennym. Podobnie gdy np. jakiś durnowaty
parametr był double, a ma być wskaźnikiem do double to czeka cię
męczenie fParam na pfParam. Jeżeli jeszcze wpadniesz na pomysł ze to
ma być jednak lpfParam to znowu zmieniasz.

A w 90% i tak nie musisz wiedzieć czym to param jest. Na przykład:

param = GetParam()
SetParam(1,param)
SetParam(2,param)

No jest jakieś set/get, ale nie ma potrzeby zamęczać się medytowaniem
czym jest param - int, float, tablica czy plik, jakieś coś, może
obiekt. Nota bene coś takiego jest całkiem poprawnym kodem w
Phytonie...

do góry

On Tue, 2 May 2017 15:23:41 +0200, "HF5BS" <h...@...pl> wrote:
> po prostu potrzeba więcej dyscypliny. Długo "bawiłem się" dialektem
z C64
> (taki sam dialekt, jak VIC-20), wzięty zresztą od M$,

Chyba starszy niż MS, bo na początku lat 70-tych był już taki, a MS
nie było przed 1975. BASICA i QBASIC były nieco inne niż to co miał
C64 zeszyte w ROM.

QBASIC da się odpalić na współczesnych Windows. MS miał taką paczkę o
nazwie OLDDOS (czy jakoś tak) - uzupełniała WIN95 o QBasic, subst,
join itp. Można pobrać gdzieś z serwera MS.

C64 to niegłupi Simons Basic. Hires i auto. Tyle że wtedy już był
normalny Fortran 77 na klonach PC XT. A to oznaczało że programy z
kart dziurkowanych można było puszczać zamiast na Odrze to na PC. Na
przykład NAP2.

do góry

On Tue, 02 May 2017 18:41:48 +0200, slawek <f...@f...com> wrote:
> męczenie fParam na pfParam

W zasadzie powinno być lfParam i plfParam.

Czyli jeszcze trudniej to przeczytać na głos.

do góry

Użytkownik "slawek" <f...@f...com> napisał w wiadomości
news:almarsoft.2769688524361255343@news.v.pl...
> On Tue, 2 May 2017 15:23:41 +0200, "HF5BS" <h...@...pl> wrote:
>> news:almarsoft.6054727570073437054@news.v.pl...
>
>
>> Dla dodania 2+2, komenty są IMO zbędne, [...]
>
> Niekoniecznie, np.
>
> i = 2;
> j = 2;
> k = i + j; /* może nie być 4, bo j jest volatile i modyfikowane
> równoległego wątku */

Aberracja praw matematycznych? Na władzę (języka programowania, itd) nie
poradzę, ale matematyka mówi jasno. I to ona jest dla mnie wyznacznikiem.
Aha... z równoległego wątku? Cóż, matmie to nie przeczy. Zresztą nawet w
C64, jakiś to problem napisać małego rezydenta, który mi przechwyci i
podmieni wartość zmiennej? Wcisnąć w przerwanie klawiatury, mało kto
zauważy, że jego obsługa ciut dłużej trwa.

>
> Albo coś takiego:
>
> a = 200.0;
> b = 200.0;
> if (a + b == 400.0) ...
> else...

A bo to raz się takie coś stosowało? Zadziwiająco często jest potrzebne.
Czasem łatwiej tak, niż dymać się z procedurami, podprogramami, itd. A
czasami ułatwia ich konstrukcję. Matematyka, to matematyka. Inna sprawa, co
sobie programista zaprogramuje, niechby nawet prawdziwość równania
(inspiruje mnie pewien dowcip) żaba+termometr=niedziela.
PS Odejmij 5.2-5, w C64, co dostaniesz? :) Ale to już nie jest wina
matematyki.
Tu masz emulator http://codeazur.com.br/stuff/fc64_final/ Jedyny, który
chciał mi bez javy ruszyć pod starą Operą. Uwaga na kursor i klawiaturę
(łatwo uruchomić nie to, co się chce, do tego trzeba pamiętać, gdzie na
klawie C64 leżą niektóre znaki). Sprawdziłem, efekt występuje.

Nie gniewaj się, że tak to może niecodziennie widzę, muszę jakoś odróżnić,
czy rządzą tym prawa matematyczne, czy języka programowania.

--
"Jeśli przyjmiesz do siebie zabiedzonego psa i sprawisz,
że zacznie mu się dobrze powodzić - nie ugryzie cię.
Na tym polega zasadnicza różnica między psem a człowiekiem"
(C) Mark Twain

do góry

Użytkownik "slawek" <f...@f...com> napisał w wiadomości
news:almarsoft.2528235484099296367@news.v.pl...
> On Tue, 2 May 2017 15:23:41 +0200, "HF5BS" <h...@...pl> wrote:
>> ułatwia jawna deklaracja w nazwie, np. a=zmienna pojedynczej
> precyzji,
>> b!=zmienna podwójnej precyzji, c#=zmienna całkowita, d$=zmienna
> łańcuchowa.
>
>
> To można załatwić tzw. węgierską notacją (lpszTitle, cbInput czy
> lplphacbFarFarAway).
>
> Ale jest uważane - obecnie - za bardzo szkodliwe. Dlaczego? Gdy np. masz
> program w pojedynczej precyzji i chcesz zmienić na podwójną... musisz
> zmienić nazwy zmiennym. Podobnie gdy np. jakiś durnowaty

Raczej staram się to przewidzieć i od początku zadeklarować/użyć zmiennych w
potrzebnej precyzji.

> parametr był double, a ma być wskaźnikiem do double to czeka cię męczenie
> fParam na pfParam. Jeżeli jeszcze wpadniesz na pomysł ze to ma być jednak
> lpfParam to znowu zmieniasz.

No, czasem się zdarzy obsuwa z deklaracją/użyciem rodzaju, a czasem, bywa,
kompilator daje dupy, gdy z jakiegoś powodu zajdzie potrzeba np. dodania
liczny całkowitej, do podwójnej precyzji, bywa, że nagle się kładzie i tak
leży, albo daje wyniki z tejże dupy wyjęte. A czasami wszystko idzie jak
należy. Mniejsza o powód takiej mieszanki, ale czasem to upraszcza. Kiedyś
częściej, dziś jakoś mi cierpliwości do tego nie styka.

>
> A w 90% i tak nie musisz wiedzieć czym to param jest. Na przykład:
>
> param = GetParam()
> SetParam(1,param)
> SetParam(2,param)
>
> No jest jakieś set/get, ale nie ma potrzeby zamęczać się medytowaniem czym
> jest param - int, float, tablica czy plik, jakieś coś, może obiekt. Nota
> bene coś takiego jest całkiem poprawnym kodem w Phytonie...

Faktycznie, nie kojarzę tego obecnie (nie zajmowałem się, choć ciągnie mnie
do tego; dla mnie zawsze najgorsze jest to, że jak zaczynam czytać o takich
rzeczach, to nie tak rzadko dwa różne źródła, różnie to traktują, a nie chcę
sobie wdrukować złego wzorca), ale, jeśli to trzyma jakieś zasady,
przewidywalne (o ile kompilator znów tylca nie nadstawi) i dające wyniki
(oczywiście, prawidłowe wyniki), to... to ja się zgadzam. Choćby to się
opierało w środku o armię leprikonów z kolorową tęczą (nie mylić z symboliką
LGBT, miałem na myśli taką fizyczną tęczę, albo taką z opowieści o garncu
złota u podstaw) w zestawieniu.
Dobra, zmykam, latają fronty atmosferyczne i jestem jakiś ścięty ostatnio.

--
"Jeśli przyjmiesz do siebie zabiedzonego psa i sprawisz,
że zacznie mu się dobrze powodzić - nie ugryzie cię.
Na tym polega zasadnicza różnica między psem a człowiekiem"
(C) Mark Twain

do góry

Użytkownik "slawek" <f...@f...com> napisał w wiadomości
news:almarsoft.24686994549888747@news.v.pl...
> On Tue, 2 May 2017 15:23:41 +0200, "HF5BS" <h...@...pl> wrote:
>> po prostu potrzeba więcej dyscypliny. Długo "bawiłem się" dialektem
> z C64
>> (taki sam dialekt, jak VIC-20), wzięty zresztą od M$,
>
> Chyba starszy niż MS, bo na początku lat 70-tych był już taki, a MS nie
> było przed 1975. BASICA i QBASIC były nieco inne niż to co miał C64
> zeszyte w ROM.

Ale składnia jest bardzo podobna. Oczywście, podstawowego zestawu, bo
wspomniane dialekty, wobec prymitywnego Basic 2.0 w Komodzie, są bardzo
rozbudowane. A tych już w C64 nie ma.

>
> QBASIC da się odpalić na współczesnych Windows. MS miał taką paczkę o

I często to robię na XP - działa bardzo ładnie. Choć ja staram się używać
QB64 (są wersje 32 i 64), tylko muszę rozpracować problem, że liczba w
okolicach 2^24, przy permamentnym dodawaniu +1, nagle przestaje rosnąć i nie
wyrzuca błędu. Co mi wręcz uniemożliwiło napisanie pewnego programu, a
QBasic ma z kolei inny problem - działa ślicznie, zapisałem 26 GB do pliku
(oczywiście, ćwiczebnie, zawsze najpierw sprawdzam, nauczony smutnymi
doświadczeniami, czy mi program nie da rzyci, w najmniej odpowiednim
momencie). No, zapisało się, a teraz, Waść, zamknij plik. Powodzen ia, ślepa
Gienia, kup se trąbk...Aj, to nie teraz... cholera, śpiący jestem...

> nazwie OLDDOS (czy jakoś tak) - uzupełniała WIN95 o QBasic, subst, join
> itp. Można pobrać gdzieś z serwera MS.

W98 miał to już chyba na pokładzie. Nie pamiętam, czy nie miał tego również
NT4, ale nawet jeśli nie (dawno już nie używam, ale postawić bez problemu
dam radę), wiem, że w XP musiałem dogrywać, co nie było problemem, bo w
necie znajduje się to chyba szybciej, niż o gołych babach.

>
> C64 to niegłupi Simons Basic. Hires i auto. Tyle że wtedy już był

Simons - a jakże! Choć nie miałem okazji szerzej użyć (Wówczas nie było
jeszcze netu, z którego bym to ściągnął). Natomiast chwalę sobie BASIC 7.0 z
C128 D (zwany żartobliwie Diesel), ma bardzo cenną rzecz - rozdzieloną
pamięć programu i zmiennych liczbowych, od pamięci łańcuchów, co umożliwia
sortowanie nawet bardzo dużych i skomplikowanych, jak na Komodę, baz, bo
C64, ze wszystkim (program, łańcuchy, zmienne, musi wyrobić się w 38 kB, a
na C128 mam na to aż 122 kB, bankowanie następuje w locie. Lepiej też sobie
radzi z natłokiem zagłębionych GOSUB. Ale i tu Commodore zaliczył obsuwę,
IMHO raczej niewybaczalną - na stronie zerowej, jest duża część ważnych
wektorów i zmiennych systemowych. Między C64 i C128, o 2 bajty w bok, są
przesunięte lokalizacje większości z nich (a nie ma tej obsuwy między C64 i
VIC20), co utrudnia napisanie uniwersalnego programu, który sięgałby trochę
głębiej w system, celem np. dopieszczenia działania niektórych programów
(np. nie wiem teraz, czy równie łatwo bym napisał oparty o dynamiczną
klawiaturę wczytywacz programów listingów ASCII)

> normalny Fortran 77 na klonach PC XT. A to oznaczało że programy z kart
> dziurkowanych można było puszczać zamiast na Odrze to na PC. Na przykład
> NAP2.

Ale musiałeś mieć chyba czytnik? Bo same z kart raczej nie spłynęły...
BTW. Tak na szybko z gugla...
https://archive.org/details/NevadaFortranfortheCommo
dore64 :) Ale języka
poszukam już z rana... zresztą... i tak na razie nie chcę szerzej w to
włazić.
I w ogóle https://www.lyonlabs.org/commodore/onrequest/collect
ions.html Nie
muszę chyba oznajmiać, ze to zaledwie garstka? :)

Dobra, na razie, do następnych...

--
"Jeśli przyjmiesz do siebie zabiedzonego psa i sprawisz,
że zacznie mu się dobrze powodzić - nie ugryzie cię.
Na tym polega zasadnicza różnica między psem a człowiekiem"
(C) Mark Twain

do góry

On Wed, 3 May 2017 02:34:37 +0200, "HF5BS" <h...@...pl> wrote:
> Aha... z równoległego wątku?

I po to są komentarze. Bez komentarza fragment w którym dodaje się
a+b wygląda na nudny, wręcz niepotrzebny. Komentarz zwraca uwagę na
kontekst i ważność komentowanego fragmentu.

Nota bene, MS zdarzyło się nie przywracać stanu FPU przy
przełączeniach pomiędzy zadaniami. Na szczęście natychmiast był
patch.

do góry

On Wed, 3 May 2017 02:47:26 +0200, "HF5BS" <h...@...pl> wrote:
> Raczej staram się to przewidzieć

Niby można. Gorzej gdy program pisze trzech lub więcej ludzi. Albo
gdy coś było pisane dla double, a ma działać potem z uchwytami do
bitmap. Co? Np. jakieś sortowanie czy wyszukiwanie. Zwykle 90% kodu
nie obchodzi co tam jest, patrz szablony w C++.

do góry

On Wed, 3 May 2017 03:29:15 +0200, "HF5BS" <h...@...pl> wrote:
> QBasic ma z kolei inny problem - działa ślicznie, zapisałem 26 GB
do pliku
> (oczywiście, ćwiczebnie, zawsze najpierw sprawdzam, nauczony
smutnymi
> doświadczeniami, czy mi program nie da rzyci, w najmniej
odpowiednim
> momencie). No, zapisało się, a teraz, Waść, zamknij plik. Powodzen
ia, ślepa
> Gienia, kup se trąbk...Aj, to nie teraz... cholera,

Hardcore to kill program (przez odłączenie zasilanie też można) i
puszczanie potem chkdsk do fixacji dysku. Na 95% znajdzie i odzyska
26 GB plik. I to będzie to.

do góry

On Wed, 3 May 2017 03:29:15 +0200, "HF5BS" <h...@...pl> wrote:
> Ale musiałeś mieć chyba czytnik? Bo same z kart raczej nie
spłynęły...

Napęd taśm półcalowych dla PC. To do danych.

A programy? Przepisanie paru tysięcy linijek to nie jest aż tak
wielki problem. Być może niektóre były przepompowne przez port
szeregowy: coś elektrycznie zgodnego było jeżeli nie w Odrze to w
PDP11, w 8-bitowcach takich jak C64, Atari itp.

Internetu nie było. Ale dyskietki były. Chyba nawet C64 dawał radę
zapisywać w FS FAT. Z drugiej strony nie było ograniczeń prawnych i
wirusów, a to stwarzało możliwości których obecnie nie ma.

do góry