Мне кажется вы немного не понимаете современные механизмы использования памяти. Пока есть свободная память целесобразно использовать ее по максимуму, так как это делает возможным более быструю работу (очень многое кешируется).
Приложению нет смысла освобождать память пока есть еще свободная.
В десятичную систему переводится только при преобразовании в строку. Все, больше нет других вариантов.
Почитал еще код. Не учите людей так работать с битами, ну пожалуйста. Преобразовывать в строки – извращение, есть ведь побитовые операции – javascript.ru/bitwise-operators
«Неизменяемая» (хотя это скорее immutable), «сохраняемая», не? Хотя вообще отличеие persistent jn immutable лишь в хранении указателей на старые версии насколько я понимаю.
Вы внимательно статью прочитали? Программа генерирует машинный код а потом его исполняет. При чем тут эффективность работы Паскаля?
Кстати эта ваша «беда» отключается в опциях компилятора паскаля еще начиная с Turbo Pascal. Просто нужно отключить проверку на попадание в границы массива.
2. Эти два пункта применимы и к Гугловской библиотеке. Если не выдирать их из контекста а посмотреть на причины.
Do not use assertions for argument checking in public methods. Этот пункт обоснован что параетры функции должны 1) проверятся всегда 2) ошибка должна кидать документированное исключение а не любое. Контракты никак не решают пункт 2), да и насчет пункта 1) не уверен.
Кстати в багрепорте почему-то упоминается что сейчас мол приходится повторять такой код:
if (! some_precondition_assertion)
throw new PreconditionException();
Хотя явно никто не мешает вынести его в отдельную функцию чтоб можно было писать например: check(some_precondition_assertion).
Do not use assertions to do any work that your application requires for correct operation. Это означает что у ассертов не должно быть побочных эффектов. Этот же момент применим и к контрактам. Они тоже не должны иметь побочных эффектов для корректного функционирования кода.
Короче ваш комментарий к сожалению не отстаивает вашу точку зрения.
Ну и каким образом данный багрепорт подтверждает вашу точку зрения?
В итоге просто предлагается синтаксический сахар для того же ассерта:
int foo()
pre ASSUME_EXPR
post ENSURE_EXPR
{
BODY
}
вместо
int foo() {
assert ASSUME_EXPR;
try {
BODY
} finally {
assert ENSURE_EXPR;
}
}
Не вижу тут какой-то действительно принципиальной разницы. Ну другая форма записи немного, но что это меняет по существу? Ну если это на уровне языка сделано – еще ясно зачем, но когда в виде кривого костыля – непостижимо.
Тогда уже можно начать утверждать что в Си невозможно ООП потому что там нет для него синтаксического сахара.
Еще описанную функциональность можно получить просто настроив Gallery (только нужно перенаправлять ей жесты).
groups.google.com/group/android-x86/msg/5928c8c972ad38e9
Она как раз достаточно неочевидна в отличие от самой установки.
Стаття 10
Приложению нет смысла освобождать память пока есть еще свободная.
Пока есть свободная память – грех ее не использовать для ускорения работы (например кешировать отрендеренную страницу для плавного скроллинга).
Почитал еще код. Не учите людей так работать с битами, ну пожалуйста. Преобразовывать в строки – извращение, есть ведь побитовые операции – javascript.ru/bitwise-operators
> За сервис спасибо
Может воспользуетесь им все-таки, а? :)
Это взорвало мой мозг. Все числа в JS хранятся в двоичном виде. Вы наверное что-то другое имеете в виду.
И не поленитесь – прогоните код через jsbeautifier.org/ например, форматирование ужасно, а исправить автоматом – 2 минуты.
Кстати эта ваша «беда» отключается в опциях компилятора паскаля еще начиная с Turbo Pascal. Просто нужно отключить проверку на попадание в границы массива.
Но для этого явно не нужно городить код в строках как сабж.
2. Эти два пункта применимы и к Гугловской библиотеке. Если не выдирать их из контекста а посмотреть на причины.
Do not use assertions for argument checking in public methods. Этот пункт обоснован что параетры функции должны 1) проверятся всегда 2) ошибка должна кидать документированное исключение а не любое. Контракты никак не решают пункт 2), да и насчет пункта 1) не уверен.
Кстати в багрепорте почему-то упоминается что сейчас мол приходится повторять такой код:
Хотя явно никто не мешает вынести его в отдельную функцию чтоб можно было писать например: check(some_precondition_assertion).
Do not use assertions to do any work that your application requires for correct operation. Это означает что у ассертов не должно быть побочных эффектов. Этот же момент применим и к контрактам. Они тоже не должны иметь побочных эффектов для корректного функционирования кода.
Короче ваш комментарий к сожалению не отстаивает вашу точку зрения.
В итоге просто предлагается синтаксический сахар для того же ассерта:
вместо
Не вижу тут какой-то действительно принципиальной разницы. Ну другая форма записи немного, но что это меняет по существу? Ну если это на уровне языка сделано – еще ясно зачем, но когда в виде кривого костыля – непостижимо.
Тогда уже можно начать утверждать что в Си невозможно ООП потому что там нет для него синтаксического сахара.