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.