Здравствуйте, Denis Ivlev, Вы писали:

CC>>templates никуда не делись, классы никуда не делись, банальный push_back в контейнер который принимает Т&& весьма нужен

DI>Ты упоротый что-ли? Ты же говорил:
DI>

DI>Весь std:: — так себе библиотека, я это уже много раз говорил. Годная для прототипирования а дальше надо уже смотреть.

DI>и

DI>

DI>С++ это только сам язык. Либы отдельно.
DI>>STL описан в стандарте С++, так что не засчитывается.
DI>Пофигу. С++ это только сам язык.

И? Как это относится к тому, что templates продолжают работать и move semantics тоже? STL файлы для них не нужны от слова совсем.

CC>>классы никуда не делись
DI>в том подмножестве о котором мы говорим классы использовать нельзя из-за непредсказуемого размещения в памяти.
Ты несёшь лютую чушь. Какое ещё нафиг "непредсказуемое размещение"?

Здравствуйте, Denis Ivlev, Вы писали:

DI>>>Я уже давно на плюсах не пишу
CC>>And it shows...
DI>И где же это видно?
Да почти в каждом посте. Мсье очевидный теоретик, практики мало и та строго по книжке. Как оно работает имеешь весьма отдалённое представление.

DI>ты побежал по всем моим сообщениям "гы" писать.
Ай цирк, ты ещё и как RSDN Janus работает не в курсе.
Нет деточка, ты мне нахрен не сдался, грусти.

CC>>>>Ты читать не умеешь?
DI>>>Умею, ты что-то прогундел и слился.
CC>>Гуляй, зелёный.
DI>Что-то ты снова загундел, что сказать-то хочешь?
Эт тебе к ушнюку надо

CC>>>>>>Иди почитай за SMM лучше, чудо!
DI>>>Хватит кривляться, если есть, что сказать так скажи, а то как школьник щеки надуваешь, будто что-то знаешь, но не скажешь.
CC>>Мне давно не интересно метать бисер перед троллями.
DI>Что-то ты снова загундел, что сказать-то хочешь?
Это у тебя просто коллектор прогорел и шумит теперь.

CC>>>>Это развлечение надоело уже пару лет назад.
DI>>>Лукавишь ведь.
CC>>Нет. Еды не будет, грусти. Я дальше буду только издеваться.
DI>Кек, болезный )
Опять похужело?

Здравствуйте, placement_new, Вы писали:

_>Какие языки тянет за собой backend area?
Backend чего именно?

_> Это может быть как scala так и c++.
Угу, надо бы конкретики.

Здравствуйте, placement_new, Вы писали:

_>Ты видимо или в google никогдва не собеседовался
Не, меня их странная культура не привлекает.

_> или просто специалсит уровня Principal.
Возможно.

Здравствуйте, Hobbes, Вы писали:

H>compile-time отладчик?
Это как?

Здравствуйте, andyp, Вы писали:

A>Ну т.е. их крутят чтобы жизнь упростить.
Верно. Но народ увы про это с большего забыл и накручивает слишком много тех самых излишних абстракций.

A>но это ж проблема дизайна, а не языка .
Верно.

Здравствуйте, Hobbes, Вы писали:

H>std::vector'у существует намного больше лет, чем Rust. Не понимаю, в чём проблема контроля за выходом за пределы массива.

У вектора есть метод at бросающий исключение при выходе за границы, статически же такое далеко не всегда возможно проверить.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, lpd, Вы писали:

lpd>>Реально мув-семантика играет сколько-то заметную роль в конечном общем быстродействии программы очень-очень редко
CC>Просто поменяй всё && на одинарный & и тут же начнётся веселуха, когда вместо того чтоб забрать объект в контейнер его сначала весь скопируют а потом старый убьют. И как только объект в себе тащит другие объекты начинается deep copy, которое занимает время.

Я это понимаю, но где это копирование реально занимает хотя бы 10% времени от работы программы, чтобы это было заметно? Ради чего вся эта синтаксическая возня с && и std::move? Ну можно сделать move в узком месте, но все равно там будет прямое управление памятью и обычные C-массивы, с которыми для этого одного объекта можно сделать мув вручную.

lpd>> и это не стоит реализации ее в C++ языке, тем более такой запутанной.
CC>А запутанность то там где?
Целый новый тип ссылок, move — там немало нового вроде как.

lpd>> Там где это нужно, можно сделать у объекта руками метод Move(), в том числе для push_back().
CC>Всё можно сделать на ручнике, только вот беда в том что кода зело много приходится писать.
Почему много? У тебя есть CCString{ char *buf }; Вместо std::move для этого класса можно сделать метод:

CCString::Move(CCString *str1) 
{
    this->buf = str1->buf;
    str1->buf=0;
}

Это то же самое, только проще, и это нужно максимум для пары массивов во всей программе.
Также для особых оптимизаций можно сделать vector::push_back_movable(IMovable3 *obj), и все.

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

Я вообще не сторонник лишних оптимизаций, но в крайнем случае предпочту прямую работу с памятью, чем расчет на магию компилятора. Не знаю, вопрос вкуса наверное.

Здравствуйте, CreatorCray, Вы писали:

DI>>Зеленый, вместо еды погрызи учебник логики, дабы так не позорится.
CC>Хехе, пригорает?

Оттого, что ты не знаешь, что сначала тезис надо доказать?

Здравствуйте, CreatorCray, Вы писали:

CC>>>классы никуда не делись
DI>>в том подмножестве о котором мы говорим классы использовать нельзя из-за непредсказуемого размещения в памяти.
CC>Ты несёшь лютую чушь. Какое ещё нафиг "непредсказуемое размещение"?

Не стыдно не знать язык за который ты тут глотку рвешь? В С++ для совместимости с С есть POD типы у которых расположение полей предсказуемое — в порядке объявления, для не POD типов таких гарантий нет и компилятор может изменять порядок полей по своему усмотрению.

Здравствуйте, Denis Ivlev, Вы писали:

DI>Не стыдно не знать язык за который ты тут глотку рвешь? В С++ для совместимости с С есть POD типы у которых расположение полей предсказуемое — в порядке объявления, для не POD типов таких гарантий нет и компилятор может изменять порядок полей по своему усмотрению.

Ээ... я правильно понимаю, что если в структуру добавить конструктор, то компилятор может у структуры поменять порядок полей?
А можно ссылку на Стандарт, а то что-то я отстал от жизни.

Здравствуйте, CreatorCray, Вы писали:

DI>>>>Я уже давно на плюсах не пишу
CC>>>And it shows...
DI>>И где же это видно?
CC>Да почти в каждом посте.

Пока только я тебя носом тычу в твое невежество.

DI>>ты побежал по всем моим сообщениям "гы" писать.
CC>Ай цирк, ты ещё и как RSDN Janus работает не в курсе.

Да мне насрать на твой янус, я не знаю и знать не хочу что это, я пользуюсь веб-версией.

CC>Нет деточка, ты мне нахрен не сдался, грусти.

Ты и правда упорот. Это не твои что-ли подряд сообщения мне?

http://rsdn.org/forum/job/7555225.1

Автор: CreatorCray
Дата: 30.09.19

http://rsdn.org/forum/job/7555226.1

Автор: CreatorCray
Дата: 30.09.19

http://rsdn.org/forum/job/7555227.1

Автор: CreatorCray
Дата: 30.09.19

В каждом гыканья и куча смайликов. Знатно же тебя порвало.

CC>>>>>Ты читать не умеешь?
DI>>>>Умею, ты что-то прогундел и слился.
CC>>>[неразборчивый гундеж]
DI>>Что-то ты снова загундел, что сказать-то хочешь?
CC>[неразборчивый гундеж и попердывания]

CC>>>>>>>Иди почитай за SMM лучше, чудо!
DI>>>>Хватит кривляться, если есть, что сказать так скажи, а то как школьник щеки надуваешь, будто что-то знаешь, но не скажешь.
CC>>>[неразборчивый гундеж]
DI>>Что-то ты снова загундел, что сказать-то хочешь?
CC>[неразборчивый гундеж и попердывания]

CC>>>>>Это развлечение надоело уже пару лет назад.
DI>>>>Лукавишь ведь.
CC>>>[неразборчивый гундеж]
DI>>Кек, болезный )
CC>[неразборчивый гундеж и попердывания]

Дыши глубже.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Ээ... я правильно понимаю, что если в структуру добавить конструктор, то компилятор может у структуры поменять порядок полей?

Да.

SVZ>А можно ссылку на Стандарт, а то что-то я отстал от жизни.

Отстал? Да это еще в 2003 стандарте было, может и раньше. Я хз где в открытом доступе есть стандарт, придется тебе самому искать или верить cppreference.com:

https://en.cppreference.com/w/cpp/named_req/PODType

Здравствуйте, lpd, Вы писали:

lpd>Я это понимаю, но где это копирование реально занимает хотя бы 10% времени от работы программы, чтобы это было заметно?
Достаточно чтоб оно занимало слишком много времени в узком месте.

lpd> Ради чего вся эта синтаксическая возня с && и std::move?
lpd> Ну можно сделать move в узком месте, но все равно там будет прямое управление памятью и обычные C-массивы
А массивы то откуда взялись? И зачем для move "прямое управление памятью"?

lpd>Целый новый тип ссылок, move — там немало нового вроде как.
Совсем чуть чуть: новый тип с довольно ограниченным применением и пучок правил как оно работает.

lpd>>> Там где это нужно, можно сделать у объекта руками метод Move(), в том числе для push_back().
CC>>Всё можно сделать на ручнике, только вот беда в том что кода зело много приходится писать.
lpd>Почему много? У тебя есть CCString{ char *buf }; Вместо std::move для этого класса можно сделать метод:
lpd>

lpd>CCString::Move(CCString *str1) 
lpd>{
    this->>buf = str1->buf;
    str1->>buf=0;
lpd>}
lpd>

lpd>Это то же самое, только проще

Как с таким подходом задать move constructor рядом с copy constructor?
Самый большой impact от разницы move vs copy+delete получается когда ты не простой объект пихаешь а составной, внутри которого большая иерархия.
Это всё можно сделать и на ручнике, но с move constructor это всё работает автоматически.

lpd> и это нужно максимум для пары массивов во всей программе.
Да как то в гораздо большем колве мест на деле.

lpd>Я вообще не сторонник лишних оптимизаций, но в крайнем случае предпочту прямую работу с памятью, чем расчет на магию компилятора.

Я уже давно убедился что современный промышленный компилятор генерит достаточно хороший код чтоб перестать экономить на спичках и забил на заморочки. Профайлером поглядываю на критические куски иногда и пока всё хорошо. Уже давно всё упирается скорее в data layout (cache hit/miss) чем в инструкции. А SSE оптимизации на интринсиках удобно вышиваются.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Ээ... я правильно понимаю, что если в структуру добавить конструктор, то компилятор может у структуры поменять порядок полей?

Он про то, что для non-POD разрешены data layout optimizations. Некоторые туповатые компиляторы могут радостно утрамбовать поля так, чтоб было поменьше padding, в результате чего иногда может возникнуть false sharing. Эта самодеятельность пресекается declspec, если понадобится.

Здравствуйте, Denis Ivlev, Вы писали:

DI>Пока только я тебя носом тычу в твое невежество.
Да чота всё промахиваешься и падаешь в лужу
Поди тыкалка у тебя уж слишком короткая, обтекай и отращивай

DI>Да мне насрать на твой янус, я не знаю и знать не хочу что это, я пользуюсь веб-версией.
Ну, грусти

DI>Ты и правда упорот. Это не твои что-ли подряд сообщения мне?
Это ответы на твои сообщения

DI>[неразборчивый гундеж и попердывания]
DI>[неразборчивый гундеж и попердывания]
DI>[неразборчивый гундеж и попердывания]

Ты что сказать то хотел?

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, lpd, Вы писали:

lpd>>Целый новый тип ссылок, move — там немало нового вроде как.
CC>Совсем чуть чуть: новый тип с довольно ограниченным применением и пучок правил как оно работает.
Ничего себе чуть-чуть.

CC>Самый большой impact от разницы move vs copy+delete получается когда ты не простой объект пихаешь а составной, внутри которого большая иерархия.
CC>Это всё можно сделать и на ручнике, но с move constructor это всё работает автоматически.
CC>Да как то в гораздо большем колве мест на деле.

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

lpd>>Я вообще не сторонник лишних оптимизаций, но в крайнем случае предпочту прямую работу с памятью, чем расчет на магию компилятора.

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

Использование move-семантики — это и есть эталонная экономия на спичках(копировании). Измерял профилировщиком выигрыш в скорости от мув-семантики где-нибудь, и вклад этого выигрыша в суммарное время отклика или скорость?

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

$>А кому нужны десктопные приложения?

Такое ощущение, что кто-то не вылез из 2007-го. Тогда как раз были модными подобные радикальные идеи. Потом реальность внесла свои коррективы. Причём внесла весьма брутально — по крайней мере на Маке всё большее количество профессиональных ниш обратно отвоёвывается Mac App Store'ом, на долю браузера приходится всё меньше активности. А таких монстров, как, например, IDA, Xcode, Photoshop, After Effects, Sketch, Pro Tools, Final Cut Pro в уебе не будет от слова никогда. Да что говорить — даже G.Docs и Office 365 до нативного Ворда–Экселя и близко не дотягивают по возможностям и эргономике, хотя лет первым уже ого-го сколько.

$>Это интересная точка зрения. Кто-то ещё переписал всё взад из микросервисов в монолит, кто-то из жавы взад в сипипи. Но это всё против мейнстрима.
Мейнстрим не нужен. И это на первый взгляд одиозное и максималистичное заявление при ближайшем рассмотрении таковым не является. Чистая прагматика: 99.(9)% проектов провальны, распределение Парето в области софта остро как нигде больше, а оставшиеся истории успеха настолько уникальны и ни на что не похожи, что ни о каком мейнстриме говорить не приходится. Блин, да даже какой-нибудь завалящий клиент фейсбучика на iOS. Попробуйте его реверснуть — охренеете от гипер-навороченности нативного кода внутри. Хотя в его случае одновременно непонятно, на кой такие заморочки, и терзают сомнения, пошло ли ему это на пользу.

Здравствуйте, checkthestack, Вы писали:

Помнится, у Ильфака Гильфанова (IDA, Hexrays) была вакансия с просто-таки щикарным (ц) пожеланием к соискателю: "глубокие знания C++ и столь же глубокое нежелание его использовать" То есть да, в сложных проектах Цепепе полезен, и его знание сильно помогает, но писать в наши дни на крестах весь проект от и до — изощренное самоубийство.