KOPOJI

Pilarentes, без перехода на личности и оскорблений неинтересно, очевидно жеж

0

@tezaurismosis

Война поугасла как-то, но стоит только вбросить - вспыхнет снова.
Мы не против, только правила соблюдайте.

0

@Curry

Байт код проще реинжинерить чем машинный. То есть, если не хотим показывать алгоритм, или защититься от копирования, то лучше использовать те языки, которые компилируются в машинный код. То есть, лучше С++.

1

@Pilarentes

Curry,
можно писать код на шарпе и юзать библиотеки написанные на плюсах)

0

Vourhey

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

0

@Curry

Вот! Значит плюсы лучше, т.к. можно всё на плюсах, но не наоборот.
И потом, отдельную либу проще ковырять чем большой экзешник.
Случалось что и нативные расковыривали, но это сложнее.

0

@Usaga

Эти "не везде" - настолько же массовое явление как и пользователи Windows XP. А значит потеря это части пользователей - ни что на фоне выгод от ускорения разработки за счёт более удобных языков.

Плюсы рулят там, где нужна плотная работа с железом или где максимальная производительность является конкурентным преимуществом (движок браузера, кодек, архиватор и т.д). А смотреть на плюсы только как на язык с обфускаций из коробки... Ну хз.

0

@tezaurismosis

Есть инструменты для компиляции .NET сразу в машинный код
Для UWP: .NET Native
Для других платформ: Mono AOT
+ инструменты для компиляции в LLVM

0

@Curry

На самом деле, про подлодку я упомянул для наглядности. Облако не приемлемо в более частых случаях. Я сталкивался с тем что заказчику не нравится вариант аренды облака потому что не хотят светить данные накапливаемые в базе, не уверены что сервер не прикроют или не поднимут существенно аренду. Когда всё у тебя под рукой, оно, как то спокойнее. Сделали клинент серверный вариант некой системы, так в аренду никто не взял, все захотели установить серверную часть на своих серверах, пришлось туда защиту вешать, а для этого частично переписывать.
не только, но к тому же.
Интересно, насколько такой вариант получается взломоустойчивый? Вряд ли, конечно, в exe заворачивают MSIL код вместе с CLR без рефлексии, но, возможно, каждая MSIL-команда компилируется в одинаковый набор машинных инструкций, а то и в вызов функции выполняющей одну инструкцию. Впрочем, тут мне врят ли ответят, со специалистами по защите не густо.
Собственно, защищают и MSIL, вот, например. А уж насколько эта защита реально действенна, вопрос. Больше 10 лет назад я с ними говорил тет-а-тет, и тогда мне высказались в духе "у народа есть желание защищать .NET сборки, ну, если хотят, пожалуйста, но, на самом деле ...". Однако, 10 лет прошло, защита могла и улучшиться.

0

@NeoMatrix

То я и вижу, как все современные версии браузеров не едят память и быстро работают на современных же машинах в современных же ОСях.
Что 15 лет назад едва ворочалось при никаком подключении, что сейчас на оптике и современном железе - всё едино по скорости. Только почему-то каждая вкладка не меньше 50 - 100 метров оперативы норовит сожрать.

0

@Curry

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

0

@Usaga

Так собственные сервера никто не отменял. Что сразу облака-то? Ну и те, кто ваши клиент-серверные системы покупает, чтобы у себя разворачиваать, обычно их взломом не занимаются, ибо тупо бессмысленно.

Ну, так возможностей стало не в пример больше, чем раньше, вплоть до трёхмерной графики. Ну и сравните браузер на плюсах с браузером на яве или C#, если таковой найдёте)

0

@tezaurismosis

Да, там так не делают, инструмент просто прогоняет JIT-компиляцию и заталкивает полученный машинный код в экзешник. Вообще, основная цель этих манипуляций - увеличение производительности.

По поводу обфускации и проч. была тема в бейсике с множеством таких ухищрений: Марафон по безопасности
Но средства с тех пор наверняка были сильно усовершенствованы.

1

@Curry

Странное утверждение. Кругом полно ломаного софта. Как он возникает? Кто то покупает, а потом кто то имеющий к нему доступ, ломает.

В общем то C# неплохой язык. Были бы ещё в нём деструкторы ...

