🚀 go-pugleaf

W dniu 2018-06-07 o 11:02, radoslaw@korzeniewski.net pisze:
> Witam,
> 
> Mam klasę bazową A:
> class A {
>    bool send() { return send(0); };
>    virtual bool send(int flags);
> }
> oraz klasę pochodną B:
> class B: public A {
>    bool send(int flags);
> }
> chciałbym teraz móc skorzystać z B.send() ale kompilator wywala:
> error: no matching function for call to ‘B::send()’
>    b.send();
>               ^
> note: candidate: virtual bool B::send(int)
> obejście w postaci zdefiniowania B::send() jakoś mi nie pasuje. Przyjmę wszelaką krytykę i pomoc, także query do google.
> 

Nie jestem biegłym programistą (raz na rok jakiś mały programik 
narzędziowy mi się zdarzy).

Moim pierwszym skojarzeniem jest, że send() jest prywatną funkcją A. 
Można ją wywołać tylko w funkcjach klasy A.
P.G.

W dniu czwartek, 7 czerwca 2018 12:06:14 UTC+2 użytkownik Piotr Gałka napisał:
> Moim pierwszym skojarzeniem jest, że send() jest prywatną funkcją A. 
> Można ją wywołać tylko w funkcjach klasy A.
Niestety to nie to. Wstawienie public: dla send() niczego nie zmienia.

W dniu 07.06.2018 o 11:02, radoslaw@korzeniewski.net pisze:
> Witam,
> 
> Mam klasę bazową A:
> class A {
>    bool send() { return send(0); };
>    virtual bool send(int flags);
> }
> oraz klasę pochodną B:
> class B: public A {
>    bool send(int flags);
> }
> chciałbym teraz móc skorzystać z B.send() ale kompilator wywala:
> error: no matching function for call to ‘B::send()’
>    b.send();
>               ^
> note: candidate: virtual bool B::send(int)
> obejście w postaci zdefiniowania B::send() jakoś mi nie pasuje. Przyjmę wszelaką krytykę i pomoc, także query do google.
> 
Send z B przykrywa wirtualną, trzeba
b.A::send();
- sprawdzone na VStudio

W dniu 2018-06-07 o 15:16, Borneq pisze:
> W dniu 07.06.2018 o 11:02, radoslaw@korzeniewski.net pisze:
>> Witam,
>>
>> Mam klasę bazową A:
>> class A {
>>    bool send() { return send(0); };
>>    virtual bool send(int flags);
>> }
>> oraz klasę pochodną B:
>> class B: public A {
>>    bool send(int flags);
>> }
>> chciałbym teraz móc skorzystać z B.send() ale kompilator wywala:
>> error: no matching function for call to ‘B::send()’
>>    b.send();
>>               ^
>> note: candidate: virtual bool B::send(int)
>> obejście w postaci zdefiniowania B::send() jakoś mi nie pasuje. 
>> Przyjmę wszelaką krytykę i pomoc, także query do google.
>>
> Send z B przykrywa wirtualną, trzeba
> b.A::send();
> - sprawdzone na VStudio

Dla mnie dziwne.
Skoro B nie ma send() to powinna zawołać się send() z A (jeśli publiczna).
Ta powinna zawołać send(int), a że ta jest wirtualna to powinna zawołać 
się ta z B.
P.G.

W dniu czwartek, 7 czerwca 2018 15:16:29 UTC+2 użytkownik Borneq napisał:
> W dniu 07.06.2018 o 11:02, r... pisze:
> > Witam,
> > 
> > Mam klasę bazową A:
> > class A {
> >    bool send() { return send(0); };
> >    virtual bool send(int flags);
> > }
> > oraz klasę pochodną B:
> > class B: public A {
> >    bool send(int flags);
> > }
> > chciałbym teraz móc skorzystać z B.send() ale kompilator wywala:
> > error: no matching function for call to ‘B::send()’
> >    b.send();
> >               ^
> > note: candidate: virtual bool B::send(int)
> > obejście w postaci zdefiniowania B::send() jakoś mi nie pasuje. Przyjmę wszelaką krytykę i pomoc, także query do google.
> > 
> Send z B przykrywa wirtualną, trzeba
B::send(int) jest tam specjalnie aby dostarczyć inną implementację metody send().

> b.A::send();

Ale to wymaga znajomości klasy podstawowej poza implementacja klasy co jest sprzeczne z ideą dziedziczenia.

> - sprawdzone na VStudio

