Здравствуйте, MTD, Вы писали:

MTD>Это не то развитие которого ждет индустрия. С точки зрения ученого да, все классно, средствами языка можно все выразить, невероятная мощь, ребята умные, спору нет, вот только когда нужно просто дом построить им становится неинтересно, слишком приземленно. Нужен инженер, а у инженера интеллектуальные способности несколько иные и потребности отличаются. Инженеру же нужен простой, удобный и быстрый инструмент. Я пробовал использовать Boost.Spirit и в процессе мне постоянно приходилось думать как делать, а не о том, что мне нужно сделать, в то время как yacc прост как палка и понятен.

В случае Spirit'а дело совсем не в том, чтобы выразить всё средствами языка из принципа. Просто такой подход реально обеспечивает гораздо более удобную интеграцию и высокое быстродействие.

MTD>С++ стал популярен, потому что на тот момент времен затачивался под инженеров, а буст в массе пилят ученые, поэтому многие библиотеки из него использует дай бог сотня людей во всем мире.

У меня противоположное мнение. На мой взгляд Boost — это сейчас стандарт де-факто в мире C++. А программисты, использующие вместо него какие-то свои велосипеды, только лишь демонстрируют свою низкую квалификацию.

MTD>Здесь показателен другой язык заточенный под решение практических задач, а потому неплохо выстрелившим, я о Go — недавно Мейл.ру проводил хайлоад кап, так первые строчки все были заняты Go уже через несколько дней, в то время как решения на плюсах появились только где-то к концу второй недели, при этом по быстродействию не сказать, что Go был порван. Вот тебе и соотношение скорость разработки на скорость выполнения.

Ну вот когда рядом с nginx/iis/apache появится с процентами выше стат.погрешнсти какое-то решение на Go, то тогда и поговорим. ))) А так то скажем на PHP можно накидать страничку ещё быстрее, чем на Go, но это ни о чём не говорит.

_>>Ну предложи своё решение данной задачки) Чтобы с такой же краткостью и быстродействием.
MTD>Установить локаль, читать из потока.

Это ты про потоки из стандартной библиотеки языка? Они же дико тормозные — это уже даже на мегабайтах будет ощущаться. Да и даже если забыть о быстродействие, то всё равно подобный код будет намного более громоздким, чем одна короткая строчка на Spirit'е.

MTD>>>Про время компиляции, диагностику ошибок и удобство в поддержке возражений нет? Ок.
_>>Про удобство поддержки очевидно как раз всё наоборот — одна краткая строчка против целого нетривиального файла.
MTD>Что там нетривиального-то? Все просто как палка. А еще для отладки грамматик есть инструменты.

Нетривиально по сравнению с аналогичным решением на Spirit'е.

_>>Время компиляции у меня например не минуты, а секунды (потому что любой профессионал в C++ работает только с помощью эффективных SSD).
MTD>Да SSD сейчас у всех, нашел чем удивить, вот только не панацея это. Реакция людей пересевших, например с С# на плюсы — компиляция подвисла, что делать.

Кстати, это следствие совсем не шаблонов и метапрограммирования, а специфической "модульности" в C/C++. Теоретически это может быть решено после введения нормальных модулей в C++ (опять же ожидалось в C++17). Хотя лично мне решение от Microsoft не очень нравится — там надо дорабатывать.

_>>Просто чтобы было понятно, что преимущество одновременно по всем параметрам (и лаконичность кода и удобство интеграции и итоговое быстродействие).
MTD>Я пока у Spirit не вижу вообще никаких преимуществ кроме идеологических.

Ну похоже что ты просто его никогда не использовал по делу и всё. )))

Здравствуйте, alex_public, Вы писали:

_>У меня противоположное мнение. На мой взгляд Boost — это сейчас стандарт де-факто в мире C++. А программисты, использующие вместо него какие-то свои велосипеды, только лишь демонстрируют свою низкую квалификацию.

От буста, после того, как в стандарт перехала его часть можно и нужно отказываться. Есть конечно вполне ок либы, тот же Asio, но есть куча странных трехколесных велосипедов, типа Format, который использует непонятный синтаксис и при этом дико тормозной http://zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html

_>Ну вот когда рядом с nginx/iis/apache появится с процентами выше стат.погрешнсти какое-то решение на Go, то тогда и поговорим. ))) А так то скажем на PHP можно накидать страничку ещё быстрее, чем на Go, но это ни о чём не говорит.

Ты малость не в теме, конечно http сервер писать на go смысла нет (кстати, он пишется в 10 строк) так как уже есть отличные решения, тот же nginx, но сервера на нем пилят только так. В том же Мейл.ру часть старых проектов переписывают на нем, новые вообще по-моему все на нем начинаются. Вот, кстати, результат упомянутого чемпионата: https://highloadcup.ru/rating/ PHP в топе нет, а Go есть и нормально выглядит рядом с С++ и С.

