Дядя Миша
Как вообще связано использование абстракций и невозможность реализации определенных алгоритмов?
Выглядит как сравнение умений рисовать чертежи от руки и в программных пакетах, для этого заточенных. То есть никакой связи.
ComradeAndrew писал: Как вообще связано использование абстракций и невозможность реализации определенных алгоритмов?
в данном случае речь не за абстракцию, а за арихметику указателей. Уж если человек не может выучить 4 правила арифметики, куды ему более сложные задачи?
Цитата:
XaeroX писал: Берём std::map... Всё.
А вместо указателей берём auto_ptr? Меня вот мысль посетила, а что если разработчики STL будут писать все программы за всех программистов мира? Раз они такие умныя.
Дядя Миша писал: Уж если человек не может выучить 4 правила арифметики, куды ему более сложные задачи?
Дело не в правилах арифметики, а в банальной человеческой забывчивости и невнимательности. Использование сырых указателей имеет свои плюсы, но может легко привести к вылетам. А это баги, которые надо чинить, тратя на это ресурсы (время и деньги). Умные указатели позволяют эти ресурсы сэкономить ценой небольшого снижения производительности, в большинстве случаев приемлемого. Хотя нам, движкописателям, этого не понять - у нас почти весь код performance-critical.
Цитата:
Дядя Миша писал: А вместо указателей берём auto_ptr?
В старом стандарте, С++98 - да. В новом он deprecated, т.к. есть более качественная и эффективная реализация с учётом move-семантики - unique_ptr.
Цитата:
Дядя Миша писал: а что если разработчики STL будут писать все программы за всех программистов мира?
Так они и так уже почти все кирпичики написали, осталось их сложить в нужном порядке и заточить под твои входные данные. А если они чего-то не написали - есть boost, в котором как в Греции, ну ты понял.
Дядя Миша
Конкретно этот подход ни к чему подобному не приводит.
Он приводит к удешевлению и ускорению разработки, что куда более актуально, чем оптимизация потребления памяти с 500 Мб до 498 Мб.
Сколько времени у тебя займёт написать собственную реализацию КЧ-дерева, при условии что копипастить CUtlRbTree из Сорса - нельзя? Час? И ещё час на отладку и базовые тесты? И она будет быстрее STL-ной, ты это можешь заранее гарантировать?
XaeroX писал: Он приводит к удешевлению и ускорению разработки, что куда более актуально
К ускорению разработки в первую очередь приводит знакомая среда, а не чьи-то непонятные инструменты.
Цитата:
XaeroX писал: чем оптимизация потребления памяти с 500 Мб до 498 Мб.
Правильно понимаю, это ты переписал скайп и сэкономил всего 2 мегабайта?
Цитата:
XaeroX писал: при условии что копипастить CUtlRbTree из Сорса - нельзя?
вот и задумайся отчего в сорсе STL не юзали. А вопрос можно брать или нельзя зависит от условий поставленной задачи. Где-то и самому писать нельзя, только STL.
Цитата:
XaeroX писал: И она будет быстрее STL-ной, ты это можешь заранее гарантировать?
Я в канпиляторах вот кокрастоке выкинул STL и получил прирост в 12% примерно, по скорости. Так что да, могу.
Дядя Миша писал: Правильно понимаю, это ты переписал скайп и сэкономил всего 2 мегабайта?
Нет, я предположил, что из 500 Мб оверхед умных указателей где-то 2 Мб будет. У тебя есть какие-то конкретные данные по этому вопросу?
Цитата:
Дядя Миша писал: вот и задумайся отчего в сорсе STL не юзали.
Зачем задумываться, я знаю, отчего в сорсе STL не юзали. В те годы STL был весьма сырым. Но с момента начала разработки сорса почти 20 лет прошло, и многие "детские" болезни STL излечены. Во многом - благодаря улучшению языка в стандарте С++11.
Цитата:
Дядя Миша писал: Я в канпиляторах вот кокрастоке выкинул STL и получил прирост в 12% примерно, по скорости.
А где гарантия, что компиляторы писали грамотные люди, которые правильно использовали STL? Если плохо знаешь язык, можно и с арифметикой сырых указателей так затормозить программу, что мало не покажется.
Цитата:
Дядя Миша писал: Так что да, могу.
Ты хотя бы CUtlRbTree относительно std::map профилировал?