Dziękuję za wyczerpujące odpowiedzi i jednocześnie chylę czoło.
mnogość stylów programowania jest pożądaną cechą i oczywistą konsekwencją wieloparadygmatowości języka
Zupełnie jak w Perlu, popieram. :)
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
SQL na Atari 8-bit Nowe narzędzia pozwalają na obsługę baz danych SQL na Atari 8-bit przy użyciu urządzenia FujiNet.
Altirra 4.50 test4 Nowa wersja testowa emulatora Altirra przynosi poprawki interfejsu oraz wsparcie dla środowiska Wine.
8. edycja Atari Homebrew Awards Ruszyło głosowanie na najlepsze gry wydane w 2025 roku na konsole i komputery Atari.
AspeQt-2K26 Nowoczesny fork klasycznego AspeQt wspierający Qt 6 i TNFS
Fujisan 1.1.3 Fujisan 1.1.3 to nowa odsłona emulatora opartego na libatari800, skupiona na integracji z FujiNet.
atari.area forum » Posty przez Fox
Dziękuję za wyczerpujące odpowiedzi i jednocześnie chylę czoło.
mnogość stylów programowania jest pożądaną cechą i oczywistą konsekwencją wieloparadygmatowości języka
Zupełnie jak w Perlu, popieram. :)
Nawiązując do niedoskonałości naszych cross-assemblerów proponuję przyjrzeć się, jak sobie radzą poważne komisje standaryzacyjne języków programowania, a nuż czegoś się nauczymy.
@epi: Proszę bardzo. Nie wiem jak MADS, ale C++ ma z poprzednikiem dokładnie tyle kompatybilności ile trzeba oraz nie zawiera on żadnych nie do końca przemyślanych ficzerów dodanych z powodu braku porozumienia wśród tych, którym na nich zależało, co z kolei implikuje, że nie istnieją żadne rzekome nieoczywiste szczególne przypadki na styku tychże nieistniejących ficzerów. Nie ma również żadnych śladów nieskoordynowanego rozwoju o czym łatwo się przekonać analizując tryb pracy komisji standaryzacyjnej, a mnogość stylów programowania jest pożądaną cechą i oczywistą konsekwencją wieloparadygmatowości języka.
To oczywiście subiektywna opinia i jeżeli jednak uważasz inaczej, to fajnie jakbyś podał jakieś przykłady, do których można byłoby się odnieść, ale to już chyba w jakimś innym wątku, bo głupio tu tak perfidnie offtopikować.
Jestem laikiem w temacie C++, poproszę o odpowiedzi na pytania:
1. Którą implementację byś wybrał i dlaczego:
a. void foo(Bar *bar) { /* kod */ }
b. void foo(Bar &bar) { /* kod */ }
2. Potrzebujesz obsługi błędów w przenośnym kodzie. Użyjesz:
a. wyjątków
b. kodów błędów
c. czegoś innego
Uzasadnij odpowiedź.
3. Operujesz łańcuchami znaków. Użyjesz:
a. std::string
b. const char *
c. LPCTSTR
d. klasy z ulubionego frameworku (jakiego?)
e. własnej implementacji klasy string
4. Operatory logiczne zwracają:
a. bool
b. int
5. Implementujesz przenośną bibliotekę. Użyjesz:
a. C++
b. C
6. Duży projekt w C++ może wymagać obchodzenia (workarounds) błędów kompilatorów:
a. prawda
b. kompletna bzdura
7. Instrukcja C w rodzaju: char *s = malloc(size);
a. jest bardzo często spotykana, więc C++ utrzymało kompatybilność
b. stanowi błąd w C++, bo nie trzeba kompatybilności (dlaczego?). Uzasadnij wyższość składni wymaganej przez C++.
8.
a. #include <iostream.h>
b. #include <iostream>
9. Dziedziczenie wielobazowe:
a. Jest konstrukcją nowoczesnych języków programowania
b. Zostało zaimplementowane dla zgodności z C
c. Jest nazywane "goto programowania obiektowego"
10. this jest:
a. referencją
b. wskaźnikiem
Uzasadnij decyzję projektową.
11. Program
#include <iostream>
using namespace std;
class A
{
public:
int x;
};
static void printArray(const A *tab, int len)
{
for (int i = 0; i < len; i++)
cout << tab[i].x << endl;
}
class B : public A
{
public:
char *p;
};
int main()
{
B tab[3];
tab[0].x = 1;
tab[1].x = 2;
tab[2].x = 3;
printArray(tab, 3);
return 0;
}a. wypisze liczby 1,2,3
b. powoduje błąd kompilacji
c. kompiluje się z ostrzeżeniem
d. inna odpowiedź (opis)
12. Visual C++ 2010 przy kompilacji programu:
#include <iostream>
int main()
{
return 0;
}z opcją /Wall:
a. nie wyświetli ostrzeżeń podczas kompilacji
b. wyświetli ostrzeżenia (dlaczego?)
Aby perfidnie nie offtopikować przeniosłem tu.
laoo: Trafia do mnie Twoja argumentacja. O "inx #0" pisałem w czasie przeszłym i obecnie już bym tak nie napisał. Jest to głównie spowodowane odzwyczajeniem od kodu 6502 oraz stosowaniem edytorów z ograniczonymi możliwościami kolorowania składni.
xxl: Skoro, jak sam napisałeś, "nie istnieje rozkaz inx z argumentem", to wynika z tego, że $00 nie jest argumentem inx. W kwestii wiedzy, zapoznaj się ze składnią QA oraz historią kompilatorów (ze szczególnym uwzględnieniem kompilatorów, które znajdowały literówki).
Widzę tylko narzekania w stylu "nie rozumiem X, pomyliłem się przy Y, więc to jest wina autora asemblera". Nikt Wam nie każe używać cross-assemblera mojego ani Tebego. Wybierzcie taki asembler, którego składnię jesteście w stanie pojąć. Jestem bardzo zadowolony ze składni xasm - to, czego mi brakowało w QA, dodałem bez łamania zgodności wstecz. Nie podobała mi się tylko ewidentnie dyrektywa opt, ale to zwykle jedna linijka w źródle.
Wiele razy umyślnie pisałem kod w stylu:
ldx #29
sta:rpl ^00,x-
inx #0gdzie #0 to oczywiście komentarz. Nigdy nie miałem z tym problemu - przecież wiem, jak działa inx.
mono napisał/a:Hmmm. A co myślicie o czymś takim:?
lda # ldx # ldy #Co powinno się zdarzyć?
zdarzy się ZERO
No to już jest folklor madsowy.
ta "spojna regula" z 1991 zawiera i wyjatki i bledy:
przyklad wyjatku:
[etykieta] rozkaz [wymagane argumenty ][komentarz]
[wymagane argumety ] w rozkach w trybie adresowania akumulatora sa wymagane tylko jesli w linii jest pole komentarza :-) niezla kicha.
przyklad bledu:
z powyzszego powinno byc
[etykieta] rozkaz [wymagane argumenty] [komentarz]
to zalatwia cala sprawe. w rozkazach bezargumetowych i tych gdzie argument mozna pominac przed komentarzem dwa odstepy (spacje/taby - nieistotne; z tego co pamietam tak jest w mac65). oczywiscie lepszym rozwiazaniem jest srednik.
To wcale nie są reguły z 1991. Ani w QA ani w xasm nie ma wyjątku dla adresowania akumulatora - musi być "@". Nie ma też uzależniania interpretacji od tego, czy jest jedna, dwie czy pięć spacji.
Offtopic albo i nie: http://faqs.cs.uu.nl/na-dir/atari-8-bit/faq.html (szukamy "O.S. Authors")
mads kompiluje cos takiego:
pha $00
pla $00
Quick Assembler też.
Według tych kryteriów 6809 i Z80 są 16-bitowe, a 6309 i 68000 32-bitowe.
Na oko możliwości zbliżone do 65816. Wolałbym 65816. :)
Zajebiste? Takie rzeczy to oglądałem wiele razy w Audacity.
Jak obetniesz 8-bitowego sampla do 4 bitów będzie szumić - była o tym mowa.
Dobrze zrobiony sampel 4-bit będzie ładnie grał na 15556 Hz - tylko policz sobie, ile pamięci zajmie taki parusekundowy. :)
Często spotyka się dwukrotnie mniejszą częstotliwość, ale IMHO nadaje się ona do czegoś, co i tak szumi (perkusja).
epi: zapraszam. :)
Co do cen, w poniedziałki w Dekancie piwo było tańsze (nie wiem, czy to aktualne). Zawsze też możemy zmienić lokal. :)
14 zł za litr piwa to nie jest dużo jak na Warszawę, w dodatku centrum.
Ew. możemy kupić piwo w Biedronce i wypić pod sklepem. ;)
E no wielkanocny nie. Proponuję 2 kwietnia od 18 Dekanta.
Widzę pięcioro potencjalnych kandydatów na alternatywny termin - poniedziałek. :)
A sprzęt to nie Amiga tylko pecet.
"This app is incompatible with your phone" :( - Xperia X10 Mini Pro z andkiem 2.1.
Adam: Od lat tysiące SAPów mają określony TIME i tylko dla części z nich było to robione ręcznie. Dla SIDów też jest baza z ich długościami.
Ad.2. W trakcie realizacji rozkazu adr: STA WSYNC na magistrali adresowej pojawiają się kolejno wartości adr, adr+1, adr+2, a na magistrali danych kolejno $8D, $0A, $D4 Czasem przetykane wartościami wysyłanymi i odczytywanymi przez ANTIC :)
Wyraziłem się nieprecyzyjnie - co jest na szynach po wykonaniu STA WSYNC, gdy 6502 jest wstrzymany, a ANTIC nie pobiera danych?
INS - odejmowanie jest z pożyczką
SHA - tak jak pisałem, opis jest błędny - nie ma magicznej stałej 7, tylko starszy bajt adresu + 1 - widać, że ktoś testował tylko na szóstej stronie
Nieprawda. SAPy mają teraz określony czas odtwarzania i ASAP w postaci wtyczek do kilkunastu różnych odtwarzaczy to obsługuje.
atari.area forum » Posty przez Fox
Wygenerowano w 0.065 sekund, wykonano 24 zapytań