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:

type Minuta is new Integer range 0..59;
type 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).