Что Безопасно с точки зрения типов?

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

Некоторые простые примеры:

// Fails, Trying to put an integer in a string
String one = 1;
// Also fails.
int foo = "bar";

Это также относится к аргументам метода, так как Вы передаете явные типы им:

int AddTwoNumbers(int a, int b)
{
    return a + b;
}

, Если я пытался назвать то использование:

int Sum = AddTwoNumbers(5, "5");

компилятор бросил бы ошибку, потому что я передаю строку ("5"), и он ожидает целое число.

На свободно типизированном языке, таком как JavaScript, я могу сделать следующее:

function AddTwoNumbers(a, b)
{
    return a + b;
}

, если я называю его как это:

Sum = AddTwoNumbers(5, "5");

JavaScript автоматически преобразовывает 5 в строку и возвращается "55". Это происходит из-за JavaScript с помощью +, расписываются за конкатенацию строк. Для создания его осведомленным о типе необходимо было бы сделать что-то как:

function AddTwoNumbers(a, b)
{
    return Number(a) + Number(b);
}

Или, возможно:

function AddOnlyTwoNumbers(a, b)
{
    if (isNaN(a) || isNaN(b))
        return false;
    return Number(a) + Number(b);
}

, если я называю его как это:

Sum = AddTwoNumbers(5, " dogs");

JavaScript автоматически преобразовывает 5 в строку и добавляет их, для возврата "5 собак".

Не все динамические языки являются столь же прощающими как JavaScript (На самом деле, динамический язык не делает implicity, подразумевают свободный типизированный язык (см. Python)), некоторые из них на самом деле дадут Вам ошибку периода выполнения на недопустимом преобразовании типа.

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

Теперь, назад к C#...

C# поддерживает функцию языка, названную ковариантность , это в основном означает, что можно заменить базовым типом дочерний тип и не вызвать ошибку, например:

 public class Foo : Bar
 {
 }

Здесь, я создал новый класс (Нечто), которое разделяет Панель на подклассы. Я могу теперь создать метод:

 void DoSomething(Bar myBar)

И вызов это с помощью или Нечто или Панели как аргумент, оба будут работать, не вызывая ошибку. Это работает, потому что C# знает, что любой дочерний класс Панели реализует интерфейс Панели.

Однако Вы не можете сделать инверсии:

void DoSomething(Foo myFoo)

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

, Конечно, теперь я пошел путем от глубины и вне объема исходного вопроса, но его всего хорошего материала для знания:)

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

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

Много безопасных с точки зрения типов языков дают иллюзию "безопасности типов", настаивая на том, чтобы строго определять типы для переменных и только позволять переменной быть присвоенными значениями того же "типа". Существует несколько проблем с этим подходом. Например, программа может иметь переменную "yearOfBirth", который является годом, человек родился, и заманчиво преобразовать тип его как короткого целого. Однако это не короткое целое. В этом году это - число, которое является меньше, чем 2009 и больше, чем-10000. Однако этот набор растет на 1 каждый год как прогоны программы. При создании этого не соответствует "короткое целое". То, что необходимо для создания этой переменной безопасной с точки зрения типов, является функцией проверки во время выполнения, которая гарантирует, что число всегда больше, чем-10000 и меньше, чем следующий календарный год. Нет никакого компилятора, который может осуществить такие критерии, потому что эти критерии всегда являются уникальными характеристиками проблемной области.

Языки, которые используют динамический контроль типов (или ввод утки или ввод декларации), такой как Perl, Python, Ruby, SQLite и Lua, не имеют понятия переменных определенного типа. Это вынуждает программиста записать стандартную программу проверки во время выполнения для каждой переменной, чтобы гарантировать, что это корректно, или вынесите последствия необъясненных исключений на этапе выполнения. По моему опыту, программисты на статически типизированных языках, таких как C, C++, Java и C# часто убаюкиваются в размышление, которое статически определило типы, все, что они должны сделать для извлечения пользы из безопасности типов. Это просто не верно для многих полезных компьютерных программ, и трудно предсказать, верно ли это для какой-либо конкретной компьютерной программы.

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

Безопасный с точки зрения типов означает, что программно, тип данных для переменной, возвращаемого значения или аргумента должен соответствовать в определенные критерии.

На практике, это означает, что 7 (целый тип) отличается от "7" (заключенный в кавычки символ строкового типа).

PHP, JavaScript и другие динамические языки сценариев обычно со слабым контролем типов, в котором они преобразуют (строка) "7" к (целому числу) 7, при попытке добавить "7" + 3, хотя иногда необходимо сделать это явно (и JavaScript использует "+" символ для конкатенации).

C/C ++/Java не поймет, что, или свяжет результат в "73" вместо этого. Безопасность с точки зрения типов предотвращает эти типы ошибок в коде путем создания требования типа явным.

Безопасность с точки зрения типов очень полезна. Решение вышеупомянутого "7" + 3 состояло бы в том, чтобы ввести бросок (интервал) "7" + 3 (равняется 10).

Примерьте это объяснение...

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

Для небезопасного с точки зрения типов поведения, рассмотрите это:

object x = 89;
int y;

, при попытке сделать это:

y = x;

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

y = Convert.ToInt32( x );

присвоение выше не безопасно с точки зрения типов. Безопасный с точки зрения типов assignement - то, где типы могут непосредственно быть присвоены друг другу.

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

, Например:

Session[ "x" ] = 34;

хорошо работает. Но присваивать целочисленное значение назад, Вы должны будете:

int i = Convert.ToInt32( Session[ "x" ] );

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

C# является безопасным с точки зрения типов языком, но часами для статей о C# 4.0; интересные динамические возможности вырисовываются (он хорошая вещь, что C# по существу получает Строгую Опцию: Прочь... мы будем видеть).

Много ответов здесь соединяют безопасность типов со статическим контролем типов и динамическим контролем типов. Динамически типизированный язык (как smalltalk) может быть безопасным с точки зрения типов также.

А короткий ответ: язык считают безопасным с точки зрения типов, если никакая операция не приводит к неопределенному поведению. Многие считают требование явных преобразований типов необходимым для языка, чтобы быть строго введены, поскольку автоматические преобразования могут иногда приводить к четко определенным но неожиданным/неинтуитивным поведениям.

Объяснение от главные гуманитарные науки, не главная наука аккомпанемента:

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

, Например, в C#, я определяю функцию как:

 void foo(int arg)

компилятор будет тогда мешать мне делать это:

  // call foo
  foo("hello world")

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

Безопасные с точки зрения типов языки пытаются поймать больше во "время компиляции".

На вниз стороне, с безопасными с точки зрения типов языками, когда у Вас есть строка как "123" и Вы хотите воздействовать на нее как интервал, необходимо записать больше кода для преобразования строки в интервал, или когда Вы имеете интервал как 123 и хотите использовать его в сообщении как, "Ответ равняется 123", необходимо записать больше кода для преобразовывания/бросания ее в строку.