Так или иначе, но мне видится, что любой новый продукт должен пройти весь цикл тестирования до попадания в stable. Или для backports существуют иные правила?
Вообще удивительный шаг — обычно в stable попадают продукты после довольно продолжительного тестирования в нестабильной и тестовой ветви, здесь же чувствуется спешный переход «чтобы было».
Также, естественно, динамические массивы были заранее созданы и наполнены элементами (т.е. новые элементы не добавлялись во время тестовых замеров).
Насколько мне известно, под «динамическими массивами» понимаются массивы, размеры которых изменяются во время выполнения программы. В вашем случае при изменении размерности x матрицы необходимо перелопачивание и перезаполнение одномерного массива, так как в этом случае обращение a[x + y*size_x] будет приводить к непредсказуемым результатам (изменен size_x). Таким образом, ваша оптимизация будет корректно работать лишь со статическими матрицами.
Вы не первый, кто пытается оптимизировать работу с массивами, так давайте не будем пытаться изобрести новый одномерный велосипед =)
Спекулянты есть как на бирже, так и на вполне реальных рынках товаров (хотя на рынке они и выполняют в первую очередь функцию доставки продукта до потребителя). На биржах же спекулянты помогают компаниям в борьбе с рисками — покупают их товары и берут на себя риски, связанные с изменением цены этих товаров в будущем. То, что они кладут себе в карман — плата за услугу (взятые риски). Увы, спекулянты нужны и на рынках, и на биржах.
В статье вполне себе описан принцип работы с TortoiseHg. Полное описание в стиле «кнопка commit — это для коммитов, а кнопка push — для пушей» со скринами тех самых кнопок, это, простите, чересчур.
Все-таки проще — эабить user:pass в батник, нежели ковырять конфиги. С точки зрения безопасности — конфиги, безусловно, лучше. Однако не хочется удлинять и так уже тяжелый текст.
Обязательно опишу в следующей части статьи, если возьмусь ее написать =)
Так, безусловно, грамотнее и правильнее, но целью статьи не было описание всего и вся, что есть в Mercurial. Без hgrc на первых порах вполне можно обойтись, со временем все обязательно найдется в мануалах.
В общем-то, эти сокращения — дело вкуса) Но, опять же, в вводной статье про СКВ не хочется грузить читателей кучей новых терминов. Новички сами разберутся со временем, а профессионалам данная статья не нужна вовсе.
Вы не первый, кто пытается оптимизировать работу с массивами, так давайте не будем пытаться изобрести новый одномерный велосипед =)
Не вижу смысла, все что вы пушите в bitbucket — лежит и в вашем локальном репозитории.
Спасибо, исправил, потерялось при перепубликации.
Обязательно опишу в следующей части статьи, если возьмусь ее написать =)