Я заметил, что многие проекты с открытым исходным кодом больше не используют флаги BITWISE, даже если они полностью поддерживаются средой программирования, общей для Интернета (php / Mysql). Это «потерянная практика» для какой-то эффективной проблемы, или просто многие программисты php не знают, как справиться с этим типом реализации?
Ничего особенного, просто очень любопытно :) спасибо вам всем






Многие программисты в наши дни, кажется, просто забиты знаниями, достаточными для того, чтобы вывести код грубой силой и затем отправить их в рабочую силу, не будучи обученными тому, что вообще означают такие слова, как «побитовый».
Говорю вам, это умирающее искусство ...
Я до сих пор использую побитовые операторы, хотя, поскольку мой основной язык (и в профессиональном плане) - это C#, я часто использую для него перечисления Flag :) Но да, я думаю, что многие люди, которые кодируют такие вещи, как PHP, являются самоучками, и не знать о побитовых операциях или их использовании.
Будучи самоучкой, я мало что знал о них, пока не начал писать код на C и C++. Теперь я использую их там, где они имеют смысл :)
Это не дает ответа на вопрос. Чтобы критиковать или запрашивать разъяснения у автора, оставьте комментарий под его сообщением.
@IlijaDimov Без обид, но этот ответ был написан почти 7 лет назад, когда с переполнением стека все было немного по-другому. Оставленный вами комментарий не требовался.
Этот ответ появился в очереди на просмотр сообщений низкого качества несколько дней назад. Я пометил это как не ответ, основанный на текущих правилах хорошего ответа, и комментарий появился автоматически.
Если у вас уже сложное приложение, зачем его усложнять, используя побитовые флаги. Я лично не стал бы использовать такие флаги, если бы не было больше плюсов, чем просто быть крутым. И, исходя из опыта, написать это довольно легко, позже поправить сложнее, не говоря уже о том, что вы не писали это сами.
Да, кстати, я знаю, как их использовать.
Я согласен, они просто сложнее, когда память была дорогой, они имели смысл. Сейчас память дешевая, а пропускная способность выше нет смысла.
Тем не менее, каждый разработчик должен знать, что такое побитовые флаги, на случай, если ему когда-либо придется иметь с ними дело (например, устаревший код или аппаратное взаимодействие). Кажется, что многим разработчикам это действительно не хватает.
Да, я полностью согласен с этим, но то, что кто-то не использует определенную технику, не обязательно означает, что он этого не осознает или не знает.
Я высуну шею и скажу, что каждая техническая позиция требует хорошего понимания побитовых операций.
И у меня есть анекдот, косвенно касающийся этой темы.
В январе 2007 года я был в Кочине, Индия, набирал постоянных сотрудников по развитию. Поскольку я не участвовал в предварительном отборе кандидатов, я понятия не имел, какого стандарта ожидать, поэтому я подготовил ряд вопросов и тем, начиная от простого понимания двоичного и шестнадцатеричного до архитектуры, дизайна и управления проектами.
Когда я обсуждал свой подход с индийским специалистом по персоналу, меня (мягко) упрекнули за слишком низкую подачу. Он ясно дал понять, что мои вопросы о проклятии, возможно, будут истолкованы как оскорбление опыта или образования кандидата.
Но мой опыт проведения собеседований с сотнями кандидатов в Великобритании укрепил во мне убеждение, что нельзя говорить слишком низко. Мое мнение было и остается тем, что если станет очевидным, что кандидат хорошо квалифицирован, то легко и просто изменить уровень обсуждения. Я никогда не слышал, чтобы кто-нибудь выразил чувство оскорбления, напротив, я думаю, что хорошо квалифицированный кандидат может почувствовать облегчение в самом начале интервью. Это также помогает сломать лед и построить взаимопонимание, необходимое для содержательного интервью. С другой стороны, неквалифицированные кандидаты обычно не справляются с этими более низкими препятствиями.
Но не желая полностью игнорировать местные советы, я осторожно решил включить свои основные темы интервью и был вполне готов отказаться от них, если они не сработают.
По мере того, как продолжались интервью, я был рад, что начал на этом уровне. Это никого не обидело, и неподходящих кандидатов легко выявляли.
Это не означает, что я ожидаю, что кандидаты будут ежедневно иметь дело с бит-тидлингом, но независимо от языка важно хорошее понимание основ программирования. Даже разработчики на более высоких уровнях абстракции регулярно сталкиваются с шестнадцатеричным кодом (например, значениями RGB). Parroting вещи, которые вы найдете в сети поможет только в той степени, в которой все работает идеально с первого раза.
Но для разработчиков, начинающих в последние пять лет, я считаю, что слишком легко приукрашивать основы из-за благих намерений IDE и мемов "бескодового" программирования. Экраны установки Visual Studio могут похвастаться возможностью разработки без написания кода. Действительно, разве Visual Studio портит разум??
Интересный анекдот, но я не понимаю, как он отвечает на вопрос.
Битовые поля очень полезны, если у вас очень жесткие требования к памяти и скорости, или при низкоуровневом программировании оборудования.
Если вы не занимаетесь встроенным программированием или чем-то подобным, они вам не нужны. Существуют гораздо более удобочитаемые, мощные и расширяемые механизмы для выполнения той же задачи. Например, Java EnumSets.
Я ожидаю, что хороший программист их знает и не использует :-p
В них всегда есть место для хранения большого количества логических флагов в небольшом пространстве;
Подумать только, если у вас 32 флага (например); Вы можете сохранить их все в одном «длинном целом числе» и просто использовать 4 байта. А теперь представьте, что вы решили использовать длинное число для каждого флага (просто потому, что код легче поддерживать - теперь у вас есть 128 байтов для работы.
Мой фон в основном C / C++, поэтому я был воспитан на них, поэтому я определенно использую их на всех языках, которые использую; но я согласен; начинающим программистам, как правило, наплевать - вся эта память валяется - кого это волнует?
«Изобилие» довольно общее, нам нужны имена! ;-)
Серьезно, я пришел с ассемблера и C, и я довольно хорошо разбираюсь в побитовых операциях. Но я бы не стал использовать их для замены, скажем, 10 несвязанных логических значений в классе с двоичными флагами в целом числе ... Если, может быть, у меня нет миллионов экземпляров этого класса!
Если мне придется манипулировать множеством экземпляров логических значений, я бы использовал некоторый класс битового набора, чтобы оптимизировать и абстрагироваться от этих массивов битов.
Теперь битовая манипуляция fu почти обязательна в программировании, если вы хотите получить доступ к компонентам значений RGB [A], если вы хотите вызвать некоторые API (даже если это просто операция ИЛИ для нескольких именованных флагов) и т. д.
Короче говоря, я не буду использовать это в каждом проекте, который я делаю, но вы не можете игнорировать, как это делать (что-то вроде регулярных выражений ...).
Побитовые операции - это не только сохранение памяти. Они действительно полезны для написания понятного кода. Что бы вы предпочли увидеть?
OpenFile("...", true, false)
или же
OpenFile("...", writeonly | append)
Это своего рода бессмысленный / тривиальный пример, но идею вы поняли.
Я бы предпочел первый, со всплывающими окнами с документацией по коду. Второе кажется более неоднозначным.
Во втором случае нет необходимости запоминать порядок опций, не увеличивается количество параметров, которые функция должна поддерживать, и вызов самодокументируется.
За пределами встроенного программирования, где критически важно управление памятью, их стоимость превышает их минимальную ценность. В частности, запрос столбцов базы данных, содержащих побитовые флаги, создает загадочный SQL, который требует ссылки на код приложения только для определения того, на какое значение ссылается каждая побитовая операция.
WHERE (ISNULL(flags, 0) & 4096 = 0 -- What does this bit refer to?
Если необходимость запрашивать вашу БД таким образом вас не пугает, так и должно быть.
Действительно, эти значения мешают реконструировать. У меня есть эта проблема, когда я вижу значения отчетов об ошибках php в конфигурациях apache!
Этот фрагмент SQL выглядит знакомым ...
Ха! Привет, Джесси - Маленький мир, который я видел!
Я не вижу внятного оправдания. Да, этот навык становится все менее актуальным / распространенным, но это не отвечает на вопрос.