Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
dyskusyjnych:jrdfvo$pgc$...@i...gazeta.pl...
> Ale nie :) Po prostu nigdy nie dalem i nie dam sie przywiazac do zadnej
> "kuli".

Jedno słowo: grawitacja.

> Mentalnie przywiazac.

Dałeś się - aniołki u góry, diabełki u dołu - grawitacja określa oś dobra i
zła.

> Przeciez to u Ciebie jest ograniczona prawie wylacznie do Fortranu.

Dlatego właśnie pytam mądrzejszych (?) niż ja.

> A Fortran to wlasnie chora skladnia (fakt ze od F90 juz zdecydowanie

Fortran ma jakąś składnię?!

> ulepszona. Doceniam to). No moze oprocz chorych pointerow
> ktore po ch..re do Fortranu wprowadzono) i _nic ponad to_

Nie patrz na nie. Ignoruj je. To i one cię nie zauważą. Mi się udało, tobie
też się uda.

Ponad? Jejku, jest tyle fajnych rzeczy nowych - w porównaniu do Fortranu
II - że aż dech zapiera. Na przykład takie ELSE.

do góry

On 14.06.2012 22:15, AK wrote:
> PS1: Czy wiesz ze wiekszosc obecnych tu fachowcow
> C++ swiecie wierzy ze nawiasy w C/C++ wymuszaja
> kolejnosc obliczen ?

The grouping of operators and operands is indicated by the syntax.74)
Except as specified later (for the function-call (), &&, ||, ?:, and
comma operators), the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified.

_subexpressions_

MAX_INT + 1 - 1 //to jest UB
MAX_INT + (1 - 1) //to nie
(a-1)+(c-2) // unspecified który nawias policzy kompilator najpierw.
unspecified nawet czy je policzy w ogóle, ale nawet jeżeli policzy to
wyrażenie jako ((a+b)-3) to z puntu widzenia programisty zachowanie ma
być dokładnie takie jakie wynika z łączności, m.i. gdy MAX_INT-a==b-1
nie ma być UB

--
Pozdrawiam
Michoo

do góry

On 15.06.2012 02:28, Michoo wrote:
> (a-1)+(c-2)
[...]
> ((a+b)-3)
((a+c)-3) oczywiście


--
Pozdrawiam
Michoo

do góry

On 14/06/2012 20:22, slawek wrote:
>
> Użytkownik <n...@m...invalid> napisał w wiadomości grup
> dyskusyjnych:jr62lb$m8o$...@n...icpnet.pl...
>> IMHO, raczej laika, state-of-the-art współczesnego programowania
>> spoczywa w językach typu Haskell/Prolog dla problemów deterministycznych
>
> Prolog? Niewiele młodszy od Fortranu. Mało atrakcyjny i zbyt mocno
> abstrakcyjny. Ortogonalny do OOP i CNC. No i nie da się w tym pisać
> programów dla Androida.

http://www.jekejeke.ch/idatab/doclet/blog/en/docs/ex
t/01_general/099_releases/topic_999947.html

do góry

On 14/06/2012 19:28, slawek wrote:
>
> Użytkownik "A.L." <l...@a...com> napisał w wiadomości grup
> dyskusyjnych:2nnct7lvjnd46p6j7b29cbbmk5p5r267ac@4ax.
com...
>> "System templatow" to zwykly, ordynarny maroprocesor. Gorszy od tych
>> ktore byly znane w latah 60. Badziewie zwykle, jak i caly C++
>
> Zgadzam się. Ale to w sensie implementacji. Bo nigdzie (chyba!) nie jest
> napisane, że to musi być takie badziewie. Więc teoretycznie...

W standardzie jest napisane.

do góry

On 14/06/2012 19:00, slawek wrote:
>
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
> wiadomości grup dyskusyjnych:jquqpo$e4k$...@i...gazeta.pl...
>> wykonania w takiej kolejności". Program deklaratywny też można opisać
>> jako "ciąg instrukcji" w szerszym znaczeniu, a w niektórych przypadkach
>
> Wątpię czy istnieje jednoznaczność.

Nie rozumiem? Gdzie istnieje? Jednoznaczność czego?

>> nawet jako "zbiór instrukcji" (kiedy kolejność poszczególnych
>> "instrukcji" nie ma znaczenia - raczej nie mamy do czynienia z
>> paradygmatem imperatywnym).
>
> Czyli program wielowątkowy nie może być napisany w C ?

W programie wielowątkowym kolejność poszczególnych instrukcji nadal ma
znaczenie. W C raczej ciężko napisać program tak, żeby każda instrukcja
wykonywała się w oddzielnym wątku.

