для и цикл с условием продолжения в c#
попробуйте использовать empty так:
@if(!empty($estate->piano)) //do_someThisng @else //do_something_or_nothing @endif
, если вы хотите сделать это в контроллере
foreach($estate as $e)
{
if($e == null)
{
unset($estate[$s]);
}
}
Я надеюсь, что этот код работает для вас, я использовал его для чего-то иначе, но похоже на вашу работу, но я не знаю, работает ли это таким образом или нет.
6 ответов
(обновление) На самом деле - существует один сценарий, где эти for конструкция более эффективна; цикличное выполнение на массиве. Компилятор/JIT имеет оптимизации для этого сценария , пока Вы используете arr.Length в условии :
for(int i = 0 ; i < arr.Length ; i++) {
Console.WriteLine(arr[i]); // skips bounds check
}
В этом очень конкретном случае, это пропускает проверку границ, поскольку это уже знает, что никогда не будет выходить за пределы. Интересно, если Вы "поднимаете" arr.Length, чтобы попытаться оптимизировать его вручную, Вы предотвращаете это:
int len = arr.Length;
for(int i = 0 ; i < len ; i++) {
Console.WriteLine(arr[i]); // performs bounds check
}
Однако с другими контейнерами (List<T> и т.д.), подъем довольно разумен как ручная микрооптимизация.
(заканчивают обновление)
<час>Ни один; для цикла оценен как некоторое время цикл под капотом так или иначе.
, Например, 12.3.3.9 из ECMA 334 (определенное присвоение) диктует что для цикла:
for ( for-initializer ; for-condition ; for-iterator ) embedded-statement
чрезвычайно эквивалентно (от Определенное присвоение перспектива (не совсем, то же, что "компилятор должно генерировать этот IL")), как:
{
for-initializer ;
while ( for-condition ) {
embedded-statement ;
LLoop:
for-iterator ;
}
}
с продолжают операторы, которые предназначаются для оператора, переводимого в операторы перехода, предназначающиеся для маркировать LLoop. Если для условия опущен от для оператора, то оценка определенных доходов присвоения, как будто для условия были заменены истинным в вышеупомянутом расширении.
Теперь, это не означает, что компилятор должен сделать точно то же самое, но в действительности это в значительной степени делает...
Я сказал бы, что они - то же, и Вы никогда не должны делать такой микрооптимизации так или иначе.
Эффективность программы прибывает из надлежащих алгоритмов, хорошего объектного дизайна, умной архитектуры программы, и т.д.
, Бритье цикла или два с для циклов по сравнению с циклами с условием продолжения никогда не будет делать медленную программу быстро или быструю программу медленной.
, Если Вы хотите улучшить производительность программы в этом разделе, найдите, что путь к любому частично разворачивает цикл (см. Устройство Вареного пудинга ), или улучшите производительность того, что сделано в цикле.
Производительность будет тем же. Однако, если Вы не должны получать доступ i переменная вне цикла затем, необходимо использовать for цикл. Это будет более чисто, так как i будет только иметь объем в блоке.
Никакой. Они эквивалентны. Можно думать 'для' цикла, являющегося более компактным способом записать цикл с условием продолжения.