Wpis z mikrobloga

@Saly: sharedptr to nie zło. Po prostu używanie do wszystkiego, bo działa, jest złe. Powinno się używać tylko i wyłącznie w przypadku kiedy faktycznie współdzieli się pewien zasób, a nie dla każdej lepszepej asocjacji.

Ale jak to bywa, błędy się zdarzają a borrow checkera się tu nie zaimplementuje ( ͡° ͜ʖ ͡°)-

Poza tym samo sprawdzenie poprawności programu poprzez zliczanie
  • Odpowiedz
Powinno się używać tylko i wyłącznie w przypadku kiedy faktycznie współdzieli się pewien zasób, a nie dla każdej lepszepej asocjacji.


@lionbest: niby tak. Z drugiej strony przy płynącym czasie i bardzo złożonej bazie kodowej prawdopodobieństwo współdzielenia zasobu rośnie szybko do 1.

Tak czy owak mój wywód dotyczy wydajności a nie designu
  • Odpowiedz
@Saly: Kiedy artykuł jest właśnie o poświęceniu wydajności na rzecz pozbycia się UB, które mogą okazać się exploitami.

Costs: Performance (TBD; as of August 2021 we are actively quantifying the impact of several implementations).


Jak ktoś chce mieć szybkie i bezpieczne wskaźniki, to niech w ogóle się pozbędzie wskaźników, na rzecz "object pool" i indeksowania.

Generalnie dla mnie C++ może umrzeć, więc niech żyje C++ (
  • Odpowiedz
@lionbest: cpp tak umiera już od 20 lat ( ͡° ͜ʖ ͡°) i dalej jest krulem. jedynie rust mógłby przejąć koronę, ale nie wiem czy to nastąpi w tym dziesięcioleciu
  • Odpowiedz
jedynie rust mógłby przejąć koronę, ale nie wiem czy to nastąpi w tym dziesięcioleciu


@314159: nie jestem pewien czy Rust ma taki poziom abstrakcji jak C++.

Jest jeszcze Carbon - ale ten tworzony jest przez google więc raczej nikt poważny nie zainteresuje się tym bo ludzie wiedza jak google uwielbiam porzucać/psuć orpjekty.
  • Odpowiedz
@sorek: carbon nigdy nie miał być zamiennikiem cpp. nawet na stronie projektu jest informacja, że jak możesz użyć czegoś innego, to nie używaj carbona
  • Odpowiedz
@sorek: No właśnie ciężko powiedzieć. Traity są bardziej ogólnym i elastyczniejszym mechanizmem niż klasy. Natomiast Rustowi brakuje ujednoliconego meta programowania i tu się z Stroustrupem, że makra są evil.
  • Odpowiedz
@lionbest: z drugiej strony masa projektów jest napisana w C i jakoś to działa. Metaprogramowanie to fajny dodatek ale da się bez niego żyć. Zwłaszcza w podejściu Rustowym, które w większości przypadków jest dużo lepsze (fajny system traitów, generowanie kodu poprzez strukturalne makra)
  • Odpowiedz
Jak ktoś chce mieć szybkie i bezpieczne wskaźniki, to niech w ogóle się pozbędzie wskaźników, na rzecz "object pool" i indeksowania.


@lionbest: clue artykułu jest takie, że większość problemów bierze się stąd, że developer B ma nieodpowiednią wiedzę o kodzie napisanym przez developera A. Object pool brzmi dobrze przy prostych zastosowaniach, jak cykl życia obiektów się skomplikuje to pewnie jest jeszcze większy burdel (albo ogromne zużycie pamięci) niż w przypadku
  • Odpowiedz
@Saly: Co do Rusta to generalnie masz racje, w skomplikowanych zastosowaniach często DSL jest lepszym podejściem. Szczególnie odpalanie makr na poziomie Cargo, które faktycznie są Rust kodem i można generować i skanować co się chce.
Co do bibliotek w C sporo jest przepisywanych na Rusta, albo przynajmniej istnieją wrapery.

@Saly: Również się zgadzam z clue artykułu a oznaczanie co ze wskaźnikiem można robić, poprzez opakowanie go w magiczny pointer uważam za słuszne podejście. A potem plugin do statycznego sanitizera clanga i cyk już wiadomo, gdzie się ma bugi.
Tylko to w cholerę roboty, która powinna być już gotowa na poziomie jakieś biblioteki, a jak wiadomo w C++ mamy ryż
  • Odpowiedz
Co do bibliotek w C sporo jest przepisywanych na Rusta, albo przynajmniej istnieją wrapery.


@lionbest: bardziej chodziło mi o to, że w community C++ często widzę taką opinię, że C++ jest mesjaszem języków, bo ma metaprogramowanie. Gdzie to metaprogramowanie jest naprawdę biedne (C++ jest chyba jedynym językiem w TOP 10, który nie pozwala na automatyczne/półautomatyczne parsowanie jsona do struktury, naprawdę potężny język), przekomplikowane (#!$%@? templaty, sfinae, nieczytelny kod) i da
  • Odpowiedz