Шок от С. Как склеивать строки?

Я тоже попробую.

NSMutableDictionary *m = [NSMutableDictionary new];
m[@"str"] = @1;
m[@"str"] = @([m[@"str"] integerValue] + 1);

NSMutableDictionary *m = [NSMutableDictionary new];
[m setObject:@1 forKey:@"str"];
[m setObject:@([m[@"str"] integerValue] + 1) forKey:@"str"];

ты это имел ввиду под «читить»?

Нет, на ЛОР есть персонажи, которые бы написали бы, например:

m_str = 2;

Извиняюсь, если подобное предположение задело.

И ты серьезно считаешь это более понятным?

m[@«str»] = @1;
Но сахар - не очень хорошо

Почему, сахар в меру - очень хорошо, потому-то его таки и добавили в objc, другое дело, что взяв этот вариант и сравнив с С++ все-равно будут только минусы.

Изначально в objective c код, который выглядит как сишный означает только то, что и в сишке. Из-за этого пришлось «@» вводить. И это плюс. А где минусы?

Из-за этого пришлось «@» вводить

Я про [], его добавили относительно недавно.

А где минусы?

NSMutableDictionary *m = [NSMutableDictionary new];

не указаны типы ключей и значений, нет проверок типов в compile-time. Более многословно, там где в С++ просто пишется тип и имя - тут дублирование NSMutableDictionary и т.п.

m[@"str"] = @1;

«пришлось «@» вводить» - читать проще явно не стало

m[@"str"] = @([m[@"str"] integerValue] + 1);

Тут, думаю, все очевидно.

m[@«str»] = @1;

/me не знал что это работает для mutable :)

Более многословно, там где в С++ просто пишется тип и имя - тут дублирование NSMutableDictionary и т.п.

id m = [NSMutableDictionary alloc];

«пришлось «@» вводить» - читать проще явно не стало

@ как раз очень важен и полезен — он показывает что это objc объект, а не просто сишный литерал.

id m = [NSMutableDictionary alloc];

Не развнозначный код. И не такой читабельный, даже первый вариант на objc лучше.

@ как раз очень важен и полезен — он показывает что это objc объект, а не просто сишный литерал.

Так я не спорю - для objc полезен и нужен, а вот в коде на С++ просто вызывается нужный конструктор (std::string в данном случае). Ничего руками выписывать не надо, и сишный литерал остается сишным литералом.

Не развнозначный код.

в каком месте?

И не такой читабельный, даже первый вариант на objc лучше.

ты определись уже.. то тебе дублирование типа не читабельно, то наоборот.

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

в objc тоже так можно:

[NSString stringWithUTF8String:"C Literal"];

и это очень хорошо, что это делается явно, т.к. наглядно показывается, что NSString и const char[] это разные вещи. многие крестовики думают что у std::string нет оверхеда, именно из-за сахара.

в каком месте?

В месте типа переменной.

ты определись уже.. то тебе дублирование типа не читабельно, то наоборот.

Просто ты не хочешь замечать, они нечитабельны по-разному, первый - дублирование, второе - тип переменной перестает что-либо говорить и надо смотреть на выражение справа.

в objc тоже так можно:
[NSString stringWithUTF8String:«C Literal»];

Хорошая шутка.

В месте типа переменной.

и что с ним? можешь привести пример, где неравнозначность проявляет себя?

Просто ты не хочешь замечать, они нечитабельны по-разному, первый - дублирование, второе - тип переменной перестает что-либо говорить и надо смотреть на выражение справа.

это ты не хочешь понять, что это аналог new из c++. если ты будешь выделять свой map через new, будет то же самое: либо auto, либо дублирование.

многие крестовики думают что у std::string нет оверхеда, именно из-за сахара.

Ну и пусть думают. Если будет нужно - они начнут смотреть что и как улучшить, в том числе им подскажут более опытные товарищи. Не будет нужно - ну и хрен с ним с этим оверхедом, значит он ни на что не влияет.

и что с ним? можешь привести пример, где неравнозначность проявляет себя?

compile-type checking, хотя тебе вроде на него вообще наплевать.

это ты не хочешь понять, что это аналог new из c++

new не полный аналог. Ну и большая часть переменных - это либо локальные, либо члены класса. И, кстати, ты ведь понимаешь какой оверхед ты получаешь используя objc в таких случаях? ;)

И, кстати, ты ведь понимаешь какой оверхед ты получаешь используя objc в таких случаях? ;)

да

Подскажите пожалуйста, в чем будет отличие в плане размещения в памяти этих трех строк:

#include <stdio.h>

int main() {
  printf("It's Friday, Friday\n");
  char *s1 = "Gotta get down on Friday\n";
  printf(s1);
  char s2[] = "Everybody's lookin' forward to the weekend, weekend\n";
  printf(s2);
}

параметр и s1 в .rodata, s2 на стеке

очевидно же

А если к s1 и s2 добааить static или const, их дислокация изменится

Это вопрос был? const никак не повляет, static на s2 определенно да. s2 будет в .data. Собственно, и s1 переедет в .data, но т.к. s1 - указатель, на строку это никак не повлияет.

Спасибо, теперь понятно

прочитать

Спасибо. Узнал много нового

int A[5] = { [2] = 10, [4] = 20 }; /* C99, не C++ */

Такой код нормально компилируется свежим GCC, но далеко не все компиляторы умеют компилировать C99 (Visual Studio не умеет), а главное это не является корректным кодом на C++, поэтому вряд ли стоит использовать такую инициализацию.

C99 (Visual Studio не умеет)

давно в анабиозе?

Это отрывок из вышеприведенной методички. Там на каждой странице «мудрость» автора, способная разжечь холивар

не подскажешь текущее состояниие MSVS?

Внезапно, стрингбилдер создается внутри цикла, точно так же как внутри цикла вызывается .toString(). Т.е. толку в этом коде от стрингбилдера ровно 0. Анонимус конечно криво выразился, но никто не вынес создание стрингбилдера из цикла, а значит по-прежнему в цикле будет создаваться новый char[] и копироваться в него все предыдущее содержимое.

//извиняюсь за некропостинг