Случайное использование = вместо ==

одна полезная конструкция, например:

char *pBuffer;
if (pBuffer = malloc(100))
{
    //continue to work here
}

редактировать:
как уже упоминалось ранее, и за это время я получил несколько голосов против, я могу добавить, что это не особенно хороший стиль, но его можно увидеть достаточно часто, чтобы сказать, что он полезен. Я также видел это с new, но это вызывает больше боли в груди.

Другим примером, менее спорным, может быть:

while (pointer = getNextElement(context))
{
    //go for it, use the pointer to the new segment of data
}

что означает, что функция getNextElement() возвращает NULL, когда нет следующего элемента, так что цикл завершается.

Потому что это не незаконно (по крайней мере, в C или C++), а иногда и полезно ...

if ( (x = read(blah)) > 0)
{
    // now you know how many bits/bytes/whatever were read
    // and can use that info. Esp. if you know, say 30 bytes
    // are coming but only got 10
}

Большинство компиляторов вызывают настоящую вонь, если вы все равно не ставите скобки вокруг присваивания, что мне нравится.

Многие компиляторы обнаружат это и предупредят вас, но только если вы установите достаточно высокий уровень предупреждения.

Например:

 ~> gcc -c -Wall foo.c
foo.c: In function ‘foo’:
foo.c:5: warning: suggest parentheses around assignment used as truth value

В большинстве случаев компиляторы очень стараются сохранить обратную совместимость.

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

Это зло, с которым мы в значительной степени застряли в банкоматах, но есть способы обойти и уменьшить его опасность.

Пример:

   void *ptr = calloc(1, sizeof(array));
   if (NULL = ptr) {
       // some error
   }

Это вызывает ошибку компиляции.

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

В C это довольно распространенная идиома для тестирования указателей, возвращаемых malloc, или если после вилки мы находимся в родительском или дочернем процессе:

if ( x = (X*) malloc( sizeof(X) ) {
   // malloc worked, pointer != 0

if ( pid = fork() ) {
   // parent process as pid != 0

Компиляторы C / C++ будут предупреждать с достаточно высоким уровнем предупреждения, если вы попросите об этом, но это не может считаться ошибкой, поскольку язык позволяет это. Если только вы снова не попросите компилятор рассматривать предупреждения как ошибки.

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

if ( 0 == variable ) {
   // the compiler will complaint if you mistakenly 
   // write =, as you cannot assign to a constant

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

Поэтому лучше написать:

0 == CurrentItem

Вместо:

CurrentItem == 0

так что компилятор предупредит вас, если вы наберете = вместо ==.

Неужели это такая частая ошибка? Я узнал об этом, когда сам изучил C, и как учитель я иногда предупреждал своих учеников и говорил им, что это обычная ошибка, но я редко встречал ее в реальном коде, даже у новичков. Конечно, не чаще, чем другие ошибки операторов, например, написание «&&» вместо «||».

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

Простой ответ: операция присваивания, такая как x = y, имеет значение, такое же, как вновь присвоенное значение в x. Вы можете использовать это непосредственно в сравнении, поэтому вместо

x = y; if (x) ...

ты можешь написать

if (x = y) ...

Это меньше кода для написания (и чтения), что иногда хорошо, но в настоящее время большинство людей соглашаются с тем, что его следует написать каким-то другим способом для повышения читабельности. Например так:

if ((x = y) != 0) ...

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

p = malloc(4711); if (p != NULL) printf("Ok!");

Сравнение с NULL является избыточным, поэтому вы можете переписать его следующим образом:

p = malloc(4711); if (p) printf("Ok!");

Но поскольку операция присваивания имеет значение, которое можно использовать, вы можете поместить все присваивание в условие if:

if (p = malloc(4711)) printf("Ok!");

Это делает то же самое, но более кратко.

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

Да, все примеры, в которых он используется, можно переписать в виде более длинных фрагментов кода.

Есть несколько тактик, которые помогут это обнаружить ... одна уродливая, другая обычно представляет собой макрос. Это действительно зависит от того, как вы читаете свой разговорный язык (слева направо, справа налево).

Например:

if ((fp = fopen("foo.txt", "r") == NULL))

Против:

if (NULL == (fp = fopen(...)))

Иногда бывает проще прочитать / написать (сначала) то, для чего вы тестируете, что упрощает определение задания по сравнению с тестом. Затем пригласите большинство людей с comp.lang.c, которые страстно ненавидят этот стиль.

Итак, вводим утверждать ():

#include <assert.h>

...
fp = fopen("foo.txt", "r");
assert(fp != NULL);
...

когда вы находитесь в середине или в конце запутанного набора условных выражений, assert () - ваш друг. В этом случае, если FP == NULL, вызывается abort () и передается строка / файл с ошибочным кодом.

Итак, если вы упс:

if (i = foo)

помимо

if (i == foo)

с последующим

assert (i > foo + 1)

... вы быстро заметите такие ошибки.

Надеюсь это поможет :)

Короче говоря, изменение аргументов иногда помогает при отладке. Assert () - ваш долгий друг, и его можно отключить во флагах компилятора в производственных версиях.

Стандартная идиома C для итерации:

list_elem* curr;
while ( (curr = next_item(list)) != null ) {
  /* ... */
}

Идиома 'if (0 = x)' почти бесполезна, потому что она не помогает, когда обе стороны являются переменными ('if (x = y)') и большую часть (все?) Времени вы должны использовать постоянные переменные а не магические числа.

Две другие причины, по которым я никогда не использую эту идиому. ИМХО, это делает код менее читаемым, и, честно говоря, я считаю, что единственный знак «=» является корнем очень небольшого зла. Если вы тщательно протестируете свой код (что, очевидно, и делаем все мы), такого рода синтаксические ошибки обнаруживаются очень быстро.

Это очень часто встречается с конструкциями цикла "низкого уровня" в C / C++, например, с копиями:

void my_strcpy(char *dst, const char *src)
{
    while((*dst++ = *src++) != '\0') { // Note the use of extra parentheses, and the explicit compare.
        /* DO NOTHING */
    }
}

Конечно, для циклов for очень часто используются присваивания:

int i;
for(i = 0; i < 42; ++i) {
    printf("%d\n", i);
}

Я действительно считаю, что легче читать назначения, когда они представляют собой за пределами операторов if:

char *newstring = malloc(strlen(src) * sizeof(char));
if (newstring == NULL) {
    fprintf(stderr, "Out of memory, d00d!  Bailing!\n");
    exit(2);
}

// Versus:

if ((newstring = malloc(strlen(src) * sizeof(char))) == NULL) // ew...

Убедитесь, что задание очевидно, thuogh (как в первых двух примерах). Не скрывайте этого.

Что касается случайного использования ... со мной такое случается нечасто. Распространенной защитой является размещение вашей переменной (lvalues) в правой части сравнения, но это не работает с такими вещами, как:

if (*src == *dst)

потому что оба варианта == имеют lvalue!

Что касается компиляторов ... кто может их винить? Писать компиляторы сложно, и вы все равно должны писать идеальные программы для компилятора (помните GIGO?). Некоторые компиляторы (самые известные наверняка) предоставляют встроенную проверку в стиле lint, но это, конечно, не требуется. Некоторые браузеры не проверяют каждый отправленный байт HTML и Javascript, так зачем компиляторам?

Попробуйте просмотреть

if ( life_is_good() )
    enjoy_yourself();

в виде

if ( tmp = life_is_good() )
    enjoy_yourself();

На практике я этого не делаю, но есть хороший совет:

if ( true == $x )

В случае, если вы не укажете равные значения, присвоение $xtrue, очевидно, вернет ошибку.

Я думаю, что разработчики языков C и C++ заметили, что в запрещающий нет реального использования, потому что

• Компиляторы могут предупредить об этом, если захотят
• Запрещение этого добавит к языку особых случаев и приведет к удалению возможной функции.

Это не сложно. C++ просто говорит, что требуется выражение, неявно конвертируемое в bool. В C есть полезные случаи, подробно описанные в других ответах. В C++ они пошли еще дальше и допустили еще одно:

if (type * t = get_pointer()) {
    // ....
}

Что на самом деле ограничивает область действия t только if и его телами.

За 15 лет разработки у меня была эта опечатка только ОДИН РАЗ. Я бы не сказал, что это стоит на первом месте в моем списке вещей, на которые стоит обратить внимание. Я все равно избегаю этой конструкции.

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

Размещение константы слева от сравнения - это защитное программирование. Уверен, что ВЫ никогда не совершите глупую ошибку, забыв этот лишний знак "=", но кто знает о ДРУГОМ парне.

Язык программирования D помечает это как ошибку. Чтобы избежать проблемы с желанием использовать значение позже, он позволяет объявления вроде того, что позволяет C++ с циклами for.

if (int i = some_fn())
{
   another_fn(i);
}

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

Одна выработанная мною привычка, которая удерживает меня от укуса (по крайней мере, на языках Си-иш), заключается в том, что если одно из двух сравниваемых значений является константой (или иначе не допустимым lvalue), я помещаю его в левой части компаратора: if (5 == x) { whatever(); } Тогда, если я случайно наберу if (5 = x), код не будет компилироваться.

Отчасти это связано с личным стилем и привычками. Я не сторонник чтения if (kConst == x) или if (x == kConst). Я не использую константу слева, потому что исторически я не делаю этой ошибки и пишу код так, как я бы сказал или хотел бы его прочитать. Я рассматриваю это как личное решение как часть личной ответственности за то, чтобы быть самосознательным, улучшающимся инженером. Например, я начал анализировать типы ошибок, которые создавал, и начал перестраивать свои привычки, чтобы они не создавались - аналогично постоянным слева, только с другими вещами.

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

Оператор присваивания может использоваться в условных операторах по-разному, и было бы настоящей головной болью постоянно видеть предупреждения о каждом из них. Было бы неплохо, если бы в вашей среде IDE была функция, которая позволила бы вам выделить все места, где использовалось присваивание вместо проверки равенства - или - после того, как вы напишете что-то вроде этого:

if (x = y) {

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

Я лично считаю это наиболее полезным примером.

Скажем, у вас есть функция read(), которая возвращает количество прочитанных байтов, и вам нужно использовать ее в цикле. Намного проще использовать

while((count = read(foo)) > 0) {
    //Do stuff
}

чем пытаться получить задание из заголовка цикла, что приведет к таким вещам, как

while(1) {
    count = read(foo);
    if (!(count > 0))
        break;
    //...
}

или же

count = read(foo);
while(count > 0) {
    //...
    count = read(foo);
}

Первая конструкция кажется неудобной, а вторая неприятным образом повторяет код.

Если, конечно, я не упустил какую-нибудь блестящую идиому для этого ...

О допустимом использовании if (i = 0)

Проблема в том, что вы воспринимаете проблему с ног на голову. Обозначение «if» не предназначено для сравнения двух значений, как в некоторых других языках.

Инструкция C / C++ "if" ожидает любого выражения, которое будет иметь либо логическое значение, либо нулевое / ненулевое значение. Это выражение может включать сравнение двух значений и / или может быть гораздо более сложным.

Например, у вас может быть:

if (i >> 3)
{
   std::cout << "i is less than 8" << std::endl
}

Это доказывает, что в C / C++ выражение if не ограничивается == и =. Подойдет все, что угодно, если оно может быть оценено как истинное или ложное (C++) или как ноль, отличное от нуля (C / C++).

Другое допустимое использование C++:

if (MyObject * pObject = dynamic_cast<MyInterface *>(pInterface))
{
   pObject->doSomething() ;
}

И это простое использование выражения if (обратите внимание, что это также можно использовать в строке объявления цикла for). Существуют более сложные варианты использования.

О расширенном использовании if (i = 0) в C++ [цитируется от меня]

After discovering a duplicate of this question at В каком случае, если (a = b) - хорошая идея?, я решил дополнить этот ответ дополнительным бонусом, то есть инъекцией переменной в область видимости, которая возможна в C++, потому что if будет оценивать свое выражение, включая объявление переменной, вместо того, чтобы ограничивать себя сравнением двух операндов, как это сделано на других языках:

Итак, цитирую от себя:

Другой вариант использования - это то, что называется C++ Variable Injection. В Java есть это классное ключевое слово:

synchronized(p)
{
   // Now, the Java code is synchronized using p as a mutex
}

В C++ это тоже возможно. Я не имею в виду точный код (ни точную статью DDJ, где я его обнаружил), но этого простого определения должно быть достаточно для демонстрационных целей:

#define synchronized(lock) \
   if (auto_lock lock_##__LINE__(lock))

synchronized(p)
{
   // Now, the C++ code is synchronized using p as a mutex
}

Таким же образом, смешивая инъекцию с if и для объявления, вы можете объявить примитивный макрос foreach (если вам нужен foreach промышленного уровня, используйте boost).

См. Следующие статьи для менее наивной, более полной и надежной реализации:

• http://www.drdobbs.com/184401723?pgno=6
• http://www.drdobbs.com/184401728
• http://www.drdobbs.com/184401752

Сколько на самом деле ошибок такого рода бывает?

Редко. На самом деле, я еще не вспомнил ни одного, а я профессионал уже 8 лет. Я предполагаю, что это произошло, но затем, за 8 лет, я действительно произвел значительное количество ошибок. Просто такого рода ошибок было недостаточно, чтобы я с разочарованием вспомнил о них.

В C у вас будет больше ошибок из-за переполнения буфера, например:

void doSomething(char * p)
{
   strcpy(p, "Hello World, how are you \?\n") ;
}

void doSomethingElse()
{
   char buffer[16] ;
   doSomething(buffer) ;
}

Фактически, Microsoft так сильно обиделась из-за того, что они добавили в Visual C++ 2008 предупреждение об отказе от strcpy !!!

Как избежать большинства ошибок?

Самая первая «защита» от этой ошибки - это «развернуть» выражение: поскольку вы не можете присвоить значение константе, это:

if (0 = p) // ERROR : It should have been if (0 == p). WON'T COMPILE !

Не компилируется.

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

Например, вместо:

void doSomething(char * p)
{
   if (p == NULL) // POSSIBLE TYPO ERROR
      return ;

   size_t length = strlen(p) ;

   if (length == 0) // POSSIBLE TYPO ERROR
      printf("\"%s\" length is %i\n", p, length) ;
   else
      printf("the string is empty\n") ;
}

Попытка "константировать" как можно больше переменных позволит вам избежать большинства ошибок опечаток, в том числе тех, которые не находятся внутри выражений "если":

void doSomething(const char * const p) // CONST ADDED HERE
{
   if (p == NULL) // NO TYPO POSSIBLE
      return ;

   const size_t length = strlen(p) ; // CONST ADDED HERE

   if (length == 0) // NO TYPO POSSIBLE
      printf("\"%s\" length is %i\n", p, length) ;
   else
      printf("the string is empty\n") ;
}

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

Заключение

Обычно я вижу код, использующий нотацию if (0 == p), но без константной нотации.

Для меня это все равно, что иметь мусорное ведро для вторсырья, а другое - для неперерабатываемых, а затем, в конце концов, выбросить их в один контейнер.

Так что не повторяйте привычку к простому стилю, надеясь, что это сделает ваш код намного лучше. Не будет. По возможности используйте языковые конструкции, что означает, в данном случае, использование как записи if (0 == p), если она доступна, так и использования ключевого слова const в максимально возможной степени.

Условное присвоение допустимо для C и C++, и любой компилятор, который не разрешает его, не является настоящим компилятором C или C++. Я надеюсь, что любой современный язык, не предназначенный для явной совместимости с C (как был C++), сочтет это ошибкой.

Бывают случаи, когда это позволяет кратким выражениям, таким как идиоматический while (*dest++ = *src++);, копировать строку на C, но в целом это не очень полезно, и я считаю это ошибкой в ​​языковом дизайне. По моему опыту, эту ошибку легко сделать и трудно обнаружить, если компилятор не выдает предупреждения.

Компилятор не будет отмечать это как ошибку, потому что он действителен для C / C++. Но что вы можете сделать (по крайней мере, с Visual C++), так это поднять уровень предупреждения, чтобы он пометил его как предупреждение, а затем сказал компилятору рассматривать предупреждения как ошибки. В любом случае это хорошая практика, чтобы разработчики не игнорировали предупреждения.

Если вы на самом деле имели в виду = вместо ==, тогда вам нужно сказать об этом более четко. например

if ((x = y) != 0)

Теоретически вы должны уметь это:

if ((x = y))

чтобы отменить предупреждение, но это не всегда работает.

 if ((k==1) || (k==2)) is a conditional
 if ((k=1)  || (k=2) ) is BOTH a conditional AND an assignment statement

• Вот объяснение *

Как и большинство языков, C работает от внутреннего к внешнему в порядке приоритета операторов.

Сначала он пытается установить k равным 1, и ему это удается.

Result: k = 1 and Boolean = 'true'

Далее: устанавливает k равным 2 и успешно.

Result: k = 2 and Boolean = 'true'

Далее: он оценивает (истина || истина)

Result: k still = 2, and Boolean = true

Наконец, он разрешает условие: If (true)

  Result: k = 2 and the program takes the first branch.

За почти 30 лет программирования я не видел веской причины для использования этой конструкции, хотя, если она существует, вероятно, это связано с необходимостью намеренно запутать ваш код.

Когда у кого-то из наших новых людей возникает проблема, это одна из вещей, которую я ищу, наряду с тем, чтобы не наклеивать терминатор на строку и копировать оператор отладки из одного места в другое и не менять '% i на' % s 'для соответствия новому выгружаемому полю.

Это довольно распространено в нашем магазине, потому что мы постоянно переключаемся между C и Oracle PL / SQL; if (k = 1) ЕСТЬ правильный синтаксис в PL / SQL.

Образец RegEx

RegEx r;

if (((r = new RegEx("\w*)).IsMatch()) {
   // ... do something here
}
else if ((r = new RegEx("\d*")).IsMatch()) {
   // ... do something here
}

назначить тест ценности

int i = 0;
if ((i = 1) == 1) {
   // 1 is equal to i that was assigned to a int value 1
}
else {
   // ?
}