_>Это ты про потоки из стандартной библиотеки языка? Они же дико тормозные

Ну вот как так? Такой язык мощный, продуманная библиотека и тормоза

_>Кстати, это следствие совсем не шаблонов и метапрограммирования, а специфической "модульности" в C/C++. Теоретически это может быть решено после введения нормальных модулей в C++ (опять же ожидалось в C++17). Хотя лично мне решение от Microsoft не очень нравится — там надо дорабатывать.

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

Здравствуйте, SaZ, Вы писали:

_>>А во-вторых этот вопрос вообще не имеет никакого отношения к нашей дискуссии, т.к. обсуждаемый нами препроцессор вообще никак не связан с упомянутыми особенностями архитектуры, а занят исключительно поддержкой кривой реализации системы сигналов и метаинформацией.
SaZ>Я ещё раз акцентирую мысль. Qt изначально выбрала необходимость кодогенерации. С этим ничего не поделаешь. Но это позволило обеспечить поддержку очень большого зоопарка компиляторов, ещё во времена, когда С++11 даже и не пахло. Я не утверждаю, что нельзя добиться того же поведения без препроцессора на современных стандартах языка. Просто не стоит оно того

Ещё раз повторяю, кодогенерация в Qt не используется для поддержки старых компиляторов. Она используется для:

1. поддержки сигналов, что априори бредово, т.к. все необходимые для этого возможности компиляторы C++ имеют уже много десятилетий.
2. поддержки метаинформации, что наоборот не возможно пока ни в одном компиляторе C++, даже самого последнего стандарта (и это тоже плохо на мой вкус, т.к. является "выходом за пределы языка").

_>>Повторяю уже не первый раз: никаких извращений для поддержки реализации сигналов в C++ не требуется. Это должно бы очевидно каждому, даже после знакомства с языком на уровне статьи из Википедии. Просто потому что в C++ (да и даже в C) указатель на функцию является первоклассной сущностью. Более того, полно готовых (и совсем не новых) библиотек на эту тему (например http://www.boost.org/doc/libs/1_65_1/doc/html/signals2.html), оборачивающих эту базовую возможность языка в удобные ООП конструкции.
SaZ>Ну лично мне намного удобнее объявить
SaZ>void clicked(); вместо boost::signals2::signal<void ()> clicked;

Я думаю всем очевидно, что при использование данной библиотеки никто не будет писать префикс "boost::signals2::". Соответственно особой разницу не видно и даже второй вариант однозначнее выглядит.

SaZ>и
SaZ>connect( источник, метод, приёмник, метод, [тип соединения] ); вместо (из примеров буста) deliverNews.connect(signal_type::slot_type(&NewsMessageArea::displayNews,
SaZ> newsMessageArea.get(), _1).track(newsMessageArea));

Ну да, только у тебя тут для Boost'а полноценная компилируемая строчка со всеми идентификаторами, а для Qt некий упрощённый шаблон применения. Ты напиши полноценный аналог с теми же именами переменных/сигналов/слотов и тогда сравни. )

_>>Жирная не в смысле размера дистрибутива (хотя тут конечно тоже не всё хорошо, но по сравнению со всякими новомодными Электронами и т.п. можно считать что нормально), а в смысле устройства библиотеки.
SaZ>Так чем плохое устройство? Понять принцип сигналов/слотов, который синтаксически проще, чем буст или аналоги. Понять что такое QObject, когда он нужен и модель управления временем жизни объекта (parent/child). Понять, что такое event loop (тоже не вижу проблем, если знаком с разработкой GUI). А остальное — уже по вкусу.

Она плоха тем, что заточена на использование своих убогих велосипедов, вместо общепринятых в языке подходов. Т.е. я не могу просто взять их GUI классы (нужные мне) и использовать в нормальном современном C++ окружение.

_>>Угу, всё приложение в одном убогом Java-стиле. ))) Нет, спасибо, не надо такого "удовольствия". )))
SaZ>А что такое Java стиль? Не понимаю о чём вы.

