*TL - за и против?

Тема в разделе "LANGS.C", создана пользователем Voodoo, 14 фев 2008.

  1. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    fret

    Покажи мне пальцем, где я хоть слово сказал про операционные системы MS, в частности Vista? Речь пока что шла про STL. Не путай палец с сам знаешь чем.


    Имею ли я достаточный авторитет? Этот вопрос нужно задавать не мне, а остальным людям. Лично мне абсолютно по барабану, имею я авторитет, или нет. Согласен кто-то с моими высказываниями, или нет. Я не собираюсь никому ничего доказывать. Это совершенно бессмысленная, бесплодная и бесцельная трата времени. По крайней мере моего. Я просто высказываю свою точку зрения с элементами иронии)) Соглашаться с ней или слать ее фтопку - твое неотъемлемое право и твое личное дело.


    Добавлено.

    Предлагаю провести на васме соц. опрс: "DEN - достаточно ли авторитетен этот человек?" :-D
     
  2. KeSqueer

    KeSqueer Сергей

    Публикаций:
    0
    Регистрация:
    19 июл 2007
    Сообщения:
    1.183
    Адрес:
    Москва
    ))
    Ну, раз так, то
    DEN давно на форуме, получаю достойные ответы, но его сложно в чем-то убедить.
     
  3. fret

    fret New Member

    Публикаций:
    0
    Регистрация:
    30 янв 2008
    Сообщения:
    24
    _DEN_
    Системы от Microsoft я привел в качестве примера к твоему удтверждению что размер исполнимого файла неважен.
    Он может быть не важен в единичной программе, а если этих файлов многие тысячи? Пусть 10-20гб места на диске это не так много, но держать все это гавно в памяти это чересчур высокая плата за ускорение процесса разработки. Память ведь еще не исчисляется десятками гигабайт, да и лучше использовать ее для чего нибудь полезного, а не для хранения тысяч никому не нужных файлов огромного размера.
    Может быть проблема в том, что современное поколение программистов теряет квалификацию? И сейчас те кто не умеет написать даже хеловорд без STL и .NET и не наделать в нем кучу ошибок поливают грязью немногих кодеров которые еще способны делать маленькие, быстрые и безглючные программы.
     
  4. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    fret

    Ты опять навязываешь мне слова, которых я не говорил.

    Размер программы, потребление памяти, и производительность, это три разных критерия. Я говорю только про первый, а ты мне, как это кое-где говорят, подводишь второй и третий. Вот не надо этого делать, хорошо? :derisive: Я говорю только про то, что я говорю, не надо дописывать картину своей рукой))

    А про мелкие программы и ленивых программистов... Ну да, ленивые, глупые и бездарные люди есть везде. Ну и что теперь? По-твоему STL является г**ном только потому что им никто пользоваться не умеет? Прикол. 99,9% людей не знают как решать дифференциальные уравнения. И что теперь? Дифференциальные уравнения - го*но?

    Добавлено.

    Боюсь, что не поймешь метафоры)) Вот простым языком: 99,9% людей не умеют пользоваться C++ (STL, boost и всем остальным). Эти 99,9% пишут жуткий шыт, от которого такие как ты и страдают. И такие как ты делают выводы о языке и его библиотеках по результатам работы этих 99,9%. Вот только ни C++, ни STL никакого отношения к этим 99,9% не имеют. Судить о языке по его продуктам в корне не верно, при условии что этим языком никто толком пользоваться не умеет.
     
  5. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    KeSqueer

    Бугага, кросавчег, плюсадин! Йа упрям как баран! )))) Мне это кстати очень помогает в жизни)))
     
  6. fret

    fret New Member

    Публикаций:
    0
    Регистрация:
    30 янв 2008
    Сообщения:
    24
    Размер программы напрямую связан с потреблением памяти. Ты с этим не согласен?
    Программа имеющая максимально универсализированый код в большинстве случаев будет избыточна, и такой код будет иметь больший размер и работать медленее кода специализированого под решаемую задачу. Не согласен?
    Отсюда вывод - меньший размер во многих случаях, но не всегда, говорит о большей производительности и меньней требовательности к ресурсам. Примеров этому могу привести великое множество, да впрочем даже ты со своим ослиным упорством не сможешь это отрицать.
     
  7. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Не согласен ни сколечко))

    Не согласен ни сколечко)) Моя - не будет))

    Получается что вывод не верный))

    Согласен! Но я уже сказал, что 99,9% не умеют использовать C++. Все эти примеры - детища этих 99.9%. Только что это доказывает?
     
  8. Voodoo

    Voodoo New Member

    Публикаций:
    0
    Регистрация:
    9 апр 2003
    Сообщения:
    297
    Адрес:
    Новосибирск
    Нехорошее заявление, совсем нехорошее. Просто-таки некорректное.

    Сомневаюсь, что это применимо к пресловутым TL - шаблоны таки.
    [added]В смысле, лишнего кода там не появится.

    Вобщем, по-моему логическая цепочка как-то сильно прохромала. Да и была не совсем в тему.

    Возвращаясь к изначальному вопросу... Скажем так - когда и, немаловажно, кому не стоит использовать STL?
     
  9. fret

    fret New Member

    Публикаций:
    0
    Регистрация:
    30 янв 2008
    Сообщения:
    24
    _DEN_
    Ты не согласен со мной, я не согласен с тобой. Остается только послать тебя на три буквы и закрыть дискуссию.
     
  10. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Voodoo

    Все просто. STL не стоит использовать тому, кто не умеет им пользоваться и не понимает зачем он нужен. Не нужно использовать STL только для того, чтобы использовать STL. Вот и все.


    fret

    Нееееет!!! После посылания на три буквы я должен тоже послать тебя туда же, после этого мы должны встретиться в реале и подраться! :-D
     
  11. fret

    fret New Member

    Публикаций:
    0
    Регистрация:
    30 янв 2008
    Сообщения:
    24
    Не следует его использовать тем кто решает системно ориентированые задачи. Здесь приветствуется только си без всяких наворотов. И все нормальные оси пишуться на си, а не на с++ с STL. Может вы скажете что разработчики этих ОС идиоты не знающие всей мощи приплюснутых наворотов, но я так не считаю.
    Ну а нашему высококвалифицированому STL кодеру Дену стоит показать нам свой сверхоптимизированый код, чтобы ни у кого не было сомнений что он так крут как хочет казаться.
    Встречный вопрос - а кому нужно его использовать?
    Допустим я поверю что с STL можно писать программы не хуже чем без него. Тогда зачем мне нужно его изучать, если я могу писать быстрый, компактный, безглючный код без всякого STL, который будет понятен любому с первого взгляда, что немаловажно. Как уже было сказано - не нужно писать на STL ради STL, а лично я от него не получу абсолютно никакой пользы.
     
  12. Joes

    Joes New Member

    Публикаций:
    0
    Регистрация:
    5 янв 2008
    Сообщения:
    98
    Нравится вам или нет - без STL в достаточно больших проектах плохо.
    Каждый мега кодер считает что свой велосипед-дерево-контейнер будет работать в н-цать раз быстрее. Потратит, скажем, 4 часа на разработку и отладку и даже если там не окажется багов, будет отлично если он выиграет хотя бы 15% от скорости STL'ного контейнера. А ведь можно заюзать уже готовый контейнер, делов на минуту максимум.
    Или еще пример: сортировку каждый раз руками писать? Особенно когда сортировать надо, например, по полю структурки? std:sort таки очень быстрый и точно будет быстрее баблсорта, который на коленке склепает такой вот сотрудник. Да и code reuse рулит, а то я уже видел проектов, где если надо было сортировать что то, каждый раз вписывали баблсорт, так как лень было писать qsort с его рекурсией и доп. функциями.
    Вобщем, STL это не панацея, а просто хороший и качественный инструмент которым нужно уметь пользоваться. Если умеешь - понимаешь как можно сократить время разработки не потеряв в скорости выполнения приложения.
     
  13. fret

    fret New Member

    Публикаций:
    0
    Регистрация:
    30 янв 2008
    Сообщения:
    24
    15% это серьезная прибавка если речь идет об оптимизации часто использующегося алгоритма. Ради этого позволено потратить гораздо больше 4х часов. Если же ваш мега-кодер оптимизирует то что оптимизировать не нужно, то увольте его и наймите кодера способного прислушиваться к ТЗ.
    Зачем же каждый раз руками? Есть библиотечный вызов qsort работающий без всяких STL с массивами любого типа. Увольте тех кто каждый раз пишет пузырьковую сотрировку в каждом месте где она применяется. Они явно не слышали о повторном использовании кода и о стандартных библиотеках не прибавляющих ни байта к размеру программы, потому что они всегда есть в системе и всегда уже загружены в память. Если время сортировки сверхкритично и размер сортируемых данных составляет десятки гигабайт, то можно потратить время на эксперименты с своей комбинацией qsort и merge sort.
     
  14. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    fret

    В яблочко!
     
  15. fret

    fret New Member

    Публикаций:
    0
    Регистрация:
    30 янв 2008
    Сообщения:
    24
    _DEN_
    С тобой все ясно. Черезвычайно повышеная самооценка в сочитании с ослиным упорством. Переубеждать таких бесполезно - проще убить.
     
  16. nester7

    nester7 New Member

    Публикаций:
    0
    Регистрация:
    5 дек 2003
    Сообщения:
    720
    Адрес:
    Russia
    Осел ослу:
    - Слушаай, да ты - осел!

    Не закрывайте тему, а то если я (да собсно, любой из не-модеров-форума) попрошу, так
    вы непременно забьёте болтик на просьбу сию )
     
  17. Joes

    Joes New Member

    Публикаций:
    0
    Регистрация:
    5 янв 2008
    Сообщения:
    98
    Есть отличная штука, принцип 80-20. 80% всего времени выполняется в 20% кода. Оптимизировать 20% надо, остальные 80% просто надо писать сразу правильно и не заморачиваться с premature optimization. Если нет готового инструмента (сортировки, контейнера, пофиг), будут писать "специализированные" велосипеды. Твоя фраза про специализированный код не вяжется с фразой о повторном использовании кода.

    Не поверите - C'шный qsort медленнее std::sort в 2 раза. Гугл в помощь. Почему - инлайн за счет темплейтов и не обязательно qsort (там адаптивный выбор алгоритма, во всяком случае в STLPort).

    Эээ.. Сишный CRT не добавляет ни байта к размеру программы? Это как?

    А есть разница сколько там данных, если гарантированно готовый алгоритм будет давать весьма приемлимую скорость (быстрее библиотечной qsort)? Вот и получается, или писать что то под конкретный случай (на каждый случай свое - тратить время) или юзать уже готовое. Вот это и есть code reuse.
     
  18. n0name

    n0name New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2004
    Сообщения:
    4.336
    Адрес:
    Russia
    Код (Text):
    1. Размер программы напрямую связан с потреблением памяти.
    если размер бинарника, написанного без STL, на харде меньше аналогичного с STL на 1 Мб (к примеру конечно), то в памяти он будет занимать меньше на этот же Мб или еще большая разница может получится.
    Код (Text):
    1. Не согласен ни сколечко)) Моя - не будет))
    практически всегда можно написать более оптимальную по быстродействию/размеру функцию для конкретной задачи, чем унифицированный аналог.
    например достаточно избежать лишних проверок корректности аргументов в частовызываемых функциях.
    я слышал про 90-10 %)
     
  19. nester7

    nester7 New Member

    Публикаций:
    0
    Регистрация:
    5 дек 2003
    Сообщения:
    720
    Адрес:
    Russia
    Можно я повторюсь? )

    Осел ослу:
    - Слушаай, да ты - осел!
     
  20. fret

    fret New Member

    Публикаций:
    0
    Регистрация:
    30 янв 2008
    Сообщения:
    24
    Все прекрасно вяжется. Я говорил о необходимости оптимизации ключевых участков кода от которых зависит производительность.

    Курите msvcrt.dll или libc.so. Нужный код уже есть в ОС в единственном экземпляре.

    Есть разница. Потому что сортировать данные превыщающие размер памяти ни STL ни CRT не умеют.