Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Scena - 8bit » CC65: jak to ugryzc na WinXP ???
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Okiej, aluzju paniał, prędzej cmoknę się we własny zadek niż poproszę o pomoc na atariarea.
No nie no, dlaczego kazdy prawie watek konczy sie tekstem w tym stylu. Dajcie wszyscy na luz. Juz taka mentalnosc Polakow, ze nawet jak pomoga to musza powiedziec przy okazji pare slow krytyki... Pirx: olej docinki i korzystaj z tresci merytorycznej watku. Nawet taki ilr piszac swojego posta podal tresci uzyteczne, mimo, ze opatrzone spora porcja jadu (no offence).
Wiecej luzu!
Ja sie przyznam ze C/C++/C# znam od podszewki (ale nie zaryzykuje twierdzenia "nie maja przede mna tajemnic") i chetnie odpowiem na kazde pytanie nie odsylajac do zadnej literatury :D
@IIr tak się składa że na codzień programuje w c#, a C znam dobrze.
Stwiedziłem tylko że przykładach błędnie napisano polecenie printf("test\n"), bo nie sądze aby celem było uzyskanie napisu testn na ekranie,
print("test\n) co jest błędem i daje na ekranie testn
staną się trywialne - nie jest to żaden błąd, po prostu sekwencja \ służy do wyprowadzenia .
a tak wynika z Twojego posta
Faktem jest ze skompilowałem pare trywialnych programów i wyprowadzanie tekstów na ekran przy pomocy stdio.h wywoływało błędy po użyciu znaku sterującego n.
@Iir jeżeli wiesz dlaczego to odpowiedz, a jeżeli nie wiesz, to nie obrażaj innych :?
"Język ANSI C" autorstwa Briana W. Kernighana i Dennisa M. Ritchiego (można kupić w księgarni albo ściągnąć w postaci pdfa z internetu)
Jak podasz adres tego pdfa, to Cię ozłocę. ;)
Juz taka mentalnosc Polakow, ze nawet jak pomoga to musza powiedziec przy okazji pare slow krytyki...
Bo w ten sposób najłatwiej odwrócić uwagę od własnego braku kompetncji. ;)
Jest jeden plus tego całego zamieszania i kąsania - ściągnąłem CC65. :)
Widzę, że poczuliście się dotknięci moim postem. Zapewniam Was, że nie było moim zamiarem ubliżać nikomu. W związku z powyższym wszystkich szczerze przepraszam.
Pozdrawiam
ilr
Faktem jest ze skompilowałem pare trywialnych programów i wyprowadzanie tekstów na ekran przy pomocy stdio.h wywoływało błędy po użyciu znaku sterującego n.
To znaczy konkretnie jakie błędy? Pytam z ciekawości, żeby nie było.
[ Dodano: 28.04.2005 11:37:48 ]
"Język ANSI C" autorstwa Briana W. Kernighana i Dennisa M. Ritchiego
Czy to jest coś innego niż B.W. Kernighan, D.M. Ritchie, "Język C"?
Czy to jest coś innego niż B.W. Kernighan, D.M. Ritchie, "Język C"?
Zdaje się, że jesto to drugie (uzupełnione) wydanie powyższej. Nie mam jej niestety pod ręką więc nie mogę podać szczegółów.
To znaczy konkretnie jakie błędy? Pytam z ciekawości, żeby nie było.
Cofam co napisałem i przepraszam za zamieszanie.
W Atari800Win 4.0 po uruchomieniu takiego programu następuje zawieszenie, pod SpartaDosX i MYDOSem.
Ale właśnie sprawdziłem ten sam program na Atari i pod MyDosem 4.50 działa znakomicie.
Czy to jest coś innego niż B.W. Kernighan, D.M. Ritchie, "Język C"?
Zdaje się, że jesto to drugie (uzupełnione) wydanie powyższej. Nie mam jej niestety pod ręką więc nie mogę podać szczegółów.
Zgadza sie:
http://cm.bell-labs.com/cm/cs/cbook/
[ Dodano: Czw Kwi 28, 2005 1:43 pm ]
ps. rowniez chetnie pomoge w C bez odsylania do dokumentacji.
W Atari800Win 4.0 po uruchomieniu takiego programu następuje zawieszenie, pod SpartaDosX i MYDOSem.
Nie ma to jak crossdevelopment :P
Dla zainteresowanych, to chyba to: ed2k://|file|B.Kernighan.D.Ritchie_Jezyk.C(ansi.C).rar|17530433|53549B4A3B470B222976B06BF646FC69|/
ok zapamietam znak < uzyskujemy przez < a > przez >
i nie wiem skad ta wrzawa, martwa materia aarea nabroila a Wy juz do gardel skaczecie :)
w zalaczniku oryginal, bez dodatkowych znaczkow dziwaczkow, dodawanych przez aarea, mozecie nawet do Worda to wczytac i edytowac
"Środowisko": ;) ˇ Windows XP SP2
ˇ cc65 V2.10.1
ˇ set CC65_INC=C:PROGRA~1CC65INCLUDE
set CC65_LIB=C:PROGRA~1CC65LIB
set LD65_CFG=C:PROGRA~1CC65LIB
ˇ nieśmiertelny program hello.c o znanej wszystkim zawartości ;)Zmienne środowiskowe wyglądają dokładnie tak jak widać.
Sekwencja:
cc65 -t atari -o hello.s hello.c
ca65 -t atari -o hello.o hello.sdziała dobrze, natomiast:
ld65 -t atari -o hello.xex hello.o atari.o atari.libprodukuje zły plik binary - linker pod Win32 jest zwalony.
Natomiast:
cl65 -t atari -o hello.xex hello.cdaje idealny program działający pod Atari 800Win. Nie wiem, czy na prawdziwym sprzęcie też ruszy (powinien), bo gdzieś mi wcięło APE. :?
Pirx, kierunek slashy w zmiennych CC65_* nie ma znaczenia, tak samo jak nie ma znaczenia obecność slasha na końcu ścieżki (zerknij na linie 69. :oops: pliku cc65-2.10.1srccommonsearchpath.c w źródłach ;) ).
Poeksperymentowałem trochę ze slashami i, gdy zmienne zawierają '\', to też wszystko działa.
ale chyba CC65 nie uzywa INCLUDE, tylko tych swoich zmiennych???
I całe szczęście. Wyobraź sobie co by sie stało, gdybyś zapodał do CC65 stdio.h z takiego BC++, a do LD65 stdlib.lib, czy coś podobnego. :mrgreen:
Na koniec praca domowa dla beginnerów: co wyświetli taki program? ;)
#include <stdio.h>
int main()
{
int c=1;
c+=++c+c++;
printf("%dn",c);
return 0;
}Proszę najpierw ładnie w głowie, a potem sprawdzić, czy aby na pewno. :)
Czyzby 9? Od razu mowie, ze C uczylem sie dobrych pare lat temu (tak z osiem) i na codzien nie uzywam... Do tego nie mam zadnego kompilatora C zeby sprawdzic.
6? Konkurs zdrapka?
Dziadzia byl bardzo blisko :>
A ja uwazam, ze nikt nie byl blisko: wynik tej operacji jest niezdefiniowany. To jest klasyczny przyklad. Spotkalem sie juz z wynikami 5, 6 i 7 8)
PS.: sory ze zepsulem zabawe
nie dam sobie nic obciac ale wydaje mi sie ze JEST to zdefiniowane (kolejnosc dzialan z pre/inkrementacja operatorow) w standardzie ANSI C. Nie mam teraz pod reka ani literatury ale wydaje mi sie ze kompilator zgodny z ANSI C powinien wyprodukowac 7 i tylko 7. Istnienia innych wynikow nie wykluczam ale sadze ze biora sie wlasnie z tej niezgodnosci. Jesli ktos umie wiecej powiedziec na ten temat to chetnie poslucham.
Nie jest dokladnie ten sam przyklad ale
Basically, in C and C++, if you read a variable twice in an expression where you also write it, the result is undefined. Don't do that.
A skad wzialem te wyniki: 6 i 7 powstalo z najnowszego GCC tylko ze 6 na emulatorze PPC a 7 pod cygwinem. Siodemke drukuje tez VC++. A piątke drukuje c#. Coprawda to nie C, ale chcialem pokazac ze wynik moze byc jeszcze inny.
Wyglada na to ze nie mialem racji. Laoo masz browca :)
1.35: People keep saying that the behavior of i = i++ is undefined,
but I just tried it on an ANSI-conforming compiler, and got the
results I expected.A: A compiler may do anything it likes when faced with undefined
behavior (and, within limits, with implementation-defined and
unspecified behavior), including doing what you expect. It's
unwise to depend on it, though.
Ale drugiego na Quascie stawiam ja :D
People keep saying that the behavior of i = i++ is undefined
Tu, niezależnie od literatury, obstawiałbym, że i zostanie zwiększone o 1. Najpierw pod i zostanie przypisana wartość i, a potem do i zostanie dodane 1 i zapisane w i. :)
Wracając do mojego przykładu (int c = 1; c += ++c + c++): GCC pod FreeBSD i Slackwarem oraz CC65 zwraca 7. Czy ktoś z ST/TT/F030 mógłby to sprawdzić pod Pure C? Jestem ciekawy jak Borland sie na to zapatruje.
++c jest wykonywane przed całością, a c++ na samym końcu, czyli już po przypisaniu wartości do zmiennej. Wiedząc to można stwierdzić: ˇ ++c zwiększa wartość c na 2 i to właśnie ta wartość jest brana pod uwagę
ˇ potem jest wykonywane dodawanie c + c, czyli mamy 4
ˇ c zwiększane jest o 4 (c+=4), co daje 6
ˇ na koniec c++ i mamy 7Preinkrementacja zmienia wartość zmiennej natychmiast, więc wszelkie dalsze obliczenia są wykonywane na nowej wartości. Szóstka w GCC na PPC wzięła się przez pomyłkę. :lol: Wpierw zostało wykonane c++ a później += co jest dla wg poważnym błędem. 5 w C# łatwo natomiast wytłumaczyć: c + c to dodawanie dwóch różnych zmiennych (najpierw ++c, czyli 2, potem 2+1=3, 3++ daje 4, a c += 4, to 1 + 4 = 5). 8) Dywagacje nt 5 i 6 są czysto teoretyczne. Nie sprawdzałem tego.
Zgadzam się z Mikeyem i Laoo. Jak ognia należy unikać podwójnej i więcej modyfikacji tej samej zmiennej.
GCC pod FreeBSD i Slackwarem ... zwraca 7.
Co nie jest niczym dziwnym, bo w obu przypadkach jest to ten sam kompilator (obie maszyny i386 w dodatku).
ktoś bawił sie ACEC C ? Znalazłem toto na PAGE6 http://www.page6.org/, kompilator, optymalizator, linker dla XE/XL
Bawiłem się dawno temu. Jeżeli masz cc65, to na Ace C szkoda czasu. Tyle.
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Scena - 8bit » CC65: jak to ugryzc na WinXP ???
Wygenerowano w 0.026 sekund, wykonano 67 zapytań