Dzięki.

W dniu czwartek, 7 czerwca 2018 15:35:11 UTC+2 użytkownik Piotr Gałka napisał:
> Dla mnie dziwne.
> Skoro B nie ma send() to powinna zawołać się send() z A (jeśli publiczna).
> Ta powinna zawołać send(int), a że ta jest wirtualna to powinna zawołać 
> się ta z B.

Dokładnie taki sam tok myślenia przeprowadziłem ale niestety generuje to błąd podczas kompilacji. Zakładam że to ja jestem w błędzie i dlatego poszukuję pomocy.

Dzięki.

> Ale to wymaga znajomości klasy podstawowej poza implementacja klasy co jest sprzeczne z ideą dziedziczenia.

Dodam jeszcze, że "obejściem problemu" było zwyczajne skopiowanie send() z klasy A do klasy B. Ale uważam, że to najmniej eleganckie rozwiązanie. Chociaż z drugiej strony jak coś jest głupie ale działa to nie jest głupie. Jednak wolał bym dowiedzieć się (i nauczyć) dlaczego mój tok rozumowania jest błędny - bo jest.

W dniu 2018-06-07 o 15:42, radoslaw@korzeniewski.net pisze:
> W dniu czwartek, 7 czerwca 2018 15:35:11 UTC+2 użytkownik Piotr Gałka napisał:
>> Dla mnie dziwne.
>> Skoro B nie ma send() to powinna zawołać się send() z A (jeśli publiczna).
>> Ta powinna zawołać send(int), a że ta jest wirtualna to powinna zawołać
>> się ta z B.
> 
> Dokładnie taki sam tok myślenia przeprowadziłem ale niestety generuje to błąd podczas kompilacji. Zakładam że to ja jestem w błędzie i dlatego poszukuję pomocy.
> 

Sprawdziłem pod C++ Builder 5 (który używam) i jest tak samo jak u Ciebie.
Wychodzi na to, że zapewne użycie tej samej nazwy w klasie pochodnej 
zasłania wszystkie funkcje o takiej nazwie z kasy bazowej.
Chodzi mi po głowie, że mogłem kiedyś coś takiego wiedzieć, ale wiedza 
nie używana ulatuje (o dziedziczeniu uczyłem się z książki od C do C++, 
którą kupiłem w 93r.).
P.G.

W dniu 07.06.18r. o 18:52, Piotr Gałka pisze:
> W dniu 2018-06-07 o 15:42, radoslaw@korzeniewski.net pisze:
>> W dniu czwartek, 7 czerwca 2018 15:35:11 UTC+2 użytkownik Piotr Gałka 
>> napisał:
>>> Dla mnie dziwne.
>>> Skoro B nie ma send() to powinna zawołać się send() z A (jeśli 
>>> publiczna).
>>> Ta powinna zawołać send(int), a że ta jest wirtualna to powinna zawołać
>>> się ta z B.
>>
>> Dokładnie taki sam tok myślenia przeprowadziłem ale niestety generuje 
>> to błąd podczas kompilacji. Zakładam że to ja jestem w błędzie i 
>> dlatego poszukuję pomocy.
>>
> 
> Sprawdziłem pod C++ Builder 5 (który używam) i jest tak samo jak u Ciebie.
> Wychodzi na to, że zapewne użycie tej samej nazwy w klasie pochodnej 
> zasłania wszystkie funkcje o takiej nazwie z kasy bazowej.
> Chodzi mi po głowie, że mogłem kiedyś coś takiego wiedzieć, ale wiedza 
> nie używana ulatuje (o dziedziczeniu uczyłem się z książki od C do C++, 
> którą kupiłem w 93r.).
> P.G.

Tak wlasnie jest w C++ (odwrotnie niz w Javie, tam by to dzialalo). I 
nawet jest na to uzasadnienie. Zalozmy, ze mamy takie cos:

	struct A { void f(long); };
	struct B : A { void f(long); };

	B b;
	b.f(0);

Oczywiscie zawola sie B::f. Teraz przypuscmy, ze nagle ktos postanowil 
do klasy A dolozyc funkcje void f(int);. Gdyby B::f nie przykrywalo 
wszystkich wersji A::f to w tym momencie zawolaloby sie A::f(int) i 
zmienia sie dzialanie naszego programu (0 jest int-em, wczesniej bylo 
niejawnie rzutowane na longa). Jezeli teraz spojrzymy na A jak na 
interfejs a na B jak na implementacje, to zmiana czegos w interfejsie 
moze rozwalic caly program. Co wiecej tak samo by bylo gdyby w A 
wczesniej w ogole nie bylo funkcji f. Dolozenie f(int) by wszystko 
rozwalilo. Jeszcze dolozmy do tego, ze tworca A raczej nie musi wiedziec 
jak jego interfejs jest uzywany, wiec moze dokladac co chce. Az dziw, ze 
programy w Javie dzialaja po upgradzie API :)