Современный C++ развивается сейчас в сторону функционального стиля, использования локальных переменных с типами-значениями (отсюда и семантика перемещения), активного использования обобщённого и мета программирования. А засилье ООП, сплошные new/delete и т.п. осталось в C++ далёких 90-ых. Ну и вот в Qt. Кстати, это видно даже по стандарту имён переменных — Qt соответствует классической Java нотации, а не C++. Да и вообще они этого не скрывают (см. например http://doc.qt.io/qt-5.9/containers.html#java-style-iterators).

_>>Ну и кстати все эти не GUI модули (базы, сеть, потоки и т.п.) являются крайне жалкими по сравнению с нормальными современными C++ инструментами в соответствующих областях. Точнее и GUI часть в Qt точно такая же кривая, но у неё просто нет настолько же полнофункциональных аналогов. А вот во всех других областях такие аналоги есть и они на голову выше реализации в Qt.
SaZ>Ну так с базами на C++ в принципе плохо, особенно с универсальными провайдерами. Я кроме QxOrm и SQLAPI ничего внятного не видел. ODB с натяжкой, слишком интрузивный.

Да ладно, из старого же есть очень удобная библиотечка SOCI, умеющая наверное все СУБД. А из нового можно глянуть на sqlpp11, которая имеет полноценную статическую (во время компиляции проекта) проверку синтаксиса SQL, т.е. по сути круче чем Linq (там часть работы в рантайме идёт). Правда последняя пока ещё в какой-то степени экспериментальная и поэтому имеет поддержку только нескольких СУБД.

_>>Я вроде как ясно сказал, что мне от Qt только и нужна эта "малая часть" (GUI).
SaZ>Терпите. Весь мир утонул в необходимости backward compatibility

Вот смотрю я например на эту https://github.com/wjakob/nanogui библиотеку и думаю, что если бы ей добавить:
1. нормальную поддержку unicode.
2. дополнить коллекцию стандартных контролов до классического количества (ну как минимум tree и list то должны быть)
3. реализовать внутренние темы и сделать считывания всех соответствующих настроек оформления системы при старте приложения (данный тупой платформозависимый код можно напрямую взять из Qt) с формированием из них текущей темы для всех контролов.
4. (опционально) сделать визуальный редактор контролов.

То можно было бы спокойно выкидывать Qt на свалку.

_>>Не аргументированные сказки.
SaZ>Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.

Так а чем Boost::signal2 не подходит? )

SaZ>>>Первый пример, который мне пришёл в голову — панель для редактирования свойств объектов. Без рефлексии там пришлось бы писать тонны кода на каждый новый класс. А с рефлекйсией — один раз написали и забыли.
_>>

_>>unordered_map<string, unique_ptr<property_base>> dynamic_properties;
_>>

_>>Ага, тонны кода. Ну да, ну да.
SaZ>Ни о чём код. Мы видимо о разном говорим. Про Spirit и его лаконичность тут где-то рядом уже всё написали.
SaZ>Вопрос был, кто и при помощи каких данных заполнит эту мапу? Без рефлексии — придётся на каждый написанный класс писать ещё метод для заполнения этой мапы. При редактировании класса — чинить этот метод и т.д.

Эм, зачем? Почему нельзя использовать напрямую данные из этой коллекции в этих самых классах? Тем более, что это позволит делать им реально динамические свойства, а не псевдо, как в Qt.

Здравствуйте, alex_public, Вы писали:

_>Ещё раз повторяю, кодогенерация в Qt не используется для поддержки старых компиляторов. Она используется для:

_>1. поддержки сигналов, что априори бредово, т.к. все необходимые для этого возможности компиляторы C++ имеют уже много десятилетий.
_>2. поддержки метаинформации, что наоборот не возможно пока ни в одном компиляторе C++, даже самого последнего стандарта (и это тоже плохо на мой вкус, т.к. является "выходом за пределы языка").

1. Это ничего не меняет. Можно и через кодогенерацию делать. В данном случае нет необходимости менять то, что работает. В Qt6 уже можно будет от этого уйти.
2. Это не выход за пределы языка ни разу. Просто кодогенератор делает за программиста работу — формирует описание структуры класса на С++. На выходе получается чистый С++.

_>Ну да, только у тебя тут для Boost'а полноценная компилируемая строчка со всеми идентификаторами, а для Qt некий упрощённый шаблон применения. Ты напиши полноценный аналог с теми же именами переменных/сигналов/слотов и тогда сравни. )

В Qt один метод — QObject::connect. Там в любом случае 5 или меньше аргументов. Причём никакие аргументы не нужно заворачивать ни в какие врапперы.

_>Она плоха тем, что заточена на использование своих убогих велосипедов, вместо общепринятых в языке подходов. Т.е. я не могу просто взять их GUI классы (нужные мне) и использовать в нормальном современном C++ окружение.

Ну так в чём проблема — сделайте свои GUI классы и используйте. Никто ведь не заставляет. Проблема лишь в том, что у ребят из Qt это уже есть и работает. Причём работает очень хорошо и гибко.

