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

В двух словах, что это такое? Вот я пользуюсь с, с++ и bash в основном, хз, есть там "вывод типа" или нет...

djamshud, 

http://ru.wikipedia.org/wiki/%D0%92%D1%8B%...%BF%D0%BE%D0%B2






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

Vasay, tnx!

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

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

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

k0rvin, 



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

djamshud, ты видимо кодишь не на С++, а на С с классами

попробуй объявить переменную с типом результата boost.bind например
какбэ не всегда программисту известен тип того с чем он работает

попробуй Haskell или OCaml

k0rvin, 

Может все же приведешь конкретный пример, где это может быть полезно?

что значит где? везде в коде

Vasay, 

k0rvin, 



Это не ответ на вопрос - "А чем это удобно?"  

>попробуй Haskell или OCaml

Какое отношение с++ имеет к этой функциональщине? С++ решает _другие_ задачи, вот нагородили вокруг него монстров вроде буста, а потом ревут "с++ мостроузное ###, да на лиспе я это в пару десятков скобок заколбашу!". Достала школота.

GoldFinch, про буст уже написал. А пишу я на и на С, и на С++, с классами, шаблонами, покером, куртизанками и прочими ништяками, но решаю задачи средствами языка, а не нагороженных вокруг него костылей. И да, я наверное не программист, раз всегда знаю типы того, с чем работаю.

Это был пример плохо читаемого кода, вводящего в ступор  механизм подсказок IDE?

Или, Вы хотели сказать этим что-то другое?

Это сообщение отредактировал(а) Vasay - 15.5.2010, 12:05

ты и не задавал такой вопрос

Добавлено @ 12:10

никакого. давай так: какое отношение С++ имеет к моему посту, в котором я привёл пример языков с хорошо реализованным выводом типов?

Это сообщение отредактировал(а) k0rvin - 15.5.2010, 12:12

Вы невнимательны:

http://forum.vingrad.ru/index.php?showtopi...t&p=2153052




Причем, вдвойне:

k0rvin, кончай вилять. Или ответь уже кому-нибудь по существу, или сливайся.

еще как внимателен: 

здесь только "где?": http://forum.vingrad.ru/index.php?showtopi...t&p=2153073

ни слова про С++: http://forum.vingrad.ru/index.php?showtopi...t&p=2153052

Добавлено через 37 секунд

никто по существу ничего спросить не может

k0rvin, 

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

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

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

Добавлено @ 12:34

там присутствует костыль, а не вывод типов. у С++ слишком слабая система типов, чтобы на ней сделать нормальный вывод.

Это сообщение отредактировал(а) k0rvin - 15.5.2010, 12:46

И как следствие ухудшить  читаемость кода,  остаться без подсказок IDE по методам, вывода  ***doc-ов, а так же лишиться проверки кода на стадии написания.

Не высокая ли цена?

Это сообщение отредактировал(а) Vasay - 15.5.2010, 12:53

djamshud, Vasay, 
вы на С++ boost.bind, boost.lambda, boost.spirit видели?
первые 2 - костыли, а вот спирит не костыль

если нет, то вам "повезло", вы не юзаете ту часть С++, которую юзает большинство С++ программистов,
и вам auto и decltype в C++0x не надо.

а всем остальным - надо.

Добавлено @ 12:57
В: чем это удобно
О: тем что тип может быть слишком длинным чтобы его написать, или неизвестным вообще, или unspecified (может поменяться в дальнейшем)


Это сообщение отредактировал(а) GoldFinch - 15.5.2010, 13:04

в каком месте это ухудшит читаемость кода? куда денутся подсказки? куда денется вывод ***doc-ов? и куда денется проверка кода?
и главное: почему это все должно куда-то деться?

Это сообщение отредактировал(а) k0rvin - 15.5.2010, 13:05

GoldFinch, 



Честно - не видел, да и С++ последний раз видел много лет тому назад. Но если бы Вы привели пример - был бы благодарен.




Для решения этой проблемы существует система пакетов и хорошие IDE. 

 

Есть такое дело, однако я не уверен что "Вывод типов" - самое красивое решение данной ситуации.




ИМХО - подобного  лучше стараться избегать.

Vasay,

вот это пример типа который
1) длиный
2) неизвестный (чтобы его узнать мне пришлось сгенерить ошибку компиляции)
3) в boost.bind типы возвращаемые boost::bind() не указаны, они могут поменяться в следующей версии библиотеки

Ну, поехали...


AFAIK, в какой-то там яве (7-ой?) обещали/предлагали что-то такое:


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


