Почему C имеет различие между-> и.?

Я не думаю, что есть что-то сумасшедшее в том, что вы сказали. Используется . указатели на структуры будут работать.

Однако мне нравится тот факт, что указатели на структуры и структуры обрабатываются по-разному.

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

Рассмотрим этот фрагмент. , представьте, что он находится в середине достаточно большой функции.

s.c = 99;
f(s);

assert(s.c == 99);

В настоящее время я могу сказать, что s - это структура. Я знаю, что он будет полностью скопирован для вызова f . Я также знаю, что это assert не может сработать.

При использовании . с указателями на структуру были разрешены, я бы ничего об этом не знал, и утверждение может сработать, f может установить sc (err s-> c ) на что-то другое.

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

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

Что ж, здесь явно нет двусмысленности или предложение не могло быть сделано. Единственная проблема заключается в том, что если вы видите:

p->x = 3;

вы знаете, что p - это указатель, но если вы разрешите:

p.x = 3;

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

Что ж, определенно могут быть случаи, когда у вас есть что-то сложное, например:

(*item)->elem

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

item.elem

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

Так что да,

Да, это нормально, но это совсем не то, что действительно нужно C

Не только это нормально, но и современный стиль. И Java, и Go используют только . . Поскольку все, что не помещается в регистр, является на каком-то уровне ссылкой, различие между вещь и указатель на вещь определенно немного произвольна, по крайней мере, пока вы не дойдете до функции вызовы.

Первым эволюционным шагом было создание постфикса оператора разыменования, что, как однажды подразумевал dmr , он в какой-то момент предпочел. Паскаль делает это, поэтому у него есть p ^ .field . Единственная причина, по которой там даже является оператор -> , потому что глупо набирать (* p) .field или p [0] .field .

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

Я утверждал, что использование () для вызовов функций и [] для индексации массива неверны. Почему бы не разрешить разным реализациям экспортировать разные абстракции?

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

Что действительно нужно C, так это не совсем немного более быстрые способы написания небезопасного кода. Я не против работать на C, но руководителям проектов не нравится, когда их надежность определяется их худшим парнем, и возможно, что C действительно нуждается в безопасном диалекте, что-то вроде Cyclone или, возможно, что-то вроде Go .

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