🚀 go-pugleaf

On Friday, January 31, 2020 at 7:28:45 PM UTC+1, (fir) wrote:
> W dniu piątek, 31 stycznia 2020 18:35:58 UTC+1 użytkownik M.M. napisał:
> > On Friday, January 31, 2020 at 5:43:48 PM UTC+1, (fir) wrote:
> > > W dniu piątek, 31 stycznia 2020 17:15:08 UTC+1 użytkownik M.M. napisał:
> > > > On Friday, January 31, 2020 at 4:19:57 PM UTC+1, (fir) wrote:
> > > > > W dniu piątek, 31 stycznia 2020 13:29:10 UTC+1 użytkownik john.st...@gmail.com napisał:
> > > > > > Sorki pisze z telefonu.. gdyby tak było to by znaczyło że dowolny patologiczny duren moze zrobić wlasciwie wymyslec lepszy język dodając do języka C dowolna nieważne jak głupie kupkę gowna.
> > > > > > 
> > > > > > Cpp trzeba rozliczać przez to co wnosi w stosunku do tego jakby było napisać to w C. I tak cpp jest na niesłusznie nobilitowany przez to że C jest jego czescia. Gdyby rozliczać czyste czesc cpp słone to by wyszedł prawie czysty crap. O tyle nie zupełnie totalny bo pewne drobne poprawki są trafione ale te poprawki to jednak małe elementy w morzu crapu ;( {fir}
> > > > > 
> > > > >  wyzej powinno byc "gdyby rozliczac czystą czesc c++ alone, to wyszedlby prawie czysty krap"
> > > > 
> > > > To niech kolega kontynuuje, a ja będę miał rozrywkę ;-)
> > > > 
> > > > Poważnie postawiłem pytanie (trzeci raz w tym wątku):
> > > > 
> > > > Dlaczego według rankingów aż około 5-7% programistów wybiera C, gdy 
> > > > język najbardziej popularny w danym czasie wybiera np. 12-15%. Coś nie 
> > > > tak z tymi programistami od C jeśli są tylko zalety z przejścia na C++, 
> > > > czy to jednak jakaś mądrość tłumu?
> > > > 
> > > nie rozumeim logicznego zwiazku co ma wibierenie c w 5-7 % a wybieraniem najbardziej popukarnego 12-15 % ? jaki jest zwiazek miedzy tymi dwiema 
> > > rzeczami?
> > 
> > Miałem na myśli lepszy sposób porównywania. Jeśli napiszę, że 5% osób
> > wybiera język programowania C, to osoba niezaznajomiona z tematyką, 
> > albo w pośpiechu nawet osoba zaznajomiona, może pomyśleć że 5% to 
> > bardzo mało. Jeśli podam dwie liczby, mianowicie te 5% i 15% to widać że
> > język C wybiera zaledwie 3 razy mniej programistów niż wybrało język
> > najbardziej popularny. To nadal niedoskonałe porównanie, ale i tak
> > lesze niż 5% do całkowicie nieokreślonych 95%.
> > 
> > 
> > > na pytanie "czemu ludzie wybueraja c skoro c++ jest lepszy ?" moge opdowiedziec, zalozenie ze c++ jest lepszy (jesli kolega tak mysli, nie mam sily sprawdzac co dokladnie kto powiedzial) jest kolegi zludzeniem
> > 
> > Zadając powyższe pytanie absolutnie nic nie myślę, tylko oczekuję
> > odpowiedzi: dlaczego wybierają goły C, jak mają (naprawdę lub na niby)
> > lepszy C++ zupełnie za darmo?
> > 
> >  
> > > nie mam jednak nic przeciwko pisaniu w tzw trybie c++ (sam niektore kody pisze w zdaje sie ansi C ale wiekszosc kodow kopiluje w trybie zgodnosci z jakims tam starym c++ (tez chyab z 89) tylko wylaczam wszystkie mozliwe c++ owe specyfiki itp i oczywiscie pisze wwylacznie c - a robie to ze wzgledu wlasnie na ten "const int tab_max = 10000;" bo ciezko mi zdzierzyc uzywanie emumow do tego celu..ale mimo wszystko nie nazywam mojego kodu c++em - i wolabym zeby nikt tak nie twierdzil bo moge sie naprawd wpienic ;c (bo takie wciskanie kitu na podstawie 'formalnosci' mnie strasznie wpienia szczerze mowiac)
> > 
> > Rozmawialiśmy, że szkolenie zajmuje czas, a mam go przeznaczyć na rozmowę z
> > której będzie (w porywach) niewiele nauki ;-) Po prostu pytam, dlaczego
> > wybierają (tak często) C, skoro C++ jest 'lepszy' i całkowicie za darmo?
> > 
> 
> bo nie jest lepszy? 

Ale pod jakim względem lepszy?

W C muszę:
1) Użyć programu zewnętrznego do wygenerowania wektora intów (lub innego typu).
2) Potem napisać:
  #include "MyVectorInt.h"
  .....
  struct TMyVectorInt v;
  int i;
  TMyVectorInt_init( &v );
  for( i=0 ; i<10 ; i++ ) {
   TMyVectorInt_append( &v , rand() );
  }
  for( i=0 ; i<TMyVectorInt_size( &v ); i++ ) {
    printf("%d\n" , (int)TMyVectorInt_get( &v , i ) );
  }
  TMyVectorInt_free( &v );