_>Современный C++ развивается сейчас в сторону функционального стиля, использования локальных переменных с типами-значениями (отсюда и семантика перемещения), активного использования обобщённого и мета программирования. А засилье ООП, сплошные new/delete и т.п. осталось в C++ далёких 90-ых. Ну и вот в Qt. Кстати, это видно даже по стандарту имён переменных — Qt соответствует классической Java нотации, а не C++. Да и вообще они этого не скрывают (см. например http://doc.qt.io/qt-5.9/containers.html#java-style-iterators).

Современный С++ как раз таки мультипарадигмный. И это его достоинство подчёркивается его разработчиками. К тому же Qt сами сказали, что с новым стандартом лучше использовать STL вместо собственных Qt-шных классов, где это возможно. И они по максимуму стали вводить поддержку STL. А раньше, вместо мув семантики у них была очень хорошая реализация COW для всех внутренних типов. new/delete уже никто не использует, всюду есть RAII. Стандарт имён переменных — дело каждого конкретного проекта. Лично мне нравится, что в Qt код выдержан в одном стиле. Причём мне не важно в каком. Под стиль подстраиваешься за пару месяцев работы над проектом.

_>Да ладно, из старого же есть очень удобная библиотечка SOCI, умеющая наверное все СУБД. А из нового можно глянуть на sqlpp11, которая имеет полноценную статическую (во время компиляции проекта) проверку синтаксиса SQL, т.е. по сути круче чем Linq (там часть работы в рантайме идёт). Правда последняя пока ещё в какой-то степени экспериментальная и поэтому имеет поддержку только нескольких СУБД.

Вот именно, экспериментальная. А в Qt это работает давно и хорошо, даже на С++03 компиляторах на слабом железе. Ещё раз — не нужно сравнивать Qt со свежими библиотеками, которые писались сразу под C++11. Придёт время и необходимость — они всё отрефакторят.

_>Вот смотрю я например на эту https://github.com/wjakob/nanogui библиотеку и думаю, что если бы ей добавить:
_>1. нормальную поддержку unicode.
_>2. дополнить коллекцию стандартных контролов до классического количества (ну как минимум tree и list то должны быть)
_>3. реализовать внутренние темы и сделать считывания всех соответствующих настроек оформления системы при старте приложения (данный тупой платформозависимый код можно напрямую взять из Qt) с формированием из них текущей темы для всех контролов.
_>4. (опционально) сделать визуальный редактор контролов.
_>То можно было бы спокойно выкидывать Qt на свалку.

Qt ещё долго на свалку не пойдёт. Вот когда их библиотека сможет без тормозов показывать списки на пару миллионов записей и когда там в пару строк кода можно будет писать кастомные контролы — тогда да, можно будет использовать.

SaZ>>Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.
_>Так а чем Boost::signal2 не подходит? )

При беглом гуглении не нашёл простой возможности сказать, в каком потоке выполнять слот. И не нашёл примеров цикла обработки сообщений.

_>Эм, зачем? Почему нельзя использовать напрямую данные из этой коллекции в этих самых классах? Тем более, что это позволит делать им реально динамические свойства, а не псевдо, как в Qt.

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

Здравствуйте, MTD, Вы писали:

_>>У меня противоположное мнение. На мой взгляд Boost — это сейчас стандарт де-факто в мире C++. А программисты, использующие вместо него какие-то свои велосипеды, только лишь демонстрируют свою низкую квалификацию.
MTD>От буста, после того, как в стандарт перехала его часть можно и нужно отказываться. Есть конечно вполне ок либы, тот же Asio, но есть куча странных трехколесных велосипедов, типа Format, который использует непонятный синтаксис и при этом дико тормозной http://zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html

Ну по поводу элементом переехавших из Boost в стандартную библиотеку, я естественно тоже сразу стал использовать только их. Но при этом там до сих пор осталось очень много разных вкусностей. И законченных решений глобальных "доменных" вещей типа Spirit, Asio, MSM, обёртки OpenCL и MPI, полноценной работы с юникодом, логирования, юнит-тестов, сереализации, интеграции с Python. И классных технологий, дорабатывающих язык, типа Coroutine/Fibers, Type Erasure, метапрограммирования (Metaparse, Hana, MPL, Fusion, Proto, плюс отдельно библиотеки поддержки стандартного препроцессора PP и VMD), Range (будет реально актуально после включения концептов во всех компиляторах). И просто множество готовых удобных реализаций небольших известных программистских задач: дополнительные алгоритмы и crc, различные контейнеры в стиле STL (включая lock-free, интрузивные, графы, пулы, многомерные и ещё куча всего — я даже не пробовал их все), различная математика (статистика, геометрия, кватернионы, числа произвольной точности, рациональные числа, линейная алгебра, диф.уравнения, размерности), кроссплатформенная поддержка IPC/динамических библиотек/процессов, стандартный разбор командной строки, хранение иерархических конфигов. И всё это качественный код, написанный в стиле современного C++!

