Объявления указателей: T* e vs. T *e vs. T * e [C]

[aa_dav]

Munin в сообщении #1017836 писал(а):

Кажется, Си обзавёлся уже ссылками, так что можно ссылку на массив.

Ну в сущности примера это ничего бы не поменяло, только при выводе значений было бы меньше писанины, а всё что выше вместо некоторых * стало бы & и всё.

[arseniiv]

aa_dav в сообщении #1017654 писал(а):

Ответ: в декларациях функций.
Например

void f(int(*)(int,int));

Ясно. Жалко только, что если аргумент как-нибудь захотеть здесь назвать, всё портится (так что в моём понимании это всё равно гипотенуза ).

[aa_dav]

arseniiv в сообщении #1017990 писал(а):

Жалко только, что если аргумент как-нибудь захотеть здесь назвать, всё портится (так что в моём понимании это всё равно гипотенуза ).

А, сейчас вспомнил другой пример - конвертация типов - (type)value; То же самое - type в принципе можно сделать чем угодно. Так что парсер "выражения типа тип" и для голого Си вполне естественнен и употребляется довольно часто.

[arseniiv]

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

[aa_dav]

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

arseniiv в сообщении #1018192 писал(а):

Видимо, значит, у создателей было недостаточно времени на последовательность

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

int a[size];

чтобы функции были

int func(int arg);

Отсюда "правосторонний приоритет скобок".
Альтернатива привела бы к достаточно уродливой даже сейчас форме:

int(int arg) func;

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

[iifat]

Вот только не надо о читаемости. Смею вас уверить, PROC (REAL, INT) REAL f = (REAL a, INT n) REAL: a^n вполне себе читабельно.

[aa_dav]

iifat в сообщении #1029537 писал(а):

Вот только не надо о читаемости. Смею вас уверить, PROC (REAL, INT) REAL f = (REAL a, INT n) REAL: a^n вполне себе читабельно.

Не, я не спорю что это дело привычки. :) Но запись array[x] и func(args) как то всё же более привычна среди именно что широких слоёв населения.
При этом в том же С++ мы в конечном итоге, после кучи прочих штук сейчас так и пишем:

Используется синтаксис C++

std::function<float(float,int)> f = [](float a, int n) ->float { return pow(a,n); };
 

Если присмотрется, то вдруг, внезапно - почти всё на тех же местах. %) Несмотря на то, откуда всё начиналось.

[Munin]

iifat в сообщении #1029537 писал(а):

Вот только не надо о читаемости. Смею вас уверить, PROC (REAL, INT) REAL f = (REAL a, INT n) REAL: a^n вполне себе читабельно.

А это на чём?

(Оффтоп)

iifat
aa_dav
By the way, use [ tt ] please. It was specially made to be like the in-line [ code ] alternative.

[aa_dav]

Munin в сообщении #1029579 писал(а):

А это на чём?

Судя по гуглу - Алгол 68 (именно 68).

[arseniiv]

aa_dav в сообщении #1029530 писал(а):

Но с функциями.... не не не. А это некоторая потеря целостности, если иначе.

Не сказал бы, что так, если вы имели потерю целостности в использовании как тип(типы) f = что-то-1, так и тип f(аргументы) что-то-2, даже если синтаксис точно такой. И использовать один вариант в одних случаях, а другой в других — это тоже не всегда страшно. Только не могу сейчас вынести какого-то общего суждения о том, когда это приемлемо, а когда нет.

[_Ivana]

С позиции дилетанта выскажу 2 мнения -
1) синтаксис языка стоит далеко не на первом месте в списке важных характеризующих его вещей
2) если для автоматической кодогенерации или разбора какой-либо синтаксис удобнее, то его и имеет смысл использовать. Все эти антропоориентированные вдолбленные с начальной школы синтаксисы инфиксных бинарных операций при префиксных унарных и прочей арности, таблицы приоритетов и учитывающие их деревья разборов или сортировочные станции это конечно хорошо, но когда я задумал реализовать свой интерпретатор, то выбрал префиксный бесприоритетный синтаксис Лисп по многим факторам, в которых он предпочтительнее. (Кто вдруг не знает, во многих текстовых редакторах есть паредит или его аналоги, а подсветка парных скобок существует в еще большем количестве редакторов)

[aa_dav]

arseniiv в сообщении #1029755 писал(а):

Не сказал бы, что так, если вы имели потерю целостности в использовании как тип(типы) f = что-то-1, так и тип f(аргументы) что-то-2

Да не надо так глубоко копать.
Просто есть необходимость писать функции. Уже в корнях есть примеры что оно привычно записываться должно как
name(args)
то же самое с массивами, т.к. просто привычная запись. Если идея поставить "телегу впереди лошади" и всплывала, по аналогии с какими нибудь Алгол-68, то я думаю она как раз была быстро подавлена - ну непривычно и всё тут.
И если идти этим путём, то к системе типов С/С++ вы придёте автоматически.

-- 22.06.2015, 21:27 --

_Ivana в сообщении #1029760 писал(а):

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

Ну вот с этим многие как раз чаще всего не согласны. Всякие форты были как раз экзотикой.
Семейство Си можно сказать даже как то атипично вклинилось - синтаксис после паскалей и бейсиков выглядит с налётом эзотеричности. Но даже он всё равно не терял изрядной доли "классичности", как мы видим.

[_Ivana]

aa_dav в сообщении #1029764 писал(а):

И если идти этим путём, то к системе типов С/С++ вы придёте автоматически.

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

aa_dav в сообщении #1029764 писал(а):

Ну вот с этим многие как раз чаще всего не согласны.

Это не новость и не трагедия. И уж тем более не повод менять точку зрения.

[Munin]

_Ivana в сообщении #1029760 писал(а):

1) синтаксис языка стоит далеко не на первом месте в списке важных характеризующих его вещей

Как ни странно, в числе первых.

Не надо недооценивать банальную удобность. Она презирается, её называют syntactic sugar и ещё по-разному, но она даёт огромный прирост эффективности работы с нотацией - хотя и очень слабоформализуемый, "одному нравится арбуз, а другому - свиной хрящик".

Не удивлюсь, если начальный всплеск популярности Си, и потом начальный всплеск популярности C++ - обязаны именно удачной нотации (в том числе). Ну и наверняка, среди функциональных языков Haskell-оподобные по внешнему виду - популярнее LISP-подобных.

[arseniiv]

Раз уж речь зашла о удобстве интерфейса vs. реализации, добавлю (банальное и) неутешительное #itscomplicated:

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

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

Т. е. все правы кроме крайних.

(Оффтоп)

Munin в сообщении #1029784 писал(а):

её называют syntactic sugar

К слову, если fancy thing — это единственный вариант описания, а не синоним какого-то ещё «канонического», её звать сахаром не будут.