Praca w C++? czemu programiści nie lubią C++?

Odpowiedz Nowy wątek
Złoty Pomidor
2018-05-26 12:30
Złoty Pomidor
0

Wielu twierdzi, że C++ jest trudne do ogarnięcia, ale moim zdaniem C++ jest bardzo podobne do Java i C#. Chyba jedyną trudnością tego języka jest nauczenie się wskaźników i zarządzania pamięcią... więc dlaczego programiści żywią niechęć wobec tego języka?

IDE do C++ są już coraz lepsze.

praca w C++, a praca w webie? ktoś ma doświadczenie na obu polach i podzieli się swoimi doświadczeniami? jakie są specyficzne różnice?

Pozostało 580 znaków

2018-05-26 12:40

Rejestracja: 15 lat temu

Ostatnio: 16 minut temu

6

Chyba jedyną trudnością tego języka jest nauczenie się wskaźników i zarządzania pamięcią

Nauczenie się wskaźników to względnie prosta sprawa, ale bolesne jest kopanie się z losowymi segfaultami i dziwacznym zachowaniem programu, gdy pomylisz się w obsłudze wskaźników. Po co tracić życie na coś takiego zamiast implementować jakiś fajny ficzer? Nie każdy odczuwa przyjemność z obcowania ze wskaźnikami.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

Chory Szczur
2018-05-26 13:30
Chory Szczur
0

C++ nie jest trudne do ogarnięcia, ale po prostu tracisz dużo więcej czasu na rzeczy, które w innych językach zrobisz szybciej i prawdopodobnie lepiej, bo ktoś bardziej doświadczony dał Ci "podstawę".

Pozostało 580 znaków

2018-05-26 13:50

Rejestracja: 3 lata temu

Ostatnio: 7 godzin temu

7

Chyba jedyną trudnością tego języka jest nauczenie się wskaźników i zarządzania pamięcią...

Mało jeszcze wiesz... :P

Pozostało 580 znaków

Lucek
2018-05-26 18:53
Lucek
1
Złoty Pomidor napisał(a):

Wielu twierdzi, że C++ jest trudne do ogarnięcia, ale moim zdaniem C++ jest bardzo podobne do Java i C#. Chyba jedyną trudnością tego języka jest nauczenie się wskaźników i zarządzania pamięcią... więc dlaczego programiści żywią niechęć wobec tego języka?

Po 8 latach w cpp przesiadek się na c#
Już nie muszę martwić się reference collapising
Kiedy jest Universal ref a kiedy r value

Itp itd

Żeby zarabiać w cpp tyle co w c#, js, java trzeba parę razy więcej wiedzieć

A jak się nie musi to po jakiego grzyba się męczyć

Pozostało 580 znaków

2018-05-26 19:02

Rejestracja: 3 lata temu

Ostatnio: 11 godzin temu

0

Bo większość ludzi zna starego C++ z musem pisania wskaźników, new i innych dziwactw. Kontenery, smart pointery, auto, czy inicjalizacja klamrowa wiele ułatwiają ;)

Pozostało 580 znaków

2018-05-26 19:15

Rejestracja: 15 lat temu

Ostatnio: 16 minut temu

0

Bo większość ludzi zna starego C++ z musem pisania wskaźników, new i innych dziwactw. Kontenery, smart pointery, auto, czy inicjalizacja klamrowa wiele ułatwiają ;)

