Здравствуйте, 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).
