gribozavr
0
Существует контракт API, который описан в документации. Если его не выполнять, а просто написать код и заметить что и так, кажется, работает, то это просто везение. Кроме того, в будущем может сломаться.
gribozavr
0
let p = UnsafeMutablePointer<Int>.alloc(1)
p.memory = 20
p.dealloc(1)


Во второй строчке следует использовать метод initialize(), так как память ещё не инициализирована. Только после этого можно работать с memory. До того, как освобождать память, следует вызвать метод destroy().

Память, на которую указывает Unsafe(Mutable)Pointer, может быть инициализирована или нет. Очень важно использовать правильные методы для памяти в различных состояниях. Так как ваш указатель указывает на Int, то скорее всего в этом конкретном случае ничего плохого не случится, но как только вы начнёте работать с типами, для которых копия экземпляра не создаётся тривиальным побитовым копированием, не использование правильных методов почти наверняка приведёт к падениям программы и утечкам памяти. Посмотрите документацию на UnsafeMutablePointer, там довольно подробно написано про состояния, в которых он может находиться.

Тем не менее подобный низкоуровневый код в некоторых случаях позволяет оптимизировать программу либо по скорости, либо по количеству используемой памяти.


Чаще всего прямая работа с указателями нужна для вызова API на C, которые принимают сложные структуры данных с указателями внутри.
gribozavr
+9
Тогда я не могу воспроизвести вашу проблему. У нас в тестах используются pthread, причём под достаточной нагрузкой, что мне кажется, мы бы заметили, если эти тесты текут. Например, один из тестов на модель памяти и атомарные операции github.com/apple/swift/blob/master/validation-test/stdlib/AtomicInt.swift Все тесты проходят как на OS X, так и на Linux.

Если сможете, запостите, пожалуйста, нам в баг-трекер код, который течёт.
gribozavr
+5
Можно конкретный пример кода?
gribozavr
+3
Можете сказать что именно не работает? Мне не понятна фраза «ABI отваливается местами». Можете написать здесь или сразу на swift-users@swift.org.
gribozavr
+2
Clang с флагом -Wdocumentation проверяет что параметры в документации соответствуют параметрам в коде. Кроме этого, Clang выдаёт и некоторые другие предупреждения, связанные с документацией.
gribozavr
0
32-битный ARM больше 2-х не поддерживает.
gribozavr
0
> Почему так мало оперативки?

Потому что процессор 32-битный.
gribozavr
+4
Также можно включить флаг -Wdocumentation и будет проверяться соответствие комментария объявлению, насколько это возможно автоматически. Например, будет выдаваться предупреждение при @param для несуществующего параметра функции.
gribozavr
+1
> Двадцатизначное число — это число порядка 70 бит. Произведение двух таких чисел — 140 бит. В современной криптографии это все еще представляет достаточно сложную вычислительную задачу.

Вовсе нет. Любой мобильный телефон в течение минут разложит любое 140-битное число. (Конечно, если применять не trial division, а что-либо побыстрее.)
gribozavr
+1
LLVM, Clang. -Wall -pedantic.
gribozavr
0
Так это вопрос поддержки MS расширений, а не C++11, как написано в комментарии, на который я отвечаю.

> И не хочет. Упрямится поддерживать многие ms-специфики.

Что значит упрямится? Ваши патчи не приняли что ли? (Но вроде бы таких не видел в списке рассылки.) А вот от других разработчиков патчи для поддержки MS расширений видел (например, declspec(property...), квалификаторы модели наследования, uuidof). Кажется, кто-то писал что недавно удалось собрать MFC приложение.
gribozavr
0
А Clang уже поддерживает C++11 и C99, доделывать ничего не нужно.
gribozavr
+2
Clang не поставляется со стандартной библиотекой C++. Clang может работать как с libstdc++, так и с libc++.

std::less_equal<int>() не даёт strict weak ordering, код некорректен. www.sgi.com/tech/stl/StrictWeakOrdering.html
gribozavr
0
Проверенный на других компиляторах — не значит коррекрный с точки зрения стандарта. Не все компараторы корректны. Но хотелось бы подробностей.

И да, компилятор к std::sort имеет довольно опосредованное отношение.
gribozavr
0
Это не имеет никакого значения для Qt.
gribozavr
0
Ну-ну. Например?
gribozavr
+2
Я отвечу кодом. Вот тесты:
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
gribozavr
+2
Сообщение датировано 2011 годом. MCJIT на ARM сейчас вполне работает, IIRC.
gribozavr
0
> Есть какое-то число, которое надо сдвинуть на 63 и на 64. Это граничные значения. Как известно, именно граничные значения приносят больше всего неприятностей. Что же будет в res63 и res64? По идее должны быть нули.

