Вообще, я аллокаторы для примера привел… Вообще все «низкоуровневые» функции имеет смысл скрывать за абстракциями, только долго это, кода лишнего требует… Поясню, под «низкоуровневыми» я понимаю все, что платформо-зависимо, в т.ч. API.
Вы что-то пропустили… есть такая штука, называется boost::graph, которая в частности применима к деревьям.
Там есть:
* Различные варианты представления графа в памяти (можно, например, использовать граф, оптимизированный под поиск, а можно оптимизированный под добавление элементов)
* Хранение данных не только в узлах, но и в связях между узлами.
* Двусторонние/односторонние связи.
* В полпинка (в 100 строчек) делается вывод графа в png файлы (через graphvis).
* Куча разных итераторов, перебирающих граф в разных порядках.
* Уже реализованные разные алгоритмы, вроде поиска кратчайшего пути.
Я бы также добавил про смысл: избегайте массивов в си стиле и непонятных операций с типами. В с++ есть STL. Всякие malloc и free в коде использоваться не должны, разве что в таких вещах, как Small Object Allocator, но таких мест в программе обычно очень мало, да и ошибки там отлавливаются очень быстро.
«Автоматически исправлять» это не значит что прямо вот так делать все за программиста… Это вообще хороший вопрос как такое можно сделать, но, мне кажется, можно придумать систему, которая существенно упростила бы жизнь. Хотя бы какой-то интерактивный помощник, предлагающий варианты исправления для каждого предупреждения.
Я осознаю, что в ручную конечно лучше… но «вручную» на проекте более миллиона строк это страшно… учитывая, что size_t нигде нету, так уж повелось…
Да… без нормальных функций это некрасиво выглядит… Впрочем, возможно, оно быстрее работает, чем у Intel, интеловский ассемблер действительно перегружен командами…
Даже с учетом этого приведенный код будет работать, потому что char выравнивается на 1 байт. И даже если бы там были не char, а что-то еще оно бы все равно работало, потому как типы обычно выравниваются на размер типа.
На мой взгляд, переход на страницу памяти, не загруженную в оперативку генерирует аппаратное исключение, которое обрабатывает ОС, подгружая новую страницу и возвращая управление к тому месту, где произошло исключение.
А то по вашему получается, что в С++ теперь нельзя разыменовывать указатели без какого-то непонятного шаманства.
Это в смысле ошибки IntelliSence? Лучше никак не реагировать… у нас в коде таких «ошибок» студия находит просто бешенное количество, хотя там все ок… она просто «не разобралась»
На самом деле, совершенно нету разницы сколько байт занимает int, если ваш код написан одинаково (т.е. все программисты считают, что размер int 4 байта или, например, 8).
Если вам не нравится, как сделали в компиляторе, добавьте
Распределенные системы всех спасут :)
Так thepiratebay.org уже около года работает с отключенным трекером, а раздачи все равно загружаются :) Осталось только систему поиска распределенную сделать…
Вообще, я аллокаторы для примера привел… Вообще все «низкоуровневые» функции имеет смысл скрывать за абстракциями, только долго это, кода лишнего требует… Поясню, под «низкоуровневыми» я понимаю все, что платформо-зависимо, в т.ч. 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%.
Было бы очень удобно :)
Если вам не нравится, как сделали в компиляторе, добавьте
в настройки проекта…
Так thepiratebay.org уже около года работает с отключенным трекером, а раздачи все равно загружаются :) Осталось только систему поиска распределенную сделать…