Здравствуйте, kaa.python, Вы писали:
SVZ>>Т.е. взломать программу с включенный RTTI это вообще не проблема. Для коробочных продуктов это жЫрный минус.
KP>А что вы такое пишете, что это стало проблемой?
Софт не для хомячков. Рабочее место стоит от 2 до 7 килобаксов в год. Правда у конкурентов цены добегают до 70+ килобаксов за рабочее место.
KP>Впервые виде что этим кто-то в мире коробочного софта заморачивается.
Народ таки заморачивается и тот же Адоб в своё время рассылал пользователям палёного софта "письма счастья" в большом количестве.
Кто-то привлекает юридический ресурс для борьбы с палёнкой.
Мы тоже решили проблему — провели аудит, выключили RTTI, по рекомендациям переделали защиту.
В итоге кряки попадаются только для древней версии 2015 года.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, lpd, Вы писали:
lpd>Но ты в исходном посте не смог обойтись без гиперболизации и упомянул перегрузку операторов и шаблоны.
Были перечислены претензии, которые нам озвучивались. В частности, что-то вроде
> мне не нравится библиотека, API которой позволяет писать вот так: > this >>= new_state;
Так что каждый может строить об окружающем его мире любые предположения, но когда этот самый окружающий мир начинает демонстрировать свое нескончаемое разнообразие, то остается только развести руками. Каких-то пожеланий или претензий не услышишь.
Здравствуйте, so5team, Вы писали:
CC>>А что, остальные просят такие же "каналы как в go"? S>Остальные просят "такие же, но с перламутровыми пуговицами".
Скорее уж остальные пожимают плечами и говорят "а нафига оно нам?"
Это ж всего лишь один из подходов. Который в каких то случаях отлично подходит, а в каких то как собаке пятая нога.
S>Самые замшелые вообще говорят, что диды без каналов писали и мы будем.
Не, ну есессна, go channels is the greatest thing since sliced bread! По крайней мере пока не начнут все фапать вприсядку на что нить другое.
S>Просто использовать то, что лучше подходит под конкретный пример.
Ну дык именно так на деле и делают.
S> И спокойно принимать то, что в стандартную библиотеку C++ входят вещи, которые устраивают далеко не всех (как по своему дизайну, так и по производительности).
Ну так надо тогда принять и то, что стандартную библиотеку критикуют за то, что в неё напихали то, что устраивает далеко не всех как по своему дизайну, так и по производительности
Содержимое std уже давно воспринимается как что то, что пригодно скорее для быстрого прототипирования. Дальше либо оставляют как есть (если всё устраивает) либо таки меняют на более подходящие сторонние "велосипеды".
Здравствуйте, so5team, Вы писали:
CC>>А реально ли надо ли все эти навороты? S>Как правило, лямбды и шаблоны позволяют писать меньше (иногда сильно меньше) и получать более безопасный код.
Угу, но там, где они к месту.
Если же начать писать в стиле "меня долго грыз Александреску" получится только хуже. В итоге параметризуется всё и всем, и то, чем параметризовали тоже параметризуется.
Здравствуйте, CreatorCray, Вы писали:
CC>Скорее уж остальные пожимают плечами и говорят "а нафига оно нам?" CC>Это ж всего лишь один из подходов. Который в каких то случаях отлично подходит, а в каких то как собаке пятая нога. CC>Не, ну есессна, go channels is the greatest thing since sliced bread! По крайней мере пока не начнут все фапать вприсядку на что нить другое.
Нет, речь не о тех, кто знает о том, что такое каналы и для чего они нужны. Речь о тех, что думает, что им достаточно одним mutex-ом закрыть разделяемую переменную, через которую потоки будут обмениваться значениями. И, может быть, которые со временем дойдут до того, что одну переменную, скорее всего, придется заменить каким-то message-queue. Которую, конечно же, напишут сами на коленке.
CC>Ну так надо тогда принять и то, что стандартную библиотеку критикуют за то, что в неё напихали то, что устраивает далеко не всех как по своему дизайну, так и по производительности
Одно дело, когда критикуют и предлагают варианты исправления. Другое -- когда просто кричат "хэш-таблицы в C++ говно, я взял и у меня все тормозит".
CC>Содержимое std уже давно воспринимается как что то, что пригодно скорее для быстрого прототипирования. Дальше либо оставляют как есть (если всё устраивает) либо таки меняют на более подходящие сторонние "велосипеды".
А это одна из ее задач. Другая задача -- это дать некий общий словарь, посредством которого смогут общаться модули/библиотеки, разработанные разными командами в разное время. Можно много плохого сказать в адрес std::string, но когда std::string заменил множество самописных и несовместимых между собой велосипедов, то стало сильно легче.
Здравствуйте, CreatorCray, Вы писали:
S>>Как правило, лямбды и шаблоны позволяют писать меньше (иногда сильно меньше) и получать более безопасный код. CC>Угу, но там, где они к месту.
А кто судья?
CC>Если же начать писать в стиле "меня долго грыз Александреску" получится только хуже. В итоге параметризуется всё и всем, и то, чем параметризовали тоже параметризуется.
Опять же, вы так говорите, как будто это обязательно плохо. Что, опять же, может зависеть от того, кто является судьей.
Здравствуйте, CreatorCray, Вы писали:
>>> this >>= new_state;
CC>Если это единственный вариант использования то претензия совершенно обоснованная. Это довольно укуренный способ.
Не единственный и появившийся в результате накопленного опыта работы. Но проще же не вникать, а просто сказать про укуренный способ.
Собственно, еще одна демонстрация претензий к пуговицам не того цвета.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Софт не для хомячков. Рабочее место стоит от 2 до 7 килобаксов в год. Правда у конкурентов цены добегают до 70+ килобаксов за рабочее место.
Тем более непонятно, с чего тут проблема, я было думал что игры пишете, хотя игроделы(как минимум Юбисофт) используют более интесные практики с отложенным неопределённым поведением приложения при детектировании взлома. Обидно, как мне кажется, именно подобные "здравые" идеи в духе запрета исключений или RTTI и отваживают желающих начинать новую разработку на C++.
SVZ>Мы тоже решили проблему — провели аудит, выключили RTTI, по рекомендациям переделали защиту. SVZ>В итоге кряки попадаются только для древней версии 2015 года.
Основная проблема продуктов такого класса не кряки. Те кто крякал всяко продукт не купят, но есть еще одна категория: те кто реально купил продукт и считает что он у него лицензионный, но это не так. Грубо говоря, у вас есть продукт за 5К, а на неком сайте, по бешеной "скидке в 80% только сегодня и только у нас" продается ваш продукт за 1К. Тот кто его купил думает, что купил оригинал, но... но он купил сломанную версию. Качественно сломанную версию, а не барахло с торрента или то, к чему есть кряк.
Здравствуйте, so5team, Вы писали:
S>Как раз очень широкое применение C++,
Так было 10 лет назад, сейчас С++ вытеснен практически из всех этих ниш.
S>от встраиваемых систем
Python, C
S>hard real-time систем
C
S>до сервер-сайда
Go, Python, Java и ко
S>HPC
Fortran, R, Python
S>GUI
Отчасти, но сильно потеснили Objective-C, Swift, C#
S>игр
Только AAA
S>мобильных приложений
Swift, Kotlin
S>Поинт был в том, что в C++ из-за его широкого применения в самых разнообразных условиях невозможно создать простые и удобные инструменты, которые бы подходили всем.
Не соглашусь. Масса языков поставляется с батарейками на все случаи жизни, никаких проблем нет, а вот С++ слишком долго пытается угодить всем, причем часто в угоду маргиналам игнорируя интересы большинства. Дурацкие рассуждения "на утюге нет фаловой системы, значит и в С++ это не нужно" повторяются до сих пор с серьезным лицом.
S>Поэтому высказывания о том, что в C++ нет таких же удобных каналов, как в Go, в реальности разбиваются о то, что подобные каналы в C++ будут использовать хорошо, если 30% разработчиков. А остальные не смогут этого сделать по совершенно разным причинам. В том числе и идеологическим.
Снова ты подметил самую суть — С++ давно не инструмент, а вопрос идеологии.
S>В том числе и потому, что "у нас на проекте много низкоквалифицированных программистов, поэтому им нельзя давать ничего со сложной шаблонной машинерией внутри".
Именно, поэтому так хорошо, например Go зашел.
DI>>Это все конечно прекрасно, но нужно оно в первую очередь разработчикам библиотек, а на обычного разработчика давно положен болт. Каналы, корутины, модули, идет 2019 год.
S>Ну вот и хэш-таблицы, и регулярные выражения в стандартной библиотеке C++ присутствуют с 2011-го. Но критики в их адрес больше, чем хотелось бы. Или вот в C++20 завезут fmtlib и все равно будет полно возгласов, что мой любимый домашний велосипед лучше и быстрее.
Нет, нормально их используют. Кто-то конечно всегда критиковать будет, такой контингент всегда есть, еще какому-то малому проценту объективно то, что в стандартной библиотеке может не подойти и они напишут свое, но подавляющее большинство просто использует и в большинстве кейсов это нормально работает.
S>Это особенность мира C++: чтобы не завезли в стандарт, все это будет раскритиковано.
SVZ>Нанятый ревёрсер принес практически идентичный нашему исходный код программы, только что не с комментариями. SVZ>Т.е. взломать программу с включенный RTTI это вообще не проблема. Для коробочных продуктов это жЫрный минус.
Вот после таких сообщений у меня появляются мысли, которые мешают спать. Как так получается, что в C++ RTTI кому-то мешает, а в языках типа JRE интроспекция только помогает?
Здравствуйте, Masterspline, Вы писали:
SVZ>>Нанятый ревёрсер принес практически идентичный нашему исходный код программы, только что не с комментариями. SVZ>>Т.е. взломать программу с включенный RTTI это вообще не проблема. Для коробочных продуктов это жЫрный минус.
M>Вот после таких сообщений у меня появляются мысли, которые мешают спать. Как так получается, что в C++ RTTI кому-то мешает, а в языках типа JRE интроспекция только помогает?
Наверное потому, что JRE используют на сервере и в корпоративных системах, где реверсинг с целью взлома/клонирования не актуален.
А десктопные приложения клепают на С++, Шарпе, там проблема защиты бинарников актуальна.
Видимо поэтому Шарписты очень любят обфускаторы.
_____________________
С уважением,
Stanislav V. Zudin
NB>>и стандартный механизм установки зависимых пакетов из репозитория. S>Я бы сказал это главная проблема С++ на сегодня. И в обозримом будущем она не решится. Другая большая проблема это системы сборки, но тут CMake стал почти стандартом (хоть я его и не очень люблю, но задачу решить можно).
Чет мне кажется, что вы с предыдущим комментатором не разделяете системный пакетный менеджер и менеджер пакетов языка.
IMHO, не нужно путать пакетный менеджер языка и пакетный менеджер OS. Первый нужен во время написания проекта (и сборки пакетов для OS пакетным менеджером OS). Второй нужен для установки зависимостей в OS. Пакетный менеджер языка позволяет легко использовать разные версии зависимостей во время разработки (например, если нужно добавить новую фукнциональность в проект "калькулятор", то меняется и GUI калькулятора и libcalculator, который может запросто быть отдельным проектом, в результате чего будут альфа версии двух проектов GUI и lib). Менеджер пакетов OS очень в этом ограничен и к тому же возникает отдельный шаг — сборка пакета и установка в OS, после каждого изменения lib. Т.е. после каждого изменения libcalculator придется не только его пересобрать, но и собрать пакет OS и установить его, и хорошо, если libcalculator использует только разрабатываемое приложение, а если это libpng (установить alpha версию libpng в OS параллельно со стабильной вряд ли получится, да и использовать разные трюки типа docker тоже удобства не добавляет, к тому же, а если libpng будет использовать компилятор — рекурсия, однако).
Здравствуйте, so5team, Вы писали:
CC>>Угу, но там, где они к месту. S>А кто судья?
Здравый смысл.
CC>>Если же начать писать в стиле "меня долго грыз Александреску" получится только хуже. В итоге параметризуется всё и всем, и то, чем параметризовали тоже параметризуется. S>Опять же, вы так говорите, как будто это обязательно плохо.
Угу, когда простой класс, в котором пара полей и одно единственное применение в проекте с самого начала параметризуется бОльшим колвом template parameters чем там вообще есть типов — это плохо.
S> Что, опять же, может зависеть от того, кто является судьей.
Опять тот же здравый смысл.
Здравствуйте, so5team, Вы писали:
S>Не единственный
Уже хорошо.
S>Но проще же не вникать, а просто сказать про укуренный способ.
Он укуренный. Из той же оперы что и перекрытие оператора "запятая".
Да можно, да работает. Нет не стоит так делать без крайней на то нужды.
Здравствуйте, Masterspline, Вы писали:
M>Чет мне кажется, что вы с предыдущим комментатором не разделяете системный пакетный менеджер и менеджер пакетов языка.
pip он системный или языковой? NPM? Не знаю что там в го и расте, но сдается мне дела там получше, чем в С++.
M>IMHO, не нужно путать пакетный менеджер языка и пакетный менеджер OS. Первый нужен во время написания проекта (и сборки пакетов для OS пакетным менеджером OS).
Ну вот такого стандартного (покрывающего значительную часть самых распространенных либ на всех 3 платформах) — нет.
Если хочется рассказать что-то интересное по теме, то уместно будет рассказать о CI/CD проекта на С++ с поддержкой 3-х платформ, 3+ компиляторов, генерацией кода и зависимостями типа boost/Qt/etc. Расскажите как у вас такое или подобное организованно.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Наверное потому, что JRE используют на сервере и в корпоративных системах, где реверсинг с целью взлома/клонирования не актуален. SVZ>А десктопные приложения клепают на С++, Шарпе, там проблема защиты бинарников актуальна. SVZ>Видимо поэтому Шарписты очень любят обфускаторы.
Тогда почему в продуктах Автодеска (ага, те же самые бешеные деньги за одну рабочую станцию) есть RTTI? Что-то мне кажется, кто-то перемудрил
Здравствуйте, kaa.python, Вы писали:
KP>Тогда почему в продуктах Автодеска (ага, те же самые бешеные деньги за одну рабочую станцию) есть RTTI?
Противоречия нет:
1. RTTI нужен только там где нужен dynamic_cast
2. RTTI отключается per-file
Если у тебя в проекте вообще нет dynamic_cast то можно выключить RTTI вообще на весь проект
В противном случае можно оставить там, где он надо. Ну или выключить там, где его быть не должно.
Здравствуйте, CreatorCray, Вы писали:
CC>Если у тебя в проекте вообще нет dynamic_cast то можно выключить RTTI вообще на весь проект CC>В противном случае можно оставить там, где он надо. Ну или выключить там, где его быть не должно.
Ты бы это не мне, а Stanislav V. Zudin рассказывал? Отключить RTTI в проекте и ограничить себя в использовании "очень хорошо бы подходящей к некоторым нашим задачам" библиотеки для защиты проекта от взлома (который не является проблемой для проектов подобной ценовой категории) никогда в голову не приходило и надеюсь не придет.
