Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.16.15.149] |
|
Страницы: (77) 1 2 [3] 4 5 ... 76 77 ( Перейти к последнему сообщению ) |
Сообщ.
#31
,
|
|
|
Цитата Gunnar @ Это к психиатру, однозначно. Если есть соглашения, им нужно следовать, если нет - их нужно принять. Если тип из 3-парти либы, к нему нужно написать адаптер, который реализует соглашения. Одно из предназначений шаблонов — интеграция кода из разных библиотек написанных разными людьми в разное время. Так что вполне нормальная ситуация. А вообще, хотелось бы в языке видеть что-то наподобие Nemerle'вских макросов вместо программирования на шаблонах (например, см. http://rsdn.ru/article/nemerle/nemerleMacros.xml) (раз уж лисповские макросы не получится сделать). Это бы сильно упростило метапрограммирование. |
Сообщ.
#32
,
|
|
|
Нет.. не была.. но я все надеялся что будет разрешена.. но видимо зря.. (( Добавлено Цитата archimed7592 @ есть ещё такой момент, что T^ - используется в C++/CLI, а C++/CLI используется микрософтом, Не вижу связи.. языки то разные.. какая разница что там чтото используется.. Да я понял.. просто хотел чтобы T&& было ссылкой на ссылку всеже.. и... если делать отдельный токен как && то надежда о ссылке на ссылку улетает.. ибо онаб выгладила как &&.. |
Сообщ.
#33
,
|
|
|
Цитата LuckLess @ Не вижу связи.. языки то разные.. какая разница что там чтото используется.. Не совсем разные. C++/CLI - это надмножество С++. Т.е использование T^ в С++ неприемлемо. |
Сообщ.
#34
,
|
|
|
Цитата Gunnar @ C++/CLI - это надмножество С++. Ту.. тогда уж это надмножество С++ стандарта 2003-го года, и в принципе может и не быть надмножеством 2009-го года.. Хотя я вообще не уверен что это может быть именно надмножеством.. как допускаются asm вставки в управляемый код?? но спорить не буду ибо с темой не знаком. ладно.. какие там еще значки есть.. T% rvalueRef; пусть так тогда.. |
Сообщ.
#35
,
|
|
|
Цитата LuckLess @ принципе может и не быть надмножеством 2009-го года Ну дык будет новый стандарт C++/CLI "подогнанный" под С++ 2009 |
Сообщ.
#36
,
|
|
|
Gunnar
Есть ли asm вставки в C++/CLI ? Добавлено Цитата Gunnar @ Ну дык будет новый стандарт C++/CLI "подогнанный" под С++ 2009 ну так пусть портят .Net всякими && а оставят нормальный С++ с нормальными значками. ну да ладно есть еще T$, T#, T%... |
Сообщ.
#37
,
|
|
|
Цитата LuckLess @ Нет.. не была.. но я все надеялся что будет разрешена.. но видимо зря.. (( Не совсем понял... а как ты себе представляешь "ссылку на ссылку". Т.е. какой у неё будет смысл? Цитата LuckLess @ в c++/cli допустимо всё, что допустимо в с++ плюс .net навороты.Не вижу связи.. языки то разные.. какая разница что там чтото используется.. Цитата LuckLess @ T% Уже занято тем же c++/cli Цитата LuckLess @ как допускаются asm вставки в управляемый код? Цитата LuckLess @ Есть ли asm вставки в C++/CLI ? Вроде да. Там нету отличия уравляемого кода от неуправляемого. По крайней мере на уровне языка. Твори что душе угодно |
Сообщ.
#38
,
|
|
|
Цитата archimed7592 @ Не совсем понял... а как ты себе представляешь "ссылку на ссылку". Т.е. какой у неё будет смысл? Такойже как у ссылки. т.е. ссылка на ссылку на ссылку на ссылку тоже самое что просто ссылка. Зачем это? пример. class BigClass { public: BigClass (const BigClass&) //very very slooow copy { } BigClass () { } bool Func (int) const { std::cout << "Ы\n"; return false; } }; class LLClass { public: bool Func (BigClass&) const //workaround //bool Func (BigClass) const //no ref! copying BigClass! А если конструктор копирования вообще закрыт?? { std::cout << "Ы\n"; return false; } }; int main () { BigClass veryBigVariable; std::vector<LLClass> lotsOfBigClasses; std::for_each (lotsOfBigClasses.begin (), lotsOfBigClasses.end (), std::bind2nd (std::mem_fun_ref (&LLClass::Func), veryBigVariable));//error C2529: '_Right' : reference to reference is illegal } |
Сообщ.
#39
,
|
|
|
Цитата LuckLess @ Такойже как у ссылки. т.е. ссылка на ссылку на ссылку на ссылку тоже самое что просто ссылка Эээ... так нет. Это ввели. Это и понимается под правилами сворачивания ссылок. |
Сообщ.
#40
,
|
|
|
Цитата archimed7592 @ Эээ... так нет. Это ввели. Это и понимается под правилами сворачивания ссылок. Но как тогда обходится конфликт с &&.. ибо во время инстанциирования шаблона у меня получится T&& который будет означать ссылку на ссылку, а не ссылку на ravlue. |
Сообщ.
#41
,
|
|
|
Цитата LuckLess @ ибо во время инстанциирования шаблона у меня получится T&& У тебя получится "T & &", а это не то же самое, что и "T &&". Опять повторяю, что "&&" и "& &" разные вещи. Аналогично как и "++" и "+ +". |
Сообщ.
#42
,
|
|
|
Цитата archimed7592 @ У тебя получится "T & &", а это не то же самое, что и "T &&". т.е. для указателей я могу написать ** а для ссылок нада извращатся с "& &"? И если это изза того что гребанный C++/CLI есть на белом свете то я пойду отстреливать Билла. Добавлено T# хоть не занят эти дурацким языком? Если не занят то почему бы не использовать T#? И вообще.. что будет взятие адреса у T&&? не T* же? Этож нада будет новый тип опять... указатель на rvalue.. чтото типа нада сделать rvalue T& rvalueVar; //ссылка на rvalue rvalue T* rvalueVar; //указатель на ravlue Добавлено Цитата LuckLess @ И вообще.. что будет взятие адреса у T&&? не T* же? погоди.. неужели это будет тип T&&*? |
Сообщ.
#43
,
|
|
|
Цитата LuckLess @ т.е. для указателей я могу написать ** а для ссылок нада извращатся с "& &"? Ты так можешь написать только потому, что такого токена как ** не существует и, соответственно, интерпретируется как два последовательных * Цитата LuckLess @ И если это изза того что гребанный C++/CLI есть на белом свете то я пойду отстреливать Билла. Да нет же. Не поэтому. Вот по текущему стандарту необходимо писать "set<set<int> >", а не "set<set<int>>". Ты же не пойдёшь отстреливать Кернигана за то, что он придумал ввести в язык побитовые сдвиги и токен ">>" интерпретируется именно как оператор сдвига, а не как две закрывающих скобки. |
Сообщ.
#44
,
|
|
|
Цитата archimed7592 @ Ты так можешь написать только потому, что такого токена как ** не существует Правильно. Ссылка во многом похожа на указатель в плане "написания" типа. Почему бы токен ** тогда не придумать.. вот все охренеют.. Когда я вижу ** я знаю что тут указатель на указатель, и обсолютно логично смотреть на && как на ссылку на ссылку. Дохрена ведь разных значков есть, зачем использовать && мне непонятно.. T~, T`, T", T#, T:, T?, T.; еще думаю придумать можно.. запись T&& будет путать 100 процентно. Мое имхо что && в финальной версии не будет, ибо это бяка. Ключевое слово, или новый символ.. вот что должно быть. |
Сообщ.
#45
,
|
|
|
Цитата LuckLess @ T# хоть не занят эти дурацким языком? Если не занят то почему бы не использовать T#? Да расслабься ты. Эти ссылки были предложены ещё в 2002 году и тогда, если не ошибаюсь и ^ и % были "свободны". Они и сейчас свободны. Просто, видимо, решили сделать синтаксис rvalue-ссылок похожим на синтаксис обычных(lvalue). Цитата LuckLess @ И вообще.. что будет взятие адреса у T&&? не T* же? Будет T *, означающая адрес ссылаемого объекта. Дабы не разводить лишнего флейма, прочитай пожалуйста ещё раз, зачем были введены эти ссылки. Можешь в оригинале(n1377). В двух словах: для того, чтобы отличать временные объекты от обычных, что может дать прирост производительности(при соответствующей поддержке со стороны реализации класса). Добавлено Цитата LuckLess @ Правильно. Ссылка во многом похожа на указатель в плане "написания" типа. Почему бы токен ** тогда не придумать.. вот все охренеют.. Когда я вижу ** я знаю что тут указатель на указатель, и обсолютно логично смотреть на && как на ссылку на ссылку. Дохрена ведь разных значков есть, зачем использовать && мне непонятно.. T~, T`, T", T#, T:, T?, T.; еще думаю придумать можно.. запись T&& будет путать 100 процентно. LuckLess, как тебе такой момент, что нельзя будет писать int & & x? Между прочим, если бы можно было, то путало бы это не меньше. Цитата LuckLess @ Ты не поверишь, но rvalue-ссылки уже включены в WP(рабочий черновик) и внедрены в туеву хучу мест стандарта(вся стандартная библиотека) и, поверь, никто не будет переделывать это на лад шапочек или процентиков.Мое имхо что && в финальной версии не будет, ибо это бяка. Ключевое слово, или новый символ.. вот что должно быть. Ещё раз напоминаю, что так решили с 2002 года и за 5 лет пока никому в голову не пришло, что это будет путать или ещё чем-то не устроит. |