Marcin

W dniu czwartek, 7 czerwca 2018 22:32:17 UTC+2 użytkownik Marcin napisał:
> W dniu 07.06.18r. o 18:52, Piotr Gałka pisze:
> > W dniu 2018-06-07 o 15:42, r.... pisze:
> >> W dniu czwartek, 7 czerwca 2018 15:35:11 UTC+2 użytkownik Piotr Gałka 
> >> napisał:
> >>> Dla mnie dziwne.
> >>> Skoro B nie ma send() to powinna zawołać się send() z A (jeśli 
> >>> publiczna).
> >>> Ta powinna zawołać send(int), a że ta jest wirtualna to powinna zawołać
> >>> się ta z B.
> >>
> >> Dokładnie taki sam tok myślenia przeprowadziłem ale niestety generuje 
> >> to błąd podczas kompilacji. Zakładam że to ja jestem w błędzie i 
> >> dlatego poszukuję pomocy.
> >>
> > 
> > Sprawdziłem pod C++ Builder 5 (który używam) i jest tak samo jak u Ciebie.
> > Wychodzi na to, że zapewne użycie tej samej nazwy w klasie pochodnej 
> > zasłania wszystkie funkcje o takiej nazwie z kasy bazowej.
> > Chodzi mi po głowie, że mogłem kiedyś coś takiego wiedzieć, ale wiedza 
> > nie używana ulatuje (o dziedziczeniu uczyłem się z książki od C do C++, 
> > którą kupiłem w 93r.).
> > P.G.
> 
> Tak wlasnie jest w C++ (odwrotnie niz w Javie, tam by to dzialalo). I 
> nawet jest na to uzasadnienie. Zalozmy, ze mamy takie cos:
> 
> 	struct A { void f(long); };
> 	struct B : A { void f(long); };
> 
> 	B b;
> 	b.f(0);
> 
> Oczywiscie zawola sie B::f. Teraz przypuscmy, ze nagle ktos postanowil 
> do klasy A dolozyc funkcje void f(int);. Gdyby B::f nie przykrywalo 
> wszystkich wersji A::f to w tym momencie zawolaloby sie A::f(int) i 
> zmienia sie dzialanie naszego programu (0 jest int-em, wczesniej bylo 
> niejawnie rzutowane na longa). Jezeli teraz spojrzymy na A jak na 
> interfejs a na B jak na implementacje, to zmiana czegos w interfejsie 
> moze rozwalic caly program. Co wiecej tak samo by bylo gdyby w A 
> wczesniej w ogole nie bylo funkcji f. Dolozenie f(int) by wszystko 
> rozwalilo. Jeszcze dolozmy do tego, ze tworca A raczej nie musi wiedziec 
> jak jego interfejs jest uzywany, wiec moze dokladac co chce. Az dziw, ze 
> programy w Javie dzialaja po upgradzie API :)
Dziękuję za tak obszerne wyjaśnienia.

Radek

W dniu 2018-06-07 o 22:32, Marcin pisze:
> Oczywiscie zawola sie B::f. Teraz przypuscmy, ze nagle ktos postanowil 
> do klasy A dolozyc funkcje void f(int);. Gdyby B::f nie przykrywalo 
> wszystkich wersji A::f to w tym momencie zawolaloby sie A::f(int) i 
> zmienia sie dzialanie naszego programu (0 jest int-em, wczesniej bylo 
> niejawnie rzutowane na longa). Jezeli teraz spojrzymy na A jak na 
> interfejs a na B jak na implementacje, to zmiana czegos w interfejsie 
> moze rozwalic caly program. Co wiecej tak samo by bylo gdyby w A 
> wczesniej w ogole nie bylo funkcji f. Dolozenie f(int) by wszystko 
> rozwalilo. Jeszcze dolozmy do tego, ze tworca A raczej nie musi wiedziec 
> jak jego interfejs jest uzywany, wiec moze dokladac co chce. Az dziw, ze 
> programy w Javie dzialaja po upgradzie API :)

