🚀 go-pugleaf

On Sat, 03 Nov 2007 10:47:38 +0100
Hoobert <michal_hr@yahoo.pl> wrote:

> Natkąłem się na takie coś: www.fefe.de/c++/c++-talk.pdf
> W sumie nic nowego, ale kilka rzeczy dość fajnie pokazanych jest.
> Jak dla mnie przykład z foo->bar w części "C++ is hard to read" jest 
> dość wymowny.

Mi sie spodobal kod ze strony 48, nigdy bym sie nie spodziewal bledu w
takim miejscu.

Witam

Sulsa wrote:

>> Natkąłem się na takie coś: www.fefe.de/c++/c++-talk.pdf
>> W sumie nic nowego, ale kilka rzeczy dość fajnie pokazanych jest.
>> Jak dla mnie przykład z foo->bar w części "C++ is hard to read" jest
>> dość wymowny.
> 
> Mi sie spodobal kod ze strony 48, nigdy bym sie nie spodziewal bledu w
> takim miejscu.

Zacząłbym od tego, że ten kod się nie kompiluje. 

Po upgrade, aby mógł się kompilować wszystko działa dobrze. 

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia Tue, 06 Nov 2007 23:34:04 +0100
Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> napisał(a):

> > Mi sie spodobal kod ze strony 48, nigdy bym sie nie spodziewal
> > bledu w takim miejscu.
> 
> Zacząłbym od tego, że ten kod się nie kompiluje. 
> Po upgrade, aby mógł się kompilować wszystko działa dobrze. 

Nie wiem czy dobrze interpretuję "wszystko działa dobrze". ;-)

Pozwoliłem sobie na potestowanie, bo w sumie mi też przykład się podoba.
#v+
#include <stdio.h>

struct bar {int member;};
struct foo : public bar {int member2;};

void frobnicate(struct bar* x)
{
        printf("INSIDE: %d %d %d\n", x[0].member, x[1].member,
		x[2].member);
	x[0].member -= x[1].member;
}

int main()
{
        struct foo x[10];

        x[0].member = 10; x[1].member = 5; x[2].member = 1234;
        x[0].member2 = 31337;

        printf("BEFORE: %d %d\n", x[0].member, x[1].member);
        frobnicate(x);
        printf("AFTER: %d %d\n", x[0].member, x[1].member);
        return 0;
}
#v-

No i wewnątrz funkcji zamiast do member drugiego elementu tablicy
funkcja dostaje się do member2 pierwszego elementu tablicy. Może
niespecjalnie mnie to dziwi (i dlatego też myślę, że "działa dobrze"
może oznaczać, że psuje się jak powinno), ale szkoda, że nawet warninga
nie ma...

Czy metodologię testowania mam zepsutą? ;/

Pozdrawiam! 
-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

> Pozwoliłem sobie na potestowanie,
Skleroza nie boli. Stdout programu:
BEFORE: 10 5
INSIDE: 10 31337 5
AFTER: -31327 5

(g++ 4.1.2)
Pozdrawiam.
-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

Witam

Tomasz bla Fortuna wrote:

> Pozwoliłem sobie na potestowanie, bo w sumie mi też przykład się podoba.

Słusznie.

> struct bar {int member;};
> struct foo : public bar {int member2;};
> 
> void frobnicate(struct bar* x)

Co się tu dzieje? Funkcja pobiera wskaźnik do obiektu typu bar.

> {
>         printf("INSIDE: %d %d %d\n", x[0].member, x[1].member,
> x[2].member);
> x[0].member -= x[1].member;

A tu skąd kompilator ma wiedzieć, że skok iteratora z pozycji [0] do [1]
wynosi 8 a nie 4? 
Podany był w deklaracji bar, a bar ma rozmiar 4. 

Należy pomyśleć tak.
Co byłoby, gdyby klasa foo była zdefiniowana w całkiem innej bibliotece
dynamicznej. Skąd kompilator ma niby wiedzieć, że w tej bibliotece jest
jakiaś np. class baz : public bar { int a[100]; }, i że dla niego ten
iterator ma skakać o 4 * 100 + 4, przecież dla foo skacze o 8? 
Kompilator wykonuje dokładnie to co Pan Felix chciał. Może Pan Felix
powinien użyć zamiast bar *, bar **?

> }
> 
> int main()
> {
>         struct foo x[10];
> 
>         x[0].member = 10; x[1].member = 5; x[2].member = 1234;
>         x[0].member2 = 31337;
> 
>         printf("BEFORE: %d %d\n", x[0].member, x[1].member);
>         frobnicate(x);
>         printf("AFTER: %d %d\n", x[0].member, x[1].member);
>         return 0;
> }
> #v-
> 
> No i wewnątrz funkcji zamiast do member drugiego elementu tablicy
> funkcja dostaje się do member2 pierwszego elementu tablicy. Może
> niespecjalnie mnie to dziwi (i dlatego też myślę, że "działa dobrze"
> może oznaczać, że psuje się jak powinno), ale szkoda, że nawet warninga
> nie ma...
> 
> Czy metodologię testowania mam zepsutą? ;/

Metodologia jest dobra. 

Kod Pana F. jak dla mnie jest fatalny. Jak można obiekt polimorficzny
dokładnie rzutować na klasę bazową. W C++ takie "cóś" bardziej elegancko
robi się używając vector < smart_ptr <bar> >. Jak chce mieć stały rozmiar
polecam boost::array. 

Używanie polimorfizmu albo trzeba robić, jak to przystoi na wysokim poziomie
np. używając kontenery zamiast tablic i smart pointery a nie wskaźniki.

Albo należy spodziewać się klapsa to tu to tam, kiedy ktoś dziubie kod ala
C.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Hoobert pisze:
> Natkąłem się na takie coś: www.fefe.de/c++/c++-talk.pdf
> W sumie nic nowego, ale kilka rzeczy dość fajnie pokazanych jest.
> Jak dla mnie przykład z foo->bar w części "C++ is hard to read" jest
> dość wymowny.

Dla mnie C++ wygląda czasami jak wielogłowowa hydra, gdzie po ucięciu
jednej głowy, wyrastają trzy nowe, i potrzebny jest napradę zeje*isty
rycerz/haker żeby z całością sobie dać radę.

-- 
Semper Fidelis

Adam Klobukowski
adamklobukowski@gmail.com

