А что тут придумывать? Ключевая фраза — «С файлами SMD могут работать большинство 3D-редакторов после установки маленького плагина». Cнести условно бесплатный фотошоп и условно бесплатный 3ds Max, после чего поставить Blender для нормальной работы с трёхмерной графикой. Последний, к слову, развивается не в пример быстрее, чем GIMP.
Gimp 2.7.3 из PPA. Переключаю в однооконный режим, закрываю, запускаю заново — снова наблюдаю кучу окошек. Раздел «Поведение окон» в настройках тоже не помогает. Что не так?
Хм, конечно же хранит, но это происходит вне объекта (где-то в QApplication, под рукой у основного цикла событий). Речь шла о том, что контроль за целостностью указателя программистом не осуществляется в принципе.
Если кратко, то никак. А зачем в определённый момент может понадобиться список всех собак? Если для того, чтобы выполнить какой-нибудь метод или вызвать деструктор, то сигналы-слоты с этим нормально справляются. Всю логику отношений N к N можно выразить таким образом.
Скажем, если человеку нужно завести несколько собак, то приведённый код надо переписывать с нуля. А если у каждой собаки может быть несколько владельцев одновременно, то слежение за всеми ссылками превращается в сущий кошмар.
А в Qt если необходимо установить связь между объектами, совсем не обязательно в объекте хранить указатели на соседа. Например:
Да, это относится к фразе «на практике означает, что писать код под сборщик мусора нельзя». Очевидно, что сборщик мусора тянет за собой рантайм, а за рантаймом всегда есть контроль со стороны программиста.
Т. е. вы считаете, что на чистом Си спокойно можно написать сборщик мусора boehm, а в C++ нельзя? A для кого в стандарте пишут, например, такое
In a garbage-collecting implementation, the fact that a region in an object is registered with declare_no_pointers() should not prevent the object from being collected.
А для чего там написаны разделы «20.6.4 Pointer safety» и «3.7.4.3 Safely-derived pointers»?
Вы действительно ожидаете, что я здесь напишу километровый комментарий на тему всего-подряд-нового в C++0x? Да тут на несколько статей не опишешь. Вкратце предлагаю взять статью из Википедии и разделить новшества на две части: пришедшие из boost-а и возникшие сами по себе. Так вот для последних (за исключением overrides, final, range-based for и может быть чего-нибудь ещё) практически невозможно найти статически типизированные языки, в которых оно реализовано.
занимало полторы сотни страниц (при том что весь остальной стандарт — около 800
Не знаю, откуда эта цифра, но у меня в финальном черновике 1338 страниц.
В С++0х сборщика мусора не будет.
Не «не будет», а в стандарте определено как «зависит от реализации». Я не занудствую, это действительно разные вещи. И второе на данный момент намного лучше. По крайней мере до того момента, пока не формализуют условия существования мифического zero-cost garbage collector. Ну или не опровергнут проблему остановки =).
Thread pools, task launching, and reader-writer locks
Не забывайте, что в новом стандарте есть новая глава Threads на 50 страниц. Почти всё, что нужно программисту для multithread-программирования там есть.
template <typename T> class c1 {
BOOST_STATIC_ASSERT(boost::is_arithmetic<T>::value);
};
Один из примеров, когда Boost спокойно справляется с задачей. А вот ответ компилятора на неправильный тип:
main.cpp: In instantiation of 'c1<void>':
main.cpp:13:11: instantiated from here
main.cpp:8:2: error: static assertion failed: «boost::is_arithmetic<T>::value»
Плохое в том, что перед написанием кода неплохо бы задаться реальной практической целью, с которой пишется код. Люди видят, что в языках есть интроспекция и сразу накручивают макросы добавления метаданных к классу «чтобы просто были». Люди видят, что в языках есть рефлексия и сразу на каждое поле данных класса приделывают класс с теми самыми метаданными. Зачем нужна интроспекция и рефлексия никого не волнует.
А ведь можно было задаться целью написать систему сериализации/десериализации классов, в которых поля определены как «field(float, f);». Или приделать систему динамического добавления полей. В любом случае нужно задаться реальной целью до начала написания кода.
Какая-то жуткая смесь Си, C++ и С++0x с регулярным эксплуатированием багов компилятора студии. Гигантские макросы, которые разворачиваются в шаблоны, которые инстанциируются для классов, которые в свою очередь сгенерированы препроцессором. Мечта для любителей отладки.
А причина появления статьи просто гениальна: «в C++ нет средства описания полей класса с контролируемым доступом, как например property в C#». Конец объяснений (к слову, в прошлой статье то же самое). Опять же, полный игнор комментариев к предыдущей статье. Извините, но это совсем не fun.
Собственно, в Clang анализатор нашёл только две ошибки. Из них одна на самом деле ошибкой не является. Всё остальное — ошибки LLVM, который, впрочем, тоже неплохо подходит для анализа, но ни в коем случае не является частью Clang (скорее наоборот).
Об ошибках сообщил в несколько мест, часть уже исправили, остальное перенаправили авторам участков кода.
По поводу PS: как так получается, что после препроцессирования у вас остаются комментарии? Моя версия из trunk старательно вырезает комментарии при процессировании (флаг -E) и нормально расставляет переносы. Вполне возможно, что баг уже давно исправлен.
Скажем, если человеку нужно завести несколько собак, то приведённый код надо переписывать с нуля. А если у каждой собаки может быть несколько владельцев одновременно, то слежение за всеми ссылками превращается в сущий кошмар.
А в Qt если необходимо установить связь между объектами, совсем не обязательно в объекте хранить указатели на соседа. Например:
Соответственно, если humanObject или dogObject удалить, то связь будет разрушена и методы вызываться не будут.
А для чего там написаны разделы «20.6.4 Pointer safety» и «3.7.4.3 Safely-derived pointers»?
Не знаю, откуда эта цифра, но у меня в финальном черновике 1338 страниц.
Не «не будет», а в стандарте определено как «зависит от реализации». Я не занудствую, это действительно разные вещи. И второе на данный момент намного лучше. По крайней мере до того момента, пока не формализуют условия существования мифического zero-cost garbage collector. Ну или не опровергнут проблему остановки =).
Не забывайте, что в новом стандарте есть новая глава Threads на 50 страниц. Почти всё, что нужно программисту для multithread-программирования там есть.
Зачем оно нужно, когда можно написать:
Один из примеров, когда Boost спокойно справляется с задачей. А вот ответ компилятора на неправильный тип:
И всё. И стоит оно сотни страниц стандарта?
А ведь можно было задаться целью написать систему сериализации/десериализации классов, в которых поля определены как «field(float, f);». Или приделать систему динамического добавления полей. В любом случае нужно задаться реальной целью до начала написания кода.
А причина появления статьи просто гениальна: «в C++ нет средства описания полей класса с контролируемым доступом, как например property в C#». Конец объяснений (к слову, в прошлой статье то же самое). Опять же, полный игнор комментариев к предыдущей статье. Извините, но это совсем не fun.
Вы посетитель №10000 на нашем сайте!
Вам предоставляется шанс выиграть ценный приз!
У вас осталось 10 секунд!
Желаете видеть flash-баннеры с озвучкой в Википедии? Викии на вас не хватает!
Об ошибках сообщил в несколько мест, часть уже исправили, остальное перенаправили авторам участков кода.
По поводу PS: как так получается, что после препроцессирования у вас остаются комментарии? Моя версия из trunk старательно вырезает комментарии при процессировании (флаг -E) и нормально расставляет переносы. Вполне возможно, что баг уже давно исправлен.