Mój wniosek: B.Stroustrup dokładnie wiedział co robi.
P.G.

On 2018-06-07 15:46, Radosław Korzeniewski wrote:

>> Ale to wymaga znajomości klasy podstawowej poza implementacja klasy co jest sprzeczne z ideą
>> dziedziczenia.

Prawda.

> Dodam jeszcze, że "obejściem problemu" było zwyczajne skopiowanie send() z klasy A do klasy B.
> Ale uważam, że to najmniej eleganckie rozwiązanie. 

Nie tyle nieelegackie, ale po prostu błędne.

> Chociaż z drugiej strony jak coś jest głupie ale działa to nie jest głupie.

Nistety, ale wciaz jest glupie (a nawet gorzej). :)

> Jednak wolał bym dowiedzieć się (i nauczyć) dlaczego mój tok rozumowania jest błędny - bo jest.

Stosujesz polimorfizm, a wolania stosujesz "zwykłe"/niepolimorficzne.
Po prostu zwyczajnie nei dajesz szans zadzialania polimorfizmowi.

Spóbuj zwyczajnie/książkowo:

class A
{
public:
   bool send() { return send(0); }
   virtual bool send(int flags) = 0;
};

class B : public A
{
public:
   virtual bool send(int flags) { return 123 | 0x02; }
};

int main()
{
   A& b = B(); // sedno sprawy
   b.send();
   return 0;
}

PS: ...a najlepiej porzuć zgrzybiałego staruszka z dwoma krzyżykami
      na karku np. na rzecz Pythona :)

AK

> PS: ...a najlepiej porzuć zgrzybiałego staruszka z dwoma krzyżykami
>       na karku np. na rzecz Pythona :)

Tak się jakoś składa, że:
* C++ to język obiektowy o największych możliwościach (nie tylko w śród języków kompilowanych, ale w ogóle wszystkich jakie powstały)
* C++ pod względem wyników przypomina język Asembler, tyle że pozwala tworzyć aplikacje o dużo bardziej zaawansowanej architekturze (np. ukrywanie danych w klasach i szablony klas i metod)
* ogromne możliwości C++ nie wpływają negatywnie na szybkość działania, bo jezyk jest w całości zaprojektowany przede wszystkim pod kątem szybkości. Więc jego wszystkie zaawansowane funkcje są uwzględniane jedynie w czasie kompilacji do kodu maszynowego (po kompilacji są jedynie funkcje i zmienne jak w Asemblerze, natomiast cały obiektowy majdan jest spłaszczany i nie istnieje w pliku exe/so/dll).
* C++ jest stale rozwijany
* C++ z biblioteką Qt jest bardzo przyjemny w programowaniu (Qt tez jest ciągle rozwijana)
* C++ daje w wyniku NORMALNE programy (bez konieczności łączenia programu z maszynami wirtualnymi, interpreterami, jakichś zwyrodniałych kompilacji do kodu bajtowego i innych wynalazków w stylu Jit). W C++ po prostu masz plik exe czy so/dll i po prostu to działa.
* poważne biblioteki są tylko w C i C++ (i bez problemu można użyć ich obu rodzajów)
* w C++ można pisać przenośne programy (przenośne między systemami operacyjnymi), a jednocześnie mogą dobrze zintegrowane z systemem operacyjnym na którym działają (po przez klauzule typu: #ifdef Q_OS_WIN) - jest to bezproblemowe i bez udziwnień i nie wymaga stosowania niczego innego poza Api danego systemu operacyjnego.
* program w C++ z definicji powinien dużo szybciej działać niż wspomniany Python czy Java czy C#. Gdyż one właśnie są pisane w C++ na bazie jego zalet są tworzone.
* programy w C++ dają akceptowalną szybkość działania w przypadku programów narzędziowych (typu edytory grafiki czy Ide). Tego typu programy pisane wyłącznie np. w Pyhtonie działają po prostu strasznie. Podobnie jest z Java i np. Eclipse (to istnie zaćmienie umysłowe musiało być u tego kto postanowił napisać to w tym języku).
* ten kto nie potrafi pisać programów w Asemblerze i C/C++ ten nie jest prawdziwym programistą. Bo bez tych języków zwyczajnie nie wie jak działa procesor (Asembler) oraz nie wie jak pisane są (a tym samym nie zna możliwości jakie dają) współczesne systemy operacyjne (C/C++).
* dla C++ powstały liczne narzędzia do debugowania i profilowania programów (co nie jest wcale takie oczywiste w przypadku takich wynalazków jak np. PHP)
* języki typu Python nadają się jedynie do pisania jakichś małych skryptów do automatyzacji przetwarzania tekstów. Które pisze się samemu, dla siebie i odpala się tylko u siebie i nie martwi się o czas ich działania. Do tego używam Pythona i w tym on się sprawdza...

W dniu niedziela, 10 czerwca 2018 22:18:21 UTC+2 użytkownik AK napisał:
> > Ale uważam, że to najmniej eleganckie rozwiązanie. 
> 
> Nie tyle nieelegackie, ale po prostu błędne.

To jakie "obejście problemu" nie było by błędne?

> 
> > Chociaż z drugiej strony jak coś jest głupie ale działa to nie jest głupie.
> 
> Nistety, ale wciaz jest glupie (a nawet gorzej). :)

