Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » Дзен » STL


STL

Сообщений 1 страница 14 из 14

1

Алексей, Вы написали

В очередной раз хочется помянуть недобрым словом STL - каким идиотом нужно быть, чтобы не дать в строках аналог strlwr/strupr, вещь постоянно нужная и считать для этого нужно использовать "std::transform(theString.begin(), theString.end(), theString.begin(), tolower);" - это бред (IMHO весь STL/boost - это омерзительный бред).

А как Вы относитесь к EASTL? Я просто начал использовать его в своих проектах и пока не знаю всех подводных камней. Имели дело с этим зверем? Буду признателен за любые замечания)

0

2

m110h написал(а):

Я просто начал использовать его в своих проектах и пока не знаю всех подводных камней

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

0

3

Ого! Спасибо за мысли! ) Я с вами во многом согласен и не поддерживаю людей, которые обливают чем не попадя плюсы, а тем временем это наиболее часто используемый в реальных проектах язык. Я имел ввиду не выискивание в EASTL всякого неудобного и субъективного, а обмен опытом и наблюдениями. Как-то так.

0

4

1. Скорее всего - гарантий нет и не будет. Все что я видел - это красивые утверждения, что этот гвонокод МОЖНО эффективно скомпилировать.
2. Ну на насчет контейнеров я полностью соглсен - для прототипирования и небольших проектов. Все. Для больших и среьезных проектов это гавно не годится.
Про то, что надо понимать струтктуры данных и подбирать их правильно никто не спорит, я просто я не люблю то море говнокода, которое называется STL

Для серьезных проектов STL  не годится (IMHO). Да и сам С++, который действительно используется в большом числе проектов, врядли используется на 100% - скорее всего используется очень урезанный вариант языка, не используя основное количество "фич"

Я не ненавистник С++ - мне обидно и жалко, что язык, на котором я программирую где-то с 1990 года из простого и красивого языка (с небольшим количеством недоделанных фич, вроде указателей на методы и оператора ->*) превратился в огромного монстра и при жтом позиционируцется как мега-язык.
Был уже такой мега-язык - PL/1, благополучно издох именно из-за своей сложности
Для программирования графики С++ - вполне подходящий язык (но мне не понятно, почему inline может игнорироваться компилятором и, соответсвенно, у всех компиляторов есть свой __forceinline).
Но вот GUI на нем делать - это мазохизм, тут что obj-c, что C# порвут С++ легко и просто.

0

5

Серебрянной пули нет. Если бы была, то все давно уже перешли бы. Приходится лавировать в зависимости от задач. Это про

Но вот GUI на нем делать - это мазохизм, тут что obj-c, что C# порвут С++ легко и просто.

Похоже на утверждение про алгоритмы и контейнеры. Каждый под свои задачи.

0

6

Какую то хрень я тут пишу всем понятную ...

0

7

Steps3D
Ежики плакали кололись, но продолжали жрать кактус? Зачем пользоваться тем что не нравится (тем чем не умеете, может быть), почему нельзя писать на С++ версии 1990 года не используя всех эти новомодных бустов?
Меня всегда поражало почему 90% населения мира спокойно используют винду и не лазают в нелюбимый ими эпл, а те жалкие несколько процентов эпловчан с завидным мазохизмом находят все больше и больше "неудобностей" в винде и кричат об этом на каждом углу. И вы не исключение: Билли с Майкрософтом у вас корпорация зла, но вы зачем-то себя мучаете и пользуетесь\следите за ней, а Стивви в iКоне, несправедливо обидели и вообще автор некомпитентен и дурак. C#, Obj-C, C и т.п. - изумительные языки, но надо взять C++ и показать всему миру, какой же он неудобный и мол все кто его используют ничего не понимают и им надо раскрыть глаза.
Я бы и слова не сказал, будь такое написано в обычном блоге, но вы же книги пишите, преподаете, к вам люди прислушиваются...

0

8

Так я бустом и не пользуюсь. STL использую минимально - для небольших примеров сойдет, хотя криво (IMHO)
В С++ почти не использую новые фичи и не считая небольшого количетсва STL и небольшого количества темплейтов и получается С++ версии 1990 года
И я действительно считаю что С++ убог и крив и если это поможет кому-то посмотреть на С++ с другой точки зрения и посмотреть на другие языки - IMHO это только пойдет на пользу.
Я не призываю к полному отказу от С++ - для ряда задач он очень удобен. Но и понимать что очень далек от идеала и откровенно убог во многих аспектах - надо.
И то направление в котором идет его развитие  - это бред - язык становится все сложнее и сложнее. Причем развитие идет исключительно в одном направлении - о нормальной поддержке метаинформации вообще речи не идет.
В результате большие библиотеки вводят свои объектные модели, свою работу с метаниформацией и т.п. и как-то не спешат использовать новые фичи

