Здравствуйте, kaa.python, Вы писали:
KP>Ну, допустим, я тебе ни раз приводил доводы почему современный C++ не торт. Допустим, у тебя есть взвод индусов, как из анекдота, которые булевое значение со строкой сравнивают, а продукт делать надо. И ты понимаешь, что используя C++ ты его ну никак не сделаешь. Вот вообще, никак, а с индусоустойчивым инструментом ты завершить продукт в срок и с ожидаемым качеством. Надо осмысленно инструмент подбирать, и, кстати, Си-с-классами куда более приемлемый язык для совсем уж бездарностей от программирования. А вообще, в идеале, надо брать Go
В идеале, надо отправить индусов на кухню готовить чикен массала, это у них хорошо получается, а программы доверить писать не индусам, независимо от используемого языка Но это, к сожалению, малодостижимый идеал...
Здравствуйте, Pzz, Вы писали:
Pzz>Это вообще, с точки зрения эффективности, злобный антипаттерн. Программы на C++, активно использующие всякое там автоматическое освобождение, имеют тенденцию создавать в куче объекты с очень коротким временем жизни, и сразу же их освобождать. Это ОЧЕНЬ медленно, медленнее, например, чем автоматическое управление памятью в языках со сборкой мусора, типа какого-нибудь даже яваскрипта.
Насчёт тормозов всё верно. Только ты вот это сейчас описал совсем не "программы на C++, активно использующие всякое там автоматическое освобождение", а скорее программиста на Java/C# севшего за C++. Потому как в обычном C++ приложение мелкие объекты с фиксированным временем жизни традиционно размещаются на стеке, а не в куче. Если же вдруг у нас встретилась очень редкая задача, в которой реальной требуется разместить множество мелких объектов в куче, то для этих целей используют специальные аллокаторы (например аллокатор на пуле), которые на порядки эффективнее и shared_ptr и любого сборщика мусора.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Представляю, во что превратится код программы, если в гуйне каждая кнопка поинлайнится. _>>Ну и во что превратися? Расскажи... ) Pzz>В очень много повторов практически одинакового кода.
Вообще то нет. Но предположим даже что да. И что бы было в этом страшного (если это конечно не программирование под МК, но там и вопросов таких не стоит)? Ведь речь о машинном коде, а не о написанном человеком...
_>>Кстати, та же самая Qt (которая родом из 90-ых и насквозь динамическая) уже давно научилась использовать лямбды в качестве слотов, чем я активно пользуюсь. Конечно ни к какой оптимизации это не приводит (да и не нужна она в GUI), т.к. внутри там всё равно динамика, причём даже ещё хуже чем обычные виртуальные функции C++. Но это без разницы, т.к. лямбды мне здесь нужны исключительно для удобства и простоты кода. Pzz>Лямбды и не нужны для оптимизации. Лямбды нужны именно что для читаемости кода.
Совершенно верно. И кстати, получается, что тут ты уже сам подтверждаешь, что код на современном C++ лучше читается, чем код на старом C++ или на C.
Да, ну и кстати лямбды C++ имеют в качестве побочного мелкого бонуса тот факт, что они реально повышают эффективность (в сравнение например с указателями на функции или виртуальными функциями объектов) кода, т.к. инлайнятся.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
Я сравнивал С++17 не с С, а с C++98.
_>Сборку мусора (во всяком случае эффективную, например как в JVM) невозможно просто опциональной прикрутить к системному языку — потребуется его весь переделывать. И именно, потребуется полностью изменить подход в размещение объектов в памяти — появятся ненужные скрытые поля. Из-за которых язык получит те самые тормоза и пожирание памяти, характерные для управляемых языков. Правда как бонус появится рантаймовая интроспекция (рефлексия), но это совсем не то, что требуется для языка, нацеливающегося на нашу C++.
В управляемых языках пожирание памяти не только из-за скрытых полей и сборки мусора, так что некоторое увеличение потребления памяти в C++ роли не играет. А для realtime сборку мусора можно сделать глобально отключаемой, ну или использовать умные указатели как опцию.
_>Семантика перемещения нужна в первую очередь совсем не для оптимизации (в конце концов в текущем коде она редко срабатывает автоматически, т.к. чаще перед ней срабатывает RVO), а как раз для возможности создания автоматического управления памятью (ну и кстати не только памятью, но и любыми другими ресурсами).
Ну тут многие move из-за оптимизации применяют, и даже что-то сравнивали по скорости с move и без. Когда при этом лепят мувы всего вподряд, это совсем абсурд.
_> Потому что без семантики перемещения ты просто физически не сможешь написать безопасный unique_ptr. Т.к. или у тебя будет разрешён оператор копирования (но тогда о каком "владение" можно будет говорить?) или же ты почти ничего не сможешь делать с таким указателем (ни в контейнер положить, ни в лямбду передать, вообще ничего). И кстати по тому же принципу работает множество сущностей стандартной библиотеки (потоки, мьютексы и т.п.), которые заявляют владение и соответственно не могут быть скопированы.
На копирование мьютексов я сам когда-то попал, так что в курсе этой проблемы. А unique_ptr не столь необходим, в подсчете ссылок в том же Objective-C его вроде как не было.
По-моему у тебя и у других любителей последних стандартов просто иррациональное желание усложнять код на ровном месте, отсюда все эти weak_ptr/std::move T&&/template<A,<B,<T>>>. Чем сложнее код, тем сильнее программист?. Наоборот же всегда было.
Насчет того примера что ты приводил с шаблонами, я не против простых шаблонов, какие были в C++98. Хотя и их можно заменить полиморфизмом, и делая это я бы не страдал из-за потерь быстродействия. Оптимизировать нужно только отдельные участки редкого софта вроде кодеков видео, и там (даже без оптимизации самого алгоритма)simd даст выигрыш на порядок выше всей этой вашей возни с шаблонами.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
>Правда как бонус появится рантаймовая интроспекция (рефлексия), но это совсем не то, что требуется для языка, нацеливающегося на нашу C++.
Здравствуйте, lpd, Вы писали:
lpd>Я сравнивал С++17 не с С, а с C++98.
Тогда откуда претензии к трехэтажным шаблонам? Позволю себе напомнить, что шаблоны, которые можно параметризовать шаблонами -- это не фишка C++17, и даже не фишка C++11. Это все появилось еще в C++98.
Даже полиморфные лямбды из C++14 -- это всего лишь синтаксический сахар для функторов, которые можно было вручную писать в C++98, вроде вот такого:
struct my_functor {
template<class A> void operator()(A arg) {...}
};
Ну и смею напомнить, что книга Александреску, которая показала широким массам, что такое современный C++, -- это ведь исключительно C++98.
А уж какие претензии к weak_ptr вообще не понятно. Это ведь не изобретение C++11. В Boost-е weak_ptr появился задолго до по вполне себе объективным причинам. Он не имеет отношения к особенностям языка, а служит для решения фундаментальной проблемы борьбы с циклическими ссылками в языках без полноценного автоматического GC. И аналоги Boost-овского weak_ptr были и в других библиотеках, если мне не изменяет склероз.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, lpd, Вы писали:
lpd>>Я сравнивал С++17 не с С, а с C++98.
S>Тогда откуда претензии к трехэтажным шаблонам? Позволю себе напомнить, что шаблоны, которые можно параметризовать шаблонами -- это не фишка C++17, и даже не фишка C++11. Это все появилось еще в C++98.
Я имею ввиду злоупотребление сложными шаблонами вообще, для чего в С++14/17 открывается простор возможностей.
S>Даже полиморфные лямбды из C++14 -- это всего лишь синтаксический сахар для функторов, которые можно было вручную писать в C++98, вроде вот такого:
Против лямбд ничего не имею, сам иногда применял.
S>А уж какие претензии к weak_ptr вообще не понятно.
Опять же имею ввиду именно головную боль с циклическими ссылкам, которую решает GC. И в некоторых случаях умные указатели тоже полезны, я не спорю, но показывать пальцем на каждый обычный указатель в программе и говорить, что это устаревший C++ считаю излишним. Впрочем где-то были библиотеки сборки мусора для C++, в следующий раз как(если) буду писать что-нибудь свое на C++, попробую.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
_>>>Просто из-за скорости изменения. А подходит только что-то типа STMStudio, в которой строится график значения, который можно сравнивать с параллельным ему графиком другой переменной — по сути такой софтверный осциллограф. M>>А, так для этого есть FreeMaster
_>Ну да, это того же типа продукт. Кстати, а он с st-link работает?
Честно говоря, я его не трогал. Его трогали коллеги, которые моторами крутят. Они вроде как через UART его использовали
_>>>Советую глянуть на такую штуку, как jlink (его кстати можно прошить даже в обычный st-link с Али). Там очень много вкусностей. И в том числе идёт RTT. M>>А в чем его плюс по сравнению с ST-Link'ом?
_>Ну для начала он банально намного быстрее. Т.е. понятно что это вообще не принципиальный параметр, но всё равно как сильно приятнее с ним. Ну и потом там есть множество мелких удобство. Одно из которых как раз "свой printf" (причём поделённый на каналы и в отдельном удобном приложение).
Хм. А как эти printf'ы будут шарить SWD с отладчиком?
Здравствуйте, lpd, Вы писали:
lpd>Я имею ввиду злоупотребление сложными шаблонами вообще, для чего в С++14/17 открывается простор возможностей.
Так это "злоупотребление" появилось как только стали широко доступны компиляторы с более-менее приличной поддержкой шаблонов. Т.е. где-то рубеж 1990-х и 2000-х. Напомню, что само понятие метапрограммирования на шаблонах открыли в середине 1990-х.
Современные стандарты лишь сделали работу с шаблонами сильно проще.
lpd>Опять же имею ввиду именно головную боль с циклическими ссылкам, которую решает GC.
Ну так C++ -- это язык без GC. Странно ставить в вину языку то, что является одним из немногих оставшихся конкурентных преимуществ.
lpd>но показывать пальцем на каждый обычный указатель в программе и говорить, что это устаревший C++ считаю излишним
Не вы один так считаете. Проблему составляют не голые указатели вообще, а владеющие голые указатели. Вот владеющие голые указатели -- это признак потенциальных проблем. Но, опять же, такое отношение к голым указателям не сегодня появилось, а как раз после появления C++98.
Современный C++ здесь разве что устранил проблему с auto_ptr.
Здравствуйте, so5team, Вы писали:
S>Так это "злоупотребление" появилось как только стали широко доступны компиляторы с более-менее приличной поддержкой шаблонов. Т.е. где-то рубеж 1990-х и 2000-х. Напомню, что само понятие метапрограммирования на шаблонах открыли в середине 1990-х.
Шаблоны в 90-х появились. Но злоупотребление метапрограммированием и раньше было, только вместо шаблонов использовались макросы с параметрами.
Здравствуйте, alex_public, Вы писали:
_>Насчёт тормозов всё верно. Только ты вот это сейчас описал совсем не "программы на C++, активно использующие всякое там автоматическое освобождение", а скорее программиста на Java/C# севшего за C++. Потому как в обычном C++ приложение мелкие объекты с фиксированным временем жизни традиционно размещаются на стеке, а не в куче.
Когда ты размещаешь std::string на стеке, буфер-то еёйный все равно размещается в куче.
Здравствуйте, alex_public, Вы писали:
_>Вообще то нет. Но предположим даже что да. И что бы было в этом страшного (если это конечно не программирование под МК, но там и вопросов таких не стоит)? Ведь речь о машинном коде, а не о написанном человеком...
Кэш инструкций выносится, производительность падает, батарейка быстрее садится...
_>Да, ну и кстати лямбды C++ имеют в качестве побочного мелкого бонуса тот факт, что они реально повышают эффективность (в сравнение например с указателями на функции или виртуальными функциями объектов) кода, т.к. инлайнятся.
Ну лямбду, скорее всего, потом позовут, когда чего-нибудь случится или кончится. А в промежутке она будет храниться в виде указателя.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Pzz, Вы писали:
Pzz>>Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать.
IID>То ли дело в чистом си! Нужна копия сокета при accept — выделим память и алга в нее memcpy. В результате CVE-2017-8890, чудесная дырочка, через которую буханки трескались как орешки. С success rate выше 98% (сорян, но выиграть две гонки с 100% рейтом это уже фантастика).
_>Т.е. вот сейчас серьёзно заявляешь, что такой код: _>проще такого: _>???
_>>>Во-вторых естественно вопрос производительности. Статический полиморфизм очевидно на порядки эффективнее, т.к. вызов не просто идёт напрямую (а не косвенно, как в случае виртуальной функции), но и практически гарантированно инлайнится.
я бы всем любителям "статического полиморфизма" распечатывал бы их говнокод на формате A3, сворачивал бы в трубочку и засовывал бы им в очко, потому что только пассивные тридварасы могут предпочесть нечитабельное неизолируемое негрепабельное неотлаживаемое говно тёплому ламповому полиморфизму на интерфейсах.
B>А о том, что С++ повторяет судьбу С и постепенно сужается в узкие вышеозначенные области. Причем последние две области будут, скорее всего, относительно динамично переползать на Go и Rust. И только графика и ML, в силу мощных устоявшихся библиотек, еще долго будут тащить за собой C++.
из C++ надо убегать роняя тапки, rust кстати не взлетит, потому что птичий язык для извращенцев-мазохистов (а-ля C++ или Haskell), а не для инженеров. Го взлетит, потому что наоборот, практичный язык для инженеров, а не теоретиков кайфа.
Здравствуйте, alex_public, Вы писали:
_>Сборку мусора (во всяком случае эффективную, например как в JVM) невозможно просто опциональной прикрутить к системному языку — потребуется его весь переделывать. И именно, потребуется полностью изменить подход в размещение объектов в памяти — появятся ненужные скрытые поля.
Дело не в ненужных скрытых полях. Они и так, кстати, есть. Когда аллоцируешь объект с кучи, где-то там перед ним есть невидимая информация, необходимая для организации кучи (ссылки на предыдущий/следующий занятый кусок памяти, размер куска памяти и т.п.). Там же и нашлось бы место для сборщика мусора.
Проблема в том, что разглядывая C++'ный объект, нельзя, в общем-то, понять, есть в нем указатели, которые должен учитывать сборщик мусора, или нет. Вот например:
struct foo {
enum { PTR, INT } type;
union {
void *ptr;
int val;
};
};
Вот как понять по такому объекту, указатель там сейчас лежит, или целое число?
Или взять, к примеру, uintptr_t. В нем может быть и указатель, и целое, стандартом это разрешено.
Или, к примеру, если мы освобождаем память, на которую указывает указатель, никто ведь не требует его, указатель, занулять. И никто и не зануляет. А сборщику мусора как понять, принимать во внимание такой указатель, или нет?
Ну т.е., я понимаю, да, такие объекты лучше не заводить, они потенциально опасны и все такое. Но что делать, если они уже есть?
Здравствуйте, AleksandrN, Вы писали:
AN>Шаблоны в 90-х появились. Но злоупотребление метапрограммированием и раньше было, только вместо шаблонов использовались макросы с параметрами.
Макросы с параметрами сроду не были тьюринг-полнымы, так что на них было особо не развернуться.
Здравствуйте, Мирный герцог, Вы писали:
МГ>я бы всем любителям "статического полиморфизма" распечатывал бы их говнокод на формате A3, сворачивал бы в трубочку и засовывал бы им в очко, потому что только пассивные тридварасы могут предпочесть нечитабельное неизолируемое негрепабельное неотлаживаемое говно тёплому ламповому полиморфизму на интерфейсах.
Тебе понадобится принтер, который печатает на наждачной бумаге.
Здравствуйте, lpd, Вы писали:
_>>Сборку мусора (во всяком случае эффективную, например как в JVM) невозможно просто опциональной прикрутить к системному языку — потребуется его весь переделывать. И именно, потребуется полностью изменить подход в размещение объектов в памяти — появятся ненужные скрытые поля. Из-за которых язык получит те самые тормоза и пожирание памяти, характерные для управляемых языков. Правда как бонус появится рантаймовая интроспекция (рефлексия), но это совсем не то, что требуется для языка, нацеливающегося на нашу C++. lpd>В управляемых языках пожирание памяти не только из-за скрытых полей и сборки мусора, так что некоторое увеличение потребления памяти в C++ роли не играет. А для realtime сборку мусора можно сделать глобально отключаемой, ну или использовать умные указатели как опцию.
Ещё раз повторюсь: отключаемый сборщик мусора в C++ есть и уже давно (https://en.wikipedia.org/wiki/Boehm_garbage_collector). А вот если он тебя чем-то не устраивает и ты хочешь сборщик мусора уровня jvm, то тогда тебе придётся полностью переделать язык, сделав его не пригодным для ключевых ниш C++.
_>>Семантика перемещения нужна в первую очередь совсем не для оптимизации (в конце концов в текущем коде она редко срабатывает автоматически, т.к. чаще перед ней срабатывает RVO), а как раз для возможности создания автоматического управления памятью (ну и кстати не только памятью, но и любыми другими ресурсами). lpd>Ну тут многие move из-за оптимизации применяют, и даже что-то сравнивали по скорости с move и без. Когда при этом лепят мувы всего вподряд, это совсем абсурд.
Семантика перемещения действительно оптимизирует код. Причём в некоторых случаях это работает даже без правки кода (как раз из-за того, что она стала применяться по умолчанию). Т.е. если просто перекомпилировать код с C++98 на C++11, то он может стать гораздо эффективнее. Однако это увеличение гораздо менее важно, чем то, что принесла семантика перемещения в архитектурном плане.
_>> Потому что без семантики перемещения ты просто физически не сможешь написать безопасный unique_ptr. Т.к. или у тебя будет разрешён оператор копирования (но тогда о каком "владение" можно будет говорить?) или же ты почти ничего не сможешь делать с таким указателем (ни в контейнер положить, ни в лямбду передать, вообще ничего). И кстати по тому же принципу работает множество сущностей стандартной библиотеки (потоки, мьютексы и т.п.), которые заявляют владение и соответственно не могут быть скопированы. lpd>На копирование мьютексов я сам когда-то попал, так что в курсе этой проблемы. А unique_ptr не столь необходим, в подсчете ссылок в том же Objective-C его вроде как не было.
Ха, так причём тут unique_ptr и подсчёт ссылок? Последнее — это shared_ptr и у него естественно нет никаких вопросов с копированием. А в unique_ptr никаких подсчётов ссылок нет.
lpd>По-моему у тебя и у других любителей последних стандартов просто иррациональное желание усложнять код на ровном месте, отсюда все эти weak_ptr/std::move T&&/template<A,<B,<T>>>. Чем сложнее код, тем сильнее программист?. Наоборот же всегда было.
Ну ОК, давай напиши сущность с функциональностью unique_ptr, используя любые возможности C++98 (собственно можно хоть C++20 взять без семантики перемещения и это ничего не изменит).
lpd>Насчет того примера что ты приводил с шаблонами, я не против простых шаблонов, какие были в C++98. Хотя и их можно заменить полиморфизмом, и делая это я бы не страдал из-за потерь быстродействия. Оптимизировать нужно только отдельные участки редкого софта вроде кодеков видео, и там (даже без оптимизации самого алгоритма)simd даст выигрыш на порядок выше всей этой вашей возни с шаблонами.
Дело не в быстродействие, а в удобстве. На кой нужны все эти интерфейсы и прочая ересь, если при статическом полиморфизме компилятор всё равно всё проверит и даже более строго, чем с виртуальными функциями.
Здравствуйте, student__, Вы писали:
>>Правда как бонус появится рантаймовая интроспекция (рефлексия), но это совсем не то, что требуется для языка, нацеливающегося на нашу C++. __>Проблема в том, что в С++ и статической-то нет.
Полностью согласен. На мой взгляд это самая большая проблема C++, которую следовало бы решать в первую очередь, вместо всяких ненужных модулей и т.п. А они вместо этого отложили статическую интроспекцию не раньше C++23...
Но это, к сожалению, малодостижимый идеал...
