С сильно типизирован? - PullRequest
       77

С сильно типизирован?

73 голосов
/ 10 января 2009

Цитировать Википедия :

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

Есть ли более точный ответ?

Ответы [ 17 ]

1 голос
/ 06 сентября 2010

c слабо напечатано, b - без шрифта.

1 голос
/ 10 января 2009

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

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

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

0 голосов
/ 10 января 2009

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

0 голосов
/ 10 января 2009

В чем причина вашего запроса? Причина, по которой я спрашиваю, заключается в том, что это своего рода незначительная разница, и ваше конкретное использование «строго типизированного» может потребовать более или менее разъяснения. Я бы определенно сказал, что Java и другие языки имеют более жесткие ограничения на неявный диалог типов.

0 голосов
/ 10 января 2009

Не сильно напечатано.

Рассмотрим, что говорит вам следующий прототип функции о типах данных аргументов:

void func (int n, char ch, ...);

Ничего. Поэтому я предлагаю, чтобы строгая типизация здесь не применялась.

0 голосов
/ 10 января 2009

Я бы сказал, что это строго типы, поскольку каждое выражение имеет тип, который не является функцией его значения; E.I. это может быть известно до выполнения.

OTOH Я не уверен, что это правильное описание строго типизированных. Единственное более сильное утверждение, которое я вижу в качестве причины для выбора языка, - это уверенность в том, что вы не можете подорвать систему типов во время выполнения посредством переосмысления приведений типов, объединений, вызовов на другие языки, указателей, языка ассемблера и т. П. существуют, но настолько повреждены, что, кажется, они не представляют большого интереса для программистов за пределами высокого уровня уверенности и научного сообщества. Как указывалось кем-то, чтобы действительно сделать это правильно, вы начинаете нуждаться в таких типах, как nonZeroInt и еще много чего. Тьфу.

0 голосов
/ 10 января 2009

Я бы сказал, что C написан строго так, как требует ваш компилятор / платформа. Например, если вы строите на строгой платформе, разыменование перенаправленного указателя типа, скорее всего, сломается:

void m_free(void **p)
{
        if (*p != NULL) {
                free(*p);
                *p = NULL;
        }
}

....
char *str = strdup("foo");
m_free((void **) &foo);

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

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

...