Здравствуйте, kr510, Вы писали:
K>На мобильниках наиболее распространены: Objective C, Java и C#.
Для приложений да.
Для игр нет, на плюсах обычно, OpenGL ES (iOS, Android) / Direct3D (WP8).
K>Всё это ещё те тормоза и им до проблем высших порядков типа динамической-статической памяти как до Луны.
С точностью наоборот.
Когда ресурсов много, как например на сервере, в котором 16 ядер 128 GB RAM, как правило работают даже сборщики мусора, не говоря уж про динамическую память.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Во-первых, это бездумная ссылка на авторитетов, которая, как паттерн поведения, устарела еще до Просвещения. Ну, гугл, и что? Нам, современным людям, нужно объяснение, почему это плохо. Объяснения я не увидел.
Да, согласен. Я, признаться, думал, что это ты любишь гугл и для тебя это авторитет. Ты говорил про результат и "делом надо заниматься, а не программированием". Вот гугл денег много заработал, дел выгодных много сделал, карманы набил. Я думал, ну раз ты человек бизнеса, то это тебе ближе. Ну раз это не так, тогда ладно. Стало быть ты тоже инженер и программист. Тогда дам тебе ссылку на подробное объяснение почему пихать все в один класс не рекомендуется. C++ Coding Standards. Chapter 33. Prefer minimal classes to monolithic
BDA>Во-вторых, нет слова «антипаттерн», вас кто-то обманул. Неявная теория за этим словом стоит такая: есть книжка GoF и там перечислены паттерны.
ГОФ вообще тут не причем. Если даже слова такого нет, то понятие такое точно есть. Просто люди называют его по разному. Припарковать машину на железнодорожных путях — это антипатерн.
BDA>Так вот, про цели и объяснения. Что значит «минимализм»? Ничего лишнего в бинарях? Это C++, он статически линкуется, главное, дайте исходники. Я вас уверяю, что если никто не вызовет String::Split, этот код в конечный продукт не попадет. Ничего лишнего в головах? Ну так он там и так есть, поскольку есть в ECMAScript. Или, может быть, в хайлоудных проектах гугла ни одна универсальная реализация не годится, ибо подправленная реализация даже
Ну есть еще SOLID и S это single responsibility. Подробное объяснение есть в гугле. Если с ним конкретно не согласен, можно подискутировать. Я сам согласен с ним и на практике для себя его подтвердил.
BDA>Дело не в том, где такого совсем нет. Дело в том, что платят за результат (который сам на 3/4 очковтирательство, но это неважно). И программист, ориентированный на результат, сталкивается с тем, что во всех приличных языках в системной библиотеке есть нужный ему код, а в этом языке — нет. Что делает язык не очень подходящим для использования программистами, ориентированными на результат. О чем и речь.
Так а кто запрещает использовать несколько библиотек. Зачем все должно быть в системной. Ведь лучше чтобы все занимались тем, что у них лучше получается. Это как десктопный компьютер. Пользователь может сам подобрать компоненты под задачу.
G>>Это компенсируется стабильностью. Опытный программист обучается обходить грабли и использует это умение много лет. Да, порог вхождения выше, зато, когда вошел, выходить не надо еще много лет, в отличии от того же дот нета.
BDA>Перефразаирую: да, дерьмо, но зато они его не исправляли много лет. От себя добавлю: и не собираются.
Я не считаю, что STL настолько плох. Если душа к нему не лежит, нужно искать другую работу. Каждому свое.
BDA>Опять антипаттерн. Ну ладно, а какой кастинг не антипаттерн? Только не говорите, что все — они и без указателей нужны, а уж с указателями-то просто must have.
92. Avoid using reinterpret_cast и 93. Avoid using static_cast on pointers
BDA>Я тут одному товарищу рассказывал уже, но он мне не поверил. Сильно подозреваю, не осилил драйвера или держит какой-нибудь MacAfee. Поставьте себе не откровенно плохой SSD размером на полтерабайта, установите на него систему, файл подкачки, поставьте побольше памяти и у вас все, включая фотошоп, будет запускаться настолько быстро, насколько возможно. В частности, разницы между QtCreator'ом и студией вы не увидите.
А может в клауд запустить вижуал студию? Ну там пять узлов, horizontal scaling. Если серьезно, то на работе купили самые современные, дорогие десктопы с SSD и прочими прибамбасами. За антивирусом я уже давно научился следить. Так вот, тормозит даже на топовом железе. Я не спорю если я себе промышленный сервер под стол поставлю, то я не замечу разницы. А вообще тормознутость и прожерливость студии признают даже ее создатели, но разводят руками.
BDA>Кроме того, есть, знаете ли, разница в функционале между первым и вторым.
Так я этот функционал даже не начал использовать. Просто голую студию запускал. А уж если я начну его пользовать, тогда студия будет очень плавной.
BDA>Много раз слышал это утверждение, но на практике оно, чаще всего, означает стопицотый велосипед, который делает то, что FCL умела с первой версии. Если же речь идет о чем-то узкоспециализированном, то есть, вещах с малым инпутом и большой обработкой внутри, никто не мешает собирать ее в модуль и дергать откуда угодно.
Если производительность и память не важны, тогда и плюсы не нужны. Дот нет или джава и вперед.
BDA>Страуструп, по-моему, это делал в рамках прикладной задачи. Богатыри, не мы, и т.д. и т.п.
Не это главное, а то, что его компания его профинансировала и было согласовано с руководством, потому, что времена были другие. В наше время, его такие как вы "делом надо заниматься" будете гонять ссаными тряпками, пока он результат выдавать не начнет
Здравствуйте, koandrew, Вы писали:
K>Виртуальное наследование — очень полезная фишка, потому что про него очень удобно спрашивать на собеседованиях, когда нужно завалить кандидата. Т.к. этой фичей реально никто не пользуется, то о ней никто путью и не знает
Это почему еще не знает? Я кое-что знаю. Возможно, не все конечно. По крайней мере как-то разбирался, как оно работает. Там есть таблица смещения класса относительно базы. Лежит рядом с таблицей виртуальных функций. И это смещение используется для определения положения в классе. Ну и видимо, по значению стоит условие, чтобы много раз конструктор не вызывать для виртуальной базы.
Здравствуйте, Zenden, Вы писали:
Z>Не то что эти всякие попсовые Сишарпы/жавы для слабаков. Написал код, а он просто работает. Скучно ведь!
В квесте C#/Java я всегда останавливался на этапе «написать код». Как-то он не пишется... Если код компилируется, значит он работает это больше было про Ada. Частично про Delphi.
Здравствуйте, кубик, Вы писали:
К>Я забулькало после главы const_iterator.
.................................................
.................................................
А я — выделил ключевое слово...
От себя добавлю — закусывать пора!
Здравствуйте, greenpci, Вы писали:
BDA>>Во-первых, это бездумная ссылка на авторитетов, которая, как паттерн поведения, устарела еще до Просвещения. Ну, гугл, и что? Нам, современным людям, нужно объяснение, почему это плохо. Объяснения я не увидел.
G>Да, согласен. Я, признаться, думал, что это ты любишь гугл и для тебя это авторитет. Ты говорил про результат и "делом надо заниматься, а не программированием". Вот гугл денег много заработал, дел выгодных много сделал, карманы набил. Я думал, ну раз ты человек бизнеса, то это тебе ближе.
Вы не слышали про культ карго? Это он и есть. Давайте будем слепо поклоняться гугловым гайдлайнам, раз гугл с ними заработал, и мы заработаем. Ну смешно же, честное слово. Если кто-то хочет заработать денег, крайне не рекомендовал бы пытаться сделать это так. Объясню на примере. Допустим, вы видите, что у компании Miscrosoft есть свой R&D-центр. Денег на него тратится — море. Вы думаете: наверное, он очень хорошо окупается. Дай-ка и я открою при своем стартапе из 3 программистов R&D-центр в виде четвертого. Между тем, инсайдеры рассказывали, что ихний центр это идея лично БГ и служит он пенсией для тех, кому лямку тянуть надоело. Он же изначально умных нанимал, да еще натаскивал их потом, а куда они пойдут на свободе? Ну, объедут свет, купят ресторан, а потом? Потом к конкурентам или свой стартап открывать. При ЕГО масштабе и рыночном положении выгоднее было дать им возможность играть в бирюльки и платить, чтобы просто обезвредить. При масштабе «3 программиста, CEO и собака» балласт в виде четвертого может погубить все дело. Вот что бывает, когда гоняешься за авторитетами, а не объяснениями.
>Ну раз это не так, тогда ладно. Стало быть ты тоже инженер и программист. Тогда дам тебе ссылку на подробное объяснение почему пихать все в один класс не рекомендуется. C++ Coding Standards. Chapter 33. Prefer minimal classes to monolithic
Вы определенно издеваетесь. Или по-другому не умеете.
Divide and conquer: Small classes are easier to write, get right, test, and use. They are also more likely to be usable in a variety of situations. Prefer such small classes that embody simple concepts instead of kitchen-sink classes that try to implement many and/or complex concepts (see Items 5 and 6).
Designing fancy large classes is a typical mistake when starting object-oriented design. The prospect of having a class that offers complete and complex functionality in one shot can be quite alluring. However, designing smaller, minimal classes that can be easily combined is an approach that is more successful in practice for systems of any size, for many reasons:
A minimal class embodies one concept at the right level of granularity. A monolithic class is likely to embody several separate concepts, and using one implies dragging the intellectual overhead of all others. (See Items 5 and 11)
A minimal class is easier to comprehend, and more likely to be used and reused.
A minimal class is easier to deploy. A monolithic class must often be deployed as a bulky indivisible unit. For example, a monolithic Matrix class might attempt to implement and deploy exotic functionality such as computing the eigenvalues of a matrixeven when the majority of clients just want simple linear algebra. A better packaging would implement various functional areas as nonmember functions operating on a minimal Matrix type. Then the functional areas can be tested and deployed in separation to the callers who need them. (See Item 44)
Monolithic classes dilute encapsulation. When a class has many member functions that don't need to be members but areand therefore have gratuitous visibility to the class's private implementationthen the class's private data members become nearly as bad as public variables.
Monolithic classes usually result from an attempt to predict and deliver a "complete" solution to a problem; in practice, they virtually never succeed. There's always something more that people wantand something less, for that matter.
Monolithic classes are harder to make correct and error-safe because they often tackle multiple responsibilities. (See Items 5 and 44)
Покажите, как это относится, например, к String::Printf, String::Split, String::ToLower. Это не the right level of granularity? Или это dilutes encapsulation? Или с деплоем проблемы? Короче, завязывайте с джастификационизмом и вскрывайте суть.
BDA>>Во-вторых, нет слова «антипаттерн», вас кто-то обманул. Неявная теория за этим словом стоит такая: есть книжка GoF и там перечислены паттерны. G>ГОФ вообще тут не причем. Если даже слова такого нет, то понятие такое точно есть. Просто люди называют его по разному. Припарковать машину на железнодорожных путях — это антипатерн.
Я говорю, что за этим словом стоит неразумная теория. А значит слово не имеет права на существование. Что не мешает его употреблять даже мне самому, если проблему я вижу задолго до применения этой неразумной теории, например, как в случае с кастингами.
BDA>>Так вот, про цели и объяснения. Что значит «минимализм»? Ничего лишнего в бинарях? Это C++, он статически линкуется, главное, дайте исходники. Я вас уверяю, что если никто не вызовет String::Split, этот код в конечный продукт не попадет. Ничего лишнего в головах? Ну так он там и так есть, поскольку есть в ECMAScript. Или, может быть, в хайлоудных проектах гугла ни одна универсальная реализация не годится, ибо подправленная реализация даже
G>Ну есть еще SOLID и S это single responsibility. Подробное объяснение есть в гугле. Если с ним конкретно не согласен, можно подискутировать. Я сам согласен с ним и на практике для себя его подтвердил.
Ну, вот это уже по существу. Я утверждаю: форматирование строк (String::Printf) или смена регистра (String::ToLower) это по своему характеру ГОРАЗДО БОЛЕЕ строковые операции, чем std::string::swap. Спрашивается, кто нарушает single responsibility — я или Степанов?
BDA>>Дело не в том, где такого совсем нет. Дело в том, что платят за результат (который сам на 3/4 очковтирательство, но это неважно). И программист, ориентированный на результат, сталкивается с тем, что во всех приличных языках в системной библиотеке есть нужный ему код, а в этом языке — нет. Что делает язык не очень подходящим для использования программистами, ориентированными на результат. О чем и речь.
G>Так а кто запрещает использовать несколько библиотек. Зачем все должно быть в системной. Ведь лучше чтобы все занимались тем, что у них лучше получается. Это как десктопный компьютер. Пользователь может сам подобрать компоненты под задачу.
Затем, что хотя каждый язык и метит в свою нишу (один с уклоном в сторону одних прикладных задач, другой — других), есть базовые вещи, которые встречаются при работе с почти всеми прикладными задачами. Покрытие близко к 100%, хотя я и затрудняюсь указать число. Это строки и контейнеры, например. Поэтому большинство языков и поддерживает работу с ними в системной библиотеке (но так куце, как C++, по-моему, один только C++). В результате избегаются следующие проблемы:
1. Программисту не надо писать свой код для каждого нового проекта либо подключать левую библиотеку прямо с первых же шагов, поскольку базовые вещи в базовой библиотеке не сделаны.
2. Программисту не надо думать про взаимные преобразования, возникающие из-за того в п.1 разные программисты выбирает разные библиотеки. Например, про char*, wchar_t*, LPC(T)STR, OLECHAR*, _bstr_t, CString, std::string, std::wstring, QString... и продолжать могу еще долго.
G>>>Это компенсируется стабильностью. Опытный программист обучается обходить грабли и использует это умение много лет. Да, порог вхождения выше, зато, когда вошел, выходить не надо еще много лет, в отличии от того же дот нета.
BDA>>Перефразаирую: да, дерьмо, но зато они его не исправляли много лет. От себя добавлю: и не собираются.
G>Я не считаю, что STL настолько плох. Если душа к нему не лежит, нужно искать другую работу. Каждому свое.
Спасибо, но я пока лучше выберу другие языки и других людей.
BDA>>Опять антипаттерн. Ну ладно, а какой кастинг не антипаттерн? Только не говорите, что все — они и без указателей нужны, а уж с указателями-то просто must have.
G>92. Avoid using reinterpret_cast и 93. Avoid using static_cast on pointers
А, так значит dynamic_cast<T>(o), который вы пропустили — не «антипаттерн» (что бы это слово ни значило)? Тогда зачем ОН режет глаз? Чтоб жизнь медом не казалась?
G>А может в клауд запустить вижуал студию? Ну там пять узлов, horizontal scaling. Если серьезно, то на работе купили самые современные, дорогие десктопы с SSD и прочими прибамбасами. За антивирусом я уже давно научился следить. Так вот, тормозит даже на топовом железе. Я не спорю если я себе промышленный сервер под стол поставлю, то я не замечу разницы. А вообще тормознутость и прожерливость студии признают даже ее создатели, но разводят руками.
Ну так и сколько пустая студия у вас открывается в секундах?
Здравствуйте, Cyberax, Вы писали:
BDA>>Первые два пункта: это до тех пор, пока вы остаетесь в рамках старой парадигмы «Си с классами». Я встречал то ли на кремниевой тайге, то ли на геймдеффе (падонкавском, а не который .ру) душещипательный рассказ о неудовлетворительном падении перфоманса после попыток использовать (правильным образом, конечно) STL. То есть, при попытке использовать удобства, которые есть в других языках, в тех приложениях, которым перфоманс жизненно важен (3D-движках, например) результат будет принципиально неудовлетворительным. C>Ой, ну что за кретинический бред. В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов.
... N>>Под виндой есть замечательный ATL/WTL CString
BDA>Это тот же CString, что и в , насколько я знаю. Про него я написал выше. Но тащить из-за одной строки ATL/WTL... Так и рождается... мнэ... неоднозначное отношение к языку, который в стандартной библиотеке ничего близко похожего не предлагает.
Сейчас это в MFC как в ATL. И чего там тащить? Один инклюд atlstr.h. WTL это тоже всего лишь набор h-файлов, причем гораздо меньший чем собственно stl. Если пишите только под Windows то ATL вполне может быть заменой stl.
Здравствуйте, 0BD11A0D, Вы писали:
C>>Ой, ну что за кретинический бред. В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов. BDA>Я вспомнил: это был ныне выпиленный gamedeff.com. Копия рассказа лежит тут: http://sim0nsays.livejournal.com/38116.html Там есть описание проблемы и конкретные цифры.
Ну и? Причина оказалась:
Что vector::reserve(count) устанавливает capacity ровно в count, если ему вообще нужно ее менять.
Т.е. каждый следующий reserve() делает realloc, если reserve(24) а потом 24x push_back
Однако! Если bevels таки включены, то reserve-то на 24 а push_back-ов больше
Просто удивительно, всё ровно по Стандарту.
Имеем обычный баг в коде, которому не поможет никакая стандартная библиотека.
Советую почитать вот это: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
Там довольно много букв на тему того, почему компании Electronic Arts не подошёл STL, и зачем именно они делали свой аналог.
C>Есть, конечно же. А чем они нынче от обычных PC отличаются?
Например тем, что когда в мобильном приложении или в консольной игре кончается RAM, приложение крешится, а не свопится.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Я вспомнил: это был ныне выпиленный gamedeff.com. Копия рассказа лежит тут: http://sim0nsays.livejournal.com/38116.html Там есть описание проблемы и конкретные цифры.
Оказывается...
Что vector::reserve(count) устанавливает capacity ровно в count, если ему вообще нужно ее менять.
"Оказывается", млять!
Единственное что "оказывается" это то, что аффтар кода понятия не имел что делает reserve.
С таким же успехом можно пользоваться вообще чем угодно и получать стабильно хреновый результат.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Вы не слышали про культ карго? Это он и есть. Давайте будем слепо поклоняться гугловым гайдлайнам, раз гугл с ними заработал, и мы заработаем. Ну смешно же, честное слово. Если кто-то хочет заработать денег, крайне не рекомендовал бы пытаться сделать это так. Объясню на примере. Допустим, вы видите, что у компании Miscrosoft есть свой R&D-центр. Денег на него тратится — море. Вы думаете: наверное, он очень хорошо окупается. Дай-ка и я открою при своем стартапе из 3 программистов R&D-центр в виде четвертого. Между тем, инсайдеры рассказывали, что ихний центр это идея лично БГ и служит он пенсией для тех, кому лямку тянуть надоело. Он же изначально умных нанимал, да еще натаскивал их потом, а куда они пойдут на свободе? Ну, объедут свет, купят ресторан, а потом? Потом к конкурентам или свой стартап открывать. При ЕГО масштабе и рыночном положении выгоднее было дать им возможность играть в бирюльки и платить, чтобы просто обезвредить. При масштабе «3 программиста, CEO и собака» балласт в виде четвертого может погубить все дело. Вот что бывает, когда гоняешься за авторитетами, а не объяснениями.
Майкрософт другое дело. Я больше говорю про то время, когда гугл еще был стартапом. Там не то что, пенсии высиживали, а даже директора в служебной поездке, в другом городе, не брали таксти, а ехали на общественном транспорте. Дело не в карго культе, а в поведении, которое можно рационально объяснить.
А про датацентр, то эта аналогия больше подходит к классам со Split функцией, чем к std::string.
>>Ну раз это не так, тогда ладно. Стало быть ты тоже инженер и программист. Тогда дам тебе ссылку на подробное объяснение почему пихать все в один класс не рекомендуется. C++ Coding Standards. Chapter 33. Prefer minimal classes to monolithic
BDA>Вы определенно издеваетесь. Или по-другому не умеете. BDA>
BDA>Divide and conquer: Small classes are easier to write, get right, test, and use. They are also more likely to be usable in a variety of situations. Prefer such small classes that embody simple concepts instead of kitchen-sink classes that try to implement many and/or complex concepts (see Items 5 and 6)...
BDA>Покажите, как это относится, например, к String::Printf, String::Split, String::ToLower. Это не the right level of granularity? Или это dilutes encapsulation? Или с деплоем проблемы? Короче, завязывайте с джастификационизмом и вскрывайте суть.
Я предпочел бы отделить ToLower и Split от std::string. Они редко нужны и строку легче использовать без них. Я согласен с автором, строку легче использовать, когда в ней нет ToLower и друзей, а они лежат в другом месте отдельно и я про это место знаю. Проблемы еще и в следующем:
std::string ::ToLower() это еще одно выделение памяти и копирование или move (который появился относительно недавно).
std::vector<std::string> ::Split() вообще ужас. Сколько там выделений памяти, копирований? Насколько это все разбросано и не попадет в L2, я думаю, объяснять не надо.
std::string ::printf, по моему мнению, уступает
(ostringstream() << "Hello" << 123).str();
printf нужен только в тех редких случаях, когда есть шаблоны сообщений, и их можно держать отдельно от кода.
Я предпочитаю решать сам где я буду менять строку in place или copy. std::for_each(...ToUpper) или std::transform(...ToUpper). Так же я хочу добавлять символы динамически back_inserter или сделать resize(). Взять начальную строку из std::string или ifstream. И у меня для всего этого есть набор стандартных инструментов.
Для Split, в большинстве случаев, программист захочет читать строку и получать указатели на каждый элемент по очереди. Во первых, для этого не нужно туда сюда копировать. Во вторых, можно остановиться после нахождения нужного значения и не парсить дальше.
Поэтому, Split и ToUpper не достаточно гибкие для быстродействующего кода. С другой стороны, в медленных языках (C#, Java) и в С++ UI frameworks они подходят прекрасно. Поэтому они там и есть.
BDA>Я говорю, что за этим словом стоит неразумная теория. А значит слово не имеет права на существование. Что не мешает его употреблять даже мне самому, если проблему я вижу задолго до применения этой неразумной теории, например, как в случае с кастингами.
Я думаю, отметать книжки и работу других людей не продуктивно. У них есть таланты, желание, им заплатили и они потратили кучу времени на изучение особенностей языка. Если хороший умный человек, почему бы не послушать его и не воспользоваться знаниями? Надо "ехать на плече у гиганта". Да и потом, в книжках не просто написано "делай так как я сказал и все!". На каждую рекомендацию есть куча текста, описывающая почему и для чего все это нужно. Есть еще и другое полезное свойство таких книжек и рекомендаций. Самоучки в команде будут упираться и спорить, что каждый из них прав и создавать конфликты. В то время, как в книжке все написано. Показал им книжку, отправил читать ответ на вопрос "почему" так лучше, и конфликт угаснет. Другое дело, что есть разные авторы и у них может быть противоположное мнение. Я бы, кстати, хотел почитать тех, на которых основано твое мнение, если таковые имеются.
BDA>Ну, вот это уже по существу. Я утверждаю: форматирование строк (String::Printf) или смена регистра (String::ToLower) это по своему характеру ГОРАЗДО БОЛЕЕ строковые операции, чем std::string::swap. Спрашивается, кто нарушает single responsibility — я или Степанов?
Не нужно воспринимать имя string так буквально. Это контейнер для управления памятью: std::memory_management_wrapper_for_text и swap прекрасно вписывается.
BDA>1. Программисту не надо писать свой код для каждого нового проекта либо подключать левую библиотеку прямо с первых же шагов, поскольку базовые вещи в базовой библиотеке не сделаны. BDA>2. Программисту не надо думать про взаимные преобразования, возникающие из-за того в п.1 разные программисты выбирает разные библиотеки. Например, про char*, wchar_t*, LPC(T)STR, OLECHAR*, _bstr_t, CString, std::string, std::wstring, QString... и продолжать могу еще долго.
Так это и есть одна из задач, которую выполняет STL. Он подходит для интерфейсов. А внутри блоков уже можно подбирать то, что лучше. С++ сделан для экономии места и времени. Для задач, требующих тонкой настройки. Каждый инструмент там надо подбирать под задачу. В геймдеве stl вообще не подходит, есть там ToLower или нет. А вообще, есть же QT действительно, там "богатые" строки и все все есть.
G>>>>Это компенсируется стабильностью. Опытный программист обучается обходить грабли и использует это умение много лет. Да, порог вхождения выше, зато, когда вошел, выходить не надо еще много лет, в отличии от того же дот нета.
BDA>А, так значит dynamic_cast<T>(o), который вы пропустили — не «антипаттерн» (что бы это слово ни значило)? Тогда зачем ОН режет глаз? Чтоб жизнь медом не казалась?
он тоже "вызывает нахмуренное лицо" (см. цитату ниже) и достаточно редкий, что бы его в удобные скобки оборачивать.
prefer to design away downcasting: Refactor or redesign your code so that it isn't needed ...
BDA>Ну так и сколько пустая студия у вас открывается в секундах?
Не на работе сейчас. На домашнем компе Intel Core i7 4GB RAM не SSD, VS Express 2013 for Destop — 24 секунды первый раз и 4 секунды второй и последующие. Но это если сразу запускать.
Вообще-то студия не очень хорошее сравнение. Там все еще много C++ и COM осталось, если не ошибаюсь, особенно во время старта.
Здравствуйте, greenpci, Вы писали:
G>Майкрософт другое дело. Я больше говорю про то время, когда гугл еще был стартапом. Там не то что, пенсии высиживали, а даже директора в служебной поездке, в другом городе, не брали таксти, а ехали на общественном транспорте. Дело не в карго культе, а в поведении, которое можно рационально объяснить.
Забавно, вы тоже читали старика Дага. А я его закончил неделю назад или около того. Тяжелое чтение, доложу я вам. Английский у него как у Эми из Футурамы. Но кое-что интересное нашлось.
Что касается рационального объяснения, то давайте с него и начинать.
G>Я предпочел бы отделить ToLower и Split от std::string. Они редко нужны и строку легче использовать без них. Я согласен с автором, строку легче использовать, когда в ней нет ToLower и друзей, а они лежат в другом месте отдельно и я про это место знаю. Проблемы еще и в следующем:
1. Так ведь нет их в языке вообще нигде. Даже в другом месте. Буст не часть языка. Вы не можете создать новый проект в IDE и скомпилировать вызовы из boost::algo. Поэтому его и любят — это багаж малополезных знаний (куда копировать, как собирать под нужную платформу), за которые можно попросить больше денег.
2. Что значит «Строку легче использовать без них»? Я второй раз задаю этот вопрос. Программист увидит ToLower и Split и будет вынужден разбираться, тратить время? Неправда: он видит эти концепции прямо в GUI. А гугловский программист вдобавок должен знать про ECMAScript. Сама строка легче станет? Не вызывайте, она и не утяжелится. Это C++.
3. Каждая из них, может быть, нужна редко, но все вместе они нужны часто. Вот еще один автор, который пишет на джюглише: http://www.joelonsoftware.com/articles/fog0000000020.html Обратите внимение на 'Unfortunately, it's never the same 20%'. С моей точки зрения, это характерная ошибка, которую допустили создатели C++ и вы, а умницы из команды FCL и Джоэл избежали. Себя к последним не добавляю по причине того, что я сначала увидел хорошее решение, а потом задумался, почему оно такое. Не факт, что я бы не наступил на эти же грабли.
G>std::string ::ToLower() это еще одно выделение памяти и копирование или move (который появился относительно недавно).
Это зависит от (им)мутабельности. Если строка мутабельная, зачем? Может, вызывающей стороне оригинал не нужен. Если нужен, пусть снимет копию сам.
G>std::vector<std::string> ::Split() вообще ужас. Сколько там выделений памяти, копирований? Насколько это все разбросано и не попадет в L2, я думаю, объяснять не надо.
Так к этому и надо относиться: дорогая, но удобная операция. Вы что, предлагаете вообще заставить программиста ее сочинять?
G>std::string ::printf, по моему мнению, уступает G>
G>(ostringstream() << "Hello" << 123).str();
G>
G>printf нужен только в тех редких случаях, когда есть шаблоны сообщений, и их можно держать отдельно от кода. G>[/list]
Неправда и это. Вы, скорее всего, никогда не делали то, что делал я: брали процессы и читали их string table в Process Explorer. Поделайте, и поищите там %d. Я иду прямо по списку: Classic Shell, Windows Explorer, MyHomeLib, Steam, Media Player Classic, дрова от звуковой карты — все они полны форматированием строк. Исключение в моем списке — Фотошоп и Фурифокс.
Значит, их авторы не думают, что он нужен редко. Как минимум, несколько раз в проекте употребляют. Употребляют в виде какого-нибудь snwprintf, при всей неудобности такого вызова. Или пишут свои классы.
G>Я предпочитаю решать сам где я буду менять строку in place или copy.
Нормальный человек такое решение принимает в следующем виде:
String original = L"Blah-blah-blah";
String copy = original;
copy.ToLower();
String original = L"Blah-blah-blah";
original.ToLower();
И это только в том случае, когда иммутабельность не заенфорсена в языке. И лично я склоняюсь к тому, что строки должны быть иммутабельны по следующим причинам: http://stackoverflow.com/questions/2365272/why-net-string-is-immutable
G>Для Split, в большинстве случаев, программист захочет читать строку и получать указатели на каждый элемент по очереди. Во первых, для этого не нужно туда сюда копировать. Во вторых, можно остановиться после нахождения нужного значения и не парсить дальше.
Здравстуйте, а терминаторный ноль кто будет вписывать для каждого элемента? Зачем ему набор указателей с общим терминатором на всех? Короче, это никакое не большинство случаев, а самое редкое исключение.
BDA>>Я говорю, что за этим словом стоит неразумная теория. А значит слово не имеет права на существование. Что не мешает его употреблять даже мне самому, если проблему я вижу задолго до применения этой неразумной теории, например, как в случае с кастингами.
G>Я думаю, отметать книжки и работу других людей не продуктивно. У них есть таланты, желание, им заплатили и они потратили кучу времени на изучение особенностей языка.
Ну, я уже понял, что вы джастификационист. Еще когда вы первый раз на гугл сослались. Дело ваше, но я не могу общаться с джастификационистами: ИМЕННО ЭТО непродуктивно. От них не получишь новых, напоминаю вам ваши же слова: «рациональных объяснений», а только ссылки на авторитеты.
Раз уж вы читаете примерно те же книжки, что и я, вот что я прежде каких бы то ни было приплюсов посоветовал: https://books.google.com/books/about/The_Beginning_of_Infinity.html?id=jZHanN5_KPgC&hl=en
>Если хороший умный человек, почему бы не послушать его и не воспользоваться знаниями? Надо "ехать на плече у гиганта". Да и потом, в книжках не просто написано "делай так как я сказал и все!". На каждую рекомендацию есть куча текста, описывающая почему и для чего все это нужно. Есть еще и другое полезное свойство таких книжек и рекомендаций. Самоучки в команде будут упираться и спорить, что каждый из них прав и создавать конфликты. В то время, как в книжке все написано. Показал им книжку, отправил читать ответ на вопрос "почему" так лучше, и конфликт угаснет. Другое дело, что есть разные авторы и у них может быть противоположное мнение. Я бы, кстати, хотел почитать тех, на которых основано твое мнение, если таковые имеются.
Если вы обратили внимание, выше я сделал именно это: дал ссылку на объяснение, почему строки должны быть иммутабельны. Своими словами переписывать не стал. Но это ссылка на ХОРОШЕЕ ОБЪЯСНЕНИЕ. Именно поэтому я и сослался. Более того, каждый пункт могу объяснить так, как если бы я сам его написал. А вот вы сослались на yada-yada, набор слов с большой вариативностью. Он не является хорошим объяснением. Сошлитесь на хорошее объяснение, и вопросов не будет. Дело же не в ссылках.
Что касается команд, создайте свою, где можно сослаться на гугл и заткнуть рты. А результаты мы потом сравним.
BDA>>Ну, вот это уже по существу. Я утверждаю: форматирование строк (String::Printf) или смена регистра (String::ToLower) это по своему характеру ГОРАЗДО БОЛЕЕ строковые операции, чем std::string::swap. Спрашивается, кто нарушает single responsibility — я или Степанов?
G>Не нужно воспринимать имя string так буквально. Это контейнер для управления памятью: std::memory_management_wrapper_for_text и swap прекрасно вписывается.
Да неужели? Смотрите сами. В std::string есть std::string::substr(), который является частью строки как строки. Не как контейнера (в обобщенных контейнерах такого нет). Даже in-place вам сделать не дадут, что примечательно. Так вот, это будет responsibility номер раз. А swap и прочая контейнерщина — это responsibility номер два. Значит принцип SR нарушен.
BDA>>1. Программисту не надо писать свой код для каждого нового проекта либо подключать левую библиотеку прямо с первых же шагов, поскольку базовые вещи в базовой библиотеке не сделаны. BDA>>2. Программисту не надо думать про взаимные преобразования, возникающие из-за того в п.1 разные программисты выбирает разные библиотеки. Например, про char*, wchar_t*, LPC(T)STR, OLECHAR*, _bstr_t, CString, std::string, std::wstring, QString... и продолжать могу еще долго.
G>Так это и есть одна из задач, которую выполняет STL. Он подходит для интерфейсов. А внутри блоков уже можно подбирать то, что лучше. С++ сделан для экономии места и времени. Для задач, требующих тонкой настройки. Каждый инструмент там надо подбирать под задачу. В геймдеве stl вообще не подходит, есть там ToLower или нет. А вообще, есть же QT действительно, там "богатые" строки и все все есть.
Напоминаю вам, что если бы в стандарт (который сам по себе мне мало интересен, но интересен из-за компиляторов и IDE) входили библиотеки с достаточно полным базовым функционалом, это был бы другой язык. Намного лучше, хотя вопросы по многословному синтаксису и нарушению инкапсуляции (и много других) остались бы.
BDA>>А, так значит dynamic_cast<T>(o), который вы пропустили — не «антипаттерн» (что бы это слово ни значило)? Тогда зачем ОН режет глаз? Чтоб жизнь медом не казалась?
G>он тоже "вызывает нахмуренное лицо" (см. цитату ниже) и достаточно редкий, что бы его в удобные скобки оборачивать.
Так он «антипаттерн» или нет? Если да, какой кастинг не? Если нет, зачем он такой уродливый? Мало ли что редкий.
Кстати, «антипаттерность» тоже не оправдание, чтобы делать вещи уродливыми. Не хочешь давать использовать — убери из языка или генерируй deprecation warning, хотя бы. Требуй unsafe, в конце концов. Но уж если оставляешь — не уродуй. Ну, представьте себе, есть магазин с задним входом. Нам не нравится, что покупатели через него проникают внутрь — это небезопасно, так как они проходят через склад и могут стырить товар. Мы не будем закрывать заднюю дверь, мы не будет ставить охранника, чтобы он следил за товаром, мы не будем не делать ничего (потери на товаре меньше, чем на уменьшении траффика), а будем каждого покупателя, зашедшего не оттуда, обливать молоком и поджигать, чтобы переучить. Вот это и есть ваш dynamic_cast<T>, а заодно и static. И что я думаю о таких языках, я уже сказал. После появления шаблонов он только деградирует.
G>Не на работе сейчас. На домашнем компе Intel Core i7 4GB RAM не SSD, VS Express 2013 for Destop — 24 секунды первый раз и 4 секунды второй и последующие. Но это если сразу запускать.
Жесть какая. Снять, что ли, как за 3 секунды запускается все и на ютуп выложить?
Здравствуйте, Cyberax, Вы писали:
C>>>Ой, ну что за кретинический бред. В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов. BDA>>Я вспомнил: это был ныне выпиленный gamedeff.com. Копия рассказа лежит тут: http://sim0nsays.livejournal.com/38116.html Там есть описание проблемы и конкретные цифры. C>Ну и? Причина оказалась: C>
C>Что vector::reserve(count) устанавливает capacity ровно в count, если ему вообще нужно ее менять.
C>Т.е. каждый следующий reserve() делает realloc, если reserve(24) а потом 24x push_back
C>Однако! Если bevels таки включены, то reserve-то на 24 а push_back-ов больше
C>Просто удивительно, всё ровно по Стандарту.
Назвать это «тупой и понятный контейнер», по-моему, нельзя.
Здравствуйте, 0BD11A0D, Вы писали:
G>>Я предпочел бы отделить ToLower и Split от std::string. Они редко нужны и строку легче использовать без них. Я согласен с автором, строку легче использовать, когда в ней нет ToLower и друзей, а они лежат в другом месте отдельно и я про это место знаю. Проблемы еще и в следующем:
BDA>2. Что значит «Строку легче использовать без них»? Я второй раз задаю этот вопрос. Программист увидит ToLower и Split и будет вынужден разбираться, тратить время? Неправда: он видит эти концепции прямо в GUI.
Вопрос тебе на засыпку. А какая реализация должна быть у этих функций?
Мы не знаем, что хранится в std::string — ansii или utf-8 или 100500 других кодировок. Запихивая эти функции внутрь класса ты ограничиваешь его использование.
Этим функциям самое место где-то в хелперах.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Вопрос тебе на засыпку. А какая реализация должна быть у этих функций? SVZ>Мы не знаем, что хранится в std::string — ansii или utf-8 или 100500 других кодировок. Запихивая эти функции внутрь класса ты ограничиваешь его использование. SVZ>Этим функциям самое место где-то в хелперах.
Вы процитировали самый конец переписки. В начале я неявно жаловался, что до сих пор кодировки явным образом в строках отсутствуют. Это снимает ваш вопрос?
Здравствуйте, 0BD11A0D, Вы писали:
SVZ>>Вопрос тебе на засыпку. А какая реализация должна быть у этих функций? SVZ>>Мы не знаем, что хранится в std::string — ansii или utf-8 или 100500 других кодировок. Запихивая эти функции внутрь класса ты ограничиваешь его использование. SVZ>>Этим функциям самое место где-то в хелперах.
BDA>Вы процитировали самый конец переписки. В начале я неявно жаловался, что до сих пор кодировки явным образом в строках отсутствуют. Это снимает ваш вопрос?
Я читал. Ну будем считать, то снимает.
На мой взгляд принятое решение очень разумно — жестко завязываться на конкретную кодировку (ATL/WTL, Qt) так же плохо, как и тащить внутрь класса строки всю ICU.
Универсального решения здесь нет.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, 0BD11A0D, Вы писали:
C>>Просто удивительно, всё ровно по Стандарту. BDA>Назвать это «тупой и понятный контейнер», по-моему, нельзя.
А что тут непонятного-то? Вектор — это непрерывный блок в памяти, который имеет размер равный capacity, а size указывает на реально используемый участок. Capacity автоматически экспоненциально увеличивается при исчерпании. Метод reserve() позволяет ей управлять вручную.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Я читал. Ну будем считать, то снимает. SVZ>На мой взгляд принятое решение очень разумно — жестко завязываться на конкретную кодировку (ATL/WTL, Qt) так же плохо, как и тащить внутрь класса строки всю ICU. SVZ>Универсального решения здесь нет.
То же самое говорили про int16/int32/int64
А вообще, если хочется большего контроля, никто не запрещает кодировку задавать как для экземпляра (в конструкторе), так и по умолчанию для всего проекта (через проектный #define).
Здравствуйте, 0BD11A0D, Вы писали:
SVZ>>Универсального решения здесь нет. BDA>То же самое говорили про int16/int32/int64
Поэтому сейчас все используют int128 для всего, да?
BDA>А вообще, если хочется большего контроля, никто не запрещает кодировку задавать как для экземпляра (в конструкторе), так и по умолчанию для всего проекта (через проектный #define).
#define идёт в топку вместе с тем, кто предлагает такое решение. Задание кодировки в самой строке будет требовать дополнительные 4/8 байт на указатель и будет мешать Small String Optimization.
Естественно, при этом не давая никаких преимуществ кроме того, что говноразработчики смогут втыкать ToLower, не удосужившись даже заглянуть в документацию.
А потом будут чесать репу почему std::govnostring("ISTANBUL".ToLower()) != std::govnostring("istanbul").
