Не знаю, как остальные утилиты, но Intel® Concurrency Checker, помоему, абсолютно бесполезна. Базовую информацию я и сам посмотрю в диспетчере задач. А того, что действительно важно: информации о синхронизации потоков, использовании кеша, о том, кто кого, как и почему ждет (желательно с привязкой к строчке в коде) там нету…
— Вообще статья несколько странная… Например фраза
«Наверное, стоит уточнить, что технология Intel® Active Management (Intel® AMT) — это функциональность, встроенная в платформы Intel, которая расширяет возможности управлению корпоративными вычислительными системами»
не говорит абсолютно ничего человеку, который не знаком с указанной технологией, 2 строчки из википедии мне сказали намного больше…
Вообще, я аллокаторы для примера привел… Вообще все «низкоуровневые» функции имеет смысл скрывать за абстракциями, только долго это, кода лишнего требует… Поясню, под «низкоуровневыми» я понимаю все, что платформо-зависимо, в т.ч. API.
Вы что-то пропустили… есть такая штука, называется boost::graph, которая в частности применима к деревьям.
Там есть:
* Различные варианты представления графа в памяти (можно, например, использовать граф, оптимизированный под поиск, а можно оптимизированный под добавление элементов)
* Хранение данных не только в узлах, но и в связях между узлами.
* Двусторонние/односторонние связи.
* В полпинка (в 100 строчек) делается вывод графа в png файлы (через graphvis).
* Куча разных итераторов, перебирающих граф в разных порядках.
* Уже реализованные разные алгоритмы, вроде поиска кратчайшего пути.
Я бы также добавил про смысл: избегайте массивов в си стиле и непонятных операций с типами. В с++ есть STL. Всякие malloc и free в коде использоваться не должны, разве что в таких вещах, как Small Object Allocator, но таких мест в программе обычно очень мало, да и ошибки там отлавливаются очень быстро.
«Автоматически исправлять» это не значит что прямо вот так делать все за программиста… Это вообще хороший вопрос как такое можно сделать, но, мне кажется, можно придумать систему, которая существенно упростила бы жизнь. Хотя бы какой-то интерактивный помощник, предлагающий варианты исправления для каждого предупреждения.
Я осознаю, что в ручную конечно лучше… но «вручную» на проекте более миллиона строк это страшно… учитывая, что size_t нигде нету, так уж повелось…
Да… без нормальных функций это некрасиво выглядит… Впрочем, возможно, оно быстрее работает, чем у Intel, интеловский ассемблер действительно перегружен командами…
Даже с учетом этого приведенный код будет работать, потому что char выравнивается на 1 байт. И даже если бы там были не char, а что-то еще оно бы все равно работало, потому как типы обычно выравниваются на размер типа.
На мой взгляд, переход на страницу памяти, не загруженную в оперативку генерирует аппаратное исключение, которое обрабатывает ОС, подгружая новую страницу и возвращая управление к тому месту, где произошло исключение.
А то по вашему получается, что в С++ теперь нельзя разыменовывать указатели без какого-то непонятного шаманства.
Это в смысле ошибки IntelliSence? Лучше никак не реагировать… у нас в коде таких «ошибок» студия находит просто бешенное количество, хотя там все ок… она просто «не разобралась»
— Вообще статья несколько странная… Например фраза
«Наверное, стоит уточнить, что технология Intel® Active Management (Intel® AMT) — это функциональность, встроенная в платформы Intel, которая расширяет возможности управлению корпоративными вычислительными системами»
не говорит абсолютно ничего человеку, который не знаком с указанной технологией, 2 строчки из википедии мне сказали намного больше…
Вообще, я аллокаторы для примера привел… Вообще все «низкоуровневые» функции имеет смысл скрывать за абстракциями, только долго это, кода лишнего требует… Поясню, под «низкоуровневыми» я понимаю все, что платформо-зависимо, в т.ч. API.
Там есть:
* Различные варианты представления графа в памяти (можно, например, использовать граф, оптимизированный под поиск, а можно оптимизированный под добавление элементов)
* Хранение данных не только в узлах, но и в связях между узлами.
* Двусторонние/односторонние связи.
* В полпинка (в 100 строчек) делается вывод графа в png файлы (через graphvis).
* Куча разных итераторов, перебирающих граф в разных порядках.
* Уже реализованные разные алгоритмы, вроде поиска кратчайшего пути.
и т.д.
Я бы также добавил про смысл: избегайте массивов в си стиле и непонятных операций с типами. В с++ есть STL. Всякие malloc и free в коде использоваться не должны, разве что в таких вещах, как Small Object Allocator, но таких мест в программе обычно очень мало, да и ошибки там отлавливаются очень быстро.
Я осознаю, что в ручную конечно лучше… но «вручную» на проекте более миллиона строк это страшно… учитывая, что size_t нигде нету, так уж повелось…
Заменять int на size_t в очевидных случаях достаточно утомительное занятие…
я имею в виду, что на х86 в ассемблере можно писать
до х64 ассемблера я не дожил, но думаю там тоже как-то так… а как в power pc?
з.ы. кстати, конструкция с циклом при компилировании в х86 вообще должна превратиться в что-то вроде «repne scasb»
На мой взгляд, переход на страницу памяти, не загруженную в оперативку генерирует аппаратное исключение, которое обрабатывает ОС, подгружая новую страницу и возвращая управление к тому месту, где произошло исключение.
А то по вашему получается, что в С++ теперь нельзя разыменовывать указатели без какого-то непонятного шаманства.
Насчет прогресса… а можно ли сделать, чтобы показывало в качестве прогресса количество собранных проектов?
Например, в solution 10 проектов, если уже собрано 3, то прогресс 30%.
Было бы очень удобно :)