Maciej Sobczak wrote:
> On 7 Lis, 21:51, Mateusz Loskot <see...@signature.net> wrote:
> 
>>>> Oj tak, konstrukcja "usnig namespace" powinna zniknąć z tego języka...
>>> Wystarczy, jeśli preprocesor wyłapywałby ją w nagłówkach i krzyczał.
>>
>> Aha, ale w sumie to można załatwić narzędziem o wdzięcznej
>> nazwie Vera++ ;-)
> 
> Nie jest to takie oczywiste, bo using namespace może być zupełnie
> sensownie użyte np. w ciele funkcji, która jest zdefiniowana w
> nagłowku. Np:
> 
> template <typename T>
> void print(const T & t)
> {
>     using namespace std;
>     cout << t;
> }
> 
> Nie ma powodu, żeby tego zabraniać a odróżnienie tego od tych
> "brzydkich" przypadków nie jest proste.
> Niemniej, taka reguła zostanie dodana.

Zgadzam się, choć zależy od tego czego delikwent chce się dowiedzieć o
swoim kodzie. Jeśli w projekcie po prostu zakazano stosowania using
namespace w nagłówkach, wtedy można określić dość prostą regułę.

Pozdrawiam
-- 
Mateusz Loskot
http://mateusz.loskot.net

Witam

Adam Klobukowski wrote:

> Dla mnie C++ wygląda czasami jak wielogłowowa hydra, gdzie po ucięciu
> jednej głowy, wyrastają trzy nowe, i potrzebny jest napradę zeje*isty
> rycerz/haker żeby z całością sobie dać radę.

Semper in altum :-).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Seweryn Habdank-Wojewódzki wrote:
>>struct bar {int member;};
>>struct foo : public bar {int member2;};
>>
>>void frobnicate(struct bar* x)
> 
> Co się tu dzieje? Funkcja pobiera wskaźnik do obiektu typu bar.
> 
> 
>>{
>>        printf("INSIDE: %d %d %d\n", x[0].member, x[1].member,
>>x[2].member);
>>x[0].member -= x[1].member;
> 
> 
> A tu skąd kompilator ma wiedzieć, że skok iteratora z pozycji [0] do [1]
> wynosi 8 a nie 4? 
> Podany był w deklaracji bar, a bar ma rozmiar 4. 


Skutek sp*pnego projektu języka. Jakby tablica nie była konwertowalna do 
wskażnika na jej pierwszy element to by nie było problemu.


> Należy pomyśleć tak.
> Co byłoby, gdyby klasa foo była zdefiniowana w całkiem innej bibliotece
> dynamicznej. Skąd kompilator ma niby wiedzieć, że w tej bibliotece jest
> jakiaś np. class baz : public bar { int a[100]; }, i że dla niego ten
> iterator ma skakać o 4 * 100 + 4, przecież dla foo skacze o 8? 

To jest błąd projektowy języka. Poważny.

Kompilator albo musi to wiedzieć a jak nie wie to albo trzeba wyliczenie 
kroku przenieść do runtime albo niedopuszczać takiej konstrukcji.

> Kompilator wykonuje dokładnie to co Pan Felix chciał. Może Pan Felix
> powinien użyć zamiast bar *, bar **?

Kompilator realizuje źle zaprojrktowany język. W źle zaprojektowanym języku 
kaszana jest na porządku dziennym.

> Kod Pana F. jak dla mnie jest fatalny. Jak można obiekt polimorficzny
> dokładnie rzutować na klasę bazową.

Co to znaczy dokładnie rzutować? Tu nic takiego nei ma.

> W C++ takie "cóś" bardziej elegancko
> robi się używając vector < smart_ptr <bar> >. Jak chce mieć stały rozmiar
> polecam boost::array. 
> 
> Używanie polimorfizmu albo trzeba robić, jak to przystoi na wysokim poziomie
> np. używając kontenery zamiast tablic i smart pointery a nie wskaźniki.
> 
> Albo należy spodziewać się klapsa to tu to tam, kiedy ktoś dziubie kod ala
> C.

Co to znaczy ala C? To jest właśnie skutek kulawego języka.

pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

>> A tu skąd kompilator ma wiedzieć, że skok iteratora z pozycji [0] do [1]
>> wynosi 8 a nie 4?
>> Podany był w deklaracji bar, a bar ma rozmiar 4.
> 
> 
> Skutek sp*pnego projektu języka. Jakby tablica nie była konwertowalna do
> wskażnika na jej pierwszy element to by nie było problemu.

Sebastian spójrz prawdzie w oczy. C++ powstał kiedy C był królem. Późniejsze
języki z miłą chęcią zgarnęły wszystkie doświadczenia ++ zarówno te dobre
jak i te złe. Wyjaśnij mi proszę fakt, czemu Smalltalk przeszedł do
historii, z ten badziewny C++ nie?

Zawrapowanie C było jego mocną stroną. Dziś ludziska mogą wybierać i
przebierać i mogą sobie łączyć języki jak im się podoba. Kiedyś tak nie
było!!! trzeba było osadzić język na mocnych podstawach innego języka, aby
to miało ręce i nogi. Zresztą dlaczego J ma "{"?
 
>> Kompilator wykonuje dokładnie to co Pan Felix chciał. Może Pan Felix
>> powinien użyć zamiast bar *, bar **?
> 
> Kompilator realizuje źle zaprojrktowany język. W źle zaprojektowanym
> języku kaszana jest na porządku dziennym.

Kaszana to jest w tym PDF, tam nie ma jednego kodu w typowym stylu ++.
To są potworki napisane przez C-geeka, które niczemu nie służą. 

Odpowiedz mi na jedno pytanie, czy taki kod masz w swoich kawałkach w C++?
Ja nie mam, jeśli to nie jest podyktowane jakimś mocnym argumentem za i
czasami mam tak kiedy wrapuję bibliotekę C i kod który ją owija czasem jest
syfiasty, bo np. biblioteka posługuje się void* (*) (void*). BTW wtedy
znienawidzone przez Was szablony to jedyne sensowne narzędzie sprzątające
taki gniot.
 
>> W C++ takie "cóś" bardziej elegancko
>> robi się używając vector < smart_ptr <bar> >. Jak chce mieć stały rozmiar
>> polecam boost::array.
>> 
>> Używanie polimorfizmu albo trzeba robić, jak to przystoi na wysokim
>> poziomie np. używając kontenery zamiast tablic i smart pointery a nie
>> wskaźniki.
>> 
>> Albo należy spodziewać się klapsa to tu to tam, kiedy ktoś dziubie kod
>> ala C.
> 
> Co to znaczy ala C? To jest właśnie skutek kulawego języka.

Zamiast tego kodu pracowałbym na vector < smart_ptr<bar> >.

Cieszę się, że ++ jest kulawy. Chociaż raczej określiłbym go jako taki co ma
trzecią nogę w postaci "C". I jak ktoś nie umie chodzić na 3 nogach to ma
problem, ale ten co umie chodzić na 3 nogach może mieć przewagę nad tymi do
chodzą na 2.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

On Thu, 08 Nov 2007 16:41:32 +0100
Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> wrote:

> 
> Cieszę się, że ++ jest kulawy. Chociaż raczej określiłbym go jako taki co ma
> trzecią nogę w postaci "C". I jak ktoś nie umie chodzić na 3 nogach to ma
> problem, ale ten co umie chodzić na 3 nogach może mieć przewagę nad tymi do
> chodzą na 2.
> 
Matka natura w skotek stosowania algorytmow ewolucyjnych uzana ze
jednak nie.

Witam

Sulsa wrote:

>> Cieszę się, że ++ jest kulawy. Chociaż raczej określiłbym go jako taki co
>> ma trzecią nogę w postaci "C". I jak ktoś nie umie chodzić na 3 nogach to
>> ma problem, ale ten co umie chodzić na 3 nogach może mieć przewagę nad
>> tymi do chodzą na 2.
>> 
> Matka natura w skotek stosowania algorytmow ewolucyjnych uzana ze
> jednak nie.

Widzisz kłopot polega na tym, że w rzeczywistości biologicznej rządzą inne
prawa niż w rzeczywistości technicznej. 

Przykładem są połączenia obiektów. W biologii musisz mieć kontakt stały, a
zatem wszelakie zginania i obroty o skończony kąt są dobre. 
Jednak pełne obroty już nie. Natomiast przemysł używa koła, chyba się
przemysłowcy coś pomylili. Napisz do nich, że błądzą, że powinni robić
rzeczy na 2 nogach (a nie np. na 4 kołach).

W organizmach żywych nie ma kół, bo koła wymagają zerwania kontaktu.
Wymagają, otwarcia organizmu. 

A zatem filozofia przenoszenia praw biologii na technikę może być marna w
skutkach. Nawet pojazdy do poruszania się w dziwnym terenie mają koła, a
nie "nogi". Te co mają nogi, są raczej mocno eksperymentalne i długo będą.
Zresztą jak mają nogi to też więcej niż 2. 

Czyżby człowiek mając dwie nogi był nie optymalnie wykonany? A może jest
doskonały, tylko że optimum ma inne cechy niż optimum dla pojazdów?

Pozdrawiam.

Ps. Cieszę się, że w projekcie łączysz ++ z Py. Tylko mam pytanie czemu
chcesz sobie życie obrzydzić? Po co piszesz swój projekt w ++ zamiast
wszystko napisać w Py.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

On Thu, 08 Nov 2007 20:38:01 +0100, Seweryn Habdank-Wojewódzki wrote:


> Czyżby człowiek mając dwie nogi był nie optymalnie wykonany? A może jest
> doskonały, tylko że optimum ma inne cechy niż optimum dla pojazdów?

Rozważyłbym optima globalne i lokalne  także :)

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Nie mogę znaleźć odpowiednich postów więc odpowiadam tutaj.
Właśnie przejrzałem http://en.wikipedia.org/wiki/C%2B%2B0x - i większość z 
wymienionych tutaj problemów będzie rozwiązana - włącznie z (void *)0, 
enumami itp. - jeśli dobrze rozumiem ;) Kiedy to będzie pozostaje kwestią 
otwartą.

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Maciej Piechotka pisze:
> Nie mogę znaleźć odpowiednich postów więc odpowiadam tutaj.
> Właśnie przejrzałem http://en.wikipedia.org/wiki/C%2B%2B0x - i większość z 
> wymienionych tutaj problemów będzie rozwiązana - włącznie z (void *)0, 
> enumami itp. - jeśli dobrze rozumiem ;) Kiedy to będzie pozostaje kwestią 
> otwartą.
> 
> Pozdrawiam