Tyle, że jak nawstawiasz wszelkie bajery (sprytne wskaźniki, metody wirtualne, sprawdzanie indeksów tablic, sprawdzanie nullptr przy każdym korzystaniu z wskaźników itp itd) zbliżające C++ np do Javy to zostaniesz z czymś wolniejszym od Javy, więc jaki w tym sens? Sprytne wskaźniki są natomiast ułomne (i to każdy rodzaj sprytnych wskaźników) z bardzo prostego powodu - nie radzą sobie z cyklicznymi referencjami i nie nadają się do współdzielenia stanu (obojętne czy mutowalnego czy nie) między wątkami (bo albo są oparte o kosztowne operacje atomowe albo psują się przy korzystaniu z wielu wątków jednocześnie). Odśmiecanie pamięci (w sensie tracing GC) jest znacznie wygodniejsze i kompletne.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Pokaż pozostałe 34 komentarze
Jak weak_ptr wpływa na determinizm? I tak musisz mieć gdzieś shared_ptr który zarządza cyklem życia. - Wibowit 2018-05-27 13:46
..i wiesz kiedy zwolnisz i jak i czy. A GC zrobi kiedy chce i ... może tak a może nie lub przesunie do "później";) Poza tym smart-ptr mają trochę więcej metod niż wynika z RAII... zresztą.. tytuł wątku może zawierać słowo Java i także okaże się że można jej nie lubić;) - Mokrowski 2018-05-27 14:13
A GC zrobi kiedy chce i ... może tak a może nie lub przesunie do "później";) - no, nigdzie nie twierdziłem, że GC ma same zalety - Wibowit 2018-05-27 14:15
zresztą.. tytuł wątku może zawierać słowo Java - albo .NET, bo porównanie jest tracing GC vs sprytne wskaźniki, a nie C++ vs Java - Wibowit 2018-05-27 14:16
Na chwilę poczułem się jak w latach 90-tych... Dzięki chłopaki :) - vpiotr 2018-05-27 21:35

Pozostało 580 znaków

2018-05-26 19:18

Rejestracja: 3 lata temu

Ostatnio: 11 godzin temu

0

A to w języku trzeba pisać tylko dlatego, że jest szybszy niż inny? Gdyby tak było nie wychodziłbym poza C. :)

Ponadto, prosiłbym o jakieś dane potwierdzające tezę o tym, że smart pointery czy .at() przy std::array spowalnia program, bo mam inne informacje. 

Pokaż pozostałe 6 komentarzy
Czemu rzadko korzystacie z .at? - Wibowit 2018-05-27 10:49
Bo nie ma potrzeby sprawdzać przy każdym dostępie, czy indeks mieści się w zakresie. - _0x666_ 2018-05-27 10:56
Potrzeba wynika z bardzo prostego powodu - każdy może pomylić się w ocenie, kiedy trzeba sprawdzać indeks :] Kompilator powinien być na tyle sprytny, by wyciąć ifa z .at w większości przypadków. JVM przynajmniej jest na tyle sprytny, a w Javce sprawdzanie indeksów jest zawsze włączone (w każdej instrukcji dostępu przez indeks). - Wibowit 2018-05-27 11:00
No widocznie nie każdy, jeśli rzadko stosuje się at :P Co do kompilatora, te C++'owe też są sprytne i potrafią różne sztuczki. Tak na szybko sprawdziłem dostęp z at w pętli i nie widzę ani wywołania metody, co oczywiste, ani kodu odpowiedzialnego za sprawdzenie zakresu. - _0x666_ 2018-05-27 11:30
Testy na szybko prowadzą zwykle do błędnych wniosków, bo proste pętle są wygodne dla kompilatora. Wiele optymalizacji działa bezbłędnie na prostych pętlach, a przy skomplikowanym kodzie się wywalają (tzn nie dają oczekiwanych wzrostów wydajności). - Wibowit 2018-05-27 11:42

Pozostało 580 znaków

2018-05-26 19:33

Rejestracja: 6 lat temu

Ostatnio: 1 godzina temu

Lokalizacja: Warszawa

1

Z Javy korzysta się zamiast z C w aplikacjach biznesowych bo łatwo ją przenieść (JVM ) i kod jest czytelniejszy.C++ z typi pierdołami typu smart pointery itd. jest mniej czytelny od Javy i wolniejszy od niej (wedlug tego co napisał @Wibowit). Ma więc wady C i wady Javy, zalet nie widze


"w haśle <młody dynamiczny zespół> nie chodzi o to ile masz lat tylko jak często zmienia się skład"

Pozostało 580 znaków

