Действительно ли C со строгим контролем типов?

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

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

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

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

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

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

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

Не со строгим контролем типов.

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

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

Ничто. Таким образом, я предполагаю, что строгий контроль типов не применяется здесь.

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

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

Много хороших ответов здесь. Я хочу поднять важный момент от реальный мир Haskell :

полезно знать, что у многих сообществ языка есть свои собственные определения “strong type”. Тем не менее, мы будем говорить кратко и в общих чертах о понятии силы в системах типов.

(надрез)

фейерверки вокруг систем типов имеют свои корни на обычном английском языке, где люди присоединяют понятия значения к словам “weak” и “strong”: мы обычно думаем о силе как лучше, чем слабость. Намного больше программистов говорит на простом английском языке, чем академический жаргон, и довольно часто академики действительно бросают резкие замечания в любую систему типов, не удовлетворяет их воображению. Результат часто в том состоит что популярное интернет-времяпрепровождение, война пламени.

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

По-моему, C/C++ со строгим контролем типов. Тип взломов, которые позволяют типам быть преобразованными (пусто*) там из-за близости C с машиной. Другими словами, можно назвать ассемблерные команды от Паскаля и управлять указателями, и Паскаль все еще рассматривается как язык со строгим контролем типов. Можно назвать ассемблер и исполняемые файлы C от Java до JNI, но это не делает Java со слабым контролем типов.

C просто имеет ассемблер, "встроенный" в него с необработанными указателями и таким.

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

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

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

C считают со статическим контролем типов (у Вас не может быть переменного изменения от интервала для плавания). Как только переменная объявляется, она застревает тот путь.

, Но это считают со слабым контролем типов, потому что типы могут быть переброшенным зеркальным отражением.

, Что 0? '\0', ЛОЖЬ, 0.0, и т.д.

на многих языках Вы не можете сказать, ЕСЛИ (переменная), потому что условия только примут булевы значения от булевых выражений. Они более со строгим контролем типов. То же относится к движению между символами и целыми числами.

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

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

, Но можно утверждать, что по сравнению с Perl C со строгим контролем типов. Таким образом, это - один из тех известных аргументов (vi по сравнению с emacs, Linux по сравнению с окнами, и т.д.). C# более силен введенный, чем C. В основном можно спорить так или иначе. И Ваши ответы, вероятно, пойдут обоими путями:) Также в некоторых учебниках/веб-страницах будет сказано, что C со слабым контролем типов, и некоторые скажут, что C со строгим контролем типов. Если Вы переходите к Википедии, запись C говорит "частично слабый контроль типов". Я сказал бы по сравнению с Python C, со слабым контролем типов. Так Python/C#, C, Perl на континууме.

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

Литература не соглашается с этим. Я думаю, что со строгим контролем типов не да/нет, существуют различные степени строгого контроля типов.

язык программирования А имеет спецификацию того, как он выполняет программы. Иногда не ясно, как выполниться с определенными программами. Например, программы, которые пытаются вычесть строку из числа. Или программы, которые делятся на нуль. Существует несколько способов иметь дело с этими условиями. Некоторые языки имеют правила для контакта с этими ошибками (например, они выдают исключение). Другие языки просто не имеют правил справиться с этими ситуациями. Те языки обычно имеют системы типов для предотвращения программ компиляции, которые приводят к неуказанному поведению. И там также существуют языки, которые имеют неуказанное поведение и не имеют системы типов для предотвращения этих ошибок во время компиляции (если Вы пишете программу, которая поражает неуказанное поведение, это могло бы запустить ракеты).

Так:

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

, Также - действительно ли Java со статическим контролем типов? Да, потому что его система типов запрещает вычитание строки от числа. Нет, потому что это позволяет Вам делиться на нуль. Вы могли предотвратить деление на нуль во время компиляции с системой типов. Например, путем создания типа числа, который не может быть нулем (например, NonZeroInt), и только позволить делиться на числа, которые имеют этот тип.

Так C со строгим контролем типов или со слабым контролем типов? C со строгим контролем типов, потому что система типов запрещает некоторые ошибки типа. Но это со слабым контролем типов в других случаях, когда это не определено, что происходит (и система типов не защищает Вас).

C более со строгим контролем типов, чем JavaScript и менее со строгим контролем типов, чем Ada.

я сказал бы, что это больше попадает в сторону со строгим контролем типов континуума. но кто-то еще мог бы не согласиться (даже если они неправы).

, Как это для категорического?

Термин со строгим контролем типов не имеет согласованного определением. Поэтому, если Вы не определяете то, что Вы средний "со строгим контролем типов", невозможно ответить на Ваш вопрос.

, По моему опыту, термины, "со строгим контролем типов" и "со слабым контролем типов", используются исключительно сообщениями-розыгрышами, потому что их отсутствие определений позволяет сообщениям-розыгрышам переопределять их середина аргумента для удовлетворения их программе. Кроме для запуска flamewars, эти условия в значительной степени бесполезны.

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

Трудно классифицировать каждый язык в 'слабо' или 'сильно' введенный - это - больше континуума. Но по сравнению с другими языками C довольно со строгим контролем типов. Каждый объект имеет тип времени компиляции, и компилятор сообщит (громко) при выполнении чего-то с объектом, который его тип не позволяет Вам сделать. Например, Вы не можете вызвать функции с неправильными типами параметров, структура/члены профсоюза доступа, которые не существуют, и т.д.

, Но существует несколько слабых мест. Одна главная слабость является преобразованиями типа - они по существу говорят, что Вы собираетесь быть слоняющимися без дела с типами объектов, и компилятор должен быть тихим (когда это может). void* также другая слабость - это - универсальный указатель на неизвестный тип, и когда Вы используете их, необходимо быть дополнительны осторожный, что Вы делаете правильную вещь. Компилятор не может статически проверить большую часть использования void*. void* может также быть преобразован в указатель на любой тип без броска (только в C, не в C++), который является другой слабостью.