Вот видишь, учись "хуяк-хуяк и в продакшн" на Цэ делать, а не вот это все, а то тебя так никто в свою уютненькую ппшу не возьмет.
Прикинь не берут =( Говорят приходил спереди толстый а сзади кривой и сказал тебя не брать. Как тебе элитный кодес работы с путями?
Я даже не хочу в это все вникать.
А че там вникать функа смотрит строку и если она не заканчитвается \ то она добавляет к концу \, вот так просто берет и добавляет все что функа принимает это SetPathEndForSlash(PWCHAR path), без контроля длины и тд, просто там же полюбому 2 байтика должно быть свободных, это же не 100 а всесго 2.
Я имею ввиду, что в шкафчике скорее всего никогда не будет каких-то вещей, что мне были бы интересны с практической или теоретической точки зрения. Поэтому вникать в это не имеет смысла, ну окей там можно поржать с говнокода, но дальше то что с этой информацией делать?
Ну это олдскульный подход, раньше все жили с путями, ограниченными MAX_PATH (вроде 260 символов, если мне не изменяет память), и были счастливы. Те же самые "замечательные" winapi-функции Path* из shlwapi.dll на это и рассчитывают. Это, наверное, еще с доса тянется, типа 1 символ - буква диска, 2 символа ":\", 256 символов - путь и \0 на конце, в сумме 260, но не суть. Как бы гавнокод, это понятно, но если, например, у него буфер со строкой размером 32к символов (максимальный размер пути в NTFS), то я не вижу прям критичного в том, чтобы в данном случае длиной строки пренебречь. Ну это по Цэшному и грозит условным buffer overflow, но вряд ли кто-то будет пытаться переполнять буфер в шкафчике, и вряд ли ты в своей жизни хоть раз встретишь путь длиннее, чем 32к символов.
Хз какая там у него начальная строка (32к символов или нет), но в целом, все верно - пути больше физически не существует в виндах, а каждый раз получать длину, считать, да еще реаллочить - это потеря времени.
я уже говорил тебе и твоему "коллеге" Льву, в чем вы меряете успех в кодинге? В деньгах или в написанных умных словах на форуме или в поощрениях от старшего менеджера или "карме" на хабре или еще в чем? А то у нас дискуссия какая-то в стиле разговор ради самого разговора. Возвращаясь к твоим темам про спортзал - можно заниматься для здоровья, можно для соревнований, можно для внешнего вида, для физической силы, да дохрена для чего. Каждый выбирает свое, а тут такой срач, как лифтеры вс бодибилдеры вс турникмены.
как раз болячка говнокода когда Ц стайл типа - Somethin(LPWSTR pStr) посчитает pStr, потом передаст этот pStr еще куда то, потом там еще куда то и в каждом месте будут считать потому что это указатель на массив который оканчивается нулем и единственный способ узанть его длину это каждый раз считать, а каждый раз потому что это не объект как например string котрый знает свой размер и не пересчитывает себя при каждом запросе длины. Говнокод детектед.
Его "коллега" Лев измеряет свой успех в кодинге в интересе и творчестве. Вот я запилил статьи про всратый анклав и виртуализацию на этапе компиляции, и сижу довольный. Вообще похер, практично это в итоге или нет, доработает это кто-нибудь и вставит к себе в малварь или нет, заплатят мне за эти статьи на конкурсе или нет, докопается до моего кода какой-нибудь душнила или нет. Мне было весело и интересно в этом копаться, на остальное похер.
Это как реверс шкафчиков ради реверса шкафчиков, а вовсе, ну вот вообще ни разу не для того, чтобы запилить свою ппшу или устроиться в уже существующую.
Ну к слову, куча далеко не самая оптимизированная по скорости вещь. Поэтому часто в играх и других приложениях, которым нужна скорость используют сторонние аллокаторы, ну или пишут свои. Для шкафчика скорее всего подошел бы арена-аллокатор.
Мы меряем качество кода а не финансовый успех. Качество кода не меряется финансовым успехом, так же как вес не меряется сантиметрами. Для кода есть критерии качества и это не деньги.
Для шкафчика мог бы аллокатор сыграть какую то роль только в плане избежать проблемы фрагментации, да и то вряд ли, если нет утечек то адово зафрагментировать память не выйдет. А оптимизацию надо делать только после того как нйдешь ботлнеки.
.text:008A8395 loc_8A8395: ; CODE XREF: CreateBmpImageAndSetItForWallpaperIfFlagSet+18E?j
.text:008A8395 push 1024 ; Size
.text:008A839A call _RtlAllocateHeap
.text:008A839F mov [ebp+pWallpaperFileW], eax
...
.text:008A85D6 loc_8A85D6: ; CODE XREF: CreateBmpImageAndSetItForWallpaperIfFlagSet+3CF?j
.text:008A85D6 push 0
.text:008A85D8 push 23h
.text:008A85DA push [ebp+pWallpaperFileW]
.text:008A85DD push 0
.text:008A85DF call SHGetSpecialFolderPathW
.text:008A85E5 push [ebp+pWallpaperFileW]
.text:008A85E8 call SetPathEndForSlash
.text:008A85ED mov ebx, [ebp+pWallpaperFileW]
.text:008A85F0 mov ecx, pRegistryKeyNameBasedOnLockKey ; .w7FOAXxHF
.text:008A85F6 lea eax, [ecx+2]
.text:008A85F9 push eax ; Source
.text:008A85FA push ebx ; Dest
.text:008A85FB call wcscat
.text:008A8601 add esp, 8
.text:008A8604 push ebx ; Str
.text:008A8605 call wcslen
.text:008A860B add esp, 4
.text:008A860E lea eax, [ebx+eax*2]
.text:008A8611 mov dword ptr [eax], 0B79E4016h ; b'.bmp'
.text:008A8617 mov dword ptr [eax+4], 0B78C4055h
.text:008A861E mov dword ptr [eax+8], 0B7FC4038hНа Цэ сложно сделать приятные и удобные абстракции. Для примера можно взять тот же GObject, красноглазикам из GNOME пришлось целых два новых языка программирования (Vala и Genie) запилить, чтобы меньше страдать с GTK и GObject на Цэшке.
Так просто надо признать что ц устарел и двигатся дальше.
Дилда, конечно, хорош в риторике, но ни разу не мессИя. Язык всего лишь инструмент, надо лучше общий уровень грамотности повышать, чтобы то и дело не появлялись гении, которые рантайм детекты елочками обходят. Ну а лечить жертв стокгольмского синдрома у меня нет сил.
Ну да мессия он то по воде а ты под себя, но это же не повод опускать руки! Но знаешь вот что меня тревожит, кроме нас с тобой вообще всем похрен, ну кроме кевейка, но того во что не ткни он все равное скажет что вовсе это не говно раз за него деньги уплочены, а остальным всем вообще все равно, и это тревожит.
По моему мнению, качество кода определяется задачей, которую этот код решает. А то это выглядит как выставка военной техники, и кто-то критикует условную бмп-3, что там железо слишком толстое, двигатель мол топлива жрать много будет. И сидения какие-то не эргономичные, нет возможности разложить, и твердое всё.. Ну это же малварь, тут другие критерии должны быть.
Везде можно найти, до чего докопаться.
А что обсуждать? Уж извини, но я своего мнения не поменяю, писал пишу и буду писать на Си. Мне в нем не хватает только contexptr или как его, т.е. чтобы макросами шифровать строки. А так - Gdi+ и СОМ вполне себе норм с процедурного кодинга работают, в целом удобно, работает - что еще надо? Агитировать можно начинающих, но опять же - вот я написал статью "как кодить малварь". Где написал про Си. В статье написали дофига критики (и ты, и пендос какой-то, и так далее), но никто не написал такую же статью со своим виденьем ситуации. Вот чтобы от а до я, вида "учимся кодить малварь на шарпе", и такие мануалы шарп для нубов, особенности шарпа, повершелл.. нет этого почему-то.
