Aktywne Wpisy

Kempes +540
#katolicyzm #bekazkatoli #heheszki #polska
Ale już napie... dzwonami od samego rana to temu wyznawcy dziadziusia w niebie nie przeszkadza XD
Ale już napie... dzwonami od samego rana to temu wyznawcy dziadziusia w niebie nie przeszkadza XD
źródło: temp_file2481202444147821461
Pobierz





1. Nauczcie się porządnie C razem z jego arytmetyką wskaźników. To jest proste. C jest bardzo prostym językiem.
2. Nauczcie się wybranych elementów C++: klasy (niekoniecznie dziedziczenie i przeciążanie operatorów), referencje, namespace'y, wątki i ich bezpieczeństwo, model pamięci.
3. Opanujcie wzorzec RAII i smart pointery
4. Nieobowiązkowo wyjątki - można żyć bez nich,
5. Podstawowe informacje o szablonach.
5. Cmake + jakiś framework do testów (może być Google Test)
Dodatkowo (niezależnie od C++):
6. Wzorce projektowe, algorytmy i struktury danych.
7. Nie stosujcie programowania obiektowego wtedy, gdy nie jest to uzasadnione. Czasem wystarczy zwykłe proceduralne. To, czy programowanie obiektowe jest uzasadnione, czy nie jest, niezwykle trudno stwierdzić. Najlepiej zatem: nie programujcie obiektowo! :)
8. Kod imperatywny zazwyczaj jest łatwiejszy do zrozumienia od deklaratywnego. Tu można się spierać.
9. Piszcie prosty, bezpieczny, wielowątkowy kod, który jest utrzymywalny i zrozumiały przez 70% programistów (nie tylko C++). Nie, Rust, to nie o Tobie :)
10. Profit.
#programowanie #programista15k #cpp #c++ #rust
j---ć falubaz
@gacek_w: xDD
@zwei: Da się, ale z drugiej strony są lepsze języki do wielowątkowości jeżeli chcemy prosty, bezpieczny i wielowątkowy kod. C / C++ raczej służą optymalizacji, szybkości wykonania, a wtedy albo nie jest prosto, albo nie do końca bezpiecznie.
@gacek_w: a to mi wyjaśnisz? Przecież na obiektach najprościej i najczytelniej nawet proste skrypty
@gacek_w: kod deklaratywny jest prostszy do analizy z definicji. W kodzie deklaratywnym nie masz kolejności wykonywania instrukcji i zrozumienie przepływu kodu polega na ciągłym przeglądaniu zależności, gdzie w paradygmacie imperatywnym masz to samo plus złożoność wynikacjąca z kolejności
@MilionoweMultikonto: Zła struktura kodu jest o wiele gorsza od braku struktury. Niezwykle trudno jest zaprojektować dobrą strukturę obiektów dla nietrywialnego problemu. Zazwyczaj kończy się to smutną, niepotrzebnie pokomplikowaną kulą błota. Mówię o dużych projektach, przy których pracuje wielu programistów.
Oczywiście jeśli pracujesz sam nad jakimś małym projektem, to może Ci się to udać. Ale i tak wymaga
Jeśli to nie bait to się nie znasz
@pwone: To nie bait. Przeczytaj moją odpowiedź wyżej.
@lycaon_pictus: Szczerze współczuję, serio. Ja 12 lat pisałem crudy w Javie. Co ciekawe jak się inteligentnych ludzi zmusza do takich rzeczy, to później powstają: fabryki fabryk abstrakcyjnych, deklaratywne, reaktywne streamy z map-reduce dla danych ze źródeł nierelacyjnych, itp. itd. A to wszystko dla problemów, które nie są bardziej skomplikowane od tych, które dzieci rozwiązują na lekcjach informatyki w szkole. Bez urazy, ofc.
@gacek_w: proponujesz podejście "yolo i do przodu" dla dużych projektów, dla których ciężko jest nawet stworzyć strukturę obiektową? Moim zdaniem to albo jesteś trolem, albo głupkiem, albo c---a się znasz.
@j557: Nie. Proponuję co najmniej 2x zastanowić się nad wyborem paradygmatu programowania. Tylko tyle. Na siłę wpychanie programowania obiektowego tam, gdzie lepiej sprawdzi się proceduralne nie ma sensu. To nie tylko moje zdanie.
A to, że większość wielkich projektów obiektowych kończy się big ball of mud, to niestety przykry fakt.
@gacek_w: to jest dopiero świetny przepis na wielką kulę błota, i to od samego początku ( ͡° ͜ʖ ͡°)
@boryspo: Zwróć uwagę na wytłuszczony fragment mojego wpisu. Nie widzę tu przepisu na kulę błota. :)
Często bardzo trudno