Да, и по поводу твоей ссылки (кстати откуда ты её взял интересно? Просто я буквально на днях кидал её прямо на этом форуме)... А тебя не смущает, что там среди лидеров по быстродействию значится тот самый Spirit, на который ты "наезжал"? )))

_>>Ну вот когда рядом с nginx/iis/apache появится с процентами выше стат.погрешнсти какое-то решение на Go, то тогда и поговорим. ))) А так то скажем на PHP можно накидать страничку ещё быстрее, чем на Go, но это ни о чём не говорит.
MTD>Ты малость не в теме, конечно http сервер писать на go смысла нет (кстати, он пишется в 10 строк) так как уже есть отличные решения, тот же nginx, но сервера на нем пилят только так. В том же Мейл.ру часть старых проектов переписывают на нем, новые вообще по-моему все на нем начинаются. Вот, кстати, результат упомянутого чемпионата: https://highloadcup.ru/rating/ PHP в топе нет, а Go есть и нормально выглядит рядом с С++ и С.

Вот открываем твою же ссылку и видим там сплошное засилье C/C++. Одинокая Java на 12-ом месте и одинокий Go на 15-ом. Как-то странно это соотносится с твоими же словами. )))

_>>Это ты про потоки из стандартной библиотеки языка? Они же дико тормозные
MTD>Ну вот как так? Такой язык мощный, продуманная библиотека и тормоза

Ну для целей взаимодействия с пользователем в консоли они подходят отлично. ) А для всего остального лучше использовать более эффективные способы. )

_>>Кстати, это следствие совсем не шаблонов и метапрограммирования, а специфической "модульности" в C/C++. Теоретически это может быть решено после введения нормальных модулей в C++ (опять же ожидалось в C++17). Хотя лично мне решение от Microsoft не очень нравится — там надо дорабатывать.
MTD>Вот, хороший пример когда всякая чухня идет в стандарт, а действительно важные вещи (корутины, файловая система, модули) задвигается на потом. Об этом я и говорю — оторванные от реальности ученые рулят, а то что надо инженерам — на то положить.

Так файловую систему же приняли. Модули не приняли и я с этим согласен. В том смысле что они конечно нужны, но пока действительно хорошей системы не видно. А вот насчёт корутин поддерживаю — жаль не приняли (причём я бы предпочёл в начале получить stackfull решение, а не проталкиваемое MS не очень нужное решение из C#). Но они в принципе и сейчас работают (просто в виде библиотек), так что не проблема. А вот концепты и интроспекцию через библиотеки не реализуешь, так именно эти две вещи мне жаль больше всего. Ну будем надеяться что к C++20 всё же смогут договориться.

Здравствуйте, SaZ, Вы писали:

_>>Современный C++ развивается сейчас в сторону функционального стиля, использования локальных переменных с типами-значениями (отсюда и семантика перемещения), активного использования обобщённого и мета программирования. А засилье ООП, сплошные new/delete и т.п. осталось в C++ далёких 90-ых. Ну и вот в Qt. Кстати, это видно даже по стандарту имён переменных — Qt соответствует классической Java нотации, а не C++. Да и вообще они этого не скрывают (см. например http://doc.qt.io/qt-5.9/containers.html#java-style-iterators).
SaZ>Современный С++ как раз таки мультипарадигмный. И это его достоинство подчёркивается его разработчиками. К тому же Qt сами сказали, что с новым стандартом лучше использовать STL вместо собственных Qt-шных классов, где это возможно. И они по максимуму стали вводить поддержку STL. А раньше, вместо мув семантики у них была очень хорошая реализация COW для всех внутренних типов. new/delete уже никто не использует, всюду есть RAII. Стандарт имён переменных — дело каждого конкретного проекта. Лично мне нравится, что в Qt код выдержан в одном стиле. Причём мне не важно в каком. Под стиль подстраиваешься за пару месяцев работы над проектом.

Я в курсе, что разработчики Qt тоже понемногу пытаются смещаться в направление основного вектора развития современного C++. Однако пока у них в этом сделаны только самые начальные шаги и библиотека по прежнему больше напоминает продукт из мира Java.

_>>Да ладно, из старого же есть очень удобная библиотечка SOCI, умеющая наверное все СУБД. А из нового можно глянуть на sqlpp11, которая имеет полноценную статическую (во время компиляции проекта) проверку синтаксиса SQL, т.е. по сути круче чем Linq (там часть работы в рантайме идёт). Правда последняя пока ещё в какой-то степени экспериментальная и поэтому имеет поддержку только нескольких СУБД.
SaZ>Вот именно, экспериментальная. А в Qt это работает давно и хорошо, даже на С++03 компиляторах на слабом железе. Ещё раз — не нужно сравнивать Qt со свежими библиотеками, которые писались сразу под C++11. Придёт время и необходимость — они всё отрефакторят.

Я же вроде как ясно всё написал. Хочешь под старый компилятор и не экспериментальную — бери SOCI.

_>>Вот смотрю я например на эту https://github.com/wjakob/nanogui библиотеку и думаю, что если бы ей добавить:
_>>1. нормальную поддержку unicode.
_>>2. дополнить коллекцию стандартных контролов до классического количества (ну как минимум tree и list то должны быть)
_>>3. реализовать внутренние темы и сделать считывания всех соответствующих настроек оформления системы при старте приложения (данный тупой платформозависимый код можно напрямую взять из Qt) с формированием из них текущей темы для всех контролов.
_>>4. (опционально) сделать визуальный редактор контролов.
_>>То можно было бы спокойно выкидывать Qt на свалку.
SaZ>Qt ещё долго на свалку не пойдёт. Вот когда их библиотека сможет без тормозов показывать списки на пару миллионов записей и когда там в пару строк кода можно будет писать кастомные контролы — тогда да, можно будет использовать.

Забавно, что перечисленное тобой скорее всего уже работает в этой библиотечке. ))) Но ты прав, что эта библиотека ещё не готова к нормальному использованию (хотя бы по перечисленным мною пунктам). К большому сожалению...

