Избавляемся от строковых констант в Objective-C

Если под авто выравниванием понимаете autoresizing mask, то все банально до неприличия:

someButton.center = newCenterCGPoint;

Ну и анимировано:

[UIView animateWithDuration:0.3f animations:^{
     someButton.center = newCenterCGPoint
 }];

Если же под авто выравниванием вы понимаете Autolayout, то, к сожалению я не так плотно с ним работал. Но вот, нарыл гуглением:
— изменяются константы autolayout'а, после чего делается

[self.view layoutIfNeeded];

Избавляемся от строковых констант в Objective-C

Вот, кстати, замечательная статья о разработке cocos2d игры с использованием Storyboard

Избавляемся от строковых констант в Objective-C

На самом деле для большинства казуальных 2-d игр UIKit для меню и всего неигрового — отличный выбор. Для экрана самой игры — тот-же CCViewController (если вы используете cocos2d). Можно хоть xib-ы, хоть storyboard-ы использовать. (у меня так пару игровых приложений написана)
Другое дело, что даже красивая анимация, смех и дышание кнопок никак не противоречат авторесайзу

Избавляемся от строковых констант в Objective-C

Я что-то не совсем понимаю. Вы работаете с CoreData, но будете продолжать писать FetchRequest-ы оперируя строковыми константами, вместо того, чтобы использовать библиотеки, которые на порядки уменьшат количество кода (и соответственно ошибок), таких как ActiveRecord for Core Data. Вы предпочитаете не использовать инструменты автоматизирующие рутинные операции, а писать все руками? По поводу свойств — я говорил о KVO и KVC: рефакторинг в Xcode не настолько умен, чтобы переименовать и строковые константы вместе со свойствами.
Наверное я вас неправильно понял.
Все вышеописанное совсем не надуманные для меня проблемы. Это проблемы, с которыми я встречаюсь каждый день. И в своем, и в чужом коде. Я лишь описал один из способов решения этих (с моей точки зрения) проблем.
Эти библиотеки и утилиты сэкономили мне кучу времени и нервов. И я буду рад если помогут и другим.
Если для вас эти подходы сложны, неочевидны и нестандарты — не используйте их.

Избавляемся от строковых констант в Objective-C

Вы часто делаете рефакторинг? Вы часто изменяете reuseIdentifiers / storyboardID? Вы переименовуете имена пропертей? Вы плотно работаете с CoreData? Никто не спорит: Objective-C динамичен и прекрасен в своей гибкости. Но некоторые вещи я лучше доверю компилятору. Именно поэтому я не отключаю Static Analyser. Именно поэтому я буду использовать инструменты, позволяющие выявлять ошибки на стадии компиляции.
Я ценю свое время.

Избавляемся от строковых констант в Objective-C

Не обязан, но желательно, чтобы один ксиб содержал один объект(вьюху, ячейку, контроллер).
Если ксиб содерджит 20 вьюх/селл, а нам нужна всего одна, то в память будут загружены и инстанциированы все 20 вьюх.
Если же одна вьюшка содержит аутлеты на остальные, то не проблема назвать сам ксиб но имени класса этой вьюшки.

Избавляемся от строковых констант в Objective-C

Так серебряной пули не существует. Нужно, конечно, всегда смотреть от контента. Но, согласитесь, что такой UI — это не норма, а скорее наоборот. И для одного окна можно и 2 ксиба завести. Но в подавляющем большинстве случаев UI отлично растягивается/перемещается автоматически.
Смысл статьи немного не о именовании ксибов для исключительных случаев — а в том, чтобы помочь компилятору выявлять как можно больше ошибок еще до того, как приложение запустится и упадет

Избавляемся от строковых констант в Objective-C

Если интерфейс так разительно отличается из-за половины дюйма, да так, что AutoresizingMask / Autolayout не спасают, то стОит подумать. Стоит сильно подумать что не так с интерфейсом. Или почитать про AutoresizingMask / Autolayout подробнее. Или вычислить положение некоторых элементов в рантайме. И только в крайнем случае заводить два ксиба для одного и того-же экрана под 3.5 / 4 дюйма. Так как поддержка двух вьюх для одного и того-же контроллера — занятие утомительное и неблагодарное. ИМХО опять-же

