🚀 go-pugleaf

On Sat, 03 Nov 2007 10:47:38 +0100, Hoobert 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.

1. Warm-up. 'Błąd' kompilatora (tzn. brak zwijania templatów). Chyba jest 
planowane załatanie
2. Ever Changing Style. Pierwsze się chyba nadal stosuje do zwykłych petli 
a drugie do iteratorów.
3. C++ is hard to parse. Kompilatory (m. innymi używany przez autora g++) 
mają zabezpiecznie np, do 100 iteracji
4. C++ is hard to parse. Każdy język zapisany ciagłym kodem i 
niezalecanymi własciwościami jest nieczytelny. A czytelności nieczytalnego 
algorytmu język nie poprawi...
5. C++ is hard to parse. (foo) + a*b. cos(ab) powinno być równoważen 
a*b*c*o*s. A nie jest ;)
6. C++ is hard to write. Rozpacz, że cin kowertuje się do void *. Wynika z 
założeń kompatybilności z C. Kompatybilność z C jest potrzebna (chyba, że 
ktoś kocha pisać wrappery).
7. Iterators and their Containers. Don’t know anything about the container.
a) Co jeśli nie są związane z kontenerem tylko iterują między np. 1 a 6 
(dlaczego nie)?
b) Co jeśli mamy merge_iterator(begin1, end1, begin2, end2) który iteruje 
między begin1 aż do end1 (wyłącznie) a potem od begin2 do end2?
8. Bounds Checking. Szkoda, że programista może wybrać szybki nóż, którym 
może się pokaleczyć. Najlepiej mu go zabrać ;)
9. Virtual functions in con/destructor. Można prosić o rozwiązanie 
problemu bez odwoływania się do 'nieprzyzwoitej wiedzy' obiektu potomnego 
o rodzicu?

class A
{
protected:
  int x;
  int y;
public:
  virtual int
  a()
  {
    return 0;
  }
  virtual int
  b()
  {
    return 0;
  }
  A()
  {
    x = a();
    y = b();
  }
}

class B : public A
{
public:
  virtual int
  a()
  {
    return y; //Ops. A nie jest gotowe...
  }
}

Klasa B ma gwarancje w ten sposób, że obiekt A jest gotowy.

9. Virtual functions in con/destructor. Jak wyżej. Ponieważ klasa potomna 
używa klasy nadrzędnej jest niszczona jako pierwsza. A potem chcemy 
wywołać funkcję zniszczonego obiektu :)
Circullar Dependences to zawsze problem ale autor powinien zaprezentować 
jakieś sensowne wyjście jak krytykuje (bo istnieje).

10. C++ is hard to write. Tak. Najlepiej przy wywołaniu każdej funkcji 
podajmy typy parametrów. Jakimś dziwnym trafem języki ewoluują w 
przeciwnym kierunku.

11. C++ is hard to write. O using namespace whatever;. Zapomnieli dopisać 
but shouldn't.

12. C++ is hard to write. Tak zapomnijmy o polimorfizmie. Patrz ostatnie 
zdanie 10.

13. Zdania mówiące wszystko:
Obviously, there could be preprocessor tricks.
Those are in C, too, and I like C, so I’m not bashing them here.
I do agree that they need some bashing.

13. C++ makes auditing painful. Na temat audytu referencji:
int test(int &tmp);

int test2() {
  int i;
  return test((const int)i);
}

Jak jest int test(int tmp); to nie wyrzuci błędu

Nie przepadam za C++ - cześciowo z powodów wymienionych w tekście. Ale nie 
sądze, żeby dużo z wymienionych powodów dało się wyeliminować bez 
dodatkowych narzutów czasowych (także dla przypadków skrajnych które 
prawie nigdy nie występują).

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 wrote:

> 3. C++ is hard to parse. Kompilatory (m. innymi używany przez autora g++)
> mają zabezpiecznie np, do 100 iteracji

A nie powinny mieć. Jak ktoś używa szablonów rekurencyjnych,
to powinien dokładnie wiedzieć, co robi.

> 4. C++ is hard to parse. Każdy język zapisany ciagłym kodem i
> niezalecanymi własciwościami jest nieczytelny. A czytelności nieczytalnego
> algorytmu język nie poprawi...

"parse" oznacza nieczytelność dla kompilatora, nie dla człowieka...

> 6. C++ is hard to write. Rozpacz, że cin kowertuje się do void *. Wynika z
> założeń kompatybilności z C. Kompatybilność z C jest potrzebna (chyba, że
> ktoś kocha pisać wrappery).

Nie jest potrzebna i licząc netto to C++ chyba znacznie więcej na
niej traci niż zyskuje. A wrappery pisze się raz, a używa wielokrotnie,
więc nie widzę powodu, by twórcy bibliotek dostarczali taki wrapper,
co jest robione np. przez GMP.

> 11. C++ is hard to write. O using namespace whatever;. Zapomnieli dopisać
> but shouldn't.

Oj tak, konstrukcja "usnig namespace" powinna zniknąć z tego języka...

> Nie przepadam za C++ - cześciowo z powodów wymienionych w tekście. Ale nie
> sądze, żeby dużo z wymienionych powodów dało się wyeliminować bez
> dodatkowych narzutów czasowych (także dla przypadków skrajnych które
> prawie nigdy nie występują).

Dałoby się, np. kolejność obliczania.

    Pozdrawiam
    Piotr Wyderski

On Sat, 03 Nov 2007 15:20:11 +0100, Piotr Wyderski wrote:

> Maciej Piechotka wrote:
> 
>> 3. C++ is hard to parse. Kompilatory (m. innymi używany przez autora
>> g++) mają zabezpiecznie np, do 100 iteracji
> 
> A nie powinny mieć. Jak ktoś używa szablonów rekurencyjnych, to powinien
> dokładnie wiedzieć, co robi.
> 

Może nie powinny mieć, ale miałem algorytmy, przy których kompilator się 
wysypywał z takim komunikatem. Opisywane tam jest to jako wada zresztą 
(tzn. takie zabezpieczenie to zaleta).

>> 6. C++ is hard to write. Rozpacz, że cin kowertuje się do void *.
>> Wynika z założeń kompatybilności z C. Kompatybilność z C jest potrzebna
>> (chyba, że ktoś kocha pisać wrappery).
> 
> Nie jest potrzebna i licząc netto to C++ chyba znacznie więcej na niej
> traci niż zyskuje. A wrappery pisze się raz, a używa wielokrotnie, więc
> nie widzę powodu, by twórcy bibliotek dostarczali taki wrapper, co jest
> robione np. przez GMP.
> 

Można dyskutować. Jak obserwuje inne języki to mimo wszystko bywa gorzej.

>> 11. C++ is hard to write. O using namespace whatever;. Zapomnieli
>> dopisać but shouldn't.
> 
> Oj tak, konstrukcja "usnig namespace" powinna zniknąć z tego języka...
> 

Nie wiem. Wiem, że nie wolno jej stosować w nagłówkach.

>> Nie przepadam za C++ - cześciowo z powodów wymienionych w tekście. Ale
>> nie sądze, żeby dużo z wymienionych powodów dało się wyeliminować bez
>> dodatkowych narzutów czasowych (także dla przypadków skrajnych które
>> prawie nigdy nie występują).
> 
> Dałoby się, np. kolejność obliczania.
> 

Dużo != wszystkie.

>     Pozdrawiam
>     Piotr Wyderski

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/)

Paweł Kierski wrote:
> Seweryn Habdank-Wojewódzki w wiadomości <fgqn9m$74j$2@news.vectranet.pl> pisze:
> [...]
>> Odniosłem się *tylko* do postu Piotra. Ostatnio nie mam czasu czytać
>> wszystkich wypocin szanownego gremium ktytykantów C i C++ :-).
> 
>   A to źle! 8-) Ktoś może mieć rację i warto o tym wiedzieć.
> 
>   Pomijąc fakt, że to, co napisałeś, niebezpiecznie zbliża się do
> kwestii Kaowca: "Nie słyszałem piosenki, więc chciałem powiedzieć parę
> słów na jej temat".

No tak, jeszcze trzeba nam tu kogoś kto spłętuje na drzwiach
kibla "Gupi KaOwiec." ,-)

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

Piotr Wyderski wrote:
> Maciej Piechotka wrote: 
>> 11. C++ is hard to write. O using namespace whatever;. Zapomnieli dopisać
>> but shouldn't.
> 
> Oj tak, konstrukcja "usnig namespace" powinna zniknąć z tego języka...

Wystarczy, jeśli preprocesor wyłapywałby ją w nagłówkach i krzyczał.

A do kompletu to brakuje mi narzekania (w tym tekście) na brak domyślnej
właściwości noncopyable dla typów użytkownika.

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

Mateusz Loskot wrote:
> Piotr Wyderski wrote:
>> Maciej Piechotka wrote: 
>>> 11. C++ is hard to write. O using namespace whatever;. Zapomnieli dopisać
>>> but shouldn't.
>> 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++ ;-)

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

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.

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

Witam

Maciej Sobczak wrote:

> 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;
> }

Jaki jest poziom zagnieżdżenia tego using? Tak na prawdę szkodliwe jest
tylko globalne using, jak sobie ktoś w swojej przestrzeni nazw tak zrobi to
sam sobie powróz ukręcił na karku. 

Można ewentualnie patrzeć czy nie dajemy tak:

