Pull to refresh

Comments 19

Отличная статья, как и первая. Понравился текст на одной из картинок: «64 bit +good luck» :).
Прошу у кого есть, поделиться своими аналогичными примерами.

И буду рад узнать о замеченных ляпах, опечатках, неточностях и так далее. Но с этим прошу в почту.
Да как-то я все это уже тут видел, повторю просьбу: мне интересны ошибки при разработке кроссплатформенного софта, то есть такого, который в большем количестве различных ABI работает.
Я не знаю си, но статья понравилась. Особенно грузовик с сорванной башней :)
Большое и настоящее спасибо.
Действительно интересные статьи.
А ваша студия не умеет автоматически исправлять тривиальные ошибки?

Заменять int на size_t в очевидных случаях достаточно утомительное занятие…
Не умеет и это сознательное решение.

Во-первых, подобный класс программ (статические анализаторы кода) так не работают — это не причина конечно, но просто можно учесть.

Во-вторых, (и это главное на самом деле) — эксперименты сделанные вручную показывают, что автозамена подобная принесет вреда и пользы одинаково. То есть да, где-то оно сработает и станет лучше, а где-то заменит наоборот и будет хуже. Так что выгода не очевидна.

В-третьих, к сожалению во многих случаях тупой компьютер не может принять решение, как исправить ошибку. И должен обращаться к программисту за тайным знанием.

Но конечно было бы прикольно в Visual Studio как в Word мышкой ошибки исправлять подчеркнутые.

P.S. Да, и еще язык C++ (бесовский) к подобным тулам (которые на лету что-то правят) очень уж не склонен.
«Автоматически исправлять» это не значит что прямо вот так делать все за программиста… Это вообще хороший вопрос как такое можно сделать, но, мне кажется, можно придумать систему, которая существенно упростила бы жизнь. Хотя бы какой-то интерактивный помощник, предлагающий варианты исправления для каждого предупреждения.

Я осознаю, что в ручную конечно лучше… но «вручную» на проекте более миллиона строк это страшно… учитывая, что size_t нигде нету, так уж повелось…
>> можно придумать систему
ни индустрия статических анализаторов в целом, ни мы конкретно не смогли придумать удобного варианта.

В нашем инструменте мы это решаем по-возможности внятными диагностическими сообщениями («рекомендуем исправить так-то») плюс внятной справкой с примерами исправления.

>> «вручную» на проекте более миллиона строк это страшно

автоматически на таком проекте еще более страшно :-). В случае правок «вручную» ответственность лежит на программисте, а в случае автозамены очень большой соблазн обвинить инструмент во всех последствиях такой «автозамены».

Это я не отмазываюсь от того, чтобы такое сделать. Просто говорю о логике рассуждения, почему такое не делают.

Все-таки инструменты для (фактически) рефакторинга C++-кода сейчас намного хуже, чем инструменты для рефакторинга C# (к примеру). А замена типов — это и есть рефакторинг по сути. Помочь мог бы здесь скажем Microsoft с открытием публичного интерфейса в Visual C++ для реализации подобных штук. Они вроде бы даже и заявляют, что хотят со временем открыть это API, но проблема в том, что его сначала нужно сделать :-). Нынешняя реализация Visual C++ (по словам разработчиков) не позволяет легко и просто предоставлять разработчикам сторонних решений подобную функциональность.
я вот ни разу не c++ программист.

но мне кажется большинство указанных тут случаев можно свести к одному правилу:
«НЕХУЙ ИСПОЛЬЗОВАТЬ АРИФМЕТИКУ С УКАЗАТЕЛЯМИ!»

А я системный С ++ программист, но с вами абсолютно согласен: если есть возможность не пользоваться указателями — не пользуйтесь ими или сводите операции над указателями к минимуму.

Да и большинство ошибок в статье является вариантом адаптированных 32-ух битных.
Скажу даже более, вообще все примеры можно привести к одной фразе «при использовании арифметики/сдвигов/итд думайте мозгами»

Уже не первый десяток лет принята практика «пересборки» старого кода под новые процы и каждый раз одно и тоже. Понатыкают костылей типа #ifdef _WIN32, а результат всё тот-же что 20 лет назад. Cловно учиться на чужих ошибках «не кошерно» надо обязательно на грабли наступить, а может ещё и попрыгать на них…
Я сейчас патчу ядро Linux и не понимаю ваших проблем: что под 32-бита, что под 64-бита! работает!

А всего-то сделали что размер long равен размеру void*.
Адресная арифметика активно применялась в те времена, когда не было более безопасных методов, но вот нахуй её сейчас использовать не понимаю. Впрочем те, кому она реально нужна думаю таки знают как её использовать без ошибок
а расскажите о причинах использования арифметики указателей?

не таких идиотских, как в примерах, а вообще.

Слава б-гу не пишу на сях… Одна только мысль, что int остался ограничен 2^31, а вот int* уже 2^63 и из-за этого программа МОЖЕТ работать не корретно, вызывает у меня нервный смех :)
Это мне кажется или до половины проблем связаны с тем, что UINT_PTR и ULONG — разные по размеру типы?
В GCC сделано правильнее: long — всегда размером с указатель.
Вторая часть оказалась интереснее, спасибо.
Собственно имеется вопрос, зачем вообще все эти, long, long long, long long int, ULONG, UINT_PTR, __int64, size_t, ptrdfiff_t, и прочий геморрой?
В SDL хорошо сделано:
Uint64, Sint64, Uint32, Uint32 и так далее от 8 бит. IMHO идеальный вариант когда все типы фиксированы.
Sign up to leave a comment.