Ухудшения читаемости? Ну, классический пример:


Что читаемей?

Тут, как всегда. Мы ведь уже знает тип, раз присваиваем данные этого типа. И, классическая фраза - "если и мы, и компилятор это знаем, зачем это говорить лишний раз?". Можно, конечно, сказать, что знаем не всегда:


Ну.. Что сказать? Во-первых, не всегда приемлем вывод типов. Но.. вот в конкретно данном случае - это зачастую повод подумать. Вполне может, что нам достаточно было бы возвращать из метода объект класса Base (всмысле декларировать метод, как возвращающий Base).

Далее. Время компиляции. На самом деле, компилятору всё равно необходимо понять какого типа выражение, поэтому увидев var/auto/etc. ему не проблема считать, что у переменной именно этот тип.


Средства абстракции не есть костыли  


Тут дело в другом. То, что type inference исторически появился в "функциональщине" - это.. просто исторически. По-моему, полезность каких-нибудь лямбд (если это не требует синтаксического насилия) уже никому не приходится доказывать?


Ну.. Я не буду утверждать за С++, там всегда всё было плохо с ИДЕ, но шарпу и студии var ни капли не вредит. F12 по var переходит к определению нужного типа, автокомплит работает и т. д. Короче - всё отлично с ИДЕ 

Добавлено @ 13:30

Когда говорят про "длинные типы" обычно имеют ввиду всякие темлпейты/дженерики. На самом деле, без вывода типов решение есть только в С++ (из мейнстримных языков) - это typedef. Есть using type = ... в шарпе, но это действует только в пределах одного файла.


Ты слишком строг!  На самом деле гибкость - это хорошо. У нас же не всякие руби с пайтонами - всё равно всё при компиляции увидим (если вдруг на новой версии библиотеки нет какого-то метода и пр.)  


Это сообщение отредактировал(а) Любитель - 15.5.2010, 14:54

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

>длиный
Да, бывает неприятно, но при "нормальном" для меня кодировании проблема сводится на нет typedef-ами и макросами.

>неизвестный (чтобы его узнать мне пришлось сгенерить ошибку компиляции)
Скажите спасибо используемой библиотеке костылей, палок и веревок.

>в boost.bind типы возвращаемые boost::bind() не указаны, они могут поменяться в следующей версии библиотеки 
См. предыдущий пункт.

К слову о мнимых проблемах в ИДЕ. Вот мы пишем какой-нить экспрешен (скажем, вызов метода) и ставим точку. Неужели при этом мы не увидим списка мемберов?! Но ведь мы не говорили (в данной строке) о типе выражения? Сделать тривиальный парсинг в рантайме современные ИДЕ просто обязаны. Вон для скриптовых языков пытаются сделать нормальную работу с ИДЕ (скажем, в той же студии недавно оч хвалились, что JS-ный эдитор теперь имеет виртуальную машину, чтоб заметить динамически добавляемые поля), а мы тут боимся за мирный вывод типов..

djamshud, твоя позиция понятна, но если ты не используешь полностью ни язык ни библиотеки, то что ты забыл в этой теме?
Так кто угодно может сказать "*** не нужно, потому что это плохо, потому что мне это не нужно, потому что я это не юзаю".

То что ты говоришь "поделки", "костыли, палки и веревки" - так это говорит только о том, что ты не знаешь языка, не понимаешь как он работает и как им пользоваться.
Да язык сложный, библиотеки сложные, но если не можешь с этим разобраться - то зачем это ругать? А те кто разобрались - те юзают и радуются %)

GoldFinch, я, как и все остальные наверно, в этой теме провожу время. И выражаю свою гражданскую позицию, которая заключается в том, что в изначально мощные изящные языки (я говорю все же скорее о с++, ибо он мне ближе) тянут бяки, которые безусловно хороши там, где им место, там, где они заложены в архитектуру языка. В с++ же это "костыли, палки и веревки", которые нарушают его изящную концепцию и приводят к тому, что программисты начинают думать не в терминах языка, а в терминах "костылей, палок и веревок" в то время, как задача изумительно (ИЧСХ, чаще проще) решается без них.

djamshud, по тому что ты говоришь - получается что ты не знаешь языка, 
не знаешь настолько чтобы вообще говорить о "терминах языка"

STL - это часть языка.
алгоритмы - это часть языка.
функторы которые нужны алгоритмам - тоже часть языка.
адапторы в <functional> - часть STL но, она устарела, по этому сделали boost.bind, сейчас std::tr1::bind
tr1 - это во всех смыслах часть языка

термины языка это например Callable. В С++98 это как правило подразумевает собой функтор, как правило результат bind