namespace foo
{
        using namespace ::std;

}

Potrzebne są dwa liczniki, jeden kontrolujący poziom zagnieżdzenia, drugi
wskazujący, czy dane zagnieżdżenie dotyczy namespace, czy nie.
 
> Nie ma powodu, żeby tego zabraniać

Też tak uważam. W zasadzie to wystarczy sprawdzić co jest przed "{"
poprzedzającym wyrażenie using i wiadomo czy to jest groźne czy nie.

Praktycznie należy zapamiętać dwa wyrażenia poprzedzające "{" i
jeżeli "using namespace" (UN) występuję na poziomie 0 to zawsze alarm.
Jeżeli UN występuje na poziomie > 0 to odpamiętuje się dwa wyrazy przed "{"
jeśli one są cokolwiek inne niż {bleble, namespace} albo {namespace, xxx} to
jest raczej dobrze.

Przykład paskudny:

#define NASTY_DEFINE
#define NASTY_DEFINE1
#define NASTY_DEFINE2
#define NASTY_DEFINE3

namespace foo NASTY_DEFINE NASTY_DEFINE1 NASTY_DEFINE2 NASTY_DEFINE3 
{

}

> a odróżnienie tego od tych 
> "brzydkich" przypadków nie jest proste.

Proszę, czy możesz podać coś konkretnego?

Pozdrawiam.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seweryn Habdank-Wojewódzki pisze:
> Witam
> 
> Tomasz bla Fortuna wrote:
> 
>> AFAIR chodziło właśnie o koszt obliczeń potrzebny do skompilowania
>> szablonów, a nie run-time.
> 
> A to przepraszam. A co to szkodzi, że kompilacja trwa dłużej? Czy ta
> kompilacja odpalana jest w run-time?

Jak się kompiluje (za przeproszeniem) kalkulatorek na zaliczenie to
różnicy wielkiej nie ma. Jak pełny build wielkiej kobyły trwa 8+ godzin
to już jest różnica. Nawet "uzupełniający" build może wówczas zabierać
długo. Czas programisty jest cenny.

- --
Semper Fidelis

Adam Klobukowski
adamklobukowski@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHMqykVVIYOc5drI0RAiYAAJ9hCyCotyC44niDNYcwzmRkdEzgFACfWB3+
0gVZ34K/2QKxNRIJhrgP59Y=
=crnF
-----END PGP SIGNATURE-----

Witam

Adam Klobukowski wrote:

> Seweryn Habdank-Wojewódzki pisze:
>> Witam
>> 
>> Tomasz bla Fortuna wrote:
>> 
>>> AFAIR chodziło właśnie o koszt obliczeń potrzebny do skompilowania
>>> szablonów, a nie run-time.
>> 
>> A to przepraszam. A co to szkodzi, że kompilacja trwa dłużej? Czy ta
>> kompilacja odpalana jest w run-time?
> 
> Jak się kompiluje (za przeproszeniem) kalkulatorek na zaliczenie to
> różnicy wielkiej nie ma.

Już wyrosłem z zaliczeń i kalkulatorków :-D.

> Jak pełny build wielkiej kobyły trwa 8+ godzin 
> to już jest różnica. 
> Nawet "uzupełniający" build może wówczas zabierać 
> długo. 

Rozumiem. A tak optymistycznie -- jakie są możliwości przyspieszania
kompilacji?

To co ja używam:
- jawne konkretyzacje szablonów dla spodziewanych typów w połączeniu z
- prekompiled headers a całość
- kompilacja wielowątkowa/procesowa np. make z opcją -j.

> Czas programisty jest cenny.

Wiem. Ale programista powinien wiedzieć co to praca wielowątkowa. Jak
kompilacja trwa 8+ h, to może powinien poprawiać w tym czasie dokumentację,
uzupełniać listę zadań na następny raz. Może zastanowić się czy nie trzeba
czegoś refaktoryzować. 

Dla mnie kompilacja nie jest stratą czasu. Kompilacja krótka to jest czas na
oddech odejście od klawiatury i spojrzenie krytyczne na "dzieło".
Kompilacja długa to czas na intensywną pracę w innej dziedzinie należącej
do programowania.

Pozdrawiam.

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

Seweryn Habdank-Wojewódzki pisze:
> Adam Klobukowski wrote:
>> Czas programisty jest cenny.
> 
> Wiem. Ale programista powinien wiedzieć co to praca wielowątkowa. Jak
> kompilacja trwa 8+ h, to może powinien poprawiać w tym czasie dokumentację,
> uzupełniać listę zadań na następny raz. Może zastanowić się czy nie trzeba
> czegoś refaktoryzować. 
> 
> Dla mnie kompilacja nie jest stratą czasu. Kompilacja krótka to jest czas na
> oddech odejście od klawiatury i spojrzenie krytyczne na "dzieło".
> Kompilacja długa to czas na intensywną pracę w innej dziedzinie należącej
> do programowania.

Problem zaczyna się w momencie, jak trzeba naprawić jakiegoś małego,
denerwującego buga a kompilacja za każdym razem zabiera 0.5h. Wprawdzie
to nie wina kompilatora, ale mój kolega musi pracować którego restart
(np w celu naprawy drobnego buga) trwa 0.5h. I kiedy on naprawia tego
buga to przez 0.5h musi czekać. A jak nie naprawi za pierwszym razem to
i drugie 0.5h. Dobrze przynajmniej że kompilator jest szybki.
Programowanie wymaga skupienia. Ciężko w "międzyczasie" robić coś innego
i być dobrym programistą.

-- 
Semper Fidelis

Adam Klobukowski
adamklobukowski@gmail.com

Seweryn Habdank-Wojewódzki wrote:

> To co ja używam:
> - jawne konkretyzacje szablonów dla spodziewanych typów w połączeniu z
> - prekompiled headers a całość
> - kompilacja wielowątkowa/procesowa np. make z opcją -j.

distcc - kompilacja na malej farmie :)
http://distcc.samba.org/

-- 
Michal Schulz

Witam

Adam Klobukowski wrote:

> Problem zaczyna się w momencie, jak trzeba naprawić jakiegoś
> 
> małego, (#)
>
> denerwującego buga a kompilacja za każdym razem zabiera
> 
> 0.5h. (##)

Jak dla mnie (#) i (##) są sprzeczne. Rozumiem i wiem, że kompilacja trwa,
ale jeżeli poprawka wymusza 0.5h kompilacji, to znaczy, że dotyczy nie
jednego modułu, albo jednego bardzo rozległego modułu, a zatem bug nie był
mały.

Wiem, że w Pythonie nie ma kompilacji i wszyscy się cieszą ale jest super
nie tracimy czasu. W Javie kompilacja jest szybka. Pytanie czy w C++ pisząc
kod copy-paste from Java proces kompilacji nie byłby podobnie szybki.

Kompilację wydłużają *szablony*. Szablony w takiej wersji jak są w C++ nie
występują w Javie. W Pythonie można zrobić wiele podobnych rzeczy.
Był już kiedyś flame nt. tego czy kompilacja coś daje czy nie i nie chcę do
tego wracać.

> Wprawdzie  
> to nie wina kompilatora, ale mój kolega musi pracować którego restart
> (np w celu naprawy drobnego buga) trwa 0.5h. I kiedy on naprawia tego
> buga to przez 0.5h musi czekać.

Zapomniałem dodać, że ma w maku opcję make check, która wyłącza wszystkie
optymalizacje i kompilator pracuje w trybie "czy się uda skompilować?".

> A jak nie naprawi za pierwszym razem to 
> i drugie 0.5h. Dobrze przynajmniej że kompilator jest szybki.
> Programowanie wymaga skupienia. Ciężko w "międzyczasie" robić coś innego
> i być dobrym programistą.

Tak wiem. Ale to jest mit, że koderzy są niesamowicie skupieni i że tylko
kodują. Skupieni są co najwyżej bardzo i nieprawdą jest, że tylko kodują.

Kiedyś wykazałem, że nawet arcyszybki koder spędza max 5% czasu na surowe
pisanie/klikanie kodu. Więc może powinniśmy ustalić jakie jeszcze zadania
spoczywają na jego barkach i czy przypadkiem nie da się pewnych rzeczy
zrównoleglić z procesem kompilacji.

Pozdrawiam.

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

Seweryn Habdank-Wojewódzki pisze:
> Witam
> 
> Adam Klobukowski wrote:
> 
>> Problem zaczyna się w momencie, jak trzeba naprawić jakiegoś
>>
>> małego, (#)
>>
>> denerwującego buga a kompilacja za każdym razem zabiera
>>
>> 0.5h. (##)
> 
> Jak dla mnie (#) i (##) są sprzeczne. Rozumiem i wiem, że kompilacja trwa,
> ale jeżeli poprawka wymusza 0.5h kompilacji, to znaczy, że dotyczy nie
> jednego modułu, albo jednego bardzo rozległego modułu, a zatem bug nie był
> mały.
> 

Albo też błąd jest mały, a program nie ma modułów, tylko jest jednym
wielkim monolitem, albo też zawsze robią tam pełną rekompilację
wszystkiego. Tak czy siak taka organizacja projektu jest swego rodzaju
pomyłką.

Szymon wrote:
>>Jak dla mnie (#) i (##) są sprzeczne. Rozumiem i wiem, że kompilacja trwa,
>>ale jeżeli poprawka wymusza 0.5h kompilacji, to znaczy, że dotyczy nie
>>jednego modułu, albo jednego bardzo rozległego modułu, a zatem bug nie był
>>mały.
> 
> Albo też błąd jest mały, a program nie ma modułów,

Przy szablonach kompilacja 3 linijek może trwać kilka godzin.

> tylko jest jednym
> wielkim monolitem, albo też zawsze robią tam pełną rekompilację
> wszystkiego. Tak czy siak taka organizacja projektu jest swego rodzaju
> pomyłką.

Wystarczy, że muszą zrestartować jakiś większy system.

pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

> Szymon wrote:
>>>Jak dla mnie (#) i (##) są sprzeczne. Rozumiem i wiem, że kompilacja
>>>trwa, ale jeżeli poprawka wymusza 0.5h kompilacji, to znaczy, że dotyczy
>>>nie jednego modułu, albo jednego bardzo rozległego modułu, a zatem bug
>>>nie był mały.
>> 
>> Albo też błąd jest mały, a program nie ma modułów,
> 
> Przy szablonach kompilacja 3 linijek może trwać kilka godzin.

A mogę poprosić o przykład? Nigdy nie udało mi się zatłuc kompilator na tak
długo per linia kodu.
 
> Wystarczy, że muszą zrestartować jakiś większy system.

Ale to dotyczy każdego kompilatu nie tylko ++, obawiam się, że # i J też tak
będą miały.

Pozdrawiam.

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

Seweryn Habdank-Wojewódzki wrote:
> Kiedyś wykazałem, że nawet arcyszybki koder spędza max 5% czasu na surowe
> pisanie/klikanie kodu. Więc może powinniśmy ustalić jakie jeszcze zadania
> spoczywają na jego barkach i czy przypadkiem nie da się pewnych rzeczy
> zrównoleglić z procesem kompilacji.

Było o tym -- i zwykle się nie daje. Albo zajmie się czymś innym i do 
kompilacji wróci 3h po jej zakończeniu, albo to coś innego to jest np. 
falmowanie na newsach ;) -- z pracą nie ma nic wspólnego

\SK

Witam

Sebastian Kaliszewski wrote:

> Było o tym -- i zwykle się nie daje.

Czego się nie daje?

> Albo zajmie się czymś innym i do 
> kompilacji wróci 3h po jej zakończeniu, albo to coś innego to jest np.
> falmowanie na newsach ;) -- z pracą nie ma nic wspólnego

Jak dla mnie flejmowanie nie jest "evil" dopóki padają konkrety. W
zasadzie "evil" zaczyna się dopiero kiedy rzucane są już *tylko*
pejoratywy :-D.

Oczywiście flame ma swoją sprawność (IMHO ok. 10-20%), ale człowiek szybkim
rzutem oka widzi czy warto posta czytać czy już nie. I jeszcze
jedna "zaleta" flame czasami człowiek dowiaduje się rzeczy o które nawet
nie wiedział, o co zapytać i jak zapytać i tu sprawność skacze do setek
procent.

Nie wiem jak ma ogół koderów, ale na moim biurku leży masa ważnych pozycji
literaturowych, mogę też grzebać po sieci, mogę poprawiać doki, mogę
przymierzać się do refaktoryzacji czegoś.
Kompilacja trwa. 
Mam też kupę papierków z propozycjami na przyszłość i z zapiskami TODO.
Zazwyczaj czeka na mnie też jakieś wyprowadzonko lub testowy algorytm do
napisania. Mogę sobie nawet w innej konsoli kodować coś co będzie w
kolejnej wersji programu, czy jakieś testy dla procedurek/klas/szablonów. 
Kompilacja trwa.

Czy do WC koder też *nie* chodzi, bo to zajmuje mu czas i odbiera
koncentrację nad kodem? A może zabiera ze sobą lapciaka/pocketPC i tam
koduje?

A co z posiłkami i piciem?
Są firmy gdzie stoi automat do kawy i często widuję grupy ludzi stojących w
kolejce po swoją rację, czy to odrywa ich od pracy w stopniu istotnie
pogarszającym wyniki? 
A może to dobrze wpływa na socjalne aspekty pracy. Chwila oderwania, wymiana
zdań przy kawie? Hmm.... 

A może WC posiłek i picie są kompresowane w postaci posiadania na biurku
rury z granulatem dla dwónogów. Pod spodem znajduje się muszla, oraz
automatyczny zestaw czyszczący tkanki miękkie i odświeżający powietrze, aby
inne dwónogi nie miały kłopotów z koncentracją? Hę, jak to jest?

Wszyscy pracodawcy wiedzą, że pracownicy pracują nawet wolnym czasie
wystarczy ich spotkać ze sobą -- generalnie rozmawiają o tym co w
jest/było/będzie w pracy. Nawet na spotkaniu na wyścigach nie wszyscy
podziwiają "żonę" szefa i jego "konie", zawsze jest taka grupa, która
rozmawia o pracy. Tak więc tym bardziej przy kawie (w czasie kompilacji)
ludzie będą gadać o pracy.

Chciałbym zaznaczyć, że koder to nie generator kodu. Zresztą są nawet
zalecenia lekarskie, aby co 45 minut przestać kodować, bo nadgarstki mogą
później chorować. Do tego dochodzą zalecania co do gimnastyki oczu itd.

"Ludzie bądźcie ludźmi!" Z tym strasznym problemem kompilacji to mam
wrażenie, że "złej baletnicy zawadza rąbek od spódnicy".

Pozdrawiam.

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

Szymon pisze:
> Seweryn Habdank-Wojewódzki pisze:
>> Witam
>>
>> Adam Klobukowski wrote:
>>
>>> Problem zaczyna się w momencie, jak trzeba naprawić jakiegoś
>>>
>>> małego, (#)
>>>
>>> denerwującego buga a kompilacja za każdym razem zabiera
>>>
>>> 0.5h. (##)
>> Jak dla mnie (#) i (##) są sprzeczne. Rozumiem i wiem, że kompilacja trwa,
>> ale jeżeli poprawka wymusza 0.5h kompilacji, to znaczy, że dotyczy nie
>> jednego modułu, albo jednego bardzo rozległego modułu, a zatem bug nie był
>> mały.
>>
> 
> Albo też błąd jest mały, a program nie ma modułów, tylko jest jednym
> wielkim monolitem, albo też zawsze robią tam pełną rekompilację
> wszystkiego. Tak czy siak taka organizacja projektu jest swego rodzaju
> pomyłką.

To fakt, ale cóż zrobić, klient płaci i wymaga.

-- 
Semper Fidelis

Adam Klobukowski
adamklobukowski@gmail.com

Adam Klobukowski w wiadomości <fh1civ$cgb$2@news.dialog.net.pl> pisze:
[...]
> > Albo też błąd jest mały, a program nie ma modułów, tylko jest jednym
> > wielkim monolitem, albo też zawsze robią tam pełną rekompilację
> > wszystkiego. Tak czy siak taka organizacja projektu jest swego rodzaju
> > pomyłką.
> 
> To fakt, ale cóż zrobić, klient płaci i wymaga.

  Czego? Monolitu, czy rekompilacji przy każdej poprawce? Naiwnie
sądziełem, że klient chce produktu, nie projektu...

-- 
    Paweł Kierski
    news@pkierski.net
    dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
    albo koniecznie chcesz obejść moje filtry 8-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paweł Kierski pisze:
> Adam Klobukowski w wiadomości <fh1civ$cgb$2@news.dialog.net.pl> pisze:
> [...]
>>> Albo też błąd jest mały, a program nie ma modułów, tylko jest jednym
>>> wielkim monolitem, albo też zawsze robią tam pełną rekompilację
>>> wszystkiego. Tak czy siak taka organizacja projektu jest swego rodzaju
>>> pomyłką.
>> To fakt, ale cóż zrobić, klient płaci i wymaga.
> 
>   Czego? Monolitu, czy rekompilacji przy każdej poprawce? Naiwnie
> sądziełem, że klient chce produktu, nie projektu...

Fakt naiwnie, bo akurat ten klient żąda aby projekt był prowadzony w
taki a nie inny sposób.

- --
Semper Fidelis

Adam Klobukowski
adamklobukowski@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHNOHlVVIYOc5drI0RAmjXAJ9PYPvHAwH5I2iIHMC3+lKk7Q6XnwCcDCec
ryjmNfgX4rNPrW0Un/XGf4Y=
=kRf5
-----END PGP SIGNATURE-----

"Adam Klobukowski" wrote:

> Paweł Kierski pisze:
>> Adam Klobukowski w wiadomości <fh1civ$cgb$2@news.dialog.net.pl> pisze:
>> [...]
>>>> Albo też błąd jest mały, a program nie ma modułów, tylko jest jednym
>>>> wielkim monolitem, albo też zawsze robią tam pełną rekompilację
>>>> wszystkiego. Tak czy siak taka organizacja projektu jest swego rodzaju
>>>> pomyłką.
>>> To fakt, ale cóż zrobić, klient płaci i wymaga.
>>
>>   Czego? Monolitu, czy rekompilacji przy każdej poprawce? Naiwnie
>> sądziełem, że klient chce produktu, nie projektu...
>
> Fakt naiwnie, bo akurat ten klient żąda aby projekt był prowadzony w
> taki a nie inny sposób.
>
Co z reszta wcale nie jest jakims widzimisie tylko normalna praktyka 
biznesowa.

pzdr
Muchomor 

Seweryn Habdank-Wojewódzki wrote:
>>>>Jak dla mnie (#) i (##) są sprzeczne. Rozumiem i wiem, że kompilacja
>>>>trwa, ale jeżeli poprawka wymusza 0.5h kompilacji, to znaczy, że dotyczy
>>>>nie jednego modułu, albo jednego bardzo rozległego modułu, a zatem bug
>>>>nie był mały.
>>>
>>>Albo też błąd jest mały, a program nie ma modułów,
>>
>>Przy szablonach kompilacja 3 linijek może trwać kilka godzin.
> 
> 
> A mogę poprosić o przykład? Nigdy nie udało mi się zatłuc kompilator na tak
> długo per linia kodu.

Przecież masz przykład pana F.

>>Wystarczy, że muszą zrestartować jakiś większy system.
> 
> 
> Ale to dotyczy każdego kompilatu nie tylko ++, obawiam się, że # i J też tak
> będą miały.

Nie będą. W nich proces kompilacji nie musi rozwiązywać zadań potencjalnie 
nierozwiązywalnych (bo statyczna storna nie jest Turing-complete). J i # 
kompilują się szybko.

pzdr
\SK

Dnia 13-12-2007, Cz o godzinie 16:12 +0100, Adam Karpierz pisze:

> Kontekstowosc w C (tylko fraza else) to pikus.

Nie tylko else. Największą trudnością w składni C jest kontekstowość
typedefów (jeśli liczyć składnię po przejściu przez preprocesor).

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

Witam

Marcin ?Qrczak? Kowalczyk wrote:

> Dnia 13-12-2007, Cz o godzinie 16:12 +0100, Adam Karpierz pisze:
> 
>> Kontekstowosc w C (tylko fraza else) to pikus.
> 
> Nie tylko else. Największą trudnością w składni C jest kontekstowość
> typedefów (jeśli liczyć składnię po przejściu przez preprocesor).

Dziękuję za obiektywną ocenę "pikusiów".

Pozdrawiam.

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

Witam

Sebastian Kaliszewski wrote:

> A co za problem? Te języki nie mają (poza C) ciężko chorej, kontekstowej
> składni. 

> Parser robi się łatwo -- pół-mechanicznie przepisując publicznie 
> dostępną gramatykę na źródło jakiegoś tam ANTLR-a

Tak.

> czy JavaCC czy co tam 
> będzie wygodnego w używanym języku.

Hmm...

> Potem tę przepisaną gramatykę nalezy 
> ubrac w odpowiednie dla zastosowania akcje, ale parserem już jest to coś
> bez akcji.

Super. A ja pisałem o samodzielnym pisaniu, a nie użyciu gotowców. Dla
mnie "Pisałem bezproblemowo" oznacza, że sam pisałem, a nie użyłem
generatorów kodu.

> Tak, pisałem przy użyciu ANTLR parser wcale nieprostego języka -- w
> tydzień był gotowy :)

Super. Gratuluję umiejętności korzystania z "Worda". Co innego jest
korzystanie z "Worda", a co innego jest napisanie "Worda". Ja też umiem
kilkać GUI w Javie, a nie twierdze, że "bezproblemowo piszę".

Pozdrawiam.

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

Użytkownik "Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> napisał:

>>> Kontekstowosc w C (tylko fraza else) to pikus.
>>
>> Nie tylko else. Największą trudnością w składni C jest kontekstowość
>> typedefów (jeśli liczyć składnię po przejściu przez preprocesor).
>
> Dziękuję za obiektywną ocenę "pikusiów".

Akurat rozwiazywanie kontekstowosci typedefow jest tak samo proste
jak "przeslaniania" zmiennych (stos zwykly)  i...
wbrew pozorom nie tyczy czystego synktatycznego parsingu
a bardziej juz semantyki.

Natomiast kontekstowosc else jest wazna juz na etapie czystego
parsingu (czyli budowy drzewa) bo bez wlasciwego 'rozwiazania'
tejze frazy moze to drzewo byc zbudowane niepoprawnie.

AK

Dnia 13-12-2007, Cz o godzinie 23:56 +0100, Adam Karpierz pisze:

> Akurat rozwiazywanie kontekstowosci typedefow jest tak samo proste
> jak "przeslaniania" zmiennych (stos zwykly)  i...
> wbrew pozorom nie tyczy czystego synktatycznego parsingu
> a bardziej juz semantyki.

Kontekstowość typedefów wymusza albo informację zwrotną od analizy
semantycznej do leksera (na bieżąco), albo parsowanie do jakiejś
pokręconej struktury uwzględniającej różne możliwości statusu
typedefowego identyfikatorów, która potem będzie dopiero
ujednoznaczniana (nie wiem, czy to w ogóle jest praktyczne, bo
wszyscy robią tą pierwszą metodą, ale teoretycznie parser mógłby
pozostawić coś niewiele różniącego się od ciągu leksemów, więc
jakiś wariant drugiego rozwiązania jest teoretycznie możliwy).

W C++ to jest znacznie gorzej, bo identyfikatory nie muszą być globalne,
tylko mogą pochodzić z szablonów, które trzeba ukonkretniać, więc praca
spleciona z lekserem jest znacznie szersza - obejmuje nawet wyliczanie
stałych wyrażeń (typów całkowitych). Oprócz statusu typedefowego do
parsowania potrzebny jest też status bycia szablonem. Ale w C praktyczna
konieczność splecenia ze sobą faz, które zazwyczaj są osobne, już się
objawia.

> Natomiast kontekstowosc else jest wazna juz na etapie czystego
> parsingu (czyli budowy drzewa) bo bez wlasciwego 'rozwiazania'
> tejze frazy moze to drzewo byc zbudowane niepoprawnie.

Kontekstowość else jest trywialnie rozwiązywalna przez modyfikację
gramatyki (zdublowanie niektórych symboli w wersji dopuszczającej
kończenie się na if bez else bądź nie), choć prościej może być
pozostawić niejednoznaczność, jeśli wiemy, jak będzie rozwiązana.

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

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message 
news:1197591962.23942.28.camel@qrnik...
Dnia 13-12-2007, Cz o godzinie 23:56 +0100, Adam Karpierz pisze:

> Kontekstowość typedefów wymusza albo informację zwrotną od
> analizy semantycznej do leksera (na bieżąco),

Zgadza sie:
I tak sie to zazwyczaj robi.
Wiadomo dlaczego (bledy na biezaco).
Jako "nosnik" starczy zwykly stos /w scope pamieta sie tylko
gdzie wrocic a szuka sie przy jednoczesnej redukcji
typedefow od konca/.

> albo parsowanie do jakiejś pokręconej struktury uwzględniającej
>  różne możliwości statusu typedefowego identyfikatorów,
> która potem będzie dopiero ujednoznaczniana (nie wiem,
> czy to w ogóle jest praktyczne, bo wszyscy robią tą pierwszą metodą,
> ale teoretycznie parser mógłby pozostawić coś niewiele różniącego
>  się od ciągu leksemów, więc jakiś wariant drugiego
>  rozwiązania jest teoretycznie możliwy).

Zgadza sie.  Tyle ze niekoniecznie do pokreconej struktury tylko
normalnie w drzewie jako node typedefa
(node typu: typedef z subnode1: nazwa i subnode2: "rozczesanym" typem).
Oczywiscie ze to gorsze z w/w powodow ale analize typedefow mozna
przeprowadzic dopiero po utworzeniu drzewa (podobnie mozna by zrobic
ze zmiennymi - np error gdy nieistnieje/neizadeklarowana).
Analiza na juz gotowym drzewie nie tylko wykrywala by bledy
semantyczne ale rowniez redukowala drzewo o typedefy wlasnie.

> W C++ to jest znacznie gorzej, bo identyfikatory nie muszą być globalne,
> tylko mogą pochodzić z szablonów, które trzeba ukonkretniać, więc praca
> spleciona z lekserem jest znacznie szersza - obejmuje nawet wyliczanie
> stałych wyrażeń (typów całkowitych). Oprócz statusu typedefowego do
> parsowania potrzebny jest też status bycia szablonem. Ale w C praktyczna
> konieczność splecenia ze sobą faz, które zazwyczaj są osobne, już się
> objawia.

No i _dokladnie_ z w/w powodow dalem sobie spokoj.
Po prostu (juz szczegolow nie pamietam - bawilem sie tym chyba juz chyba
2 lata z hakiem temu) w semantyce np. typologii C++ robi sie dzungla.
Co mi z parsera jesli nad poparsingowa nawet semantyka i redukcjami drzewa
musialbym siedziec reszte zycia - _nie_ chce umrzec znajac raport C++
na pamiec :)

> Kontekstowość else jest trywialnie rozwiązywalna przez modyfikację
> gramatyki (zdublowanie niektórych symboli w wersji dopuszczającej
> kończenie się na if bez else bądź nie),

Dokladnie !

> choć prościej może być pozostawić niejednoznaczność,
> jeśli wiemy, jak będzie rozwiązana.

Tez swieta prawda :)


PS: Nie wiem czy wiesz ale pomiedzy ostatnim ogolnioe dostepnym
       draftem standardu,  a oficjanym standardem C++ istnieja...
       roznice w gramatyce C++.  W szablonach wlasnie.

AK

Dnia 14-12-2007, Pt o godzinie 01:49 +0100, Adam Karpierz pisze:

> Jako "nosnik" starczy zwykly stos /w scope pamieta sie tylko
> gdzie wrocic a szuka sie przy jednoczesnej redukcji
> typedefow od konca/.

To jest trochę inne podejście (też dobre): uproszczona analiza
kontekstowa tylko dla potrzeb rozpoznawania typedefów, której wyniki
służą tylko lekserowi. Potem się to robi od nowa z uwzględnieniem
wszystkich konstrukcji.

Bo można też wykonywać początkowe etapy dalszej analizy równolegle
z lekserem: budować wszelkie informacje o symbolach widocznych w różnych
zakresach. Do dokończenia po parsowaniu, a nie do zrobienia od początku.

> Zgadza sie.  Tyle ze niekoniecznie do pokreconej struktury tylko
> normalnie w drzewie jako node typedefa
> (node typu: typedef z subnode1: nazwa i subnode2: "rozczesanym" typem).

Zupełnie nie o to mi chodziło. Problemem nie jest parsowanie samych
definicji ze słowem kluczowym 'typedef', tylko rozróżnianie
identyfikatorów oznaczających typy od pozostałych w innych produkcjach.
Wszystkie gramatyki C, o których słyszałem, mają osobny leksem na
identyfikator zwykły i osobny na identyfikator wprowadzony przez
typedef. Bez tego gramatyka byłaby niejednoznaczna i nie wiem, czy
ujednoznacznianie byłoby praktyczne.

Jeśli mamy coś takiego:
   a(*b)(c(d));
to jeśli a był wprowadzone przez typedef, to jest to deklaracja
wskaźnika b na funkcję zwracającą a, której parametr jest typu c
(nazwa d nie ma tu znaczenia jako nazwa parametru w typie funkcji).
Jeśli jednak a nie jest wprowadzone przez typedef, to jest to aplikacja
funkcji a do wartości odczytanej spod wskaźnika b, gdzie następnie
wynik jest zaaplikowany do aplikacji c do d. To jest zupełnie inne
drzewko, tzn. może i strukturalnie wygląda podobnie, ale węzły mają
zupełnie inną interpretację.

Inne są ciągi leksemów dopuszczone w analogicznych miejscach w jednym
i w drugim przypadku. Na przykład po deklaracji może być "=", "{"
i inicjalizator tablicy bądź struktury (w C99 z dodatkowymi ficzerami
w stylu jawnych nazw pól), a jeśli po wyrażeniu jest "=", to jest to
operator przypisania, po którym jest wyrażenie, które nie może mieć
formy czegoś w klamrach.

Zatem gdyby tworzyć zunifikowane drzewko bez wiedzy o tym, które
identyfikatory zostały wprowadzone przez typedef, to tych wszystkich
wariantów nie można by rozróżniać już w trakcie parsowania, tylko trzeba
zapamiętać, że było coś w klamrach, i dopiero potem się okaże, czy to ma
być analizowane jak inicjalizator, czy jak wyrażenie.

Podobnie problematyczna jest składnia rzutowania, która zaczyna się od
zupełnie niewinnego nawiasu okrągłego. (a)(b)(c) to może być aplikacja
a do b, a wynik jeszcze zaaplikowany do c, albo rzutowanie aplikacji b
do c, na typ a, albo rzutowanie c na typ b, a potem jeszcze na typ a.
A co dopiero, jeśli w nawiasach będą kombinacje typów funkcyjnych,
tablicowych i wskaźnikowych, gdzie nie wiadomo, co jest typem, a co
wyrażeniem.

Na domiar złego przy rzutowaniu mamy typ bez identyfikatora znajdującego
się w tym miejscu, w którym zazwyczaj przy wystąpieniu typu jest jakiś
identyfikator. To znaczy deklaracja zmiennej albo typedefu może wyglądać
np. tak:
   int (*(*a)(int *b))[10];
gdzie definiowanym identyfikatorem jest a, ale przy rzutowaniu mamy
w tym miejscu dziurę:
   (int (*(*)(int *b))[10])x
co może być trudno parsować jako rozszerzone wyrażenie, gdyby zamiast
int był identyfikator, o którym nie wiemy, czy jest typedefem.

Nie wiem, jak mogłoby wyglądać zunifikowane drzewko przy gramatyce
nierozróżniającej identyfikatorów typedefów od pozostałych. Może
wcale nie przypominałoby drzewka, może na przykład nie mogłoby zrobić
wiele więcej niż zbilansowanie nawiasów różnych rodzajów i zebranie
ciągów wyrażenio-typo-deklaratoro-inicjalizatorów między nawiasami.
Ludzie wolą jednak sprzęgnąć lekser z dalszymi fazami. Parsowanie
bezkontekstowe ze zunifikowanym drzewkiem jest co prawda teoretycznie
możliwe (o ile nie mamy narzucone, które aspekty składni musimy
rozpoznać już na etapie parsowania, a które możemy zostawić na potem),
ale być może jest całkiem niepraktyczne.

Dlatego twierdzę, że else jest łatwiejsze, bo else można ujednoznacznić
samą zmianą gramatyki, w dodatku całkiem łatwą. Język z takim else
jak w C jest wciąż bezkontekstowy - jedyny kłopot jest tej natury,
że najprostsza gramatyka bezkontekstowa jest większa niż najprostsza
gramatyka z niejednoznacznością. Jest większa i zawiera irytujące
prawie-duplikaty, dlatego literatura woli używać tej drugiej gramatyki,
gdzie trzeba uważać na sposób potraktowania niejednoznaczności.

W C++ równolegle z analizą leksykalną oprócz śledzenia typedefów trzeba
sprawdzać typy, budować hierarchię klas, rozpoznawać miejsca wstawienia
niejawnych konwersji, rozwiązywać przeciążanie funkcji, dedukować
parametry szablonów z typów argumentów funkcji szablonowej, uwzględniać
Koenig lookup, liczyć sizeofy typów, wykonywać arytmetykę na stałych -
połowa kompilatora musi być napisana w taki sposób, żeby można było
wykonywać ją przyrostowo na tym, co właśnie sparsowaliśmy, nie znając
jeszcze pełnego drzewa modułu wychodzącego z parsera.

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

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message 
news:1197596465.19934.36.camel@qrnik...
Dnia 14-12-2007, Pt o godzinie 01:49 +0100, Adam Karpierz pisze:

> To jest trochę inne podejście (też dobre): uproszczona analiza
> kontekstowa tylko dla potrzeb rozpoznawania typedefów, której wyniki
> służą tylko lekserowi. Potem się to robi od nowa z uwzględnieniem
> wszystkich konstrukcji.

Tak.

> Bo można też wykonywać początkowe etapy dalszej analizy równolegle
> z lekserem: budować wszelkie informacje o symbolach widocznych w różnych
> zakresach. Do dokończenia po parsowaniu, a nie do zrobienia od początku.

Dokladnie.

> Zgadza sie.  Tyle ze niekoniecznie do pokreconej struktury tylko
> normalnie w drzewie jako node typedefa
> (node typu: typedef z subnode1: nazwa i subnode2: "rozczesanym" typem).

> Zupełnie nie o to mi chodziło. Problemem nie jest parsowanie samych
> Jeśli mamy coś takiego:
>   a(*b)(c(d));
> to jeśli a był wprowadzone przez typedef, to jest to deklaracja
> wskaźnika b na funkcję zwracającą a, której parametr jest typu c
> (nazwa d nie ma tu znaczenia jako nazwa parametru w typie funkcji).
> Jeśli jednak a nie jest wprowadzone przez typedef, to jest to aplikacja
> funkcji a do wartości odczytanej spod wskaźnika b, gdzie następnie
> wynik jest zaaplikowany do aplikacji c do d. To jest zupełnie inne
> drzewko, tzn. może i strukturalnie wygląda podobnie, ale węzły mają
> zupełnie inną interpretację.

Wlasnie o to chodzi ze strukturalnei (synktatycznie) jest  identyczne.
Mozna sobie wiec przyjac na poczatku dowolne z poddrzew.
Natomiast _faktyczna_ "naprawa" drzewa moze sie juz odbyc
pozniej droga przechodzenai po calym drzewie i "naprawy"
tych wieloznacznych subnodes na wlasciwe (pointer albo call).

Wiec czasami stosuje nodes typu CUSalboCUS
(slawetny przyklad z konstruktorem klasy czy tez funkcja c C++
  ten znany blad z gcc 3.x0 )

> Parsowanie bezkontekstowe ze zunifikowanym drzewkiem
> jest co prawda teoretycznie możliwe (o ile nie mamy narzucone,
> które aspekty składni musimy rozpoznać już na etapie parsowania,
>  a które możemy zostawić na potem), ale być może jest całkiem 
> niepraktyczne.

To zalezy.
Jesli zalezy nam nie na tym _co_ to znaczy ale jedynie jak wyglada
(a mnie w wiekszosci przypadkow o to chodzilo jedynie) to nawet
takie "chore" drzewko starczy jesli robimy jedynei cos w rodzaju
translatora kodu a wazne dla nas nodes mamy pewnie rozpoznane.

> Dlatego twierdzę, że else jest łatwiejsze, bo else można
> ujednoznacznić samą zmianą gramatyki, w dodatku całkiem łatwą.

Z else oczywicie tak tez robie (wystarczy rozbic na dwie produkcje)
Zreszt tak naprawde _co sie tylko_ da wprzegam do gramatyki
rozbijajac pierwotne produkcje ale takze przez jakies mneij elegenckie
sztuczki typu flagi w nodach itp :)

> Język z takim else
> jak w C jest wciąż bezkontekstowy - jedyny kłopot jest tej natury,
> że najprostsza gramatyka bezkontekstowa jest większa niż najprostsza
> gramatyka z niejednoznacznością. Jest większa i zawiera irytujące
> prawie-duplikaty, dlatego literatura woli używać tej drugiej gramatyki,
> gdzie trzeba uważać na sposób potraktowania niejednoznaczności.

Ale w praktyce mnie sprawdza sie zdecydowanie ta pierwsza :)
W praktyce _i tak_ rozbijam wiekszosc bezkontekstowych
produkcji na kilka bo i tak mi sie sprawdza lepiej gdy mam wieksza
odpowioedniosc: produkcja => akcja niz badac w akcji czy aby
jakis nody sa None itp i robic jakis chore switche czy ify :)

> W C++ równolegle z analizą leksykalną oprócz śledzenia typedefów trzeba
> sprawdzać typy, budować hierarchię klas, rozpoznawać miejsca wstawienia
> niejawnych konwersji, rozwiązywać przeciążanie funkcji, dedukować
> parametry szablonów z typów argumentów funkcji szablonowej, uwzględniać
> Koenig lookup, liczyć sizeofy typów, wykonywać arytmetykę na stałych -
> połowa kompilatora musi być napisana w taki sposób, żeby można było
> wykonywać ją przyrostowo na tym, co właśnie sparsowaliśmy, nie znając
> jeszcze pełnego drzewa modułu wychodzącego z parsera.

Swieta prawda :)
Za leniwy jestem aby skonczyc a takiej dzungli :)
Wlasnie ! Z samymi namespaceami wiekszy klopot niz z typedefami
a w polaczeniu jedne z drugimi a jeszcze klasy i templates a jeszcze
to ze szlag wie czy klass czy struct (pol biedy) czy typedef czy enum czy
funkcja  :) Nie no dosc :)
Parser synktatyczny robi sie niechcacy pelnym kombajnem
semantycznym  i sie odechciewa zyc :)