Dlaczego nawet gorzej?

> 
> > Jednak wolał bym dowiedzieć się (i nauczyć) dlaczego mój tok rozumowania jest błędny - bo jest.
> 
> Stosujesz polimorfizm, a wolania stosujesz "zwykłe"/niepolimorficzne.
> Po prostu zwyczajnie nei dajesz szans zadzialania polimorfizmowi.

OK, a mógłbyś wyjaśnić trochę więcej w tej materii. Z góry dziękuję.

> 
> Spóbuj zwyczajnie/książkowo:
> 
> class A
> {
> public:
>    bool send() { return send(0); }
>    virtual bool send(int flags) = 0;

Tworzysz klasę abstrakcyjną bez implementacji ::send(int), a ja potrzebuję dwóch klas, każda z zaimplementowaną "po swojemu" metodą ::send(). Czyli musiał bym zrobić trzecią klasę C dziedziczącą po B, dziedziczącą po abstrakcyjnej A.

> PS: ...a najlepiej porzuć zgrzybiałego staruszka z dwoma krzyżykami
>       na karku np. na rzecz Pythona :)

Wiesz, każdy z języków programowania ma "swoje nisze", zalety i słabości. Pythona stosuję w bardzo wielu projektach i bardzo go lubię.

W dniu poniedziałek, 11 czerwca 2018 06:38:10 UTC+2 użytkownik szyk...@gmail.com napisał:
> > PS: ...a najlepiej porzuć zgrzybiałego staruszka z dwoma krzyżykami
> >       na karku np. na rzecz Pythona :)
> 
> Tak się jakoś składa, że:
> * ogromne możliwości C++ nie wpływają negatywnie na szybkość działania, bo jezyk jest w całości zaprojektowany przede wszystkim pod kątem szybkości.

Raczej chodziło o implementację OOP w języku tak niskopoziomowym jak C: https://www.youtube.com/watch?v=JBjjnqG0BP8
Czyli połączenie dwóch światów: niskopoziomowego C z abstrakcjonizmem znanym z Simula. 

> Więc jego wszystkie zaawansowane funkcje są uwzględniane jedynie w czasie kompilacji do kodu maszynowego (po kompilacji są jedynie funkcje i zmienne jak w Asemblerze, natomiast cały obiektowy majdan jest spłaszczany i nie istnieje w pliku exe/so/dll).

Nie do końca się zgodzę, bo struktura vtable, która jest esencją tego "całego obiektowego majdanu" tam jest i jest nie do pominięcia.

> * C++ daje w wyniku NORMALNE programy (bez konieczności łączenia programu z maszynami wirtualnymi, interpreterami, jakichś zwyrodniałych kompilacji do kodu bajtowego i innych wynalazków w stylu Jit). W C++ po prostu masz plik exe czy so/dll i po prostu to działa.

Z tą dokładnością, że ten plik exe czy so/dll działa tylko dla systemu i architektury dla której został przygotowany i nie ma technicznych możliwości poza emulacją (czyli jakieś maszyny wirtualne, interpretatory czy JIT) aby uruchomić go na czymś innym. Tej wady nie mają języki które korzystają z wspomnianych wyżej maszyn wirtualnych, interpretatorów byte-kodu czy JIT. Generalnie coś za coś. 

> * poważne biblioteki są tylko w C i C++ (i bez problemu można użyć ich obu rodzajów)

