Здравствуйте, MasterZiv, Вы писали:
MZ>Говнокод на С++, написанный С-шником -- это "С с классами". MZ>Коды возврата вместо исключений. MZ>Возврат значений через указатель на результат в параметре. MZ>Указатели на коллбэки вместо полиморфизма. MZ>Макросы вместо шаблонов. MZ>И так далее.
И что интересно, всё это работает и делает то же самое.
Так с какого бодуна это — "говнокод"?
Здравствуйте, MasterZiv, Вы писали:
MZ>Здравствуйте, sergey2b, Вы писали:
>>объясните плиз чем Си с классами отличаеться от C++\ S>>те когда это еще Си с классами, а вот после этого стал уже С++
MZ>Говнокод на С++, написанный С-шником -- это "С с классами". MZ>Коды возврата вместо исключений. MZ>Возврат значений через указатель на результат в параметре. MZ>Указатели на коллбэки вместо полиморфизма. MZ>Макросы вместо шаблонов. MZ>И так далее.
это все Ст шные приколы
MZ>Возврат значений через указатель на результат в параметре.
скажем функция формирует текстовое сообшение в буфере, как вы его веренете в std::string ?
Здравствуйте, Mr.Delphist, Вы писали:
... MD>Гы-гы-гы, это называется "перестал быть джуном"
+100500
Никто и не спорит, но это уже ООП (пусть хоть и самое начало)
MD>Настоящий С++ это именно шаблоны и всё такое, когда программа пишет сама себя. (если что, то я его точно знаю на Hello-world уровне)
Без настоящей рефлексии, как в .NET языках (тот же C#) — очень сомневаюсь что это в полной мере возможно...
P.S. В то же время, если сравнивать дженерики C# и шаблоны C++ — выигрыш подхода шаблонов C++ очевиден:
Для C++ templates — это сущности времени компиляции (в процессе выполнения кода — работают быстро и шустро)...
Для C# generics — это сущности времени выполнения (в процессе выполнения кода — работают медленно)
P.P.S. Понятное дело, что для каждого типа прикладных задач — сушествует свой подход — где-то рациональнее применение динамического полиморфизма, с применением абстрактных базовых классов, RTTI и т.д. А где-то статический полиморфизм на шаблоноах — самое то!
Здравствуйте, cures, Вы писали:
C>Здравствуйте, sergey2b, Вы писали:
S>>скажем функция формирует текстовое сообшение в буфере, как вы его веренете в std::string ?
C>Так и вернём, в std::string(buf).
прототип функции
что то преобразованиеСтроки(char *buf, size_t usize)
у нас уже есть буфер, но тем неменее вы хотите выделить память скопировать результат, еще и возрат строки из функции будет чего то стоить
Здравствуйте, sergey2b, Вы писали:
S>но тем неменее вы хотите выделить память скопировать результат, еще и возрат строки из функции будет чего то стоить
А потом бегут на кывт с вопросами почему прога на С++ работает медленее чем прога на python.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, sergey2b, Вы писали:
S>>что то преобразованиеСтроки(char *buf, size_t usize)
S>Это какой-то неправильный прототип. Вот так будет лучше: S>
Здравствуйте, sergey2b, Вы писали:
S>прототип функции S>что то преобразованиеСтроки(char *buf, size_t usize)
Плохой прототип, негодный, обычную текстовую строку "Hello, world!" туда не передашь, ибо константная.
S>у нас уже есть буфер, но тем неменее вы хотите выделить память скопировать результат,
А что Вы потом планируете с возвращённым значением делать? Солить?
И нафига заводили буфер, если его можно завести как раз под результат, чтобы результат дальше спокойно использовать, не боясь, что в это время в том же буфере начнут преобразовывать другую строку?
S>еще и возрат строки из функции будет чего то стоить
Возврат строки из функции будет стоить положения одного пойнтера и двух size_t в заранее зарезервированное место на стеке.
Более того, если функция инлайнится (или при LTO), компилер может присвоение результата, скажем, в ещё одну строку, просто выкинуть, а в Вашем случае придётся побайтно копировать, да ещё перед этим её длину считать.
Здравствуйте, so5team, Вы писали:
S>Товарища прежде всего нужно спросить зачем ему std::string, если у него уже есть буфер для преобразования.
Товарища об этом можно не спрашивать, достаточно прочитать его предыдущее сообщение и сообщение, на которое он отвечал.
Перед этим MasterZiv назвал говнокодом возврат значения через параметр-указатель. А, типа, если через референс, то нормально?
На это sergey2b привёл не очень удачный контрпример: спросил, как иначе возвращать результат работы, если вся работа — преобразование переданного буфера. Кроме того, что пример довольно искусственный — не так часто результат работы и размер исходной строки совпадают — так он ещё и не подходит для константных аргументов (например, лежащих в секции .text), да и саму исходную строку портить не всегда желательно. А завести новый стринг и вернуть через него по времени ничего не стоит. Может стоить по памяти, но мы все помним про преждевременную оптимизацию. Да и в любом случае, это явно не то, что имел в виду MZ. Тут речь про in-out аргумент, а имелись в виду чистые out. Но прикопался я именно к тому, почему бы в подобных случаях не возвращать результат отдельно.
Здравствуйте, cures, Вы писали:
C>А что Вы потом планируете с возвращённым значением делать? Солить? C>И нафига заводили буфер, если его можно завести как раз под результат, чтобы результат дальше спокойно использовать, не боясь, что в это время в том же буфере начнут преобразовывать другую строку?
планирую удалять пробелы перед текстом и после текста и заменять %s на свою подстроку
Здравствуйте, sergey2b, Вы писали:
S>планирую удалять пробелы перед текстом и после текста и заменять %s на свою подстроку
Вполне классическая обработка текста. Когда заменять станете — точно в тот же буфер не уложитесь, придётся или молиться, чтобы "своя подстрока" оказалась не длиннее двух символов, или таки заводить новый буфер. Во втором случае — новый выбор: подсчитывать ли количество вхождений %s в строку отдельным проходом, или сразу делать выделяемый буфер изменяемого размера.
Много ли Вы при всём при этом рассчитываете сэкономить тем, что на первом проходе не выделите новый буфер, а уложитесь в старый (сделаев свою функцию более узко применимой) ? По операциям — одинаково: чтение-модификация-запись, причём, как я понимаю, последовательные. И то, что читать и писать будете в одну и ту же память, на скорость практически не повлияет. Выделение памяти — штука нынче довольно быстрая. Если Вам не нужна исходная строка — так она освободит память, если присвоите результат в неё же. Сдаётся мне, тут совершенно классический пример незрелой оптимизации.
Здравствуйте, MasterZiv, Вы писали:
MZ>Возврат значений через указатель на результат в параметре.
Ох ты ёлки, а чем этот способ не угодил? Вполне годный вариант.
А как ошибку возвращать?
Кидать исключение, а потом снаружи наворачивать try/catch, как в Яве?
Или городить std::any с кастами? И что, код станет читабельнее или быстрее?
MZ>Указатели на коллбэки вместо полиморфизма.
Тоже не соглашусь.
Иногда колбек (ну замени его на std::function) очень даже уместен и гораздо читабельнее, чем полиморфизьм, навернутый на ровном месте. Контекст надо смотреть.
Про макросы тоже согласился бы, но надо смотреть по месту.
Иногда приходится поддерживать всякие экзотические системы, где не то, что про С++17, про С++03 едва слышали.
У меня пока складывается впечатление, что "труЪС++" это типа хипстерской цацки, типа мы модные и современные.
Для внутренней разработки это канает, а вот как только появляется какая-никакая поддержка продукта, то лучше придерживаться теплого лампового "Си-с-классами", по крайней мере работать будет везде.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, cures, Вы писали:
C>Забавная конструкция, жалко что не стандартная.
Это часть C++ Core Gudelines Support Library. Кандидат на включение в C++20.
S>>https://github.com/Microsoft/GSL/blob/master/include/gsl/span#L510
C>Выделенное много объясняет: брать у них даже прилично выглядящий код, да ещё и с непонятной лицензией, чревато боком.
Здравствуйте, cures, Вы писали:
C>Беда не приходит одна! Эта реализация, опять же, имеет какую-то левую лицензию, да ещё и с явным копирайтом (не копилефтом) Микрософта.