Raczej kwestia otwarta to: kiedy będą kompilatory, które tego używają,
no i kiedy będą kompilatory zgodne z istniejącym standardem... w końcu
każdy kompilator robi co innego i jak chcesz przenieść program z jednego
na drugi to musisz się nieco natrudzić :)

Dnia 12-11-2007, Pn o godzinie 10:09 +0100, Szymon pisze:

> Raczej kwestia otwarta to: kiedy będą kompilatory, które tego używają,

GCC wspiera coraz więcej C++0x.
http://gcc.gnu.org/projects/cxx0x.html

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Mon, 12 Nov 2007 16:11:44 +0100, Marcin ‘Qrczak’ Kowalczyk wrote:

> Dnia 12-11-2007, Pn o godzinie 10:09 +0100, Szymon pisze:
> 
>> Raczej kwestia otwarta to: kiedy będą kompilatory, które tego używają,
> 

To miałem na myśli właśnie ;) - przepraszam za niedopisanie.

> GCC wspiera coraz więcej C++0x.
> http://gcc.gnu.org/projects/cxx0x.html

Skąd ja znałem nazwę kompilatora który będzie miał prawdopodobnie jako 
pierwszy to zaimplementowane... ;)

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Witam

Maciej Piechotka wrote:

>> GCC wspiera coraz więcej C++0x.
>> http://gcc.gnu.org/projects/cxx0x.html
> 
> Skąd ja znałem nazwę kompilatora który będzie miał prawdopodobnie jako
> pierwszy to zaimplementowane... ;)

IMHO to nie jest dziwne. Większość dużych firm ma swoje języki/kompilatory,
środowiskom open pozostają języki ogólno-dostępne.
Głowni gracze już rozdali (sobie) karty

C# - M$,
Java - Sun, IBM,
Python 2.x jest ogólno-dostępny, 3k obawiam się, że licencja będzie
wskazywała że właścicielem będzie Google.
D - Digital Mars

C++ nie suportuje żadna firma tak wiec najlepszym kompilatorem jest ten
który oferuje community.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Seweryn Habdank-Wojewódzki wrote:
>>>A tu skąd kompilator ma wiedzieć, że skok iteratora z pozycji [0] do [1]
>>>wynosi 8 a nie 4?
>>>Podany był w deklaracji bar, a bar ma rozmiar 4.
>>
>>Skutek sp*pnego projektu języka. Jakby tablica nie była konwertowalna do
>>wskażnika na jej pierwszy element to by nie było problemu.
> 
> Sebastian spójrz prawdzie w oczy. C++ powstał kiedy C był królem.

Jak również Pascal, tudzież Lisp. Zaś wcześniej przetoczyły się Algol 60 i 
68, Simula 67, itd...

Było wiadomo, że parę rozwiązań jest "nie tego", ale zostały użyte.

Potem zaś, choć C++ niby wzbrania się przed "break existing code", złamano 
"existing code" w dodatku w rzeczy stosunkowo mało istotnej. A tam gdzie to 
dałoby większy pożytkiem, tchórzliwie pozostawiono kaszanę.


> Późniejsze
> języki z miłą chęcią zgarnęły wszystkie doświadczenia ++ zarówno te dobre
> jak i te złe. Wyjaśnij mi proszę fakt, czemu Smalltalk przeszedł do
> historii, z ten badziewny C++ nie?

