m110h написал(а):Я просто начал использовать его в своих проектах и пока не знаю всех подводных камней
Да нету там подводных камней. И указанная конструкция скорее всего отработает по скорости не хуже, чем strlwr. Просто любым инструментом надо уметь пользоваться. Вот чем плох микроскоп? Если им забивать гвозди - то да, неудобно, медленно, да и дорого впридачу. Ровно то же самое в std::map пытаться сохранить 100500 ключей и надеяться, что оно по скорости обойдет, чем специализрованный метод, применяемый в каком-нибудь mysql. Но для прототипирования и не performance critical кода хватает с головой и большим запасом. Более того, ее можно использовать в pc коде, если ключей не особо много (благополучно используем, и ботлнек ох как не в нем). Та же история, если std::list использовать для хранения большого количества мелких, постоянно используемых объектов. Но при этом, от того что вы сами реализуете список лучше вам вряд ли станет. Искуство программирования стоит не в поиске "подводных камней", особенно там, где их нет, а в понимании, какой инструмент/алгоритм подходит для решения задачи, как при этом не изобрести очередной кривой велосипед (и не погрязнуть в его отладке) и как сделать так, что бы написанный код использовался чуть больше одного раза. Я еще не разу не сталкивался с ситуацией, когда проблемы в архитектуре приложения были бы связаны с языком С++. Это исключительно всегда ошибки на этапе проектирования (например, из за отсутствия опыта). Ненавистники С++, к которым относится, к сожалению, и Алексей, предпочитают во всем видеть именно "убогость языка". При этом они, как правило, не могут объяснить, когда им не хватало compile time композирования и, например, статической типизации делегатов. При этом великие и мудрые, например Гамма или Хелм, в необходимости динамического композирования и "динамической" типизации видят исключительно ошибку архитектуры приложения. И если говорить строго, то это так и есть. Необходимость в этом является серъезным источником ошибок и значительно снижает эффективность.
