[Ki3mon]

Poleci ktoś jakiś tutek na yt od podstaw w cpp? ( ͡° ͜ʖ ͡°)
#cpp #programowanie #programista15k

[Saly]

@Kaczus2B: patrzyłem kiedyś jak działa zarządzanie pamiecią w stringstream, testowałem clanga i g++. W obu przypadkach widać było piękne realokowanie do 2x większego obszaru https://wandbox.org/permlink/XIsV6286iFfmxaGj

[Kaczus2B]

@Saly: to zamien sobie teraz na std::string skompiluj i sprawdz, ze ta druga opcja zajmie 2 razy tyle pamieci...

[Saly]

@Kaczus2B: akurat w tym przypadku wyszło jakieś 0.8x mniej https://wandbox.org/permlink/IUWjVdkNflwu8Oaq

[Saly]

@Kaczus2B: jeszcze benchmark http://quick-bench.com/XUNbio24-VYtOpeqAH1a0umzfZU : sam się zdziwilem, ze dziala az tak wolno

[Kaczus2B]

@Saly: bo masz staly string, wiec mozliwosc ladnej optymalizacji, a teraz zamiast 'a' daj << i a w drugim przypadku + std::to_string(i)

[Saly]

@Kaczus2B: http://quick-bench.com/hpNGmzpucxTVFJWws5TYPdlzswc jest lepiej, ale nadal 2x wolniej

[Kaczus2B]

@Saly: ale dlaczego pomijasz propozycje ktore daje, tu znowu masz staly string - dobry kompilator powinien to wylapac.... napisalem cos co sie zmienia, zaproponowalem bys dodawal za kazdym razem licznik... Ba wtedy zobaczysz jak w roznych implementacjach roznie to wyglada, bo jak napisalem, o ile std::string ma wieksze ograniczenia, to w przypadku std::stringstreama mozna sie popisac i wtedy jakosc programistow tworzacych biblioteke standardowa danego kompilatora moze sie wykazac

[Saly]

@Kaczus2B: wołając std::to_string będę robił to samo pod spodem co stringstream, wiec imo to nie ma sensu + marnuje dużo cyklów procesora na stworzenie stringa, którego nie potrzebuję. Zresztą string nie ma api do dopisywania stringow, co nie zmienia faktu, że jak napiszę to od ręki: http://quick-bench.com/8vI8uc3uR1UhjC1FQQ8LCVp_5y8 to i tak jest 2x szybciej.

[Kaczus2B]

@Saly: zaraz zaraz, kolega wyzej pisal ze char b[11] to zlo, a ty uzywasz! Arytmetyka wskaznikow... Bo jakbys pozostal przy konwencjonalnym to_string to okazaloby sie wolniejsze. Wiec wolisz na sile zaciemniac.
A przeciez dyskusja zaczela sie od tego, ze to jest niepotrzebne. Widzisz zagladajac do implementacji mozna kilka sztuczek podejrzec. Napisalem, ze w niektorych sytuacjach std:strinstream moze yc szybsze i jest - ale uwaga zalezne jest to od potrzeb, jak

[Saly]

zaraz zaraz, kolega wyzej pisal ze char b[11] to zlo, a ty uzywasz! Arytmetyka wskaznikow...

@Kaczus2B: jest to zło, niestety C++ jeszcze nie ma na tyle dojrzałej biblioteki standardowej, żeby porzucić pointery. Najbliżej tego czego użyłem jest std::span, niestety jest on dostępny dopiero od C++20. Zwłaszcza, że std::tochars jest nowy, pochodzi z C++17. Co do tablicy to mógłbym użyc std::arraya, ale tak jest wygodniej ( ͡° ͜ʖ ͡°)

Bo

[Kaczus2B]

@Saly: moze dalem za duzy skrot myslowy klejenie stringow, to dla mnie cos wiecej niz dodatnie 2, bo tu nawet nad optymalizacja bym sie nie zastanawial, ale chodzi mi o caly arsenal, musisz zbudowac stringa z liczb, innych stringow ect. Inna sprawa, ze jak pisalem, teoretycznie streamstring moze dzialac szybciej, ale to znajdziesz w mniej typowych implementacjach zazwyczaj, ale sa tez takie, ktore zaoszczedza np na ilosci alokacji na przyklad.

[lionbest]

@Saly: Ok masz racje że std::stringsteam to rak, chociaż brak możliwości rezerwacji, czy przeniesienia stringa oraz to że .str() robi kopię! Mimo wszystko to nie znaczy że koncept StringBuilder nie będzie działał szybciej od konkatenacji obiektów String, chociaż taki Qt się wycfanił z operatorem%.
Niestety szczegół polega na tym ze od stringstreama nie da się uciec, przykładowo lokalizacja polega na tym.

[lionbest]

W każdym bądź razie lepiej się skupić na koncepcjach projektowych, niż nad używaniem tablic z C.