тут вопрос про бустовый проперти_три

ну работает

пишет читает, перформанс не тестил - не для этого оно

я просто пользовался всегда другими либами. Надо будет тестить, авторам написать

потому что меня уже раздражает, почему мы не имеем либ для работ с такими форматами в станадртной либе

Вот что там плохо, так это BOOST_FOREACH

по назначению

я лично его пользовал только раз чтобы конфиги при старте читать из xml. тоже проблем не заметил

если перетягивать в стандарт, то это дело легко фиксится

Хотя пишут, что обычный for each должен работать

я лично его пользовал только раз чтобы конфиги при старте читать из xml. тоже проблем не заметил

да, для конфигов он более менее, опять же может читать xml, json И ini

Хотя пишут, что обычный for each должен работать

Он вроде как удовлетворяет требованиям к стандартным контейнерам, так что в 11 можно даже новый for использовать

И пользовательские конвертеры можно писать

да-да, неплохая знаю это. Сейчас пытаюсь связаться с авторами либы, чтобы узнать, что они думают по этому поводу

А вот по производительности ничего не скажу

Производительность так себе :) Но там можно очень много чего хорошего накрутить для лучшей производительности (там rvalue references сейчас даже не поддерживаются)

так что требует серьёзной модернизации

Производительность так себе :) Но там можно очень много чего хорошего накрутить для лучшей производительности (там rvalue references сейчас даже не поддерживаются)

не можешь подсказать насчёт поддерживаемости в настоящий момент? Я отправил письмо мейнтейнеру, но я что-то не припомню никакой активности от мейнтейнера проперти_три

Давно небыло активности: "Latest commit 29a7f03 on 8 Oct 2016" https://github.com/boostorg/property_tree

https://github.com/boostorg/property_tree/pull/7 ну год назад они еще реагировали

ой, это уже ДВА года назад, епт

по хорошему им бы свой json (де)сериализатор выкинуть и взять нормальный

предложение огонь! Если вы сделаете обёртку над нормальным десереилизатором, чтобы он выдавал результат в property_tree - будет оч круто!

если активность была два года назад, то как же в бусте тогда либу держат? там же политика - у каждой либы должен быть активный мейнтейнер

ну либа собирается, тесты проходит

новый функционал просто не пилится

предложение огонь! Если вы сделаете обёртку над нормальным десереилизатором, чтобы он выдавал результат в property_tree - будет оч круто!

такая обёртка имеет право быть добавленной к property_tree?

ну как бы ломаться то пока что не откуда. Более чем уверен, что если либу погонять fuzzингом, зарепортить багов, то они просто останутся висеть

идея хранить всё в едином дереве реально замечательная. Но вот я боюсь, что либа в текущем состоянии реально скорее мертва, чем жива

да там висит пулл реквестов гора уже

может мейнтейнера пнуть напрямую?

я уже пнул

предложение огонь! Если вы сделаете обёртку над нормальным десереилизатором, чтобы он выдавал результат в property_tree - будет оч круто!

по идее прямо в сам pt это совать необязательно, можно задекаплить сторадж от внутреннего представления pt

мне кажется, что просто стоит поднять вопрос о том, насколько мейнтейнер активен сейчас

ну чуда от этого действия ожидать не стоит: из-за того что менйтейнер не активен, люди не бросятся фиксить, чинить и улучшать библиотеку.

ну чуда от этого действия ожидать не стоит: из-за того что менйтейнер не активен, люди не бросятся фиксить, чинить и улучшать библиотеку.

как реашается вопрос в бусте с неактивными мейнтенерами?

надо предложить себя мейнтейнером на замену

хехе )

как реашается вопрос в бусте с неактивными мейнтенерами?

Библиотека переходит в поддержку <не-помню-как-наывазется-группа-из-топовых-челов-буста>. Они фиксят критические вещи, стараются найти нового maintainer и принимают пулл реквесты. Допиливанием фичей как правило не занимаются.

Библиотека переходит в поддержку <не-помню-как-наывазется-группа-из-топовых-челов-буста>. Они фиксят критические вещи, стараются найти нового maintainer и принимают пулл реквесты. Допиливанием фичей как правило не занимаются.

как ты думаешь, стоит ли поднять вопрос о активности мейнтейнеров проперти_три?

поспрашивай в бустовой рассылке. Но по хорошему нужно найти нового maintainer, если старый сдулся

надо предложить себя мейнтейнером на замену

