Здравей,

Не, няма предимство ръчно да се превръща в hex вместо да се ползва stoi(). Аз го правя го правя ръчно най-вече за да покажа как би било направено ако не ползвате stoi() (пък и stoi() е от C++11, което в някаква ситуация е възможно да не може да ползвате - на изпита ще може, но тук-там има реални проекти, които стоят на стария стандарт). То като цяло за тази задача няма голям смисъл да се превръща в число изобщо, достатъчно е да въвеждаш в масив от 6 char-а и да го обработваш като 6 байта върху които правиш XOR - но го направих така за да е по-четимо.

Спорно е дали getchar е по-бързо от cin (зависи как го направиш, ако четеш по 6 наведнъж сигурно ще има забързване), обикновено когато cin e бавен, е бавен заради рендерирането на самата конзола (местене на маркера примерно) - в Judge системата cin е пренасочен към RAM паметта и не рендирира конзола, така че е сравнително бърз. Да, има забавяне, защото трябва да знае какво cin-ва и как да го обработи, но за случая на char обработка няма (ако беше int щеше да трябва да направи нещо еквивалентно на stoi за да го прочете). И, отново, cin ви е по-познато от лекциите, затова гледам да ползвам него. Като цяло задачите ги правя така, че скоростта на четене от конзолата да не ви определя резултата на решението, защото това бързо четене е нещо с доста ограничено приложение в истинския свят (повечето истински проекти или нямат големи четения на данни, или тези четения се извършват от някакви специални библиотеки, които са специализирани да бъдат бързи в това). Но е хубаво, че се интересуваш, така можеш да си спечелиш няколко допълнителни милисекунди на изпита и да компенсираш ако решението ти има някоя не-оптимална част :)

Поздрави,

Жоро

Ок, мерси много за отговора. Тази задача доста успя да ме поизпоти и може би за това търсих подобни дребни оптимизации. :)

Ей тoва нещо std::ios::sync_with_stdio(false);

от програмата за 2 задача със cin, направи от 3 секунди и нещо да върви на 1,7 сек и нещо.

Не че знам какво прави.