0

9

Простой пример - в С я могу легко подгрузить dll/so и по имени загрузить функцию.
Как с этим в С++? Нестандартизированный name mangling все уродует
А про создание класса по имени из dll/so - вообще никак. Нужно руками делать специальную функцию.
И никакого улучшение в этом нет и не будет. Куча людей уже давно ушла на более гибкие и просые языки - в основном остались те, кому нужно быстродействие

0

10

Какая-то однобокая аргументация, в С++ есть такая фишка как extern "C"... и поехали, насчет классов, да соглашусь, но их нет и в С, я бы не считал отсутствие фичи в языке плюсом этого языка. Вернемся к вашей задаче про отсутсвие strlwr/strupr в STL'е: ваш запрос удовлетворяется написанием функции обертки в одну строку - это займет пару минут. В С вообще не возможно реализовать класс строк, приходится пользоваться не нативными и небезопасными strcmp, strcpy и т.п. с мета информацией тут дела обстоят не лучше чем в С++, развития языка, не то что бы хорошо, а хоть какого-то серьезного - вообще нет. Я имею право на основании всего вышесказанного сделать вывод что С "очень далек от идеала и откровенно убог во многих аспектах" ?
Насчет кучи людей, С++ все еще прочно занимает свое место в 10-ке самых популярных языков в мире и боюсь переживет еще очень многие языки.

0

11

Насчет классов - проблема в том, что новая сущеность введна, а адекватного механизма работы с ней при раздельно линкуемом коде нет
В этом плане С целостнее, хотя конечно на С++ писать лучше, чем на С, поэтому он почти не развивается - смысла нет
Насчет метаинформации - я бы не сказал, что в ней есть огромная потребность, кроме того несложный скрипт ее всю ведерет из кода
А вот с С++ совсем иначе - потребность есть и серьезная, доказано, что в общем случае выдирание метаинформации эквивалетно компиляции, т.е. чтобы выдрать метаинфорацию нужен не маленький скрипт, а большой кусок компилятора (посмортрите как boost::python тихо пришел к использованию gccxml, только почему-то по результатам gccxml они генерят не нормальные байндинги, а свой)

+1

12

Не дописал -
генерят вместо нормального байндинга свой говнокод.
Ну а кто кого переживет - COBOL и FORTRAN тут в явных лидерах
А место С++ - для вычислительно-емких задач, задач, требующих строгого контроля над ресурсами альтернатив в общем нет - либо С, либо С++
Java/C# тут явно не годятся
Так что место в десятке - просто наличие задач, требующих С-подобного языка, а поскольку С++ даже уровня 1990 года удобнее, чем С, то вот он занимает место
Впрочем язык С как-то не слишком сильно упал

0

13

Т.е. по сути все претензии к языку сводятся к тому, что нужно добавить поддержку мета информации (хотя ИМХО не так уж много существует задач, где без нее не обойтись) + немного синтаксического сахара в STL/Boost ?

0

14

Steps3D написал(а):

а адекватного механизма работы с ней при раздельно линкуемом коде нет

Механизм-то есть. Стандарта нет. И боюсь, что даже если бы он был, то все бы на него положили... Как кладут сейчас на стандарт самого языка. Хватило бы, если честно, просто бинарной совместимости. Патерн factory еще никто не отменял. Но даже ее нет...

Steps3D написал(а):

FORTRAN тут в явных лидерах

Да, Intel хорошо двигает фортран в области научных вычислений. Их компилятор выдает фантастического качества бинарники.

Steps3D написал(а):

Впрочем язык С как-то не слишком сильно упал

Как на первом месте был, так там и останется. Если ряд задач, которые в силу различных причин и ограничений не реализуемы на языке уровнем выше, чем С.

ReanGD написал(а):

что нужно добавить поддержку мета информации

Добавить - не совсем корректное слово. Она кагбе есть. Но пользоваться ей нужно аккуратно. Да и фиговая она, мягко говоря. И реализации медленные. Свои обычно в 10-ки (и даже 100-ни) раз быстрее.

0


Вы здесь » Компьютерная графика » Дзен » STL


создать свой форум бесплатно