Контракты кода в.NET 4.0, никакая радость для не допускающих NULL-значения вентиляторов ссылочных типов?

Ну, если бы они в основном независимы друг от друга, я думал бы с точки зрения:

Initialize an array of jobs pending (queue, ...) - 200 entries
Initialize an array of jobs running - empty

while (jobs still pending and queue of jobs running still has space)
    take a job off the pending queue
    launch it in background
    if (queue of jobs running is full)
        wait for a job to finish
        remove from jobs running queue
while (queue of jobs is not empty)
    wait for job to finish
    remove from jobs running queue

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

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

9
задан RobSullivan 1 October 2009 в 09:18
поделиться

4 ответа

Я думаю, что вы правы в этом. Проверка ссылок, не допускающих значения NULL, во время компиляции была убойной функцией, которую я ждал в Code Contracts, и на самом деле ее там нет.

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

int? n;

Для согласованности было бы идеально, если бы то же самое было верно для ссылочных типов. Но это нарушило бы все существующие программы на C # и поэтому не вариант. В исследовательском языке Spec # они использовали суффикс восклицательного знака для обозначения не допускающего значения NULL:

string! s = "Hello";

Как и в случае с обычными типами значений, компилятор статически проверяет, что строка ! Переменная не используется ни в одном пути кода до ее инициализации (я считаю, что Spec # требует, чтобы объявление и инициализация происходили в одном и том же операторе).

Она также запрещает присвоение null параметру эта переменная.

И, конечно же, запрещает присвоение обычной строки строке ! . Итак, как преодолеть разрыв между двумя типами шрифтов? Написав проверку:

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

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

Еще одна плохая идея из 1960-х !

Он также запрещает присвоение этой переменной null .

И, конечно же, запрещает присвоение обычной строки строке ! ]. Итак, как преодолеть разрыв между двумя типами шрифтов? Написав проверку:

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

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

Еще одна плохая идея из 1960-х !

Он также запрещает присвоение этой переменной null .

И, конечно же, запрещает присвоение обычной строки строке ! ]. Итак, как преодолеть разрыв между двумя типами шрифтов? Написав проверку:

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

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

Еще одна плохая идея из 1960-х !

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

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

Еще одна плохая идея из 1960-х !

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

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

Еще одна плохая идея из 1960-х !

20
ответ дан 4 December 2019 в 08:52
поделиться

Я не уверен, какую проблему решают "ссылочные типы, не допускающие значения NULL". Хорошо, поэтому этот код с меньшей вероятностью вызовет исключение: -

a.ToString();

Однако, скорее всего, он будет правильным , потому что он не допускает значения NULL? Каким будет начальное значение a ? Вероятно, какой-то экземпляр типа "Пустой" по умолчанию. В этом случае не будет ли это более трудным для отладки, поскольку значения, которым должны были быть присвоены значения, этого не сделали. Просто иметь какое-то поведение по умолчанию вместо того, чтобы вызывать исключение, не похоже на то, чего я хотел бы.

3
ответ дан 4 December 2019 в 08:52
поделиться

вместо использования null вы можете использовать значение по умолчанию, например string.empty, нули не нужны

-2
ответ дан 4 December 2019 в 08:52
поделиться

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

Я не слишком беспокоюсь о статической проверке, если не считать очевидного foo! = ноль; не удается, но intellisense, я думаю, был бы очень полезен в качестве подсказки для изменения намерения.

3
ответ дан 4 December 2019 в 08:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: