Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, alex_public, Вы писали:
_>>Только вот GPL — это уж точно не свободная лицензия. ))) S>KDE распространяло Qt под какой-то более "свободной" лицензией?
Да, что-то было такое. Может быть, и сейчас такое. Они там с тролтехом (изначальными авторами Qt) договорились об особых условиях. Ох, как давно же это было!
Здравствуйте, dsorokin, Вы писали:
D>Да, что-то было такое.
Нет. Там было другое: если Trolltech перестает выпускать/закрывает Qt, то KDE может использовать последнюю открытую версию Qt под FreeBSD, но это не случилось.
D>Может быть, и сейчас такое.
Нет.
D>Они там с тролтехом (изначальными авторами Qt) договорились об особых условиях. Ох, как давно же это было!
Да.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, dsorokin, Вы писали:
D>>Да, что-то было такое. S>Нет. Там было другое: если Trolltech перестает выпускать/закрывает Qt, то KDE может использовать последнюю открытую версию Qt под FreeBSD, но это не случилось.
Тут все зависит от того, как понимать свободу.
Накину-ка в продолжение основной темы. В выходные колупался с одной своей поделкой. Суть такова, что я как истый функциональщик и хаскелист написал код на Rust, где очень много замыканий и семантики move, которая очень хорошо в этом языке поддерживается, причем когда пишешь, то даже особо не задумываешься о всех тех нюансах, с которыми сталкиваешься, попробуй написать такое же в С++. Так вот, в выходные я попробовал. Код, собранный на GCC отстает от растовского раза в 4. Код, собранный с помощью clang отстает в раз 10... Сборка релизная безусловно, с -O3. Код закрыт, показывать не буду. Скорее всего, это больше говорит о моих еще далеко несовершенных знаниях C++, где я чего-то еще недопонимаю, но мне такой расклад очень запомнился.
lpd>Интересен был бы пример, чтобы в где-то применялся unique_ptr<>, и это дало большой выигрыш. Может я правда что-то упускаю.
move семантика в C++11 сделана не только ради выигрыша (по скорости), но и для выражения семантики владения ресурсом. Когда объект не может быть скопирован, а только перемещен (с передачей владения ресурсом). Актуально для mutex'ов, thread'ов и для пользовательских объектов с семантикой единоличного владения (не разделяемого).
S>>KDE распространяло Qt под какой-то более "свободной" лицензией?
D>Да, что-то было такое. Может быть, и сейчас такое. Они там с тролтехом (изначальными авторами Qt) договорились об особых условиях. Ох, как давно же это было!
Владельцы Qt (самые изначальные и все последующие) договаривались с KDE о том, что если владелец Qt не будет его развивать или попытается закрыть, то KDE выпустит Qt под свободной лицензией (возможно, под BSD). Суть договоренности в том, чтобы независимо от желания или нежелания владельцев Qt его развивать в открытом виде (компания владелец обанкротилась, решила остановить разработку или выпустила Qt под закрытой лицензией), Qt так и остался открытым, ибо на нем основан KDE и куча другого софта (Qt лежит в основе OpenSource).
Но эта договоренность не имеет значения, пока Qt развивается и остается доступным под свободной лицензией.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>В простоте кода, надежности, расширяемости, в чем угодно. Хотя бы в общих чертах описание что за объект такой и в каком контексте без unique_ptr<T> и его move было бы плохо.
S>В том числе там и unique_ptr применяется для того, чтобы руками не закрывать ресурсы.
Я так примерное использование unique_ptr<> и представлял, только в примере не видно, где делают его move. Реально упрощает ли это код? В принципе наверное да, хотя мне больше нравится явно и наглядно вызывать close/free(), чем зависеть от уничтожения unique_ptr<> на стеке, которое мне не кажется проще. В С++ компилятор и так многое проверяет по сравнению с каким-нибудь питоном, и я бы таким положением вещей и ограничился. У меня в коде бывают ошибки и сложные участки, но это обычно учет ссылок, синхронизация, обработка ошибочных ситуаций и прочие ошибки архитектуры и логики. Такое синтакическими фишками вроде unique_ptr<> не решается. Но если вам так нравится, пишите unique_ptr<>, не буду спорить.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>У меня в коде бывают ошибки и сложные участки, но это обычно учет ссылок, синхронизация, обработка ошибочных ситуаций и прочие ошибки архитектуры и логики.
Вообще-то часть этих проблем типизацией и решается. И вам не просто так был задан вопрос о вашем коде на который можно было бы посмотреть.
Но т.к. смотреть нечего, то остается только догадываться о том, что и как вы пишите, раз даже понять выгоды от unique_ptr не в состоянии.
lpd>Такое синтакическими фишками вроде unique_ptr<> не решается.
Тут очень не хватает жирного "ИМХО".
lpd>Но если вам так нравится, пишите unique_ptr<>, не буду спорить.
Простите, а вы собственно кто чтобы ваше разрешение имело хоть для кого-нибудь хоть какое-нибудь значение?
Здравствуйте, dsorokin, Вы писали:
D>Скорее всего, это больше говорит о моих еще далеко несовершенных знаниях C++, где я чего-то еще недопонимаю, но мне такой расклад очень запомнился.
Ну прямо классика: "Ложечки-то нашлись, но осадочек остался."
НС>>тем меньше серверов надо оплачивать — прямая бизнес-выгода.
_>И? ) Эти мои слова как-то противоречат каким-то другим моим словам или что? )))
Эти слова демонстрируют, что ты первый начал обсуждать экономику, а когда аргумент оказался так себе начал переводить стрелки.
_>Повышенное отжирание памяти Java приложениями в сравнение с нативными — это насколько избитая тема с таким множеством различных тестов,
Речь шла не про отжирание вообще, а конкретно про рекордсеты.
Здравствуйте, so5team, Вы писали:
lpd>>Такое синтакическими фишками вроде unique_ptr<> не решается.
S>Тут очень не хватает жирного "ИМХО".
Хотите сделать язык, на котором нельзя допускать логические и архитектурные ошибки? Именно они основные.
В твоем примере move не использовался, только просто unique_ptr<>.
lpd>>Но если вам так нравится, пишите unique_ptr<>, не буду спорить.
S>Простите, а вы собственно кто чтобы ваше разрешение имело хоть для кого-нибудь хоть какое-нибудь значение?
Ну ясно, местные С++-тролли — последователи Страуструпа. Только его мнение и имеет для вас значение, вот и мучаетесь со своими шаблонами. Что ж страдайте, может тяготы кодинга отучат вас от темплейтства, когда программы будете писать, а не helloworld на С++17, где в одной функции файл открывается, и тамже закрывается.
Аргументы у меня закончились, у тебя вроде тоже, наверное к консенсусу не придем. Осталось похамить для rsdn-кармы, и разойтись каждый с чувством собственной правоты.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, dsorokin, Вы писали:
D>>Скорее всего, это больше говорит о моих еще далеко несовершенных знаниях C++, где я чего-то еще недопонимаю, но мне такой расклад очень запомнился.
S>Ну прямо классика: "Ложечки-то нашлись, но осадочек остался."
Нет. Увы! Мне сейчас кажется, что C++ в такой задаче не может догнать Rust в силу особенностей того, как работает move в Rust и C++. Очень хотел бы ошибиться.
В Rust move — это обычно всего лишь копирование битов из одного места памяти в другое. Потом для расположенного в памяти старого объекта не будет вызван деструктор (он называется Drop), и все. А многие объекты (векторы, умные указатели, срезки, строки, реализующие классы типов объекты) имеют такое представление в памяти, что их достаточно просто взять и скопировать побитого во время move.
Если брать C++, то для тех же std::function последние нужно компилятору явно обнулить, чтобы потом у перенесенного объекта корректно сработал деструктор, т.е. здесь C++ выполняет лишнюю работу, которую Rust не делает, потому что Rust так спроектирован.
Более того, пишут в интернетах, что для C++ копирование может даже оказаться дешевле, чем move. Еще там исключения ошиваются рядом. Короче, опечалился, потому что это важно для моей задачи.
Тут такая штука любопытная вырисовывается. В C++ основным является копирование объектов, хотя и необязательным, тогда как move сделан был уже позже. В Rust же основным является move, язык на это заточен с самого начала, а вот копирование в Rust должно быть всегда явным. В терминах Rust это более корректно назвать "клонированием". Так называемое "копирование" тоже есть, но оно является частным случаем клонирования, когда можно уже побитового скопировать, сохранив идентичность старого объекта (числа, например). Итого получатся, что move в Rust обычно намного дешевле, чем копирование.
Здравствуйте, so5team, Вы писали:
S>В том числе там и unique_ptr применяется для того, чтобы руками не закрывать ресурсы.
В тех примерах руками дропать объекты есть неверно, это верно. Там unique_ptr и подобная муть оправдана, как и в любом хеллоуворлде. В масштабных же системах-это очень большая редкость, когда мы можем допустить автоматическое уничтожение объекта, уничтожение его фактом уничтожения других объектов, скручивания стека, etc. В подавляющем большинстве случаев, необходимость уничтожить объект появляется при определённом стечении обстоятельств, самых разных, чаще всего поступающих извне системы, внешних (сигналы из железок, события с других сервисов etc). Можно юзать unique_ptr, но придётся делать ему reset, что ничем от close/free не отличается. Так зачем оно всё тогда нужно? Чтоб быть модным и молодёжным C++-ником?
Здравствуйте, smeeld, Вы писали:
S>Можно юзать unique_ptr, но придётся делать ему reset, что ничем от close/free не отличается. Так зачем оно всё тогда нужно? Чтоб быть модным и молодёжным C++-ником?
Надеюсь, что это шутка. Ты ещё скажи, что автоматическое отпускание мьютексов и закрытие файлов — это плохо.
Здравствуйте, dsorokin, Вы писали:
D>Нет. Увы! Мне сейчас кажется, что C++ в такой задаче не может догнать Rust в силу особенностей того, как работает move в Rust и C++. Очень хотел бы ошибиться.
Не видя кода остается доверять только вашим словам о вашем небольшом знании C++. Я видел слишком много кода от новичков в C++, в котором локальные объекты создавались через new, а shared_ptr использовался направо и налево вне зависимости от его надобности и ненадобности.
В С++ очень легко получить просадку производительности. Например, используя такие невинные, на первый взгляд, вещи, как shared_ptr<T>{new T()}, или задействуя std::regex, или вызывая std::vector::push_back в цикле без предварительного reserve(), или даже применяя std::unordered_map в каких-то сценариях. Или написав return std::move(some_object).
В этом смысле показательно ваше упоминание std::function: если вы его активно используете для хранения лямбд с непустым списком захвата, то, вероятно, вы используете динамическую память сами того не подозревая.
Так что без кода ваши результаты можно списать как на проблемы C++, так и на радиус кривизны ваших рук (из-за недостатка опыта/знаний).
. I think I trust the programmers a bit better, and I think I trust the tool builders a bit more than some people. I think we should focus more on making programming simpler for the majority of programmers rather than strengthening the hand of builders foundation libraries and language lawyers. There’s a tension there because a lot of the people in the standards community are of course experts; they are experts in a variety of things and when it comes to the votes a lot of people vote for help for experts. They are experts, and they think to help other experts like themselves, and well that’s maybe 1 percent or ½ percent of C++ users population, and I will rather help the rest of them. There are many cases where you can do both at the same time so the conflict is not as dramatic as you might think it is but it is tension, and it’s constant tension.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Хотите сделать язык, на котором нельзя допускать логические и архитектурные ошибки?
Речь о том, что возможности C++, если про них знать и не бояться использовать, могут помочь в борьбе с некоторыми логическими ошибками точно. И, местами, указывать на архитектурные просчеты.
lpd>В твоем примере move не использовался, только просто unique_ptr<>.
"Суслика видишь? А он есть!" (с)
lpd>Что ж страдайте, может тяготы кодинга отучат вас от темплейтства, когда программы будете писать, а не helloworld на С++17, где в одной функции файл открывается, и тамже закрывается.
Длиной решил померятся персонаж, который боится показать свой же находящийся в открытом доступе код?
Ну и да, возможность возвращать std::ostream из функции как раз помогает в ситуациях, когда файл закрывается совсем не там, где открывается.
lpd>Аргументы у меня закончились
У вас были аргументы? Помилуйте, где же? Дайте ссылочку, а то у меня ощущение, что упустил что-то важное.
Пока что ни от вас, ни от smeeld не было вообще ничего кроме стона о том, что "я не осилил" и намеков на то, что "уж мы то давно в индустрии, пишем такие системы, которые всем системам системы". Что-то странно, что такие монстры от софтостроения не могут даже вменяемого примера кода привести чтобы хоть как-то свои слова аргументировать.
Здравствуйте, smeeld, Вы писали:
S>Можно юзать unique_ptr, но придётся делать ему reset, что ничем от close/free не отличается. Так зачем оно всё тогда нужно?
Знаете что? А давайте вы хоть каким-нибудь образом докажите, что имеете отношение к разработке на C++ чего-то объемом больше 10KLOC.
А то из ваших слов получается, что вы именно что хеллоувордами и занимаетесь под пристальным надзором более старших товарищей, которые за вами сопли в коде подтирают. Иначе непонятно, как вы умудряетесь игнорировать вещи, которые делают разработку более-менее сложного софта сильно проще.
Пока что от вас было пару кусков почти что говнокода, который, как выяснилось, даже и не ваш. И вы сами не представляли, как же он работает.
S>Чтоб быть модным и молодёжным C++-ником?
Модным и молодежным C++ником я был лет эдак 27 назад. С тех пор при виде кода, в котором ресурсы закрываются вручную там, где это можно было бы делать посредством RAII, уже передергивает. Слишком много шишек набито от граблей, тщательно раскиданных олдскульщиками вроде вас.
