Здравствуйте, aik, Вы писали:

aik>Это не то чтоб плохо, но неудобство в том, что передаётся "const char[]", а функция принимает "string", и компилятор сам разбирается а не нужен ли там new для массива char внутри string.
А разве это не такие же памперсы что так любят submissive managed челы. Чтоб за них решили как круглое вставить в квадратное.
Для людей с опытом это даёт возможность задать специализированные перегрузки под конкретные типы а компилятор выберет наиболее подходящую из них.
Или же можно сделать generic и опять таки компилятор сам соберёт правильную цепочку.

aik>Это затрудняет чтение настолько
Чтение это как раз не затрудняет. Это скорее может вылезти на профайлинге.

aik> что в этих всяких go и rust типы надо руками приводить даже там, где си не требовал — так этот автоматизм людей достал.
А, ну так тем более пусть в сад идут с такими заморочками. Мало им что на С надо писать туеву хучу бойлерплейта, так они ещё и тут цирк устраивают.
В современном С++ уже есть достаточно возможностей чтоб автоматические преобразования запретить, есессна не с ширпотребными либами, которые заточены на противоположное, автоматическое использование.

Здравствуйте, netch80, Вы писали:

N>они ожидали основного перетока как раз от C++.
С какого бы перепугу?
У меня одно только их := вызывает паскальские флешбеки и рвотный рефлекс

Здравствуйте, so5team, Вы писали:

S>Теперь пробуем довести до логического завершения: что здесь плохого? Особенно если функции именно копия текста и нужна.

Копия (т.е. выделение памяти) должно быть явным. Хочется копию — some_func(strdup("Hello world")), или как минимум some_func(string("Hello world")). Аллокаторов в ядре линукса несколько (эта подветка про ядро), и они не взаимозаменяемые.

Здравствуйте, aik, Вы писали:

aik>эта подветка про ядро

Ой, проссыте, низаметил. И давно?

Здравствуйте, so5team, Вы писали:

aik>>эта подветка про ядро
S>Ой, проссыте, низаметил. И давно?

ответ [26]

Смысл такой что с++ в ядре можно использовать, но с такими адскими ограничениями, что от него (по сравнению с си) останутся только ... vtbl? Но и их лайфпатчат в прямые вызовы.

Здравствуйте, aik, Вы писали:

S>>Ой, проссыте, низаметил. И давно?

aik>ответ [26]

В ответе [27] за счет цитат Торвальдса (который высказывался о C++ вообще, а не только применительно к ядру Linux-а) предмет обсуждения был расширен. В рассмотрение пошел даже git.

Если говорить о ядре, то мой пример (к которому прицепились как к демонстрации ущербности C++) вообще нерелевантен. Просто по факту применения там std::cout, std::format, да и std::string.

Здравствуйте, so5team, Вы писали:

S>Если говорить о ядре, то мой пример (к которому прицепились как к демонстрации ущербности C++) вообще нерелевантен. Просто по факту применения там std::cout, std::format, да и std::string.

В том примере printf("lalala %s\n", v) и замена параметра функции на "const char *" сделает всё тоже самое, только проще и безо всякого неявного создания объектов и вызовов конструкторов. Переопределять оператор "<<" настолько далеко от сдвига по-моему тоже так себе идея.

Здравствуйте, aik, Вы писали:

S>>Теперь пробуем довести до логического завершения: что здесь плохого? Особенно если функции именно копия текста и нужна.

aik>Копия (т.е. выделение памяти) должно быть явным. Хочется копию — some_func(strdup("Hello world")), или как минимум some_func(string("Hello world")). Аллокаторов в ядре линукса несколько (эта подветка про ядро), и они не взаимозаменяемые.

Не используй std::string в ядре. Используй с нужным аллокатором. В чем проблема?

А с твоим strdup — кто память освобождать будет? some_func? И что, мне надо каждый явно раз копию делать, даже когда мне это не нужно? Если у меня куча коротких строк, которые надо обработать, одно-двух-трех символьных, тоже память под каждый чих выделять? Или, может, написать две версии функции, some_func и some_func_and_free?

