нету

нету

Я имел ввиду С++ , а не просто С
просто не обратил внимания на то что в том посте без плюсов

PS многие здесь программируют на чистом си без плюсов?

Beltar

Помогает, когда у функции много параметров, а указать надо лишь часть. И читается в таком случае лучше.

Это сообщение отредактировал(а) Void - 8.2.2007, 19:07

Но в Delphi тоже можно:
function f(X:Integer;Y:Integer=1):Integer;

И вызывать можно f(x) и f(x,y).

В чем разница?

Попробую словами: при вызове функции опциональные (строго говоря, не только) аргументы можно указывать в произвольном порядке с помощью синтаксиса <имя параметра> = <значение>.

Теперь понятно.

пример можно

Про именованные аргументы Страуструп писал в D&E

Это было предложение Роланда Хартингера

Причина отклонения: группа по расширениям единодушно решила,
что предложение не даёт почти ничего нового,
приведёт к несовместимости с существующим кодом
и будет способствовать распространению неудачного стила программирования

Там есть и альтернативы именованным аргументам,
например, дополнительные типы для представления наиболее типичных вариантов

Void, а ну марш покупать и читать D&E! 




Это сообщение отредактировал(а) SergeCpp - 8.2.2007, 20:59

Я Страуструпа уважаю (а вопросы обратной совместимости уважать себя просто заставляют  ), но подход с реализацией всего что только можно через библиотеки, не трогая ядро языка, и то, во что он [подход] превратил нынешний C++, как-то не очень… На когда-то желанный C++0x теперь приходится смотреть с опаской.

Alexander Stepanov — Notes on Programming (примерно 900 K)

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


Естьboost::parameter. Не вглядывался в реализацию, но использование достаточно приятно, правда редко нужно.

Насчёт рестрикта - ещё пару слов. Как таковой он должен применяться не к конкретному указателю, а к их парам. Если функция принимает два параметра, то здесь всё понятно (хотя нелогично к какому именно указателю ставить рестрикт). Но допустим, что у функции три параметра. Между двумя первыми гарантировано соблюдение рестрикта, а вот третий может "вклиниться" в любой из первых двух. Вполне возможно, что однако (теоретически) возможна оптимизация. Возможно, что третий указатель, нужен для просто задания элемента (не из массива). То есть существующий синтаксис рестрикта нелогично описывает ситуацию. Получается мы гарантируем отсутствие алиасов с любыми другими указателями - это возможно очень редко.

Кстати,

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

Это сообщение отредактировал(а) Artemios - 9.2.2007, 11:30

какой-то странный уровень поддержки   
если что то игнорируется в GCC (например export), то warning соответствующий появляется

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

Последняя stable версия Perl (5.8.8). Начало одной из функций файла util.c

Дата модификации файла: 9 января 2006