Существует контракт API, который описан в документации. Если его не выполнять, а просто написать код и заметить что и так, кажется, работает, то это просто везение. Кроме того, в будущем может сломаться.
let p = UnsafeMutablePointer<Int>.alloc(1)
p.memory = 20
p.dealloc(1)
Во второй строчке следует использовать метод initialize(), так как память ещё не инициализирована. Только после этого можно работать с memory. До того, как освобождать память, следует вызвать метод destroy().
Память, на которую указывает Unsafe(Mutable)Pointer, может быть инициализирована или нет. Очень важно использовать правильные методы для памяти в различных состояниях. Так как ваш указатель указывает на Int, то скорее всего в этом конкретном случае ничего плохого не случится, но как только вы начнёте работать с типами, для которых копия экземпляра не создаётся тривиальным побитовым копированием, не использование правильных методов почти наверняка приведёт к падениям программы и утечкам памяти. Посмотрите документацию на UnsafeMutablePointer, там довольно подробно написано про состояния, в которых он может находиться.
Тем не менее подобный низкоуровневый код в некоторых случаях позволяет оптимизировать программу либо по скорости, либо по количеству используемой памяти.
Чаще всего прямая работа с указателями нужна для вызова API на C, которые принимают сложные структуры данных с указателями внутри.
Тогда я не могу воспроизвести вашу проблему. У нас в тестах используются pthread, причём под достаточной нагрузкой, что мне кажется, мы бы заметили, если эти тесты текут. Например, один из тестов на модель памяти и атомарные операции github.com/apple/swift/blob/master/validation-test/stdlib/AtomicInt.swift Все тесты проходят как на OS X, так и на Linux.
Если сможете, запостите, пожалуйста, нам в баг-трекер код, который течёт.
Clang с флагом -Wdocumentation проверяет что параметры в документации соответствуют параметрам в коде. Кроме этого, Clang выдаёт и некоторые другие предупреждения, связанные с документацией.
Также можно включить флаг -Wdocumentation и будет проверяться соответствие комментария объявлению, насколько это возможно автоматически. Например, будет выдаваться предупреждение при @param для несуществующего параметра функции.
> Двадцатизначное число — это число порядка 70 бит. Произведение двух таких чисел — 140 бит. В современной криптографии это все еще представляет достаточно сложную вычислительную задачу.
Вовсе нет. Любой мобильный телефон в течение минут разложит любое 140-битное число. (Конечно, если применять не trial division, а что-либо побыстрее.)
Так это вопрос поддержки MS расширений, а не C++11, как написано в комментарии, на который я отвечаю.
> И не хочет. Упрямится поддерживать многие ms-специфики.
Что значит упрямится? Ваши патчи не приняли что ли? (Но вроде бы таких не видел в списке рассылки.) А вот от других разработчиков патчи для поддержки MS расширений видел (например, declspec(property...), квалификаторы модели наследования, uuidof). Кажется, кто-то писал что недавно удалось собрать MFC приложение.
Во второй строчке следует использовать метод initialize(), так как память ещё не инициализирована. Только после этого можно работать с memory. До того, как освобождать память, следует вызвать метод destroy().
Память, на которую указывает Unsafe(Mutable)Pointer, может быть инициализирована или нет. Очень важно использовать правильные методы для памяти в различных состояниях. Так как ваш указатель указывает на Int, то скорее всего в этом конкретном случае ничего плохого не случится, но как только вы начнёте работать с типами, для которых копия экземпляра не создаётся тривиальным побитовым копированием, не использование правильных методов почти наверняка приведёт к падениям программы и утечкам памяти. Посмотрите документацию на UnsafeMutablePointer, там довольно подробно написано про состояния, в которых он может находиться.
Чаще всего прямая работа с указателями нужна для вызова API на C, которые принимают сложные структуры данных с указателями внутри.
Если сможете, запостите, пожалуйста, нам в баг-трекер код, который течёт.
Потому что процессор 32-битный.
@param
для несуществующего параметра функции.Вовсе нет. Любой мобильный телефон в течение минут разложит любое 140-битное число. (Конечно, если применять не trial division, а что-либо побыстрее.)
> И не хочет. Упрямится поддерживать многие ms-специфики.
Что значит упрямится? Ваши патчи не приняли что ли? (Но вроде бы таких не видел в списке рассылки.) А вот от других разработчиков патчи для поддержки MS расширений видел (например, declspec(property...), квалификаторы модели наследования, uuidof). Кажется, кто-то писал что недавно удалось собрать MFC приложение.
std::less_equal<int>() не даёт strict weak ordering, код некорректен. www.sgi.com/tech/stl/StrictWeakOrdering.html
И да, компилятор к std::sort имеет довольно опосредованное отношение.
llvm.org/viewvc/llvm-project/llvm/trunk/test/ExecutionEngine/MCJIT/
Вот конфиг системы тестирования, в котором написано, на каких платформах тесты запускать:
llvm.org/viewvc/llvm-project/llvm/trunk/test/ExecutionEngine/MCJIT/lit.local.cfg?revision=183143&view=markup