Bo narodziła się Java, która wystarczająco dobrze łączy hierarhię obiektów 
Smalltalka ze składnią klamerkową i z przywyczajeniami ludu do pracy na 
plikach, używając ulubionego edytora, systemu kontroli wersji itd,  a nie w 
zamkniętym środowisku.


> Zawrapowanie C było jego mocną stroną. Dziś ludziska mogą wybierać i
> przebierać i mogą sobie łączyć języki jak im się podoba. Kiedyś tak nie
> było!!! trzeba było osadzić język na mocnych podstawach innego języka, aby
> to miało ręce i nogi. Zresztą dlaczego J ma "{"?

J została osadzona na mocnych podstawach C++ po odrzuceniu niepotrzebengo 
(jak również i potrzebnego :) ) bagażu.


>>>Kompilator wykonuje dokładnie to co Pan Felix chciał. Może Pan Felix
>>>powinien użyć zamiast bar *, bar **?
>>
>>Kompilator realizuje źle zaprojrktowany język. W źle zaprojektowanym
>>języku kaszana jest na porządku dziennym.
> 
> Kaszana to jest w tym PDF, tam nie ma jednego kodu w typowym stylu ++.

Pokaż mi "typowy styl C++" -- nie ma takiego.

> To są potworki napisane przez C-geeka, które niczemu nie służą. 

Które pokazują konkretne problemy.

> 
> Odpowiedz mi na jedno pytanie, czy taki kod masz w swoich kawałkach w C++?

Ja mam swój styl. Nawet 2 style -- jeden firmowy, z użyciem firmowych 
bibliotek i drugi własny (z np. silnym użyciem Śmieciucha). Oba są bardzo 
różne od stylu boosta czy paru innych.

[...]

>>>Albo należy spodziewać się klapsa to tu to tam, kiedy ktoś dziubie kod
>>>ala C.
>>
>>Co to znaczy ala C? To jest właśnie skutek kulawego języka.
> 
> Zamiast tego kodu pracowałbym na vector < smart_ptr<bar> >.

Czyli obejściem kulawości języka

> Cieszę się, że ++ jest kulawy. Chociaż raczej określiłbym go jako taki co ma
> trzecią nogę w postaci "C". I jak ktoś nie umie chodzić na 3 nogach to ma
> problem, ale ten co umie chodzić na 3 nogach może mieć przewagę nad tymi do
> chodzą na 2.

Jakoś tak wyszło że lepiej miec 2 albo 4. Na 3 przy chodzeniu 
niesymetrycznie się obciążenia rozkładają.

pzdr
\SK

Dnia Wed, 7 Nov 2007 01:26:33 +0100, Tomasz bla Fortuna skrobie:
> [-- text/plain, encoding quoted-printable, charset: ISO-8859-2, 57 lines --]

> Dnia Tue, 06 Nov 2007 23:34:04 +0100
> Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> napisał(a):

> > > Mi sie spodobal kod ze strony 48, nigdy bym sie nie spodziewal
> > > bledu w takim miejscu.
> > 
> > Zacząłbym od tego, że ten kod się nie kompiluje. 
> > Po upgrade, aby mógł się kompilować wszystko działa dobrze. 

> Nie wiem czy dobrze interpretuję "wszystko działa dobrze". ;-)

> Pozwoliłem sobie na potestowanie, bo w sumie mi też przykład się podoba.
> #v+
> #include <stdio.h>

> struct bar {int member;};
> struct foo : public bar {int member2;};

> void frobnicate(struct bar* x)
> {
>         printf("INSIDE: %d %d %d\n", x[0].member, x[1].member,
>                 x[2].member);
>         x[0].member -= x[1].member;
> }

> int main()
> {
>         struct foo x[10];

>         x[0].member = 10; x[1].member = 5; x[2].member = 1234;
>         x[0].member2 = 31337;

>         printf("BEFORE: %d %d\n", x[0].member, x[1].member);
>         frobnicate(x);
>         printf("AFTER: %d %d\n", x[0].member, x[1].member);
>         return 0;
> }
> #v-

> No i wewnątrz funkcji zamiast do member drugiego elementu tablicy
> funkcja dostaje się do member2 pierwszego elementu tablicy. Może
> niespecjalnie mnie to dziwi (i dlatego też myślę, że "działa dobrze"
> może oznaczać, że psuje się jak powinno), ale szkoda, że nawet warninga
> nie ma...

Moment - na co przepraszam chcesz mieć warning?

Zdecyduj ty się może, czy przekazujesz pojedynczy obiekt, czy przekazujesz
wskazanie na pojedynczy element tablicy (i, co ważniejsze, wiesz na pewno,
że za nim znajdują się w tej tablicy jeszcze co najmniej dwa elementy).

Oczywiście, nikt nie będzie zaprzeczał, że zunifikowanie iteratora do tablicy
z wskaźnikiem na pojedynczy obiekt, jest poważną wadą - istnieje jednak od
początków języka C i jak zatwierdzano standard, nikt nie widział w tym żadnego
problemu. A C++ nie był w stanie niczego z tym zrobić. W C++ i tak jest duży
postęp przez to, że nie można domyślnie konwertować niespokrewnionych
wskaźników.

> Czy metodologię testowania mam zepsutą? ;/

W przypadku języka C, faktycznie, nie jesteś w stanie ustrzec się takiego
błędu. Ciesz się, jeśli kompilator rzuci warning, że konwertujesz różne
typy wskaźnikowe (bo nie musi rzucać - w ANSI C nie jest to błąd).

W przypadku C++ można się tego ustrzec o tyle, o ile się będzie pamiętać, żeby
nie stosować operatora [] na typie X* - jeśli się miało na myśli tablicę,
należy jawnie napisać, że chodzi o iterator. W takim przypadku przynajmniej
nie będzie można takiego programu skompilować.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

Dnia Thu, 15 Nov 2007 00:32:51 +0000 (UTC)
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
napisał(a):

> > No i wewnątrz funkcji zamiast do member drugiego elementu tablicy
> > funkcja dostaje się do member2 pierwszego elementu tablicy. Może
> > niespecjalnie mnie to dziwi (i dlatego też myślę, że "działa dobrze"
> > może oznaczać, że psuje się jak powinno), ale szkoda, że nawet
> > warninga nie ma...
> 
> Moment - na co przepraszam chcesz mieć warning?
Było by fajnie dostać po głowie za, chociażby, upcastowanie
wskaźnika na tablicę obiektów. Albo za użycie [] na wskaźniku obiektu,
który znajduje się w jakiejś hierarchii obiektów.

Abstrahuję od realizowalności takiego warninga.
> 
> Zdecyduj ty się może, czy przekazujesz pojedynczy obiekt, czy
> przekazujesz wskazanie na pojedynczy element tablicy
Wskazanie na pierwszy element tablicy - jej początek. Funkcja może
nawet za argument brać struct bar x[], co nic nie zmieni.