Cokolwiek masz na myśli pod pojęciem "poważne", to z wymiennością C i C++ nie jest tak różowo. Owszem, bez problemu i jakichkolwiek starań możesz użyć funkcji napisanej w C bezpośrednio w programie napisanym w C++, ale odwrotne działanie już jest mocno problematyczne.
Z tego co obserwuję podczas pracy, to biblioteki napisane w C/C++ (mające API dla tych języków) to przede wszystkim funkcjonalności niskopoziomowe, może "średnio" poziomowe. Wszelkie wysoko-poziomowe albo nie mają API dla C/C++ albo istniejące API jest zrobione "aby było i można było wpisać do CV", z wersją 0.1 beta aktualizowaną 4 lata temu. Oczywiście YMMV.

> * w C++ można pisać przenośne programy (przenośne między systemami operacyjnymi), a jednocześnie mogą dobrze zintegrowane z systemem operacyjnym na którym działają (po przez klauzule typu: #ifdef Q_OS_WIN) - jest to bezproblemowe i bez udziwnień i nie wymaga stosowania niczego innego poza Api danego systemu operacyjnego.

Przenośne w sensie kodu źródłowego do skompilowania, tak można. Warunkiem jest jednak rozwiązanie ogromnej ilości pobocznych problemów związanych z różnicą API takich systemów.

> * program w C++ z definicji powinien dużo szybciej działać niż wspomniany Python czy Java czy C#. Gdyż one właśnie są pisane w C++ na bazie jego zalet są tworzone.

W pewnym sensie masz rację, jednak w pozostałym się mocno mylisz. Java może być skompilowana do natywnego kodu. A w pewnym sensie nawet kod binarny na poziomie współczesnych procesorów jest "interpretowany" na poziomie sprzętowym. 

> * programy w C++ dają akceptowalną szybkość działania w przypadku programów narzędziowych (typu edytory grafiki czy Ide). Tego typu programy pisane wyłącznie np. w Pyhtonie działają po prostu strasznie. Podobnie jest z Java i np. Eclipse (to istnie zaćmienie umysłowe musiało być u tego kto postanowił napisać to w tym języku).

Zależy od tego jak to programista napisał i generalnie nie zależy od wybranego języka.

> * ten kto nie potrafi pisać programów w Asemblerze i C/C++ ten nie jest prawdziwym programistą. Bo bez tych języków zwyczajnie nie wie jak działa procesor (Asembler) oraz nie wie jak pisane są (a tym samym nie zna możliwości jakie dają) współczesne systemy operacyjne (C/C++).

Na obecnym etapie rozwoju informatyki pisanie w Assemblerze jest skrajnie nieefektywne nie tylko ze względu na czas poświęcony na napisanie takiej aplikacji ale także ze względu na możliwy do osiągnięcia poziom optymalizacji kodu. W tej materii kompilatory już dawno prześcignęły możliwości człowieka. Owszem pojedyncze, specjalizowane funkcje można napisać lepiej i często tak się robi. To są jednak wyjątki.

> * języki typu Python nadają się jedynie do pisania jakichś małych skryptów do automatyzacji przetwarzania tekstów. Które pisze się samemu, dla siebie i odpala się tylko u siebie i nie martwi się o czas ich działania. Do tego używam Pythona i w tym on się sprawdza...

Python, Java itp. języki już dawno dorobiły się ogromnej ilości wysoko-poziomowych bibliotek/narzędzi (o czym pisałem powyżej) przez co pisanie całych aplikacji jest w tych językach znacznie prostsze, efektywniejsze i przez to znacznie tańsze. To już od dawna nie są tylko proste skrypty.

W dniu 2018-06-11 o 09:25, Radosław Korzeniewski pisze:

>> * C++ daje w wyniku NORMALNE programy (bez konieczności łączenia programu z maszynami wirtualnymi, interpreterami, jakichś zwyrodniałych kompilacji do kodu bajtowego i innych wynalazków w stylu Jit). W C++ po prostu masz plik exe czy so/dll i po prostu to działa.
> 
> Z tą dokładnością, że ten plik exe czy so/dll działa tylko dla systemu i architektury dla której został przygotowany i nie ma technicznych możliwości poza emulacją (czyli jakieś maszyny wirtualne, interpretatory czy JIT) aby uruchomić go na czymś innym. Tej wady nie mają języki które korzystają z wspomnianych wyżej maszyn wirtualnych, interpretatorów byte-kodu czy JIT. Generalnie coś za coś.

tu sam sobie zaprzeczasz, z jednej strony ganisz emulację, a w drugiej 
wychwalasz. Czyli emulacja realnej maszyny jest be, emulacja maszyny 
wymyślonej jest ok... Czy to trochę nie karkołomne?

-- 
http://zrzeda.pl

W dniu poniedziałek, 11 czerwca 2018 09:36:56 UTC+2 użytkownik Tomasz Kaczanowski napisał:
> W dniu 2018-06-11 o 09:25, Radosław Korzeniewski pisze:
> 
> >> * C++ daje w wyniku NORMALNE programy (bez konieczności łączenia programu z maszynami wirtualnymi, interpreterami, jakichś zwyrodniałych kompilacji do kodu bajtowego i innych wynalazków w stylu Jit). W C++ po prostu masz plik exe czy so/dll i po prostu to działa.
> > 
> > Z tą dokładnością, że ten plik exe czy so/dll działa tylko dla systemu i architektury dla której został przygotowany i nie ma technicznych możliwości poza emulacją (czyli jakieś maszyny wirtualne, interpretatory czy JIT) aby uruchomić go na czymś innym. Tej wady nie mają języki które korzystają z wspomnianych wyżej maszyn wirtualnych, interpretatorów byte-kodu czy JIT. Generalnie coś za coś.
> 
> tu sam sobie zaprzeczasz, z jednej strony ganisz emulację, a w drugiej 
> wychwalasz. 

Ani nie ganię emulacji, ani nie zachwalam. Każde z nich ma swoje zalety i wady.
 
> Czyli emulacja realnej maszyny jest be, emulacja maszyny 
> wymyślonej jest ok... Czy to trochę nie karkołomne?

Świat nie jest czarno/biały (bo że jest zerojedynkowy to wszyscy wiemy :)). Tak jak pokazałem powyżej, można nie lubić interpretacji wykonywanego kodu i wszystko kompilować, ale interpretacja skompilowanego kodu i tak zachodzi we współczesnych procesorach, ale kod skompilowany ma teoretycznie szansę na najszybszą pracę na takim procesorze o czym powyżej pisał szyk...

