fret Покажи мне пальцем, где я хоть слово сказал про операционные системы MS, в частности Vista? Речь пока что шла про STL. Не путай палец с сам знаешь чем. Имею ли я достаточный авторитет? Этот вопрос нужно задавать не мне, а остальным людям. Лично мне абсолютно по барабану, имею я авторитет, или нет. Согласен кто-то с моими высказываниями, или нет. Я не собираюсь никому ничего доказывать. Это совершенно бессмысленная, бесплодная и бесцельная трата времени. По крайней мере моего. Я просто высказываю свою точку зрения с элементами иронии)) Соглашаться с ней или слать ее фтопку - твое неотъемлемое право и твое личное дело. Добавлено. Предлагаю провести на васме соц. опрс: "DEN - достаточно ли авторитетен этот человек?" :-D
_DEN_ Системы от Microsoft я привел в качестве примера к твоему удтверждению что размер исполнимого файла неважен. Он может быть не важен в единичной программе, а если этих файлов многие тысячи? Пусть 10-20гб места на диске это не так много, но держать все это гавно в памяти это чересчур высокая плата за ускорение процесса разработки. Память ведь еще не исчисляется десятками гигабайт, да и лучше использовать ее для чего нибудь полезного, а не для хранения тысяч никому не нужных файлов огромного размера. Может быть проблема в том, что современное поколение программистов теряет квалификацию? И сейчас те кто не умеет написать даже хеловорд без STL и .NET и не наделать в нем кучу ошибок поливают грязью немногих кодеров которые еще способны делать маленькие, быстрые и безглючные программы.
fret Ты опять навязываешь мне слова, которых я не говорил. Размер программы, потребление памяти, и производительность, это три разных критерия. Я говорю только про первый, а ты мне, как это кое-где говорят, подводишь второй и третий. Вот не надо этого делать, хорошо? Я говорю только про то, что я говорю, не надо дописывать картину своей рукой)) А про мелкие программы и ленивых программистов... Ну да, ленивые, глупые и бездарные люди есть везде. Ну и что теперь? По-твоему STL является г**ном только потому что им никто пользоваться не умеет? Прикол. 99,9% людей не знают как решать дифференциальные уравнения. И что теперь? Дифференциальные уравнения - го*но? Добавлено. Боюсь, что не поймешь метафоры)) Вот простым языком: 99,9% людей не умеют пользоваться C++ (STL, boost и всем остальным). Эти 99,9% пишут жуткий шыт, от которого такие как ты и страдают. И такие как ты делают выводы о языке и его библиотеках по результатам работы этих 99,9%. Вот только ни C++, ни STL никакого отношения к этим 99,9% не имеют. Судить о языке по его продуктам в корне не верно, при условии что этим языком никто толком пользоваться не умеет.
KeSqueer Бугага, кросавчег, плюсадин! Йа упрям как баран! )))) Мне это кстати очень помогает в жизни)))
Размер программы напрямую связан с потреблением памяти. Ты с этим не согласен? Программа имеющая максимально универсализированый код в большинстве случаев будет избыточна, и такой код будет иметь больший размер и работать медленее кода специализированого под решаемую задачу. Не согласен? Отсюда вывод - меньший размер во многих случаях, но не всегда, говорит о большей производительности и меньней требовательности к ресурсам. Примеров этому могу привести великое множество, да впрочем даже ты со своим ослиным упорством не сможешь это отрицать.
Не согласен ни сколечко)) Не согласен ни сколечко)) Моя - не будет)) Получается что вывод не верный)) Согласен! Но я уже сказал, что 99,9% не умеют использовать C++. Все эти примеры - детища этих 99.9%. Только что это доказывает?
Нехорошее заявление, совсем нехорошее. Просто-таки некорректное. Сомневаюсь, что это применимо к пресловутым TL - шаблоны таки. [added]В смысле, лишнего кода там не появится. Вобщем, по-моему логическая цепочка как-то сильно прохромала. Да и была не совсем в тему. Возвращаясь к изначальному вопросу... Скажем так - когда и, немаловажно, кому не стоит использовать STL?
_DEN_ Ты не согласен со мной, я не согласен с тобой. Остается только послать тебя на три буквы и закрыть дискуссию.
Voodoo Все просто. STL не стоит использовать тому, кто не умеет им пользоваться и не понимает зачем он нужен. Не нужно использовать STL только для того, чтобы использовать STL. Вот и все. fret Нееееет!!! После посылания на три буквы я должен тоже послать тебя туда же, после этого мы должны встретиться в реале и подраться! :-D
Не следует его использовать тем кто решает системно ориентированые задачи. Здесь приветствуется только си без всяких наворотов. И все нормальные оси пишуться на си, а не на с++ с STL. Может вы скажете что разработчики этих ОС идиоты не знающие всей мощи приплюснутых наворотов, но я так не считаю. Ну а нашему высококвалифицированому STL кодеру Дену стоит показать нам свой сверхоптимизированый код, чтобы ни у кого не было сомнений что он так крут как хочет казаться. Встречный вопрос - а кому нужно его использовать? Допустим я поверю что с STL можно писать программы не хуже чем без него. Тогда зачем мне нужно его изучать, если я могу писать быстрый, компактный, безглючный код без всякого STL, который будет понятен любому с первого взгляда, что немаловажно. Как уже было сказано - не нужно писать на STL ради STL, а лично я от него не получу абсолютно никакой пользы.
Нравится вам или нет - без STL в достаточно больших проектах плохо. Каждый мега кодер считает что свой велосипед-дерево-контейнер будет работать в н-цать раз быстрее. Потратит, скажем, 4 часа на разработку и отладку и даже если там не окажется багов, будет отлично если он выиграет хотя бы 15% от скорости STL'ного контейнера. А ведь можно заюзать уже готовый контейнер, делов на минуту максимум. Или еще пример: сортировку каждый раз руками писать? Особенно когда сортировать надо, например, по полю структурки? std:sort таки очень быстрый и точно будет быстрее баблсорта, который на коленке склепает такой вот сотрудник. Да и code reuse рулит, а то я уже видел проектов, где если надо было сортировать что то, каждый раз вписывали баблсорт, так как лень было писать qsort с его рекурсией и доп. функциями. Вобщем, STL это не панацея, а просто хороший и качественный инструмент которым нужно уметь пользоваться. Если умеешь - понимаешь как можно сократить время разработки не потеряв в скорости выполнения приложения.
15% это серьезная прибавка если речь идет об оптимизации часто использующегося алгоритма. Ради этого позволено потратить гораздо больше 4х часов. Если же ваш мега-кодер оптимизирует то что оптимизировать не нужно, то увольте его и наймите кодера способного прислушиваться к ТЗ. Зачем же каждый раз руками? Есть библиотечный вызов qsort работающий без всяких STL с массивами любого типа. Увольте тех кто каждый раз пишет пузырьковую сотрировку в каждом месте где она применяется. Они явно не слышали о повторном использовании кода и о стандартных библиотеках не прибавляющих ни байта к размеру программы, потому что они всегда есть в системе и всегда уже загружены в память. Если время сортировки сверхкритично и размер сортируемых данных составляет десятки гигабайт, то можно потратить время на эксперименты с своей комбинацией qsort и merge sort.
_DEN_ С тобой все ясно. Черезвычайно повышеная самооценка в сочитании с ослиным упорством. Переубеждать таких бесполезно - проще убить.
Осел ослу: - Слушаай, да ты - осел! Не закрывайте тему, а то если я (да собсно, любой из не-модеров-форума) попрошу, так вы непременно забьёте болтик на просьбу сию )
Есть отличная штука, принцип 80-20. 80% всего времени выполняется в 20% кода. Оптимизировать 20% надо, остальные 80% просто надо писать сразу правильно и не заморачиваться с premature optimization. Если нет готового инструмента (сортировки, контейнера, пофиг), будут писать "специализированные" велосипеды. Твоя фраза про специализированный код не вяжется с фразой о повторном использовании кода. Не поверите - C'шный qsort медленнее std::sort в 2 раза. Гугл в помощь. Почему - инлайн за счет темплейтов и не обязательно qsort (там адаптивный выбор алгоритма, во всяком случае в STLPort). Эээ.. Сишный CRT не добавляет ни байта к размеру программы? Это как? А есть разница сколько там данных, если гарантированно готовый алгоритм будет давать весьма приемлимую скорость (быстрее библиотечной qsort)? Вот и получается, или писать что то под конкретный случай (на каждый случай свое - тратить время) или юзать уже готовое. Вот это и есть code reuse.
Код (Text): Размер программы напрямую связан с потреблением памяти. если размер бинарника, написанного без STL, на харде меньше аналогичного с STL на 1 Мб (к примеру конечно), то в памяти он будет занимать меньше на этот же Мб или еще большая разница может получится. Код (Text): Не согласен ни сколечко)) Моя - не будет)) практически всегда можно написать более оптимальную по быстродействию/размеру функцию для конкретной задачи, чем унифицированный аналог. например достаточно избежать лишних проверок корректности аргументов в частовызываемых функциях. я слышал про 90-10 %)
Все прекрасно вяжется. Я говорил о необходимости оптимизации ключевых участков кода от которых зависит производительность. Курите msvcrt.dll или libc.so. Нужный код уже есть в ОС в единственном экземпляре. Есть разница. Потому что сортировать данные превыщающие размер памяти ни STL ни CRT не умеют.
