всем снова доброго дня.
недавно, в GCC были реализованы User-defined Literals, и я за одно решил собрать mingw на основе trunk версии исходников. для "просветиться", так сказать.

в стандарте и гугле выловил несколько примеров, и закодил такое:

все работает. вывод:

далее, увидел в стандарте такую форму записи:


и попробовал записать это так:

но получаю такую ошибку:

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

полный код:

это первый вопрос.


второй вопрос - что с этим делать, и как применять?
третий - какого типа являются объекты/переменные(?) _degrees/_func1/_var_string ?

спасибо.

Добавлено через 4 минуты и 34 секунды

кстати на вики приводится такой же пример: http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals

Это сообщение отредактировал(а) boostcoder - 9.11.2011, 13:36

На сколько я понял написанное в описании этой фичи, тебе необходимо добавить параметр в литерал _var_string...

кстати, а что значит "char..."?

чего я только туда не добавлял  

Цитата(bsa @  9.11.2011,  13:42 )

кстати, а что значит "char..."?

variadic template состоящий из переменного кол-ва чаров.

Это ужас. Такими стараниями еще чуть-чуть и они доведут С++ по уровню write-only до перла. Вот эти литералы, &&-ссылки (в следующем стандарте уже предусмотрели что-нибудь для &&&?), нагромождения в темплейтах, синтаксически ужасные лямбды... Все это очень печально.

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

  

лямбды очень даже юзабильные.


это одно из применений. вот только хочется понять всю идею.

Они полностью выбиваются из синтаксиса С++ (того, уже старого С++). ну вот пример из википедии:
Что за помесь бульдога с носорогом с++ и хаскеля? Это конечно лучше тех позорных недолямбд из буста, но все равно фу!

Опять же, дополнительные модификаторы типов параметров в []-начале лямбды, что за идиотизм? Нужно было приделывать внутри ()-параметров к каждому аргументу.

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

Это сообщение отредактировал(а) boostcoder - 9.11.2011, 14:35

Кхм, так это "настройка" замыкания. Точно не в теме  Но это же не нужно. Все "внешние" переменные, использованные в лямбде, должны автоматически замыкаться с доступом на чтение/запись. Совершенно лишние усложнения.

согласен

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



синтаксис да фу, но их теперешнее наличие   

и да это оффтопик.. 


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

Достаточно всегда захватывать по ссылке. Есть ли смысл захватывать по значению? То есть каждый раз копировать исходный объект, правильно? Просто я много пишу кода с замыканиями, и ни разу не приходило в голову, что может понадобиться семантика с копированием замкнутого объекта.

банально - существование функционального объекта инкрементирует счетчик ссылок.

Добавлено через 37 секунд
похоже, что делать с сабжем, никто не знает...

