Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я бы взял готовую библиотеку, универсальную для user/kernel, но в 90-х таких тупо не было, а потом их стали делать так же, как STL/Boost — на все случаи жизни, мне такое не надо.
std+boost вполне годна даже для кернель, только надо было осилить кастомные аллокаторы (это если про контейнеры, но std это не только они). На предыдущей работе один деятель написал свои замены векторов/строк и тп для использования на STM32, и оно даже в целом работает, только он там столько граблей разложил, что я себе ладошкой лоб разбил. Он, с одной стороны, неплохо прошарился в шаблоны и в компайл-тайм, с другой стороны лютую хрень творил, не зная кучи всего из базовых вещей. Но у него работа с перифкой контроллера более менее работала, я её использовал, а остальное брал из std или boost'а, и жил шоколадно.
M>>кучи других плюсовых библиотек являются универсальными для 99% случаев применения, и ими пользуется большинство разработчиков.
ЕМ>Да и на здоровье, я ж не призываю от них отказываться. Многие вот кока-колу каждый день пьют, и им даже нравится.
Ммм, а Гитлер ел огурцы. Узнаю неумелого демагога
M>>Сам процесс создания софта основан на всевозможных "трюках".
ЕМ>Глупости. Трюки нужны или для реализации редких, сильно нестандартных вещей, для которых не удосужились сделать штатных средств, или для преодоления имманентных недостатков инструмента.
Сортировка пузырьком — тоже трюк, для продавщицы из Пятёрочки. Она только на кассе кнопки жамкать умеет
Здравствуйте, Евгений Музыченко, Вы писали:
M>>даже твой велосипед не является прекрасным
ЕМ>У меня не было цели делать его прекрасным. Это просто рабочий инструмент. У меня и молоток не сверкает, и шуруповерт несколько потерт, а преобразователи напряжения и вовсе без корпусов.
То, что я уже много раз объяснял — реализация библиотеки, невозможная без использования трюков, уродлива по определению (как и языковые средства, предполагающие, и даже поощряющие использование этих трюков).
R>Тебе же задали вопрос конкретно про std::string, или std::vector.
Ну хорошо, эти простейшие классы можно считать относительно изолированными, и более-менее адекватными в плане структуры своих шаблонов. Но это лишь мелкий фрагмент std, который нет смысла обсуждать изолированно. И их реализация тоже уродлива, ибо не допускает использования без поддержки исключений, которых им по логике вовсе не требуется.
R>с твоей точки зрения, пригодны std::string, или std::vector для или нет?
С моей точки зрения, для написания программ, синтаксически и семантически удовлетворяющих стандартам C++, пригодна вся std. А дальше уже начинаются нюансы.
Здравствуйте, Marty, Вы писали:
M>Обычно это бывает только тогда, когда пользователь сам начинает неумело шаблонить.
"У порядочных людей" такого не должно быть никогда, независимо от умелости пользователя.
M>компиляторы нихрена не пытаются смягчать. Они просто вываливают портянку сообщения со своей диагностикой, как есть.
Сравните эти портянки у компиляторов начала 90-х, когда только были реализованы шаблоны с возможностью SFINAE, где-нибудь начала-середины 2000-х, когда они активно пошли в массы, и сейчас.
M>компилятор мог бы делать такую же или, что гораздо вероятнее, гораздо более лучшую работу.
Я бы предпочел, чтобы компилятор делал более адекватную работу, обрабатывая более вменяемый синтаксис (который возможен, но вряд ли будет реализован), нежели борется с последствиями использования невменяемого.
M>Это как раз не про мусор под ковёр, а про качественную диагностику.
Качественная диагностика возможна тогда, когда программисту предоставлены адекватные возможности для выражения своего замысла. Когда у него есть возможность использовать, грубо говоря, лишь иносказания и намеки, качественная диагностика возможна лишь с помощью эвристических методов, алгоритмические не работают.
M>Ещё я, при проблемах с компиляцией, смотрю, выхлоп GCC на том же проекте, часто помогает.
Ну а я просто не использую инструментов, в выхлопе от которых приходится регулярно разбираться особыми методами. Если вдруг попадется инструмент, использовать который будет значительно проще и эффективнее, чем обойтись без него или написать самому — буду использовать его.
ЕМ>>Главная проблема в том, что в языке до сих пор нет внятных средств для построения сложных и одновременно понятных и надежных метаконструкций.
M>Да есть, просто ты не осилил.
И не собираюсь. Не вижу смысла осиливать хождение по канату исключительно потому, что нынче это модно.
M>А это ты вообще о чем?
Все о том же — что C++ в нынешнем виде не столько "умен", сколько "заумен".
Здравствуйте, Marty, Вы писали:
M>std+boost вполне годна даже для кернель
Она туда "годна" исключительно в том смысле, что технически ее можно было бы туда запилить. И даже использовать, если не смотреть в генерируемый код. Только нет в том ни малейшего смысла.
M>только надо было осилить кастомные аллокаторы
У Вас понятие "осиливания" ассоциируется исключительно с позитивным, желательным, героическим смыслом, к чему стоит стремиться и чем стоит гордиться. Если же немного подумать, то далеко не все, что поддается "осиливанию", оказывается позитивным и желательным.
M>На предыдущей работе один деятель написал свои замены векторов/строк и тп для использования на STM32, и оно даже в целом работает, только он там столько граблей разложил, что я себе ладошкой лоб разбил.
Верно, а почему? Именно потому, что он возомнил, будто это достойный путь крутого программера. Не он первый, не он последний.
Здравствуйте, Marty, Вы писали:
M>Кстати, std — тоже просто рабочий инструмент
Это скорее микроскоп, которым настойчиво предлагается заодно забивать гвозди, выравнивать поверхности, использовать в качестве утяжелителя и т.п., лишь для того, чтобы обойтись одним "универсальным инструментом".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С моей точки зрения, для написания программ, синтаксически и семантически удовлетворяющих стандартам C++, пригодна вся std. А дальше уже начинаются нюансы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну хорошо, эти простейшие классы можно считать относительно изолированными, и более-менее адекватными в плане структуры своих шаблонов. Но это лишь мелкий фрагмент std, который нет смысла обсуждать изолированно. И их реализация тоже уродлива, ибо не допускает использования без поддержки исключений, которых им по логике вовсе не требуется.
Исключения — ты их хейтишь, потому что пишешь ядрёный код, в котором, как я понимаю, исключения нельзя использовать. Но это нужно 0.001%-у разработчиков. Исключения нужны, чтобы можно было в RAII
Расскажи, как быть, если конструируемая строка не может выделить буфер?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Кстати, std — тоже просто рабочий инструмент
ЕМ>Это скорее микроскоп, которым настойчиво предлагается заодно забивать гвозди, выравнивать поверхности, использовать в качестве утяжелителя и т.п., лишь для того, чтобы обойтись одним "универсальным инструментом".
Нет, это лаборатория, совмещенная с мастерской, где есть и молоток и микроскоп, уровень и правило, утяжелители, и даже гири со штангами.
Нет, std я не использую прежде всего потому, что она навязывает чрезмерные для меня требования.
R>тебе точно нужен C++?
Ну, до сих пор я не нашел языка, на котором мог бы более эффективно и комфортно делать то, что делаю.
R>А может тогда и в форуме C++ нужно вести себя как-то поскромнее — не делать заявлений космического масшаба
Каким образом возможности C++, которые я (и не только я) считаю убогими, могли бы стать менее убогими от того, что я ими не пользуюсь (или стараюсь не пользоваться)?
Здравствуйте, Marty, Вы писали:
M>Исключения — ты их хейтишь, потому что пишешь ядрёный код
Нет — прежде всего потому, что их концепция в C++ нарушает его собственный принцип "не платить за то, чего не используешь". Используй они в минимальном варианте только коды и указатели, и лишь в расширенном — произвольные типы, я б их так не хейтил.
M>в котором, как я понимаю, исключения нельзя использовать.
Это не проблема. Если б я любил исключения, то давно бы сколхозил для них собственную поддержку.
M>Исключения нужны, чтобы можно было в RAII
Они для этого не "нужны", а "могут использоваться'. Я вполне себе активно использую RAII без исключений.
M>Расскажи, как быть, если конструируемая строка не может выделить буфер?
Известно, как. Можно вызвать заранее заданную функцию-обработчик, можно сконструировать "невалидную" строку, которая вернет этот признак при опросе, а при попытке что-то с нею делать вызовет уже обработчик более высокого уровня, или системное исключение.
Исключения в C++ — одно из нескольких мест, где при переходе от C перескочили сразу через несколько промежуточных этапов, поставив простоту и универсальность выше масштабируемости.
Здравствуйте, Marty, Вы писали:
M>это лаборатория, совмещенная с мастерской, где есть и молоток и микроскоп, уровень и правило, утяжелители, и даже гири со штангами.
Здравствуйте, Shmj, Вы писали:
S>Встречали ли вы такую концепция кодирования? Одобряете?
Встречал. От языка это мало зависит и присутствует в той или иной мере во всех языках.
Обычные ограничения:
запрет на goto или его разновидности
запрет на переиспользование переменных
запрет на использование чисел с плавающей точкой
запрет на использование самоизменяющегося кода.
Редкие ограничения:
запрет на алокацию памяти
запрет на использование макросов
запрет на использование голых указателей
запрет на использование информации о типе
запрет на использование циклов для прохода по массиву
запрет на множественное наследование данных
Некоторые языки разрабатываются только для того, чтобы внести свои новые ограничения, но как по мне — это тупиковый путь.
К сожалению зараза запретов проникла и в С++. Мешает, понимаешь, свобода оптимизации.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Встречалась ли вам концепция — "C++ как C с классами". Т.е. когда правила кодирования устанавливают запрет на множество фич, которые есть в языке, но которые часто запутывают код и делают сложным для восприятия — сводят фактически к C, но с удобным синтаксисом для RAII. Однако же указатели и пр. — используются все как в C.
Да, встречалась. Но RAII уже позволяет создать умный указатель, а значит позволяет минимально автомативировать управление памятью.
S>Причем на C успешно пишут все что угодно — то какие проблемы делать то же самое, добавив в C — удобный RAII в мин. варианте?
Вместе с удобным RAII в нагрузку добавится десяток граблей, это уже будет не С. Главным особенностью С является относительная низкоуровневость языка и отсутствие каких либо скрытых параметров, код будет делать только то, что ты явно написал. Если добавить RAII то появится какие-то правила, автоматический вызов каких-то функций, простота и низкоуровневость пропадут.
S>B здесь главное не поддаться греху гордыни — когда тебе хочется доказать другим что ты способен, что SFINAE и 4-х этажные шаблоны тебе по плечу. А нужно не поддаваться греху гордыни а наоборот проявить смирение и кротость — аскетизм. Ограничить себя в излишествах и довольствоваться простым минимализмом. S>
S>В принципе — я всецело поддерживаю и уважаю эту концепцию C++. Чем проще код — тем лучше. Кто хочешь поддаться греху гордыни — есть вам Haskell — пожалуйста.
Поддерживаю, но лишь отчасти. Если код уже написан на С с классами, то закидывать туда трехэтажный шаблон как-то нехорошо. И да, надо пытаться писать простой и ясный код. Но стоит ли реально отказываться от полезных возможностей? Помню, на чистом С, я задолбался, когда мне надо было сделать не совсем тривиальный разбор аргументов коммандной строки. При этом используя С++ строки std::map я бы сделел это за 10 минут. А ведь стандартые контейнеры это довольно непростые шаблоны. Надо ли от них отказываться?
S>Но! С появлением умных указателей стала возможна другая концепция — C++ может быть аналогом ЯВУ типа C#|Java. В чем суть? Суть в том, чтобы в угоду простоте кодирования и отладки — отказаться от ряда фич языка, запретить их использование. А именно:
Во первых концепция умных указателей в С++ очень старая, и относится к 90-м годам. Книга Джеффа Элджера, где он детально расписывает множество видов умных указателей вышла в 99 году. И он там описывает то, что тогда уже активно использовалось ведущими специалистами.
Во вторых не стоит сравнивать умные указатели со сборщиком мусора, это совершенно разные концепции, и они вообще друг на друга не похожи. То есть это совсем не Java и не C#.
S>1. Отказ от сырых указателей, буквальный запрет их в коде. Замена — умные указатели, ссылки, std::optional, std::optional<std::reference_wrapper<>>.
Я поддерживаю отказ от ручного управления памятью. Нельзя вручную вызывать new и delete. Но полный отказ от указателей не поддерживаю. Указатель простой способ передать объект не передавая владение. Да, надо быть осторожным, и лучше не передавать сырой указатель, если он там куда-то далеко пробрасывается.
S>2. Отказ от сложных шаблонов, вариадических, SFINAE, запрет концептов. Т.е. свести к уровню шаблонов в Java/C#.
Поддерживаю частично. Главное не писать сложные шаблоны просто потому, что можешь. Надо всегда понимать, зачем это тебе, и бить себя по рукам, если просто хочется еще обобщить и добавить еще один уровень абстракции. В 99% случаев сложные шаблоны не нужны, но в 1% это может реально помочь, не стоит полностью отказываться.
Даже простые шаблоны в С++ очень сильно отличаются от java/C#. Это внутри совершенно разные вещи.
S>3. Отказ от макросов.
Тут полностью поддерживаю. Ну макросы можно например использовать для отладочного логирования, чтобы добавить в описание ошибки имя функции или для условной компиляции. Активно использовать макросы для абстракции и кодогенерации — это зло и делает код вообще не читаемым. Если уж так хочется погенерировать код, лучше использовать какой нибудь внешний скриптовый язык.
S>4. Запрет множественного наследования реализаций.
Тоже полностью поддерживаю. Не знаю ни одного случая, где бы это реально было нужно. Более того, считаю, что наследование реализвации даже не множественное тоже не особо нужно, его всегда можно заменить агрегированием, а наследовать только интерфейсы. Наследование реализации размазывает функиональность по иерархии классов и ухудшает читаемость кода. Хрен поймешь какой там реально класс, где и когда метод был переопределен, и что именно там вообще вызывается, когда видишь вызов метода.
S>5. И т.д. (это примерный список, на самом деле гораздо больше).
S>Вы скажите — в чем тогда смысл, не лучше ли писать сразу на Java? А смысл чисто практический — по факту С++ наиболее кросс-платформенный и наименее гемморный на сегодня. Дошло до того, что C# компиллят в C++. Здесь не вопрос холивара — просто по факту так оно и есть.
Подход java очень сильно отличается и при всем желании на C++ не получится писать как на java. Под капотом там все совсем подругому работает.
И вообще я скажу да, если вы не можете точно сказать, зачем вам С++, то лучше пишите на java или еще на чем-нибудь, сейчас есть новые молодежные языки.
S>Встречали ли вы такую концепция кодирования? Одобряете?
То что ты написал, это не java, по болшей части одобряю.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>3. Отказ от макросов.
ЕМ>C++ слишком убог, чтобы это было возможно без серьезного урезания удобства работы с ним.
Ну, убогость С++ вообще это вопрос довольно спорный. Но вот препроцессор С, перекочевавший в С++ действительно убог. Причем настолько убог, что от макросов в С++ действительно надо по возможности максимально стараться отказаться (полностью отказаться конечно не возможно).
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, Shmj, Вы писали:
S>>Вопрос такой. S>>Встречалась ли вам концепция — "C++ как C с классами"...
R>У меня вопрос другой: ты нахрена опять профильный форум загаживаешь своей трепологией? Тебе КСВ мало?
Там вроде кнопочка есть для модерации. Не знаю наверняка, как она устроена, увы в ветке С++ у меня нет полномочий, но весь его флуд из Qt я, как правило, напрямую перекидываю в "священные войны".
Здравствуйте, ksandro, Вы писали:
K>от макросов в С++ действительно надо по возможности максимально стараться отказаться
А на что их менять-то? Только самые кондовые макросы можно без потери функциональности, общности и удобства заменить на инлайн-функции или шаблоны.
K>(полностью отказаться конечно не возможно)
Это одно из следствий убожества C++ — если C был простым, кондовым, и внутренне достаточно согласованным, то C++ уже через несколько лет после начала своего шествия в массы стал превращаться в нечто бесформенное, что одни старательно пытались втиснуть в некие рамки (порой весьма странные), а другие, столь же старательно — превратить в нечто совершенно чудовищное.
Здравствуйте, SaZ, Вы писали:
SaZ>Там вроде кнопочка есть для модерации. Не знаю наверняка, как она устроена, увы в ветке С++ у меня нет полномочий, но весь его флуд из Qt я, как правило, напрямую перекидываю в "священные войны".
Ну у него же был период, когда он проявлял сознательность и, по крайней мере, стался не флудить в форуме С++. Но сейчас вот снова у него гайки сорвало. Видимо, на почве неудовлетворённого интереса по поводу его примера
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, SaZ, Вы писали:
SaZ>>Там вроде кнопочка есть для модерации. Не знаю наверняка, как она устроена, увы в ветке С++ у меня нет полномочий, но весь его флуд из Qt я, как правило, напрямую перекидываю в "священные войны".
R>Ну у него же был период, когда он проявлял сознательность и, по крайней мере, стался не флудить в форуме С++. Но сейчас вот снова у него гайки сорвало. Видимо, на почве неудовлетворённого интереса по поводу его примера
Ну он либо очень толстый тролль, либо человек у которого проблемы с социализацией и эмпатией. И он осторожно пытается это дело компенсировать форумом, совершенно не понимая какой дискомфорт он доставляет.
Тут ещё есть другая категория похожих людей (не только на рсдн) — это которые упорно долбят старьё и при этом категорически отказываются от новых технологий, думая что старое == хорошее. И сидят такие на Qt4, MFC, WTL и прочих. При этом пытаются доказывать и аргументировать свою позицию фразами типа "для моих задач этого достаточно", а потом начинают бороться с тем, что умные люди уже давно решили в современных фреймворках.