Przeciwny jestem takiemu porównywaniu języków programowania, a szczególnie C/C++ z pozostałymi wysoko-poziomowymi, a do tego dodawanie Assemblera do porównania. To są całkowicie różne bieguny. Owszem, każdy z nich jest ogólnego przeznaczenia, więc w każdym da się osiągnąć to samo, ale w jednym efektywniej a w innym mniej.

On 2018-06-11 06:38, szykcech@gmail.com wrote:
>> PS: ...a najlepiej porzuć zgrzybiałego staruszka z dwoma krzyżykami
>>        na karku np. na rzecz Pythona :)
> 
> Tak się jakoś składa, że:
> * C++ to język obiektowy o największych możliwościach (nie tylko w śród języków kompilowanych
>, ale w ogóle wszystkich jakie powstały)
Walnij chopcze baranka w najbliższy mur (byle twardy...)

> * języki typu Python nadają się jedynie do pisania jakichś małych skryptów do automatyzacji
> przetwarzania tekstów.

...popraw w pierwszy napotkany słup...

AK

On 2018-06-11 09:25, Radosław Korzeniewski wrote:
>> Tak się jakoś składa, że:
>> * ogromne możliwości C++ nie wpływają negatywnie na szybkość działania, bo jezyk jest w całości zaprojektowany przede wszystkim pod kątem szybkości.
> 
> Raczej chodziło o implementację OOP w języku tak niskopoziomowym jak C: https://www.youtube.com/watch?v=JBjjnqG0BP8
> Czyli połączenie dwóch światów: niskopoziomowego C z abstrakcjonizmem znanym z Simula.

Szacunek i brawo - zwlaszcza za wymienienie Simuli (mialem szczescie
w niej nieco pisac...).

AK

On 2018-06-11 09:56, Radosław Korzeniewski wrote:

> Ani nie ganię emulacji, ani nie zachwalam. Każde z nich ma swoje zalety i wady.

.. zwlaszcza, ze procesor tez przeciez emuluje rozkazy (microkod itd/itp).

AK

> .. zwlaszcza, ze procesor tez przeciez emuluje rozkazy (microkod itd/itp).

Zdrowo myślący programista przyjmuje, że instrukcje Asemblerowe to najniższy poziom. Bo tworzenie procesorów to inny poziom - poziom elektronika. I nie ma na to wpływu to, że jakiś programista po polibudzie dorwie się do FPGA - to i tak poziom elektronika.

