Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\
S>те когда это еще Си с классами, а вот после этого стал уже С++
Очень просто, когда не пытаются выпихнуть обработку данных в complile-time и использовать шаблонные не поназначению, а просто пишут код которые решает поставленнуюю задачу, вы без иде можете сказать какой тип у переменной — это C с классами.
А вот когда у вас кругом header-only, шаблон на шалоне, везде где только можно move-семантика, смарт поинтеры, для компиляции нужно топовое железо, огромное количество кода которой не решает задау, а делает "удобнее", "правильнее" и "всеобъемлюще", при этом создаётся больше проблем чем решается и любая незначительная опечатка приводит к неочевидной ошибке компиляции которую надо еще самому долго вкуривать — вот тут уже следует насторажиться видимо современный C++ где-то рядом.
Здравствуйте, σ, Вы писали:
S>>Прочел соседнию ветку S>>объясните плиз чем Си с классами отличаеться от C++\
S>>те когда это еще Си с классами, а вот после этого стал уже С++
σ>См. Страуструп "Дизайн и эволюция языка C++" раздел 3.1 "От C with Classes к C++".
Чёткой грани нет. Например, кто-то считает, что использование virtual member functions это уже С++, хотя есть проекты на Си, которые вполне успешно эмулируют vtbl через массив + макросы. Большинство остальных элементов С++ тоже так или иначе реализуются на чистом Си или с раширешниями (например, RAII через аттрибут переменной __cleanup). Другое дело, что компилятор С++ может при прочих равных гарантиировать какую-то долю целостности. Я считаю более корректно — говорить "на проекте используется подмножество С++" с указаем того, что используется.
Здравствуйте, sergey2b, Вы писали:
S>объясните плиз чем Си с классами отличаеться от C++\
Подразумевается, что C++ это не только объектно-ориентированное программирование. Но и какие-то элементы метапрограммирования на шаблонах, возможности по перегрузке функций и операторов, пространства имён, argument dependent lookup в частности, исключения, полиморфизм, какой-то syntax sugar и современного C++ типа lambda-выражений. В середине-конце 90-х и начале 2000-х выпускалось много книг рассматривающих C++ именно в разрезе OO, мол это единственная парадигма и серебрянная пуля, видимо отсюда и пошёл C с классами, от Turbo-C++, первых версий MSVC, да и поддержка C++ в них была далеко не на высоте, в gcc времён 3.3.3 тоже. Собственно в начале 2000-х все возможности C++ и использовать толком не было возможности, так что C с классами скорей старая школа, кто учился в начале 2000-х.
>объясните плиз чем Си с классами отличаеться от C++\ S>те когда это еще Си с классами, а вот после этого стал уже С++
Говнокод на С++, написанный С-шником -- это "С с классами".
Коды возврата вместо исключений.
Возврат значений через указатель на результат в параметре.
Указатели на коллбэки вместо полиморфизма.
Макросы вместо шаблонов.
И так далее.
Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\ S>те когда это еще Си с классами, а вот после этого стал уже С++
С с классами изначально и был С++.
Потом уже пришли люди которые вернули греческую и римскую культуры назад в варварство и средневековье. Дикари compile time. Это было еще терпимо. Просто слушаешь шизиков киваешь улыбаешься, пока кто не вызовет доктора. Но потом дно стало еще хуже потому что туда стали заходить люди из микрозофт.
Они стали говорить — мы сейчас вам сделаем тут си щарп — вариадики все это, смарт поинтеры. Когда у них спрашивает зачем языку с ручным управлением памяти смарт поинтеры, они отвечают — ну как — мы же не учились управлять памятью в кулинарных техникумах. Грэйт джаб гайз!!!
Просто пользуйте С++ 11 с ООП и все. stl неплох в базе но к нему есть вопросы кое что там пользовать можно.
Здравствуйте, kov_serg, Вы писали:
_>Очень просто, когда не пытаются выпихнуть обработку данных в complile-time и использовать шаблонные не поназначению, а просто пишут код которые решает поставленнуюю задачу, вы без иде можете сказать какой тип у переменной — это C с классами.
Конечно, там почти все
void*
А также лапша из макросов, функции по 500+ строк, goto exit, куча похожего кода который делает почти тоже самое и прочие "радости".
_>А вот когда у вас кругом header-only, шаблон на шалоне, везде где только можно move-семантика, смарт поинтеры, для компиляции нужно топовое железо, огромное количество кода которой не решает задау, а делает "удобнее", "правильнее" и "всеобъемлюще", при этом создаётся больше проблем чем решается и любая незначительная опечатка приводит к неочевидной ошибке компиляции которую надо еще самому долго вкуривать — вот тут уже следует насторажиться видимо современный C++ где-то рядом.
Для большинства задач можно и без крайностей. В общем случае такие "крайности" дают остальным нормальные кросс-платформенные строки, контейнеры, доступ к файловой системе и т.д. с минимально возможными издержками.
Здравствуйте, MasterZiv, Вы писали:
MZ>Возврат значений через указатель на результат в параметре.
Ох ты ёлки, а чем этот способ не угодил? Вполне годный вариант.
А как ошибку возвращать?
Кидать исключение, а потом снаружи наворачивать try/catch, как в Яве?
Или городить std::any с кастами? И что, код станет читабельнее или быстрее?
MZ>Указатели на коллбэки вместо полиморфизма.
Тоже не соглашусь.
Иногда колбек (ну замени его на std::function) очень даже уместен и гораздо читабельнее, чем полиморфизьм, навернутый на ровном месте. Контекст надо смотреть.
Про макросы тоже согласился бы, но надо смотреть по месту.
Иногда приходится поддерживать всякие экзотические системы, где не то, что про С++17, про С++03 едва слышали.
У меня пока складывается впечатление, что "труЪС++" это типа хипстерской цацки, типа мы модные и современные.
Для внутренней разработки это канает, а вот как только появляется какая-никакая поддержка продукта, то лучше придерживаться теплого лампового "Си-с-классами", по крайней мере работать будет везде.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, cures, Вы писали:
Ops>>Это религия. На мой взгляд, MIT-BSD самые удобные лицензии, но у красноглазиков от них подгорает. C>Удобные, для копирастов C>Прочитайте, под ней можно софтину перелицензировать, плюс даётся разрешение позволять пользователям модифицированной софтины делать с ней то же самое. То есть, по умолчанию у них такого права не будет.
Да, это как раз и есть настоящие свободные лицензии. В отличие от всякой вирусной мерзости типа GPL, которые не имеют вообще никакого отношения к свободе.
E>У винды, понятно, что всё в порядке с именами. Имена, кстати, могут ни в какую кодировку не укладываться, кроме юникода. Например каталог польский, а файл русский...
E>Так как мне написать совместимый код, который из текстового конфигурационника читает путь к файлу и возвращает istream ?
Небольшую обёртку написать.
Реализация ifstream в MSVC++ содержит конструкторы и функции open() с параметрами wchar_t* и std::wstring. Поэтому — реализовывай следующим образом:
Конфигурацию хранить в UTF-8. Под Виндовс конвертировать строку в wstring, под Linux — в кодировку текущей локали (сейчас обычно везде UTF-8). Сконвертированную строку используй в ifstream.
Без #ifdef не обойтись, но платформозависимого кода будет немного.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Рефлексия — это всё же run-time (когда программа уже написана), а шаблоны — чистый compile-time. Обе вещи полезны, но работают в совершенно разных областях.
Оригинальный смысл рефлексии — это когда программа сама себя наблюдает и модифицирует. Run-time или compile-time — зависит от того, что за программа подразумевается. В C++ идет нацеливание на compile-time и эдакую "мета-программу"
Здравствуйте, -MyXa-, Вы писали:
MX>Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
Сильно зависит от проекта. Я видел крупный проект на чистом Си, который собирается гораздо дольше.
Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\
S>те когда это еще Си с классами, а вот после этого стал уже С++
Чёткой грани нет. Например, кто-то считает, что использование virtual member functions это уже С++, хотя есть проекты на Си, которые вполне успешно эмулируют vtbl через массив + макросы. Большинство остальных элементов С++ тоже так или иначе реализуются на чистом Си или с раширешниями (например, RAII через аттрибут переменной __cleanup). Другое дело, что компилятор С++ может при прочих равных гарантиировать какую-то долю целостности. Я считаю более корректно — говорить "на проекте используется подмножество С++" с указаем того, что используется.
Здравствуйте, AlexGin, Вы писали:
AG>Так, если три кита ООП это: AG>1) инкапсуляция AG>2) наследование AG>3) полиморфизм
AG>Значит, Си с классами — это только первый шаг, когда кроме инкапсуляции, ничего другого (пока???) не умеют...
AG>Достаточно точное определение: AG>https://toster.ru/q/124001
S>>те когда это еще Си с классами, а вот после этого стал уже С++
AG>Вот когда поняли, что такое абстрактный базовый класс и чисто виртуальный метод... AG> AG>Тогда пора бежать в магазин за бутылкой — справлять новоселье в доме С++
Гы-гы-гы, это называется "перестал быть джуном"
Настоящий С++ это именно шаблоны и всё такое, когда программа пишет сама себя. (если что, то я его точно знаю на Hello-world уровне)
Здравствуйте, Mr.Delphist, Вы писали:
... MD>Гы-гы-гы, это называется "перестал быть джуном"
+100500
Никто и не спорит, но это уже ООП (пусть хоть и самое начало)
MD>Настоящий С++ это именно шаблоны и всё такое, когда программа пишет сама себя. (если что, то я его точно знаю на Hello-world уровне)
Без настоящей рефлексии, как в .NET языках (тот же C#) — очень сомневаюсь что это в полной мере возможно...
P.S. В то же время, если сравнивать дженерики C# и шаблоны C++ — выигрыш подхода шаблонов C++ очевиден:
Для C++ templates — это сущности времени компиляции (в процессе выполнения кода — работают быстро и шустро)...
Для C# generics — это сущности времени выполнения (в процессе выполнения кода — работают медленно)
P.P.S. Понятное дело, что для каждого типа прикладных задач — сушествует свой подход — где-то рациональнее применение динамического полиморфизма, с применением абстрактных базовых классов, RTTI и т.д. А где-то статический полиморфизм на шаблоноах — самое то!
Здравствуйте, sergey2b, Вы писали:
S>но тем неменее вы хотите выделить память скопировать результат, еще и возрат строки из функции будет чего то стоить
А потом бегут на кывт с вопросами почему прога на С++ работает медленее чем прога на python.
Здравствуйте, cures, Вы писали:
C>Беда не приходит одна! Эта реализация, опять же, имеет какую-то левую лицензию, да ещё и с явным копирайтом (не копилефтом) Микрософта.
Здравствуйте, alex_public, Вы писали:
_>Да, это как раз и есть настоящие свободные лицензии. В отличие от всякой вирусной мерзости типа GPL, которые не имеют вообще никакого отношения к свободе.
Ага, не дают со "свободных" дурачков бабла настричь!
Здравствуйте, sergey2b, Вы писали: S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\ S>те когда это еще Си с классами, а вот после этого стал уже С++
Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
коммент
На С++ этого рубежа можно (и нужно) достичь, примерно, за неделю разработки.
Если не поможет, будем действовать током... 600 Вольт (C)
Здравствуйте, sergey2b, Вы писали:
S>Прочел соседнию ветку S>объясните плиз чем Си с классами отличаеться от C++\
Попытаюсь выразить моё ИМХО, чтобы совсем уж не свалиться в КСВ...
Так, если три кита ООП это:
1) инкапсуляция
2) наследование
3) полиморфизм
Значит, Си с классами — это только первый шаг, когда кроме инкапсуляции, ничего другого (пока???) не умеют...
Достаточно точное определение: https://toster.ru/q/124001
S>те когда это еще Си с классами, а вот после этого стал уже С++
Вот когда поняли, что такое абстрактный базовый класс и чисто виртуальный метод...
Тогда пора бежать в магазин за бутылкой — справлять новоселье в доме С++
Ну а понимание концепции RTTI и всяких там dynamic_cast<...>() — это вообще праздник
Здравствуйте, -MyXa-, Вы писали:
... MX>Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
1) Это далеко не всегда так;
2) Сильно зависит от оборудования (я считаю, что компилировать проект нужно всегда на шустром SSD, а не на HDD).
Так, на современном компе проект на несколько человеко-лет с вполне даже C++11/14/17 уложится в это время,
особенно если в процессе рефакторинга прогеры выбрасывали ненужную хрень из проекта
MX>На С++ этого рубежа можно (и нужно) достичь, примерно, за неделю разработки.
Также очень спорное утверждение. Тем более спорное — насчет нужно:
обычно всё-таки стараешься решить поставленную задачу, а не просто раздуть объем полученного кода...
Здравствуйте, Skorodum, Вы писали:
S>Для большинства задач можно и без крайностей. В общем случае такие "крайности" дают остальным нормальные кросс-платформенные строки, контейнеры, доступ к файловой системе и т.д. с минимально возможными издержками.
Про кросс-платформенный доступ к ФС смешно. Как открыть на винде файл с юникодным именем?
Но в целом я не спорю, кстати, большинство наворотов в языке по делу. Просто часто программисты используют их по другому делу, неподходящему
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Про кросс-платформенный доступ к ФС смешно. Как открыть на винде файл с юникодным именем?
OpenFileW(), fwopen().
В C++17 появилась библиотека std::filesystem, которая умеет преобразовывать std::wstring в путь в кодировке ОС, а так-же умеет работать с UTF-8, UTF-16 и UTF-32.
Здравствуйте, AleksandrN, Вы писали:
AN>OpenFileW(), fwopen().
Это не совместимо
AN>В C++17 появилась библиотека std::filesystem, которая умеет преобразовывать std::wstring в путь в кодировке ОС, а так-же умеет работать с UTF-8, UTF-16 и UTF-32.
AN>NTFS хранит имя файла в юникоде.
У винды, понятно, что всё в порядке с именами. Имена, кстати, могут ни в какую кодировку не укладываться, кроме юникода. Например каталог польский, а файл русский...
Так как мне написать совместимый код, который из текстового конфигурационника читает путь к файлу и возвращает istream ?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AleksandrN, Вы писали:
AN>Без #ifdef не обойтись, но платформозависимого кода будет немного.
Ха, в таком режиме я и без STL умею...
Это про сто про совместимый доступ к файлам.
Если истории с юникодными именами файлов мало, можно задуматься над тем на какой платформе когда увеличивается длина файла на диске, когда мы открываем его на запись, потом делаем seek за конец, потом туда пишем
И т. д...
Ещё, кстати, можно задуматься над значением выражений вроде 155 >> 128
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, -MyXa-, Вы писали:
MX>Если весь проект, пусть даже он разрабатывался N человеко-лет, пересобирается быстрее, чем за 20 секунд, это Си с классами.
Не-а. У нас был проект многолетний, там сишная часть собиралась на HT-процах 20 минут. Но это был именно "ANSI C" для железяк и классический "C с классами" для десктопной части — там даже STL с таким боем удалось протолкнуть для работы с векторами и мэпами, что мама не горюй (ваш код никто не поймёт! да и вы сами тоже через N месяцев!)
Здравствуйте, Mr.Delphist, Вы писали:
MD>Не-а. У нас был проект многолетний, там сишная часть собиралась на HT-процах 20 минут. Но это был именно "ANSI C" для железяк и классический "C с классами" для десктопной части — там даже STL с таким боем удалось протолкнуть для работы с векторами и мэпами, что мама не горюй (ваш код никто не поймёт! да и вы сами тоже через N месяцев!)
20 минут — это ещё ничего.
Я участвовал в проекте, где проект собирался 8 (прописью — ВОСЕМЬ) часов.
Да, да и там не было ничего сложнее STL-я.
Здравствуйте, MasterZiv, Вы писали:
MZ>Говнокод на С++, написанный С-шником -- это "С с классами". MZ>Коды возврата вместо исключений. MZ>Возврат значений через указатель на результат в параметре. MZ>Указатели на коллбэки вместо полиморфизма. MZ>Макросы вместо шаблонов. MZ>И так далее.
И что интересно, всё это работает и делает то же самое.
Так с какого бодуна это — "говнокод"?
Здравствуйте, MasterZiv, Вы писали:
MZ>Здравствуйте, sergey2b, Вы писали:
>>объясните плиз чем Си с классами отличаеться от C++\ S>>те когда это еще Си с классами, а вот после этого стал уже С++
MZ>Говнокод на С++, написанный С-шником -- это "С с классами". MZ>Коды возврата вместо исключений. MZ>Возврат значений через указатель на результат в параметре. MZ>Указатели на коллбэки вместо полиморфизма. MZ>Макросы вместо шаблонов. MZ>И так далее.
это все Ст шные приколы
MZ>Возврат значений через указатель на результат в параметре.
скажем функция формирует текстовое сообшение в буфере, как вы его веренете в std::string ?
Здравствуйте, cures, Вы писали:
C>Здравствуйте, sergey2b, Вы писали:
S>>скажем функция формирует текстовое сообшение в буфере, как вы его веренете в std::string ?
C>Так и вернём, в std::string(buf).
прототип функции
что то преобразованиеСтроки(char *buf, size_t usize)
у нас уже есть буфер, но тем неменее вы хотите выделить память скопировать результат, еще и возрат строки из функции будет чего то стоить
Здравствуйте, 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 в строку отдельным проходом, или сразу делать выделяемый буфер изменяемого размера.
Много ли Вы при всём при этом рассчитываете сэкономить тем, что на первом проходе не выделите новый буфер, а уложитесь в старый (сделаев свою функцию более узко применимой) ? По операциям — одинаково: чтение-модификация-запись, причём, как я понимаю, последовательные. И то, что читать и писать будете в одну и ту же память, на скорость практически не повлияет. Выделение памяти — штука нынче довольно быстрая. Если Вам не нужна исходная строка — так она освободит память, если присвоите результат в неё же. Сдаётся мне, тут совершенно классический пример незрелой оптимизации.
Здравствуйте, cures, Вы писали:
C>Забавная конструкция, жалко что не стандартная.
Это часть C++ Core Gudelines Support Library. Кандидат на включение в C++20.
S>>https://github.com/Microsoft/GSL/blob/master/include/gsl/span#L510
C>Выделенное много объясняет: брать у них даже прилично выглядящий код, да ещё и с непонятной лицензией, чревато боком.
Здравствуйте, alpha21264, Вы писали:
A>И кого сейчас это волнует? A>Реально тормозит 1% программного кода. Вот его и надо оптимизировать. A>А остальное пишется как проще/надёжнее.
Что значит "1% тормозит"? Если ты закинул работу с std::string, обеспечивающими успешно копирования туда-сюда одного и того же на ровном месте (и не только std::string, много у чего из STL та же проблема), в асинхронный хендлер (код который вызывается в потоке хендлера) сетевого демона, то эта функция просто сразу же вылетает в топ в профилировщике при задании демону высокой нагрузки. Недавно возился с apache trafficserver, он написан на Си с классами с редкими вкраплениями использования параметризации типов, но нигде нет ни малейшего использования штук из STL в коде ядра демона (это 98% всего TS), всё своё, оптимизированное по-максимому.
Здравствуйте, AlexGin, Вы писали:
AG>Без настоящей рефлексии, как в .NET языках (тот же C#) — очень сомневаюсь что это в полной мере возможно...
Рефлексия — это всё же run-time (когда программа уже написана), а шаблоны — чистый compile-time. Обе вещи полезны, но работают в совершенно разных областях.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, alpha21264, Вы писали:
A>>И кого сейчас это волнует? A>>Реально тормозит 1% программного кода. Вот его и надо оптимизировать. A>>А остальное пишется как проще/надёжнее.
S>Что значит "1% тормозит"? Если ты закинул работу с std::string, обеспечивающими успешно копирования туда-сюда одного и того же на ровном месте (и не только std::string, много у чего из STL та же проблема), в асинхронный хендлер (код который вызывается в потоке хендлера) сетевого демона, то эта функция просто сразу же вылетает в топ в профилировщике при задании демону высокой нагрузки. Недавно возился с apache trafficserver, он написан на Си с классами с редкими вкраплениями использования параметризации типов, но нигде нет ни малейшего использования штук из STL в коде ядра демона (это 98% всего TS), всё своё, оптимизированное по-максимому.
Ну вот примерно это и означает.
Есть места, которые надо оптимизировать, а есть места, которые не надо.
Тех, которые надо, в среднем 1%. Во всех остальных делаем как проще.
Ты же хотел "шаблоны и прочие возможности языка"? Ну вот они.
В данном случае STL. Ты што, против STL? Ну ты и ретроград!
Здравствуйте, Ops, Вы писали:
Ops>Это религия. На мой взгляд, MIT-BSD самые удобные лицензии, но у красноглазиков от них подгорает.
Удобные, для копирастов
Прочитайте, под ней можно софтину перелицензировать, плюс даётся разрешение позволять пользователям модифицированной софтины делать с ней то же самое. То есть, по умолчанию у них такого права не будет.
Здравствуйте, smeeld, Вы писали:
S>Что значит "1% тормозит"?
Это значит, что остальные 99% не тормозят
S>Если ты закинул работу с std::string, обеспечивающими успешно копирования туда-сюда одного и того же на ровном месте (и не только std::string, много у чего из STL та же проблема),
"На ровном месте" никто ничего никуда не копирует. Максимальная возможная неприятность, которая и обсуждается, — следят, чтобы никто не прошёл неинициализированным. Копировать обратно в тот же буфер, или же в буфер новый — по времени стоит практически одинаково.
S>в асинхронный хендлер (код который вызывается в потоке хендлера) сетевого демона,
С демонами аккуратнее надо быть.
S>то эта функция просто сразу же вылетает в топ в профилировщике при задании демону высокой нагрузки.
Нагрузка не должна особо поменяться. Может чуть подрасти расход памяти. Или Вы не умеете их готовить.
S> Недавно возился с apache trafficserver, он написан на Си с классами с редкими вкраплениями использования параметризации типов, но нигде нет ни малейшего использования штук из STL в коде ядра демона (это 98% всего TS), всё своё, оптимизированное по-максимому.
Из того, что какая-то софтина написана на Ц с классами и работает быстро, никак не следует, что на крестах она работала бы медленней. Но в целом, я верю, что apache вылизывали по максимуму, дожимая даже не самые горячие места. Альфа же, совершенно справедливо, говорит, что в обычном повседневном программировании такое редко требуется. Гораздо важнее сделать код надёжным, повторно используемым и сопровождаемым. Simple is better than complex. Beautiful is better than ugly.
И Питон Вы таки не к месту упомянули, нет в том коде потери производительности на два с лишним порядка ни в одном из вариантов.
Здравствуйте, alpha21264, Вы писали:
A>Ты же хотел "шаблоны и прочие возможности языка"? Ну вот они. A>В данном случае STL. Ты што, против STL? Ну ты и ретроград!
Похоже. Вы не совсе мопоняли. STL-это либа. Вообще говоря выступаю за параметризацию сущностей в целях обобщения и абстрагирования используя для этого шаблоны С++ (не штуки из STL) как средство. Почему-то под понятием шаблонов C++ часто понимается использование каких-то библиотек, которые входят в стандарт и которые предоставляют параметризованные сущности. С какого перепугу?
Здравствуйте, cures, Вы писали:
C>Удобные, для копирастов
Нет, удобные для пользователей, использующих код. Как копирасты могут что-то предъявить к такому коду, или нажиться на нем — вообще непонятно.
C>Прочитайте, под ней можно софтину перелицензировать, плюс даётся разрешение позволять пользователям модифицированной софтины делать с ней то же самое. То есть, по умолчанию у них такого права не будет.
Это ж здорово. Я могу с кодом делать что хочу, и ни перед кем ни отчитываться, в отличие от богомерзкой GPL, которая мало того, что ограничивает использование, так еще и прилипает намертво к любому коду, который заденет.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, MasterZiv, Вы писали:
>>объясните плиз чем Си с классами отличаеться от C++\ S>>те когда это еще Си с классами, а вот после этого стал уже С++
MZ>Говнокод на С++, написанный С-шником -- это "С с классами". MZ>Коды возврата вместо исключений. MZ>Возврат значений через указатель на результат в параметре.
Это удел фортранщиков. У них там in и out переменные. Благо передаются все по ссылке.
А как правильно? В нормальных языках (перл, tcl, питон) можно вернуть список. В C++ до введения auto и tuple делать было нечего.
MZ>Указатели на коллбэки вместо полиморфизма.
Не соглашусь в общем случае. О полиморфизма как раз зло, он вынуждает вместо легковесного класса адаптера городить тот самый C с классами. Да, коллбэк как функция -- зло. Но интефейсный класс не сильно меньшее зло. Что мешало оставить некий функтор, в который ляжет лямбда или std::function адаптирующая вызов к реальному классу, если он там вообще есть и нужен.
MZ>Макросы вместо шаблонов.
Макросы не заменяют шаблоны и наборот. Можно пытаться изобразить шаблон из макроса (но для него ж элементарно не написать специализации для разных типов, например). Часто макросы пишутся вместо отсутствущих вложенных функций (которые есть в паскале и gcc без ++).
fk0> Подразумевается, что C++ это не только объектно-ориентированное программирование. Но и какие-то элементы метапрограммирования на шаблонах, возможности по перегрузке функций и операторов, пространства имён, argument dependent lookup в частности, исключения, полиморфизм, какой-то syntax sugar и современного C++ типа lambda-выражений. В середине-конце 90-х и начале 2000-х выпускалось много книг рассматривающих C++ именно в разрезе OO, мол это единственная парадигма и серебрянная пуля, видимо отсюда и пошёл C с классами, от Turbo-C++, первых версий MSVC, да и поддержка C++ в них была далеко не на высоте, в gcc времён 3.3.3 тоже. Собственно в начале 2000-х все возможности C++ и использовать толком не было возможности, так что C с классами скорей старая школа, кто учился в начале 2000-х.
про операторы, шаблоны для функций min max и namespace вопрсов нет
где можно например использовать остальное в
большой колекции однотипных объектов
web server
сканирование файлов
топик был создан с целю понять что можно использовать из нового в текущем проекте