Да без проблем Просмотрите ревью реквесты и открытые баги. Исправлйте. Как накопится приличное количество правок и народ убедится в вашей компетентности - станете мейнтенйнером

это вон Александру скорее

это вон Александру скорее

я то в принципе могу попробовать стать мейнтейнером либы. Поправить баги и так далее - либа то действительно полезная и есть шанс, что её можно в будущем перетянуть в стандарт, игнорируя недочеловеков в стандарте, которые не считают, что работа с json && xml в 2017 году - частая задача

но тут вопрос будет стоять в доказывании людям, что я являюсь компетентным ?

а зачем такое тянуть в стандарт?

а зачем такое тянуть в стандарт?

а что не так?

Это же не камильфо, std должна быть минималистичной (имхо), работа с json xml это явно не то, чем разработчик занимается каждый день.

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

Это же не камильфо, std должна быть минималистичной (имхо), работа с json xml это явно не то, чем разработчик занимается каждый день.

ещё один. Тебе надо пива выпить с ubsan в Слаке

окей, я приведу тебе такой же пример, как и вчера. У меня проект, десктпное приложение под винду, где не используется ни разу сортировка, но есть куча работы с JSON && XML

ну нельзя на одном примере делать такие выводы

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

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

ну нельзя на одном примере делать такие выводы

добавляю аналогичный пример, только проект легаси и использую json-glib и xerces, чему не рад вообще

ну таким образом, при бесконечном количестве времени, в плюсах бы оказались все, когда-либо написанные либы

и поиск левых велосипедов - зачем мне это? Я свалю с одного проекта на другой,там будет другая либа по работе с тем же форматом, и мне снова что-то учить надо

добавляю аналогичный пример, только проект легаси и использую json-glib и xerces, чему не рад вообще

Мы тоже юзаем xerces, только для json юзаем jsonpp вроде как

добавляю аналогичный пример, только проект легаси и использую json-glib и xerces, чему не рад вообще

+1. Из последнийх 2х проектах в обоих нужен был json

ну таким образом, при бесконечном количестве времени, в плюсах бы оказались все, когда-либо написанные либы

Сейчас слложно представить проект где не надо парсить json или xml

Таким же образом можно сказать, что зачем нам нетворкинг

ну таким образом, при бесконечном количестве времени, в плюсах бы оказались все, когда-либо написанные либы

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

ну уйдёт json, придут другие форматы, а нетворкинг вечен как аллах

Таким же образом можно сказать, что зачем нам нетворкинг

например на моей работе нетворкинг вооооооообще не нужен абсолютно

ну уйдёт json, придут другие форматы, а нетворкинг вечен как аллах

лол, вечен. ну-ну

Но с другой стороны то, что добавляется в стандарт мягко говоря теряет гибкость. Взять хотя бы std::future. Любая сторонняя библиотека за то же время продвинулась бы куда сильнее.

а зачем такое тянуть в стандарт?

Про filesystem тоже так говорили и вот дожили до 2017 года без нормальной работы с файлововой системой. Сдуреть же можно. Базовые вещи. Иерархические структуры данных - это тоже базовые вещи. Чем полнее стандартная библиотека, тем проще использовать язык.

ERROR: S client not available

ну уйдёт json, придут другие форматы, а нетворкинг вечен как аллах

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

Суть в том, что std должен по идее идти в ногу со временем

так С++ не для простых ребят

Уверен, пройдет немного времени, и ML будет включен в стандарт той же жабы

Суть в том, что std должен по идее идти в ногу со временем

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

так С++ не для простых ребят

так пора бы уже выбросить эту тупую идею из головы. Он для простых парней!

так С++ не для простых ребят

А для кого? Непростым ребятам тоже часто нужен JSON и кроссплатформенная работа с файловой системой :)

но тут вопрос будет стоять в доказывании людям, что я являюсь компетентным ?

1. fork boostorg/property_tree 2. fix 17 pending PRs

Вообще на самом деле не было бы таких проблем, если бы включили пакетирование

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

Не понимаю, почему это должно быть в std. Язык должен отвечать современным требованиям, но он не должен быть сборищем популярных библиотек. Это же всё решается git clone. В общем, был бы я в комитете, не одобрил бы.

Вообще на самом деле не было бы таких проблем, если бы включили пакетирование

ждём-с...

Вообще на самом деле не было бы таких проблем, если бы включили пакетирование

так и я о чём

ну уйдёт json, придут другие форматы, а нетворкинг вечен как аллах

