Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это вообще всё ортогонально. Невыполнение post-condition, при удовлетворённых pre-condition — это баг. EP>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть. EP>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.
Вот есть у нас сервер. На нём работают 1000 пользователей.
В случае C# пользователь иногда будет получать сообщение: "Извыни дарагой. Нешмагла. У програмыст рука кривой. В него ужа патинка полетел."
Остальные 999 пользователей вообще ничего не заметят.
В случае с С++ если повезет упадёт весь сервер. Работа всех пользователей пропадёт.
Если не повезет. То сервер продолжит работать. Но вместо осмысленных ответов будет давать бред. Если совсем не повезёт то бред правдоподобный.
И этот баг будет жить годами.
Знаешь, как в яндексе борются с утечками памяти и проездами по памяти?
Рестартом демона по таймеру. Ну, или по факту выпадения в кору.
И это то, что происходит в реальности. А не в том эльфийском мире, который вы тут описываете.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[64]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
EP>>Это вообще всё ортогонально. Невыполнение post-condition, при удовлетворённых pre-condition — это баг. EP>>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть. EP>>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях. WH>Вот есть у нас сервер. На нём работают 1000 пользователей. WH>В случае C# пользователь иногда будет получать сообщение: "Извыни дарагой. Нешмагла. У програмыст рука кривой. В него ужа патинка полетел." WH>Остальные 999 пользователей вообще ничего не заметят.
Цена не достижения постусловий везде разная. Где-то это очень важно, где-то нет.
Сглаживание последствий багов, никак не отменяет того что это баг.
WH>В случае с С++ если повезет упадёт весь сервер. Работа всех пользователей пропадёт. WH>Если не повезет. То сервер продолжит работать. Но вместо осмысленных ответов будет давать бред. Если совсем не повезёт то бред правдоподобный. WH>И этот баг будет жить годами.
Да, для некоторых классов багов, языки с GC и выключенным unsafe — дают определённые гарантии, которых нет в C++ без внешних тулз
WH>Знаешь, как в яндексе борются с утечками памяти и проездами по памяти? WH>Рестартом демона по таймеру. Ну, или по факту выпадения в кору.
Ты так говоришь, как-будто проблемы утечек не существует для языков с GC.
Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны
WH>И это то, что происходит в реальности. А не в том эльфийском мире, который вы тут описываете.
Где мы описываем эльфийский мир?
Баги есть везде. И да, C++ на некоторые классы багов отвечает очень жёстко, самым низкоуровневым образом. Но это же очевидно, и с этим никто не спорил.
Re[55]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Sinclair, Вы писали:
S>Ваш компилятор всё ещё сумеет RVO?
RVO не было и в первом случае, был NRVO, или move
S>Поздравляю, вы получаете штраф O(N) за вызов конструктора копирования.
При таком коде — да, можно чуть изменить и не будет. Вообще-то уже выше по ветке обсуждали, что стандарт C++ говорит делать автоматический move только в некоторых случаях. Зачем повторятся-то?
Re[51]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Sinclair, Вы писали:
M>>Поэтому у программиста C есть вьібор, где и как помещать. S>Ну и у программиста С# тоже есть выбор, где и как размещать. См. напр. stackalloc.
Здравствуйте, AlexRK, Вы писали:
_>>А с чего компилятор должен ругаться то? Никакой ошибки (в смысле падения и т.п.) при данном коде не произойдёт. Да, во вторую функцию не пойдут данные, но мы же самих переместили их в другое место в коде чуть выше. ARK>Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?
Ни голый указатель, ни int не имеет смысла перемещать.
После того как объект переместили, он остаётся в valid'ном, но неопределённом состоянии. То есть в него можно что-то присвоить, или просто уничтожить.
Если хочется, в своих типах можно давать чуть большие гарантии, например после перемещения делать default contruction, но обычно делают просто "moved-from objects shall be placed in a valid but unspecified state".
Re[61]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, AlexRK, Вы писали:
ARK>Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?
"Элементарные" типы данных не перемещаются (нет смысла) — они копируются. Так что указатель и инт и во второй вызов пойдут с оригинальными значениями. Для строк и прочих контейнеров "пойдут" пустые контейнеры. Вот unique_ptr действительно даст нулевой указатель.
Re[64]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Работает и, вопряки твоему высокомерному к нему отношению, работает не плохо.
Почему высокомерное отношение то? Если я сам не раз писал, что C# великолепно справляется с задачами в своей нише (хотя Java в той же нише пожалуй ещё лучше, по сумме параметров).
VD>Собственно, одна из причин отсутствия масового причтия немерла среди шарп–программистов, то что шарп худо–бедно но развиваться. Линк — прекрасен. Лямбды тоже. Дженерики тоже не плохи, хотя и с проблемами.
Угу, по аналогичной причине D перестал быть так популярен (не в реальных проектах, где его и не было, а в мечтах о будущем) в последние годы.
Что касается LINQ, то он как раз не прекрасен, а ужасен, если вспомнить о быстродействие. Я это лично замерял несколько лет назад вместе с местными спецами по .net. Так вот там код с linq отставал от C++ аналогов не на традиционные для C# значения, а намного больше. Т.е. дело явно не в недостатках платформы .net, а в реализации самого linq. Ну или если не веришь мне, то вот тебе уже в этой темке коллеги подтвердили. )
Да, а насчёт лямбд... На C# уже можно написать код аналогичный такому http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc ?
VD>Если ты попытаешься разобраться, узнаешь, что IEnumerable не догма ни в линках, ни в foreach. И то и другое спроектированно на базе паттернов. VD>Так что можно и производительность улучшить за счет перегрузок, и от использования интерфейсов избавиться.
Можно и сделано — это очень разные вещи. )
VD>Создание альтернативной экосистемы коллекций (например, в стиле stl) поломает совместимость, а большого толку не даст.
Ну если говорить о какой-то "нашлёпке" к C#, то безусловно смысла нет. Если же говорить об отдельном новом языке, то совсем другое дело.
VD>Все и так не плохо. Хотя идея не лишина смысла. Можешь заняться. Будет еще один плюс и ещё одна альтернатива. Лично меня более–менее устраивает дотнетный подход и есть куча других задач.
Не раньше чем Nemerle оторвётся от .net'a. )
VD>Все примерно как в плюсах. Все сделать нельзя. Сделано то что было востребованно теми кто использовал язык. Ну а частные проблемы можно решать создавая частные макро–либы. Если получится универсальное решение его можно предложить в стандартную макро–либу.
А есть какой-то общий известный каталог таких библиотек для Nemerle? ) Интересно посмотреть что там уже наделали... )
VD>Я вижу, что ты и шарпе то не глубоко копал, а уж фичи из F#–я ты наверняка не не знаешь. В прочем, буду рад ошибиться. VD>Оператор структурного присвоения вообще штука еникальная. Делали аналог парповского инициализатора списков, а получилась вындервафля.
С F# не игрался, а с Haskell'ем игрался... )
_>>Я правильно понял, что C# код с await/async в Nemerle сейчас работать не будет? VD>Да. Хотя можно на те же компютейшоны транслировать. Но это поддержку шарпа нужно расширять.
Т.е. получается, что Nemerle всё же не является надмножеством C# (как например у того же C->C++) и не может компилировать его код?
VD>Что имеется в виду под этим сокращением? Completion Port винды? Если — да, то в дотнетных либах никаких проблем с ассинхроннвюым IO нет. Везде есть соответствующие перегрузки. Ну, а компьютейшоны отлично подходят для их "ввпрямления".
Как раз главное преимущество реализации этого в C# в том, что позволяет пользоваться этим довольно не простым (внутри) инструментом даже не понимая, как оно в реальности работает.
VD>Скажем если по прочим критериям задаче можно решить на Питоне, плюсах или Немерле, то я выберу Немерле именно из–за того, что на нам получится реализовать проект проще и дешевле.
Для небольшого проекта при таких условиях я бы точно выбрал Питон. )
VD>Это и есть твое надменное отношение. Ты ставишь знак равенства между специализацией (знанием граблей и паттернов позволяющих на них не наступать) и проффесианолизмом.
Специализация тоже о многом говорит. ) К примеру если один дизайнер "специализируется" в Фотошопе, а другой в Paint'е, то... )))
VD>Если бы ты сказал "внимательности", "ответственности" и т.п. я бы не имел ничего против. Но делить людей на профессионалов и нет только на основании используемого языка — это просто глупость. Если я писал на плюсах (весьма успешно) и перешел на шара, я вдруг стал не профессиональным ламером? Гы–гы.
Ты не внимательно читаешь мои фразы. Там же чётко было указано — речь о пороге вхождение. Т.е. вопрос не в том, с чём ты сейчас работаешь (я вот может вообще bat файлик ваяю), а в том с чем ты способен работать.
VD>Макросы — это (грубо говоря) точка входа в программе. Она вызывает некий код который трансформирует код программы. VD>У макр есть свой спец синтаксис. VD>Но рассказывать об это долго. Особенно с телефона. VD>Почему бы не прочесть вводную статейку да не попробывать самому?
Я не про это. Я про организацию кода. Вот на C++ мы можем смешать любые макросы, шаблоны, обычный код в одном файле. Можем конечно и раскидать по отдельным, но это как ты понимаешь будет исключительно наше разделение, а не формальное правило. С другой стороны, в том же упоминаемом выше T4 ситуация обратная и это как раз формальное требование. Так вот вопрос как у нас этим в Nemerle? )
Соответственно если в Nemerle ситуация с макросами как и в C++, то я не вижу особого смысла в каком-то выделение Nemerle библиотек, содержащих макросы. Ну разве что как раз в том смысле, что их нельзя использовать из других языков... )
_>>Насчёт костылей тут очень тонкий вопрос... VD>Вопрос очень прост. В дотнете есть функциональный тип (делегаты) , а в прюсах нет. Буст лечил эту недоработку, пока фанаты С++ обясняют почему эта фича не нужна...
Не, речь о других вещах. Например различные техники работы с Tuple. В C++ то это всё во время компиляции отрабатывает. Так что тут именно тонкий вопрос. Я например могу сказать что ничего подобного в C# нет вообще и буду абсолютно прав. С другой стороны ты можешь сказать что tuple в C# имеется (только работает во время исполнения, что вообще скучно) и к нему даже не нужные какие-то специльные инструменты. И тоже будешь в какой-то степени прав. )))
_>>Ну а вообще для программирование на Nemerle я бы поискал образцы скорее в стандартной библиотеке D, а не в Boost'e. Всё же в C++ МП слабенькое... VD>ОК. И что там?
А там всё тоже самое, но по другому. ) Я хочу сказать, что там реализована в общем то обычная функциональность стандартной библиотеки языка, но с изначальной заточкой на использование МП, вычисления во время компиляции и т.п. Итог получился очень приятный.
VD>Кстати, для ди инфраструктура всетаки есть или ее нет?
Дохленькая. Мы же это уже обсуждали когда-то. Даже библиотеку gui вменяемую не найти.
_>>Я правильно понял, что ты считаешь, что с помощью МП улучшать в контейнерах .net'a нечего? ) VD>В этом нет необходимости.
А вот в D вполне используют. ) Хотя от МП там всего лишь "static if" и нужен. )
VD>И что? Это спосает отзацикливаний, фрагментации памяти и необходимости тратить время на подсчет ссылок и очистку памяти при нулевом их числе?
А ты статью, на которую я кидал тебе ссылку, посмотрел? ) Ну там где про мобильную разработку и ужасы сборщика мусора в ней...
VD>Я всегда это осознаю. Покажите в чем я не прав и я изменю точку зрения.
Про разные мелкие косяки в дискуссии со мной (типа как с Sign# и т.п.) умолчим. Но тебе уже несколько человек в этой темке указывали на то, что ты абсолютно не верно проводишь сравнения с C++. Ты при этом всё время берёшь код, написанный в лучших традициях Java/C# (кстати, довольно странно для бывшего специалиста в C++), сравниваешь его прямо такой с аналогами на C# (или Nemerle) и делаешь совершенно предсказуемые выводы. Ну да, C++ язык мультипарадигменный и формально говоря позволяет писать и такую кривизну. Но когда ты на основе подобных кривых реализаций начинаешь делать глобальные выводы об эффективности языков, это вызывает в лучшем случае усмешку...
VD>Ну вот тут спорить не буду. Это задачи для С/С++. Но вы же не только их на плюсах решаете?
Не только, но что можно на скриптах (в каком-то смысле). Дотнету в любом случае тут делать нечего. )
VD>Ну вот это совсем не по делу применение, если, конечно там все не настолько приметивно, что по фиг на чем писать.
Ммм, там не примитивно, просто как раз там сидят самые нагруженные по быстродействию вещи (те самые "кодеки", вывод на экран и т.п.). Ну т.е. понятно, что у окружающих "кнопок" никакой нагрузки нет, но это уже совсем извращением будет написать остальной gui на каком-то другом языке и потом как-то интегрировать его с окнами от C++ в единое целое.
Ну и потом с помощью правильных инструментов (весь GUI задаётся в специальном удобном редакторе, который потом автоматически генерирует весь нужный C++ код) GUI легко делается и в C++.
Re[53]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Дело ж не в записи, а в том, что в одном случае я обязан заранее знать где и сколько будет жить обект, а во втором я не забиваю себе голову и получаю тот же оезутьтат, если время жизни соответствует размещению на стеке.
Во-первых не получаешь. Правильная формулировка такая: есть шанс, что получишь при определённых условиях работы на определённых java машинах.
А во-вторых в чём проблема знать где и сколько будет жить объект? ) Как бы это нормальная ситуация. ))) Раньше просто в C++ была проблема, что даже если ты знаешь, что объект живёт за пределами данной функции, то передать его выше удобным образом и одновременно с нулевым оверхедом было невозможно. Сейчас эта проблема решена.
Re[62]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>Я уже отвечал на этот вопрос. Аналогия не верна. VD>Переписывать имеет смысл, только только то, что даст приемущество отгегерации кода во время компиляции и т.п. VD>Но это, по факту, не такое частое явление.
Если это действительно так, то боюсь будет не так уж просто доказывать необходимость существования Nemerle вообще...
Re[55]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, AlexRK, Вы писали:
ARK>Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?
Туда пойдёт то, что определил автор перемещаемого класса в конструкторе перемещения. )
Re[46]: Nemerle через 5 лет - выстрелит или скончается?
Кстати, если говорить о производительности и безопасности вместе и о .net в системном программирование... Есть вот такая http://habrahabr.ru/post/208608/ любопытная информация. Не знаю дадут ли этому когда-нибудь ход. Но если дадут, то я обязательно попробую. )
Но в любом случае там есть ряд довольно интересных фраз, особенно про переход на C++ в будущем. )))
Re[63]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Sinclair, Вы писали: EP>Непонятно что именно даёт здесь EA для type safety, которая и так была
EA — это способ получить stack life cycle для объектов без потери type safety.
С++ гордится тем, что у него есть stack life cycle, но при этом в нём нет type safety.
EP>Не мёртв, а пуст EP>Это считай своего рода swap с пустым объектом.
Что такое "пустой объект"?
EP>Что такое "программирование под Windows"
Это значит способ написания Windows-программ с GUI, удовлетворяющим стандартам платформы.
Я просто не в курсе, может быть после MFC, ATL, и WTL появилось что-то "более С++", чем эти пережитки C.
EP>Внутри реализации или интерфейса?
Внутри реализации, естественно. GC-то работает с реализацией, а не с интерфейсом.
EP>Повторяю в N'ый раз — эта техника подходит для затейливых задач, типа сложных графов, в которых без GC ну ни как.
Эта техника подходит для дисциплинированных программистов. Затейливость задачи тут нерелевантна. EP>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть.
Да. Статический верификатор, способный проверить все постусловия, эквивалентен halting problem. EP>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.
Поэтому давайте не будем сравнвать две бесконечности, а перейдём к инженерному подходу, в котором обсуждаются ровно способы облегчить последствия. S>>В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще. EP>Отчего же "от слова вообще"? Вот самый примитивный способ — клади каждый объект в отдельную виртуальную страницу.
Вы, фактически, предлагаете вообще отказаться от освобождения памяти — ведь если страница остаётся "занятой" навсегда, то в чём вообще смысл оператора delete()? Деструктор вызвали — и всё. Не, этот способ неприменим en masse: у 32х разрядного процесса в адресном пространстве нету столько страниц, чтобы хватило на всё время жизни приложения. EP> Или, например, используй инструментацию кода
И что эта инструментация должна сделать?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[65]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, Sinclair, Вы писали:
S>>А что такое "пустой объект"? Я не помню такого термина в спецификации С++, по которой работал я (в своей пред-предыдущей жизни). DE>Если на пальцах, то как-то так: DE>[ccode] DE>string s("test"); // s = "test". DE>foo(move(s)); // Тут у нас "пустой обьект".
По прежнему не вижу определения понятия "пустой объект".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[56]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали: EP>RVO не было и в первом случае, был NRVO, или move
move, вообще-то, как раз O(N). Чудес-то не бывает.
EP>При таком коде — да, можно чуть изменить и не будет.
Попробуйте изменить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[56]: Nemerle через 5 лет - выстрелит или скончается?
S>>Ваш компилятор всё ещё сумеет RVO? Поздравляю, вы получаете штраф O(N) за вызов конструктора копирования.
_>Ну вот как раз здесь компилятору и надо немного подсказать. Например так: _>
Здравствуйте, Sinclair, Вы писали:
EP>>Непонятно что именно даёт здесь EA для type safety, которая и так была S>EA — это способ получить stack life cycle для объектов без потери type safety. S>С++ гордится тем, что у него есть stack life cycle, но при этом в нём нет type safety.
Вообще ортогональные вещи.
В C++ можно выделить подмножество (и даже сделать верификатор, для проверки соответствия), в котором будет и type safety, и "stack life cycle", и не будет EA
EP>>Не мёртв, а пуст EP>>Это считай своего рода swap с пустым объектом. S>Что такое "пустой объект"?
Для простоты считай default constructed. Грубо говоря:
{
T x(something);
T y;
swap(x, y);
}
// approximatly equal to:
{
T x(something);
T y(std::move(x));
}
Здесь x остаётся живым — его можно использовать далее по коду.
Чуть более точные формулировки, были выше по топику.
EP>>Что такое "программирование под Windows" S>Это значит способ написания Windows-программ с GUI, удовлетворяющим стандартам платформы.
С чего это вдруг "программирование под Windows" это обязательно GUI?
Тем не менее, std::thread в данном контексте ничем не отличается от GUI — он также внизу вызывает низкоуровневые функции OS.
S>Я просто не в курсе, может быть после MFC, ATL, и WTL появилось что-то "более С++", чем эти пережитки C.
Да взять хоть тот же QT.
EP>>Внутри реализации или интерфейса? S>Внутри реализации, естественно. GC-то работает с реализацией, а не с интерфейсом.
Не пойму что ты пытаешься сказать — внутри реализаций .NET библиотек, использующих те или иные функции OS — будут те же самые lParam
EP>>Повторяю в N'ый раз — эта техника подходит для затейливых задач, типа сложных графов, в которых без GC ну ни как. S>Эта техника подходит для дисциплинированных программистов. Затейливость задачи тут нерелевантна.
Речь шла про задачи, в которых в силу их структуры возникают жёсткие циклы, с которыми ref_counting/weak_ptr не справится.
Даже если такие редкие и затейливые задачи возникнут при использовании C++ — всегда можно использовать под неё кучу с точным GC.
Разговора о том, чтобы использовать GC для всего приложения — не было.
EP>>Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть. S>Да. Статический верификатор, способный проверить все постусловия, эквивалентен halting problem.
Да, об этом и речь.
EP>>В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях. S>Поэтому давайте не будем сравнвать две бесконечности, а перейдём к инженерному подходу, в котором обсуждаются ровно способы облегчить последствия.
По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.
В целом же, я предпочитаю акцент на минимизации багов, чем на defensive programming. В общем случае, defensive programming применим только к некоторым классам проблем, и уж тем более никак не сможет заставить программу с багом выполнить свою задачу. От создания корректного кода никуда не деться.
S>>>В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще. EP>>Отчего же "от слова вообще"? Вот самый примитивный способ — клади каждый объект в отдельную виртуальную страницу. S>Вы, фактически, предлагаете вообще отказаться от освобождения памяти — ведь если страница остаётся "занятой" навсегда, то в чём вообще смысл оператора delete()? Деструктор вызвали — и всё.
Это всего лишь синтетический пример, показывающий что твоя оценка "от слова вообще" слишком категоричная.
S>Не, этот способ неприменим en masse: у 32х разрядного процесса в адресном пространстве нету столько страниц, чтобы хватило на всё время жизни приложения.
Естественно речь была про x64.
EP>> Или, например, используй инструментацию кода S>И что эта инструментация должна сделать?
Например: у объекта, и всех указателей на него, сделать shared state в виде флага is_alive.
Re[57]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Sinclair, Вы писали:
EP>>RVO не было и в первом случае, был NRVO, или move S>move, вообще-то, как раз O(N). Чудес-то не бывает.
С чего это вдруг O(N)?
Вот например swap двух строк, это какая сложность по-твоему?
EP>>При таком коде — да, можно чуть изменить и не будет. S>Попробуйте изменить.
_>>опять же не будет никаких копирований. S>Сдаётся мне, что таки будут копирования.
Не будет. Если немного упростить — допустим string это всего лишь обвёртка вокруг null terminated:
class string
{
char *data;
public:
string() : data (nullptr) {} // default
//....
~string()
{
delete[] data; // if nullptr - does nothing
}
};
тогда move конструктор выглядит следующим образом:
string(string &&donor)
{
data = donor.data;
donor.data = nullptr
}
То есть мы копируем все необходимые внутренности(в данном случае это один указатель), и "зануляем" внутренности донора таким образом, что бы для него смог корректно отработать его деструктор.
S>Можно посмотреть код move-конструктора для std::string?
), сравниваешь его прямо такой с аналогами на C# (или Nemerle) и делаешь совершенно предсказуемые выводы. Ну да, C++ язык мультипарадигменный и формально говоря позволяет писать и такую кривизну. Но когда ты на основе подобных кривых реализаций начинаешь делать глобальные выводы об эффективности языков, это вызывает в лучшем случае усмешку...
— эта техника подходит для затейливых задач, типа сложных графов, в которых без GC ну ни как.