2018-05-26 20:16

Rejestracja: 15 lat temu

Ostatnio: 16 minut temu

3

Ponadto, prosiłbym o jakieś dane potwierdzające tezę o tym, że smart pointery czy .at() przy std::array spowalnia program, bo mam inne informacje.

W prostych benchmarkach różnic pewnie dużych nie będzie, bo proste przypadki się prosto optymalizuje. Trzeba by było wziąć jakiś większy algorytm i dorobić wszędzie te rzeczy o których pisałem (sprytne wskaźniki, sprawdzanie nullptr przy każdym wykorzystaniu wskaźnika, sprawdzanie indeksów tablic, itp itd). Zrobiłem jednak prosty benchmark symulujący pointer chasing:

#include <array>
#include <vector>
#include <cstdlib>
#include <chrono>  // for high_resolution_clock
#include <inttypes.h>

int main(int argc, char** argv) {
    std::array<int32_t, 100> tablica;
    for (int32_t i = 0; i < 100; i++) {
        tablica[i] = (i * 34373 + 43) % 100;
    }
    int64_t iterations = 1000000000;

    int64_t op_sum = 0;
    int64_t op_index = 0;
    auto op_start = std::chrono::high_resolution_clock::now();
    for (int64_t i = 0; i < iterations; i++) {
        op_sum += tablica[tablica[tablica[tablica[op_index]]]];
        op_index = i % 100;
    }
    auto op_finish = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double> op_elapsed = op_finish - op_start;

    int64_t at_sum = 0;
    int64_t at_index = 0;
    auto at_start = std::chrono::high_resolution_clock::now();
    for (int64_t i = 0; i < iterations; i++) {
        at_sum += tablica.at(tablica.at(tablica.at(tablica.at(at_index))));
        at_index = i % 100;
    }
    auto at_finish = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double> at_elapsed = at_finish - at_start;

    printf("%" PRId64 ", %lf\n", op_sum, op_elapsed.count());
    printf("%" PRId64 ", %lf\n", at_sum, at_elapsed.count());
    return EXIT_SUCCESS;
}

Wyniki:

49500000041, 1.517305
49500000041, 1.774159

To jest nadal bardzo prosty kod i niespecjalnie wykorzystuje możliwości procesora w zakresie (spekulatywnego) wykonywania kodu poza kolejnością. Na jakimś słabym procku pewnie różnice byłyby znacznie większe.

Sprawdzanie indeksów tablic czy nullptrów można zoptymalizować zarówno podczas kompilacji AOT jak i JIT. Zarówno kompilatory C++ jak i JVM to robią i dla prostych benchmarków nie ma dużej różnicy wydajnościowej między C++, a Javą. Gdy optymalizatory wysiadają zwiększa się spadek wydajności spowodowany tymi bajerami typu sprawdzanie indeksów tablic czy nullptrów.

Poza tym, gdyby sprawdzanie indeksów tablic i nullptrów było całkowicie darmowe w C++ to wtedy zupełnym nieporozumieniem byłoby utrudnianie korzystania z tego. Korzystanie z operatora [] jest wygodniejsze niż z metody .at, więc ludzie korzystają z [] narażając się na irytujące problemy czy wręcz niebezpieczeństwa. Sprytne wskaźniki to ceremonia w porównaniu np do jednego rodzaju referencji jak to jest w większości popularnych języków (Java, C#, JS, PHP, Python, etc). Sam kompilator C++ nie wymusza też reguł stosowania sprytnych wskaźników. Robi to natomiast kompilator Rusta, więc Rust ma tutaj przewagę nad C++em (jedną z wielu).


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 8x, ostatnio: Wibowit, 2018-05-26 20:56

Pozostało 580 znaków

2018-05-26 21:10

Rejestracja: 4 lata temu

Ostatnio: 10 minut temu

0
     *
    ***
   *****
  *******
 *********
***********
*(**(*wtf))
edytowany 16x, ostatnio: WeiXiao, 2018-05-26 21:29

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0