> (i, co ważniejsze, wiesz na pewno, że za nim znajdują się w tej
> tablicy jeszcze co najmniej dwa elementy).
Ilość elementów nie gra roli -- ją mogę przekazać jako drugi parametr
lub jako NULL pod ostatnim adresem tablicy.

> Oczywiście, nikt nie będzie zaprzeczał, że zunifikowanie iteratora do
> tablicy z wskaźnikiem na pojedynczy obiekt, jest poważną wadą -
> istnieje jednak od początków języka C i jak zatwierdzano standard,
> nikt nie widział w tym żadnego problemu.
Pytanie czy właśnie nie powinien widzieć. ;) (Mówię o standardzie C++,
w C - ok)

> A C++ nie był w stanie
> niczego z tym zrobić. W C++ i tak jest duży postęp przez to, że nie
> można domyślnie konwertować niespokrewnionych wskaźników.
"No jest zepsute. Ale przecież mogło być znacznie gorzej"

> 
> > Czy metodologię testowania mam zepsutą? ;/
> 
> W przypadku języka C, faktycznie, nie jesteś w stanie ustrzec się
> takiego błędu.
W C takiego błędu by nie było. W C bym nie upcastował nigdy wskaźnika
na klasę. Bo.. no nie ma klas. Jeśli funkcja dostaje wskaźnik do
tablicy elementów A typu T i jej wielkość to A[0] to pierwszy
element, a A[1] to drugi element, a nie dalszy kawałek A[0], który
okazał się być jednak innego typu niż T.

A nawet jakbym rzutował w C większe structy na mniejsze to nie jest to
tak naturalne jak w C++ upcasting. W Idealnych warunkach ten przykład
nie powinien się skompilować bez zastosowania reinterpret_cast<>.

> Ciesz się, jeśli kompilator rzuci warning, że
> konwertujesz różne typy wskaźnikowe (bo nie musi rzucać - w ANSI C
> nie jest to błąd).
A to inna sprawa jest.

> W przypadku C++ można się tego ustrzec o tyle, o ile się będzie
> pamiętać, żeby nie stosować operatora [] na typie X* - jeśli się
> miało na myśli tablicę, należy jawnie napisać, że chodzi o iterator.
> W takim przypadku przynajmniej nie będzie można takiego programu
> skompilować.
No tak. Jedyny problem jest taki, że można zrobić tak jak w tym kodzie i
nikt nas (prócz segmentation fault) nie poinformuje, że zrobiliśmy
cokolwiek źle.

Pozdrawiam.
-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

Tomasz bla Fortuna wrote:
>>W przypadku języka C, faktycznie, nie jesteś w stanie ustrzec się
>>takiego błędu.
> 
> W C takiego błędu by nie było. W C bym nie upcastował nigdy wskaźnika
> na klasę. Bo.. no nie ma klas. Jeśli funkcja dostaje wskaźnik do
> tablicy elementów A typu T i jej wielkość to A[0] to pierwszy
> element, a A[1] to drugi element, a nie dalszy kawałek A[0], który
> okazał się być jednak innego typu niż T.
> 
> A nawet jakbym rzutował w C większe structy na mniejsze to nie jest to
> tak naturalne jak w C++ upcasting. W Idealnych warunkach ten przykład
> nie powinien się skompilować bez zastosowania reinterpret_cast<>.

Tak powinno być, gdyby w C++ nie było tego poważnego błedu projektowego.

Można to było rozwiązać na różne sposoby.