AK

Seweryn Habdank-Wojewódzki wrote:
>>A co za problem? Te języki nie mają (poza C) ciężko chorej, kontekstowej
>>składni. 
> 
>>Parser robi się łatwo -- pół-mechanicznie przepisując publicznie 
>>dostępną gramatykę na źródło jakiegoś tam ANTLR-a
> 
> Tak.
>
> 
>>czy JavaCC czy co tam 
>>będzie wygodnego w używanym języku.
> 
> Hmm...

Co, hmm???


>>Potem tę przepisaną gramatykę nalezy 
>>ubrac w odpowiednie dla zastosowania akcje, ale parserem już jest to coś
>>bez akcji.
> 
> Super. A ja pisałem o samodzielnym pisaniu, a nie użyciu gotowców.

Jakich gotowców??? Wiesz co to jest ANTLR czy Yacc czy Bison czy Flex czy 
JavaCC?


> Dla
> mnie "Pisałem bezproblemowo" oznacza, że sam pisałem, a nie użyłem
> generatorów kodu.

A co za różnica? Po jaką cholerę się męczyć, jak można użyć właściwego 
narzędzia. Narzędzia, które odwali za mnie mechaniczną część roboty.

  Zamiast pisać


def parse(file):
   while not end(file):
     if lookup(file) == WHILE:
       parse_while(file)
     elif lookup(file) == IF:
       parse_if(file)
     elif lookup(file) == ID:
       parse_assign(file)
     else:
       raise ParseError, "Unknown instruction"
     if(lookup(file) == TERMINATOR:
       eat(file)
     else:
       raise ParseError, "; expected"

def parse_while(file):
   eat(file)
   parse_expression(file)
   if lookup(file) == BEGIN:
     parse(file)
     if(lookup(file) == END:
       eat(file)
     else:
       raise ParseError, "No matching end"
   else:
     raise ParseError, "Loop body must begin with begin"

def parse_if(file):
   eat(file)
   parse_expression(file)
   if lookup(file) == BEGIN:
     parse(file)
     if(lookup(file) == END:
       eat(file)
     else:
       raise ParseError, "No matching end"
   else:
     raise ParseError, "Conditional instruction body must begin with begin"
   if lookup(file) == ELSE:
     eat(file)
     if lookup(file) == BEGIN:
       parse(file)
       if(lookup(file) == END:
         eat(file)
       else:
         raise ParseError, "No matching end"
     else:
       raise ParseError, "Conditional instruction body must begin with begin"

def parse_assign(file):
   id = eat(file).value
   if lookup(file) != ASSIGN:
     raise ParseError, ":= expected"
   eat(file)
   parse_expression(file)

def parse_expression(file):
   if lookup(file) == NUMBER:
     num = eat(file).value
   elif lookup(file) == ID:
     id = eat(file).value
   if lookup(file) == MINUS:
     eat(file)
     parse_expression(file)



  Wolę napisać:


body: ((while | if | assign) TERMINATOR)*

while: WHILE expression BEGIN body END

if: IF expression BEGIN body END (ELSE BEGIN body END)?

assign: ID ASSIGN expression

expression: (NUMBER | ID)? (MINUS expression)?



Krócej a znaczy tyle samo. Logiki to za mnie nie rozwiąże, ale pisania dużo 
mniej, zapis czytelniejszy i trudniej o błąd.


>>Tak, pisałem przy użyciu ANTLR parser wcale nieprostego języka -- w
>>tydzień był gotowy :)
> 
> Super. Gratuluję umiejętności korzystania z "Worda". Co innego jest
> korzystanie z "Worda", a co innego jest napisanie "Worda". Ja też umiem
> kilkać GUI w Javie, a nie twierdze, że "bezproblemowo piszę".

Widzę, że nic a nic nie rozumiesz. Analogia kompletnie bez sensu.
Jak jesteś taki mądry to pisz w assemblerze -- po co ci jakiś język wyższego 
poziomu, przecież nie będziesz korzystał z gotowców...

pzdr
\SK

Witam 

Sebastian Kaliszewski wrote:

> Jakich gotowców??? Wiesz co to jest ANTLR

Widziałem, ale nieużywałem.

> czy Yacc czy Bison

Gneratory parserów. Kod przez nich tworzony jest bardzo dziwny (raczej z
kategorii nieruszać).

> czy Flex czy JavaCC?

Nie używałem.

> A co za różnica? Po jaką cholerę się męczyć, jak można użyć właściwego
> narzędzia. Narzędzia, które odwali za mnie mechaniczną część roboty.

Używać to nie znaczy rozumieć co się dzieje pod maską. Jak na razie
przychylam się do opisów Qrczaka, że parsowanie to nie jest banalna sprawa,
a nie "bezproblemowe pisanie".
 
> Krócej a znaczy tyle samo. Logiki to za mnie nie rozwiąże, ale pisania
> dużo mniej, zapis czytelniejszy i trudniej o błąd.

Oczywiście. Z wyjątkiem faktu, że ręcznie napiszesz kontekstowy parser nawet
prostego języka, a takie automaty mają kłopoty.

Kiedyś pisałem parser prostej gramatyki ale kontekstowej i nie było to
bardzo proste, tak więc mam inne zdanie niż Ty o parsowaniu w ogólności.

> Widzę, że nic a nic nie rozumiesz.
> Analogia kompletnie bez sensu.
> Jak jesteś taki mądry to pisz w assemblerze

Czasem pisałem.

> -- po co ci jakiś język wyższego poziomu, przecież nie będziesz korzystał
> z gotowców... 

Może i tak, może i nie. W każdym razie znajomość gotowca/generatora nie
wskazuje o zrozumieniu tematu, a już na 100% nie o tym czy faktyczne
zadanie jest proste czy nie.

Pozdrawiam.

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

Dnia 14-12-2007, Pt o godzinie 14:34 +0100, Seweryn Habdank-Wojewódzki
pisze:

> Używać to nie znaczy rozumieć co się dzieje pod maską. Jak na razie
> przychylam się do opisów Qrczaka, że parsowanie to nie jest banalna sprawa,
> a nie "bezproblemowe pisanie".

To wcale nie jest moje zdanie.

Parsowanie z reguły jest prostą sprawą, a do tego od dawna bardzo dobrze
zbadaną. Nie trzeba wcale używać gotowych narzędzi, a już zwłaszcza nie
trzeba używać narzędzi, których się nie rozumie. Parser łatwo pisać
ręcznie w dowolnym języku ogólnego przeznaczenia, czeka nas najwyżej
trochę monotonnej roboty.

Tylko nieliczne składnie (C, C++, Perl) wymagają nadzwyczajnego
czarowania przy parsowaniu.

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

"Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> wrote:

>> czy Yacc czy Bison
>
> Gneratory parserów. Kod przez nich tworzony jest bardzo dziwny (raczej z
> kategorii nieruszać).

No bo ruszanie tego kodu powinno byc zabronione pod
kara wywalenia z pracy :) (a nie zawsze tak jest :)

> Używać to nie znaczy rozumieć co się dzieje pod maską.
> Jak na razie przychylam się do opisów Qrczaka, że parsowanie to
> nie jest banalna sprawa, a nie "bezproblemowe pisanie".

Zalezy od jezyka.
Jesli jest kontekstowy (ta sama  konstrukcja synktatyczna jest wieloznaczna
czyli jej znaczenie zalezy od 'polozenia' w kodzie albo innych 'pobocznych'
do synktatyki rzeczy,  to jest to syf - jesli gramatayka
jest 'czysta' to jest to przyjemnosc i to bez wzgledu na stopien 
'rozbuchania'
jezyka w sensie ilosci konstrukcji/statementow itp.

>> Krócej a znaczy tyle samo. Logiki to za mnie nie rozwiąże, ale pisania
>> dużo mniej, zapis czytelniejszy i trudniej o błąd.
>
> Oczywiście.
> Z wyjątkiem faktu, że ręcznie napiszesz kontekstowy parser nawet
> prostego języka, a takie automaty mają kłopoty.

Co ?
Ze niby recznie opiszesz sie wtedy mniej ?

AK

Witam

Adam Karpierz wrote:

> No bo ruszanie tego kodu powinno byc zabronione pod
> kara wywalenia z pracy :) (a nie zawsze tak jest :)

Hmm... może i tak, ale warto zerknąć, co tam się dzieje.
 
>>> Krócej a znaczy tyle samo. Logiki to za mnie nie rozwiąże, ale pisania
>>> dużo mniej, zapis czytelniejszy i trudniej o błąd.
>>
>> Oczywiście.
>> Z wyjątkiem faktu, że ręcznie napiszesz kontekstowy parser nawet
>> prostego języka, a takie automaty mają kłopoty.
> 
> Co ?
> Ze niby recznie opiszesz sie wtedy mniej ?

Nie. Ale parser kontekstowy trudno jest zrobić automatem.

Pozdrawiam.

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

"Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> wrote:

>> No bo ruszanie tego kodu powinno byc zabronione pod
>> kara wywalenia z pracy :) (a nie zawsze tak jest :)
>
> Hmm... może i tak, ale warto zerknąć, co tam się dzieje.

Absolutnie nie warto (w wiekszosci przypadkow).

>> Co ?
>> Ze niby recznie opiszesz sie wtedy mniej ?
>
> Nie. Ale parser kontekstowy trudno jest zrobić automatem.

Automat tu nic nei zmienia, a z reguly ulatwia
bo przynajmniej oferuje odpowiednei struktury
(drzewo i nei tylko) i funcje do oparerowania na nich
ktore tylko ulatwiaja rozwiazywanie wszelkich
niejednoznacznosci bo przynajmniej nei trzeba
pisac podstawowej narzedziowki.

AK

Witam

Marcin ?Qrczak? Kowalczyk wrote:

>> Używać to nie znaczy rozumieć co się dzieje pod maską. Jak na razie
>> przychylam się do opisów Qrczaka, że parsowanie to nie jest banalna
>> sprawa, a nie "bezproblemowe pisanie".
> 
> To wcale nie jest moje zdanie.

OK. Wymieniłeś tyle zadań parsowania, że uznałem, że też widzisz w tym
zadaniu dużą złożoność.
 
> Parsowanie z reguły jest prostą sprawą, a do tego od dawna bardzo dobrze
> zbadaną.

Rozumiem, że na chwilę uciekło twojej uwadze parsowanie jako zadanie ogólne.
Rozumiem, że wszyscy chcą udowodnić, że każdy język łatwo się parsuje, a
tylko C C++ i Perl są czarnymi owcami, z czego C++ jest jeszcze wilkiem i
kozą.

> Nie trzeba wcale używać gotowych narzędzi, a już zwłaszcza nie 
> trzeba używać narzędzi, których się nie rozumie.

Słusznie.

> Parser łatwo pisać 
> ręcznie w dowolnym języku ogólnego przeznaczenia, czeka nas najwyżej
> trochę monotonnej roboty.

Tak.

> Tylko nieliczne składnie (C, C++, Perl) wymagają nadzwyczajnego
> czarowania przy parsowaniu.

Przyjżyj się projektom automatycznych translatorów, które próbują parsować
zdania w języku np. niemieckim i zamieniać na angielski. 
Zobacz jakie to jest trudne zadanie. Zacznij od zapisu składni w postaci
EBNF ;-).
Największe sukcesy w tej materii jak na razie odnosi Google Translate.
Odnosi je właśnie dzięki temu, że do zadania parsowania (i nie tylko)
podchodzi w specyficzny sposób. 
Stosuje właśnie różnorakie wyszukiwanie wzorców w zdaniach i próbuje je
odbudowywać na bazie znanych już wzorców w języku docelowym. 
W szczególności, np. język polski nie preferuje powtórzeń, to powoduje, że
kolejne parsowane i przekształcane zdanie zależy od poprzedniego i nie
tylko. A co z idiomami lub slangiem?

