-
71. Data: 2017-07-11 18:25:48
Temat: Re: Algorytm hex,dec<->liczba
Od: s...@g...com
> Poza tym ma największe możliwości z pośród dostępnych języków programowania:
szablony, wielodziedziczenie, przeładowywanie operatorów.
Zapomniałem dodać, że jest do tego kompatybilny z C i Asemblerem i to nie w jakiś
pokraczny sposób, ale w standardzie...
-
72. Data: 2017-07-11 19:16:00
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Tue, 11 Jul 2017 09:25:48 -0700 (PDT), s...@g...com wrote:
> > Poza tym ma największe możliwości z pośród dost=
> ępnych języków programowania: szablony, wielodziedziczenie, =
> przeładowywanie operatorów.
No, no.
A ma monady? Nie ma? O to wuj!
Tak na marginesie: redefiniowanie operatorów to nie jest tak dobry
pomysł jak się wydawało w latach 90-tych. Dziedziczenie
wielobazowe... no cóż ma to zalety seksu grupowego: wiele możliwości,
ale nie każdy w tym się odnajdzie, potem nie wiadomo co jest
odziedziczone po kim, drzewo klas przypomina zasieki spod Verdun.
Koparka jest dzieckiem silnika i łyżki oraz gąsienicy. A może jednak
ma silnik, łyżkę i gąsienicę? Szablony? Po co komu szablony jak ma
kaczyzm typowania? Szablony to tylko próba, co prawda heroiczna,
obejścia dyscypliny w typach.
-
73. Data: 2017-07-11 22:30:26
Temat: Re: Algorytm hex,dec<->liczba
Od: "M.M." <m...@g...com>
On Tuesday, July 11, 2017 at 7:16:07 PM UTC+2, slawek wrote:
> On Tue, 11 Jul 2017 09:25:48 -0700 (PDT), s...@g...com wrote:
> > > Poza tym ma największe możliwości z pośród dost=
> > ępnych języków programowania: szablony, wielodziedziczenie, =
> > przeładowywanie operatorów.
>
> No, no.
>
> A ma monady? Nie ma? O to wuj!
>
> Tak na marginesie: redefiniowanie operatorów to nie jest tak dobry
> pomysł jak się wydawało w latach 90-tych.
Gdy normalnie programuję, to są dwie możliwości. Albo robię klasę
obudowującą (niemal dosłownie) jednego inta i dla niej operatory
dodawania, odejmowania są tak naturalne, że sam nie wiem kiedy
te operatory przedefiniuję. Albo... w ogóle nigdy nie przedefiniowuję
operatorów. Gdy nie programuję normalnie, tylko bardzo, bardzo
starannie i dam sobie dużo czasu na przemyślenie, to wtedy czasami w
minimalnym stopniu używam przedefiniowania. Podsumowując, gdy się
pisze w pośpiechu, to funkcja jednak jest tworem w jakimś minimalnym
stopniu samodokumentującym się.
> Dziedziczenie
> wielobazowe... no cóż ma to zalety seksu grupowego:
Nie. Ma to takie zalety, (rzecz jasna chodzi o zalety względem
konkurencyjnego rozwiązania jakim jest agregacja wielu obiektów
wewnątrz klasy bazowej) że nie trzeba przeklepywać nazw funkcji, a
gdy nazwy takie same (potencjalny konflikt) to można użyć
operatora :: i wskazać o którą bazową klasę chodzi. Bez dziedziczenia
wielobazowego nie masz od razu dostępu do wszystkich metod w klasach
bazowych.
> wiele możliwości, ale nie każdy w tym się odnajdzie, potem nie
> wiadomo co jest odziedziczone po kim, drzewo klas przypomina
> zasieki spod Verdun.
Tak, gdy nadużywałem, to miałem właśnie takie problemy. Przyznaję
rację, że łatwo o nadużycia. Niejeden programista, w tym ja sam
tak robiłem, stosuje wielodziedziczenie np. po to aby zabłysnąć
że opanował ten mechanizm.
> Koparka jest dzieckiem silnika i łyżki oraz gąsienicy.
Bez względu na to, czy przekonałeś mnie tym przykładem, czy nie, powiedz,
co proponujesz w zamian dziedziczenia wielobazowego? Proponujesz
agregację? Zgadłem? Jeśli zgadłem, to powiedz mi, co zabrania stosowania
agregacji w C++? Otóż nic tego nie zabrania. A że ludzie nadużywają...
cóż mam powiedzieć, sam nadużywałem.
> A może jednak
> ma silnik, łyżkę i gąsienicę? Szablony?
To już było powyżej.
> Po co komu szablony jak ma
> kaczyzm typowania? Szablony to tylko próba, co prawda heroiczna,
> obejścia dyscypliny w typach.
Owszem. Elegancki kaczyzm w C++ to metody wirtualne. Rozwiązania na
metodach wirtualnych (lub jakiś wskaźnikach na funkcje) są moim
zdaniem bardziej przejrzyste. Poza tym składnia szablonów jest
brzydka, ale z tego co wiem, szukano składni alternatywnej i
nic fajnego nie znaleziono. Szablony od jakiegoś czasu dają kompilatorowi
szansę na wygenerowanie bardziej efektywnego kodu, skrojonego na konkretny
typ. Dają też szansę na wychwycenie niektórych błędów.
Pozdrawiam
-
74. Data: 2017-07-11 23:53:42
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Tue, 11 Jul 2017 13:30:26 -0700 (PDT), "M.M." <m...@g...com>
wrote:
> Nie. Ma to takie zalety, (rzecz jasna chodzi o zalety względem
> konkurencyjnego rozwiązania jakim jest agregacja wielu obiektów
> wewnątrz klasy bazowej)
A w takiej np. Javie można użyć interfejsów. Albo mieć klasę z
zagnieżdżonymi klasami które dziedziczą osobno. Jakoś to musi
działać, skoro ludzie piszą w tej Javie i nie narzekają. W
Sorry, Python to nie jest szczególnie ogarnięty język, ale jak
porównać co można przez szablony w C++, a co można bez szablonów w
Pythonie (metaprogramowanie), to Python wygrywa bezdyskusyjnie.
-
75. Data: 2017-07-12 01:00:08
Temat: Re: Algorytm hex,dec<->liczba
Od: "M.M." <m...@g...com>
On Tuesday, July 11, 2017 at 11:53:44 PM UTC+2, slawek wrote:
> On Tue, 11 Jul 2017 13:30:26 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
> > Nie. Ma to takie zalety, (rzecz jasna chodzi o zalety względem
> > konkurencyjnego rozwiązania jakim jest agregacja wielu obiektów
> > wewnątrz klasy bazowej)
>
> A w takiej np. Javie można użyć interfejsów.
Zalety, o której pisałem wyżej, nie można uzyskać dzięki
interfejsom. Każdą metodę interfejsu trzeba nadpisać w
klasie implementującej ten interfejs. W przypadku agregacji,
o której piszesz poniżej a ja też pisałem powyżej, nie
trzeba nadpisywać, ale bez nadpisania nie ma się dostępu do
metod agregowanych klas. Tylko w przypadku wielodziedziczenia
ma się dostęp do składowych więcej niż dwóch klas (poprawnie:
więcej niż dwóch hierarchii klas) bez reimplementacji.
Przykład z dziedziczeniem pojedynczym
class A {
metoda1() {
}
};
class B1 {
A a;
};
class B2 : A {
};
B1 b1;
b1.metoda1(); // błąd bez reimplementacji
B2 b2;
b2.metoda1(); // działa bez reimplementacji
////////////////////////////////////////////
To samo będzie w przypadku wielodziedziczenia.
class A {
metodaA() {}
};
class B {
metodaB() {}
};
class C1 {
A a;
B b;
};
class C2 : A, B {
};
C1.metodaA() // błąd;
C1.metodaB() // błąd
Muszę się męczyć i dopisywać:
class C1 {
A a;
B b;
metodaA() {
a.metodaA();
}
metodaB() {
b.metodaB();
}
};
W przypadku klasy C2, kompilator za mnie to dopisze. Gdy używam C++, to
jeszcze mam dziedziczenie wirtualne, aby lepiej kompilatorowi
podpowiedzieć o jakie zachowanie klasy wyprowadzonej z kilku klas mi
chodzi.
> Albo mieć klasę z
> zagnieżdżonymi klasami które dziedziczą osobno.
To jest właśnie agregacja.
> Jakoś to musi
> działać, skoro ludzie piszą w tej Javie i nie narzekają.
Działa, ale trzeba dopisać ręcznie to co może dopisać kompilator.
> W
>
> Sorry, Python to nie jest szczególnie ogarnięty język, ale jak
> porównać co można przez szablony w C++, a co można bez szablonów w
> Pythonie (metaprogramowanie), to Python wygrywa bezdyskusyjnie.
Rozwiń proszę.
Pozdrawiam
-
76. Data: 2017-07-12 08:21:41
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Tue, 11 Jul 2017 16:00:08 -0700 (PDT), "M.M." <m...@g...com>
wrote:
> W przypadku agregacji,
> o której piszesz poniżej a ja też pisałem powyżej,
Nie chodzi o class Qux { Bar b1; Buz b2; }.
Ale o class Foo { class Bar extends BaseBar {...}; class Buz extends
BaseBuz {...}; }
-
77. Data: 2017-07-12 11:43:22
Temat: Re: Algorytm hex,dec<->liczba
Od: Roman Tyczka <n...@b...no>
On Tue, 11 Jul 2017 17:53:00 +0200, slawek wrote:
>> To się nazywa przepisywanie, my tu mówimy o funkcji odzyskiwanej =
>> z kodu maszynowego.
>
> A niby o czym?
>
> Jest kod maszynowy. Da się odtworzyć na jego podstawie kod źródłowy.
> Zwłaszcza jeżeli znamy jaki był kompilator.
A Sławuś jak zwykle gubi się w zeznaniach. Napisałeś:
"Swego czasu rekonstrowałem funkcję C z jej kodu źródłowego. Można."
Przeczytaj jeszcze raz spokojnie i przemyśl to :-)
--
pozdrawiam
Roman Tyczka
-
78. Data: 2017-07-12 14:05:55
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Wed, 12 Jul 2017 11:43:22 +0200, Roman Tyczka <n...@b...no>
wrote:
> "Swego czasu rekonstrowałem funkcję C z jej kodu źródłowego. Można."
Powinno być "do" zamiast "z".
-
79. Data: 2017-07-12 15:24:20
Temat: Re: Algorytm hex,dec<->liczba
Od: "M.M." <m...@g...com>
On Wednesday, July 12, 2017 at 8:21:44 AM UTC+2, slawek wrote:
> On Tue, 11 Jul 2017 16:00:08 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
> > W przypadku agregacji,
> > o której piszesz poniżej a ja też pisałem powyżej,
>
> Nie chodzi o class Qux { Bar b1; Buz b2; }.
>
> Ale o class Foo { class Bar extends BaseBar {...}; class Buz extends
> BaseBuz {...}; }
Jak ten przykład wpływa na te korzyści co napisałem?
Pozdrawiam
-
80. Data: 2017-07-12 20:44:33
Temat: Re: Algorytm hex,dec<->liczba
Od: "AK" <n...@n...net>
Użytkownik "Roman Tyczka" <n...@b...no> napisał:
> A Sławuś jak zwykle gubi się w zeznaniach. Napisałeś:
>
> "Swego czasu rekonstrowałem funkcję C z jej kodu źródłowego. Można."
>
> Przeczytaj jeszcze raz spokojnie i przemyśl to :-)
Co tu "przemysliwac" ?
Normalka.
W przypadku gdy zna sie kompilator (i lib-y) to zrodla sa calikem ok.
W przypadku bytecode (ktory jest zwykle wyzszego poziomu niz kod maszynowy) tym
bardziej.
PS0: Do zabezpiecznia code/bytecode przed dekompilacja sluza podpisy.
PS: Slawus ma racje. Nihil novi sub sole
AK