Np, jeśli już koniecznie musimy akurat ten quirk z C przejmować (wywalając 
parę innych, takich jak typ funkcja(), konwersje między różnymi wskaźnikami, 
itd) to można było choć w wprowadzić jakieś sensowne rozróżnienie na POD i 
nie-POD. Naprzykład takie class to jest w zasadzie to samo co
struct { private:. Nic więc nie wnosi. A gdyby struct było zawsze POD, a 
class nigdy POD i dla nie-POD odróżnić twardo * od [] (przy okazji w class 
wywalić domyślny konstruktor kopiujący i przypisanie) byłoby już lepiej.


pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

> Bo narodziła się Java, która wystarczająco dobrze łączy hierarhię obiektów
> Smalltalka ze składnią klamerkową i z przywyczajeniami ludu do pracy na
> plikach, używając ulubionego edytora, systemu kontroli wersji itd,  a nie
> w zamkniętym środowisku.

Widzisz Ty J-codera, który pisze bez IDE? Py-coder i owszem, ale J-coderów
piszących w vim/emacs nie widuję. Tak więc J-powraca do zamkniętego
środowiska, szybciej niż się z niego urwała.
 
> Pokaż mi "typowy styl C++" -- nie ma takiego.

Kurs podstawowy zaczynam od książki Koenig Moo. To jest dla mnie "basic
legal style". Jak piszesz jak w tej książce (domyślnie to jest bezpieczne),
to przechodzenie na ciemną stronę mocy jest spokojne.

>> To są potworki napisane przez C-geeka, które niczemu nie służą.
> 
> Które pokazują konkretne problemy.

Tak, ale kod wydumany, nigdy nikt po kursie Koenig Moo tak nie napisze (by
default). Oczywiście, że tak się da pisać, ale chodzi o poprawne nawyki.
 
> Ja mam swój styl. Nawet 2 style -- jeden firmowy, z użyciem firmowych
> bibliotek i drugi własny (z np. silnym użyciem Śmieciucha). Oba są bardzo
> różne od stylu boosta czy paru innych.

Człowieku, ale Ty jesteś koderem z doświadczeniem i nie wierzę, że Twoje
style są takie jak Pana F.

>> Zamiast tego kodu pracowałbym na vector < smart_ptr<bar> >.
> 
> Czyli obejściem kulawości języka

Nie. To się nazywa znajomość bibliotek?
 
>> Cieszę się, że ++ jest kulawy. Chociaż raczej określiłbym go jako taki co
>> ma trzecią nogę w postaci "C". I jak ktoś nie umie chodzić na 3 nogach to
>> ma problem, ale ten co umie chodzić na 3 nogach może mieć przewagę nad
>> tymi do chodzą na 2.
> 
> Jakoś tak wyszło że lepiej miec 2 albo 4. Na 3 przy chodzeniu
> niesymetrycznie się obciążenia rozkładają.

Dorzucam 4 nogę w postaci inline (lub nie) Asemblera. Osobiście rzadko z
tego korzystam. 
Ale zapytaj kowboja Piotra wyderskiego, czy na tym czworonożnym bydlątku
jeździ się jak na mule, czy jak na ognistym rumaku?

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Seweryn Habdank-Wojewódzki wrote:
>>Bo narodziła się Java, która wystarczająco dobrze łączy hierarhię obiektów
>>Smalltalka ze składnią klamerkową i z przywyczajeniami ludu do pracy na
>>plikach, używając ulubionego edytora, systemu kontroli wersji itd,  a nie
>>w zamkniętym środowisku.
> 
> Widzisz Ty J-codera, który pisze bez IDE? Py-coder i owszem, ale J-coderów
> piszących w vim/emacs nie widuję. Tak więc J-powraca do zamkniętego
> środowiska, szybciej niż się z niego urwała.

To nie jest zamknięte środowisko. Takie Eclipse to je jest J2EE. System 
pilków też jest poza Eclipse. Webserwer, nawet kobyła z wbudowanym wszytskim 
z J2EE, EJB itd, taka w rodzaju WebLogica to też nie edytor.
W Smalltalku miałeś połączone wszystko -- to myła totalna (totalitarna) 
przestrzeń obiektów, w której miałeś obiekt edytora, viewera kodu, debugera. 
Tu miałeś obiekty klas środowiska jak i swoich własnych klas. Tak jak wielu 
ludzi nie ma kompuetra tylko budełko na których chodzi Word, tak 
smalltalkowiec miał pudełko na którym żyła przestrzeń Smalltalka. Jak 
wychodziłeś ze środowiska to zapisywałeś nie konkretne pliki tylko kazałeś 
zapamiętać aktualny stan środowiska jako całości.

Oczywiście w środowiskach do robienia kodu produkcyjnego (a nie tylko zabawy 
i edukacji) były narządy do wyekstrachowania konkretnej aplikacji i 
zrobienia z niej systemu stand-alone, uruchamianaego z poziomu systemu 
operacyjnego a nie przez kliknięcie w run w obiekcie edytora. Była też 
możliwość wyciągnięcia źródeł wybranych w postaci pliku. Ale i to i to były 
dodatki, do języka, dostosowujące impedancję do świata zewnętrznego.


>>>Zamiast tego kodu pracowałbym na vector < smart_ptr<bar> >.
>>
>>Czyli obejściem kulawości języka
> 
> Nie. To się nazywa znajomość bibliotek?

Takie rzeczy to powinny być w języku.


[...]
pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

>> Widzisz Ty J-codera, który pisze bez IDE? Py-coder i owszem, ale
>> J-coderów piszących w vim/emacs nie widuję. Tak więc J-powraca do
>> zamkniętego środowiska, szybciej niż się z niego urwała.
> 
> To nie jest zamknięte środowisko. Takie Eclipse to je jest J2EE. System
> pilków też jest poza Eclipse. Webserwer, nawet kobyła z wbudowanym
> wszytskim z J2EE, EJB itd, taka w rodzaju WebLogica to też nie edytor.
> W Smalltalku miałeś połączone wszystko -- to myła totalna (totalitarna)
> przestrzeń obiektów, w której miałeś obiekt edytora, viewera kodu,
> debugera. Tu miałeś obiekty klas środowiska jak i swoich własnych klas.
> Tak jak wielu ludzi nie ma kompuetra tylko budełko na których chodzi Word,
> tak smalltalkowiec miał pudełko na którym żyła przestrzeń Smalltalka. Jak
> wychodziłeś ze środowiska to zapisywałeś nie konkretne pliki tylko kazałeś
> zapamiętać aktualny stan środowiska jako całości.
> 
> Oczywiście w środowiskach do robienia kodu produkcyjnego (a nie tylko
> zabawy i edukacji) były narządy do wyekstrachowania konkretnej aplikacji i
> zrobienia z niej systemu stand-alone, uruchamianaego z poziomu systemu
> operacyjnego a nie przez kliknięcie w run w obiekcie edytora. Była też
> możliwość wyciągnięcia źródeł wybranych w postaci pliku. Ale i to i to
> były dodatki, do języka, dostosowujące impedancję do świata zewnętrznego.

No to nie rozumiałem co masz na myśli.
 
>>>>Zamiast tego kodu pracowałbym na vector < smart_ptr<bar> >.
>>>
>>>Czyli obejściem kulawości języka
>> 
>> Nie. To się nazywa znajomość bibliotek?
> 
> Takie rzeczy to powinny być w języku.

IMHO nie, jeśli język dysponuje wystarczalną wyrażalnością. Chyba tak było w
językach funkcyjnych, że one nie miały listy, tylko była para, a lista była
indukowana z paty zawierającej element i kolejna parę (ale mogę się mylić).

W każdym razie w matematyce tak jest i to wystarczy, dla mnie cenniejsza
jest swoboda projektowa i wyrażalność niż to czy język oferuje listę, czy
jest ona w stdlib.

Tak całkiem na marginesie. Ostatnio w Pythonie naciąłem się na taki problem.

Możesz słownik opisać tak:

dict({A=10, B=20, C=30})

Natomiast tego co poniżej nie możesz zrobić. Naszczęście wyjaśniono mi
dlaczego, ale tego "wyjątku" nie ma w manualu. 

dict({'proces_A'=dict({'object_1'=('message_name_1','message_name_2'),
'object_2'=('message_1')}),
'process_B'=dict({'object_1'=('message_name_1','message_name_2'),
'object_2'=('message_1')})}) 

Jak myślisz czy to jest taka sytuacja jak z quirkami C++? Oczywiście nie
martw się, nie narzekam, że takiego czegoś NIE mogę zrobić w Pythonie, bo
jest na to coś czego nie lubisz, a ja to uznaje jako normę --- tak
domyśliłeś się --- to nazywa się OBEJŚCIE :-D. 
Naszczęście obejścia nie są dla mnie wadą. Szczególnie te, które da się
wytłumaczyć i które są konsekwentne. Cóż w każdym języku są obejścia i
quirki.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia 22-11-2007, Cz o godzinie 20:34 +0100, Seweryn Habdank-Wojewódzki
pisze:

> Tak całkiem na marginesie. Ostatnio w Pythonie naciąłem się na taki problem.
> 
> Możesz słownik opisać tak:
> 
> dict({A=10, B=20, C=30})

Wcale nie. Możesz tak:

   dict(A=10, B=20, C=30)

albo tak:
   
   {'A':10, 'B':20, 'C':30}

> Natomiast tego co poniżej nie możesz zrobić. Naszczęście wyjaśniono mi
> dlaczego, ale tego "wyjątku" nie ma w manualu. 
> 
> dict({'proces_A'=dict({'object_1'=('message_name_1','message_name_2'),
> 'object_2'=('message_1')}),
> 'process_B'=dict({'object_1'=('message_name_1','message_name_2'),
> 'object_2'=('message_1')})}) 

Jakiego wyjątku? Dlaczego miałoby się dać? Możesz tak:

   dict(proces_A=dict(object_1=('message_name_1','message_name_2'),
   object_2=('message_1')),
   process_B=dict(object_1=('message_name_1','message_name_2'),
   object_2=('message_1')))

albo tak:

   {'proces_A':{'object_1':('message_name_1','message_name_2'),
   'object_2':('message_1')},
   'process_B':{'object_1':('message_name_1','message_name_2'),
   'object_2':('message_1')}}

Jakie obejście?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Witam

Marcin ?Qrczak? Kowalczyk wrote:

> Wcale nie. Możesz tak:
> 
>    dict(A=10, B=20, C=30)

Masz rację nawiasy wstawiłem odruchowo.
 
Przestudiuj może przykład poniżej i powiedz mi co to znaczy w tym
kontekście "SyntaxError: *keyword* can't be an expression", dla mnie ten
błąd jest nieczytelny.

Przykład 1:

#!/usr/bin/env python

def main(argv):
    a = dict (one two=12, two three=23)
    #a = {'one two':12,'two three':23}
    print a

if  __name__ == '__main__':
    import sys
    sys.exit (main (sys.argv))

Przykład 2:

#!/usr/bin/env python

def main(argv):
    a = dict ('one two'=12, 'two three'=23)
    #a = {'one two':12,'two three':23}
    print a

if  __name__ == '__main__':
    import sys
    sys.exit (main (sys.argv))


Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia 22-11-2007, Cz o godzinie 21:18 +0100, Seweryn Habdank-Wojewódzki
pisze:

>     a = dict (one two=12, two three=23)

Ta składnia przypomina wołanie funkcji z nazwanymi argumentami, ale
zamiast identyfikatora będącego nazwą argumentu są dwa identyfikatory.

>     a = dict ('one two'=12, 'two three'=23)

A tutaj zamiast identyfikatora jest literał.

Czego oczekujesz? To tak jakbyś w C++ napisał:

   int jedna funkcja() {
      return 1;
   }