А если теперь по-русски, пожалуйста? Имеется в виду, что внутри лямбды инкрементируется замкнутая переменная? Но это же замыкание по ссылке, а не по значению... Я руководствуюсь тем, как это называется в случае аргументов функций: по ссылке - пришел int &x, по значению - пришел int x. Или тут все по-другому называется, и я опять не в теме?:(

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

насколько я понимаю, возвращаемый тип может быть любым ?

Это конечно так и так и должно быть. Но я сейчас начала тестировать.... Если я ничего не напутала, это какие-то неуклюжие, неполноценные и вообще бесполезные замыкания, работающие на стеке. Самый примитивный пример: функция foo, в ней объявлена какая-нибудь переменная xx (пусть она даже придет в качестве аргумента foo - не суть), она возвращает две лямбды: одна увеличивает xx, вторая возвращает текущее значение xx. Вот пример на лиспе:



Вот это настоящее замыкание. Теперь то, как я пыталсь воспроизвести такое поведение на С++:



Умоляю, скажите, что я что-то сделала не так, и замыкания в С++ настоящие!

с [&] обе лямбды будут ссылаться не на свои данные,
в первом случае с [=] ругается из за того что пытаетесь изменить рвалуе

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

за время жизни захваченной по ссылке отвечает программист

Добавлено через 5 минут и 53 секунды

замкнули стековую переменную.. С++ императивный язык..

Ну это понятно.

То есть замыканий в С++ не появилось. Я все больше разочаровываюсь в новом С++.

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

newbee, 
1. С++ не делает того что непросит пользователь, особенно если касается данных.. 
2. для таких случаев есть shared_ptr..

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

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

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

имхо, GC не поможет захватить стековую переменную..

доку целиком не читал, но полагаю, само понимание стековых переменных изменится.

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

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

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

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

смотря какие компиляторы.. В примере который написан выше захват идет именно стековой переменной.. 
если добавят в с++ gc, то gc-указатели будут иметь свой синтаксис.. 





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

Разве в стандарте С++ говорится, что переменная, объявленная в функции, должна лежать на стеке? Да даже если и так, могли изменить этот пунктик, все равно новый стандарт выпускали.  Программисту ведь вообще до балды, где располагается переменная, ему достаточно знать, что после выхода из функции она уничтожится[, если только не попала в замыкание].

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

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



кто то спорит с этим ? должен, но у с++ другая идеология и пока подобное не возможно.. 
я объясняю лишь почему это на текущий момент нельзя... 

Что например нельзя замыкать? Без какого разрешения? Программист сам создает замыкание с определенными переменными, засунув их в лямбду. Вот тебе и разрешение.

Это сообщение отредактировал(а) newbee - 9.11.2011, 22:11

сейчас напишу девелоперам GCC с вопросом о ситуации приведенной newbee. ведь по логике, получается правильно, если переменная попадает в список захвата, то компилятор изначально должен ее размещать не на стеке(в прямом понимании).

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

хм.. а есть ли смысл?

Неа. Пиши сразу Страуструпу 

newbee, а если захваченная  переменная  это ссылка,  то что с ней делать ? куда лепить подсчет ?

Это сообщение отредактировал(а) mes - 9.11.2011, 22:38

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

http://liveworkspace.org/code/c3dfe28c7e25...7b160ded7607854
вывод:


Добавлено через 2 минуты и 41 секунду

инкрементировать счетчик ссылок оригинальной переменной. или что?

Это сообщение отредактировал(а) boostcoder - 9.11.2011, 22:41

  какая связь между выводом адреса переменной и сохранностью стека ?!

а епс.. спать-спать-спать..

вот мне и интересно как  newbee это представляет 

А что мешает разместить ссылку в создаваемом контексте? Ссылка на локальную переменную функции? Ну можно, как сейчас при возврате такой ссылки, писать ворнинг и падать в рантайме, можно и саму переменную утащить в контекст, наверное... Я не вижу принципиальных технических преград.

Имхо, в принципе логично, что возникает UB при использовании лямбдами локальных переменных функции после выхода из этой функции. Но, блин, какого хрена городить огород, который может приводить к UB?!?
Имхо, вектор развития С++ ведет к тому, что в какой-то момент, тим-лидеры будут радикально ограничивать список доступных группе функций языка, так как 80% программеров не будут знать более 80% свойств языка (числа взяты от балды)... А может в какой-то момент начнется массовая смена языка для новых проектов (хотя, вроде уже сейчас что-то в этом духе идет).

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

Имхо, это все выходит за рамки допустимого для С++. Слишком много сложных действий (причем не очевидных), которые пользователь (читай разработчик) совсем не ожидает. Например, твой подход предполагает выделение в куче контекста и создание умного указателя на него. А если у меня оператор new не работает или им пользоваться нельзя (программа для микроконтроллера, например)? Программист совсем не в курсе, что создание лямбда-функции вызовет такие "подводные" действия. Конечно, это можно прописать в учебниках и стандарте БОЛЬШИМИ КРАСНЫМИ буквами, но, есть подозрение, что книжки читают только тогда, когда все остальные методы оказались бессильны.
С другой стороны, текущее поведение тоже не является чем-то правильным. Зато не нарушает идеологию - если не заказывал функциональность, то и не получишь.

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

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

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

Тогда у тебя и лямбды не будет или она не будет работать или будет работать с ограничениями, как сейчас. Про оператор new разработчик ведь откуда-то знает, и про это узнает. В любом случае это будет уже не стандартный С++, а какой-то диалект.

Добавлено через 4 минуты и 16 секунд
Ну и? Пихаем ссылку в контест, где проблема?

Я предлагаю сделать семантику замыкания такой, какая она есть в большинстве языков. Выгоды с этого вагон, это настоящее расширение парадигм С++.

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

Добавлено через 2 минуты и 43 секунды

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

Ну все, это уже пустое словоблудие пошло. Кто предлагает тащить все из других языков в С++? Я вообще за то, чтобы он оставался в рамках 2003 стандарта. Но в него тащат, это факт. Тащат неуклюже. Семантика функций в большинстве языков одинаковая. Классов, циклов, условий - тоже. Так если в С++ притащили лямбду с замыканием, почему их семантика кривая и вообще ни на что не похожая? Зачем эта калека в языке? Это были риторические вопросы, можешь не пытаться на них отвечать. Все, чао!

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


На, то же самое, но руками. Код может быть в произвольном порядке разбросан где угодно. Если программист ССЗБ и замыкает ссылки, пусть будет готов к веселой отладке.

чтоб его побыстрее все бросили ?   а что ж не за то, чтоб С++ оставался в рамка "С с классами"..  (ага , есть и такие)


измени лозунг на "зачем этот калека среди языков" и вступай в ряды под эгидой kemmisto   


да все в этом языке так.. и лямбдами делу не поможешь.. 

по правде сказать, мне с++ нравится почти всем. нет, есть конечно неприятные мелочи. но они настолько незначительны, что на них не стОит обращать внимания.
и такое мнение у меня не из-за того, что я пишу только на с/с++. я пишу и на пайтоне. и если нет категорических требований о том, что задача должна быть реализована исключительно средствами пайтона, то я всю логику пишу на с/с++ и выношу ее в .dll/.so при помощи boost.python, из из пайтона работаю с ней.
нет, конечно, бывают дико скучные задачи, которые хочется за###кодить как можно быстрей. ГУЙ на пример. в таких случаях лучше это делать на более подходящем для этого ЯП.

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

Добавлено @ 00:23
тема превратилась в сплошной оффтопик.
по сабжу, будут идеи?



Это сообщение отредактировал(а) boostcoder - 10.11.2011, 00:40

в PL-образный монстр он врядли превратится. хотя тенденция - да, нехорошая



newbee, в С++ сборки мусора нет, поэтому использовать (замкнутую) переменную вне ее контекста нельзя: нет простых методов для реализации такого функционала.
насколько мне известно, комитет по стандартизации подходит к новшествам с позиции "нельзя ли это сделать имеющимися средствами", синтаксический сахар это не путь С++. путь С++ - создавать синтаксический сахар имеющимися средствами в рамках существующего синтаксиса, т.е. перегрузкой операций и метапрограммированием.
что касается замыканий, они реализуются функциональными объектами, основной недостаток которых - необходимость много писать (причем задолго до места использования)
что касается лямбда-выражений (заметьте, они не называются лямбда-функциями), они функциональными объектами не являются и заменяют последние в подходящем контексте (типа for_each), обеспечивая более короткую и понятную запись. они, понятно, имеют свои недостатки.
на специализированном функциональном языке конечно все это гораздо стройней и изящнее, но за изящество приходится платить.

Добавлено через 6 минут и 31 секунду
кстати, пример Ваш с struct two_lm нехорош. концептуально нехорош. в этом примере правильно использовать функциональный объект, а идеологическая ниша лямбды - автоматический, локальный контекст.
да, С++ позволяет записать лямбду в function<> и и даже сделать при этом замыкание. но он так же позволяет произвольно приводить типы и записывать что угодно по любому адресу. ножик острый, но Вы же на это не жалуетесь.
а вообще С++ ужасен)))