> u�ytkownika tn� j� po bia�ych znakach na kawa�ki u�ywaj�c strtok


> rysuj_kolo(atoi(x[1]),atoi(x[2]),atoi(x[3]));
>
> i po sprawie.
>

to jest dosyc dobry sposob tyle ze golowny
problem to ten gdy ktos poda zle argumenty
i atoi sie sypnie - wtedy raczej nie bedzie
dobrze - a szkoda bo pewnieo wolalbym taka
statyczna wersje niz sekwencje

char* command = getString();

...

int x = getNumber();
int y = getNumber();
int r = getNumber();

if(parsingError) { Console("bad args for drawcircle"); return; }

DrawCircle(x,y,r);

Gdyby nie ten problem tamta wersja bylaby
lepsza, musialby byc w c mechanizm ktory
pozwolalby wyskoczyc

DrawCircle( StrToInt( arg[1] ),
StrToInt( arg[2] ),
StrToInt( arg[3] );

z tego przez break albo return czy jakos
inaczej gdy StrToInt dostanie niepoprawny
argument - a nie ma czegos takiego;

do góry

>
>
> DrawCircle( StrToInt( arg[1] ),
>
> StrToInt( arg[2] ),
>
> StrToInt( arg[3] );
>

wogole to przychodzi na mysl pomysl by c
obslugiwalo na poziomie rzutowan konwersje
ze stringow na inty i floaty i na odwrot

typu SetPixel((int)"100", (int)"200"); //atoi
albo pisz( (char[5]) 1000) //leci wbudowane itoa

to niby troche roblematyczne ale chyba ma swoje
powody by byc zrobione

do góry

Dnia 19.10.2012 kenobi <p...@g...com> napisał/a:
>> u�ytkownika tn� j� po bia�ych znakach na kawa�ki u�ywaj�c strtok
>
>
>> rysuj_kolo(atoi(x[1]),atoi(x[2]),atoi(x[3]));
>>
>> i po sprawie.
>>
>
> to jest dosyc dobry sposob tyle ze golowny
> problem to ten gdy ktos poda zle argumenty
> i atoi sie sypnie - wtedy raczej nie bedzie
> dobrze - a szkoda bo pewnieo wolalbym taka
> statyczna wersje niz sekwencje
>
> char* command = getString();
>
> ...
>
> int x = getNumber();
> int y = getNumber();
> int r = getNumber();
>
> if(parsingError) { Console("bad args for drawcircle"); return; }
>
> DrawCircle(x,y,r);
>
> Gdyby nie ten problem tamta wersja bylaby
> lepsza, musialby byc w c mechanizm ktory
> pozwolalby wyskoczyc
>
> DrawCircle( StrToInt( arg[1] ),
> StrToInt( arg[2] ),
> StrToInt( arg[3] );
>
> z tego przez break albo return czy jakos
> inaczej gdy StrToInt dostanie niepoprawny
> argument - a nie ma czegos takiego;
>

Jest "znienawidzona nie wiadomo za co" instrukcja goto która pozwala
na takie wielopoziomowe "wyskoki". Nie wiem jakiego kompilatora
używasz, ale standardowa biblioteka do GCC zawiera też funkcje strtoi
czy strtof, które konwertują ze sprawdzaniem błędów (nie pamiętam już,
czy te funkcje są częścią standardu C czy nie, w "starym C" z 1989
roku nie były, ale w ANSI C z '99 roku już chyba są, więc każdy w
miarę współczesny kompilator powinien je mieć).

do góry

Dnia 19.10.2012 kenobi <p...@g...com> napisał/a:
>>
>>
>> DrawCircle( StrToInt( arg[1] ),
>>
>> StrToInt( arg[2] ),
>>
>> StrToInt( arg[3] );
>>
>
> wogole to przychodzi na mysl pomysl by c
> obslugiwalo na poziomie rzutowan konwersje
> ze stringow na inty i floaty i na odwrot
>
> typu SetPixel((int)"100", (int)"200"); //atoi
> albo pisz( (char[5]) 1000) //leci wbudowane itoa
>
> to niby troche roblematyczne ale chyba ma swoje
> powody by byc zrobione

Ależ to są jak najbardziej poprawne konstrukcje w języku C, tylko
działają inaczej niż się pewnie spodziewasz (tzn. ta (char[5])1000 to
nie jest poprawna, ale (char*) 1000 już tak :D).

do góry

W dniu piątek, 19 października 2012 16:35:56 UTC+2 użytkownik Baranosiu napisał:
> Dnia 19.10.2012 kenobi <p...@g...com> napisaďż˝/a:
>
> >> u�ytkownika tn� j� po bia�ych znakach na kawa�ki u�ywaj�c strtok
>
> >
>
> >
>
> >> rysuj_kolo(atoi(x[1]),atoi(x[2]),atoi(x[3]));
>
> >>
>
> >> i po sprawie.
>
> >>
>
> >
>
> > to jest dosyc dobry sposob tyle ze golowny
>
> > problem to ten gdy ktos poda zle argumenty
>
> > i atoi sie sypnie - wtedy raczej nie bedzie
>
> > dobrze - a szkoda bo pewnieo wolalbym taka
>
> > statyczna wersje niz sekwencje
>
> >
>
> > char* command = getString();
>
> >
>
> > ...
>
> >
>
> > int x = getNumber();
>
> > int y = getNumber();
>
> > int r = getNumber();
>
> >
>
> > if(parsingError) { Console("bad args for drawcircle"); return; }
>
> >
>
> > DrawCircle(x,y,r);
>
> >
>
> > Gdyby nie ten problem tamta wersja bylaby
>
> > lepsza, musialby byc w c mechanizm ktory
>
> > pozwolalby wyskoczyc
>
> >
>
> > DrawCircle( StrToInt( arg[1] ),
>
> > StrToInt( arg[2] ),
>
> > StrToInt( arg[3] );
>
> >
>
> > z tego przez break albo return czy jakos
>
> > inaczej gdy StrToInt dostanie niepoprawny
>
> > argument - a nie ma czegos takiego;
>
> >
>
>
>
> Jest "znienawidzona nie wiadomo za co" instrukcja goto kt�ra pozwala
>
> na takie wielopoziomowe "wyskoki". Nie wiem jakiego kompilatora
>
> u�ywasz, ale standardowa biblioteka do GCC zawiera te� funkcje strtoi
>
> czy strtof, kt�re konwertuj� ze sprawdzaniem b��d�w (nie pami�tam
juďż˝,
>
> czy te funkcje s� cz�ci� standardu C czy nie, w "starym C" z 1989
>
> roku nie by�y, ale w ANSI C z '99 roku ju� chyba s�, wi�c ka�dy w
>
> miar� wsp�czesny kompilator powinien je mie�).

no ale tutaj nie da sie raczej wyskoczyc nawet przez goto (w przypadku blednego
argumentu trzeba po prostu zrobic return i nie wykonac komendy
Mozna napisac makro i byloby krotko ale ja
nie lubie uzywac makr o tyle atoi 'w miejscu'
odpada :( (juz wiekszosc tego napisalem rano,
moze teraz w weekend na spokojnie troche to poprawie)

do góry

W dniu piątek, 19 października 2012 16:45:20 UTC+2 użytkownik Baranosiu napisał:
> Dnia 19.10.2012 kenobi <p...@g...com> napisaďż˝/a:
>
> >>
>
> >>
>
> >> DrawCircle( StrToInt( arg[1] ),
>
> >>
>
> >> StrToInt( arg[2] ),
>
> >>
>
> >> StrToInt( arg[3] );
>
> >>
>
> >
>
> > wogole to przychodzi na mysl pomysl by c
>
> > obslugiwalo na poziomie rzutowan konwersje
>
> > ze stringow na inty i floaty i na odwrot
>
> >
>
> > typu SetPixel((int)"100", (int)"200"); //atoi
>
> > albo pisz( (char[5]) 1000) //leci wbudowane itoa
>
> >
>
> > to niby troche roblematyczne ale chyba ma swoje
>
> > powody by byc zrobione
>
>
>
> Ale� to s� jak najbardziej poprawne konstrukcje w j�zyku C, tylko
>
> dzia�aj� inaczej ni� si� pewnie spodziewasz (tzn. ta (char[5])1000 to
>
> nie jest poprawna, ale (char*) 1000 juďż˝ tak :D).

no wiem, troche znam sie na c, chodzilo
mi o niezdefiniowane obecnie konwersje
jak (char[5]) 1234 czy (char[]) 1234
powinno tworzyc lokalnie kawalek tablicy
z przetlumaczona wersja (nawet kiedys
postulowalem by itoa bylo opcodem w asemblerze

do góry

Dnia 19.10.2012 kenobi <p...@g...com> napisał/a:
[...]
> no wiem, troche znam sie na c, chodzilo
> mi o niezdefiniowane obecnie konwersje
> jak (char[5]) 1234 czy (char[]) 1234
> powinno tworzyc lokalnie kawalek tablicy
> z przetlumaczona wersja (nawet kiedys
> postulowalem by itoa bylo opcodem w asemblerze

Nie jest to potrzebne w C, bo sprintf załatwia takie konwersje
znacznie lepiej (jak napiszesz w kodzie (char[5]) 0x10 to w tablicy ma
być postać dziesiętna, szesnastkowa czy binarna? a co jeśli użyjesz
zmiennej a nie stałej na przykład (char[5])A ? zbyt wiele
niejasności). Co do itoa w assemblerze... zostańmy może lepiej przy
tym, że procesor działa na bitach, bajtach i temu podobnych rzeczach,
a nie na znakach :D Oj dopiero by się działo jakbyś w komputerze miał
procesor z chińską tablicą kodową :D Konwersja tekst<->liczba musi być
jawna, bo można to zrobić na wiele różnych sposobów :D Większość
assemblerów pozwala na tworzenie własnych makr do załatwiania takich
spraw (a jeśli ich wbudowane możliwości są za małe, to można użyć HLA
albo preprocesora takiego jak m4 :D).

do góry

W dniu piątek, 19 października 2012 17:00:22 UTC+2 użytkownik Baranosiu napisał:
> Dnia 19.10.2012 kenobi <p...@g...com> napisaďż˝/a:
>
> [...]
>
> > no wiem, troche znam sie na c, chodzilo
>
> > mi o niezdefiniowane obecnie konwersje
>
> > jak (char[5]) 1234 czy (char[]) 1234
>
> > powinno tworzyc lokalnie kawalek tablicy
>
> > z przetlumaczona wersja (nawet kiedys
>
> > postulowalem by itoa bylo opcodem w asemblerze
>
>
>
> Nie jest to potrzebne w C, bo sprintf za�atwia takie konwersje
>
> znacznie lepiej (jak napiszesz w kodzie (char[5]) 0x10 to w tablicy ma
>
> by� posta� dziesi�tna, szesnastkowa czy binarna? a co je�li u�yjesz
>
> zmiennej a nie sta�ej na przyk�ad (char[5])A ? zbyt wiele
>

mozna zrobic ten operator przeciazalnym itp,
jest to troche problematyczne glownie z tego
powodu ze dotychczas operatory rzutowania
nie robily tego typo rzeczy, ale raczej
sklaniam sie ku temu zeby to bylo w jezyku,
powod jest takie ze gdyby to bylo sporo
roznego rodzaju kodow w c daloby sie napisac
bez biblioteki a brak tego wlasnie burzy tą
ew elegancje - niezrecznosc w porownaniu np
z konwersjami double na long itp wynka wlasine z tego ze to nie jest obslugiwane na
poziomie
srzetu (a mogloby byc) tak ze mz mogloby wejsc
- jest to dosyc fundamentalna operacja i
wlasnie sporo klopotu jest z robieniem tego
samemu, uprosciloby tez kody w polaczeniu
z domyslnymi rzutowaniami - chco sa i troche
problematyczne kwestie np jesli to by mialo byc
na tak niskim poziomie to bledne konwersje
musialyby chyba rzucac wyjatkami podobnymi do
tych na fpu - no ale to jest wogole odrebny temat







> niejasno�ci). Co do itoa w assemblerze... zosta�my mo�e lepiej przy
>
> tym, �e procesor dzia�a na bitach, bajtach i temu podobnych rzeczach,
>
> a nie na znakach :D Oj dopiero by si� dzia�o jakby� w komputerze mia�
>
> procesor z chi�sk� tablic� kodow� :D Konwersja tekst<->liczba musi by�
>
> jawna, bo mo�na to zrobi� na wiele r�nych sposob�w :D Wi�kszo��
>
> assembler�w pozwala na tworzenie w�asnych makr do za�atwiania takich
>
> spraw (a je�li ich wbudowane mo�liwo�ci s� za ma�e, to mo�na u�y�
HLA
>
> albo preprocesora takiego jak m4 :D).

do góry

Dnia 19.10.2012 kenobi <p...@g...com> napisał/a:
> mozna zrobic ten operator przeciazalnym itp,
> jest to troche problematyczne glownie z tego
> powodu ze dotychczas operatory rzutowania
> nie robily tego typo rzeczy, ale raczej
> sklaniam sie ku temu zeby to bylo w jezyku,
> powod jest takie ze gdyby to bylo sporo
> roznego rodzaju kodow w c daloby sie napisac
> bez biblioteki a brak tego wlasnie burzy tą
> ew elegancje - niezrecznosc w porownaniu np
> z konwersjami double na long itp wynka wlasine z tego ze to nie jest
> obslugiwane na poziomie srzetu (a mogloby byc)

Jeśli potrzebujesz przeciążania, to możesz zastosować C++ i samemu
zdefiniować sposób rzutowania takich rzeczy jak (char[])1000 - nie ma
z tym najmniejszego problemu (za wyjątkiem tego, że trzeba to zrobić
raz na całe swoje życie :D). Sam język czym mniej robi "za plecami"
programisty tym lepiej :D Na przykład w Ada gdy zdefiniujesz:

typedef Minuta is new Integer range 0..59;
typedef Sekunda is new Integer range 0..59;

to typy Minuta i Sekunda nie są ze sobą zgodne (mimo że obydwa są
typami całkowitymi o tym samym zakresie) i bardzo dobrze, że tak jest,
bo przecież minuta to 60 sekund i równość jest dopiero gdy
licznik_sekund = 60 * licznik_minut ale skąd kompilator czy procesor
mają to wiedzieć jeśli im się tego jawnie nie "powie"? Nawet takie
"beztypowe" języki jak Python nie zaakceptują ciągu instrukcji:

A="10"
B=A*2

bo coś takiego po prostu świadczy o błędzie programisty i język POWINIEN
wymagać zrobienia B=int(A)*2 bo wtedy jest pewność, że programista wie
co robi.
Automatyczne konwersje typów char[]<->int w procesorze nie sprzyjałoby
tzw. elegancji kodu lecz byłoby tylko "wytrychem" na lenistwo bądź
niewiedzę programisty (to oczywiście moje zdanie). Czy konwersja
pomiędzy char[] a int jest problematyczna przy pisaniu programu?
Przecież wystarczy raz w programie zdefiniować SAMEMU jak ma być
robione to rzutowanie (i nawet nie trzeba robić implementacji, można
skorzystać z gotowych funkcji) i można konstrukcji typu (char[])100
używać, ale jak to jawnie zdefiniujesz, to kompilator wie, że ty
"wiesz co robisz" :D Pozatym to ty możesz sam określić kiedy w
konwersji jest błąd a kiedy nie jest, bo jak program zapyta "podaj
cenę" i użytkownik wpisze "25gr" to Ty jako programista możesz zrobić
z tego 0.25zł a procesor... albo wyrzuciłby błąd napotkawszy nieznane
znaki, albo "olałby" jednostkę i traktowałby to jako 25zł :D

Z mojego doświadczenia: jeśli konwersja typów w programie jest "na
porządku dziennym" (za wyjątkiem I/O czyli interakcji z
użytkownikiem), to znaczy, że w programie jest dużo błędów
projektowych (nie został przemyślany, tylko programista bez projektu
zasiadł do pisania i "jakoś tak samo wyszło"). Znajomość języka
programowania a umiejętność programowania to dwie różne sprawy,
pozatym język programowania potrafi przyzwyczaić do pewnych schematów
myślenia.
W swoich początkach (ponad 20 lat temu) gdy zaczynałem od BASIC, to
mojej głowie było obce myślenie w kategoriach rekurencji, list, grafów,
podprocedeur, zmiennych lokalnych itd. bo... BASIC tego nie miał, więc
nauczyłem się "żyć bez tego" i jakieś rzeczy typu deklarowanie
zmiennych czy wskaźniki w innych językach programowania uważałem za
zbędny balast, który "spowalnia wklepywanie programu do komputera".
Obecnie... nie umiałbym napisać w BASIC nic poważniejszego, nie
"zapanował bym" nad projektem gdyby cały program musiał być "płaski" i
"beztypowy" :D Statystycznie najwięcej błędów znajduję u siebie w tych
miejscach, gdzie język nie wymaga ode mnie surowej dyscypliny :D

> tak ze mz mogloby wejsc
> - jest to dosyc fundamentalna operacja i
> wlasnie sporo klopotu jest z robieniem tego
> samemu, uprosciloby tez kody w polaczeniu
> z domyslnymi rzutowaniami - chco sa i troche
> problematyczne kwestie np jesli to by mialo byc
> na tak niskim poziomie to bledne konwersje
> musialyby chyba rzucac wyjatkami podobnymi do
> tych na fpu - no ale to jest wogole odrebny temat

FPU rzuca wyjątkami w przypadku rzeczy typu dzielenie przez zero czy
arcsin(-2), nie zajmuje się konwersjami między typami liczbowymi (i ich
reprezentacjami znakowymi :D) Nie ma najmniejszego kłopotu z robieniem
tego samemu, bo w bibliotece standardowej praktycznie każdego języka
masz gotowce dobrze zdefiniowane, wystarczy z nich
skorzystać. Procesor nie jest od tego aby wnikał czy dana liczba jest
zapisana po arabsku czy po rzymsku i czy napis 10e3 to zapis
szesnastkowy 0x10e3 czy liczba rzeczywista 10000, od rozstrzygania
takich rzeczy jest programista (bo w różnych przypadkach może być
różnie :D).

do góry

W konsoli siedzi jakas fajna magia, Pamietam
w dziecinstwie mialem C64 i raz wsrod gier na
tasmach natknalem sie na kompilator fortha (lub
fortrana) Asma i basic kojarzylem ale fortha (czy
fortrana) to raczej nie Byla tam konsola, czarny
ekran i zlote/zolte lub niebieskie/szare litery, nie
mialem instrukcji i moglem tylko wyszukiwac slowa
hexedytorem i probowac na slepo cos wpisywac.

Konsola ma magie, bo jest konsola, sa tajemniecze
polecenia i mozna robic rone rzeczy - chyba wiekszosc
tej magii rozwalil dos, ktorego polecenia byly durne
a konsola b kiepska (do dzis nie wiem kto to
w sumie zrobil ) Pozatym (poza dosem i
interpreterem basica z c64) za wielu konsoli
nie znam i nie pamietam. Sa jakies inne slawne
konsole? (pamietam jeszcze lego i basic z zx spectrum
ale widzialem tylko przez moment, konsoli amigi np nie
kojarze, linuxa tez nie bardzo,( to co pamietam to
bylo nieststy troche podobne do dosa,) terminale
unixa juz jakby lepiej, przez mudy irca itp rzeczy
(ktore ja znam tylko z czasow studiow na fizyce, gdyby
nie to nie mialbym o tym pojecia) )

do góry