Обновить
0
0

Пользователь

Отправить сообщение
Мне кажется, или вы говорите о ноутбуке?
В табличке же речь идёт о стационарных пека.
Извините конечно, но очень уж стремно выглядит перевод (?) race как «рейс»
Я бы больше того сказал. Опыт профилирования показывает, что в стл-е образца студии 2010 и gcc 4.6 вектор даже без преаллокации быстрее дека в случае если не приходится вставлять элемент в начало. Хотя я сам (да и мои коллеги, частенько) ранее ожидал, что в случае если размер контейнера заранее не известен, вставлять элементы можно в конец и контейнер большой (> 1Mb) — std::deque будет быстрее вектора.
Вообще, очень смешанные чувства вызывает QML и QtQuick. С одной стороны — декларативный подход к макетам интерфейса мне кажется очень хорошей идеей, а с другой стороны — мало того, что для того, что бы пользоваться Qt Quick надо кроме глубоких познаний в Qt по-факту знать три языка: QML, JavaScript и С++, так оно ещё и часто-густо не работает или работает как-то странно. Например:
  • До недавнего времени, (в 5.0.1, в 5.1.0 ещё не проверял) в присутствии окон со свойством OnTop ко всем MouseArea элементам переставал приходить Release.
  • Не существует (по заверениям поддержки digi'ии) способа сделать View наполненный интерактивными элементами, который не будет обладать Flickable свойством пока элементы влезают в одну страницу на View.
  • Из делегата Repeater'а всё ещё никак нельзя получить доступ к модели, кроме как наделяя делегат знаниями о том, что он используется внутри Repeater'а.
  • Документацию на QML тесты похоже что удалили. В 4.7 она достаточно подробная. В 5.1.0 beta там два с половиной слова.
  • 100500 рандомных, с моей точки зрения, warning'ов, которыми сыпет плюсовая часть QtQuick'а во время работы.

И это только то, что я смог вспомнить в воскресенье утром спросонья. Ну, т.е. я надеюсь, что QtQuick как-то разовьется и будет хорошим удобным инструментом, но сейчас мне это напоминает приход Qt 4, если вы понимаете о чем я.
Почему это забытая? Не забытая. Небольшие автожиры вовсю летают и продаются. Знаком с владельцем вот такой штуки:
auto-gyro.ru/wp-content/gallery/cavalon_main/cavalon_autogyro_01.jpg
с его слов расход топлива на более-менее значительные (>100 км) дистанции выходит примерно такой же как у жигулей.
Согласен с предыдущим оратором.

Как пример неудачного поведения, кажется в MSVC 2005 (как там в более новых студиях — не знаю, не проверял) если внутри функции с throw() таки вылетает исключение то деструкторы стековых объектов созданых внутри функции не вызываются, и если где-то в деструкторе было удаление временных файлов или другие действия над долгоживущими объектами это может приводить к утечкам долгоживущих ресурсов навроде дискового пространства, что уже совсем не ок.
На счет причин реализации UCS-2 я не очень-то в курсе, если честно. Было бы интерестно почитать.
А по поводу не-BMP символов, ситуация следующая — вы можете хранить их в виндовых строках, однако, насколько мне известно, системные средства подсчета количества символов в строке (wcslen и иже с ним) будут давать неправельные результаты.
Ну, т.е. символы то могут быть какими угодно, но система поддерживает именно UCS-2.
Дело в том, что в виндовсе символы не могут быть более чем двухбайтовыми. Там реализовано подмножество Unicode UCS-2 в котором можно кодировать только символы из BMP.

По теме — ящитаю в никсах с текстом надо работать в UTF-32, хранить в UTF-8, а в виндовсе — и обрабатывать и хранить UTF-16 (UCS-2), поскольку это несёт минимум хлопот, позволяет обрабатывать строки быстро (символы фиксированной длинны позволяют проще реализовать случайный доступ к конкретному символу) и хранить их эффективно с минимальными хлопотами.

Использование UCS-2 в винде накладывает некоторые ограничения — но, как мне кажется, эти ограничения имеют скорее теоретический характер.
Спасибо. Я считал, что это противоречит стандарту, но тут видимо есть какие-то правила мне не известные…
то становится возможным существование следующего кода:

Не становится.

3.10 Lvalues and rvalues
5 The result of calling a function that does not return a reference is an rvalue. User defined operators are
functions, and whether such operators expect or yield lvalues is determined by their parameter and return
types.

Если оператор должен возвращать новое значение, то необходимо создавать новый объект (как в случае бинарного плюса). Если вы хотите запретить изменение объекта как l-value, то нужно возвращать его константным.


Если не секрет, как вы предлагаете возвращать константный объект?

Я это к тому, что если как в
const Integer Integer::operator-(const Integer& i) ;


то номер не пройдёт, т.к. при возврате по значению сохраняется семантика копирования объекта.
Вообще говоря, я согласен. Но это может быть связано только с поломанным компилятором. Я прямо сейчас колбашу кросплатформенный проект на более чем полтора десятка разных платформ и на более чем 5 архитектур процессора. И мы приняли решение перейти к исользованию исключений повсеместно.
Поскольку у нас сложилось впечатление, что чинить поддержку исключений часто бывает намного проще, чем поддерживать коды возвратов для большОго количества подсистем и архитектур.
Но это такое. Каждый выбирает инструмент на свой вкус. Главное что бы выбор был обоснован и следовали этому выбору все.
Единственный важный момент про C++ и исключения, особенно в контексте библиотек:
Не везде исключения можно использовать. Например в исключения не должны пересекать границы Dll-ки почти никогда. Поскольку их будет возможно обработать только из плюсов.
Мне кажется разумным правило никогда не использовать исключения в случае если нужна бинарная совместимость с дргими языками/компиляторами и отдавать им предпочтение во всех остальных случаях.
Как-то всё сумбурненько, смешано в одну статью. Тут тебе и работа с workitem'ами и code-review и билды, и ниочём в тоже время.

Кроме того, не вполне понимаю, что должно обозначать состояние With Comments, в контексте код ревью. По результатам ревью код или можно отдавать в продакшен или нет. Если код With Comments, это что должно обозначать?
Вообще, код ревью на фоне той же atlassian FishEye&Crucible мне показался каким-то переусложнённым.
Ещё одно: Почему автор считает, что множество это обязательно immutable? Насколько я знаю, это не так.
Множество — это просто реализация абстракции математического множества, т.е. набора уникальных различимых элементов.
В примерах на плюсах несколько досадных ошибок:
1) массив (array) в плюсах объявляется не как
int[10] i_array;
а как
int i_array[10];
2) с/с++: std::list — как уже написано выше в комментах — двусвязный список а не односвязный
3) таки существуют хеш-таблицы в C++0x: std::unordered_set/std::unordered_map
4) в последнем наборе примеров надо не stl::set, а std::set
30 минут
15% — 20%

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность