в случае с умными указателями - не только памятью, а объектами в общем, пояснение ниже
это без разницы, обьекты расположены в памяти. Ну, разве что вы имеете в виду некие ресурсы на диске, обьекты ядра и проч. Но суть все равно та же - автоматически освобождать ресурсы, когда они не нужны
Во-вторых, сам по себе GC не дает абсолютно ничего в сравнении с умными указателями, кроме некоторого снижения когнитивной нагрузки
он дает чудовищное снижение этой самой нагрузки
Попишите, например, год на сишарпе или там жаве, и потом опять на плюсах - разницу сразу прочувствуете.
т.е. недостаточная выразительность языка компенсируется за счет доп. расходов рантайма.
это не к языку, это к CLR/virtual machine
Что касается рантайма - разница там не сказать чтоб значительная, к тому же выделение памяти в managed heap сильно быстрее, чем в нативной, в силу отсутствия дефрагментации; да и современные gc нонеча работают уже совсем не так как давеча
а что такое ООП по вашему? Из трех "краугольных камней" ООП основополагающей является именно инкапсуляция. Мы объединяем логику, данные и ресурсы, в некоторую единую абстракцию - объект
одно из самых странных обьяснений ООП что я слышал, если честно
противоречит хотя бы тому же single responsibility
Иначе могут получаться "протекающие" абстракции - объект уничтожен, а ассоциированный с ним ресурс - нет. Что собственно и происходит в языках с GC.
не, не происходит:) Ну разве что с кастомными плохо спроектированными обьектами, использующими unmanaged resources
учитывая степень вашего понимания базовых концепций программирования хорошо конечно, что вы не пишете на с++...
каким образом понимание программирования на с++ связано с пониманием программирования вообще? Имхо, тут скорее наоборот, знание с++ требует столько умственных усилий, что на собственно программирование их и не остается
Конструкторы с пропертями можно для рекордов. Думаю, через пару версий втащат и в классы (ну глядя на C#10: как там акуратненько рекорды для структур всунули).
ну дай-то бог
а то мне в свое время переход на жаву тяжело дался, а потом появился котлин, и настало щастье
А потом я опять немного пересел на шарп, и возникли, знаете ли, вопросы
Есть много случаев, когда GC неуместен вообще, например когда у нас real-time или ограничены ресурсы.
насколько мне известно, в таких случаях будет использоваться скорее с, а не плюсы:))
Просто из-за того, что многие GC явно делают stop-the-world, а если даже и не делают, то накладные расходы на его работу все равно явно ненулевые.
конечно
как и на все фишечки std. Это стандартный трейдоф удобство вс перформанс; но чаще-то всего железо позволяет
помню, один товарищ (игродел) рассказывал, что они даже виртуальные функции стараются не использовать в борьбе за fps - переход по vtable ест пару тактов:) Но это давно еще было
Плюсцы это мультипарадигменный язык, и даже при написании кода в чисто процедурном стиле на плюсах вместо голых сей, можно получить немало полезных фишечек и удобств.
он адски сложный. Сколько там стандарт уже, полторы тыщи страниц? Честно, не вижу особого смысла его ни вспоминать, ни учить.
При этом, взять хотя бы вот это обсуждение - тут 80% дискуссии о том, как правильно использовать фишки языка. Не как правильно определить бизнес логику/архитектуру/алгоритмы, а как правилно использовать язык. Такая вещь в себе этот ваш с++ Причем, мне сейчас за этот камент еще и минусов насуют, очень нетерпимая коммьюнити:))
оно очень удобно и легко читается - поле зрения не засоряется всякими {} и break;
я же говорю, надо тех, кто жалуется на syntax sugar посадить на 7-8 жаву, с ее дикой многословностью и boilerplate, тогда будут ценить усилия разработчиков по созданию более лаконичных конструкций:)
Если сравнивать с Kotlin, то здесь работает тот же принцип, что помог C# стать лучше Java: когда язык проектировали не было легаси и можно было спокойно скопировать удачные решения Java, а неудачные - исправить.
Котлин - java compliant language, т.е., из него генерится ровно тот же байткод, что и из жавы. Т.е., женерики там - такое же г:(
Сейчас те же nullable reference types пришлось костылить потому что нельзя просто так исправить всю систему типов
Это да
Но в К. масса других полезных вещей. Давеча коллега опять присел на c#, так с удивлением спрашивал - как это в обьявлении класса нельзя конструктор с пропертями обьявить?!:)
Многие считают, что Java 17 даже предпочтительнее Kotlin
свят-свят
Вообще будет забавно, если в какой-то момент C# устареет как Java
нууу, это сомнительно. Все-таки у сишарпа основной разработчик один, а не эта рыхлая масса как в жаве
GC и smart pointers — очень разные концепции, и последние покрывают большинство сценариев, где GC уступает ручному управлению.
идею-то одна - автоматическое управление памятью
Да и в тех сценариях, где нужно ручное управление, умные указатели будут такими же (если не более) неуклюжими, как и gc Будем откровенны, смарт поинтеры - это все таки костыль в сравнении в нормальным gc (вот который в дотнете, например)
Это действительно не имеет никакого отношения к ООП. Это про RAII — гораздо более важную и центральную особенность C++. Не понимать и не использовать RAII == не знать плюсы.
всегда думал, что плюсы это больше про ООП, а не про способы управления ресурцами
К принципам ООП, впрочем, умные указатели отношения имеют мало (разве что в плане самих понятий "конструктор" и "деструктор", на которые они полагаются). Умные указатели можно встретить даже там где вообще нет ООП, например в проектах на чисто процедурном Си
тогда посыл статьи не совсем понятен она тогда всего лишь о том, что новонанятый прогер просто должен отлично знать современную std
Но это ж несерьезно. Умения программиста они не совсем о знании фреймворков
я к тому, что сишарп прекрасен, и в свое время был ваще самым прогрессивным и офигенным языком (да и сейчас, их имплементация женериков до сих пор на голову выше многих конкурентов)
Но вот эти новые фичи, на которые жалуются - они не новые, на самом деле, и уже б-м давно присутствуют в других языках. И сишарп в данный момент, увы, в позиции догоняющего
Поэтому использование new и delete часто является одним из признаков того, что человек пришел из языка, где нет умных указателей и подобных оберток и не привык к ним, либо вообще не подозревает о их существовании.
я уже давно живу в мире, где есть garbage collectors. Могу много рассказать про преимущества ручного управления памятью в частных случаях
Имхо, не-пользование unique_ptr это скорее про незнание отдельных аспектов стандартной библиотеки, а не про понимание принципов ооп
без virtual при delete вызовется только деструктор парента, но не производного, и вы можете получить утечку ресурсов.
ясно
ужас какой, как хорошо, что я на плюсах уже почти и не пишу; забыл уже все эти заморочки
Однако, в современных плюсах их использование есть моветон, а сишникам наверняка проще привыкнуть писать new/delete вместо malloc/free, чем освоить концепцию RAII.
new/delete - это чисто с++ концепции (вызов конструктора/деструктора при аллокации/очистке памяти), к С не имеют никакого отношения
Причём здесь ромбовидное наследование? Отсутствие виртуального деструктора в любом интерфейсном (абстрактном) классе — это выстрел себе в ногу.
Могу дать совет - попишите на жаве 8 (да или даже 11). После чего будете с дикой радостью приветствовать все эти новые фишки с#:)
Они отличные все, и жалобы мне напоминают стенания по поводу лямбд в свое время - все точно так же кричали, зачем это нужно, это непонятный бред а не нормальный язык!
Меня тогда, помню, вовсю на работе полоскали - какого хрена я втыкаю эти непонятные конструкции
вот реально, потерять год-два на.. что? Научишься чему-то новому и востребованному? Поднимешь какие-то скиллы до нужного уровня? Это ж болото и тупик, деградация себя как торговца своей рабочей силой на рынке
Мультиплатформенность PWA - это уже следствие мультиплатформенности браузеров
ну так об этом и речь
из того что я вижу, ее педалят как отличную альтернативу нативным мобильным приложениям, хотя проблемы браузерного приложения никуда не делись. Да и в последней винде уже об этом говорят, мол, все на PWA; MS вон, собирается аутлук на ней переписывать
меня это откровенно пугает, т.к. опыт пользования подобными приложениями (ms teams и прочие) - они тормозные и память жрут как не в себя.
Если уж совсем в дебри углубляться,
C++->C#->Java->Kotlin->Kotlin+C#+Java
Из них именно переход на чистую жаву был самый травмирующий:))
это без разницы, обьекты расположены в памяти. Ну, разве что вы имеете в виду некие ресурсы на диске, обьекты ядра и проч. Но суть все равно та же - автоматически освобождать ресурсы, когда они не нужны
он дает чудовищное снижение этой самой нагрузки
Попишите, например, год на сишарпе или там жаве, и потом опять на плюсах - разницу сразу прочувствуете.
это не к языку, это к CLR/virtual machine
Что касается рантайма - разница там не сказать чтоб значительная, к тому же выделение памяти в managed heap сильно быстрее, чем в нативной, в силу отсутствия дефрагментации; да и современные gc нонеча работают уже совсем не так как давеча
одно из самых странных обьяснений ООП что я слышал, если честно
противоречит хотя бы тому же single responsibility
не, не происходит:) Ну разве что с кастомными плохо спроектированными обьектами, использующими unmanaged resources
каким образом понимание программирования на с++ связано с пониманием программирования вообще? Имхо, тут скорее наоборот, знание с++ требует столько умственных усилий, что на собственно программирование их и не остается
ну дай-то бог
а то мне в свое время переход на жаву тяжело дался, а потом появился котлин, и настало щастье
А потом я опять немного пересел на шарп, и возникли, знаете ли, вопросы
насколько мне известно, в таких случаях будет использоваться скорее с, а не плюсы:))
конечно
как и на все фишечки std. Это стандартный трейдоф удобство вс перформанс; но чаще-то всего железо позволяет
помню, один товарищ (игродел) рассказывал, что они даже виртуальные функции стараются не использовать в борьбе за fps - переход по vtable ест пару тактов:) Но это давно еще было
он адски сложный. Сколько там стандарт уже, полторы тыщи страниц? Честно, не вижу особого смысла его ни вспоминать, ни учить.
При этом, взять хотя бы вот это обсуждение - тут 80% дискуссии о том, как правильно использовать фишки языка. Не как правильно определить бизнес логику/архитектуру/алгоритмы, а как правилно использовать язык. Такая вещь в себе этот ваш с++
Причем, мне сейчас за этот камент еще и минусов насуют, очень нетерпимая коммьюнити:))
оно очень удобно и легко читается - поле зрения не засоряется всякими {} и break;
я же говорю, надо тех, кто жалуется на syntax sugar посадить на 7-8 жаву, с ее дикой многословностью и boilerplate, тогда будут ценить усилия разработчиков по созданию более лаконичных конструкций:)
Котлин - java compliant language, т.е., из него генерится ровно тот же байткод, что и из жавы. Т.е., женерики там - такое же г:(
Это да
Но в К. масса других полезных вещей. Давеча коллега опять присел на c#, так с удивлением спрашивал - как это в обьявлении класса нельзя конструктор с пропертями обьявить?!:)
свят-свят
нууу, это сомнительно. Все-таки у сишарпа основной разработчик один, а не эта рыхлая масса как в жаве
идею-то одна - автоматическое управление памятью
Да и в тех сценариях, где нужно ручное управление, умные указатели будут такими же (если не более) неуклюжими, как и gc
Будем откровенны, смарт поинтеры - это все таки костыль в сравнении в нормальным gc (вот который в дотнете, например)
всегда думал, что плюсы это больше про ООП, а не про способы управления ресурцами
тогда посыл статьи не совсем понятен
она тогда всего лишь о том, что новонанятый прогер просто должен отлично знать современную std
Но это ж несерьезно. Умения программиста они не совсем о знании фреймворков
я к тому, что сишарп прекрасен, и в свое время был ваще самым прогрессивным и офигенным языком (да и сейчас, их имплементация женериков до сих пор на голову выше многих конкурентов)
Но вот эти новые фичи, на которые жалуются - они не новые, на самом деле, и уже б-м давно присутствуют в других языках. И сишарп в данный момент, увы, в позиции догоняющего
да это ж котлин!
вот мне интересно, насколько широко они используются
потому что если в виде
так такое и в котлине есть
Причем вот как раз там лямбды сделаны сильно лучше:)
я уже давно живу в мире, где есть garbage collectors. Могу много рассказать про преимущества ручного управления памятью в частных случаях
Имхо, не-пользование unique_ptr это скорее про незнание отдельных аспектов стандартной библиотеки, а не про понимание принципов ооп
ясно
ужас какой, как хорошо, что я на плюсах уже почти и не пишу; забыл уже все эти заморочки
new/delete - это чисто с++ концепции (вызов конструктора/деструктора при аллокации/очистке памяти), к С не имеют никакого отношения
[вопрос снимается, ниже ответили]
Могу дать совет - попишите на жаве 8 (да или даже 11). После чего будете с дикой радостью приветствовать все эти новые фишки с#:)
Они отличные все, и жалобы мне напоминают стенания по поводу лямбд в свое время - все точно так же кричали, зачем это нужно, это непонятный бред а не нормальный язык!
Меня тогда, помню, вовсю на работе полоскали - какого хрена я втыкаю эти непонятные конструкции
Я конечно извиняюсь, но new&delete с самого начала были именно что с++ фишки
А у вас постоянно встречается ромбовидное наследование, что ли? Это же фу-фу
да нафиг он нужен, этот кобол
вот реально, потерять год-два на.. что? Научишься чему-то новому и востребованному? Поднимешь какие-то скиллы до нужного уровня? Это ж болото и тупик, деградация себя как торговца своей рабочей силой на рынке
ну так об этом и речь
из того что я вижу, ее педалят как отличную альтернативу нативным мобильным приложениям, хотя проблемы браузерного приложения никуда не делись. Да и в последней винде уже об этом говорят, мол, все на PWA; MS вон, собирается аутлук на ней переписывать
меня это откровенно пугает, т.к. опыт пользования подобными приложениями (ms teams и прочие) - они тормозные и память жрут как не в себя.
Что-то оно выглядит, как очередная попытка сплясать на граблях мультиплатформенности.
Или я ошибаюсь?
и менеджмент такой - конечно, парни, давайте потратим пару месяцев на переосмысление, а клиенты подождут!
Когда бог создал время, он создал его достаточно(ц)
почему? Все кому-то пользователи