Oczywiście rozumiem, że można się ograniczać do parsowania cudów nie widów
mając gotowce EBNF pobrane z sieci. To jest wtedy łatwa lub nie w
zależności od tego jaki tutek jest dostępny dla generatora parsera.

W każdym razie parsowanie C++ w stosunku do ogólnych zadań parsowania to
jest pikuś.

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

Dnia 14-12-2007, Pt o godzinie 20:36 +0100, Seweryn Habdank-Wojewódzki
pisze:

> Rozumiem, że wszyscy chcą udowodnić, że każdy język łatwo się parsuje,
> a tylko C C++ i Perl są czarnymi owcami, z czego C++ jest jeszcze
> wilkiem i kozą.

Trafnie streściłeś to zagadnienie.

> Przyjżyj się projektom automatycznych translatorów, które próbują parsować
> zdania w języku np. niemieckim i zamieniać na angielski.

Mówiłem o językach programowania, a nie o językach naturalnych.

> W każdym razie parsowanie C++ w stosunku do ogólnych zadań parsowania to
> jest pikuś.

Chyba jedynym językiem poza C++, którego nie da się parsować bez
napisania połowy kompilatora, a więc którego trudność w parsowaniu
jest tej klasy co C++, jest Common Lisp z reader macros (program może
w pewnym sensie zawierać implementację fragmentów parsera, więc parser
musi zawierać interpreter Lispa).

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

