Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Posty przez epi
Spartan 6, to na pewno nie Atari. Ciekawe, że 65c816 się w nim nie zmieścił. :)
FT232RL jest na tyle dobry że nie ma sensu się bawić pozostałymi. :)
A tu właściwe forum: http://forum.php.pl/
Spieler
eins
los!
To na ramcarcie. :)
Kompatybilność z C jest oczywista – aby korzystać z bazy bibliotek napisanych w C, które kompilują się po kosmetycznych poprawkach / uściśleniach. Mógłbyś podać jednak kilka konkretów tych dziwactw? Nie twierdze, że C ich nie miał, ale np.
Uściślenia w bibliotekach napisanych w C na pewno im nie zaszkodziły, natomiast z argumentem odnośnie korzystania z bibliotek napisanych w C nie mogę się zgodzić. Inne języki nie mają z tym problemu, mimo że składniowo od C są bardziej odległe. Jak to możliwe? Łatwiej chyba jest skompilować kod w C kompilatorem C i przekazać zadanie połączenia linkerowi.
Wśród innych dziwactw wymieniłbym m.in. daleko posuniętą wymienność pojęć tablicy i wskaźnika, ułatwiającą generowanie niewykrywalnych błędów, jak ten zaproponowany przez Foxa. Wymieniłbym również składnię deklaracji, której niezgodności z intuicją dowiedli już jej autorzy, pisząc translator na język angielski. :)
nie rozumiem uwagi o powielaniu tekstu w nagłówkach? Chciałbyś żeby C++ porozumiewał się pomiędzy modułami jak C# - bez includów? To chyba inna para kaloszy nie możliwa do sensownego zaimplementowania.
Tak, chciałbym i mam to w D, dzięki czemu nie muszę uwzględniać prywatnych składowych w publicznym interfejsie ani chować ich za pImpl, jak również nie muszę się martwić, czy któryś z dołączanych nagłówków jest wrażliwy na to, co było wcześniej w dołączającym kodzie. No i nade wszystko nie muszę się pisać i utrzymywać powielonego tekstu.
Nie za bardzo czuję obiekcje to std::vector. Rozumiem, że boisz się pomieszania iteratorów, ale ja tu nie widzę żadnego problemu. Jak piszesz w C to też nie masz pewności, że dwa wskaźniki wskazują na tę samą tablicę, ale w przypadku vectora tak źle nie jest.
Jak piszę w C to nie mam tej pewności, ale C++ jest ponoć lepszy. :)
Np. w microsoftowej implementacji STLa można włączyć feature „checked iterators”, dzięki któremu operacje na iteratorach dokonują dodatkowych sprawdzeń czy dotyczą tego samego kontenera itd. Dzięki niej spokojnie wykryjesz takie błędy, a najlepsze jest to, że to jest opcja, którą w każdej chwili możesz wyłączyć i cieszyć się pełną wydajnością równoważną operacjom na wskaźnikach bez żadnego ukrytego sprawdzania zakresów jak w C# czy w Javie
Implementacja microsoftowa jest, jak rozumiem, poza standardem, ale to już coś. Przyjrzę się, jak to wygląda w implementacjach STLa, których mam szansę użyć prędzej niż tej z MS.
Uwagi do iostream niestety nie rozumiem. Wyjaśnij proszę.
Nie podoba mi się, że formatowane wyjście przeplata formatowanie z danymi do wyświetlenia oraz składnia formatowania jest rozwlekła. Nie podoba mi się również, że obiekt reprezentujący standardowe wyjście przechowuje stan definiujący formatowanie i nie zawsze mam kontrolę nad tym, w jakim stanie zostawi go kod, który wywołuję.
W nowszych rozwiązaniach to podejście nie wygląda na zbyt chętnie powielane, co moim zdaniem jest argumentem za tym, że nie było ono dobrze przemyślane.
Biblioteka C jest dla kompatybilności, jakbyś chciał skompilować kod w C. Nikt nie każe Ci jej używać, bo powszechnie wiadomo, że biblioteka C++ jest lepsza ;)
No właśnie kiedy chciałbym jej użyć, ponieważ w niektórych sytuacjach znajduję jej rozwiązania wygodniejszymi, to cały czas czuję nad sobą bat "biblioteka C to zło". ;)
Natomiast chcąc skompilować kod w C, użyję kompilatora C.
iostream i wyjątki: nie zgodzę się. Operacje na strumieniach są naturalnie narażone na niepowodzenia (użytkownik podał literkę, a chciałeś cyfre, plik się skończył itd.).
Miałem na myśli nieco tylko poważniejsze problemy, jak urwany kabel czy zniknięcie karty pamięci, na które normalnie nie jesteś przygotowany i zwykle rozwiązanie w postaci zwinięcia stosu byłoby najwygodniejsze. Na szczęście jednak byłem niedouczony – doczytałem sobie, że mogę już wybrać (co się chwali), czy chcę być obrzucony wyjątkiem. Niestety nieopatrznie upaprałem sobie spodnie grząskim gruntem. ;)
W pozostałych sytuacjach, o których mówisz, jak parsowanie wejścia od usera – pełna zgoda, wyjątki tylko utrudniają.
Czy przytoczę z pamięci reguły wiązania? Nie. Ale nawet programista C powinien wiedzieć, że tam gdzie ma wątpliwości, to czytelnik kodu też pewnie będzie je miał i trzeba dodać nawiasy. Czy to wada C++?
Chyba mówimy o czymś innym. Mam na myśli wiązanie identyfikatora z funkcją, która się za nim kryje, co (przynajmniej dla mnie, być może standardem są hardkorowcy, którzy to pojmują) nie jest łatwe ze względu na szablony i przeciążenia. Czy to wada? Jeśli za jedno z kryteriów w ocenie jakości narzędzia przyjmiemy łatwość jego użycia, to skomplikowanie jest wadą.
Co do ostatniej części (x czy y), to masz rację, czepiam się, natomiast znajomość konwencji, a zwłaszcza jej umotywowania, wymaga sporo nauki, a pogodzenie się z nią bywa ciężkie, jeśli nie pasuje do przyzwyczajenia lub trudno ją powiązać z intuicją.
Ogólnie bardzo niezbornie wyraziłeś te swoje uwagi i średnio przekonująco (z wyjątkiem przypadkowej deklaracji funkcji czy prawie leniwych operatorów). Ogólnie nie widzę, dlaczego wg Ciebie powinno to dyskredytować w jakiś sposób C++.
Dziękuję za wyczerpującą odpowiedź, mam nadzieję, że udało mi się ją wykorzystać do uściślenia uwag niezbornych i nieprzekonujących.
Nie zamierzałem dyskredytować C++, ponieważ trochę go (masochistycznie ;)) lubię i nadal używam, choć już nie tak intensywnie jak, powiedzmy, 2 lata temu i już swoich umiejętności w nim nie rozwijam.
Nie pod tym kątem więc były moje uwagi. Chciałem jedynie wykazać, że podobnie jak MADS, C++ został zaprojektowany z uwzględnieniem kompatybilności z poprzednikiem na poziomie kodu źródłowego, a w toku jego rozwoju dodawano do niego często nowe featury (znów to brzydkie słowo), które nie zawsze dobrze pasowały do już istniejących, a rzadko decydowano się na potencjalne zerwanie zgodności z istniejącym kodem.
Skutkiem tego w obu istnieje bagaż, którego zrozumienie wymaga znajomości ich ewolucji. Domagam się zatem równego traktowania błędogennych cech MADSa i C++. :)
laoo: Widzę, że Fox mnie uprzedził (czego się obawiałem), niemniej nie zamierzam się uchylać od odpowiedzi. :)
Resztki kompatybilności z poprzednikiem
Prawie wszystko, co można napisać w C89 jest poprawnym kodem w C++. Prawie, bo m.in. wiele niejawnych rzutowań wskaźników już się nie skompiluje. To akurat dobrze, ale w takim razie po co na siłę trzymać inne dziwactwa z C, wśród których najbardziej upierdliwym jest powielanie tekstu w nagłówkach?
drobne, niepasujące do siebie i nie do końca przemyślane featury powrzucane naraz z powodu braku porozumienia wśród tych, którym na nich zależało;
Tak w moim odczuciu wyglądają featury wprowadzone jako "lepsze" zastępniki featur z C, jak biblioteczne vector i iostream.
Ten pierwszy nadal wymaga przekazania dwóch obiektów (co do których nikt nie sprawdza, czy mają coś wspólnego ze sobą lub z istniejącym jeszcze kontenerem), gdy chcemy podać do funkcji podzakres.
Ten drugi "świetnie" separuje formatowanie od danych:
std::cout << "mam " << std::hex << n << " lat";
// ups, na dodatek zapomniałem posprzątać!Mimo nowych lepszych featur, biblioteka C nadal tam jest. Niezastąpiona?
liczne zaskakujące i nieoczywiste szczególne przypadki na styku tychże featur, będące śladem nieskoordynowanego rozwoju,
- Klasyk z lekcji 1:
string s1("q"); // utworzenie zmiennej s1 typu string
string s2(); // deklaracja funkcji s2 zwracającej string- Wspomniany wyżej iostream zwraca kody błędów, choć mógłby rzucać wyjątkami.
- a && b; oblicza a i jeśli wynik jest != 0, oblicza też b. No, chyba że ktoś zdefiniował operator&&, który pasuje do a i b, wtedy zawsze oblicza a i b.
- Przytoczysz z pamięci reguły wiązania?
oraz milion odległych od siebie stylów pisania.
Daj spokój z hypem o wieloparadygmatowości, są niezałatwione sprawy bliżej ziemi. ;)
- class czy typename?
- using namespace czy pełne ścieżki?
- jeśli zmienna jest out lub in/out, to użyjesz wskaźnika czy referencji?
- ++i czy i++ (gdzie ten drugi można sobie zadeklarować samemu, używając, uwaga: operator++(T&, int nieuzywany);)
Jesteś pewien, że te 27 bajtów robi ci aż taką różnicę?
Na małe Atari też napiszesz po 17 latach? ;)
laoo: Wyprowadź mnie z błędu i niech utonę nauczywszy się czegoś.
Przywołanie standardu języka C++ w kontekście Madsa przywodzi na myśl pewne analogie.
Resztki kompatybilności z poprzednikiem; drobne, niepasujące do siebie i nie do końca przemyślane featury powrzucane naraz z powodu braku porozumienia wśród tych, którym na nich zależało; liczne zaskakujące i nieoczywiste szczególne przypadki na styku tychże featur, będące śladem nieskoordynowanego rozwoju, oraz milion odległych od siebie stylów pisania. Skąd my to znamy?
Przetestowałem różne opcje i stwierdzam autorytatywnie, że z dworca najwygodniej jest rowerem.
xxl: To nie jest błąd ani wyjątek, tylko spójna reguła.
To co ty proponujesz, a tebe zaimplementował, to jest wyjątek, bo w niektórych instrukcjach nie można już teraz zacząć komentarza od czegoś, co przypadkiem stanie się poprawnym wyrażeniem arytmetycznym.
epi napisał/a:dex ma wymaganych argumentów 0, więc $xx jest komentarzem i od 1991 roku nikogo to nie dziwi.
natomiast przed 1991 taka skladnia zdziwilaby wszystkich. sprawdz np. w mac65
ale zyjemy w demokracji :-) jak wiekszosc mowi ze krowa to kon, czas siodlac krasule.
---
atasm tez tego nie lyknie :-)
Pitu pitu. Próbujemy ci wytłumaczyć, że krowa to krowa (QA), a cielęta (xasm i mads) pochodzą od krowy. Tak bowiem miało być, że xasm jest kompatybilny z QA, a mads z xasmem.
Ty natomiast dziwisz się, że krowa i cielęta żują trawę, podczas gdy (twoim zdaniem) powinny, niczym konie (mac65 i atasm), wypiąć się na trawę i żreć owies. Tebe krasulę ci już osiodłał, szerokiej drogi!
Dalej nie wiem, jaki masz problem. Składnia jest zdefiniowana następująco:
[etykieta] rozkaz [wymagane argumenty ][komentarz]
dex ma wymaganych argumentów 0, więc $xx jest komentarzem i od 1991 roku nikogo to nie dziwi.
Jeśli ci z tym źle, wybierz inny asembler, albo "use the force, change the source".
Jaki w ogóle jest wasz problem? Jeśli PLA $00 daje $68 $00, to jest to błąd w MADSie. Jeśli daje $68 to jest tak samo dobrze jak w QA i xaśmie.
No tak, bo ColdFire to jest chyba tylko source-compatible z 68k, nie?
Parametr /C :)
Btw. Pin: czytasz maile?
sqward: Czy aby na pewno?
Design a computer that has at least the same functional range as the Hades Atari clone.
This means to make an Atari Falcon clone with nearly full compatibility to an original Falcon, which will be based on a ColdFire processor which is the fastest and most compatible hardware to the 68k processor family.
xxl: To tak jakby wstawiono ci nowe serce, które potrafi pompować krew 2x wydajniej (a więc niewątpliwie jest to osiągnięcie), z tym zastrzeżeniem, że wymaga innego składu krwi, albo nie będzie pompować w ogóle. To na kiedy zapisać pana na operację? :)
6809 ma LDD i STD do przesyłania 16-bitowego akumulatora z i do pamięci, jak również ADDD, SUBD i CMPD, które na nim liczą. Spełnia kryteria 1 i 2, zatem jest 16-bitowy, tak? :)
Więcej operacji na D pojawia się w 6309; pojawia się też LDQ i STQ do 32-bitowych przesłań oraz m.in. DIVQ, który dzieli 32-bitową wartość w Q przez argument.
Bardzo fajny projekt, niemniej 65C816 byłby fajniejszy, bo można na nim uruchomić większość kodu z 6502.
grzeniu: po co?
Nie trzyma się. Powinien?
Rozszerzoną pamięć 130XE, co nie?
atari.area forum » Posty przez epi
Wygenerowano w 0.125 sekund, wykonano 47 zapytań