Temat: Wirtualny destruktor

Przemysław O.:

Marcin Er:
No ale to twoja filozofia i masz do niej prawo
ja bym się nie odważył tak pisać obiektowego kodu
Po za tym "minimalizm" w C++ to kwestia na osobną książkę :)
wydaje mi się że całkowicie kłóci się on ze standardami jaki proponują ludzie opracowujący ten język
Oczywiście krążą takie mity że jest on równie wydajny a nawet bardziej wydajny od swojego protoplasty C i kilku innych języków z których się wywodzi
- może i tak ale na pewno nie gdy sztywno trzymamy się narzucanych standardów
Więc podejście "nie płace za coś ..." ma się nijak do czystego C++

To nie moja filozofia tylko filozofia autorow jezyka. Gdyby filozifia byla inna to wszystko byloby virtual jak w Javie i nie byloby zadnych problemow. W C++ jest wybor, chcesz to uzywasz, nie to nie. Jesli jest to za trudne dla kogos to sa prostrze jezyki bez tych "problemow". Nie trzeba zawsze pisac virtual ~foo() {}; Maja to wbudowane!

PS. O moje bugi sie nie martw. Rozmawiajmy na temat.

Wydaje mi się że każdy autor języka ma taką "wygodną" filozofie
ale nie wiem czy dobrze jest gdy mają ją programiści
- Hej twój program zjadł mi połowę pamięci i zawiesił system w 15 minut
- nie chcesz nie używaj :D
Awans w dziale marketingu i piaru murowany
bo to taki językowy bonusMarcin Er edytował(a) ten post dnia 03.09.10 o godzinie 19:02

Temat: Wirtualny destruktor

Marcin Er:
Wydaje mi się że każdy autor języka ma taką "wygodną" filozofie
ale nie wiem czy dobrze jest gdy mają ją programiści
- Hej twój program zjadł mi połowę pamięci i zawiesił system w 15 minut
- nie chcesz nie używaj :D
Awans w dziale marketingu i piaru murowany
bo to taki językowy bonus

Jeśli filozofia programistów pokrywa się z filozofią twórców języka to tym lepiej bo wiadomo "co autor miał na myśli" i można uniknąć zrobienia sobie kuku.
Niepłacenie za coś czego się nie używa jest bardzo dobrym rozwiązaniem.
Idąc Twoim tokiem to można zapytać dlaczego w C++ nie domyślnego i obowiązkowego garbage collectora ? M.in. z tego samego powodu. A przecież argumenty "za" są bardzo istotne: wycieki zasobów.
Pilnując się paru reguł, które tu były wspomniane możesz ustrzec się problemów z tytułu braku wirtualnego destruktora.

Temat: Wirtualny destruktor

Michał Rotkiewicz:

Marcin Er:
Wydaje mi się że każdy autor języka ma taką "wygodną" filozofie
ale nie wiem czy dobrze jest gdy mają ją programiści
- Hej twój program zjadł mi połowę pamięci i zawiesił system w 15 minut
- nie chcesz nie używaj :D
Awans w dziale marketingu i piaru murowany
bo to taki językowy bonus

Jeśli filozofia programistów pokrywa się z filozofią twórców języka to tym lepiej bo wiadomo "co autor miał na myśli" i można uniknąć zrobienia sobie kuku.
Niepłacenie za coś czego się nie używa jest bardzo dobrym rozwiązaniem.
Idąc Twoim tokiem to można zapytać dlaczego w C++ nie domyślnego i obowiązkowego garbage collectora ? M.in. z tego samego powodu. A przecież argumenty "za" są bardzo istotne: wycieki zasobów.
Pilnując się paru reguł, które tu były wspomniane możesz ustrzec się problemów z tytułu braku wirtualnego destruktora.