I daruj sobie szczeniackie uwagi typu "Łoo! Walnij się w mór albo w słupek!". Jak nie kumasz, że C++ po prostu rządzi i jest obecnie topową technologią to masz problem z głową albo z lenistwem które nie pozwala Ci przeanalizować technologi informatycznych. Nie widzisz różnicy między kodem natywnym a kompilowanym?!? To może pogadaj z psychologiem. Jak sądzisz, że jakieś Lispy, Ady, Smaltalki czy Simule były lepsze - to czemu nikt w nich nie robi?!? Tylko C++ jest wszędzie?!? Bo wielcy ludzie myślą podobnie! C++ jest piękny, nowoczesny, potężny i szybki. Z mojego punktu widzenia ma tylko jedną wadę: Brak standardowego Abi. Ale OIMW już nad tym pracują.

W dniu poniedziałek, 11 czerwca 2018 19:03:38 UTC+2 użytkownik szyk...@gmail.com napisał:
> > .. zwlaszcza, ze procesor tez przeciez emuluje rozkazy (microkod itd/itp).
> 
> Zdrowo myślący programista przyjmuje, że instrukcje Asemblerowe to najniższy poziom.

Bo niżej nie jest mu publicznie dozwolone, działa w klatce ograniczonej przez ISA. Ale i tak ma lepiej, bo jakby chciał programować GPU to nawet Assemblera by nie dostał.

> Bo tworzenie procesorów to inny poziom - poziom elektronika.

Poniżej Assemblera w nowoczesnych procesorach jest jeszcze kilka warstw i one jak najbardziej są programowalne (i co jakiś czas muszą być łatane, bo odkrywane są w nich luki).

radoslaw@korzeniewski.net <radoslaw@korzeniewski.net> wrote:
> Witam,
>
> Mam klasę bazową A:
> class A {
>   bool send() { return send(0); };
>   virtual bool send(int flags);
> }
> oraz klasę pochodną B:
> class B: public A {
>   bool send(int flags);
> }
> chciałbym teraz móc skorzystać z B.send() ale kompilator wywala:
> error: no matching function for call to ‘B::send()’
>   b.send();
>              ^
> note: candidate: virtual bool B::send(int)
> obejście w postaci zdefiniowania B::send() jakoś mi nie pasuje. Przyjmę wszelaką krytykę i pomoc, także query do google.

Rozdziel interfejs od implementacji. 

class A
{
  // prywatna wirtualna implementacja
  virtual bool send_impl(int flags);
  public:
  // publiczny interfejs
  bool send() { return send_impl(0); };
};

bool A::send_impl(int flags)
{
  return flags == 0;
}

class B: public A
{
  bool send_impl(int flags);
};

bool B::send_impl(int flags)
{
  return flags == 1;
}

int main()
{
  A a;
  B b;

  std::cout << a.send() << std::endl;
  std::cout << b.send() << std::endl;

  A * ptr = &a;
  std::cout << ptr->send() << std::endl;
  ptr = &b;
  std::cout << ptr->send() << std::endl;
}

Google(private virtual function c++)

B.

W dniu piątek, 22 czerwca 2018 16:41:07 UTC+2 użytkownik Bartłomiej Golenko napisał:
> rpk wrote:
> > Witam,
> >
> > Mam klasę bazową A:
> > class A {
> >   bool send() { return send(0); };
> >   virtual bool send(int flags);
> > }
> > oraz klasę pochodną B:
> > class B: public A {
> >   bool send(int flags);
> > }
> > chciałbym teraz móc skorzystać z B.send() ale kompilator wywala:
> > error: no matching function for call to ‘B::send()’
> >   b.send();
> >              ^
> > note: candidate: virtual bool B::send(int)
> > obejście w postaci zdefiniowania B::send() jakoś mi nie pasuje. Przyjmę wszelaką krytykę i pomoc, także query do google.
> 
> Rozdziel interfejs od implementacji. 
> 
To w sumie dobry pomysł (który znam, pamiętam i stosuję, ale w tym przypadku jakaś zaćma).

Dzięki.
R.

On 2018-06-11, Radosław Korzeniewski <radoslaw@korzeniewski.net> wrote:
> W dniu niedziela, 10 czerwca 2018 22:18:21 UTC+2 użytkownik AK napisał:
>> > Ale uważam, że to najmniej eleganckie rozwiązanie. 
>> 
>> Nie tyle nieelegackie, ale po prostu błędne.
>
> To jakie "obejście problemu" nie było by błędne?

class B : public A {
    using A::send;
...
};