Здравствуйте, greenpci, Вы писали:
G>Я думаю когда их задумывали, то уродливость не ставилась как цель. Это случайный бонус. И, все таки, а как это сделать красивее?
Виды кастов вполне согласованны с видом шаблонов функций. И даже можно написать свои касты с точно таким же синтаксисом (бывает необходимо для чего-то типа COM-like).
М>Subj: Кому ваще этот С++ нужен?
Как кому ? Микрософтам!
У них же компилятор до сих пор нормальный Си не поддерживает.
Вот и извращаются, пишут workaround-ы на С++.
А вот кому они свои продукты жизнедеятельности впаривают — загадка.
Здравствуйте, 0BD11A0D, Вы писали:
SVZ>>Я бы предпочел разные классы для разных строк, но это вредно для здоровья кросс-платформенных приложений.
BDA>В чем вред?
Нужно ли объяснять, что методы работы с символами фиксированнной и переменной ширины различаются?
Методы разные, интерфейсы разные.
Делать универсальный интерфейс неэффективно.
Поэтому для кроссплатформенного проекта одним дефайном не обойтись.
Под каждую платформу придется писать целый набор методов для работы со строками достаточно высокого уровня.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, мыщъх, Вы писали:
М>а винда... ну она как бы есть. в магазине. но хз кто под нее что разрабатывает и почему.
Многие разрабатывают и успешно под Винду. Все security: антивирь, оптимизаторы, FW и пр. Корпоративный софт тоже под ней сидит. ИГРЫ!
В принципе, Винды никуда не делись. Просто Эппловская горячка всё затмила. Посмотрим если это надолго.
K>>В принципе, Винды никуда не делись. Просто Эппловская горячка всё затмила. Посмотрим если это надолго.
M>Можно дать определение «надолго»? Так, для справки, iPod'у (первая волна «горячки») — 14 лет. iPhone'у (главная волна «горячки») — 8 лет.
Рано или подно каюк придёт. Ведь это очевидно тупик эволюции: всё что движет их экосистему — лояльность пользователей, которые сделали им имидж (некоторые говорят секту). Ничего технологически уникального яблочники не делают, тогда откуда сверх доходы? В недавном мире подобных было много: Япония и недвижимость, 00 и дотком, нефть. И это всё было очищено рынком.
Здравствуйте, kr510, Вы писали:
K>Ничего технологически уникального яблочники не делают
Рынок не про технологии, он про продукты.
Навскидку, уникальные продукты:
1. Интернет-магазин цифровой музыки
2. Безлимитный мобильный интернет в кармане + web browser к нему
3. Магазин мобильных приложений
4. Планшет для безделья
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, kr510, Вы писали:
K>>Ничего технологически уникального яблочники не делают К>Рынок не про технологии, он про продукты. К>Навскидку, уникальные продукты: К>1. Интернет-магазин цифровой музыки К>2. Безлимитный мобильный интернет в кармане + web browser к нему К>3. Магазин мобильных приложений К>4. Планшет для безделья
И что тут уникального? Обычная "картошка" — большинство этого было еще в Ovi, ну а уж современных поставщиков (Play, Win appstore) всё это "цветёт и пахнет".
Здравствуйте, kr510, Вы писали:
К>>Рынок не про технологии, он про продукты. К>>Навскидку, уникальные продукты: К>>1. Интернет-магазин цифровой музыки К>>2. Безлимитный мобильный интернет в кармане + web browser к нему К>>3. Магазин мобильных приложений К>>4. Планшет для безделья
K>большинство этого было еще в Ovi
Этот твой Ovi был сильно позже.
iTunes store с музыкой для iPod — 2003.
Ойфон, в комплекте с первым на рынке безлимитным мобильным интернетом — 2007.
iTunes store с iOS приложениями — 2008 (обрати внимание, что в момент запуска iPhone ещё даже не был смартфоном, был просто телефон с музычкой, безлимитным EDGE интернетом и web-браузером).
И только в 2009 был запущен Ovi Store. На котором кстати даже музыки по-моему не было, рингтоны только.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Нужно ли объяснять, что методы работы с символами фиксированнной и переменной ширины различаются? SVZ>Методы разные, интерфейсы разные. SVZ>Делать универсальный интерфейс неэффективно.
SVZ>Поэтому для кроссплатформенного проекта одним дефайном не обойтись. SVZ>Под каждую платформу придется писать целый набор методов для работы со строками достаточно высокого уровня.
А мне нравится идея шаблона, параметризованного кодировкой. Даже без частных специализаций можно обойтись, перенеся специфичный функционал в класс кодировки.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Cyberax, Вы писали:
C>Ой, ну что за кретинический бред. В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов.
К сожалению (почти) нечему тормозить только у vector, с остальными контейнерами не всё так гладко.
Если найдется время, советую просмотреть пару выступлений с cppcon'14. на мой взгляд — поучительные истории о том, что бывает, когда не учитывают реальное железо в процессе разработки софта и спецификаций библиотек.
Здравствуйте, Igor Karablin, Вы писали:
IK>К сожалению (почти) нечему тормозить только у vector, с остальными контейнерами не всё так гладко. IK>Если найдется время, советую просмотреть пару выступлений с cppcon'14. на мой взгляд — поучительные истории о том, что бывает, когда не учитывают реальное железо в процессе разработки софта и спецификаций библиотек.
Степанов реальное железо всегда учитывал. Даже больше, эффективность (во всех её проявлениях) это главный лейтмотив всех его статей, книг и выступлений.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>На этот предмет есть технологии типа precompiled headers. И вообще, забавно слышать это по адресу C++, языка, ОЧЕНЬ ПЛОХО ПОДХОДЯЩЕГО для быстрой компиляции. Им есть чего подкрутитть задолго до того, как строки уродовать, причем эффекта будет намного больше.
Если я правильно понимаю, на некоторых платформах и при некоторых условиях эта фича не доступна.
BDA>А теперь послушайте другую интерпретацию вашего наблюдения. Чуть ли не единственное, но убойное преимущество ООП — возможность так организовать код, что он становится самодокументируемым. Как раз интеллисенс играет тут первую скрипку. Вы открываете его окошко и видите ВСЕ возможности некоторого класса. Альтернатива — курить маны. То есть, вышел новый стандарт, новый STL, новый boost и вы должны сразу прочитать, понять и запомнить все, что написано в сопроводиловке. Нормальные люди предпочитают осмотреть классы с высоты птичьего полета, чтобы знать, что вообще есть, а потом уже углубленно знакомиться с нюансами вызова методов (типа, почему пишется Манчестер, читается Истанбул).
Мне кажется, это негативная сторона, так же, как и Google Driven Development. Находя метод в интеллисенсе, программисты переоценивают свое понимание того, что и как он делает. Страшно подумать, сколько раз программисты очищали память с помощью std::ostringstream::clear(). Множество моих знакомых говорили, что они уже не читают книги по программированию, так как в интеллисенсе и гугле все есть. Мне кажется, даже хороший дотнет программист должен знать не только инструкцию к методу фреймворка, но и, иногда, смотреть на его код. Си плюс плюс, как язык "тонкой настройки", тем более требует знания деталей глубже, чем интеллисенс. И я лично за то, чтобы специалисты читали книжки, прежде чем, что-либо делать. Хотя, это и не популярная точка зрения. А новые платформы, как дотнет, настолько быстро меняются, что людям не когда что-то изучать, и это еще одна причина, по которой интеллисенс там так нужен. Создали проблему, решили проблему.
Это я еще не упомянул научную книгу "Антимозг", исходя из которой, можно сделать вывод, что интеллисенс также "разрушает" гиппокамус и ухудшает память.
Но это только моя точка зрения. Большинство все равно его используют и пара лишних, для кого-то ненужных методов будет слегка вредна.
BDA>Как раз вынесение алгоритмов за пределы классов принципиально и не дает воспользоваться этим преимуществом ООП. Процедурщина и хендловщина в полный рост.
class SomethingDoer
{
static void DoSomething();
}
Вот и дотнет программисты ломают голову, когда им нужен глагол, они почему-то должны придумывать существительное.
BDA>Не приведя примера такой ошибки, вы затрудняете обсуждение этого пункта. Например, шаблоны у вас, скорее всего, не к месту, но как я это покажу, не видя кода?
Да бог с ним. Вы когда-нибудь смотрели или отлаживали код СТЛ темплейтов? Я да и много раз. Это касается не только строки.
BDA>Однако по сути вы все равно не правы, и это видно даже без примеров. Мне лень объяснять детали и я сделаю проще: прибегну к специальной терминологии. Ошибка, которую вы допускаете, называется редукционизм. Что это значит и как понимать, вы узнаете из этой книги: https://books.google.ru/books/about/The_Fabric_of_Reality.html?id=2LqEPNf9jXsC&hl=en В качестве бонуса каждому прочитавшему я готов дать один файлик всего лишь на 255 байт, который, по вашей теории, должно быть легко читать и понимать. Редкая птица долетала до его середины.
За ссылки, конечно, спасибо и я постараюсь почитать, но для этого разговора, хотелось бы книжек или блогов по программированию и именно по теме поддерживающих твою точку зрения. Неужели никто ничего такого не написал? Ну, может, Мартин Фаулер, корпоративный любимчик, строитель больших ООП иерархий?
BDA>И это тоже ошибка редукционизма. Концепт string::ToUpper() занимает в голове меньше места, чем применение std::transform в каждом конкретном случае.
Я говорил о внутренностях и особенностях реализации этих методов, а не о знании их наличия.
BDA>Привели, и что? Смеяться я не буду, это просто ничем не обоснование утверждение, над чем же тут смеяться?
Для меня то, что эти люди написали (а ведь каждое правило в этой книжке содержит ссылки на более толстые книжки) и есть обоснование. Хотя я понимаю, что ты не согласен с этим.
BDA>Короче, две книжки, которые я вам посоветовал, могут полностью перевернуть ваше миропонимание. На каждом шагу вылезает то, что объяснить проблемы сиплюсплюса и его архитектуры лучше всего в терминах типа редукционизма, но сначала же теория нужна. Образование. А своими словами пересказывать эти фундаментальные труды я не могу.
Может быть почитаю. Только не факт, что я сделаю такие же выводы. Такое тоже бывают.
G>>Все делается алгоритмами. На stackoverflow есть способы сделать все это без буста и с высоким контролем над решением. Сплит делается с помощью std::find и цикла.
BDA>Все делается на ассемблере. Идите уже до конца. Остальное в глазах редукциониста должно быть просто ненужное повышение уровня.
Зачем же в крайности бросаться.
BDA>Тем не менее, отдадим ему должное, он, в процитированной колонке, дает ХОРОШЕЕ ОБЪЯСНЕНИЕ, почему bloatware (не всякое, а такое, как System.String или MS Office 2000) — миф. И это хорошее объяснение хорошо изложено. Вы это объяснение проигнорировали, а прицепились к тому, кто его дал. И если это, по-вашему, продуктивное поведение, то от продукта вашего поведения не очень хорошо пахнет.
Это зависит от пользователя и от ситуации. Кому-то notepad++, vim, а кому то раздутый ворд нужен в разные промежутки времени. Так что он и прав и не прав одновременно. Так же и со строкой. Кому-то Кьют строка нужна, а потом СТЛ строка. Но зачем же делать так, чтобы Кьютная строка была везде. Об этом ведь речь.
G>>Так о том и речь. Если хочется удобств, то надо на джаву или дот нет сразу идти
BDA>Сегодня жемчужины в этом форуме собираю горстями. Вот так вот, хочется удобств — вали отсюда. Прямо в FAQ просится, кроме шуток. Чтоб знать, с чем связываешься.
Почему же "вали"?! Я и сам на дотнете работал дохрена времени и еще буду работать. Это же как айфон и зеркалочка с киллограммовой линзой. Вот ты жалуешься, "тяжелая", надо апертуру настраивать. А я и говорю, ну не хочется, возьми айфон. Он и цвет подберет нужный и подрисует что-то. А потом когда тебе захочется что-то особенного, реальности или тонкой настройки, возьмешь зеркалку и потерпишь ее размеры и тяжесть.
BDA>>>Здравстуйте, а терминаторный ноль кто будет вписывать для каждого элемента? Зачем ему набор указателей с общим терминатором на всех? Короче, это никакое не большинство случаев, а самое редкое исключение.
BDA>То есть, это не копирование, так получается?
Ну так это, как просил, если терминаторный ноль нужен. Мне бы он не нужен был, скорее всего. С двумя итераторами тоже можно много чего сделать. std::equal, например.
BDA>dynamic_cast — никак. Сама его идея — оператор, который будет работать только при заданных опциях сборки проекта — уродлива. В других языках, где RTTI неотключаем, это делается изящным оператором as. Для всего остального есть (T).
Я не думаю, что as изящен. Ведь сразу после него надо проверять на null. Множество дотнетчиков повторяют эту ошибку изо дня в день.
string s = o as string;
if(s == null)
{
throw ...
}
Здравствуйте, 0BD11A0D, Вы писали:
BDA>А теперь послушайте другую интерпретацию вашего наблюдения. Чуть ли не единственное, но убойное преимущество ООП — возможность так организовать код, что он становится самодокументируемым. Как раз интеллисенс играет тут первую скрипку. Вы открываете его окошко и видите ВСЕ возможности некоторого класса.
Нет, далеко не все. Например он не покажет что этот объект может быть аргументом у метода другого объекта
А вот если складывать внутрь класса всё то что может быть реализовано через его публичный интерфейс — то это уже ухудшение инкапсуляции и усложнение поддержки.
Да и например в D можно вызывать non-member функцию через "точку", такое может и к C++ добавят (была даже статья от Страуструпа об этом (как и об обратом — вызов метода с синтаксисом функции)) — так что IntelliSense это слабый аргумент (это скорее вопрос к IDE — пусть делают новые формы дополнения, а не только "через точку").
BDA>Альтернатива — курить маны. То есть, вышел новый стандарт, новый STL, новый boost и вы должны сразу прочитать, понять и запомнить все, что написано в сопроводиловке.
Читать документацию придётся в любом случае, чтобы знать контракты.
BDA>Нормальные люди предпочитают осмотреть классы с высоты птичьего полета, чтобы знать, что вообще есть, а потом уже углубленно знакомиться с нюансами вызова методов (типа, почему пишется Манчестер, читается Истанбул).
А это вообще ортогонально. Декомпозицию на контейнеры и алгоритмы можно делать и в что называется в "true OO style". То есть смотришь ты "с высоты птичьего полета" на класс UTF-8 строки, и видишь что она реализует IBidirectionalSequence, далее смотришь на алгоритмы которые принимают IBidirectionalSequence — и находишь там to_lower, split или что там нужно.
Или ты против такой декомпозиции вообще? Тогда например для каждой строки (и контейнера в общем) придётся придётся реализовывать каждый алгоритм — M контейнеров * N алгоритмов
BDA>Как раз вынесение алгоритмов за пределы классов принципиально и не дает воспользоваться этим преимуществом ООП. Процедурщина и хендловщина в полный рост.
Ты так говоришь как будто "true OOP" это всегда хорошо, а "процедурщина" плохо.
Здравствуйте, greenpci, Вы писали:
BDA>>Как раз вынесение алгоритмов за пределы классов принципиально и не дает воспользоваться этим преимуществом ООП. Процедурщина и хендловщина в полный рост. G>Ты, прямо, анти-сатер и анти-александреску и еще много людей
Практически у всех must-read C++ авторов есть что-нибудь на эту тему. Я кстати делал подборку(что-то уже было выше):
1. Alexander Stepanov. Notes on Programming:
While we could make a member function to return length, it is better to make it a global friend function. If we do that, we will be able eventually to define the same function to work on built-in arrays and achieve greater uniformity of design. I made size into a member function in STL in an attempt to please the standard committee. I knew that begin, end and size should be global functions but was not willing to risk another fight with the committee. In general, there were many compromises of which I am ashamed. It would have been harder to succeed without making them, but I still get a metallic taste in my mouth when I encounter all the things that I did wrong while knowing full how to do them right. Success, after all, is much overrated. I will be pointing to the incorrect designs in STL here and there: some were done because of political considerations, but many were mistakes caused by my inability to discern general principles.)
10.3.2 Helper Functions
Typically, a class has a number of functions associated with it that need not be defined in the class itself because they don’t need direct access to the representation. For example:
int diff(Date a,Date b); // number of days in the range [a,b) or [b,a)bool leapyear(int y);
Date next_weekday(Date d);
Date next_saturday(Date d);
Defining such functions in the class itself would complicate the class interface and increase the number of functions that would potentially need to be examined when a change to the representation was considered. How are such functions "associated" with class Date? Traditionally, their declarations were simply placed in the same file as the declaration of class Date, and users who needed Dates would make them all available by including the file that defined the interface.
Basically my belief is that nonvirtual member functions in general are an unnecessary cutesy in C++ that wahses people's brains, leads to bad programs, and will take many years to wear off. For smart pointers in particular, they can do even more harm.
I'll start with the punchline: If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function. That decision increases class encapsulation. When you think encapsulation, you should think non-member functions.
Surprised? Read on.
Здравствуйте, Igor Karablin, Вы писали:
IK>К сожалению (почти) нечему тормозить только у vector, с остальными контейнерами не всё так гладко.
Могу подтвердить. Производил замеры памяти и скорости, и пришлось отказаться от std::map и std::vector<bool> (отдельная спецификация вектора) в нашем продукте в пользу других реализаций, хотя очень хотелось использовать СТЛевские. Надо сказать, что создатели и не претендавали на самую быструю реализацию. Задача была выбрать меньшее из зол и удовлетворить большинство.
Спасибо, интересно.
IK>https://youtube.com/watch?v=fHNmRkzxHWs
На слайде "A good hash table design" он прям повторяет дизайн CAtlMap, который появился в ATL 7.0 в 2003 году.
И сам же афтар признаёт, что в мире open source до сих пор нет годных аналогов.
Здравствуйте, greenpci, Вы писали:
IK>>К сожалению (почти) нечему тормозить только у vector, с остальными контейнерами не всё так гладко. G>Могу подтвердить. Производил замеры памяти и скорости, и пришлось отказаться от std::map
std::map на что заменили? На дерево со встроенным free-list?
Здравствуйте, greenpci, Вы писали:
EP>>std::map на что заменили? На дерево со встроенным free-list? G>Сам полностью написал хэш мэп. Под наши специфические данные нужно было память экономить.
То есть ты заменил одну структуру данных, на совершенно другую, с другой алгоритмической сложностью и с другими требованиями к типу данных, и на основе этих опытов пришёл к выводу что std::map тормозит?
