Здравствуйте, 0BD11A0D, Вы писали:
BDA>А вообще, если хочется большего контроля, никто не запрещает кодировку задавать как для экземпляра (в конструкторе), так и по умолчанию для всего проекта (через проектный #define).
Для всего проекта получается неудобным, т.к. часто приходится работать сразу с несколькими кодировками.
Задавать для экземпляра тоже не шибко удобно. Какую ты ожидаешь реализацию? pimpl? Или делать что-то универсальное, сразу для всех кодировок?
Я бы предпочел разные классы для разных строк, но это вредно для здоровья кросс-платформенных приложений.
Поэтому std::string в качестве контейнера (с тем же успехом можно и std::vector использовать, но печатать больше) и набор функций для его трансформации это вполне разумный компромисс.
Где нужна высокая производительность будут использовать оптимизированные варианты.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Cyberax, Вы писали:
SVZ>>>Универсального решения здесь нет. BDA>>То же самое говорили про int16/int32/int64 C>Поэтому сейчас все используют int128 для всего, да?
Речь, вообще-то, шла о введении менее абстрактных, но более полезных типов данных. То есть, fixed width integer types. Хотя бы как альтернативы более абстрактным.
BDA>>А вообще, если хочется большего контроля, никто не запрещает кодировку задавать как для экземпляра (в конструкторе), так и по умолчанию для всего проекта (через проектный #define). C>#define идёт в топку вместе с тем, кто предлагает такое решение. Задание кодировки в самой строке будет требовать дополнительные 4/8 байт на указатель и будет мешать Small String Optimization.
Я же написал: если хочется большего контроля. Меня и жесткая кодировка устраивает.
C>Естественно, при этом не давая никаких преимуществ кроме того, что говноразработчики смогут втыкать ToLower, не удосужившись даже заглянуть в документацию. C>А потом будут чесать репу почему std::govnostring("ISTANBUL".ToLower()) != std::govnostring("istanbul").
А почему это программисты на C# — говноразработчики, а не лично вы? По какому такому критерию определили? А то я, например, видал знатоков, которые день-деньской читали разные документации, но добиться от них пользы на три байта невозможно было. Я вот считаю, что это они бесполезное говно.
Здравствуйте, Zenden, Вы писали:
Z>Люблю заниматься перекомпилированием библиотек под разные компиляторы, дебаг/релиз, статик/шаред,64 бит/32 бит Z>Люблю получать странные ошибки линковки и медитировать над ними. Z>Люблю собирать опен-сурс проекты под виндой (интересно проходить этот квест) Z>Люблю многообразие систем сборки для С++.
Кстати да. Я в своё время от души намучился при попытках собрать опенсорсные либы bullet (с поддержкой double, особенно сборка примеров к нему доставляет!), CEGUI и v8 так, чтобы crt статически линковалась (т.к. не хочу заставлять юзеров ставить отдельный рантайм), и под 64 бита (дебаг/релиз). Для CEGUI полностью статическую линковку я так и не осилил (оно настаивает на том, чтобы рендер был в отдельной dllке), .lib файл для v8 в дебаге получился больше 600 МБ, а потому гитхаб его не захотел принимать (я все референсы держу в сорс-контроле для того, чтобы максимально облегчить билд — скачиваешь содержимое ветки, открываешь проект — и всё сразу билдится безо всяких танцев с бубном). v8 вообще удивил — чтобы его сбилдить, нужно поставить какую-то ихнюю утилиту, которая поставит питон (который, кстати, у меня почему-то не встал, потому пришлось вручную подсовывать его, предварительно выяснив, в какой именно папке и с каким именно именем оно хочет его видеть), который используется для генерации проектных файлов, которые уже можно использовать для билда (не забыв слегка подточить их напильником для того, чтобы использовали статическую crt).
Здравствуйте, Cyberax, Вы писали:
BDA>>Первые два пункта: это до тех пор, пока вы остаетесь в рамках старой парадигмы «Си с классами». Я встречал то ли на кремниевой тайге, то ли на геймдеффе (падонкавском, а не который .ру) душещипательный рассказ о неудовлетворительном падении перфоманса после попыток использовать (правильным образом, конечно) STL. То есть, при попытке использовать удобства, которые есть в других языках, в тех приложениях, которым перфоманс жизненно важен (3D-движках, например) результат будет принципиально неудовлетворительным. C>Ой, ну что за кретинический бред. В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов.
При довольно развесистом графе объектов может сказываться лишняя косвенность, если они, например, std::vector заюзали там, где достаточно std::array.
C>Из того, что я видел, чаще всего страдают из-за того, что в STL не так много всего. Т.е. если нужен контейнер указателей, то не думая берут vector<shared_ptr<...>>, а потому репу чешут и пишут на форумы о тормозах STL.
Есть такое. Это вечный выбор м/у shared_ptr и intrusive_ptr.
Увы, даже в новом стандарте нет ничего про intrusive_ptr.
C>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов, которые можно сразу через memcpy копировать.
Это ты так пошутил??? ))
Например MS VC старается НЕ ВСТАВЛЯТЬ явный вызов memcpy для мест, где ему известен объем копирования, вместо этого просто генерит код, который перекачивает данные через MMX/SSE/AVX регистры (если были разрешены опциями компиляции). Библиотечный же memcpy работает через rep stos и это медленнее чем генерируемый компиллером код при разрешении использовать векторные регистры.
При копировании STL вектора для POD-типов в релизе он тоже перекачивает память через MMX/SSE/AVX точно так же, как в тех случаях, когда используются массивы заведомо известного размера.
Здравствуйте, vdimas, Вы писали:
C>>Ой, ну что за кретинический бред. В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов. V>При довольно развесистом графе объектов может сказываться лишняя косвенность, если они, например, std::vector заюзали там, где достаточно std::array.
Не вижу проблем STL.
C>>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов, которые можно сразу через memcpy копировать. V>Это ты так пошутил??? ))
Нет.
V>Например MS VC старается НЕ ВСТАВЛЯТЬ явный вызов memcpy для мест, где ему известен объем копирования, вместо этого просто генерит код, который перекачивает данные через MMX/SSE/AVX регистры (если были разрешены опциями компиляции).
Это из-за того, что в MSVC CRT очень тормозной memcpy. А вот в glibc используется быстрая реализация с использованием всех возможных фич процессора. Причём она выбирается линкером динамически при загрузке библиотеки в зависимости от CPU (механизм ifunc).
Здравствуйте, 0BD11A0D, Вы писали:
C>>Поэтому сейчас все используют int128 для всего, да? BDA>Речь, вообще-то, шла о введении менее абстрактных, но более полезных типов данных. То есть, fixed width integer types. Хотя бы как альтернативы более абстрактным.
Это скорее просто кодификация сложившейся практики.
C>>#define идёт в топку вместе с тем, кто предлагает такое решение. Задание кодировки в самой строке будет требовать дополнительные 4/8 байт на указатель и будет мешать Small String Optimization. BDA>Я же написал: если хочется большего контроля. Меня и жесткая кодировка устраивает.
А меня нет.
C>>Естественно, при этом не давая никаких преимуществ кроме того, что говноразработчики смогут втыкать ToLower, не удосужившись даже заглянуть в документацию. C>>А потом будут чесать репу почему std::govnostring("ISTANBUL".ToLower()) != std::govnostring("istanbul"). BDA>А почему это программисты на C# — говноразработчики, а не лично вы?
Говноразработчики — это дизайнеры С# 1.0, которые думали книгой по ООП вместо моска. ЧСХ, в версии 2.0 им пришлось добавить https://msdn.microsoft.com/en-us/library/system.string.tolowerinvariant%28v=vs.110%29.aspx
BDA>По какому такому критерию определили? А то я, например, видал знатоков, которые день-деньской читали разные документации, но добиться от них пользы на три байта невозможно было. Я вот считаю, что это они бесполезное говно.
По признаку нарушения SRP и использования глобального состояния, в самом ядре библиотечного кода.
Здравствуйте, koandrew, Вы писали:
Z>>Люблю многообразие систем сборки для С++. K>Кстати да. Я в своё время от души намучился при попытках собрать опенсорсные либы bullet
Ну так это не С++ виноват а криворукие аффтары либы, которые её слепили как сумели.
К>Всем привет, К>Я вощем то С++ программист, звезд с неба не хватаю, писал всяикий аккаунтинг в стиле С++ с классами. К>Сейчас открыл книгу Effective Modern C++ про С++14,С++11 и думаю, блин, для кого они все это придумывают?! Для самих себя?
К>Напрмиер было:
К>typedef void (*FP)(int, const std::string&); // typedef
К>Стало:
К>using FP = void (*)(int, const std::string&);
К>Там, мля, целый комитет умников сидит, они что, сразу не могут примдумать как нормально сделать? К>Конечно как бы все улучшилось, но это только потому что до этого все ухудшалось так что и компилер не сразу выпустишь.
Z>Здравствуйте, кубик, Вы писали:
К>>Всем привет, К>>Я вощем то С++ программист, звезд с неба не хватаю, писал всяикий аккаунтинг в стиле С++ с классами. К>>Сейчас открыл книгу Effective Modern C++ про С++14,С++11 и думаю, блин, для кого они все это придумывают?! Для самих себя?
Z>Я люблю С++, в нем большой простор для творчества! Z>Чтобы написать приложение, нужно уметь писать костыли под разные компиляторы и платформы, Z>Люблю изучать информативные сообщения об ошибках (access violation at adresss 0xFFFFFFFF) Z>Люблю С++ за скорость компиляции (можно сходить куда-нибудь по делам) Z>Люблю препроцессор, особенно макросы, они делают код живым. Z>Никогда не знаешь, что сломает компиляцию на этот раз (С++ любит удивлять!) Z>Люблю заниматься перекомпилированием библиотек под разные компиляторы, дебаг/релиз, статик/шаред,64 бит/32 бит Z>Люблю получать странные ошибки линковки и медитировать над ними. Z>Люблю собирать опен-сурс проекты под виндой (интересно проходить этот квест) Z>Люблю многообразие систем сборки для С++.
Z>Не то что эти всякие попсовые Сишарпы/жавы для слабаков. Написал код, а он просто работает. Скучно ведь! Z>Чувствуешь себя ненужным.
А еще есть забавы с совместимости библиотек C++98 и C++11, когда огрызки STL светятся, как weak символы.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Забавно, вы тоже читали старика Дага. А я его закончил неделю назад или около того. Тяжелое чтение, доложу я вам. Английский у него как у Эми из Футурамы. Но кое-что интересное нашлось.
Читается легко, но только когда в автобусе едешь и не чего делать. Вот Страуструпа читать в разы тяжелее. Я сейчас на середине его новой редакции для C++11. Ну хоть бы шутки какие вставлял, что ли. Но материал очень полезный, с другой стороны.
BDA>Что касается рационального объяснения, то давайте с него и начинать.
G>>Я предпочел бы отделить ToLower и Split от std::string. Они редко нужны и строку легче использовать без них. Я согласен с автором, строку легче использовать, когда в ней нет ToLower и друзей...
Ответившие на твой пост уже привели причины. Я еще могу добавить.
1. Чем меньше кода в классе, тем быстрее он компилируется. А стринг это темплейт, то есть будет добавлен в качестве хедера в множество файлов. Эти функции могут потянуть за собой целый граф зависимостей, в зависимости от их реализации.
2. Интеллисенс "загрязняет". Еще два элемента в выпадающем списке. Мелочь конечно, но все же. "Залог успеха это множество продуманных мелочей" Черчиль
3. Тяжелее читать хедер STL, если там больше всего. А когда ошибки с темплейтами сыпятся иногда приходится смотреть на его кишки. Чем их больше, тем хуже в них ориентироваться. Чем меньше размер отдельного класса, тем легче его читать и понять. Это и есть "разделяй и властвуй".
4. Разобравшись с детялями std::transform и to_upper, мне уже не нужно держать в голове то, что делает string::ToUpper(). А голова — это как чердак забитый хламом, как говорил Шерлок Хомс.
Я давно хотел привести тебе еще одну статью из той самой C++ Coding Standards. Она называется 44. Prefer writing nonmember nonfriend functions. Ты будешь смеяться, вот что там написано:
Examples
Example: basic_string. The standard basic_string is a needlessly monolithic class with
103 member functions—of which 71 could be written as nonmember nonfriends
without loss of efficiency. Many of them duplicate functionality already available as
algorithms, or are themselves algorithms that would be useful more widely if they
weren't buried inside basic_string. (See Items 5 and 32, and [SutterO4].)
Так что, там уже дохрена всего, и без того трудно с ней иметь дело.
BDA>1. Так ведь нет их в языке вообще нигде. Даже в другом месте. Буст не часть языка. Вы не можете создать новый проект в IDE и скомпилировать вызовы из boost::algo. Поэтому его и любят — это багаж малополезных знаний (куда копировать, как собирать под нужную платформу), за которые можно попросить больше денег.
Все делается алгоритмами. На stackoverflow есть способы сделать все это без буста и с высоким контролем над решением. Сплит делается с помощью std::find и цикла.
BDA>2. Что значит «Строку легче использовать без них»? Я второй раз задаю этот вопрос. Программист увидит ToLower и Split и будет вынужден разбираться, тратить время? Неправда: он видит эти концепции прямо в GUI. А гугловский программист вдобавок должен знать про ECMAScript. Сама строка легче станет? Не вызывайте, она и не утяжелится. Это C++.
Написал выше.
BDA>3. Каждая из них, может быть, нужна редко, но все вместе они нужны часто. Вот еще один автор, который пишет на джюглише: http://www.joelonsoftware.com/articles/fog0000000020.html Обратите внимение на 'Unfortunately, it's never the same 20%'. С моей точки зрения, это характерная ошибка, которую допустили создатели C++ и вы, а умницы из команды FCL и Джоэл избежали. Себя к последним не добавляю по причине того, что я сначала увидел хорошее решение, а потом задумался, почему оно такое. Не факт, что я бы не наступил на эти же грабли.
Вот оно идолопоклонничество!!! Только разочарую, у вас с ним не взаимно. В одном из своих знаменитых постов, Джоел заявил, что программистов, у которых английский не родной, надо отправлять на помоечку.
BDA>Это зависит от (им)мутабельности. Если строка мутабельная, зачем? Может, вызывающей стороне оригинал не нужен. Если нужен, пусть снимет копию сам.
Ну так вот. Уже сложности. Не такой он и простой этот ToUpper, оказывается.
BDA>Так к этому и надо относиться: дорогая, но удобная операция. Вы что, предлагаете вообще заставить программиста ее сочинять?
Так о том и речь. Если хочется удобств, то надо на джаву или дот нет сразу идти, а Си плюс плюс хорош тонкой настройкой решения.
BDA>Неправда и это. Вы, скорее всего, никогда не делали то, что делал я: брали процессы и читали их string table в Process Explorer. Поделайте, и поищите там %d. Я иду прямо по списку: Classic Shell, Windows Explorer, MyHomeLib, Steam, Media Player Classic, дрова от звуковой карты — все они полны форматированием строк. Исключение в моем списке — Фотошоп и Фурифокс. BDA>Значит, их авторы не думают, что он нужен редко. Как минимум, несколько раз в проекте употребляют. Употребляют в виде какого-нибудь snwprintf, при всей неудобности такого вызова. Или пишут свои классы.
Конечно делал такое. Стринг тейбл это все, что можно там увидеть. Все остальное бнарное. Я же не против safe printf и не против его в отдельной функции.
G>>Для Split, в большинстве случаев, программист захочет читать строку и получать указатели на каждый элемент по очереди. Во первых, для этого не нужно туда сюда копировать. Во вторых, можно остановиться после нахождения нужного значения и не парсить дальше.
BDA>Здравстуйте, а терминаторный ноль кто будет вписывать для каждого элемента? Зачем ему набор указателей с общим терминатором на всех? Короче, это никакое не большинство случаев, а самое редкое исключение.
Имея пару итераторов и если нужна строка, то так:
std::string item(begin, end);
G>>Я думаю, отметать книжки и работу других людей не продуктивно. У них есть таланты, желание, им заплатили и они потратили кучу времени на изучение особенностей языка.
BDA>Ну, я уже понял, что вы джастификационист. Еще когда вы первый раз на гугл сослались. Дело ваше, но я не могу общаться с джастификационистами: ИМЕННО ЭТО непродуктивно. От них не получишь новых, напоминаю вам ваши же слова: «рациональных объяснений», а только ссылки на авторитеты.
Скорее то, что надо всем бежать на дотнет и джаву это и есть авторитетное мнение от лучших программисто-водов. И гугл тоже, кстати, предпочтет джаву для нового проекта, скорее всего.
BDA>Что касается команд, создайте свою, где можно сослаться на гугл и заткнуть рты. А результаты мы потом сравним.
Не на гугл, а на C++ Coding Standards 101 Rules ... или на Страуструпа или Сатера. С удовольствием поработал бы в такой команде. Только, к сожалению, больше встречаю "чукча не читатель, чукча писатель".
BDA>>>А, так значит dynamic_cast<T>(o), который вы пропустили — не «антипаттерн» (что бы это слово ни значило)? Тогда зачем ОН режет глаз? Чтоб жизнь медом не казалась?
BDA>Так он «антипаттерн» или нет? Если да, какой кастинг не? Если нет, зачем он такой уродливый? Мало ли что редкий.
Он ровно настолько уродлив, насколько он не желателен. Скобки убрали потому, что они захватывают в себе несколько операций, в то время, как нужна только одна. А какой бы синтаксис ты предпочел для этой группы, не объединяя их всех в одну операцию, как были сишные скобки?
BDA>Кстати, «антипаттерность» тоже не оправдание, чтобы делать вещи уродливыми. Не хочешь давать использовать — убери из языка или генерируй deprecation warning, хотя бы. Требуй unsafe, в конце концов. Но уж если оставляешь —
Я думаю когда их задумывали, то уродливость не ставилась как цель. Это случайный бонус. И, все таки, а как это сделать красивее?
Здравствуйте, Cyberax, Вы писали:
C>Это из-за того, что в MSVC CRT очень тормозной memcpy. А вот в glibc используется быстрая реализация с использованием всех возможных фич процессора. Причём она выбирается линкером динамически при загрузке библиотеки в зависимости от CPU (механизм ifunc).
Так это же отлично.
Но ты не объяснил мне, зачем вручную заставлять делать точно так же, если компилятор генерит такой же код при копировании вектора?
К тому же, MSVC вызывает библиотеку только для случая, когда количество копируемых байт на этапе компиляции неизвестно, а это достаточно редкий сценарий, который к тому же говорит, что в консерваитории что-то не так. ))
Голые байты на тех сценарий, в которых важно быстродействие memcpy, "перекачивают" блоками фиксированного размера. Это важно и это, действительно, даёт заметный профит (это по опыту разработок для VoIP в частности и обработчки сигнала в общем). Для интристика с известным на этапе компиляции размером можно сгенерить совсем другой код, чем для неизвестного. Например, объект размером ровно 256 байт MSVC копируется просто 4-мя подряд операциями перекачки double-регистров SSE2 прямо по месту в коде. Какая нафик библиотечная ф-ия? ))
C>Вот для самообразования её код для разных процессоров:
У ты, ах ты...
Разве у других сломался вывод в дизассемблированном виде при отладке?
И почему для разных процессоров, если у меня проц подерживает одновременно SSE2, AVX и AVX D?
Причем, эти наборы команд используют одни и те же регистры, хоть и "видят" их по-разному (SSE2 и AVX D видят данные одинаково).
Да еще ты дал код для копирования через memcpy невыровненных даных...
Какая боль... в обсуждении про то, как важен быстрый memcpy.
Умудриться так низко пасть и при этом писать "для самообразования".
От тебя всегда как привет из параллельной реальности ))
Здравствуйте, 0BD11A0D, Вы писали:
BDA>1. Так ведь нет их в языке вообще нигде. Даже в другом месте. Буст не часть языка. Вы не можете создать новый проект в IDE и скомпилировать вызовы из boost::algo. Поэтому его и любят — это багаж малополезных знаний (куда копировать, как собирать под нужную платформу), за которые можно попросить больше денег.
Qt дает вам как раз такие строки, как Вам хочется, со всеми свистелками и перделками, запускаете на любой платформе IDE (QtCreator), и эти строки вам доступны без каких-либо дополнительных телодвижений. С++ тем и хорош, что он может быть любым, в частности и таким, который Вам нравится.
BDA>2. Что значит «Строку легче использовать без них»? Я второй раз задаю этот вопрос. Программист увидит ToLower и Split и будет вынужден разбираться, тратить время? Неправда: он видит эти концепции прямо в GUI. А гугловский программист вдобавок должен знать про ECMAScript. Сама строка легче станет? Не вызывайте, она и не утяжелится. Это C++.
Мне кажется, путаница возникает из-за того, что Вы не различаете 2 типа строк — гуишную строку, которая нужна для работы с текстами в гуе, и строку-"универсальный контейнер текста", которая нужна на более низком уровне, например при работе с файлами. В первом случае все эти форматирования, ToUpper, Split и т.п. нужны, и поэтому есть во всех реализациях гуишных строк (QString, CString, etc.). Во второй реализации, эти операции не просто вредны, они часто просто не имеют смысла. Что такое ToUpper в строке иероглифов, и как корректно делать сплит в строке, состоящей их символов разного размера, как в ютф8? Я уже не говорю про строки, которые будут какой-то смесью разных вариантов. std::string будет корректно работать с самыми экзотическими текстовыми данными, какие только вы сможете придумать, даже такими, про которые вообще будет непонятно как их вообще отображать в гуе, и возможен ли для них хоть какой-то гуй. Когда к нам прилетят инопланетяне с каким-нибудь невообразимым языком, или когда какой-то безумный математик придумает еще более невообразимый язык для каких-то своих целей, std::string скорее всего сможет работать с текстовыми файлами на этих языках. Регистр символов или разбиение на символы или лексемы — это не базовые свойства текста, возможны тексты без этих понятий, поэтому работы с ними и нет в базовой, максимально универсальной std::string.
Все остальное мне кажется следствием неразличения этих двух типов строк, так что подробно разбирать остальные Ваши претензии к std::string я не буду.)
Здравствуйте, vdimas, Вы писали:
V>Так это же отлично. V>Но ты не объяснил мне, зачем вручную заставлять делать точно так же, если компилятор генерит такой же код при копировании вектора?
Быстрее.
V>К тому же, MSVC вызывает библиотеку только для случая, когда количество копируемых байт на этапе компиляции неизвестно, а это достаточно редкий сценарий, который к тому же говорит, что в консерваитории что-то не так. ))
memcpy из glibc работает быстрее нативного копирования во всех случаях, когда размер не известен статически и больше порядка 64 байт.
V>У ты, ах ты... V>Разве у других сломался вывод в дизассемблированном виде при отладке?
Ну так покажи что там генерирует MSVC. Мы посмеёмся вместе.
V>И почему для разных процессоров, если у меня проц подерживает одновременно SSE2, AVX и AVX D?
А у меня не поддерживает AVX. А на другом процессоре SSSE3 быстрее. Что мне делать?
V>Умудриться так низко пасть и при этом писать "для самообразования". V>От тебя всегда как привет из параллельной реальности ))
То что ты ничерта не знаешь, не хочешь знать, и являешься эталоном полного ламера — мы уже давно выяснили.
Здравствуйте, jahr, Вы писали:
J>Мне кажется, путаница возникает из-за того, что Вы не различаете 2 типа строк — гуишную строку, которая нужна для работы с текстами в гуе, и строку-"универсальный контейнер текста", которая нужна на более низком уровне, например при работе с файлами.
Надо ли говорить, что эти два типа строк существуют только в некоторой модели ЯП? Есть доказавшие свою жизнеспособность модели, в которых никакого разделения нет. Реально вопрос стоит так: в чем выигрыш от того, что введено подобное разделение?
Смотрим аргумент за аргументом.
>Что такое ToUpper в строке иероглифов,
Зачем брать иероглифы? Есть иллюстрация попроще: что такое "@#$%^&*".ToUpper()? Классический NoOp. Тем не менее, нужда в нем есть и безо всяких гуев: любая поисковая система нуждается в том, чтобы свести текст к наиболее общему виду, уничтожая регистр. Или возьмите компилятор Паскаля. Оттого, что в тексте есть символы, которые при преобразовании не меняются, нужда в таких преобразованиях не исчезает.
>и как корректно делать сплит в строке, состоящей их символов разного размера, как в ютф8?
Что значит «как»? Законы логики или физики не запрещают.
>Я уже не говорю про строки, которые будут какой-то смесью разных вариантов. std::string будет корректно работать с самыми экзотическими текстовыми данными, какие только вы сможете придумать, даже такими, про которые вообще будет непонятно как их вообще отображать в гуе, и возможен ли для них хоть какой-то гуй. Когда к нам прилетят инопланетяне с каким-нибудь невообразимым языком, или когда какой-то безумный математик придумает еще более невообразимый язык для каких-то своих целей, std::string скорее всего сможет работать с текстовыми файлами на этих языках.
Извините, это не я написал. Я просто присоединяюсь к написанному: язык для инопланетян и безумных математиков, совершенно верно. Таков его архитектурный идеал, начиная с эры степановских шаблонов.
>Регистр символов или разбиение на символы или лексемы — это не базовые свойства текста, возможны тексты без этих понятий, поэтому работы с ними и нет в базовой, максимально универсальной std::string.
Максимально универсальной? Ну, неправда же. Сами назовете примеры текста, с которым через интерфейс std::string работать нельзя, или подсказать? Что касается регистра, то это, как раз, способ построить универсальную модель: считать, что такое преобразование есть у каждого символа, но у некоторых оно нулевое. Дальше есть два пути: подсчитать общее число символов, с учетом неоткрытых языков и нашествия инопланетян, и долю ненулевых преобразований (путь архитектурных лунатиков) и частоту употребления символов с ненулевым преобразованием относительно остальных (путь прагматиков). По мере того, как прагматиками будет осознаваться, какие лунатики делали обсуждаемый язык, они все меньше будут к нему прибегать.
Проблема в том, что лунатизм плюсов, если разобраться, не такое уж большое зло. Проприетарность гораздо хуже. Иногда полезнее мириться с психами и их архитектурой. Это я, собственно, и написал изначально. Есть целые сектора и направления разработки, где кроме плюсов ничего толком не лезет. Но это не значит, что мы вам все забудем и простим.
Здравствуйте, greenpci, Вы писали:
G>1. Чем меньше кода в классе, тем быстрее он компилируется. А стринг это темплейт, то есть будет добавлен в качестве хедера в множество файлов. Эти функции могут потянуть за собой целый граф зависимостей, в зависимости от их реализации.
На этот предмет есть технологии типа precompiled headers. И вообще, забавно слышать это по адресу C++, языка, ОЧЕНЬ ПЛОХО ПОДХОДЯЩЕГО для быстрой компиляции. Им есть чего подкрутитть задолго до того, как строки уродовать, причем эффекта будет намного больше.
G>2. Интеллисенс "загрязняет". Еще два элемента в выпадающем списке.
А теперь послушайте другую интерпретацию вашего наблюдения. Чуть ли не единственное, но убойное преимущество ООП — возможность так организовать код, что он становится самодокументируемым. Как раз интеллисенс играет тут первую скрипку. Вы открываете его окошко и видите ВСЕ возможности некоторого класса. Альтернатива — курить маны. То есть, вышел новый стандарт, новый STL, новый boost и вы должны сразу прочитать, понять и запомнить все, что написано в сопроводиловке. Нормальные люди предпочитают осмотреть классы с высоты птичьего полета, чтобы знать, что вообще есть, а потом уже углубленно знакомиться с нюансами вызова методов (типа, почему пишется Манчестер, читается Истанбул).
Как раз вынесение алгоритмов за пределы классов принципиально и не дает воспользоваться этим преимуществом ООП. Процедурщина и хендловщина в полный рост.
G>3. Тяжелее читать хедер STL, если там больше всего. А когда ошибки с темплейтами сыпятся иногда приходится смотреть на его кишки. Чем их больше, тем хуже в них ориентироваться. Чем меньше размер отдельного класса, тем легче его читать и понять. Это и есть "разделяй и властвуй".
Не приведя примера такой ошибки, вы затрудняете обсуждение этого пункта. Например, шаблоны у вас, скорее всего, не к месту, но как я это покажу, не видя кода?
Однако по сути вы все равно не правы, и это видно даже без примеров. Мне лень объяснять детали и я сделаю проще: прибегну к специальной терминологии. Ошибка, которую вы допускаете, называется редукционизм. Что это значит и как понимать, вы узнаете из этой книги: https://books.google.ru/books/about/The_Fabric_of_Reality.html?id=2LqEPNf9jXsC&hl=en В качестве бонуса каждому прочитавшему я готов дать один файлик всего лишь на 255 байт, который, по вашей теории, должно быть легко читать и понимать. Редкая птица долетала до его середины.
G>4. Разобравшись с детялями std::transform и to_upper, мне уже не нужно держать в голове то, что делает string::ToUpper().
И это тоже ошибка редукционизма. Концепт string::ToUpper() занимает в голове меньше места, чем применение std::transform в каждом конкретном случае.
G>Я давно хотел привести тебе еще одну статью из той самой C++ Coding Standards. Она называется 44. Prefer writing nonmember nonfriend functions. Ты будешь смеяться, вот что там написано:
G>
G>Examples
G>Example: basic_string. The standard basic_string is a needlessly monolithic class with
G>103 member functions—of which 71 could be written as nonmember nonfriends
G>without loss of efficiency. Many of them duplicate functionality already available as
G>algorithms, or are themselves algorithms that would be useful more widely if they
G>weren't buried inside basic_string. (See Items 5 and 32, and [SutterO4].)
Привели, и что? Смеяться я не буду, это просто ничем не обоснование утверждение, над чем же тут смеяться?
G>Так что, там уже дохрена всего, и без того трудно с ней иметь дело.
Короче, две книжки, которые я вам посоветовал, могут полностью перевернуть ваше миропонимание. На каждом шагу вылезает то, что объяснить проблемы сиплюсплюса и его архитектуры лучше всего в терминах типа редукционизма, но сначала же теория нужна. Образование. А своими словами пересказывать эти фундаментальные труды я не могу.
BDA>>1. Так ведь нет их в языке вообще нигде. Даже в другом месте. Буст не часть языка. Вы не можете создать новый проект в IDE и скомпилировать вызовы из boost::algo. Поэтому его и любят — это багаж малополезных знаний (куда копировать, как собирать под нужную платформу), за которые можно попросить больше денег.
G>Все делается алгоритмами. На stackoverflow есть способы сделать все это без буста и с высоким контролем над решением. Сплит делается с помощью std::find и цикла.
Все делается на ассемблере. Идите уже до конца. Остальное в глазах редукциониста должно быть просто ненужное повышение уровня.
BDA>>2. Что значит «Строку легче использовать без них»? Я второй раз задаю этот вопрос. Программист увидит ToLower и Split и будет вынужден разбираться, тратить время? Неправда: он видит эти концепции прямо в GUI. А гугловский программист вдобавок должен знать про ECMAScript. Сама строка легче станет? Не вызывайте, она и не утяжелится. Это C++.
G>Написал выше.
То есть, все-таки, место в голове. Как завещал Холмс. Так вот, а я тоже выше написал: это место в голове у вас и так потрачено. Учитывая, что операции с регистром вы видите в ГУИ, ECMAScript и еще ста местах, надрочиться на чтение std::transform(s.begin(), s.end(), s.begin(), ::toupper); как s.ToUpper() на самом деле только потратит лишние клетки. Хотя, конечно, проделав с собой такое очень обидно признавать, что все это было напрасно.
BDA>>3. Каждая из них, может быть, нужна редко, но все вместе они нужны часто. Вот еще один автор, который пишет на джюглише: http://www.joelonsoftware.com/articles/fog0000000020.html Обратите внимение на 'Unfortunately, it's never the same 20%'. С моей точки зрения, это характерная ошибка, которую допустили создатели C++ и вы, а умницы из команды FCL и Джоэл избежали. Себя к последним не добавляю по причине того, что я сначала увидел хорошее решение, а потом задумался, почему оно такое. Не факт, что я бы не наступил на эти же грабли.
G>Вот оно идолопоклонничество!!! Только разочарую, у вас с ним не взаимно. В одном из своих знаменитых постов, Джоел заявил, что программистов, у которых английский не родной, надо отправлять на помоечку.
Не припоминаю за ним таких постов, но я про него весьма невысокого мнения. А как человек он мне и вовсе не нравится.
Тем не менее, отдадим ему должное, он, в процитированной колонке, дает ХОРОШЕЕ ОБЪЯСНЕНИЕ, почему bloatware (не всякое, а такое, как System.String или MS Office 2000) — миф. И это хорошее объяснение хорошо изложено. Вы это объяснение проигнорировали, а прицепились к тому, кто его дал. И если это, по-вашему, продуктивное поведение, то от продукта вашего поведения не очень хорошо пахнет.
BDA>>Это зависит от (им)мутабельности. Если строка мутабельная, зачем? Может, вызывающей стороне оригинал не нужен. Если нужен, пусть снимет копию сам. G>Ну так вот. Уже сложности. Не такой он и простой этот ToUpper, оказывается.
Нет, он простой. Сначала вы определяетесь, какие плюсы и минусы с какой стороны медали выбрать. Будете ли вы делать строку иммутабельной или нет. Это отдельное решение. Затем делаете ToUpper() в соответствии с принятым решением. Сложности в нем самом нет никакой.
BDA>>Так к этому и надо относиться: дорогая, но удобная операция. Вы что, предлагаете вообще заставить программиста ее сочинять?
G>Так о том и речь. Если хочется удобств, то надо на джаву или дот нет сразу идти
Сегодня жемчужины в этом форуме собираю горстями. Вот так вот, хочется удобств — вали отсюда. Прямо в FAQ просится, кроме шуток. Чтоб знать, с чем связываешься.
G>Я же не против safe printf ... в отдельной функции.
А я против. По причинам, изложенным в ответе на п.2.
G>>>Для Split, в большинстве случаев, программист захочет читать строку и получать указатели на каждый элемент по очереди. Во первых, для этого не нужно туда сюда копировать. Во вторых, можно остановиться после нахождения нужного значения и не парсить дальше.
BDA>>Здравстуйте, а терминаторный ноль кто будет вписывать для каждого элемента? Зачем ему набор указателей с общим терминатором на всех? Короче, это никакое не большинство случаев, а самое редкое исключение.
G>Имея пару итераторов и если нужна строка, то так:
G>
G>std::string item(begin, end);
G>
То есть, это не копирование, так получается?
G>Я думаю когда их задумывали, то уродливость не ставилась как цель. Это случайный бонус. И, все таки, а как это сделать красивее?
dynamic_cast — никак. Сама его идея — оператор, который будет работать только при заданных опциях сборки проекта — уродлива. В других языках, где RTTI неотключаем, это делается изящным оператором as. Для всего остального есть (T).
Здравствуйте, Cyberax, Вы писали:
C>>>Поэтому сейчас все используют int128 для всего, да? BDA>>Речь, вообще-то, шла о введении менее абстрактных, но более полезных типов данных. То есть, fixed width integer types. Хотя бы как альтернативы более абстрактным. C>Это скорее просто кодификация сложившейся практики.
При том, что такая кодификация — нарушение идеалов абстракции, заложенных в первые версии. (Это, конечно, если не считать, что неопределенность размера обусловлена банальной необдуманностью). И правильно, к черту эти идеалы. Одно из немногих правильных решений в эволюции этого чудовища.
C>>>Естественно, при этом не давая никаких преимуществ кроме того, что говноразработчики смогут втыкать ToLower, не удосужившись даже заглянуть в документацию. C>>>А потом будут чесать репу почему std::govnostring("ISTANBUL".ToLower()) != std::govnostring("istanbul"). BDA>>А почему это программисты на C# — говноразработчики, а не лично вы? C>Говноразработчики — это дизайнеры С# 1.0, которые думали книгой по ООП вместо моска. ЧСХ, в версии 2.0 им пришлось добавить https://msdn.microsoft.com/en-us/library/system.string.tolowerinvariant%28v=vs.110%29.aspx
Я бы, скорее, подумал, что это было сдуто с setlocale(). А потом доведено до ума.
BDA>>По какому такому критерию определили? А то я, например, видал знатоков, которые день-деньской читали разные документации, но добиться от них пользы на три байта невозможно было. Я вот считаю, что это они бесполезное говно. C>По признаку нарушения SRP и использования глобального состояния, в самом ядре библиотечного кода.
Давайте пересчитаем R. Я вижу ровно одну — представлять типичные операции с кусками текста. В отличие от C++, где их смешано две — контейнерные операции и substr() (как представитель чисто строковых функций).
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Я бы предпочел разные классы для разных строк, но это вредно для здоровья кросс-платформенных приложений.
Здравствуйте, Константин, Вы писали:
К>Стандарт сильно волнует только студентов, преподавателей, и ещё глупых разработчиков каких-то SDK. Всем остальным на него пофигу.
К сожалению, разработчики компиляторов и IDE зачем-то ориентируются на него. А их продукты волнуют уже и прагматиков.
К>Для игр однако это не очень критично, по следующим причинам: (1) Программисты всё равно обходятся в разы дешевле, чем арт (2) Код игр уже давно разделили на ядро (обычно С++) и скрипты (часто LUA). (3) Развитый рынок middleware, заточенный в основном на C++ клиентов, усложняет миграцию.
BDA> Сама его идея — оператор, который будет работать только при заданных опциях сборки проекта — уродлива. В других языках, где RTTI неотключаем, это делается изящным оператором as. Для всего остального есть (T).
эээ... ты о чем??
dynamic_cast это обязательная часть стандарта, он "неотключаем".
В стандарте есть понятие "polymorphic type", dynamic_cast работает только на них, а программист понимает, что делая класс polymorphic он может платить определеннубю цену.
Это исключительно расширение компилятора -- позволить отключить RTTI. Компилятор с такой опцией включенной не удовлетворяет стандарту.
