#6Опубликовано admin в Февраль 15, 2013 - 02:28.
Ну вы там свою книжку тогда напишите с блэкджеком и шлюхами и в ней воздерживайтесь от чего хотите, а мне не надо рассказывать про достоинства STL, моё мнение по поводу этого бастарда окончательно и пересмотру не подлежит — как, впрочем, и относительно людей, которые не понимают, почему STL именно бастард, а не что-то иное. Я, кстати, не понял, какой "первый раз" имеется в виду, книжка-то, между делом, выдержала три издания, и у меня она не первая и не единственная.
Под первоисточниками лично я привык понимать ровно те материалы, которые использованы при подготовке текста, и никакие иные. В данном случае Мейерс и кого вы там ещё упоминаете — в число "первоисточников" не входят, я вообще не считаю нужным тратить время на чтение "современных" книжек по C++ (последняя книжка, прочтение которой не было пустой тратой времени — это "дизайн и эволюция", но, естественно, старого издания, ещё до начала STL-ной эпохи), а "почему не надо использовать операцию преобразования типа" — вынесено из личного опыта.
По поводу очередного поделья "стандартизаторов" я тоже уже высказывался, повторяться смысла не вижу.
#8Опубликовано admin в Май 12, 2013 - 21:48.
Андрей, для первого раза, я имел ввиду для начинающих.
Принято.
А по поводу stl и с++11 с вами многие не согласятся.
Многие? Я больше скажу: со мной не согласятся практически все, кто C++ увидел после 1999 года (или 1995, если речь идёт об англоязычных программистах), и многие из тех, кто C++ увидел раньше. При этом всех этих "несогласных" можно поделить ровно на две части: (1) те, кто пишут на C++ (с использованием STL и прочих примочек) и (2) те, кто на C++ больше не пишут, потому что "это просто мрак какой-то".
При этом если мы разделим программистов, знающих (но не обязательно использующих) C++, по другому признаку, а именно — на людей, разборчивых в выборе средств, и на тех, кто плевать хотел на грамотный выбор инструмента, лишь бы быстро сляпать, чтобы как-то работало — то получим ровно те же самые две категории людей. Те, кто в выборе средств не разборчив, используют C++ в связке с STL. Те, кто разборчив, в большинстве своём просто уходят из C++ на другие языки, кто-то "вверх", на питон, например, или на Java, кто-то "вниз", на plain C, причём часто даже ANSI C. Замечу, мне часто приходится видеть ООП на чистом С в исполнении таких людей, они моделируют наследование, вручную строят таблицы виртуальных функций и т.п., но о возврате к C++ при этом даже не помышляют, ибо весь этот кошмар с STL'ем, RTTI и прочими примочками — ну, кошмар и есть кошмар.
Остаётся ещё очень малочисленная группа людей, разборчивых в средствах, но при этом понимающих, что C++ сам по себе — инструмент неплохой, если не считать STL и всякие Boost'ы имманентной принадлежностью "C++-программирования" и если быть готовым, например, к --disable-rtty и отказу от исключений. К этой последней группе принадлежу, собственно, я, и я очень надеюсь, что эта группа пополняется за счёт моих учеников и читателей моей книжки.
Например, если мне нужен hash map, у меня нет желания подключать стороние библитотеки или писать его самому пока это не будет критическим.
Ну так пишите на Java или на Питоне, кто мешает? Зачем вам C++, если вы готовы одним махом (подключением STL) угробить все его достоинства?
. Или как написать операторы сложения матриц без копирования временных обьектов (a+b+c) без rvalues&
Как-как, известно как — сделать отдельно объект реализации этой матрицы со счётчиком ссылок и copy-on-write.
Конечно, из-за нагромождения всяких бесполезных структур данных с++ программа может начать работать медленее чем на скала [...] Но это уже квалификация разработчиков
Вы одну простую вещь поймите — это не разработчики виноваты, это вот так вот на мышление программиста действует этот монструозный конгломерат. То есть если быть неразборчивым в средствах, то в результате такая вот "низкая эффективность" будет лишь одним из неизбежных негативных последствий. Ну а человек, разборчивый в средствах, STL применять не станет.
не надо микроскопом забивать гвозди.
Забивание гвоздя микроскопом начинается в тот момент, когда использовано ЛЮБОЕ имя из namespace std. Коготок увяз — всей птичке пропасть.
В целом, спасибо за книгу.
Пожалуйста, мне не жалко. А вам она зачем, если не секрет? Вы на перворазника вроде не похожи.
#18Опубликовано admin в Май 28, 2013 - 16:05.
Начать с того, что тело операции ++ никак не может оказать влияние на то, как её можно, а как нельзя вызывать. Тело и вызов вообще могут быть в разных единицах трансляции.
А по указателю передаётся объект при вызове операции ++. И речь здесь о том, что, оказывается, временный/анонимный объект можно передавать в его методы по неконстантному this, что, мягко говоря, неожиданно, особенно с учётом того, что передавать временные/анонимные объекты по неконстантным ссылкам нельзя, и это объясняется так, что неконстантная ссылка по смыслу — выходной параметр, а временные и анонимные объекты по смыслу — не леводопустимые (то есть как бы константы, хотя и не const).
#22Опубликовано admin в Ноябрь 21, 2013 - 02:44.
Дело в том, что вы не совсем правы. Неявное преобразование указателей будет работать там, где разрешено использование знания о том, что унаследованный класс является наследником своего предка. Например, если сделать некую функцию "другом" наследника, то внутри этой функции преобразование по закону полиморфизма работать будет: этой функции _разрешено_ знать, что наследование имеет место. То же самое будет происходить и, например, в методах наследника, включая статические — там это знание тоже разрешено.
В принципе, это напрямую следует из того, что сказано в книжке, но вообще я подумаю на тему отдельного замечания в этом плане.
Тут ещё такой момент есть, что в реальной жизни приватное наследование никогда не применяется — я, во всяком случае, ни разу с таким не сталкивался и с трудом представляю себе ситуации, когда оно зачем-то может понадобиться; ну а объём книжки хотелось бы сохранить небольшим. Есть ведь и более серьёзные вещи, которые в книжке полностью обойдены вниманием: namespaces, например, или множественное наследование, или там указатели на метод класса, да ещё много чего.