Gdyby filozofia programistów pokrywała się z filozofią twórców języka co do joty to nie martwił byś się narzutami związanymi z kolejnym adresem w v table
bo programy w c++ były by jednym wielkim narzutem
Filozofia twórców cepa jest w wielu punktach po prostu dogmatyczna i głupia
Nie chcesz używać tego cholernego vkonstruktora nie używaj
ale nie przekonuj ludzi do tego że to dobra praktyka bo tak nie jest
Mogę się założyć że jeśli przejrzysz klasy standardowej biblioteki c++
to w 99% przypadków spotkasz wirtualny destruktor
Sądzisz że ich autorzy nie wiedzieli czegoś co wiesz ty ?
Ok typy konkretne są fajne i czasami bardzo przydatne
ale to dziedziczenie i poly są jednymi z elementarnych elementów języków obiektowych i to właśnie mając je na uwadze powinno się projektować klasy
w innym przypadku to ma nie wiele wspólnego z OOP
i sens tworzenia takich klas jest bardzo dyskusyjny
Bo oprócz tego że ułatwiają życie programiście (ale głównie temu który je tworzy jeśli nie tylko jemu) porządkując kod
tworzą tylko i wyłącznie nie potrzebny narzut , którego wszyscy się tak bardzo obawiają jak bym co najmniej mieli 200 mb ramu i dysk twardy 4 GB :D

Generalnie osobiście mam mieszane uczucia w stosunku do OOP w ogóle
a zestawianie go z wydajnością trącało mi zawsze schizofrenią
no ale oczywiście trzeba się dostosowywać do panujących trendów i mądrości tłumów :)Marcin Er edytował(a) ten post dnia 03.09.10 o godzinie 19:54

Temat: Wirtualny destruktor

Marcin Er:
Gdyby filozofia programistów pokrywała się z filozofią twórców języka co do joty to nie martwił byś się narzutami związanymi z kolejnym adresem w v table
bo programy w c++ były by jednym wielkim narzutem
Filozofia twórców cepa jest w wielu punktach po prostu dogmatyczna i głupia
Nie chcesz używać tego cholernego vkonstruktora nie używaj
ale nie przekonuj ludzi do tego że to dobra praktyka bo tak nie jest
Mogę się założyć że jeśli przejrzysz klasy standardowej biblioteki c++
to w 99% przypadków spotkasz wirtualny destruktor
Sądzisz że ich autorzy nie wiedzieli czegoś co wiesz ty ?

No to poleciales po bandzie! Otworz sobie naglowek vector-a i znajdz mi tam jakis virtual, m'okey? To jedna z przyczyn problemu(a w zasadzie jego braku). C++ wspiera nie tylko OOP ale tez np metaprogramowanie. Po co tam polimofizm dynamiczny? Nie potrzebny bo mozna miec polimorfizm statyczny!

Temat: Wirtualny destruktor

Marcin Er:
Nie chcesz używać tego cholernego vkonstruktora nie używaj
ale nie przekonuj ludzi do tego że to dobra praktyka bo tak nie jest.

Jeśli domyślnie byłby virtual to jak ma go nie używać ?
Chcesz wprawdzić dodatkową składnię aby kompilator wiedział, że nie chcę wirtualnego ?

Marcin Er:
Mogę się założyć że jeśli przejrzysz klasy standardowej biblioteki c++
to w 99% przypadków spotkasz wirtualny destruktor

Przyjmuję zakład :D

Marcin Er:
Ok typy konkretne są fajne i czasami bardzo przydatne
ale to dziedziczenie i poly są jednymi z elementarnych elementów języków obiektowych i to właśnie mając je na uwadze powinno się projektować klasy

Ale w czym problem ? Chcesz mieć virtualny dtor to go robisz virtualnym.
Jak zapomnisz to twój błąd. Tak samo jak setki innych jakie możesz popełnić.

Marcin Er:> tworzą tylko i wyłącznie nie potrzebny narzut , którego wszyscy się tak bardzo obawiają jak bym co najmniej mieli 200 mb ramu i dysk twardy 4 GB :D

W wielu aplikacjach tworzysz miliony lub więcej obiektów i wtedy to nabiera znaczenia.

Temat: Wirtualny destruktor

Michał Rotkiewicz:

Marcin Er:
Nie chcesz używać tego cholernego vkonstruktora nie używaj
ale nie przekonuj ludzi do tego że to dobra praktyka bo tak nie jest.

Jeśli domyślnie byłby virtual to jak ma go nie używać ?
Chcesz wprawdzić dodatkową składnię aby kompilator wiedział, że nie chcę wirtualnego ?

Właściwie jest tylko jeden sensowny przypadek takiej sytuacji - kiedy nie chcesz pozwolić na dziedziczenie z danej klasy. W nowszych językach do tego służy właśnie specjalne słowo kluczowe - "final".

Tu przykład jak to samo osiągnąć w C++:

http://www.codeguru.com/cpp/cpp/cpp_mfc/stl/article.ph...