djamshud, знаешь ли ты такой термин языка, как адаптер?

Это сообщение отредактировал(а) GoldFinch - 15.5.2010, 14:21

>STL - это часть языка.
>алгоритмы - это часть языка.
>функторы которые нужны алгоритмам - тоже часть языка.

Да

><functional> - часть STL но, она устарела, по этому сделали boost.bind, сейчас std::tr1::bind
>tr1 - это во всех смыслах часть языка

Костыли. Которые к сожалению наверное скоро попадут в язык, но в данный момент это еще не стандарт.

>djamshud, по тому что ты говоришь - получается что ты не знаешь языка, 
>не знаешь настолько чтобы вообще говорить о "терминах языка"



Добавлено через 6 минут и 56 секунд
>djamshud, знаешь ли ты такой термин языка, как адаптер?

Я знаю такой паттерн проектирования, который никаким боком не относится к языку. Мы же говорим о языковых конструкциях.

djamshud, а про bind1st, mem_fn и еще кучу других биндеров и адаптеров ты слышал? 
это знаешь ли стандарт С++98

Добавлено @ 14:40


binders and adaptors

Это сообщение отредактировал(а) GoldFinch - 15.5.2010, 14:41

GoldFinch, я понимаю, к чему ты клонишь. Но само по себе наличие этого в стандарте с++ не делает их "правильными" в моих глазах. К сожалению библиотеки (в т.ч. стандартные) изобилуют идеями, доведенными до идиотизма. Что влечет за собой необходимость введения все новых и новых идей, которые бы обслуживали старые.

Вывод типов - добро. На подсказки IDE мне плевать - мне важно, чтобы код был читаемым, а читать его могут в любом редакторе. Новое auto в С++ - отличное улучшение, уже пользуюсь. Помимо краткости, оно ещё даёт возможности переписывать меньшее количество кода при изменении возвращаемых значений фунцкий.

Во!

Я вначале хотел сказать, что вывод типов позволяет минимизировать количество изменений при рефакторинге, но что-т подумал, что все скажут, что "фигня, моя ИДЕ итак это делает в один клик". Но, учитывая, что про С++ столько говорим - я думаю, что можно акцентировать и на этом плюсе.  

Любитель, 



В целом, я с вами согласен.

Понятно, что местами применение вывода типов будет весьма уместно. А там где неуместно - можно его и не применять.

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




И человек, который будет в дальнейшем читать этот код, будет вынужден лезть в доки класса, к которому принадлежит someObj, что бы посмотреть, что же там возвращает someMethod.  И дай бог, чтоб IDE нормально все это разбирали.


Это сообщение отредактировал(а) Vasay - 15.5.2010, 23:07

Vasay, в моей ИДЕ достаточно навести мышку на "someMethod" чтобы получить ее прототип и коммент с доками к ней (если есть)

Ещё раз. А почему этой проблемы нет, если мы не присваиваем переменной (ну мало ли) а сразу вызываем парочку методов?


Понятно, что длинная цепочка обычно просто плохочитабельная, хотя тоже зависит от подхода - есть и вполненормальные цепочечноориентированные методы, тот же LINQ на самом деле. Но сам факт - что возвращает someMethod строго говоря мы не знаем, тем не менее мы вполне можем так написать - я не вижу в этом ничего плохого.

Да, поддержка со стороны IDE нужна, опять-таки, я не говорю про С++ - там вообще всё иначе (по крайней было в моё время). Но для ИДЕ ни с цепочками, ни с "варами" проблем нет.

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

Я не в теме пока что... А к методам это применительно? т е можно написать что то типа:

По сабжу, поставил Зло, т. к. мне показалось это не совсем удобным с т. з. читабельности и не очень красивым кодом. Хотя может я изменю свое мнение, нужна практика (но так как в Java этого нет, пока ее не будет).

Это сообщение отредактировал(а) Joil - 16.5.2010, 11:14

К доступным извне - нет. К "локальным", если такое понятие есть в языке - да. В случае шарпа - это лямбды. НУ скаем, типичный пример:


p => p.Name это метод (в данном случае). С параметром типа Product и результатом типа string. Ничего явно мы не писали.

Тогда и выведение типов не поможет, оно совсем не для этого..

Добавлено через 9 минут и 46 секунд

По моему он про другое, т.е. можно ли в определении функции возвращаемый тип описывать как var / auto.
Так делать нельзя, ибо var / auto это НЕ тип, это ключевое слово языка, которое говорит компилеру, чтобы тот сам определил тип по выражению в правой части...