Witam

Marcin ?Qrczak? Kowalczyk wrote:

>> W każdym razie parsowanie C++ w stosunku do ogólnych zadań parsowania to
>> jest pikuś.
> 
> Chyba jedynym językiem poza C++, którego nie da się parsować bez
> napisania połowy kompilatora, a więc którego trudność w parsowaniu
> jest tej klasy co C++, jest Common Lisp z reader macros (program może
> w pewnym sensie zawierać implementację fragmentów parsera, więc parser
> musi zawierać interpreter Lispa).

Dziękuję za to cenne uzupełnienie mojej wiedzy :-). 
Szkoda, że ta wiedza nie jest powszechna w tym wątku.

Pozdrawiam. 

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

Dnia 14-12-2007, Pt o godzinie 20:48 +0100, Marcin ‘Qrczak’ Kowalczyk
pisze:

> Chyba jedynym językiem poza C++, którego nie da się parsować bez
> napisania połowy kompilatora, a więc którego trudność w parsowaniu
> jest tej klasy co C++, jest Common Lisp z reader macros (program może
> w pewnym sensie zawierać implementację fragmentów parsera, więc parser
> musi zawierać interpreter Lispa).

Przy czym w Lispie to ma swoje uzasadnienie. Piszemy kawałki parsera,
żeby używać zwięzłej składni dla specjalizowanych sytuacji (np. dla
wyrażeń regularnych) - chodzi tu o poziom leksykalny.

Natomiast w C++ wyszło tak niechcący, przez zaszłość historyczną.

Kiedy język C wprowadzał składnię "typ zmienna;" dla zmiennej typu
prostego, "typ zmienna[];" dla wskaźnika (kiedyś to była składnia
wskaźnika) i "typ zmienna();" dla funkcji (kiedyś nie określało się
typów parametrów), to nie miał jeszcze typedefów. Każdy typ bazowy
zaczynał się od charakterystycznego dla typów słowa kluczowego
(np. "int" albo "struct"). Wtedy język C parsował się łatwo.

Potem zachowując konwencje składni dodano typedefy, typy funkcyjne
z określeniem parametrów, C++ dodał swoje rzeczy - też stopniowo
(np. w pewnym momencie zadecydowano, że należy dokładniej analizować
treść szablonu przed jego konkretyzacją, sprawdzać typy tam gdzie
się da, a nie tylko znajdować klamrę kończącą i zapamiętywać ciąg
leksemów) i wszystko się pokomplikowało.

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

Seweryn Habdank-Wojewódzki wrote:
>>No bo ruszanie tego kodu powinno byc zabronione pod
>>kara wywalenia z pracy :) (a nie zawsze tak jest :)
> 
> Hmm... może i tak, ale warto zerknąć, co tam się dzieje.

Bez sensu. Tabele shift-reduce z jakiegoś tam Yacca są kompletnie nieczytelne.