Сказал бы я, куда с этим дупом пройти, да в бан не хочу

Здравствуйте, aik, Вы писали:

aik>ответ [26]

aik>Смысл такой что с++ в ядре можно использовать, но с такими адскими ограничениями, что от него (по сравнению с си) останутся только ... vtbl? Но и их лайфпатчат в прямые вызовы.

А C++ это и есть VTBL + шаблоны + STL алгоритмы + STL типы. Если убрать STL типы, то останется ещё куча всего

Здравствуйте, aik, Вы писали:

aik>В том примере printf("lalala %s\n", v) и замена параметра функции на "const char *" сделает всё тоже самое, только проще и безо всякого неявного создания объектов и вызовов конструкторов.

Если мы уже перестали говорить про код для ядра, а заговорили вообще, то все это "проще и безо всякого" работает нормально только в тривиальных случаях. Достаточно чутка изменить пример, скажем так:

[[nodiscard]] std::string produce_id() {...}

std::string & unescape_inplace(std::string & percent_escaped_value) {
  ...
  return percent_escaped_value;
}

void some_func(std::string v) {
  std::cout << std::format( "Processing {}", unescape_inplace(v) ) << std::endl;
  ...
}

...
some_func(produce_id());

и оказывается, что все эти неявные создания и конструкторы спасают от туевой хучи бойлерплейта.

Ну и как бы да, кроме printf("lalala %s\n", v) надо бы следом добавить и fflush(stdout);.

aik>Переопределять оператор "<<" настолько далеко от сдвига по-моему тоже так себе идея.

Этот "<<" в C++ с 1985-го года. Можно было бы уже привыкнуть, что здесь вот так. Почему-то народу "fn" в Rust-е заходит, а "<<" в C++ нет.

Ну и совсем по другому переопределение "<<" начинает выглядеть при использовании std::cout внутри шаблонов... А нет, не начинает. В Си же шаблонов нет.

Здравствуйте, aik, Вы писали:

S>>Если говорить о ядре, то мой пример (к которому прицепились как к демонстрации ущербности C++) вообще нерелевантен. Просто по факту применения там std::cout, std::format, да и std::string.
Вот именно, C++ ужасен сам по себе, а в ядре- это диверсия.

aik>В том примере printf("lalala %s\n", v)
В этом примере нет защиты от buffer overflow. afaik. Скосячил. Это не sprintf или как его. Нет никакого переполнения, читается прекрасно, хип понапрасну не дергает.

aik>Переопределять оператор "<<" настолько далеко от сдвига по-моему тоже так себе идея.
Вообще, перегрузка оператора- прикольная фича когда пишешь код. И это антипаттерн для поддержки кода.

Здравствуйте, Артём, Вы писали:

Аё>Вот именно, C++ ужасен сам по себе, а в ядре- это диверсия.

Краткий перечень аргументов Тёмчика в этой теме:

• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• C++ ужасен;
  
• ...

Здравствуйте, aik, Вы писали:

aik>Смысл такой что с++ в ядре можно использовать, но с такими адскими ограничениями
С какими?

aik> что от него (по сравнению с си) останутся только ... vtbl?
и templates (как обычные так и вариадики), и auto, и прочий RAII крайне сильно упрощающий жизнь. Что в общем то и нужно, и чего очень сильно не хватает в С.
Лямбды вот только не было нужды юзать, впрочем им в ядре ничего не мешает.
В ядре только с exceptions сложности.

aik> Но и их лайфпатчат в прямые вызовы.
Нет.

Здравствуйте, Marty, Вы писали:

M>А C++ это и есть VTBL + шаблоны + STL алгоритмы + STL типы. Если убрать STL типы, то останется ещё куча всего
Учитывая что STL полностью написан на С++ то если выкинуть STL то ничего не изменится — всё то, что там есть можно написать самостоятельно, и более того — заточить под специфику использования.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, netch80, Вы писали:

N>>они ожидали основного перетока как раз от C++.
CC>С какого бы перепугу?
CC>У меня одно только их := вызывает паскальские флешбеки и рвотный рефлекс

1. ":=" там имеет другой смысл, чем обычное "=" — ты можешь даже ограничить его использование до минимума.

2. А почему кого-то должны волновать твои персональные флэшбеки и рефлексы? Тем более если ты из линии Pascal -> Modula -> Oberon (и отвилкой на Ada) ничего кроме Pascal не хочешь вспоминать?

3. С того "перепуга", что гугловский опыт использования C++ показал, насколько легче зажать людей в прокрустово ложе и потом получать более-менее равномерный результат, чем разбираться со сложностью.

Здравствуйте, CreatorCray, Вы писали:

N>>uint8_t x = 255; x++;
N>>и оно отвечает "0" — лучше только в относительном смысле (концентрация граблей меньше), но не в абсолютном (они всё равно есть и бьют из-за угла).

CC>Неа, совершенно не сравнимо.
CC>Ты тут при декларации типа задал какое поведение ты от него ожидаешь.

И в JavaScript точно так же при декларации типа ты задал, какое поведение от него ожидаешь. Задал, что значение у тебя строка? Значит, '+' для неё будет сложением строк.
Ах, ты получил неизвестно что извне? Твоя проблема — сделай, чтобы было известно.
+x для любого x делает его числом. ""+x — строкой. Движки типа V8 умеют понимать эти идиомы и оптимально их реализовывать. Считай это декларацией типа, но с другим синтаксисом.

N>>недавно тут была роскошная дискуссия

Автор: Евгений Музыченко
Дата: 05.05.20

вокруг.
CC>Да где там роскошная? Я за использование знаковых типов

Автор: CreatorCray
Дата: 10.05.20

для значений которые принципиально не могут иметь знак готов лично "выводить в чисто поле, ставить мордой к стенке и пускать пулю в лоб" (tm)

Что такое LBA?

N>>Надо пропагандировать подход C# в этом, он выглядит самым разумным.
CC>Это какой именно?

Контекстно-задаваемый режим. Checked по умолчанию (можно поставить в настройках проекта) и unchecked там, где уверен, что проверки не нужны. Но в C# мало вариантов, для C/C++ нужен ещё минимум relaxed, и вместо исключений — подъём флага.

Здравствуйте, netch80, Вы писали:

N>>>они ожидали основного перетока как раз от C++.

N>1. ":=" там имеет другой смысл, чем обычное "=" — ты можешь даже ограничить его использование до минимума.
Можно, но тогда и в других языках можно использование неприятных особенностей угодно ограничить и тогда смысл переходить на другой язык теряется совершенно.

N>2. А почему кого-то должны волновать твои персональные флэшбеки и рефлексы?
Это было к вопросу почему люди со знанием С++ не заинтересовались.

N>насколько легче зажать людей в прокрустово ложе и потом получать более-менее равномерный результат, чем разбираться со сложностью.
Для мазохистов уже есть С, где всё приходится хреначить врукопашную. Нафига козе баян?

Здравствуйте, netch80, Вы писали:

N>Что такое LBA?
Грубо говоря это номер сектора на диске. Начинается с нуля, отрицательных значений не существует. Все железяки работают строго с unsigned значениями.

Здравствуйте, CreatorCray, Вы писали:

aik>> что от него (по сравнению с си) останутся только ... vtbl?
CC>и templates (как обычные так и вариадики), и auto, и прочий RAII крайне сильно упрощающий жизнь. Что в общем то и нужно, и чего очень сильно не хватает в С.

Меня уже почему-то не удивляет, что на одном и том же железе, макось рутинно сливает линуху в операциях io.

Аё>Меня уже почему-то не удивляет, что на одном и том же железе, макось рутинно сливает линуху в операциях io.

У некоторых Путин во всем виноват, а у Артема — плюсы во всем виноваты