Потому что нафига это в стандарте языка?

Вот ему лучше помоги.

Потому что это удобно, и не сделать никак, не меняя сам язык. Сделали же {}. И в других языках такое есть.

Давай Qt в стандарт добавим?

QJsonObject object
{
    {"property1", 1},
    {"property2", 2}
};

Я же не json предлагаю добавлять в стандарт. И в этом примере та же проблема - не отличить список от пары ключ-значение.

если каждый будет рукоблудить свои «удобства» в стандарт, грош цена такому стандарту

Чем отличается «рукоблудие каждого» от того, что туда уже добавили? initializer_list и range for тоже ничегокроме удобства не дают. Авторы C# и Python, которые добавили аналогичную конструкцию в эти языки - идиоты?

Не надо ничего изобратеть:

auto root = jsonObject{{"key1", 1},
                       {"key2", 2},
                       {"key3", jsonArray{1, 2, 3}}}

Вам бы всё лишь бы что-нибудь расширить

#include <map>
#include <string>
#include <iostream>
#include <sstream>

class JSON {
protected:
   std::map<std::string, std::string> fields;

public:
   JSON& operator() (const std::string &k, const std::string &v) {
      fields[k] = "\"" + v + "\"";
      return *this;
   }

   JSON& operator() (const std::string &k, const JSON &j) {
      fields[k] = j.str();
      return *this;
   }

   std::string str() const {
      std::stringstream ofs;
      auto it = fields.begin();
      ofs << "{ " << "\"" << it->first << "\" : " << it->second;
      ++it;
      for (; it != fields.end(); ++it) {
         ofs << ", \"" << it->first << "\" : " << it->second;
      }
      ofs << " }";
      return ofs.str();
   }
};

inline JSON j() {
   return JSON();
}

int main(int argc, char *argv[]) {
   JSON json = j()
      ("foo", "bar")
      ("LOR", "tort")
      ("nested", j()
       ("works", "fine")
       ("so",    "good"));

   std::cout << json.str() << std::endl;
   return 0;
}

$ ./a.out 
{ «LOR» : «tort», «foo» : «bar», «nested» : { «so» : «good», «works» : «fine» } }

Ну вот, с brace initializers даже лучше :)

норм

auto root = jsonObject{jsonArray{{"key1", 1},
                       {"key2", 2},
                       {"key3", jsonArray{1, 2, 3}}}}

Тогда уж по этой логике. Если объект строится побольше и посложнее, количество jsonArray начнет превышать все пределы, вместо простого и лаконичного двоеточия.

А еще хочу property в C++.

object это последовательность пар ключ-значение, array — последовательность значений. Так что не надо там ничего добавлять. Названия можно укоротить и запихнуть в нэймспейс, макросами можно вообще «красивые» сокращения сделать.

ЗЫ. Недавно на initializer list сделал DSL для парсера сообщений HL7 2.6, вообще норм вышло :)

Решил сделать свою библиотеку для работы с json.

Чем не устроили 100500 уже написанных библиотек?

Написал же, они не исользуют современные фичи C++ типа списков инициализации, а то и вовсе на C, из-за чего имеют ужасный синтаксис. Хотя тут скинули более менее современную библиотеку, но о ней не знал. Самые популярные - ужас.

иди отсюда в сисярп

Написал же, они не исользуют современные фичи C++ типа списков инициализации

Помимо упомянутой ранее header-only библиотеки есть ещё не такая переусложнённая библиотека от Dropbox.

зачёт

зачем вы делаетет пайтон из крестов?

Нужно больше говна в стандарт! initialization_list-а недостаточно! Нужно больше!

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

key << value

Не, не надо, спасибо. Тот же initializer_list и так гвоздями к std прибит, что вообще дикость. Подобного нам не надо.

initializer_list и range for тоже ничегокроме удобства не дают.

Делают из uniform initialization syntax совсем не uniform.

И как это сделать, допустим, если и key и value - стандартные типы?

Никак.

Развиваем тему

Еще из хотелок по C++: более продвинутый автовывод типов. Как это точно формализовать, надо подумать. Пример:

std::vector<Very<Long, Useless::Template<Class>>> vect;
//...
std::copy(vect.cbegin(), vect.cend(), std::ostream_iterator<Very<Long, Useless::Template<Class>>>(stream));