>>>>Krócej a znaczy tyle samo. Logiki to za mnie nie rozwiąże, ale pisania
>>>>dużo mniej, zapis czytelniejszy i trudniej o błąd.
>>>
>>>Oczywiście.
>>>Z wyjątkiem faktu, że ręcznie napiszesz kontekstowy parser nawet
>>>prostego języka, a takie automaty mają kłopoty.
>>
>>Co ?
>>Ze niby recznie opiszesz sie wtedy mniej ?
> 
> 
> Nie. Ale parser kontekstowy trudno jest zrobić automatem.

Parser kontekstowy jest trudno zrobić. Tyle, że w przypadku języków 
programowania ten problem dotyczy kilu zalewdwie przypadków i w jednym z 
nich wynika nie z zaprojektowanej wyrażalności tylko z braku projektu i 
chaosu -- ten przypadek to ...C++

pzdr
\SK

Seweryn Habdank-Wojewódzki wrote:
> Szkoda, że ta wiedza nie jest powszechna w tym wątku.

Ależ w tej części wątku ta wiedza jest powszechna -- posiadają ją wsyscy 
uczestnicy tego odgałęzienia poza takim jednym, który ma imię na S ale to 
nie ja :)

pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

> Seweryn Habdank-Wojewódzki wrote:
>> Szkoda, że ta wiedza nie jest powszechna w tym wątku.
> 
> Ależ w tej części wątku ta wiedza jest powszechna -- posiadają ją wsyscy
> uczestnicy tego odgałęzienia poza takim jednym, który ma imię na S ale to
> nie ja :)

To co za problem, że C++ ma trudny parser. Zresztą mówiłem jeśli "parsownie
C++" to jest jedyny probelem informatyki, to ośmieszacie ją. Zresztą, jeśli
ktoś sobie nie poradził z napisaniem parsera c++, to nie jest to dla mnie
żaden wyznacznik. Znam studentów co mają kłopoty z liczenem.

Pozdrawiam.

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

Witam

Sebastian Kaliszewski wrote:

> Seweryn Habdank-Wojewódzki wrote:
>>>No bo ruszanie tego kodu powinno byc zabronione pod
>>>kara wywalenia z pracy :) (a nie zawsze tak jest :)
>> 
>> Hmm... może i tak, ale warto zerknąć, co tam się dzieje.
> 
> Bez sensu. Tabele shift-reduce z jakiegoś tam Yacca są kompletnie
> nieczytelne.

Hmmm... to czemu nie przeszkadza Ci używanie Yacc, a na MPL najeżdżasz.

Wasza teoryjka, to używać i nie patrzyć co jest pod spodem.
 
> Parser kontekstowy jest trudno zrobić. Tyle, że w przypadku języków
> programowania ten problem dotyczy kilu zalewdwie przypadków i w jednym z
> nich wynika nie z zaprojektowanej wyrażalności tylko z braku projektu i
> chaosu -- ten przypadek to ...C++

To już wiem.

Pozdrawiam.

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

"Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> wrote:

> To co za problem, że C++ ma trudny parser.

Ano taki maly problem ze to _skutecznie uniemozliwia_
pewny reverse-engineering kodu (rzecz powszechna , podstawowa,
pewna i uzyteczna np. w Javie).
Druga "slodkoscia" ktora to uniemozliwia jest slawetny C++owy
preprocesor.

> Zresztą mówiłem jeśli "parsownie C++" to jest jedyny probelem informatyki,
>  to ośmieszacie ją.

Jakiej informatyki ?!
Kto tu mowi/mowil o informatyce ?
To jeden z problemow C++ zaledwie.

> Zresztą, jeśli ktoś sobie nie poradził z napisaniem parsera c++,
> to nie jest to dla mnie żaden wyznacznik.
> Znam studentów co mają kłopoty z liczenem.

No coz ja poradze ze ma Pan klopoty z liczeniem.
No chyba ze poradzil Pan sobie z napisaniem parsera C++?

Poradzil Pan sobie ?

AK

Seweryn Habdank-Wojewódzki wrote:
>>>>No bo ruszanie tego kodu powinno byc zabronione pod
>>>>kara wywalenia z pracy :) (a nie zawsze tak jest :)
>>>
>>>Hmm... może i tak, ale warto zerknąć, co tam się dzieje.
>>
>>Bez sensu. Tabele shift-reduce z jakiegoś tam Yacca są kompletnie
>>nieczytelne.
> 
> Hmmm... to czemu nie przeszkadza Ci używanie Yacc, a na MPL najeżdżasz.

Bo MPL jest ohydne w samym użyciu. Mo z MPL kompilatory mają problemy. MPL 
to typowe dla C++ rozwiązywanie problemu, który normalnie rozwiązuje się 
dużo prościej i eleganciej, ale w C++ się nie da.

> Wasza teoryjka, to używać i nie patrzyć co jest pod spodem.

To nie jest nasza teoryjka. To jest rzeczywistość.


>>Parser kontekstowy jest trudno zrobić. Tyle, że w przypadku języków
>>programowania ten problem dotyczy kilu zalewdwie przypadków i w jednym z
>>nich wynika nie z zaprojektowanej wyrażalności tylko z braku projektu i
>>chaosu -- ten przypadek to ...C++
> 
> To już wiem.

To dobrze.


pzdr
\SK

On Mon, 17 Dec 2007 17:15:12 +0100, Adam Karpierz wrote:

> "Seweryn Habdank-Wojewódzki" <shw_mail@wp.pl> wrote:
> 
>> To co za problem, ¿e C++ ma trudny parser.
> 
> Ano taki maly problem ze to _skutecznie uniemozliwia_ pewny
> reverse-engineering kodu (rzecz powszechna , podstawowa, pewna i
> uzyteczna np. w Javie).
> Druga "slodkoscia" ktora to uniemozliwia jest slawetny C++owy
> preprocesor.

Hmm?
Pisanie narzędzi do automatycznej refaktoryzacji rzeczywiście utrudnia. A 
jeśli chodzi o reverse-engieneeringu to część firm potraktuje to jako 
zaletę ;) - a i ponowne wykorzystanie plików nagłówkowych nie wydaje się 
zbytnim problemem.

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

Adam Karpierz wrote:

> No chyba ze poradzil Pan sobie z napisaniem parsera C++?

Nie.

Nawet nie próbowałem używając gotowców ściągniętych z netu w postaci
generatorów parserów i gotowych gramatyk. Bo i po co?

Język ten wymaga od parsera jak to Qrczak napisał "napisania połowy
kompilatora". 
I nawet jeśli połatane były różne bugi to parser nadal by tego wymagał, bo
szablony tego wymagają. I są oczywiście tacy mędrkowie, co im C++ szablony
przeszkadzają. 

Tak więc i tak parser c++ byłby trudny i wymagałby połowy kompilatora.

> Poradzil Pan sobie ?

Nie. 

A Pan odkopał prywatne metody z wysłanego przeze mnie pliku?

Pan machał rękami, że Pan wygrzebie, ja NIE machałem rękami, że napisałem
parser. Więc jak?

Pozdrawiam.

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

Seweryn Habdank-Wojewódzki wrote:
> Gneratory parserów. Kod przez nich tworzony jest bardzo dziwny (raczej z
> kategorii nieruszać).

I dobrze. Kodu generowanego przez kompilator, zwłaszcza zoptymalizowowawnego 
też nie należy ruszać.


>>A co za różnica? Po jaką cholerę się męczyć, jak można użyć właściwego
>>narzędzia. Narzędzia, które odwali za mnie mechaniczną część roboty.
> 
> Używać to nie znaczy rozumieć co się dzieje pod maską. 

Do kanonu wykształcenia informatycznego należy wiedza "co się dzieje pod 
maską".

> Jak na razie
> przychylam się do opisów Qrczaka, że parsowanie to nie jest banalna sprawa,
> a nie "bezproblemowe pisanie".

Parsowanie normalnych języków prgoramowania jest sprawą zupełnie prostą 
(trzeba posiąść pewną podstawową wiedzę) tylko żmudną (a żmudność generatory 
szybko redukują).


>>Krócej a znaczy tyle samo. Logiki to za mnie nie rozwiąże, ale pisania
>>dużo mniej, zapis czytelniejszy i trudniej o błąd.
> 
> Oczywiście. Z wyjątkiem faktu, że ręcznie napiszesz kontekstowy parser nawet
> prostego języka, a takie automaty mają kłopoty.

Z tego wynika tylko tyle, że w językach programowania należy kontekstowości 
unikać i bez uzasadnienia nie używać. Kontekstowość C++ to wynik b.delu w 
projekcie i podejścia, że autorzy kompilatorów jakoś sobie poradzą.


> Kiedyś pisałem parser prostej gramatyki ale kontekstowej i nie było to
> bardzo proste, tak więc mam inne zdanie niż Ty o parsowaniu w ogólności.

Pisałem nie jeden parser. Dla normalnych języków programowania to jest 
zadanie proste.


>>Widzę, że nic a nic nie rozumiesz.
>>-- po co ci jakiś język wyższego poziomu, przecież nie będziesz korzystał
>>z gotowców... 
> 
> Może i tak, może i nie. W każdym razie znajomość gotowca/generatora nie
> wskazuje o zrozumieniu tematu, a już na 100% nie o tym czy faktyczne
> zadanie jest proste czy nie.

Zadanie jest proste zarówno dla Javy jak i Pythona. Jest trudne dla C++, bo 
C++ ma bezsensownie zrobioną składnię.

pzdr
\SK