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ć.
Edytor poziomów Montezuma's Revenge Lew Daney udostępnił narzędzie pozwalające na tworzenie własnych piramid w kultowej grze na Atari.
Fujisan 1.1.5 Fujisan 1.1.5 przynosi poprawki w obsłudze FujiNet, usprawnienia XEX oraz nowe układy klawiatury.
Jutro start 24h Compo Już jutro poznamy temat nowej edycji 24h Compo.
DitherLab od Amaroka na Atari XL/XE Nowe narzędzie do ditheringu dla 8-bitowych komputerów Atari z minimum 128 kB RAM od Amaroka.
NeoDEGAS v 1.0.3 Nowoczesny edytor obrazów w formacie PI1.
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.060 sekund, wykonano 24 zapytań