std::vector<Very<Long, Useless::Template<Class>>> vect;
//...
std::copy(vect.cbegin(), vect.cend(), std::ostream_iterator<auto>(stream));

Компилятор же знает, какой тип будут передавать ostream_iterator

Откуда?

Сейчас возможно полное создание proxy-объекта, значит можно сделать и property самому. Осталось только определиться с требованиями.

А зачем они тебе?

Как сделать, чтобы proxy-объект с auto и теплейтными параметрами правильно работал?

Почему тебя смущает, что он имеет другой тип? Это более правильно, ведь проперти имеют атрибуты доступа и пр.

Странный вопрос, потому что он это компилирует и располагает полной информацией о типах. И если ты в этом шаблоне поставишь что-то другое, выдаст ошибку.

Потому что, когда я пишу auto t = foo.p;, то меня не должно волновать что там, свойство или нет. В этом же суть пропертей, иначе они не нужны просто.

Еще нужно будет явное приведение писать при передачи в темплейтный аргумент.

Если случайно эту фигную куда-то как сырые данные отправить - вообще плохо будет.

Кстати, у get/set-методов этих проблем нет, хотя у них тоже атрибуты доступа и пр.

Можно функцию сделать на подобии make_unique. Для них вывод типов работает.

С сайд эффектами тоже все неоднозначно будет.

А еще с приведением типов - не получится сделать приведение к ссылке на тип, иначе теряются все get/set.

void f(int& arg);
//...
f(t.foo); //никак не получится

Все правильно же.

В смысле? rvalue не передать, а lvalue возвращать - теряем суть проперти.

Что-то я не понял. t.foo - rvalue. Его нельзя передавать в void f(int& arg);

Так я об этом и говорю. Хочется, что бы каст к lvalue тоже был, но его с прокси-объектом не реализовать.

Шта. Висячая ссылка получится.

www.linux.org.ru/forum/linux-org-ru/11689302?lastmod=1433956693356

Я об этом и говорю, что в текущей реализации не получится ничего хорошего из этого.

Уйди, писюн конский.

Там ведь внутри вызов функции. Если явно написать ее типом int&, то все будет работать. Иначе это rvalue и все правильно. В гипотетических пропертях на уровне языка так же должно быть.

Так в том и дело, что у методов доступ внешний. А проперти само имеет разные доступы: как минимум для чтения и для записи.

Потому что, когда я пишу auto t = foo.p;, то меня не должно волновать что там, свойство или нет.

А почему тебя это волнует? Ну будет там не int, а property<int, ...>, который, когда нужно, кастанется в int...

Зато можно писать:

auto t = foo.p;
...
t = ...; // меняем foo.p

Так и не должно быть. Даже если ты в язык проперти протащишь. Ведь если ты определил get/set, то вызывать нужно их, а не обычную запись в память. Откуда кампилятору при компиляции f об этом знать?

Это не проперти. Они не решают проблему с кучей get/set-функций.

Зато можно писать:

Я не спорю, это может понадобится, но это вообще не замена get/set-функциям.

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

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

Это не проперти. Они не решают проблему с кучей get/set-функций.

Вполне решают. Можно более реальный пример, где они не работают?

И вполне себе проперти, почему нет?

потому что нефиг поощрять смешение данных с кодом, это плохой стиль

C++

ой, простите, что это я. всё хорошо, одобряю

template <typename T>
void foo(T t) {
  // код для всех типов
}

template <>
void foo(bool t) {
  // код для bool
}

// ...

struct Obj {
  bool getV() const;
  Get<Obj, bool, &Obj::getV> v;
} obj;

bool Obj::getV() {
  std::cout << "getV!" << std::endl; // тут может быть кеширование, запись в лог, много чего может быть.
  return true;
}

// ...

foo(obj.getV()); // get - вызов второй функции
foo(obj.v); // property - вызов первой функции

// ...

auto a = obj.getV(); // вызов getV
if(p1(a) && p(a)) { /* .. */ }

auto b = obj.v; // getV не вызван
if(p1(b) && p(b)) { /* .. */ } // getV вызван два раза! Ленивость!

Не заменяет get/set, вообщем.

А за неявное приведение вообще убивать.