   int "druga funkcja"() {
      return 2;
   }

i dziwił się, że to błędy składniowe.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Witam

Marcin ?Qrczak? Kowalczyk wrote:

> Dnia 22-11-2007, Cz o godzinie 21:18 +0100, Seweryn Habdank-Wojewódzki
> pisze:
> 
>>     a = dict (one two=12, two three=23)
> 
> Ta składnia przypomina wołanie funkcji z nazwanymi argumentami, ale
> zamiast identyfikatora będącego nazwą argumentu są dwa identyfikatory.
> 
>>     a = dict ('one two'=12, 'two three'=23)
> 
> A tutaj zamiast identyfikatora jest literał.

CZŁOWIEKU MYŚLĄCY!!!

Przecież wiem, że to jest złe!!!

Chodzi mi o fakt, że teoretycznie zapis

{'A':2,'B':3}

ma odpowiednik w:

dict(A=2, B=3)

Ale....

nie kiedy coś pokombinujesz, czyli

{'A B':23,'B C':34}

to tego nie bardzo da się zapisać dictem. To nazywam "wyjątkiem od reguły",
quirkiem (whatever).

Chyba, że znowu mnie czymś zaskoczysz?

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia 23-11-2007, Pt o godzinie 00:15 +0100, Seweryn Habdank-Wojewódzki
pisze:

> {'A B':23,'B C':34}
> 
> to tego nie bardzo da się zapisać dictem. To nazywam "wyjątkiem od
> reguły", quirkiem (whatever).

Cóż, C++ też nie pozwala użyć dowolnego ciągu znaków jako identyfikatora.
Tyle tylko, że C++ bardzo rzadko wykorzystuje brzmienie identyfikatora
w czasie wykonania. Może ono zostać złapane przez konstrukcję #foo
preprocesora i jeśli jakaś biblioteka ma interfejs w tej formie
(tzn. oczekuje, że kod używający biblioteki przekaże jej coś, co
zostanie w ten sposób zestrigifikowane), to też nie można przekazać
tą drogą dowolnego stringa. Są języki, w których za pomocą odpowiedniego
cytowania można zbudować identyfikator z dowolnego ciągu znaków, np.
Common Lisp i Kogut.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On 23 Lis, 01:11, Marcin 'Qrczak' Kowalczyk <qrc...@knm.org.pl> wrote:

> Są języki, w których za pomocą odpowiedniego
> cytowania można zbudować identyfikator z dowolnego ciągu znaków, np.
> Common Lisp i Kogut.

Oraz np. Tcl, ale właśnie to jest jedna z tych cech, które sprawiają,
że Tcl jest nieco "lispowaty".

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Witam

Marcin ?Qrczak? Kowalczyk wrote:

> Dnia 23-11-2007, Pt o godzinie 00:15 +0100, Seweryn Habdank-Wojewódzki
> pisze:
> 
>> {'A B':23,'B C':34}
>> 
>> to tego nie bardzo da się zapisać dictem. To nazywam "wyjątkiem od
>> reguły", quirkiem (whatever).
> 
> Cóż, C++ też nie pozwala użyć dowolnego ciągu znaków jako identyfikatora.

Otóż to Qrczaku, otóż to. Jak to się mówi "Niech pierwszy rzuci kamień ten
co jest bez winy."? 

A my tu mamy decyzję projektantów, quirk, wyjątek w języku, nazwij jak
chcesz. Jeszcze raz podkreślam, wiem i zgadzam się z tym, że C++ ma wady,
ale nie ma języka bez nich.

> Tyle tylko, że C++ bardzo rzadko wykorzystuje brzmienie identyfikatora
> w czasie wykonania. Może ono zostać złapane przez konstrukcję #foo
> preprocesora i jeśli jakaś biblioteka ma interfejs w tej formie
> (tzn. oczekuje, że kod używający biblioteki przekaże jej coś, co
> zostanie w ten sposób zestrigifikowane), to też nie można przekazać
> tą drogą dowolnego stringa.

To jest za mądre dla mnie. Czy możesz napisać jakiś obrazowy kod, albo jakoś
innymi słowami to napisać.

> Są języki, w których za pomocą odpowiedniego 
> cytowania można zbudować identyfikator z dowolnego ciągu znaków, np.
> Common Lisp i Kogut.

Jak już mowa o zaletach Koguta, to zapytam kiedy wydasz jakiś beginer
tutorial, bo z niecierpliwością czekam na niego, a przyznam się szczerze,
że mój mały rozumek tego co jest na stronie WWW nie dociera do mnie.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia 23-11-2007, Pt o godzinie 22:27 +0100, Seweryn Habdank-Wojewódzki
pisze:

> > Tyle tylko, że C++ bardzo rzadko wykorzystuje brzmienie identyfikatora
> > w czasie wykonania. Może ono zostać złapane przez konstrukcję #foo
> > preprocesora i jeśli jakaś biblioteka ma interfejs w tej formie
> > (tzn. oczekuje, że kod używający biblioteki przekaże jej coś, co
> > zostanie w ten sposób zestrigifikowane), to też nie można przekazać
> > tą drogą dowolnego stringa.
> 
> To jest za mądre dla mnie. Czy możesz napisać jakiś obrazowy kod, albo jakoś
> innymi słowami to napisać.

Zagadnienie nie jest warte tego, żeby się nad nim rozwodzić. Poważny kod
C++ nie będzie używał stringifikowanych argumentów makr jako jedynego
mechanizmu przekazywania stringów, które mogą brzmieć dowolnie, więc
problem jest hipotetyczny. Nie wykluczam, że jakaś biblioteka mogła
go popełnić (może jakieś wiązanie z bazą danych albo z innym językiem
postanowiło oczekiwać składni bez ""), ale wątpię. Zresztą można by go
w konkretnym przypadku obejść zaglądając do definicji makr.

W Pythonie też można to obejść, jeśli jakieś stringi można przekazać
wyłącznie w formie nazw nazwanych argumentów funkcji, a chcemy akurat
przekazać stringa, który nie wygląda jak identyfikator. Wywołanie
f(1, foo=2, bar=3) jest równoważne f(1, **{'foo':2, 'bar':3}), a tu już
można użyć dowolnych kluczy. Podobnie jak poprzednio problem jest raczej
hipotetyczny. dict(foo=1, bar=2) jest po prostu skrótową możliwością
opisania zawartości słownika, którego klucze wyglądają jak identyfikatory;
możliwość zapisania takiej składni istniała tak czy siak - taka jej
interpretacja sama się narzucała, więc swego czasu ją dodano.

Perl ma inną wariację na temat zamiany identyfikatora na string:
operator => znaczy tyle, co przecinek, ale jeśli wyrażenie po lewej to
goły identyfikator, to jest on traktowany jako string. Podobnie dzieje
się w kilku innych kontekstach. To jest o tyle nieszkodliwe, że w Perlu
wyrażenie rzadko kiedy ma postać gołego identyfikatora (zmienne mają $
przed nazwą). No i można wziąć stringa w "" albo '', jeśli nie wygląda
jak identyfikator.

Lisp i Kogut mają jeszcze inne konstrukcje składniowe, w których coś,
co wygląda jak identyfikator, kończy jako string albo coś podobnego.

> Jak już mowa o zaletach Koguta, to zapytam kiedy wydasz jakiś beginer
> tutorial,

Nieprędko. Ale robię porządniejszy reference manual (zresztą inną
techniką: LaTeX -> PDF) i on na pewno będzie w miarę gotowy za parę
miesięcy.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Dnia Thu, 22 Nov 2007 15:13:11 +0100, Sebastian Kaliszewski skrobie:
> Seweryn Habdank-Wojewódzki wrote:
> >>Bo narodziła się Java, która wystarczająco dobrze łączy hierarhię obiektów
> >>Smalltalka ze składnią klamerkową i z przywyczajeniami ludu do pracy na
> >>plikach, używając ulubionego edytora, systemu kontroli wersji itd,  a nie
> >>w zamkniętym środowisku.
> > 
> > Widzisz Ty J-codera, który pisze bez IDE? Py-coder i owszem, ale J-coderów
> > piszących w vim/emacs nie widuję. Tak więc J-powraca do zamkniętego
> > środowiska, szybciej niż się z niego urwała.

> To nie jest zamknięte środowisko. Takie Eclipse to je jest J2EE. System 
> pilków też jest poza Eclipse. Webserwer, nawet kobyła z wbudowanym wszytskim 
> z J2EE, EJB itd, taka w rodzaju WebLogica to też nie edytor.
> W Smalltalku miałeś połączone wszystko -- to myła totalna (totalitarna) 
> przestrzeń obiektów, w której miałeś obiekt edytora, viewera kodu, debugera. 
> Tu miałeś obiekty klas środowiska jak i swoich własnych klas. Tak jak wielu 
> ludzi nie ma kompuetra tylko budełko na których chodzi Word, tak 
> smalltalkowiec miał pudełko na którym żyła przestrzeń Smalltalka. Jak 
> wychodziłeś ze środowiska to zapisywałeś nie konkretne pliki tylko kazałeś 
> zapamiętać aktualny stan środowiska jako całości.

> Oczywiście w środowiskach do robienia kodu produkcyjnego (a nie tylko zabawy 
> i edukacji) były narządy do wyekstrachowania konkretnej aplikacji i 
> zrobienia z niej systemu stand-alone, uruchamianaego z poziomu systemu 
> operacyjnego a nie przez kliknięcie w run w obiekcie edytora. Była też 
> możliwość wyciągnięcia źródeł wybranych w postaci pliku. Ale i to i to były 
> dodatki, do języka, dostosowujące impedancję do świata zewnętrznego.

Ależ Javie powoli niewiele zaczyna do tego brakować.

Java ma WSZYSTKO swoje - i tak na dobrą sprawę może się spokojnie obyć bez
systemu operacyjnego. Na dobrą sprawę mógłby być zrobiony system w Javie,
tylko trzeba mieć jakąkolwiek najmarniejszą implementację JVM. A do tego
system operacyjny na upartego nie jest konieczny.

Pisałem zresztą o tym w felietonie.

> >>>Zamiast tego kodu pracowałbym na vector < smart_ptr<bar> >.
> >>
> >>Czyli obejściem kulawości języka
> > 
> > Nie. To się nazywa znajomość bibliotek?

> Takie rzeczy to powinny być w języku.

Wolisz żeby takie coś było od początku podane w języku, ale żeby język nie
posiadał możliwości zdefiniowania czegoś takiego?

Ja to przede wszystkim pozbyłbym się w ogóle wskaźników X*.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

Witam

Marcin ?Qrczak? Kowalczyk wrote:

>> To jest za mądre dla mnie. Czy możesz napisać jakiś obrazowy kod, albo
>> jakoś innymi słowami to napisać.
> 
> Zagadnienie nie jest warte tego, żeby się nad nim rozwodzić.

[...]

> Lisp i Kogut mają jeszcze inne konstrukcje składniowe, w których coś,
> co wygląda jak identyfikator, kończy jako string albo coś podobnego.

Dzięki już rozumiem co miałeś na myśli.

> Ale robię porządniejszy reference manual (zresztą inną techniką: LaTeX ->
> PDF) 

Jak dla mnie to jedyna słuszna opcja. Mam powyżej uszu drukowanie paskudnego
HTML. A z ekranu nie lubię czytać, bo codziennie czytam tego o wiele za
dużo.

> i on na pewno będzie w miarę gotowy za parę miesięcy.

Trzymam kciuki.

Pozdrawiam.


-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/