[Saly]

Z ciekawostek odnośnie tego, że shared_ptr to zło i nie powinno się ich używać: developerzy chroma chcą obłożyć większość raw pointerów zliczaniem referncji w celu wykrywania błędów https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub
#cpp

[lionbest]

@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

[Saly]

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

[lionbest]

@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++ (✌ ﾟ ∀ ﾟ

[314159]

@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

[sorek]

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.

[314159]

@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

[sorek]

@314159:

Carbon Language:

An experimental successor to C++

https://github.com/carbon-language/carbon-lang

[lionbest]

@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.

[Saly]

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

[Saly]

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 b----l (albo ogromne zużycie pamięci) niż w przypadku

[lionbest]

@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

[Saly]

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 (p--------e templaty, sfinae, nieczytelny kod) i da