не по комменту, но если внести в стандарт работу с XML, то это решило бы множество проблем и не надо было бы писать миллионы трансформеров

Если подключение либы это не танцы с бубнами с 90% случаев, то все бы забили на недостаток std и юзали кастомные либы

двачаю господину выше

Если подключение либы это не танцы с бубнами с 90% случаев, то все бы забили на недостаток std и юзали кастомные либы

Даёшь модули!

Даёшь единый пакетник!

Через 3 года посмотрим)

Еще год на поддержку

Еще год на наполнение

Один пакетник! Один репозиторий! Один язык!

Не понимаю, почему это должно быть в std. Язык должен отвечать современным требованиям, но он не должен быть сборищем популярных библиотек. Это же всё решается git clone. В общем, был бы я в комитете, не одобрил бы.

Решается git clone? хаха. В нашем проекте cmake-конфигурация 100500 тыщ строк какой-то магической хрени!

Не понимаю, почему это должно быть в std. Язык должен отвечать современным требованиям, но он не должен быть сборищем популярных библиотек. Это же всё решается git clone. В общем, был бы я в комитете, не одобрил бы.

1) Распространять либы через git clone - ужос какой. Conan юзай хотя бы 2) Левые либы - а зачем мне что-то мне тащить? почему я не могу это иметь из-коробки? почему я должен лишаться гарантий стандарта? Левая либа в любой момент может поломать мне всё к чертям. Например, в новой версии попрявят важный для меня баг и попутно отрефакторят интерфейсы,чем поломают мне обратную совсеместимость в 20 вещах. И вот что мне делать в данном случае?

не по комменту, но если внести в стандарт работу с XML, то это решило бы множество проблем и не надо было бы писать миллионы трансформеров

+

std должна быть минималистично и очень хорошо продуманной. Куда проще сделать модификации в сторонней либе, чем ждать следующего стандарта. Я не против того, чтобы в std было все. Вопрос в том откуда это все надлежащего качества взять.

1) Распространять либы через git clone - ужос какой. Conan юзай хотя бы 2) Левые либы - а зачем мне что-то мне тащить? почему я не могу это иметь из-коробки? почему я должен лишаться гарантий стандарта? Левая либа в любой момент может поломать мне всё к чертям. Например, в новой версии попрявят важный для меня баг и попутно отрефакторят интерфейсы,чем поломают мне обратную совсеместимость в 20 вещах. И вот что мне делать в данном случае?

блин, ну про git clone я утрировал по второму, ты же в любом случае юзаешь левые решения, тот же буст

std должна быть минималистично и очень хорошо продуманной. Куда проще сделать модификации в сторонней либе, чем ждать следующего стандарта. Я не против того, чтобы в std было все. Вопрос в том откуда это все надлежащего качества взять.

двачаю

блин, ну про git clone я утрировал по второму, ты же в любом случае юзаешь левые решения, тот же буст

а ты не докагыдваешься, почему я юзаю буст?

1) Распространять либы через git clone - ужос какой. Conan юзай хотя бы 2) Левые либы - а зачем мне что-то мне тащить? почему я не могу это иметь из-коробки? почему я должен лишаться гарантий стандарта? Левая либа в любой момент может поломать мне всё к чертям. Например, в новой версии попрявят важный для меня баг и попутно отрефакторят интерфейсы,чем поломают мне обратную совсеместимость в 20 вещах. И вот что мне делать в данном случае?

Мы же не модый язык. Так заведено, что у всех все свое. Своя атмосфера. Хочешь, ебани свое

1) Распространять либы через git clone - ужос какой. Conan юзай хотя бы 2) Левые либы - а зачем мне что-то мне тащить? почему я не могу это иметь из-коробки? почему я должен лишаться гарантий стандарта? Левая либа в любой момент может поломать мне всё к чертям. Например, в новой версии попрявят важный для меня баг и попутно отрефакторят интерфейсы,чем поломают мне обратную совсеместимость в 20 вещах. И вот что мне делать в данном случае?

Писать свою либу, конечно. </sarcasm>

std должна быть минималистично и очень хорошо продуманной. Куда проще сделать модификации в сторонней либе, чем ждать следующего стандарта. Я не против того, чтобы в std было все. Вопрос в том откуда это все надлежащего качества взять.

Вооот, а вот здесь ты абсолютно прав. Перед включением в стандарт нужно продумать 100500 вещей. Чтобы не запихнуть туда чушь всякую