Это сообщение отредактировал(а) KelTron - 17.5.2010, 04:56

А чем лямбды (в случае использования их как делегатов, а не как expression tree) не являются функцией? Для которой мы не задаём (явно) возвращаемый тип. В случае какого-нибудь Nemerle можно описать и вполне себе именованную локальную функцию:


В то же время можно пользоваться и лямбдами (более похоже на шарповский вариант):


Для методов же класса (а не локальных функций) в Nemerle вывод типов принципиально не поддерживается тоже.

Для C# - определенно добро - учитывая как в .Net любят обзывать классы, да и при работе с LINQ удобно.

Хотя, по большому счету, syntactic sugar.

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

Именно об этом я и говорю, если это значило то же что и

значит я не не правильно тебя понял.


На счёт лямбд, мне кажется пример некорректен, т.к. у функции OrderBy вполне явный тип у параметра.
Мы можем написать так:

Но так нет:



Если компилятору известно, значит и программисту известно. Другое дело если ему лень посмотреть, что там функция возвращает... но тогда как он будет работать с чем то ему неизвестным... 
Хотя по моему я понял, что ты имел ввиду.. Если ты говоришь про то, что тип очень неудобен для восприятия то да, соглашусь, но это не значит, что он неизвестен, всё-таки это разные понятия. Но даже в этом случае auto не избавит от typedef-ов.

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


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


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


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

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

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

для typedef'ов есть typeof (decltype)

Да кто с этим спорит..?

Похоже мы не понимаем друг друга.. Пара вопросов для уточнения:
Разве в определении boost::bind() не указано что оно возвращает, и мы не можем написать ЧтоТо ххх = boost::bind() ?


Но вот это ЧтоТо, возвращаемое boost::bind(), ведь останется прежним?

Проголосовал за добро, но, как и любое "добро", использовать надо с осторожностью.  Что прочуствовал, поигравшись пару дней со Scala (где-то раньше читал, не могу найти  ) - не надо использовать вывод типов:

• В выражениях, где происходит присваивание константы одного из встроенных типов данных. Специфицировать тип явно:
  

  Код

  val x: Double = 0.0

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

Это сообщение отредактировал(а) kemiisto - 19.5.2010, 12:33

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



это _ЧтоТо_ зависит от того, что биндим и состоит из такой цепочки адаптеров, которую программист в уме и вычислить не сможет 



http://www.boost.org/doc/libs/1_43_0/libs/bind/bind.html :


Это сообщение отредактировал(а) mes - 19.5.2010, 13:10

Ты путаешь разные вещи. Вывод типов это не только var. Я говорил про вывод типа возвращаемого значения из локальной функции (лямбды в случае шарпа). И тип выводится из контекста использования. Это вполне себе относится к выводу типов.

В шарпе вывод типов не столь широк, как возможен в принципе. Напомню, как можно делать в том же немерле:


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

неоднозначный вопрос
в каждом случае по-разному

На счёт дженериков согласен, не учёл. Но всё равно не то же самое, тут всё-таки более "узкий" вывод..


Т.е. по сути запись вида ЧтоТо ххх = boost::bind() невозможна для смертного и единственный способ это auto xxx = boost::bind()?
Как печально..

не единственный..  
пока нет auto можно использовать boost::function  но это не отменяет нужности auto.

например бустовская реализация концепции foreach :
http://www.boost.org/doc/libs/1_42_0/boost/foreach.hpp
обратите внимание сколько завязано на auto_any..  а будь в наличие автоопределение типа все выглядило бы гораздо проще 

да чего далеко ходить вот например обход вектора векторов..

сравните с этим:

хотя конечно еще лучше будет так :




Это сообщение отредактировал(а) mes - 19.5.2010, 17:47

а еще лучше так:

да, но это уже в С++ не затолкнуть.. как в вашем случае отличить какую i использовать внешнюю или новосозданную локальную ? 


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

только новосозданную. использовать внешнюю -- дурной тон. как минимум

Добавлено через 1 минуту и 12 секунд

и каким же образом auto указывает?

Это сообщение отредактировал(а) mes - 29.5.2010, 10:40

ну дык

ну дык:

так как &i означает совсем другое..

тогда уж что то наподобие
for ( [&] i : array ) {}
но это по сути тот же авто только другими символами.. 
а зачем изобретать ? если все и  так без проблем ложится..

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

отсюда вывод: проблемы С++ в его долбанутой грамматике

а что означает &i? вроде как & -- взятие адреса?

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

 плюс подобная грамматика свойственна не только С++.. к тому же ему она досталась по наследству..