Обновить
0
0

Пользователь

Отправить сообщение

Если уж совсем в дебри углубляться,
C++->C#->Java->Kotlin->Kotlin+C#+Java

Из них именно переход на чистую жаву был самый травмирующий:))

в случае с умными указателями - не только памятью, а объектами в общем, пояснение ниже

это без разницы, обьекты расположены в памяти. Ну, разве что вы имеете в виду некие ресурсы на диске, обьекты ядра и проч. Но суть все равно та же - автоматически освобождать ресурсы, когда они не нужны

Во-вторых, сам по себе 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

Но это ж несерьезно. Умения программиста они не совсем о знании фреймворков

я к тому, что сишарп прекрасен, и в свое время был ваще самым прогрессивным и офигенным языком (да и сейчас, их имплементация женериков до сих пор на голову выше многих конкурентов)

Но вот эти новые фичи, на которые жалуются - они не новые, на самом деле, и уже б-м давно присутствуют в других языках. И сишарп в данный момент, увы, в позиции догоняющего

Новая реализация switch в 8-й версии C# на самом деле удобна

да это ж котлин!

fun fromRainbow(colorBand: Rainbow): RGBColor =
    when (colorBand)
    {
        Rainbow.Red -> RGBColor(0xFF, 0x00, 0x00)
        Rainbow.Orange -> RGBColor(0xFF, 0x7F, 0x00)
        Rainbow.Yellow -> RGBColor(0xFF, 0xFF, 0x00)
        Rainbow.Green -> RGBColor(0x00, 0xFF, 0x00)
        Rainbow.Blue -> RGBColor(0x00, 0x00, 0xFF)
        Rainbow.Indigo -> RGBColor(0x4B, 0x00, 0x82)
        Rainbow.Violet -> RGBColor(0x94, 0x00, 0xD3)
        else -> throw ArgumentException(message: "invalid enum value", paramName: nameof(colorBand)),
    };

вот мне интересно, насколько широко они используются
потому что если в виде

var expr: (Int)->Int = x -> when (x)
{
	1 -> 0
  0 -> 1
  else -1
}

так такое и в котлине есть
Причем вот как раз там лямбды сделаны сильно лучше:)

Поэтому использование new и delete часто является одним из признаков того, что человек пришел из языка, где нет умных указателей и подобных оберток и не привык к ним, либо вообще не подозревает о их существовании.

я уже давно живу в мире, где есть garbage collectors. Могу много рассказать про преимущества ручного управления памятью в частных случаях

Имхо, не-пользование unique_ptr это скорее про незнание отдельных аспектов стандартной библиотеки, а не про понимание принципов ооп

без virtual при delete вызовется только деструктор парента, но не производного, и вы можете получить утечку ресурсов.

ясно

ужас какой, как хорошо, что я на плюсах уже почти и не пишу; забыл уже все эти заморочки

Однако, в современных плюсах их использование есть моветон, а сишникам наверняка проще привыкнуть писать new/delete вместо malloc/free, чем освоить концепцию RAII.

new/delete - это чисто с++ концепции (вызов конструктора/деструктора при аллокации/очистке памяти), к С не имеют никакого отношения

Причём здесь ромбовидное наследование? Отсутствие виртуального деструктора в любом интерфейсном (абстрактном) классе — это выстрел себе в ногу.

[вопрос снимается, ниже ответили]

Могу дать совет - попишите на жаве 8 (да или даже 11). После чего будете с дикой радостью приветствовать все эти новые фишки с#:)

Они отличные все, и жалобы мне напоминают стенания по поводу лямбд в свое время - все точно так же кричали, зачем это нужно, это непонятный бред а не нормальный язык!

Меня тогда, помню, вовсю на работе полоскали - какого хрена я втыкаю эти непонятные конструкции

Использует ручное управление памятью с new и delete, вместо RAII и умных указателей;

Я конечно извиняюсь, но new&delete с самого начала были именно что с++ фишки

Для деструкторов забывает virtual :)

А у вас постоянно встречается ромбовидное наследование, что ли? Это же фу-фу

да нафиг он нужен, этот кобол

вот реально, потерять год-два на.. что? Научишься чему-то новому и востребованному? Поднимешь какие-то скиллы до нужного уровня? Это ж болото и тупик, деградация себя как торговца своей рабочей силой на рынке

Мультиплатформенность PWA - это уже следствие мультиплатформенности браузеров

ну так об этом и речь

из того что я вижу, ее педалят как отличную альтернативу нативным мобильным приложениям, хотя проблемы браузерного приложения никуда не делись. Да и в последней винде уже об этом говорят, мол, все на PWA; MS вон, собирается аутлук на ней переписывать

меня это откровенно пугает, т.к. опыт пользования подобными приложениями (ms teams и прочие) - они тормозные и память жрут как не в себя.

Что-то оно выглядит, как очередная попытка сплясать на граблях мультиплатформенности.

Или я ошибаюсь?

Это нормально, в этот момент нужно переосмыслить весь полученный опыт, без сожаления перепроектировать все аспекты

и менеджмент такой - конечно, парни, давайте потратим пару месяцев на переосмысление, а клиенты подождут!

Когда бог создал время, он создал его достаточно(ц)

Информация

В рейтинге
Не участвует
Откуда
Laval, Quebec, Канада
Зарегистрирован
Активность