SaZ>>>Ну так я и говорю — дайте пример нормальных сигналов/слотов с многопоточностью под C++03.
_>>Так а чем Boost::signal2 не подходит? )
SaZ>При беглом гуглении не нашёл простой возможности сказать, в каком потоке выполнять слот. И не нашёл примеров цикла обработки сообщений.

Интеграция циклов обработки сообщений и т.п. — это специфика или GUI библиотек или специализированных инструментов в этой области (типа Boost::Asio или libuv). Boost::signal2 безопасна для использования в многопоточном коде, а вот перекидывания потоков исполнения между потоками и циклами обработки сообщений — это уже задача отдельных инструментов (потому как там может быть не просто какой-то поток, а например асинхронная сопрограмма).

_>>Эм, зачем? Почему нельзя использовать напрямую данные из этой коллекции в этих самых классах? Тем более, что это позволит делать им реально динамические свойства, а не псевдо, как в Qt.
SaZ>Потому что коллекцию надо сначала заполнить. Вы так и не объяснили, кто будет заполнять коллекцию свойств. В Qt это делается через рефлексию с интроспекцией.
SaZ>В Qt тоже есть динамические свойства, которые можно создавать в рантайме.

Так, ты похоже не понимаешь очевидную концепцию. Ну вот приведи пример конкретного кода, про который ты говорил и я тебе покажу о чём речь. )))

Здравствуйте, alex_public, Вы писали:

_>Да, и по поводу твоей ссылки (кстати откуда ты её взял интересно? Просто я буквально на днях кидал её прямо на этом форуме)... А тебя не смущает, что там среди лидеров по быстродействию значится тот самый Spirit, на который ты "наезжал"? )))

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

_>Вот открываем твою же ссылку и видим там сплошное засилье C/C++. Одинокая Java на 12-ом месте и одинокий Go на 15-ом. Как-то странно это соотносится с твоими же словами. )))

Так отрыв незначительный, зато скорость разработки раза в 2 выше, так что все ок.

Здравствуйте, alex_public, Вы писали:

_>...
_>Так файловую систему же приняли...

И что, ей реально интенсивно пользуются? Везде, где нужно интенсивно работать с файлами — пишутся собственные платформозависимые обвёртки. Уж очень много нет в filesystem.

Здравствуйте, MTD, Вы писали:

_>>Да, и по поводу твоей ссылки (кстати откуда ты её взял интересно? Просто я буквально на днях кидал её прямо на этом форуме)... А тебя не смущает, что там среди лидеров по быстродействию значится тот самый Spirit, на который ты "наезжал"? )))
MTD>Хорошая либа, пользуюсь, потому и ссылку дал, а к Spirit у меня претензии не из-за быстродействия, а из-за неудобства использования.

Хорошая либа — это ты про какую?
Что касается неудобства Spirit'а, то я не вижу никакой принципиальной разницы между:

sprintf(s, "%i", i);

и вариантом из Spirit'а

generate(s, int_, i);

при том что последний ещё и гарантирует проверку соответствие формата компилятором. И оба эти варианта гораздо симпатичнее канонического:

stringstream ss;
ss<<i;
s=ss.str();

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

s=to_string(i);

Но у него к сожалению нулевые возможности по форматированию.

