Замыкание накоротко логических операторов передано под мандат? И порядок оценки?
Если вы проверите свои журналы, то увидите, что ваш параметр locale не входит в область действия user. Я переформатировал эту строку:
Parameters: {
"utf8"=>"✓",
"authenticity_token"=>"...",
"user"=>{
"email"=>"testytesty@testytesty1.com",
"password"=>"[FILTERED]",
"password_confirmation"=>"[FILTERED]"
},
"locale"=>"sv",
"commit"=>"Sign up"
}
Итак, вы должны добавить ее в user группу параметров.
Как я понимаю, это произошло потому, что вы не связали это с формой. Вы должны использовать f.select вместо select_tag в вашей форме.
6 ответов
Да, замыкание накоротко и порядок оценки требуется для операторов || и && и в C и в стандартах C++.
в стандарте C++ говорится (должен быть эквивалентный пункт в стандарте C):
1.9.18
В оценке следующих выражений
a && b a || b a ? b : c a , bиспользование встроенного значения операторов в этих выражениях, существует точка последовательности после оценки первого выражения (12).
В C++ существует дополнительное прерывание: замыкание накоротко делает НЕ , относятся к типам что операторы || и &&.
Сноска 12: операторы, обозначенные в этом абзаце, являются встроенными операторами, как описано в пункте 5. Когда один из этих операторов перегружается (пункт 13) в допустимом контексте, таким образом определяя пользовательскую функцию оператора, выражение определяет вызов функции, и операнды формируют список аргументов, без подразумеваемой точки последовательности между ними.
обычно не рекомендуется перегрузить эти операторы в C++, если у Вас нет очень конкретного требования. Можно сделать это, но это может повредить ожидаемое поведение в чужом коде, особенно если эти операторы используются косвенно через инстанцирование шаблонов с типом, перегружающим эти операторы.
Оценка короткого замыкания и порядок оценки, являются переданным под мандат семантическим стандартом и в C и в C++.
, Если бы это не было, код как это не был бы общей идиомой
char* pChar = 0;
// some actions which may or may not set pChar to something
if ((pChar != 0) && (*pChar != '\0')) {
// do something useful
}
Раздел , 6.5.13 Логических операций И из спецификации C99 (ссылка PDF) говорят
(4). В отличие от поразрядного двоичного файла & оператор, & & оператор гарантирует слева направо оценку; существует точка последовательности после оценки первого операнда. Если первый операнд выдерживает сравнение равный 0, второй операнд не оценен.
Точно так же раздел 6.5.14 Логических операций ИЛИ говорят
(4) В отличие от поразрядного | оператор, || гарантии оператора слева направо оценка; существует точка последовательности после оценки первого операнда. Если первый операнд выдерживает сравнение неравный 0, второй операнд не оценен.
Подобная формулировка может быть найдена в стандартах C++, раздел проверки 5.14 в этой черновой копии . Как средства проверки отмечает в другом ответе, если Вы переопределяете & & или ||, тогда оба операнда должны быть оценены, поскольку это становится вызовом регулярной функции.
Да, это передает под мандат это (и порядок оценки и короткое замыкание). В Вашем примере, если все функции возвращают true, порядок вызовов строго от functionA тогда functionB и затем functionC. Используемый для этого как [1 123]
if(ptr && ptr->value) {
...
}
То же для оператора запятой:
// calls a, then b and evaluates to the value returned by b
// which is used to initialize c
int c = (a(), b());
Каждый говорит между левым и правым операндом &&, ||, , и между первым и вторым/третьим операндом ?: (условный оператор) "точка последовательности". Любые побочные эффекты оценены полностью перед той точкой. Так, это безопасно:
int a = 0;
int b = (a++, a); // b initialized with 1, and a is 1
Примечание, что оператор запятой не должен быть перепутан с синтаксической запятой, используемой для разделения вещей:
// order of calls to a and b is unspecified!
function(a(), b());
в Стандарте C++ говорится в 5.14/1:
& & группы оператора слева направо. Операнды оба неявно преобразовываются для ввода bool (пункт 4). Результат верен, если оба операнда являются истиной и ложью иначе. В отличие от & & & гарантии слева направо оценка: второй операнд не оценен, если первый операнд является ложью.
И в 5.15/1:
|| группы оператора слева направо. Операнды оба неявно преобразовываются в bool (пункт 4). Это возвращает true, если любой из его операндов является верным, и ложным иначе. В отличие от этого, |, || гарантирует слева направо оценку; кроме того, второй операнд не оценен, если первый операнд оценивает к истинному.
Это говорит для обоих рядом с теми:
результатом является bool. Все побочные эффекты первого выражения за исключением разрушения временных файлов (12.2) происходят, прежде чем второе выражение оценено.
, В дополнение к которому, 1.9/18 говорит
В оценке каждого из выражений
a && ba || ba ? b : Ca , bиспользование встроенного значения операторов в этих выражениях (5.14, 5.15, 5.16, 5.18), существует точка последовательности после оценки первого выражения.
Прямо от старого доброго K& R:
C гарантирует, что
&&и||оценены слева направо —, мы будем скоро видеть случаи, где это имеет значение.
Если Вы доверяете Википедии:
[
&&и||] семантически отличны от побитовых операторов & и |, потому что они никогда не будут оценивать правильный операнд, если результат может быть определен слева один
Будьте очень очень осторожны.
Для фундаментальных типов это операторы ярлыка.
, Но если Вы определяете эти операторы для своего собственного класса или перечисляемых типов, они не ярлык. Из-за этого семантического различия в их использовании при этих различных обстоятельствах рекомендуется не определить эти операторы.
Для operator && и operator || для фундаментальных типов порядок оценки слева направо (в других отношениях короткое вырезание было бы твердым:-), Но для перегруженных операторов, которые Вы определяете, это в основном синтаксический сахар к определению метода, и таким образом порядок оценки параметров не определен.