Undefined behavior от вычисления res64 будет. Не делайте так.
gribozavr
+2
Одинаково работают для контейнеров и для массивов.
gribozavr
+1
И компилятор пересобирает ваш код под нужную ISA. Я не говорил, что нужно использовать SSE прямо в коде.
gribozavr
0
X87 fpu — ужасное легаси и не практически используется в современных системах. SSE — правильый способ считать floating point на современных x86.
gribozavr
0
CentOS 6.4 x86_64 работает.
gribozavr
0
> выключает прерывания, соответственно, поток в этот период монопольно владеет процессором

Наверное, только одним ядром? Или тут нет SMP?

Если нет SMP, то вот тут нужно как раз делать только одну попытку, последующие бессмысленны:
> Зачем делать N попыток захватить mlock, если можно уснуть после первой попытки?
gribozavr
0
Это ядерный мютекс или юзерспейсный? Если юзерспейсный: что если поток завершат принудительно извне в release_mutex() после захвата mutex->ilock? Я как программист ожидаю что все операции над мютексами атомарны.

gribozavr
+1
Книгу с драконом я наоборот не посоветую, там смещены акценты на парсинг и нет многих нужных вещей.

Посоветую эти две:

www.amazon.com/Engineering-Compiler-Second-Edition-Cooper/dp/012088478X/
www.amazon.com/Advanced-Compiler-Design-Implementation-Muchnick/dp/1558603204/
gribozavr
+1
> либо используют элементарщину вроде pthread

Ага, конечно. Уважаемый cheremin, прочитайте, хотя бы основные статьи у Hans Boehm по данной теме и выясните, какие проблемы решает C++11 MM. И будет ли работать pthread если C++ MM поломана, и хотя бы Threads Cannot be Implemented as a Library. Во всех реализациях C++ уже была рабочая модель памяти, достаточная для pthread. Да, были разрешены некоторые оптимизации, которые корректны в однопоточных программах, но создают data race на пустом месте в многопоточных. Но почти все эти баги закрыты до формализации модели памяти, потому что иначе даже «элементарщина», как вы выразились, не работала бы.

> Но давайте прикинем — каков объем кода, созданного с с использованием утвержденной С11 модели памяти, и который работает в высоконагруженном продакшене?

Весь многопоточный C++, даже не использующий C++11 threads, даже написанный до формализации этой модели памяти. Основной принцип модели памяти, SC-DRF, был всем очевиден давно, и именно на него ориентировались, просто в C++11 он формализован для этого языка.

> гораздо более сложной модели памяти
Вы разбираетесь в обоих моделях памяти настолько, что можете легко сравнить их сложность для реализации?
gribozavr
0
Отвечайте, пожалуйста на поставленный вопрос. Пока я вижу только FUD. Может быть сырая и прочие теории заговора.
gribozavr
+17
Какой-то ужас. Почитайте хотя бы для начала про грамматики, метод рекурсивного спуска и AST.
gribozavr
0
Эта модель памяти обсуждалась уже давно, почитайте рабочие документы комитета WG21 прежде чем делать такие заявления.

Вот, например, документ аж из 2004-го:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1680.pdf

Кроме того, при разработке этой модели учтены все грабли, по которой прошлась Java. Кроме того, когда разрабатывалась первая JMM Intel ещё не выпустил в паблик информацию о модели памяти x86.

Примеры багов, связанных с неправильной реализацией модели памяти в gcc или clang — в студию.
gribozavr
+1
Начиная с C++11 и C11 есть модель памяти. Она в целом соответствует тому, что большинство компиляторов уже и так реализовывали. Разница в очень небольших деталях, и эти изменения уже внесены в современные версии компиляторов.
gribozavr
0
Недостаток реализации с наследованием — обратный порядок элементов кортежа в памяти и медленная компиляция (компиляторам сложнее обрабатывать глубокие иерархии наследования, чем широкие).

stackoverflow.com/questions/9641699/why-is-it-not-good-to-use-recursive-inheritance-for-stdtuple-implementations

mitchnull.blogspot.com/2012/06/c11-tuple-implementation-details-part-1.html
gribozavr
+5
Ограниченный размер памяти любой ЭВМ делает её не-тюринг-полной, и что?

gribozavr
+1
В C++11 constexpr функции очень ограничены (запрещено использовать много конструкций), а в C++14 (C++1y) большая часть ограничений была снята. В C++1y в constexpr функциях можно использовать if, switch, циклы, изменять переменные (если их lifetime начался во время вычисления константного выражения), и прочее.

isocpp.org/files/papers/N3652.html

Можно попробовать в clang -std=c++1y (Clang брать из SVN, реализация ещё не полная).
gribozavr
0
constexpr — compile time.
gribozavr
+1
А теперь перепишите на constexpr из C++14 :)
gribozavr
+6
> Если патчи таковы, что их можно отсмотреть в почтовике

Так и запишем: Linux Kernel, GCC, Clang, LLVM — не серьёзные проекты.
gribozavr
0
И в libc++:
llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?revision=176593&view=markup

См. struct __long, struct __short и struct __rep с union внутри.