_>>Вот открываем твою же ссылку и видим там сплошное засилье C/C++. Одинокая Java на 12-ом месте и одинокий Go на 15-ом. Как-то странно это соотносится с твоими же словами. )))
MTD>Так отрыв незначительный, зато скорость разработки раза в 2 выше, так что все ок.

Так откуда у тебя данные то про скорость разработки в 2 раза выше? ) И как ты себе это вообще представляешь на статическом языке, не поддерживающем обобщённое программирование? )

Здравствуйте, SaZ, Вы писали:

_>>Так файловую систему же приняли...
SaZ>И что, ей реально интенсивно пользуются? Везде, где нужно интенсивно работать с файлами — пишутся собственные платформозависимые обвёртки. Уж очень много нет в filesystem.

Я использовал ещё до переноса в стандарт языка (сейчас просто поменял boost на std), причём не для какой-то там "интенсивной работы" с файлами, а для самой обычной повседневной: задать путь удобным кроссплатформенным способом, проверить существование какого-то файла и т.п. рядовые мелочи.

Здравствуйте, alex_public, Вы писали:

_>Я использовал ещё до переноса в стандарт языка (сейчас просто поменял boost на std), причём не для какой-то там "интенсивной работы" с файлами, а для самой обычной повседневной: задать путь удобным кроссплатформенным способом, проверить существование какого-то файла и т.п. рядовые мелочи.

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

Здравствуйте, alex_public, Вы писали:

_>Хорошая либа — это ты про какую?

Про http://fmtlib.net/latest/index.html

MTD>>Так отрыв незначительный, зато скорость разработки раза в 2 выше, так что все ок.

_>Так откуда у тебя данные то про скорость разработки в 2 раза выше? )

Я уже приводил пример — решения на Go появились где-то на 3 день, на С и С++ решения стали появляться к концу второй недели. Ну и сам немного писал, многие вещи делаются очень просто.

_>И как ты себе это вообще представляешь на статическом языке, не поддерживающем обобщённое программирование? )

Ты в своей простоте прекрасен. На плюсах только инфраструктуру поднять сколько времени займет? Взять либы нужных версий, собрать их с нужными флагами, при этом от души покурить маны. Тут если кто-то мне будет рассказывать, что можно бинарники скачать или в Линуксе из репозитория поставить я просто посмеюсь, так как понятно, что человек вообще не в теме. На Go же go get и через 5 минут уже все готово. Как говорится пока в Виларибо все еще компилируют, в Вилабаджо уже половину написали. Потом, про обобщенное программирование вообще ржака в контексте скорости разработки, приведи хоть один адекватный пример когда оно сокращает время разработки, не абстрактного сферического коня, а чего-то практического. Во всех языках даже убогих проблему решили где кодогенерацией, где стиранием типов и программист просто берет готовое и использует. Сила языка прежде всего в стандартной библиотеке, то что для языка понаписали 100500 велосипедов разной степени глючности и кривости никак не в плюс, а вот библиотека позволяющая сразу из коробки перевести в нижний регистр utf8 текст или директорию обойти — вот это реально в плюс и жирный.

Здравствуйте, alex_public, Вы писали:

_>И как ты себе это вообще представляешь на статическом языке, не поддерживающем обобщённое программирование? )

Еще небольшое лирическое отступление (все совпадения с реальными людьми случайны) — любители порассуждать про "С++ проектировался чтобы работать на любых устройствах от стиральной машинки до суперкомпьютера", "работа с юникод — это свистелки и никому не надо, а вот без frexp жить нельзя", "файловой системы может и не быть, поэтому в стандарте это не надо" очень быстро сливаются, когда их с абстрактных высот, где они в облачках летают, приземляешь на грешную землю, вот как тут, например: http://rsdn.org/forum/cpp/6899816.1

Автор: MTD
Дата: 10.09.17

Здравствуйте, MTD, Вы писали:

_>>Так откуда у тебя данные то про скорость разработки в 2 раза выше? )

MTD>Я уже приводил пример — решения на Go появились где-то на 3 день, на С и С++ решения стали появляться к концу второй недели. Ну и сам немного писал, многие вещи делаются очень просто.

Не очень понятно, что из этого должно следовать. То, что если нужно быстро написать, но без особых требований к скорости работы, то Go выгоднее C++?

Здравствуйте, so5team, Вы писали:

S>Не очень понятно, что из этого должно следовать.

Если что-то непонятно, можно спрашивать.

S>То, что если нужно быстро написать, но без особых требований к скорости работы, то Go выгоднее C++?

Написать не только можно значительно быстрей, но еще и работать будет быстрее, чем код на С и С++ — первые решения сливали решениям на Go, под конец чемпионата обогнали, но не значительно. Лично я сделал вывод такой: на Go разработка значительно быстрей, производительность кода на хорошем уровне, требуется большая квалификация чтобы на С или С++ обойти Go, скорее всего с учетом квалификации средней по палате, будет медленней.