0

@tezaurismosis

Если здесь идет речь о деструкторах с *гарантированным немедленным* уничтожением объекта, то для языка, работающего со сборщиком мусора его наличие бессмысленно, имхо. Управляемая куча в .NET имеет сложную структуру с поколениями объектов, процедурой десегментации памяти, предсказания времени удаления объекта и проч. Немедленное удаление объекта оттуда по воле программиста наверняка ухудшит производительность этого процесса.

Деструкторы (финализаторы), которые просят сборщик удалить объект, когда ему будет удобно - в языке есть.

0

@Curry

Отнюдь. Память под объект может удалять GC и позже, но часты ситуации когда нужно выполнить действие при логическом завершении работы с объектом, закрытие файла, сокета,окна и т.п. В C# это решается при выходе из скопа конструкцией using (лишней для С++) и решается только вручную если объект содержит в себе другие объекты требующие Dispose. Тогда нужно создать Dispose для содержащего объекта и вызывать Dispose тех вложенных, для которых это нужно.
Между тем, разумно эти действия один раз описать в деструкторе объекта вызов которого вставлялся бы компилятором автоматически в вышеописанном случае, а не каждый раз вызывать его вручную. Я не понимаю, как GC этому мешает.

0

@Usaga

А B2B ломанного софта тоже полно вокруг? Я вот особо не видел. Ибо смысла не имеет этого делать, там весь прикол в поддержке от производителя.

Добавлено через 6 минут
А как компилятор определит, что диспозящийся объект является единоличным владельцем вложенных объектов? Будет анализировать все факты обращения к этим объектам? В плюсах-то это происходит только для объектов хранящихся в виде значений в полях класса, а в шарпах с этим туго. GC тут ни причём. Заберите из плюсов возможность держать объекты в полях класса оставив только ссылки и указатели и будет всё ровно тоже самое, без GC.

0

@tezaurismosis

Эти объекты не находятся под управлением GC, он управляет лишь ссылками на них. Поэтому они в терминологии .NET именуются неуправляемыми ресурсами.
Точно также это удаляется в C++:
- для неявного удаления есть using (C#) и он схож с RAII (C++)
- для явного удаления есть Dispose() (C#) и он схож с delete (C++)
То есть одни и те же концепции реализованы в обоих языках, но по-своему.

0

@Curry

А я очень даже. Из практики. Ковыряют только так.
Смартпоинтеры. Они и находятся в полях класса, а ссылки уже в них. Но что бы сделать смартпоинтеры нужно иметь автовызываемые деструкторы. Это не обязательно встраивать в язык (хотя в php встроили). С компилятора достаточно обеспечить вызов деструктора. На его основе будет применён подходящий смартпоинтер. В одних случаях (для одного типа смартпоинтера) объект не доступен никому кроме одного объекта, в другом может быть счётчик ссылок, передача владения. Да, можно, выбрать не тот смартпоинтер, но и в C# можно не вызвать деструктор. В целом подход с деструкторами логичнее и лучше соотвествует принципам ООП - объект сам за собой подчищает. Используя объект не нужно знать, есть ли у него деструктор вообще.
И, если так назвать, то сразу лучше станет? Я в курсе что GC управляет только распределением в оперативке.
Да. И то ввели не сразу. Соотвествует просто выходу из скопа объекта с деструтором в С++.
Вот тут и появляется вместо автоматики ручная коробка. Для вложенных объектов его нужно вызывать самим. В скольки местах программы используется объект, в стольки и вызывать. А лучше указать что это нужно 1 раз, при описании объекта.

0

@tezaurismosis

Ручных коробок в шарпе предостаточно. Этот язык только на первый (и на второй) взгляд даёт ощущение отсутствия проблем с управлением памятью.
Но конкретные кейсы по управлению утечками в управляемом коде можно пересчитать по пальцам.
Сколько там способов выстрелить себе в ногу в C++? (хотя бы по части памяти)
Уже который раз упоминается как недостаток C#. Что мешает в перегрузке финализатора или Dispose() прописать закрытие соединения с неуправляемым ресурсом?
Создаете класс, инкапсулирующий соединение с БД/хэндлером окна/каналом между процессами/etc., и делаете в деструкторе что нужно.

0