Temat: Wirtualny destruktor

Przemysław O.:

Marcin Er:
Gdyby filozofia programistów pokrywała się z filozofią twórców języka co do joty to nie martwił byś się narzutami związanymi z kolejnym adresem w v table
bo programy w c++ były by jednym wielkim narzutem
Filozofia twórców cepa jest w wielu punktach po prostu dogmatyczna i głupia
Nie chcesz używać tego cholernego vkonstruktora nie używaj
ale nie przekonuj ludzi do tego że to dobra praktyka bo tak nie jest
Mogę się założyć że jeśli przejrzysz klasy standardowej biblioteki c++
to w 99% przypadków spotkasz wirtualny destruktor
Sądzisz że ich autorzy nie wiedzieli czegoś co wiesz ty ?

No to poleciales po bandzie! Otworz sobie naglowek vector-a i znajdz mi tam jakis virtual, m'okey? To jedna z przyczyn problemu(a w zasadzie jego braku). C++ wspiera nie tylko OOP ale tez np metaprogramowanie. Po co tam polimofizm dynamiczny? Nie potrzebny bo mozna miec polimorfizm statyczny!

Tak wiem że cep jest hybrydowy ale my tu chyba nie mówimy o tym jakie paradygmaty wspiera c++ tylko o tym po co jest wirtualny destruktor
i kiedy powinno się go stosować ?
Równie dobrze można w ogóle nie pisać obiektowo
Dobra 99% to przegięcie
ale ja i tak będę się upierał że destruktory powinny być wirtualne
A co do polimorfizmu statycznego to nie sądzę aby wbrew pozorom był on dużo lepszym rozwiązaniem od polimorfizmu dynamicznego w kwestii wydajności o którą tak zabiegasz
Po za tym za v destruktorem przemawia jeden nie podważalny argument
którego najwyraźniej żaden z was nie dostrzega
bo w czasach 4 rdzeniowych procków wy nadal walczycie o zasoby
Trudno ja tam wiem że przypadku projektów z "milionem obiektów"
na dłuższą metę lepiej jednak deklarować destruktory jako wirtualne

Tak na marginesie słowo narzut jest chyba jednym z słów kluczowych języka c++ i w ogóle języków obiektowych
odkąd się z nimi zacząłem stykać w każdej książce
w każdym artykule gdzieś zazwyczaj na początku pojawia się narzut
56 słowo kluczowe c++ :)Marcin Er edytował(a) ten post dnia 04.09.10 o godzinie 01:25

Temat: Wirtualny destruktor

Marcin Er:

Po za tym za v destruktorem przemawia jeden nie podważalny argument
którego najwyraźniej żaden z was nie dostrzega
bo w czasach 4 rdzeniowych procków wy nadal walczycie o zasoby
Trudno ja tam wiem że przypadku projektów z "milionem obiektów"
na dłuższą metę lepiej jednak deklarować destruktory jako wirtualne[/edited]

Walka o zasoby to wbrew pozorom pożyteczna cecha nawet w czasach 4 rdzeniowych procków. Ja po kilku latach pracy właśnie na tego typu platformach z dużą ilością ramu wpadłem w projekty, gdzie urządzenie docelowe ma maks 4 MB Ramu + procesor 33Mhz... i zaczęły pojawiać się problemy, bo nagle każdy dodatkowy bajt wygenerowany przez wirtualne funkcje zaczął przeszkadzać :-).

To może odosobniony przypadek, nie mniej pokazuje, że problem optymalnego pisania nie jest w dzisiejszych czasach wcale taki obcy.

A... i żeby była jasność, kod muszę pisać tak, aby dało się go skompilować również na normalnym porządnym desktopie.Krzysztof Kondrak edytował(a) ten post dnia 04.09.10 o godzinie 01:47

Temat: Wirtualny destruktor

Chciałem poprawić ale mi przerwałeś
więc dodam sobie nową
Chciałem powiedzieć że właściwie to nie przegiąłem
i to że kontenery w STL nie mają virtualnych destruktorów
to błąd ich twórców
Co ja się będę tu kajał i słodził wszystkim do o koła lolMarcin Er edytował(a) ten post dnia 04.09.10 o godzinie 01:58

Temat: Wirtualny destruktor

Krzysztof Kondrak:

Marcin Er:

Po za tym za v destruktorem przemawia jeden nie podważalny argument
którego najwyraźniej żaden z was nie dostrzega
bo w czasach 4 rdzeniowych procków wy nadal walczycie o zasoby
Trudno ja tam wiem że przypadku projektów z "milionem obiektów"
na dłuższą metę lepiej jednak deklarować destruktory jako wirtualne[/edited]

Walka o zasoby to wbrew pozorom pożyteczna cecha nawet w czasach 4 rdzeniowych procków. Ja po kilku latach pracy właśnie na tego typu platformach z dużą ilością ramu wpadłem w projekty, gdzie urządzenie docelowe ma maks 4 MB Ramu + procesor 33Mhz... i zaczęły pojawiać się problemy, bo nagle każdy dodatkowy bajt wygenerowany przez wirtualne funkcje zaczął przeszkadzać :-).

To może odosobniony przypadek, nie mniej pokazuje, że problem optymalnego pisania nie jest w dzisiejszych czasach wcale taki obcy.

A... i żeby była jasność, kod muszę pisać tak, aby dało się go skompilować również na normalnym porządnym desktopie.

Jak urządzenie docelowe ma 4 mb ramu
to rzeczywiście po kilku latach pracy wybór c++ do pisania na nie softu
jest świetnym i bardzo trafionym wyborem gratsy
Żeby była jasność :)

To musiał być zegarek elektroniczny marki unitraMarcin Er edytował(a) ten post dnia 04.09.10 o godzinie 01:57

Temat: Wirtualny destruktor

Każda klasa może być klasą bazową
I to zasadniczo wszystko w tym temacieMarcin Er edytował(a) ten post dnia 04.09.10 o godzinie 02:18

Temat: Wirtualny destruktor

..:
Każda klasa może być klasą bazową

[/edited]

A jak widzisz ( albo raczej nie - tak wynika przynajmniej z chęci zakładu ;) ) twórcy STL mieli zupełnie inne zdanie w tym temacie.

Temat: Wirtualny destruktor

..:
Chciałem poprawić ale mi przerwałeś
więc dodam sobie nową
Chciałem powiedzieć że właściwie to nie przegiąłem
i to że kontenery w STL nie mają virtualnych destruktorów
to błąd ich twórców
Co ja się będę tu kajał i słodził wszystkim do o koła lolMarcin Er edytował(a) ten post dnia 04.09.10 o godzinie 01:58

Hehe, to jednak autorzy STL wiedza lepiej czy nie? :) Polimorfizm statyczny jest szybszy tak jak cale metaprogramowanie na szablonach. Wiele rzeczy dzieje sie na poziomie kompilacji(dlugo sie buduje kod) no ale potem juz smiga super :) I taka idea przyswiecala autorom STLa.

Temat: Wirtualny destruktor

Ale już po kontenerze STL się nie poszleje z dziedziczeniem :(

Temat: Wirtualny destruktor

Jakub L.:
Ale już po kontenerze STL się nie poszleje z dziedziczeniem :(

No nie ale nie jest to cos co czesto sie potrzebuje. Wiekszosc kontenerow jest typowanych alokatorami czy tez komparatorami i to styka. Jesli nie, mozna przeciez opakowac kontener we wraper.

Temat: Wirtualny destruktor

Co to jest konstruktor wirtualny? :)Adam Michalski edytował(a) ten post dnia 03.09.10 o godzinie 13:05

W poscie wyzej, to drobna pomylka ale jest taki design pattern w C++(wspomina sie o tym np tu: http://sourcemaking.com/design_patterns/factory_method).

"virtual" constructor

Prototyp to też rodzaj wirtualnego konstruktora?

Temat: Wirtualny destruktor

Jakub L.:
Ale już po kontenerze STL się nie poszleje z dziedziczeniem :(

No nie. Rodzi to mnóstwo problemów implementacyjnych.

Temat: Wirtualny destruktor

Piotr P.:

Co to jest konstruktor wirtualny? :)Adam Michalski edytował(a) ten post dnia 03.09.10 o godzinie 13:05

W poscie wyzej, to drobna pomylka ale jest taki design pattern w C++(wspomina sie o tym np tu: http://sourcemaking.com/design_patterns/factory_method).

"virtual" constructor

Prototyp to też rodzaj wirtualnego konstruktora?

wg mnie i cytowanej strony nie. ale moze to tylko kwestia terminologii.