Здравствуйте, MTD, Вы писали:

S>>То, что если нужно быстро написать, но без особых требований к скорости работы, то Go выгоднее C++?

MTD>Написать не только можно значительно быстрей, но еще и работать будет быстрее, чем код на С и С++ — первые решения сливали решениям на Go, под конец чемпионата обогнали, но не значительно.

Ну вот сказки не нужно рассказывать. "Первые решения", это, наверное, парочка самых первых реализаций на C++, потом оказалось, что в финале из 50 решений только с десяток на Go, да и те далеко не в лидерах. Все остальное, практически, один C++.

MTD>Лично я сделал вывод такой: на Go разработка значительно быстрей, производительность кода на хорошем уровне, требуется большая квалификация чтобы на С или С++ обойти Go, скорее всего с учетом квалификации средней по палате, будет медленней.

Это по поводу задачи для highloadcup-а или вообще? Если вообще, то примеры GUI-приложений на Go где-то можно посмотреть? Или, например, математические расчеты на Go так же будут быстрее, аналоги того же Eigen-а в Go уже завезли?

Здравствуйте, so5team, Вы писали:

S>Ну вот сказки не нужно рассказывать.

Сказки ты сюда пришел рассказывать.

S>"Первые решения", это, наверное, парочка самых первых реализаций на C++

А то, что на Go это тоже были первые решения не считается? Чик-чик мы в домике.

S>потом оказалось, что в финале из 50 решений только с десяток на Go, да и те далеко не в лидерах. Все остальное, практически, один C++.

С этим кто-то спорит? Да С++ и С позволяют написать код более быстрый, но требуют большей квалификации и времени на разработку, отрыв с учетом сказанного совсем не впечатляет.

S>Это по поводу задачи для highloadcup-а или вообще?

Вообще.

S>Если вообще, то примеры GUI-приложений на Go где-то можно посмотреть?

Не знаю. В Гугл делали язык для решения практической задачи — быстрого написания быстрых серверов, тут язык сияет. Но это язык универсальный, можно и гуй прикрутить, надо-ли? Не знаю.

S>Или, например, математические расчеты на Go так же будут быстрее, аналоги того же Eigen-а в Go уже завезли?

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

Здравствуйте, SaZ, Вы писали:

_>>Я использовал ещё до переноса в стандарт языка (сейчас просто поменял boost на std), причём не для какой-то там "интенсивной работы" с файлами, а для самой обычной повседневной: задать путь удобным кроссплатформенным способом, проверить существование какого-то файла и т.п. рядовые мелочи.
SaZ>Ну вот а нам не хватило, когда есть 100к+ файлов и из них нужно быстро найти что-то по маске.

И что, медленно работает? Я сам то не пробовал на таких объёмах, но код очевидный (две строчки — итератор из filesystem и проверка по маске из regexp) и по идее там негде существенно тормозить.

Здравствуйте, MTD, Вы писали:

S>>"Первые решения", это, наверное, парочка самых первых реализаций на C++

MTD>А то, что на Go это тоже были первые решения не считается? Чик-чик мы в домике.

Ну так о том и речь: если нужно быстро написать, но не нужно быстро работать, то Go "сияет".

S>>Если вообще, то примеры GUI-приложений на Go где-то можно посмотреть?

MTD>Не знаю. В Гугл делали язык для решения практической задачи — быстрого написания быстрых серверов, тут язык сияет. Но это язык универсальный, можно и гуй прикрутить, надо-ли? Не знаю.

Ну когда перепишете ICQ на Go, тогда и расскажите про универсальный язык Go.

Здравствуйте, so5team, Вы писали:

MTD>>А то, что на Go это тоже были первые решения не считается? Чик-чик мы в домике.

S>Ну так о том и речь: если нужно быстро написать, но не нужно быстро работать, то Go "сияет".

Ты можешь и дальше отрицать факты, но есть факт — сервера на Go работают очень быстро, на практике в большинстве случаев даже быстрее C и C++, чтобы его обогнать надо писать на очень низком уровне и сильно заморачиваться.

MTD>>Не знаю. В Гугл делали язык для решения практической задачи — быстрого написания быстрых серверов, тут язык сияет. Но это язык универсальный, можно и гуй прикрутить, надо-ли? Не знаю.

S>Ну когда перепишете ICQ на Go, тогда и расскажите про универсальный язык Go.

Зачем? Пока ICQ на языке не напишешь, то языка как-бы и нет? Питона нет, Руби, Джавы и т.д. Взрослый человек, а такую ахинею несешь.