> (Dla mniej spostrzegawczych - program wielowątkowy nie gwarantuje
> "kolejności instrukcji' - a język C jest językiem imperatywnym.)

Dla mniej spostrzegawczych: nie napisałem nic o gwarantowaniu kolejności
instrukcji. już wstawienie zwykłego if czy goto powoduje, że kolejność
wykonania instrukcji nie jest gwarantowana.

Jeszcze raz, co napisałem: odniosłem się do części próby definicji
programu, gdzie programem był "zbiór instrukcji". Analnie czepiając się
zauważam, że zbiór nie ma określonej ilości elementów. Rozpatruję
hipotetyczny język programowania, w którym te same instrukcje dają
zawsze ten sam program, niezależnie od kolejności wprowadzania tych
instrukcji. Zauważam, że taki hipotetyczny język raczej nie jest
językiem imperatywnym.

>> 2. Nie widziałeś "tego, co zostało z komputera", bo żadnej z tych maszyn
>
> Jeżeli dobrze zrozumiałem w Oksfordzie są pokazywane autentyczne części.
> Zapewne są to części maszyny różnicowej, ale Babbage chciał - w innej
> konfiguracji - z nich robić maszynę analityczną.

Bez sprawdzania wydaje mi się, że Babbage zlecił wykonanie części
maszyny różnicowej, maszyna analityczna była na papierze w fazie
koncepcji. Po śmierci Babbage'a ktoś wykonał kilka części maszyny
analitycznej (są w muzeach), ale maszyna analityczna jako całość nie
powstała nigdy (dwie maszyny różnicowe zostały zbudowane w tym stuleciu).

> Karty żakardowskie do obejrzenia w Białej Fabryce w mieście Łodzi.
> (Najpiękniejsze w tym, że można z nich odtworzyć _cyfrowo_ wzory
> materiałów sprzed około 150 lat.)
> Nota bene, jak się nazywałby dziś człowiek przygotowujący takie karty?
> Programistą!

Może "programatorem"?

>> No więc właśnie według mnie to naturalna kolejność. Hardware się
>> buduje jak wiadomo, że będzie użyteczny, a wykazać użyteczność
>> komputera można na przykład pisząc program do niego jako proof of
>> concept.
>
> Ujmując filozoficznie... różne rzeczy się buduje... które są zupełnie
> nieużyteczne. Ba! Część z nich nie jest nawet ładna (sztuka nie musi być
> użyteczna).

No ale mówimy o budowie maszyny liczącej. Historycznie takie maszyny
jednak budowano po to, żeby cośtam na nich liczyć.

>> Zresztą właśnie jeśli chodzi o wspomnianą maszynę analityczną
>> Babbage'a było właśnie tak, że hardware nigdy nie powstał, a programy
>> owszem (patrz: dlaczego język Ada nazywa się właśnie tak).
>
> Za dużo steampunka, za mało faktów. Nie wiem czy ocalał jakiś kod
> źródłowy... czy też jest to mit (początki patentowego trollingu?)

http://www.fourmilab.ch/babbage/sketch.html

do góry

On Thursday, June 14, 2012 7:23:48 PM UTC+1, slawek wrote:
> Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości grup
> dyskusyjnych:730e9120-4079-45d5-9fea-00c129264be2@go
oglegroups.com...
> > Typowym uzasadnieniem jest, ze wystarczy troche zmienic opcje kompilatora
> > i dwie wersje std::vector<double> staja sie niekompatybilne binarnie.
>
> Bzdurki. Typowym rzeczywistym powodem jest niechęć do nauczenia się kobyły o
> nazwie STL.

Bzdurki, dopoki nie spedzisz godziny debugujac dziwny blad systemu, zeby w koncu sie
pacnac w czolo "oh wait, ktos zmienil opcje kompilatora tej dll-ce".

RW

do góry

On 14/06/2012 15:51, Wojciech Muła wrote:
> W dniu czwartek, 14 czerwca 2012 16:35:43 UTC+2 użytkownik Roman W napisał:
>> Oczywiscie ze mozna bez wyjatkow, C przeciez sobie radzilo z takimi sytuacjami bez
wyjatkow ;-)
>
> C sobie radzi? Polecam wszystkim spróbować sił
> w "A Quiz About Integers in C" http://blog.regehr.org/archives/721
> Na kilku przykładach widać w jak głębokiej dupie
> jest koder C/C++ tylko dzięki specyfikacji języka.

E tam w dupie. Po prostu pamięta się kilka "rules of thumb".

> W ogóle jestem ciekaw ile kosztowały w sumie te
> wszystkie trywialne błędy w rodzaju "null pointer
> dereference". Znacie jakieś opracowania?

Również ciekawe, na ile _w praktyce_ UB z powodu null pointer
dereference jest bardziej kosztowne niż różne NullPointerException.

do góry

W dniu 2012-06-14 23:04, Maciej Sobczak pisze:
> SPARK jest językiem i jako taki nie obsługuje ani baz danych ani
> plików. Można w nim natomiast napisać bibliotekę, która to robi. Co ta
> biblioteka wtedy zrobi? To zależy, jak jej autor to wymyśli - ale na
> pewno nie rzuci wyjątku.

Nie gadaj, tylko rzuć przykład, bo wyobraźnia podpowiada mi koszmarne
konstrukcje ifififififelseelseelse...

artur

do góry

On Thursday, June 14, 2012 8:33:52 PM UTC+1, Wojciech Muła wrote:
> W dniu czwartek, 14 czerwca 2012 17:52:48 UTC+2 użytkownik Roman W napisał:
> > No jakos sobie radzi, skoro tyle dobrego oprogramowania napisano w C.
>
> To wynika tylko z popularności i zaszłości.

Argument kolowy: C jest popularne bo jest popularne.

RW

do góry