Избавляемся от строковых констант в Objective-C

Попробуйте называть ксибы KingViewController и KingViewController~ipad.xib — это избавит вас от одного сравнения в рантайме. А для решения проблемы 568/480 пикселей в высоту — используйте AutoresizingMask / Autolayout. Это избавит вас от необходимости поддерживать 2 интерфейса вместо одного для iPhone

Избавляемся от строковых констант в Objective-C

Да, там в реализации по умолчанию

NSStringFromClass([self class])

это только примеры, для иллюстрации основной идеи

Thread concurrency C++11, свой велосипед технологии (Apple) GCD

Можно и через бинд запоминать, но имхо если уже используется C++11, то лучше использовать лямбды — они как раз для этого и предназначены. Читабельность от этого только выиграет

Thread concurrency C++11, свой велосипед технологии (Apple) GCD

все блоки, которыми оперирует GCD объявлены как

void (^dispatch_block_t)(void)

Если вы уже используете лямбды, то зачем усложнять написание и чтение gcdpp_dispatch_async еще и параметрами?

ИМХО что-то на подобии такого будет на порядки читабельнее:

gcdpp::gcdpp_dispatch_async(gcdpp::gcdpp_dispatch_get_global_queue(gcdpp::GCDPP_DISPATCH_QUEUE_PRIORITY_HIGH) ,[=]{
   //  а вот здесь уже вызываем любую функцию с любым количеством параметров, например
  function(1, 2.0f, "Hello World");
} );

Простой JSON Schema валидатор для Objective-C

Можно. Работает в обе стороны:

[SVType schemaWithDictionary:jsonSchema];

NSDictionary* jsonSchema = [NSString toJsonObject]

Ну а превратить схему в NSDictionary вам поможет любой JSON парсер, например NSJSONSerialization

SIMD без SIMD, или ищем на С почти в два раза быстрее чем на С++

Как оказалось на ideone 32-битные машины, тогда понятно откуда замедление

SIMD без SIMD, или ищем на С почти в два раза быстрее чем на С++

Да. Речь об исходном коде. Но ideone C++11 (gcc-4.7.2) показывает напротив, что так будет в полтора раза медленнее

SIMD без SIMD, или ищем на С почти в два раза быстрее чем на С++

Если уж говорить о оптимизациях — простое изменение объявления структуры на

struct T_cash_account_row {
...    
    int32_t code;
    int32_t amount_of_money;
    int16_t height;
    int16_t age:7;
    int16_t gender:1;
...

дает точно такой-же прирост скорости — почти в 2 раза на моем 1,7ГГц Core i7 (LLVM version 4.2 (clang-425.0.28) )
И это без битовых операций.

Скорости разработки и исполнения, не достижимые на С

Спасибо за статьи. Действительно очень впечатляет. Но что насчет стоимости сопровождения такого варианта?

ИМХО использование контейнеров и запись вроде такой

auto endIterator = std::copy_if(rows.begin(),
                                    rows.end(),
                                    std::back_inserter(output),
                                    [&] (const CashAccountRow& instance) -> bool {
        // filter
    });
});

здорово ускорит разработку, уменьшит количество кода( а заодно и багов), и на порядки понизит стоимость как разработки, так и сопровождения кода.
Ну а железо дешевеет с каждым днем

Stack Overflow заменяет официальную документацию по всем вопросам

ИМХО документация по самой джаве ничуть не лучше.

Супер простой iOS JSON mapper

Основная идея в том, что создается схема. По сути это описание json'а с указанием того, какие у каких объектов есть свойства, какие у них могут быть значения (если это массив, то какие объекты он может содержать, если число — то какой дианазон оно может принимать, являются ли какие-либо поля строго обязательными и т.д) Вот обзорная статья на хабре . Так вот, метод jsonSchema как раз и создает такую схему для уже существующих классов.