Tymczasem w C++ wystarczy:
 #include <vector>
 ...........
 using std;
 vector<int> v;
 for( int i=0 ; i<10 ; i++ ) {
   v.append( rand() );
 }
 for( int i=0 ; i<10 ; i++ ) {
   cout << v[i] << endl;
 }

Oczywiście plik nagłówkowy vector nie powstał sam, ale program do 
generyków w C też nie powstał sam. Poza tym tak jakby w tym 
przykładzie w C++ 2-3 razy mniej kodu, a przejrzystość porównywalna?
Jeśli programista zapomni TMyVectorInt_free to ma wyciek, w C++ o
tym pamięta kompilator. Więc chyba nie jest lepszy pod względem
zwięzłości kodu?

 

> wiec to pytanie zakladajace ze to dziwne skoro jest lepszy sie dezaktualizuje?

Może trochę przegiąłem z formą tego pytania.

> 
> nawiasem mowiac co do c/c++ ->
> 
> niektorzy ludzie ktorzy pisza w c++ mysle nie wiedzą jak sie poprawnie pisze w c

Fakt, sam też już robię dużo sytnax error gdy używam kompilatora C.


> (a przynajmniej jak ja pisze) i wydaje im sie ze w c sie wiecej nameczą skoro nie ma vectora czy 
> jeszcze kilku rzeczy ale fakty sa takie ze jak popisac w tym c to po nauczeniu sie jak to sie robi 
> (co dla jako tako ogarnietego programisty nie zajmie strasznie duzo czasu) pozniej nie ma zadnych 
> tego typu problemow

Chyba nie tylko moim zdaniem używanie bibliotek w C++ jest dużooooooo 
łatwiejsze, ale projektowanie dobrego reużywlnego kodu w C++ jest 
moim zdaniem dużo trudniejsze w C++.

 
> a zalety sa bardzo duze i sa takie (sam nie pisuje w c++ poza znajomsocia podstaw wiec moze nie wumienie wszystkich ;c )
> 
> 1) nie ma babrania sie z szablonami i calym tym krapem (ktory jest totalnie bezsensowny) - kod jest 
>    prostszy szybszy (w czytaniu i pracy nad nim) ktrotszy, ladniejszy itd

Jeśli programista nie projektuje bibliotek szablonów, tylko ich używa, to programowanie z
użyciem szablonów nie jest aż tak uciążliwe aby nazwać je babraniem się. Jeśli projektuje
bibliotekę to owszem, praca z szablonami stanowi katorżniczy wysiłek, kod jest mniej 
przejrzysty, trudniejszy w analizie i zwykle zawiera więcej błędów niż kod bez szablonów.
Ale w C++ można też tworzyć biblioteki bez szablonów, na zasadzie "C z klasami" - tyle że
wtedy efekt dla użytkownika nie bedzie tak wyśrubowany.

 
> 2) nie ma babrania sie z OOP (mniej wiecej jak wyzej) 
> w szczegolnosci z rozmaitymi wskaznikami (kod jest prostszy szybszy itd..)

Ja w gołym C programowałem bardzo mocno obiektowo i kod innych programistów który
oglądałem też był mocno obiektowy. Natomiast zgodzę się, że zaprojektowanie dobrych
hierarchii klas często jest trudniejsze niż rozwiązanie problemu w sposób czysto
proceduralny. W C++ też często piszę proceduralnie, a przerobienie na klasy i
zoptymalizowanie przez szablony zostawiam na potem. Zgodzę się że rozwiązanie
problemu w oparciu o hierarchię klas może wolniej działać niż rozwiązanie 
proceduralne.... No i pewnie w końcu ktoś zapyta: co to za programowanie w C++
bez szablonów i hierarchii klas? Cóż... dla mnie to też taki zubożony C++, a
nie normalny C++, bardziej podobne do C niż do pełnego C++. Czy to można nazwać
programowaniem w C++? Formalnie tak, ale jak spojrzę na kod i widzę tylko
procedry i struktury, to chce sie powiedzieć że to bardziej do C podobne.



> (zamist babrania sie z oop polecam staranna prace nad dll-kami i prawdziwym kodem)
> proponuje sprobowac, a jak nie to nie, wszystko mi jedno 

Co to jest prawdziwy kod? Masz na myśli pisanie kodu do rozwiązania problemu, zamiast
szukania sub-optymalnej formy do wyrażanie tego za pomocy wielu fitczerów C++?
Jeśli tak, to popieram, ale potem reużywalność, refaktoryzacja, rozbudowa,
analiza - są trudniejsze.

 
> (zaznaczam przy tym gwoli formalnosci ze mimo ze na dzis umiem dosyc ok 
> pisac w c, napisalem kilka rzeczy to nie mam zarazem super doswiadczenia w 
> pisaniu tysiecy rzeczy zwlaszcza w trybie pisania "na ilosc" (a mniej w moim 
> typowym trybie pisania dla sztuki ;c)  ale akurat nie ma to zdaje sie 
> kluczowego znaczenia bo c i tak bedzie lepsze.. klocic sie nie mam jednak 
> zamiaru bo nie mam czasu na takie komiczne dyskusje)

No ale gołe C jest nawet bez międlenia nazw i trzeba pisać struct przed
nazwą typu w deklaracji zmiennej... Dosłownie w C bym nie chciał programować,
ale często, jakieś w miarę akceptowalne rozwiązanie, można naskrobać
w takim C++ który bardziej przypomina C.

Pozdrawiam