Здравствуйте, alex_public, Вы писали:
_>Это полная ерунда. Я бы разделил изменения в стандарте C++11 (а C++14 — это всего лишь работа над ошибками в C++11) на следующие пункты:
_>1. Замыкания/лямбды. Очень важный пункт, позволяющий элементарно реализовывать потрясающие вещи (причём не только из мира ФП). Хотя естественно нечто подобное можно было делать и раньше (см. Boost), но ценой ужасающе кривого кода. _>2. Семантика перемещения. Вообще потрясающая вещь, не имеющая прямых аналогов в других языках. Как раз она эффективно решает известную проблему с использованием замыканий без сборщика мусора. Но полезно оно не только для замыканий — с данной техникой производительность приложений на C++ уходит вообще в недостижимый отрыв. Причём что самое интересное, многие старые приложения могут ускориться даже без правки их кода — достаточно их перекомпилировать под новый стандарт. _>3. Улучшения метапрограммирования (variadic template, constexpr, decltype и т.п.). Это отдельное направление в мире C++, очень активно развивающееся. И кстати говоря не имеющее аналогов в других мейнстрим языках. Правда во многом до сих пор кривое (т.к. изначально шаблоны не для этого придумывались), но работа идёт... _>4. Мелкие синтаксические улучшения языка (nullptr, auto, range for, override, delete, final, explicit, static_assert, intX_t, литералы, инициализация членов класса, стандартная инициализация {}, using (тип), типизированные перечисления и т.д). _>5. Расширение стандартной библиотеки: unique_ptr/shared_ptr, function, array, tuple, pair, initializer_list, atomic, thread (куча всего), chrono, regex и т.д. и т.п. Тут особо комментировать нечего, т.к. на самом деле все эти вещи были доступны и раньше (в том же Boost'e), просто теперь они поставляются в одной коробке с компилятором.
_>Так вот пункты 1, 4 и 5 ведут исключительно к упрощению кода. Пункт 2 не меняет особо внешний вид кода, только ускоряя его. По пути усложнения идёт только пункт 3, но его никто не заставляет использовать насильно.
Любую программу, которую вы напишете с помощью лямбд, я напишу без них. И ни мне, ни другим программистам не прийдется запоминать синтаксис лямбд или мелких улучшений языка. Автоопределение возвращаемого функцией типа это ужас, т.к. чтобы понять что мне функция вернет, прийдется читать ее код.
Повторюсь, я не против умных указателей и некоторых других улучшений. Но во многих случаях язык становится сложнее без необходимости в этом. Синтаксис C++ интуитивен для любого, кто впервые читает книжку по C++. Расширения C++11 и C++14 требуют запоминать новые обороты — в программировании/администрировании достаточно вещей, которые нужно помнить и без них. Многие расширения C++11 и С++14 для людей, которые именно увлекаются языками программирования как теорией.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков(вроде Spring, Struts) и lpd>серверов приложений на C++.
Во что я ввязываюсь...
Основным посылом прошлого топика было:
— отсутствие универсальной, распределенной, переносимой и т.д. системы сборки (являющейся стандартом де факто и работающей под все платформы и проекты). Причины отсутствия очевидны.
— отсутствие признанных стандартом библиотек (хотя нынче boost и qt претендуют на это) покрывающих большинство потребностей. Там где у Java одна-две приличных и распространенных библиотеки, у C++ десяток вариантов, не все из которых можно назвать законченным решением. И каждый пользуется, к чему душа ближе.
— Java библиотеки проще в эксплуатации, положил куда надо и все работает. Для C++ у каждой свой подход, что-то требует cmake, что-то собирается через autotools/nmake, где-то своя система сборки. Где то мега скрипт не работоспособный без установленных perl, python & ruby. В итоге, что бы включить библиотеку в проект надо обязательно почитать README/INSTALL и понять что с ней делать. Для кроссплатформенных решений легко могут выплыть разные средства сборки и куча подводных камней. Плюс каждая OS & Arch — требует собственный билд (а зачастую просто копию библиотеки).
— Стандартная библиотечка Java побогаче.
В итоге C++ тупо менее удобен Java когда мы говорим о внешних зависимостях и извращениях со сборкой. И тупо быстрей когда у нас одна математика (и если руки не из жопы).
lpd>Представляются возможными такие причины: lpd>1) В Java по-умолчанию предоставляются стандартные переносимые функции вроде управления потоками. lpd>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов, lpd>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.
выше. lpd>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении lpd>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
Память это всего лишь один из ресурсов, помимо нее есть соединения сетевые с СУБД, файловые дескрипторы и прочие радости. И там особой разницы между C++ и Java нет. Плюс умные указатели. lpd>3) Java лучше интегрирован с браузерами.
Это вы мало пользовали Java в браузерах. Когда все эти "write once run everywhere" приложения тупо не работают с новыми JRE или требуют строго 32 JRE или старого браузера и т.д.
Нынче лучше всех интегрирован JavaScript. lpd>При различиях в производительности приложений на C++ и Java удивляет, что на C++ до сих пор нет заметных lpd>фреймворков.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, lpd, Вы писали:
lpd>>auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.
E>не 10, а два — for (x = 0; x < 10; ++x) и for(x : list). И смысл у них как-бы разный... Или ты под for еще и while подразумеваешь?
Я считаю, что язык программирования должен быть простой как C++(или Java). С++11 и С++14 требуют изучения 10ков дополнительных вариантов синтаксиса для по-большей части редко нужных вещей. Т.е. усложнение языка во многих случаях не оправдано пользой.
E>Стандартная библиотеке в сборке просто таки элементарна — ее вообще обычно собирать не надо Переносимость обычно противоречит мощности — скажем на авр-ках нет потоков / файловой системы, а плюсы там чувствуют себя прекрасно
Стандартная библиотека в некоторых отношениях слабее библиотеки Java, при этом сложнее. Из-за чего часто получается, что в проекте используется много небольших библиотек, каждая из которых требует своих опций линковки на каждом из вариантов Linux.
lpd>>Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++. E>Большой плюс явы и шарпа — управляемая среда исполнения, которая дает по рукам перед тем, как программа расстреляет стек скажем. А на си ничто не мешает его расстрелять и получить донельзя странную ошибку в произвольный момент времени
Контроль стека имеет теоретическую ценность: в реальности чтобы расстрелять стек нужны или бесконечная рекурсия, или неподходящий алгоритм, что выявить не столь сложно.
lpd>>У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind.
E>Она то может быть и реализуется, но как? boehm (или как-то так, не помню названия) — куча ограничений и тормоза вероятно еще почище явовских, смарт-поинтеры — довольно много ручной работы, не защищают от некоторых ошибок. valgrind есть только под линем...
Сборщик мусора при желании можно реализовать перегрузкой new/delete и умными указателями. Да, возможно, синтаксис будет несколько сложнее. Но сборка мусора недостаточная причина для использования VM. В том же objective c учет памяти опциональный.
lpd>>на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.
E>Да ладно. Начнем с разных форматов файлов и закончим разным АПИ на разных платформах...
Имею ввиду полностью разный исполняемый код для разных платформ в одном бинарном файле. Код может получаться из одного исходника C++, но с макросами для каждой ОС. Вроде как минимум PE-файлы Windows поддерживали вариант одного бинарника и для x86, и для Alpha.
Если я правильно помню, при появлении Java основным достоинством декларировалась портабельность Java-апплетов, что неактуально. Других существенных достоинств Java, оправдывающих в 8 раз меньшую производительность, кроме теоретически полезной безопасности, обеспечиваемой JVM, по-моему нет.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
_>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...
Мне одному кажется, что по ссылке написан какой-то нечитаемый ад?
Здравствуйте, Stanislav V. Zudin, Вы писали:
_>>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? ) SVZ>Мда. Надеюсь в реальном коде такое никогда не встретится. SVZ>А ведь когда-то над укушенными Александреску глумились
))) Вообще то это вполне нормальный код из мира ФП. Просто на C++ его раньше было проблематично записать. А теперь без проблем.
Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков для разработки корпоративных приложений(вроде Spring, Struts) и серверов приложений на C++.
Представляются возможными такие причины:
1) В Java по-умолчанию предоставляются стандартные переносимые функции вроде управления потоками.
Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов,
в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.
2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении
приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
3) Java лучше интегрирован с браузерами.
При различиях в производительности приложений на C++ и Java удивляет, что на C++ до сих пор нет заметных
фреймворков.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, enji, Вы писали:
E>Здравствуйте, lpd, Вы писали:
lpd>>Если бы C++ развивался не в сторону по большей части не нужных и несколько усложненных C++11 и C++14, E>вот не надо. auto, замыкания, for — все это нужно и не усложнено. rvalue — усложнено, но местами сильно упрощает и увеличивает производительность
auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.
lpd>> а появился бы переносимый и мощный stl, то C++ заменил бы Java и C#. E>переносимый и мощный stl сразу убирает плюсы из всяких там embedded. Собственно и в яве разные библиотеки для каких-нить мобил или карт и для веба...
О том и речь, что для конкуренции с Java нужна еще одна стандартная библиотека. Более мощная, переносимая и простая в сборке.
E>для бизнес-приложений есть более безопасные языки вроде шарпа/явы. Врядли плюсы могут их подвинуть
Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++. У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind. Переносимость, которая при появлении java считалась основным преимуществом VM нужна только для малоиспользуемых java-апплетов, т.к. на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, enji, Вы писали:
E>Что ты вообще имеешь в виду под усложнением синтаксиса в с++11/14?
Если в терминологии wikipedia{C++11}{C++14}:
lamda-выражения считаю бесполезными — если мне надо вызвать несколько функций, я их вызову без lambda.
Alternative function syntax — зачем?
User-defined literals — бесполезно.
Function return type deduction — ужас
Variable templates — бесполезно
E>она во многих отношениях слабее явы. До нелюбимого тобой с++11 там даже потоков не было... Что касается опций линковки — ты о чем?
Я и говорю, что во многих отношениях слабее явы. Если нужно собрать один и тот-же проект с несколькими библиотеками в разных дистрибутивах линукса, то процедуру сборки прийдется усложнять. Это проблема решаемая,
но все же она присутствует и средства сборки линукс не полностью интуитивны для программистов, которые не знают auto-tools или тонкости make. Потом, при линковке того же буста, в разных дистрибутивах часто возникают проблемы с заголовчными файлами.
E>Опять же, более сильная стандартная библиотека не взлетит на тех же мелких контроллерах. Все равно будут какие-то подмножества в каждой области применения.
Правильно — возможно, нужна еще одна, более полная библиотека, аналогичная библиотеке Java.
E>Чтобы расстрелять стек / кучу / etc, достаточно обратиться по мусорному указателю. С учетом отсутствия контроля со стороны рантайма, это сделать элементарно — неинициализированная переменная, дважды вызвали деструктор, вышли за границы массива, ...
Если программа дважды вызывает деструктор или обращается по мусорному указателю, то в ней баг и она работать не будет. Да, на C++ найти этот баг может быть несколько сложнее, но в больших проектах для этого можно использовать собственные менеджеры памяти и тот же valgrind(наверняка в Windows есть аналогичные средства). Да — проблемы с памятью в программах на С++ встречаются, но они решаемы, если программист понимает, что делает. Для этого всего то нужно потратить две недели-месяц на чтение книг по С++.
E>Умные указатели — это не сборщик мусора. Их надо осознанно использовать, обычные указатели никуда не деваются — т.е. есть риск ошибки, циклы разруливаются только руками — снова есть риск ошибки... Сравни это с явовской ссылкой — с ней что-то сделать не так уже значительно сложнее.
Та или иная система учета памяти в С++ была бы полезна. Но для этого не нужен сборщик мусора — система в Objective C достаточно удобна, есть и другие. И медленная VM для этого — перебор.
E>В смысле — в один exe склеены несколько файлов? Хз насчет Alpha, но win/lin в одном файле я что-то пока не видел А вот явовские софтины, запускающиеся и там и там — встречались
Да я тоже не встречал, как впрочем и живых Alpha процессоров. Наверное, достаточно распространять по бинарнику для каждой архитектуры.
E>Мы ж про бизнес-приложения? Тут безопасность рулит, а производительность — не принципиальна. Тут сбоку как раз темка про ява/с++, можешь там ознакомиться
Используя C++ можно получить все то же + нормальная производительность, но получается, что ряд мелких недочетов этому мешают и для фреймворков выбирается Java. Но имхо — эти недочеты устранимы без VM.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
_>>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? ) lpd>Возможно, в некоторых случаях ламбды сокращают код. Но любую программу можно написать без них (вроде Тьюринг еще доказывал).
Естественно. Весь вопрос в том, чтобы минимизировать количество кода при сохранение функциональности. Лямбды (точнее замыкания) в этом существенно помогают.
lpd>>> Автоопределение возвращаемого функцией типа это ужас, т.к. чтобы понять что мне функция вернет, прийдется читать ее код. _>>А шаблонные функции (которые принимают не пойми что, и надо читать их код, чтобы понять) — это тоже тогда ужас? ) lpd>Шаблонные функции могут стоить того. Но если вместо auto в объявлении функции программист расшифрует, что именно функция вернет, он вряд ли перетрудится. Даже если там что-то жуткое в стиле C++14.
В некоторых случаях (например как раз для лямбд, собственно во многом ради них auto и ввели) это в принципе невозможно. А в некоторых возможно, но требует существенных усилий (когда тип возвращаемого значения зависит от шаблонного типа параметров) от программиста. И зачем тогда страдать, если это всё может сделать компилятор?
Да, в элементарных случаях применение auto становится спорным случаем — такое надо решать на уровне внутрикомандных правил разработки. Но в некоторых случаях оно просто безальтернативно.
_>>Если новые возможности позволяют писать более краткий и простой или безопасный или быстрый код, то значит их надо изучить и использовать. А то так можно было и на ассемблере остаться... lpd>Возможно. Но, по моему мнению, направление развития C++ выбрано не лучшее. Этот топик по-идее как раз о том, чего не хватает C++ для популярности в фреймворках. И думаю, что C++14 в этом не помогает.
Что такое "популярность в фреймворках"? ) Если что, библиотек на C/C++ бесчисленное количество. Собственно большинство других языков обычно работает через них, организуя соответствующие биндинги.
Что касается направления развития, то думаю что шаг с C++11 был сделан очень вовремя для языка. Потому как уже очень многие стали посматривать на D и т.п. языки с лямбдами и развитым метапрограммированием. И приход C++11 дал понять, что снова можно какое-то время не искать замену C++.
Здравствуйте, lpd, Вы писали:
lpd>Любую программу, которую вы напишете с помощью лямбд, я напишу без них.
Любую программу которую ты напишешь без лябд, можно написать на brainfuck.
И ни мне, ни другим программистам не прийдется запоминать синтаксис лямбд или мелких улучшений языка. Автоопределение возвращаемого функцией типа это ужас, т.к. чтобы понять что мне функция вернет, прийдется читать ее код.
Т.е. осмысленные названия функций это уже не модно? Боюсь тут типы уже ничего не спасут.
lpd>Синтаксис C++ интуитивен для любого, кто впервые читает книжку по C++.
Здравствуйте, alex_public, Вы писали:
_>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...
Чудный образчик:
g++ --version && g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
g++ (GCC) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
8 7 6 5 4 3 2 1
error : "auto" is not allowed here
1> auto tuple = [](auto... args)
error : identifier "args" is undefined
1> return [=](auto f){ return f(args...); };
: error : expected a ")"
1> auto map = [](auto... args)
И т.д., 46 ошибок. VS 2013 тоже не осилила, 15 не держу.
Как работать то должно? Какую задачу (кроме демонстрации лямбд) этот код должен решить, что на входе, что на выходе?
Ну и как выше подметили, не хотелось бы видеть такое в реальных проектах.
_>Фраза "исправили старый косяк" подразумевает, что в тоже время было известно правильное решение. Можно узнать в каком именно языке оно присутствовало? )
Ха! Нужно поискать язык где бы оно отсутствовало. Сам факт лишних копирований был вызван таким подходом к семантике ссылок и увлечением абстракциями ООП. За абстракции всегдла надо платить.
_>Так вот не стоит путать метапрограммирование и обобщённое программирование — это абсолютно разные парадигмы, предназначенные для решения совершенно разных задач. И да, обобщённое программирование в C# и C++ не сильно отличается. Но здесь то речь не о нём. Хотя возможно кого-то путает тот факт, что для метапрограммирования в C++ в основном используются те же самые шаблоны, что и для обобщённого (и как раз поэтому МП в C++ достаточно кривое, т.к. изначально шаблоны разрабатывались именно для ОП), хотя и по другому. Но из этого точно невозможно сделать вывод о наличие МП в C# — там нет ничего похожего в принципе. )))
Технически метапрограммирование есть и в чистом С, через препроцессор. Что ты подразумеваешь под метапрограммированием. Особенно интересно в плане метапрограммирование vs кодогенерация (T4), метапрограммирование vs препроцессор и метапрограммирование vs метаморфизм в реалтайме.
Здравствуйте, lpd, Вы писали:
lpd>Если бы C++ развивался не в сторону по большей части не нужных и несколько усложненных C++11 и C++14,
вот не надо. auto, замыкания, for — все это нужно и не усложнено. rvalue — усложнено, но местами сильно упрощает и увеличивает производительность
lpd> а появился бы переносимый и мощный stl, то C++ заменил бы Java и C#.
переносимый и мощный stl сразу убирает плюсы из всяких там embedded. Собственно и в яве разные библиотеки для каких-нить мобил или карт и для веба...
lpd> stl в C++ в том виде, в котором он сейчас, нужен для сравнительно быстрого портирования базовых программ между разными linux и в embedded, но он недостаточно прост и силен для использования в бизнес-приложениях. lpd>Но, возможно, это не единственная причина, поэтому я и поднял исходный вопрос.
для бизнес-приложений есть более безопасные языки вроде шарпа/явы. Врядли плюсы могут их подвинуть
Здравствуйте, lpd, Вы писали:
lpd>Имею ввиду отсутствие фреймворков для бизнес-приложений вроде Spring/Struts и множества других на Java.
С++ в силу некоторых причин не подходит для написания бизнес-приложений. Поэтому соответствующих фреймворков в нём и не наблюдается. Это настолько явная и ясная причина, что меня удивляет вообще наличие подобных вопросов.
Здравствуйте, lpd, Вы писали:
lpd>auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.
не 10, а два — for (x = 0; x < 10; ++x) и for(x : list). И смысл у них как-бы разный... Или ты под for еще и while подразумеваешь?
lpd>О том и речь, что для конкуренции с Java нужна еще одна стандартная библиотека. Более мощная, переносимая и простая в сборке.
Стандартная библиотеке в сборке просто таки элементарна — ее вообще обычно собирать не надо Переносимость обычно противоречит мощности — скажем на авр-ках нет потоков / файловой системы, а плюсы там чувствуют себя прекрасно
lpd>Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++.
Большой плюс явы и шарпа — управляемая среда исполнения, которая дает по рукам перед тем, как программа расстреляет стек скажем. А на си ничто не мешает его расстрелять и получить донельзя странную ошибку в произвольный момент времени
lpd>У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind.
Она то может быть и реализуется, но как? boehm (или как-то так, не помню названия) — куча ограничений и тормоза вероятно еще почище явовских, смарт-поинтеры — довольно много ручной работы, не защищают от некоторых ошибок. valgrind есть только под линем...
lpd>на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.
Да ладно. Начнем с разных форматов файлов и закончим разным АПИ на разных платформах...
Здравствуйте, alex_public, Вы писали:
lpd>>Любую программу, которую вы напишете с помощью лямбд, я напишу без них. И ни мне, ни другим программистам не прийдется запоминать синтаксис лямбд или мелких улучшений языка.
_>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? )
Мда. Надеюсь в реальном коде такое никогда не встретится.
А ведь когда-то над укушенными Александреску глумились
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, 11molniev, Вы писали:
1>>Как минимум C# вполне себе работает с метапрограммированием.
DM>В каком виде? Кажется, вы с Алексом тут несколько разные вещи себе представляете.
В виде компилятор как сервис. С++ тут нервно курит в сторонке.
Здравствуйте, Mamut, Вы писали:
_>>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса... M>Мне одному кажется, что по ссылке написан какой-то нечитаемый ад?
Там используется абсолютно стандартная для ФП техника возврата одной лямбды (а точнее замыкания) в качестве результата вычисления другой лямбды. Она используется во многих местах и языках для разных целей. Например с помощью неё можно реализовать альтернативное ООП. ))) Единственно что в данном примере эта техника усилена возможностью лямбд из C++ принимать произвольное число произвольных параметров. Да, так уж вышло, что C++, долго отстававший в данной области, одним прыжком догнал и перегнал другие языки. )))
M>Кстати, что такое [=]?
В квадратных скобках указываются способы захвата переменных в замыкание. "=" — это самый простейший вид, означающий "всё по значению". Но вместо него там может быть что угодно. Например [x=y+z, new_v=move(v)] и т.п. )))
Здравствуйте, 11molniev, Вы писали:
1>Как работать то должно? Какую задачу (кроме демонстрации лямбд) этот код должен решить, что на входе, что на выходе? 1>Ну и как выше подметили, не хотелось бы видеть такое в реальных проектах.
Ну то, что компилятор C++ от MS давно отстал от конкурентов и превратился в убогое недоразумение, ни для кого не новость. А вот для компилятора от Intel похоже кто-то забыл включить поддержку C++14... )
Что касается самого кода, то он демонстрирует альтернативную (т.к. в C++ и так есть std::tuple) реализацию кортежей, на замыканиях. А так же работу с ними (слияние, применение функции). Кстати, этот пример должен быть весьма актуален как раз для C# — там же стандартные кортежи очень забавные, кажется максимум на 8 элементов, да? )))
_>>Фраза "исправили старый косяк" подразумевает, что в тоже время было известно правильное решение. Можно узнать в каком именно языке оно присутствовало? ) 1>Ха! Нужно поискать язык где бы оно отсутствовало. Сам факт лишних копирований был вызван таким подходом к семантике ссылок и увлечением абстракциями ООП. За абстракции всегдла надо платить.
Т.е. снова сравниваем разную функциональность? ) Естественно, что если делать убогую реализацию без RAII и со сборщиком мусора, то нет проблем. Два простейших примера:
1. У нас есть отдельные строки (по гигабайту каждая, для остроты ощущений) и пустой массив строк. Мы хотим положить одну строку в массив. Но чтобы при этом естественно не происходило копирования гигабайта. Ну и само собой при удаление массива все строки в нём должны удаляться.
— C: можно наколбасить руками эффективную реализацию
— Java/C#: работает автоматически, но не эффективно (сборщик мусора со всеми печальными последствиями из этого)
— C++: работает автоматически и эффективно
— так какой там язык давно имел эффективное автоматическое решение данной проблемы?
2. У нас есть объект, инкапсулирующий в себе некое соединение по сети и пустой массив такого же типа. Мы хотим положить этот объект в массив. Естественно мы хотим, чтобы при удаление массива все соединения закрывались.
— C: можно наколбасить руками эффективную реализацию
— Java/C#: можно наколбасить руками эффективную реализацию
— C++: работает автоматически и эффективно
— так какой там язык давно имел эффективное автоматическое решение данной проблемы?
_>>Так вот не стоит путать метапрограммирование и обобщённое программирование — это абсолютно разные парадигмы, предназначенные для решения совершенно разных задач. И да, обобщённое программирование в C# и C++ не сильно отличается. Но здесь то речь не о нём. Хотя возможно кого-то путает тот факт, что для метапрограммирования в C++ в основном используются те же самые шаблоны, что и для обобщённого (и как раз поэтому МП в C++ достаточно кривое, т.к. изначально шаблоны разрабатывались именно для ОП), хотя и по другому. Но из этого точно невозможно сделать вывод о наличие МП в C# — там нет ничего похожего в принципе. ))) 1>Технически метапрограммирование есть и в чистом С, через препроцессор. Что ты подразумеваешь под метапрограммированием. Особенно интересно в плане метапрограммирование vs кодогенерация (T4), метапрограммирование vs препроцессор и метапрограммирование vs метаморфизм в реалтайме.
Да, препроцессор в C тоже является метапрограммированием. Но безусловно на порядок более убогим) Как собственно и все препроцессоры, которые не умеют работать в терминах языка. Это так сказать МП прошлого века)
Любую внешнюю кодогенерацию вообще не имеет смысла упоминать при сравнение языков, т.к. она не имеет никого отношения к данному вопросу. А то такими темпами можно будет включить например пакет Mathematica в C++ (а что, оно же умеет генерировать соответствующий код?). )))
МП в реалтайме является стандартным инструментом (хотя частенько его рекомендуют избегать, т.к. слишком опасная штука) динамических языков. Использовать подобное в статическом языке можно только от жесткой безысходности. )))
В общем, если подвести итог, то можно сказать, что МП:
— в Java/C# просто нет
— в C++ есть, криво-косое
— в D, Nemerle и т.п. есть, нормальное.
Но есть один нюанс: мейнстрим языками тут являются только первые три... )
C# generics do not provide...
C# does not allow...
C# does not support...
C# does not support...
C# does not allow...
C# does not allow...
In C#, a generic type parameter cannot itself...
Здравствуйте, lpd, Вы писали:
lpd>Идея в том, что если: lpd>1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч.
Я написал про проблемы добавления в стандартную либу. Но да, идея вполне нормальная. lpd>2) сделать системы сборки более интуитивными
Какие ваши предложения? Даже если сделать стандартную систему сборки, останутся еще гигатонны легаси, под нее не приспособленные. lpd>3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок.
Этого не понял. Подсчет ссылок есть у shared_ptr. lpd>4) на правах флейма: убрать C++11 и C++14
Зачем? Тебя ж никто не заставляет использовать эти фичи. А многим это сильно упрощает жизнь. lpd>То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java.
Легко использовать никогда не получится, придется все же учить.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, lpd, Вы писали:
lpd>Идея в том, что если: lpd>1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч.
Теоретически не плохая мысль. Однако на практике я знаю десяток самых эффективных реализаций данного дела и все они написаны как раз на C/C++ — какую из них выбрать канонической? )
lpd>2) сделать системы сборки более интуитивными
Что-то мне кажется, что здесь имеет место путаница между системами сборки и системами управления зависимостями. Просто в мире Java эти сущности часто совмещены в один инструмент. А в C++ не так. Систем сборок здесь полно и многие поудобнее вариантов из Java (к примеру я предпочитаю waf, который наследник scons'a). А вот с зависимостями действительно всё очень печально и делается только руками.
lpd>3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок.
Если хочется подсчёт ссылок, то чем не подходит std::shared_ptr? )
lpd>4) на правах флейма: убрать C++11 и C++14
Бред.
lpd>То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java.
В принципе на C++ можно программировать и без низкоуровненого кода (игр с указателями в C стиле) и без шаблонной магии. Тогда он действительно становится похож на Java. В этом смысле весьма показателен фреймворк Qt. Когда с ним работаешь (вынужденно, ради кроссплатформенного GUI), то прямо создаётся впечатление, что пишешь на Жабке. ))) Вопрос только в востребованности подобных решений.
Здравствуйте, AlexRK, Вы писали:
EP>>Вручную выписывать каждый контейнер, а потом выписывать каждый вариант обхода, да ещё и следить за изменением списка типов не удобно. Вот как раз для автоматизации всего этого и используются библиотеки подобного рода (например Boost.Fusion или Hana). ARK>Проблему понял, хотя связь с приведенным лямбдовым кодом не вполне уловил.
Внутри реализации например нужно обходить все эти контейнеры — для этого нужен специальный for_each.
А при push_back значения — нужно найти правильный контейнер. Причём хоть это всё и происходит в compile-time, но всё же желательно чтобы поиск был суб-линейным, здесь уже появляется потребность в специальных структурах данных.
В результате появляются библиотеки для работы с такими гетерогенными значениями включающие в себя алгоритмы, структуры данных и т.п. Приведённый код с лямбдами демонстрирует небольшой кусочек мозаики. Но прелесть этого кода/трюка в том, что раньше, в C++98 для реализации аналога потребовалось намного больше кода.
ARK>Лично я, не будучи программистом экстра-класса (хотя и знаком с функциональными приблудами), однозначно предпочел бы видеть в проекте три или четыре руками написанных контейнера с разными объектами, чем нечитаемый (как минимум, лично мной) вышеприведенный говнокод с лямбдами.
А его и не нужно читать, это библиотечный код. Пользователю же можно предоставить достаточно простой интерфейс:
int main()
{
poly_seq<int, double> seq;
for(int i=0; i!=3; ++i)
{
push_back(seq, i); // int
push_back(seq, i+0.1); // double
}
for_each(seq, [](auto x)
{
cout << x << endl;
});
}
// Output is:
0
1
2
0.1
1.1
2.1
ARK>Если же число разнотипных контейнеров велико, то я бы задумался о применении нормальной — читаемой — кодогенерации (не на С++).
Кодогенерация далеко не всегда удобна. Например в этом примере for_each может быть в разных местах, и его могут использовать для разных действий — придётся генерировать каждый вариант, и делать кодогенерационные склейки в каждом месте. Так это ещё простой пример — меняться может не только действие, но и алгоритм, и даже контейнер — тогда придётся генерировать каждую комбинацию, в каждом месте.
Да и сам кодогенерационный код и сложнее обычного и тяжелей в поддержке — происходит по сути низкоуровневая манипуляция строками. Одно дело нагенерировать классы по схеме, а другое реализовывать по сути те же самые шаблоны.
Страуструп, кстати, тоже думал что макросов хватит:
http://cpp-lang.io/30-years-of-cpp-bjarne-stroustrup/
People often forget that parameterized types were there from the start. I used a vector macro with the element type as a macro parameter from the earliest days and Cfront shipped with a <generic.h> header. For a couple of years, I thought macros would be enough to support generic programming. I was very wrong about that, but I was right about the need to parameterize types and functions with (other) types. The result became templates (1988).
Здравствуйте, lpd, Вы писали:
lpd>1) В Java по-умолчанию предоставляются стандартные переносимые функции вроде управления потоками.
Начиная с C++11 управление потоками входит с стандарт.
lpd>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов, lpd>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.
А зачем для каждого развёртывания повторять (видимо вручную) какие-то операции? Напиши скрипт и дело в шляпе.
lpd>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении lpd>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду.
lpd>3) Java лучше интегрирован с браузерами.
О чём конкретно речь? Для C++ есть Emscripten, с помощью него например за четыре дня спортировали Unreal Engine в JavaScript: http://www.youtube.com/watch?v=BV32Cs_CMqo
lpd>При различиях в производительности приложений на C++ и Java удивляет, что на C++ до сих пор нет заметных lpd>фреймворков.
Для какой-то конкретной области или вообще?
lpd>Представляются возможными такие причины:
Перечисленные тобой причины практически ортогональны наличию/отсутствию фреймворков.
Здравствуйте, 11molniev, Вы писали:
1>И каких же базовых функций не хватает в связке C++11, Boost, Qt?
Boost еще надо прилинковать — но он не очень и нужен допустим. Qt предлагает средства для UI и работы с
Bluetooth, NFC и т.п., но эти средства скорее лишние для framework, зато вроде бы отсутствует HTTP. Не уверен, что в QT
достаточные для web-приложений модули для работы с Web.
1>Это три разных языка. Костяк у них конечно общий, но возможности, удобство и особенности довольно разные. 1>И да, если бы для их вытеснения было бы достаточно стандартной библиотеки, то появилось бы библиотека, а не новые языки.
Если бы C++ развивался не в сторону по большей части не нужных и несколько усложненных C++11 и C++14, а появился бы переносимый и мощный stl, то C++ заменил бы Java и C#. stl в C++ в том виде, в котором он сейчас, нужен для сравнительно быстрого портирования базовых программ между разными linux и в embedded, но он недостаточно прост и силен для использования в бизнес-приложениях.
Но, возможно, это не единственная причина, поэтому я и поднял исходный вопрос.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
AD>>С++ в силу некоторых причин не подходит для написания бизнес-приложений. Поэтому соответствующих фреймворков в нём и не наблюдается. Это настолько явная и ясная причина, что меня удивляет вообще наличие подобных вопросов. lpd>Ну вот я и пытаюсь выяснить, что это, в действительности, за причины. Но список причин получается короткий и сомнительный.
Причина собственно одна и она общеизвестна: для решения задач одинаковой сложности C++ и Java/C# требуют от программиста разного уровня подготовки. Что принципиально для бизнеса — не IT компаниям гораздо выгоднее использовать низкоуровневых и хорошо взаимозаменяемых программистов. Так вот как раз Java и C# позволяют это делать безопасно. А C++ в подобном режиме использования обычно приводит к жутким последствиям.
Кстати, при этом всём C++ софта всё равно используется больше, даже в том же бизнесе. Просто он при этом не пишется внутри компании, а покупается у специализированных IT компаний, в которых уже работают высокоуровневые спецы.
Здравствуйте, lpd, Вы писали:
lpd>Имел ввиду именно фреймворки для корпоротивных приложений вроде Spring, Struts — таких на C++ я не встречал. Скорректирую исходный пост.
Та ведь С/С++ — это базис, а Java и фреймворки — надстройка (одна из). Надстройка, как правило, решает сугубо частные проблемы, наиболее подходящие по сфере задач и эффективности сопровождения, а базис обслуживает надстройку (надстройки). Ближайший аналог C/C++ в плане доступности, компетентности в применении в прикладных фреймворках — язык Go, но он пока не сильно популярен в силу того, что есть "унаследованный груз кода", который нужно сопровождать. А на это нужны людские ресурсы, а не только деньги.
Здравствуйте, lpd, Вы писали:
lpd>Ну вот я и пытаюсь выяснить, что это, в действительности, за причины.
Тут уже написали почему: разработка и поддержка корпоративных приложений на плюсах дороже. Причём в разы, а возможно даже на порядок.
lpd>Но список причин получается короткий и сомнительный.
А зачем этому списку быть длинным? Достаточно одной веской причины.
Здравствуйте, lpd, Вы писали:
E>>Что ты вообще имеешь в виду под усложнением синтаксиса в с++11/14? lpd>Если в терминологии wikipedia{C++11}{C++14}: lpd>lamda-выражения считаю бесполезными — если мне надо вызвать несколько функций, я их вызову без lambda. lpd>Alternative function syntax — зачем? lpd>User-defined literals — бесполезно. lpd>Function return type deduction — ужас lpd>Variable templates — бесполезно
Это полная ерунда. Я бы разделил изменения в стандарте C++11 (а C++14 — это всего лишь работа над ошибками в C++11) на следующие пункты:
1. Замыкания/лямбды. Очень важный пункт, позволяющий элементарно реализовывать потрясающие вещи (причём не только из мира ФП). Хотя естественно нечто подобное можно было делать и раньше (см. Boost), но ценой ужасающе кривого кода.
2. Семантика перемещения. Вообще потрясающая вещь, не имеющая прямых аналогов в других языках. Как раз она эффективно решает известную проблему с использованием замыканий без сборщика мусора. Но полезно оно не только для замыканий — с данной техникой производительность приложений на C++ уходит вообще в недостижимый отрыв. Причём что самое интересное, многие старые приложения могут ускориться даже без правки их кода — достаточно их перекомпилировать под новый стандарт.
3. Улучшения метапрограммирования (variadic template, constexpr, decltype и т.п.). Это отдельное направление в мире C++, очень активно развивающееся. И кстати говоря не имеющее аналогов в других мейнстрим языках. Правда во многом до сих пор кривое (т.к. изначально шаблоны не для этого придумывались), но работа идёт...
4. Мелкие синтаксические улучшения языка (nullptr, auto, range for, override, delete, final, explicit, static_assert, intX_t, литералы, инициализация членов класса, стандартная инициализация {}, using (тип), типизированные перечисления и т.д).
5. Расширение стандартной библиотеки: unique_ptr/shared_ptr, function, array, tuple, pair, initializer_list, atomic, thread (куча всего), chrono, regex и т.д. и т.п. Тут особо комментировать нечего, т.к. на самом деле все эти вещи были доступны и раньше (в том же Boost'e), просто теперь они поставляются в одной коробке с компилятором.
Так вот пункты 1, 4 и 5 ведут исключительно к упрощению кода. Пункт 2 не меняет особо внешний вид кода, только ускоряя его. По пути усложнения идёт только пункт 3, но его никто не заставляет использовать насильно.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
lpd>>Любую программу, которую вы напишете с помощью лямбд, я напишу без них. И ни мне, ни другим программистам не прийдется запоминать синтаксис лямбд или мелких улучшений языка.
_>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? )
Возможно, в некоторых случаях ламбды сокращают код. Но любую программу можно написать без них (вроде Тьюринг еще доказывал).
lpd>> Автоопределение возвращаемого функцией типа это ужас, т.к. чтобы понять что мне функция вернет, прийдется читать ее код.
_>А шаблонные функции (которые принимают не пойми что, и надо читать их код, чтобы понять) — это тоже тогда ужас? )
Шаблонные функции могут стоить того. Но если вместо auto в объявлении функции программист расшифрует, что именно функция вернет, он вряд ли перетрудится. Даже если там что-то жуткое в стиле C++14.
lpd>>Повторюсь, я не против умных указателей и некоторых других улучшений. Но во многих случаях язык становится сложнее без необходимости в этом. Синтаксис C++ интуитивен для любого, кто впервые читает книжку по C++. Расширения C++11 и C++14 требуют запоминать новые обороты — в программировании/администрировании достаточно вещей, которые нужно помнить и без них. Многие расширения C++11 и С++14 для людей, которые именно увлекаются языками программирования как теорией.
_>Если новые возможности позволяют писать более краткий и простой или безопасный или быстрый код, то значит их надо изучить и использовать. А то так можно было и на ассемблере остаться...
Возможно. Но, по моему мнению, направление развития C++ выбрано не лучшее. Этот топик по-идее как раз о том, чего не хватает C++ для популярности в фреймворках. И думаю, что C++14 в этом не помогает.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, D. Mon, Вы писали:
1>>Как минимум C# вполне себе работает с метапрограммированием.
DM>В каком виде? Кажется, вы с Алексом тут несколько разные вещи себе представляете.
Здравствуйте, Poopy Joe, Вы писали:
1>>Ну как то так: 1>>Differences Between C++ Templates and C# Generics (C# Programming Guide) 1>>https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx
PJ>Это никакого отношения к метапрограммированию не имеет.
ОК. А что имеет отношение? В каких языках есть? И чего позволяет достичь, недостижимого в языках с отсутствием этого?
Здравствуйте, Poopy Joe, Вы писали:
1>>>Как минимум C# вполне себе работает с метапрограммированием. DM>>В каком виде? Кажется, вы с Алексом тут несколько разные вещи себе представляете. PJ>В виде компилятор как сервис. С++ тут нервно курит в сторонке.
Удобный Clang появился раньше Roslyn'а, не говоря уже об менее удобном GCC.
Здравствуйте, alex_public, Вы писали:
_>Ха, так это не Embedded DSL — зачем он в теме про МП? Это в точности реализация пункта 2 отсюда http://rsdn.ru/forum/philosophy/6116603.1
. Только вместо собственного лексера и парсера на flex+bizon используется готовое решение на базе компилятора C#. Можно пообсуждать плюсы и минусы подобного решения, но к нашей теме дискуссии это пример явно не относится.
Это Embedded DSL. Может ты под этим что-то свое понимаешь, но тогда давай определение своих терминов.
_>Да, т.к. изначально шаблоны не были предназначены для МП, то оно получилось в C++ весьма кривым. Но при этом есть существенный нюанс: вся сложность проявляется при создание соответствующего МП кода (т.е. лежит на авторах библиотек), а вот использование его обычно не существенно сложнее (вот разве что сообщения об ошибках бывают печальные, и то если авторы библиотеки не озаботились этим вопросом). Ну и в любом случае даже кривой инструмент лучше никакого (как у остальных мейнстрим языков). )))
Использование их вообще кошмар. Ну сообщает оно, что в вариадик темплейте какая-то ошибка. И что?
У остальных "мейстрим" языков нет никакой проблемы, потому что нет привязки к языку. Ничего не мешает писать часть на c#, часть на f# часть на хоть на том же с++. Предоставляя в совокупности гораздо более мощный инструмент, чем любые шаблоны. В с++ же полный ад. Проблемы возникают даже внутри с++. Хочется использовать VS2015 и с++14? Будешь сидеть на VS2012, просто потому что какой-нибудь производитель библиотеки не считает нужным поддерживать что-то новее.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Stanislav V. Zudin, Вы писали:
Ops>Угу. ERP — это электронное перекладывание бумажек, и это далеко не всегда основное занятие бизнеса. SVZ>>Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону). Ops>Либу — только за, при условии низкой связности модулей. 100500 велосипедов, раскиданных по разным крупным библиотекам, реально задалбывают, и часто вынуждают писать свои велосипеды под проект. Но тут другая сложность, в отличие от явы с дотнетом, здесь мы имеем неповоротливый комитет и кучу формалистики, для подобной библиотеки такой подход нежизнеспособен. Да, есть буст, который развивается по гораздо лучшей модели, но там уже начинается коллективное безответственное с поддержкой некоторых библиотек. Ну и до сих пор слышу про его категорическое неприятие и запрет в некоторых проектах, из которых процент аргументированных в окрестностях 0.
Идея в том, что если:
1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч.
2) сделать системы сборки более интуитивными
3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок.
4) на правах флейма: убрать C++11 и C++14
То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
lpd>>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов, lpd>>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.
EP>А зачем для каждого развёртывания повторять (видимо вручную) какие-то операции? Напиши скрипт и дело в шляпе.
Может потребоваться редактирование скрипта/настроек в зависимости от ОС у программиста если нужны несколько отдельно уставнавлиеваемых/компилируемых библиотек.
lpd>>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении lpd>>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
EP>Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду.
Без reflection в большинстве случаев можно обойтись. Мне на C++ никогда reflection не были нужны.
EP>Для какой-то конкретной области или вообще?
Имею ввиду отсутствие фреймворков для бизнес-приложений вроде Spring/Struts и множества других на Java.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Вот и в моих рассуждениях получается, что единственным препятствием для использования C++ в бизнес-фреймворках является
разбросанность базовых функций по множеству библиотек и следующее из этого некоторое неудобство сборки. Выходит, что
C++ для вытеснения Java и C# из области бизнес-приложений по-существу не хватает только реализации стандартной библиотеки Java.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>>>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов, lpd>>>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр. EP>>А зачем для каждого развёртывания повторять (видимо вручную) какие-то операции? Напиши скрипт и дело в шляпе. lpd>Может потребоваться редактирование скрипта/настроек в зависимости от ОС у программиста если нужны несколько отдельно уставнавлиеваемых/компилируемых библиотек.
Да, тут согласен — сторонние библиотеки для разных OS могут требовать разных процедур. Думал речь про развертывание в одинаковых средах.
lpd>>>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении lpd>>>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы). EP>>Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду. lpd>Без reflection в большинстве случаев можно обойтись. Мне на C++ никогда reflection не были нужны.
Не понял причём тут reflection, речь же шла про безопасный доступ к памяти.
Здравствуйте, lpd, Вы писали:
lpd>Вот и в моих рассуждениях получается, что единственным препятствием для использования C++ в бизнес-фреймворках является lpd>разбросанность базовых функций по множеству библиотек и следующее из этого некоторое неудобство сборки. Выходит, что lpd>C++ для вытеснения Java и C# из области бизнес-приложений по-существу не хватает только реализации стандартной библиотеки Java.
И каких же базовых функций не хватает в связке C++11, Boost, Qt?
Да неудобство есть, но при выборе языка на него кто вообще посмотрит? Потратить C времени на библиотеку для крупного проекта не сложно. Для кучи мелких можно таскать с собой пару заголовочных файлов и пользоваться общей кучей собранных библиотек. Это неудобство, а не проблема.
Это три разных языка. Костяк у них конечно общий, но возможности, удобство и особенности довольно разные.
И да, если бы для их вытеснения было бы достаточно стандартной библиотеки, то появилось бы библиотека, а не новые языки.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, lpd, Вы писали: lpd>>>>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении lpd>>>>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы). EP>>>Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду. lpd>>Без reflection в большинстве случаев можно обойтись. Мне на C++ никогда reflection не были нужны.
EP>Не понял причём тут reflection, речь же шла про безопасный доступ к памяти.
Да, насчет средств компилятора согласен, но их на данный момент никаких нет, что выглядит недостатком.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, lpd, Вы писали:
lpd>>Имею ввиду отсутствие фреймворков для бизнес-приложений вроде Spring/Struts и множества других на Java.
AD>С++ в силу некоторых причин не подходит для написания бизнес-приложений. Поэтому соответствующих фреймворков в нём и не наблюдается. Это настолько явная и ясная причина, что меня удивляет вообще наличие подобных вопросов.
Ну вот я и пытаюсь выяснить, что это, в действительности, за причины. Но список причин получается короткий и сомнительный.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Я считаю, что язык программирования должен быть простой как C++(или Java). С++11 и С++14 требуют изучения 10ков дополнительных вариантов синтаксиса для по-большей части редко нужных вещей. Т.е. усложнение языка во многих случаях не оправдано пользой.
Ну ты и сравнил. С++ отнюдь не простой, особенно по сравнению с явой. Что ты вообще имеешь в виду под усложнением синтаксиса в с++11/14?
lpd>Стандартная библиотека в некоторых отношениях слабее библиотеки Java, при этом сложнее. Из-за чего часто получается, что в проекте используется много небольших библиотек, каждая из которых требует своих опций линковки на каждом из вариантов Linux.
она во многих отношениях слабее явы. До нелюбимого тобой с++11 там даже потоков не было... Что касается опций линковки — ты о чем?
Опять же, более сильная стандартная библиотека не взлетит на тех же мелких контроллерах. Все равно будут какие-то подмножества в каждой области применения.
lpd>Контроль стека имеет теоретическую ценность: в реальности чтобы расстрелять стек нужны или бесконечная рекурсия, или неподходящий алгоритм, что выявить не столь сложно.
Чтобы расстрелять стек / кучу / etc, достаточно обратиться по мусорному указателю. С учетом отсутствия контроля со стороны рантайма, это сделать элементарно — неинициализированная переменная, дважды вызвали деструктор, вышли за границы массива, ...
lpd>Сборщик мусора при желании можно реализовать перегрузкой new/delete и умными указателями. Да, возможно, синтаксис будет несколько сложнее. Но сборка мусора недостаточная причина для использования VM. В том же objective c учет памяти опциональный.
Умные указатели — это не сборщик мусора. Их надо осознанно использовать, обычные указатели никуда не деваются — т.е. есть риск ошибки, циклы разруливаются только руками — снова есть риск ошибки... Сравни это с явовской ссылкой — с ней что-то сделать не так уже значительно сложнее.
lpd>Имею ввиду полностью разный исполняемый код для разных платформ в одном бинарном файле. Код может получаться из одного исходника C++, но с макросами для каждой ОС. Вроде как минимум PE-файлы Windows поддерживали вариант одного бинарника и для x86, и для Alpha.
В смысле — в один exe склеены несколько файлов? Хз насчет Alpha, но win/lin в одном файле я что-то пока не видел А вот явовские софтины, запускающиеся и там и там — встречались
lpd>Если я правильно помню, при появлении Java основным достоинством декларировалась портабельность Java-апплетов, что неактуально. Других существенных достоинств Java, оправдывающих в 8 раз меньшую производительность, кроме теоретически полезной безопасности, обеспечиваемой JVM, по-моему нет.
Мы ж про бизнес-приложения? Тут безопасность рулит, а производительность — не принципиальна. Тут сбоку как раз темка про ява/с++, можешь там ознакомиться
Здравствуйте, lpd, Вы писали:
lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков(вроде Spring, Struts) и lpd>серверов приложений на C++.
Здравствуйте, lpd, Вы писали:
E>>Мы ж про бизнес-приложения? Тут безопасность рулит, а производительность — не принципиальна. Тут сбоку как раз темка про ява/с++, можешь там ознакомиться lpd>Используя C++ можно получить все то же + нормальная производительность, но получается, что ряд мелких недочетов этому мешают и для фреймворков выбирается Java. Но имхо — эти недочеты устранимы без VM.
Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали: SVZ>Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь.
Во многом это так. Особенно если это приложение для малого числа пользователей. Но если есть какая-то обработка данных на Java/сортировка/сложная модель данных, то часто недооценивают проигрыш Java в скорости — пример Android и его тормозящего GUI это показал.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
SVZ>>Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь. lpd>Во многом это так. Особенно если это приложение для малого числа пользователей. Но если есть какая-то обработка данных на Java/сортировка/сложная модель данных, то часто недооценивают проигрыш Java в скорости — пример Android и его тормозящего GUI это показал.
Потребность определяется большинством.
Если пытаться сделать из С++ очередную Яву, то получится не С++ и не Ява, а "неведома зверушка"
Эти единичные приложения, требующие скорости, можно написать и на плюсах, или реализовать на плюсах только критические части. И, кстати, универсальная всемогутор библиотека тут может оказаться лишней. Ежу понятно, что общее решение будет менее эффективно, чем частное.
Собсно, ратуя за всемогущую стандартную библиотеку ты пытаешься лишить плюсы главной фишки — "ничего лишнего".
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Собсно, ратуя за всемогущую стандартную библиотеку ты пытаешься лишить плюсы главной фишки — "ничего лишнего".
Отказ от "теоретичного" разделения язык/библиотека помог бы расширить область применения. По-моему, легче разрабатывать все приложения полностью на одном языке и забыть тормоза Java/C# как страшный сон. Для этого, похоже, нужна или вторая стандартная библиотека, или более удобная система сборки. Т.к. необходимость поддерживать сборку для 10ков подвидов Linux и Unix усложняет заметно усложняет разработку.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков(вроде Spring, Struts) и lpd>серверов приложений на C++.
Это не так. Сервера приложений и фреймворки на C++ существуют, только представляют собой не то, к чему вы привыкли. А именно, это законченные среды выполнения кода на других языках программирования: Java, PHP, Perl, Python, Ruby, CLisp и т.д. совместно с серверами Apache, nginx.
В чистом виде популярные фреймворки на C/C++ используются в проектах KDE/Qt, GNOME/Gtk, LLVM.
Использую FreeBSD. У меня немного приложений на Java, но подавляющее большинство на C/C++.
Здравствуйте, iZEN, Вы писали: ZEN>В чистом виде популярные фреймворки на C/C++ используются в проектах KDE/Qt, GNOME/Gtk, LLVM.
Я неточно задал вопрос. Имел ввиду именно фреймворки для корпоротивных приложений вроде Spring, Struts — таких на C++ я не встречал. Скорректирую исходный пост.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, lpd, Вы писали:
lpd>>Ну вот я и пытаюсь выяснить, что это, в действительности, за причины. AD>Тут уже написали почему: разработка и поддержка корпоративных приложений на плюсах дороже. Причём в разы, а возможно даже на порядок.
Тогда почему именно дороже и как C++ можно улучшить, чтобы эту разницу устранить. Зарплаты C++ программистов не сильно отличаются от зарплат Java-программистов и раньше были значительно ниже. Надо учесть, что для аналогичной производительности на Java число процессоров на увеличивать в разы, что сложнее в администрировании если дело доходит до мейнфреймов. Вообще, это представляется неоправданным и даже не во всех случаях поможет.
Сомневаюсь, что дело только в незнании несложного по сути управления памятью.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, lpd, Вы писали:
lpd>>Имел ввиду именно фреймворки для корпоротивных приложений вроде Spring, Struts — таких на C++ я не встречал. Скорректирую исходный пост.
ZEN>Та ведь С/С++ — это базис, а Java и фреймворки — надстройка (одна из). Надстройка, как правило, решает сугубо частные проблемы, наиболее подходящие по сфере задач и эффективности сопровождения, а базис обслуживает надстройку (надстройки). Ближайший аналог C/C++ в плане доступности, компетентности в применении в прикладных фреймворках — язык Go, но он пока не сильно популярен в силу того, что есть "унаследованный груз кода", который нужно сопровождать. А на это нужны людские ресурсы, а не только деньги.
Да, возможно будущее за Go, D и Rust или каким-то еще языком. Скорее всего, похожим на C++.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Тогда почему именно дороже и как C++ можно улучшить, чтобы эту разницу устранить. Зарплаты C++ программистов не сильно отличаются от зарплат Java-программистов и раньше были значительно ниже. Надо учесть, что для аналогичной производительности на Java число процессоров на увеличивать в разы, что сложнее в администрировании если дело доходит до мейнфреймов. Вообще, это представляется неоправданным и даже не во всех случаях поможет. lpd>Сомневаюсь, что дело только в незнании несложного по сути управления памятью.
Тут фундаментальное непонимание и даже не одно:
1. Цена разработки определяется не величиной зарплаты программистов.
2. Зарплата программистов определяется не уровнем квалификации.
Здравствуйте, lpd, Вы писали:
lpd>Любую программу, которую вы напишете с помощью лямбд, я напишу без них. И ни мне, ни другим программистам не прийдется запоминать синтаксис лямбд или мелких улучшений языка.
ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? )
lpd> Автоопределение возвращаемого функцией типа это ужас, т.к. чтобы понять что мне функция вернет, прийдется читать ее код.
А шаблонные функции (которые принимают не пойми что, и надо читать их код, чтобы понять) — это тоже тогда ужас? )
lpd>Повторюсь, я не против умных указателей и некоторых других улучшений. Но во многих случаях язык становится сложнее без необходимости в этом. Синтаксис C++ интуитивен для любого, кто впервые читает книжку по C++. Расширения C++11 и C++14 требуют запоминать новые обороты — в программировании/администрировании достаточно вещей, которые нужно помнить и без них. Многие расширения C++11 и С++14 для людей, которые именно увлекаются языками программирования как теорией.
Если новые возможности позволяют писать более краткий и простой или безопасный или быстрый код, то значит их надо изучить и использовать. А то так можно было и на ассемблере остаться...
Здравствуйте, alex_public, Вы писали: _>Тут фундаментальное непонимание и даже не одно:
_>1. Цена разработки определяется не величиной зарплаты программистов. _>2. Зарплата программистов определяется не уровнем квалификации.
Это перевод вопроса в экономическую плоскость. Причины начинаются в технических особенностях C++.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
_>Это полная ерунда. Я бы разделил изменения в стандарте C++11 (а C++14 — это всего лишь работа над ошибками в C++11) на следующие пункты:
На самом деле все далеко не так здорово, особенно если сравнивать с шарпом.
_>1. Замыкания/лямбды. Очень важный пункт, позволяющий элементарно реализовывать потрясающие вещи (причём не только из мира ФП). Хотя естественно нечто подобное можно было делать и раньше (см. Boost), но ценой ужасающе кривого кода.
Из тройки C++/Java/C# замыкания/лямбды первыми появились в последнем. И то, что сделали с ними в C++ вызывает.. смешанные чувства. С одной стороны конечно вписали в старый язык, вроде ничего серьезно не поломав. А с другой стороны выглядит вырви глаз и после C# пользоваться таким вообще не хочется. Хотя конечно фломастеры разные.
_>2. Семантика перемещения. Вообще потрясающая вещь, не имеющая прямых аналогов в других языках. Как раз она эффективно решает известную проблему с использованием замыканий без сборщика мусора. Но полезно оно не только для замыканий — с данной техникой производительность приложений на C++ уходит вообще в недостижимый отрыв. Причём что самое интересное, многие старые приложения могут ускориться даже без правки их кода — достаточно их перекомпилировать под новый стандарт.
Скорее просто исправили старый косяк с ссылками, которые были слишком сильно завязаны на семантику указателей. Ну и немного повыносили мозг тем кто стандарт читает.
_>3. Улучшения метапрограммирования (variadic template, constexpr, decltype и т.п.). Это отдельное направление в мире C++, очень активно развивающееся. И кстати говоря не имеющее аналогов в других мейнстрим языках. Правда во многом до сих пор кривое (т.к. изначально шаблоны не для этого придумывались), но работа идёт...
Как минимум C# вполне себе работает с метапрограммированием. Я правда им пользуюсь умеренно, в основном базовые вещи, но по ним вроде одинаково у обоих. Только в шарпе листинги ошибок попроще)) Я не настолько хорошо знаком с Java, но подозреваю, что там тоже может что-то найтись (лямбды же они к себе перетянули).
Здравствуйте, 11molniev, Вы писали:
_>>1. Замыкания/лямбды. Очень важный пункт, позволяющий элементарно реализовывать потрясающие вещи (причём не только из мира ФП). Хотя естественно нечто подобное можно было делать и раньше (см. Boost), но ценой ужасающе кривого кода. 1>Из тройки C++/Java/C# замыкания/лямбды первыми появились в последнем. И то, что сделали с ними в C++ вызывает.. смешанные чувства. С одной стороны конечно вписали в старый язык, вроде ничего серьезно не поломав. А с другой стороны выглядит вырви глаз и после C# пользоваться таким вообще не хочется. Хотя конечно фломастеры разные.
Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...
_>>2. Семантика перемещения. Вообще потрясающая вещь, не имеющая прямых аналогов в других языках. Как раз она эффективно решает известную проблему с использованием замыканий без сборщика мусора. Но полезно оно не только для замыканий — с данной техникой производительность приложений на C++ уходит вообще в недостижимый отрыв. Причём что самое интересное, многие старые приложения могут ускориться даже без правки их кода — достаточно их перекомпилировать под новый стандарт. 1>Скорее просто исправили старый косяк с ссылками, которые были слишком сильно завязаны на семантику указателей. Ну и немного повыносили мозг тем кто стандарт читает.
Фраза "исправили старый косяк" подразумевает, что в тоже время было известно правильное решение. Можно узнать в каком именно языке оно присутствовало? )
_>>3. Улучшения метапрограммирования (variadic template, constexpr, decltype и т.п.). Это отдельное направление в мире C++, очень активно развивающееся. И кстати говоря не имеющее аналогов в других мейнстрим языках. Правда во многом до сих пор кривое (т.к. изначально шаблоны не для этого придумывались), но работа идёт... 1>Как минимум C# вполне себе работает с метапрограммированием. Я правда им пользуюсь умеренно, в основном базовые вещи, но по ним вроде одинаково у обоих. Только в шарпе листинги ошибок попроще)) Я не настолько хорошо знаком с Java, но подозреваю, что там тоже может что-то найтись (лямбды же они к себе перетянули).
Я так понял, под метапрограммированием здесь подразумевалось это?
Так вот не стоит путать метапрограммирование и обобщённое программирование — это абсолютно разные парадигмы, предназначенные для решения совершенно разных задач. И да, обобщённое программирование в C# и C++ не сильно отличается. Но здесь то речь не о нём. Хотя возможно кого-то путает тот факт, что для метапрограммирования в C++ в основном используются те же самые шаблоны, что и для обобщённого (и как раз поэтому МП в C++ достаточно кривое, т.к. изначально шаблоны разрабатывались именно для ОП), хотя и по другому. Но из этого точно невозможно сделать вывод о наличие МП в C# — там нет ничего похожего в принципе. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Poopy Joe, Вы писали:
PJ>>В виде компилятор как сервис. С++ тут нервно курит в сторонке.
_>Тогда конечно же можно увидеть какую-нибудь известную библиотеку, реализующую Embedded DSL на базе этой технологии? )
Библиотеками не интересовался, но вот пример. http://alemiralles.blogspot.be/2012/11/roslyn-shopping-cart-part-1.html
Попытки сделать из с++ какой-то метаязык порождают только нечитаемый кошмар, я уж молчу про сообщения об ошибках и при этом все равно крайне ограниченные возможности.
Здравствуйте, 11molniev, Вы писали:
1>Здравствуйте, D. Mon, Вы писали:
1>>>Как минимум C# вполне себе работает с метапрограммированием.
DM>>В каком виде? Кажется, вы с Алексом тут несколько разные вещи себе представляете.
1>Ну как то так: 1>Differences Between C++ Templates and C# Generics (C# Programming Guide) 1>https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx
Это никакого отношения к метапрограммированию не имеет.
Здравствуйте, 11molniev, Вы писали:
1>Здравствуйте, Poopy Joe, Вы писали:
1>>>Ну как то так: 1>>>Differences Between C++ Templates and C# Generics (C# Programming Guide) 1>>>https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx
PJ>>Это никакого отношения к метапрограммированию не имеет.
1>ОК. А что имеет отношение? В каких языках есть? И чего позволяет достичь, недостижимого в языках с отсутствием этого?
Все что позволяет создавать программы как результат работы программы. До рослина в c# в каком-то виде это было доступно только через рефлексию и expression trees. Есть во многих языках, с++ тут как раз пример где это сделано наиболее убого.
Здравствуйте, Mamut, Вы писали:
_>>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса... M>Мне одному кажется, что по ссылке написан какой-то нечитаемый ад?
Это специфичный код, для его понимания нужно понять используемую там конвенцию о кортежах. Вот
. Только вместо собственного лексера и парсера на flex+bizon используется готовое решение на базе компилятора C#. Можно пообсуждать плюсы и минусы подобного решения, но к нашей теме дискуссии это пример явно не относится.
PJ>Попытки сделать из с++ какой-то метаязык порождают только нечитаемый кошмар, я уж молчу про сообщения об ошибках и при этом все равно крайне ограниченные возможности.
Да, т.к. изначально шаблоны не были предназначены для МП, то оно получилось в C++ весьма кривым. Но при этом есть существенный нюанс: вся сложность проявляется при создание соответствующего МП кода (т.е. лежит на авторах библиотек), а вот использование его обычно не существенно сложнее (вот разве что сообщения об ошибках бывают печальные, и то если авторы библиотеки не озаботились этим вопросом). Ну и в любом случае даже кривой инструмент лучше никакого (как у остальных мейнстрим языков). )))
Здравствуйте, 11molniev, Вы писали:
PJ>>Это никакого отношения к метапрограммированию не имеет. 1>ОК. А что имеет отношение? В каких языках есть? И чего позволяет достичь, недостижимого в языках с отсутствием этого?
В C# ничего. )))
По нормальному есть скажем в D, Rust, Nim, Scala (кажется — слышал от кого-то, но сам не разбирался), Nemerle. По кривому в C++. )))
Позволяет делать такие вещи как Boost.Spirit или sqlpp11 даже с помощью кривого инструмента. А с помощью прямого можно получать уже что-то вроде шаблонизатора в vibe.d (позволяющего вставки нативного кода прямо на странице, причём с полной дальнейшей оптимизацией (инлайнами и т.п.)).
Re[16]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, alex_public, Вы писали:
1>>Как работать то должно? Какую задачу (кроме демонстрации лямбд) этот код должен решить, что на входе, что на выходе? 1>>Ну и как выше подметили, не хотелось бы видеть такое в реальных проектах.
_>Ну то, что компилятор C++ от MS давно отстал от конкурентов и превратился в убогое недоразумение, ни для кого не новость. А вот для компилятора от Intel похоже кто-то забыл включить поддержку C++14... )
icl /Qstd=c++14 /O2 /Wall main.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.179 Build 20150121
Copyright (C) 1985-2015 Intel Corporation. All rights reserved.
main.cpp
main.cpp(9): error: "auto" is not allowed here
auto tuple = [](auto... args)
И дальше поехали ошибочки...
Можно конечно поливать майкрософт грязью, но из четырех распространенных компиляторов два собирать это отказались. Оставшиеся два выше выдали диаметрально противоположный результат.
Что на выходе то быть должно? "8 7 6 54 3 2 1" или "1 2 3 45 6 7 8"? В не отстающем gcc или в не убогом clang баг?
_>Что касается самого кода, то он демонстрирует альтернативную (т.к. в C++ и так есть std::tuple) реализацию кортежей, на замыканиях. А так же работу с ними (слияние, применение функции). Кстати, этот пример должен быть весьма актуален как раз для C# — там же стандартные кортежи очень забавные, кажется максимум на 8 элементов, да? )))
Какую задачу (кроме демонстрации лямбд) этот код должен решить, что на входе, что на выходе?
Ок, кроме демонстрации лямбд, замыкания, кортежей?
Да, действительно на 8-мь элементов. Правда восьмым может быть вложенный кортеж. Но поскольку я дальше двух элементов вроде не уходил не в курсе, насколько это удобно.
_>>>Фраза "исправили старый косяк" подразумевает, что в тоже время было известно правильное решение. Можно узнать в каком именно языке оно присутствовало? ) 1>>Ха! Нужно поискать язык где бы оно отсутствовало. Сам факт лишних копирований был вызван таким подходом к семантике ссылок и увлечением абстракциями ООП. За абстракции всегдла надо платить.
_>Т.е. снова сравниваем разную функциональность? ) Естественно, что если делать убогую реализацию без RAII и со сборщиком мусора, то нет проблем. Два простейших примера:
_>1. У нас есть отдельные строки (по гигабайту каждая, для остроты ощущений) и пустой массив строк. Мы хотим положить одну строку в массив. Но чтобы при этом естественно не происходило копирования гигабайта. Ну и само собой при удаление массива все строки в нём должны удаляться. _> — C: можно наколбасить руками эффективную реализацию _> — Java/C#: работает автоматически, но не эффективно (сборщик мусора со всеми печальными последствиями из этого) _> — C++: работает автоматически и эффективно _> — так какой там язык давно имел эффективное автоматическое решение данной проблемы? Это как раз тот пример, где оверхейд сборки мусора ничтожен. Много больших объектов... нет взаимной ссылочности... и нет печальных последствий.
И кстати насчет автоматически и эффективно. Если будет не массив, а свой контейнер к примеру? В Java/C# все действительно будет автоматически, а в C++ напиши ручками все полагающиеся методы value/lvalue/rvalue. Последнее требует немного большей квалификации, поэтому иногда и соглашаются на сборщик мусора. Так проще))
_>2. У нас есть объект, инкапсулирующий в себе некое соединение по сети и пустой массив такого же типа. Мы хотим положить этот объект в массив. Естественно мы хотим, чтобы при удаление массива все соединения закрывались. _> — C: можно наколбасить руками эффективную реализацию _> — Java/C#: можно наколбасить руками эффективную реализацию _> — C++: работает автоматически и эффективно _> — так какой там язык давно имел эффективное автоматическое решение данной проблемы?
Ну вот как-то совсем не вкурил разница между Java/C# и C++ тут в чем будет? Пример кода управляемого и нет можно?
_>В общем, если подвести итог, то можно сказать, что МП: _>- в Java/C# просто нет _>- в C++ есть, криво-косое _>- в D, Nemerle и т.п. есть, нормальное.
_>Но есть один нюанс: мейнстрим языками тут являются только первые три... )
Понятно. Маленький нюанс ещё в том, что хотя последний язык и является мейнстримом, та часть, что ты называешь метапрограммированием нет. По крайней мере пока.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь.
Интересно, трейдинг — это корпоративные приложения? А какой-нибудь АСУ ТП?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
SVZ>>Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь.
Ops>Интересно, трейдинг — это корпоративные приложения? А какой-нибудь АСУ ТП?
А какой-нибудь САПР? А како-нибудь биллинг, а (подставить по вкусу)?
Что ты хочешь услышать?
Да, есть нагруженный софт. К нему и требования не такие, как к ERP.
Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону).
Моё ИМХО — нет, не выиграет. Только инструмент (С++) будет испорчен.
Для таких приложений возможно подошел бы D, но он пока сырой и непонятно, взлетит ли.
Существующего С++ вполне хватает. Да, выше трудоемкость, нужна более высокая квалификация разработчиков. Но об этом коллеги уже высказались.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А какой-нибудь САПР? А како-нибудь биллинг, а (подставить по вкусу)? SVZ>Что ты хочешь услышать?
Что все-таки не большинство ждет базу.
SVZ>Да, есть нагруженный софт. К нему и требования не такие, как к ERP.
Угу. ERP — это электронное перекладывание бумажек, и это далеко не всегда основное занятие бизнеса. SVZ>Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону).
Либу — только за, при условии низкой связности модулей. 100500 велосипедов, раскиданных по разным крупным библиотекам, реально задалбывают, и часто вынуждают писать свои велосипеды под проект. Но тут другая сложность, в отличие от явы с дотнетом, здесь мы имеем неповоротливый комитет и кучу формалистики, для подобной библиотеки такой подход нежизнеспособен. Да, есть буст, который развивается по гораздо лучшей модели, но там уже начинается коллективное безответственное с поддержкой некоторых библиотек. Ну и до сих пор слышу про его категорическое неприятие и запрет в некоторых проектах, из которых процент аргументированных в окрестностях 0.
SVZ>Моё ИМХО — нет, не выиграет. Только инструмент (С++) будет испорчен.
С чего вдруг он будет испорчен? При всех его минусах, библиотекой с ним ничего не сделаешь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, 11molniev, Вы писали:
_>>Ну то, что компилятор C++ от MS давно отстал от конкурентов и превратился в убогое недоразумение, ни для кого не новость. А вот для компилятора от Intel похоже кто-то забыл включить поддержку C++14... ) 1>
1>icl /Qstd=c++14 /O2 /Wall main.cpp
1>Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.179 Build 20150121
1>Copyright (C) 1985-2015 Intel Corporation. All rights reserved.
1>main.cpp
1>main.cpp(9): error: "auto" is not allowed here
1> auto tuple = [](auto... args)
1>
1>И дальше поехали ошибочки...
Ааа, ну 15-ая версия. Поддержка полиморфных лямбд у них с 16-ой.
1>Можно конечно поливать майкрософт грязью, но из четырех распространенных компиляторов два собирать это отказались. Оставшиеся два выше выдали диаметрально противоположный результат.
Тут вот уже показали, что даже убогий C++ от MS уже поддерживает, просто в последней версии. Так что в итоге поддерживают все четыре.
1>Что на выходе то быть должно? "8 7 6 54 3 2 1" или "1 2 3 45 6 7 8"? В не отстающем gcc или в не убогом clang баг?
В данном примере же это не принципиально.
1>Ок, кроме демонстрации лямбд, замыкания, кортежей?
Это не демонстрация работы готовых кортежей (типа std::tuple), а демонстрация рабочей реализации кортежей в пару строк (на полиморфных лямбдах). Разница думаю понятна? ) Естественно никто не собирается использовать такие кортежи в реальной работе, тем более, что есть std::tuple. Пример демонстрирует, что их можно легко создать с помощью такого мощного инструмента, как современные лямбды в C++.
1>Да, действительно на 8-мь элементов. Правда восьмым может быть вложенный кортеж. Но поскольку я дальше двух элементов вроде не уходил не в курсе, насколько это удобно.
Кстати, для двух элементов в C++ есть более удобный std::pair. А много элементов — это удобно, но при условие, что язык поддерживает всякие удобные техники работы с ними (типа автоматического разворачивания в наборы параметров и т.п.).
1> Это как раз тот пример, где оверхейд сборки мусора ничтожен. Много больших объектов... нет взаимной ссылочности... и нет печальных последствий.
Главный оверхед сборки мусора проявляется не таким тривиальным образом. А запретом на реализацию действительного эффективного кода и плюс недетерминированными задержками.
1>И кстати насчет автоматически и эффективно. Если будет не массив, а свой контейнер к примеру? В Java/C# все действительно будет автоматически, а в C++ напиши ручками все полагающиеся методы value/lvalue/rvalue. Последнее требует немного большей квалификации, поэтому иногда и соглашаются на сборщик мусора. Так проще))
Если хочется тормозное решение повышенной косвенности типа Java/C# то это делается элементарно — shared_ptr. При этом мы даже получим полноценный RAII с детерминированными задержками. Однако для мира C++ это всё равно не эффективное решение. А если хочется реальной эффективности, то надо чуть постараться и реализовать поддержку семантики перемещения. Тем более, что во всех классах из стандартной библиотеки это уже реализовано.
_>>2. У нас есть объект, инкапсулирующий в себе некое соединение по сети и пустой массив такого же типа. Мы хотим положить этот объект в массив. Естественно мы хотим, чтобы при удаление массива все соединения закрывались. _>> — C: можно наколбасить руками эффективную реализацию _>> — Java/C#: можно наколбасить руками эффективную реализацию _>> — C++: работает автоматически и эффективно _>> — так какой там язык давно имел эффективное автоматическое решение данной проблемы? 1>Ну вот как-то совсем не вкурил разница между Java/C# и C++ тут в чем будет? Пример кода управляемого и нет можно?
Как на Java/C# получить автоматическое закрытие всех соединений сразу после удаления массива? На C++ это будет просто закрытие соединение в деструкторе объекта обёртки.
Здравствуйте, Poopy Joe, Вы писали:
_>>Ха, так это не Embedded DSL — зачем он в теме про МП? Это в точности реализация пункта 2 отсюда http://rsdn.ru/forum/philosophy/6116603.1
. Только вместо собственного лексера и парсера на flex+bizon используется готовое решение на базе компилятора C#. Можно пообсуждать плюсы и минусы подобного решения, но к нашей теме дискуссии это пример явно не относится. PJ>Это Embedded DSL. Может ты под этим что-то свое понимаешь, но тогда давай определение своих терминов.
Это обычный DSL, правда реализованный сомнительным способом — с помощью некого препроцессора перед компилятором C#. Если это EDSL, то тогда можно будет вставить все эти куски с when и т.п. внутрь нормального C# кода и он нормально соберётся? )
PJ>Использование их вообще кошмар. Ну сообщает оно, что в вариадик темплейте какая-то ошибка. И что?
А в чём кошмар? ) Я вот легко использую тот же Boost.Spirit и не испытываю никаких сложностей. Более того, мне при этом даже не требуются какие-то знания о техниках метапрограммирования.
PJ>У остальных "мейстрим" языков нет никакой проблемы, потому что нет привязки к языку. Ничего не мешает писать часть на c#, часть на f# часть на хоть на том же с++. Предоставляя в совокупности гораздо более мощный инструмент, чем любые шаблоны. В с++ же полный ад. Проблемы возникают даже внутри с++. Хочется использовать VS2015 и с++14? Будешь сидеть на VS2012, просто потому что какой-нибудь производитель библиотеки не считает нужным поддерживать что-то новее.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, lpd, Вы писали:
lpd>>Идея в том, что если: lpd>>1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч. Ops>Я написал про проблемы добавления в стандартную либу. Но да, идея вполне нормальная. lpd>>2) сделать системы сборки более интуитивными Ops>Какие ваши предложения? Даже если сделать стандартную систему сборки, останутся еще гигатонны легаси, под нее не приспособленные.
Слышал но не видел, что у Java удобные системы сборки. В любом случае make несколько стар. lpd>>3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок. Ops>Этого не понял. Подсчет ссылок есть у shared_ptr.
Кроме подсчета ссылок в Objective-C память очищается когда счетчик ссылок объекта оказывается=0. Правда, есть некоторые проблемы с круговыми ссылками. Но виртуальная машина только для сборки мусора- это перебор. lpd>>4) на правах флейма: убрать C++11 и C++14 Ops>Зачем? Тебя ж никто не заставляет использовать эти фичи. А многим это сильно упрощает жизнь.
Если один программист будет использовать эти фичи в проекте, то остальным прийдется их учить. Что имхо невыносимо ибо на бесполезно, т.к. С++14/11 добавляют в С++ примерно тоже количество новых синтаксических конструкций, которое было в исходном С++; при этом мало в чем реально помогая. C++14 может и красив, но только для ценителей языков программирования. lpd>>То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java. Ops>Легко использовать никогда не получится, придется все же учить.
Имеется ввиду, что, например, менеджер памяти облегчает отладку, а система сборки может быть интуитивна.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[18]: так все же gcc или clang компилирует этот код правильно?
Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...
1>>Что на выходе то быть должно? "8 7 6 54 3 2 1" или "1 2 3 45 6 7 8"? В не отстающем gcc или в не убогом clang баг? _>В данном примере же это не принципиально.
Собственно на этом можно заканчивать...
_>Это не демонстрация работы готовых кортежей (типа std::tuple), а демонстрация рабочей реализации кортежей в пару строк (на полиморфных лямбдах). Разница думаю понятна? ) Естественно никто не собирается использовать такие кортежи в реальной работе, тем более, что есть std::tuple. Пример демонстрирует, что их можно легко создать с помощью такого мощного инструмента, как современные лямбды в C++.
Да, С++ нереально крут и аналог легкого и мощного Boost.Spirit в C#/Java не сделать.
_>Кстати, для двух элементов в C++ есть более удобный std::pair. А много элементов — это удобно, но при условие, что язык поддерживает всякие удобные техники работы с ними (типа автоматического разворачивания в наборы параметров и т.п.).
Я и написал, что std::tuple пользоваться не приходилось.
1>> Это как раз тот пример, где оверхейд сборки мусора ничтожен. Много больших объектов... нет взаимной ссылочности... и нет печальных последствий. _>Главный оверхед сборки мусора проявляется не таким тривиальным образом. А запретом на реализацию действительного эффективного кода и плюс недетерминированными задержками.
Эффективность определяется в первую очередь руками. И на счет эффективности и насчет Stop world — это никак не отменяет, что именно в приведенном примере эти эффекты наблюдать не будут. Ты привел именно тот крайний случай когда все будет близко к паритету, но поскольку не знаком с особенностями строк, работой менеджеров памяти Java/C# и их GC считаешь иначе. Ну или у меня сложилось впечатление, что не знаком.
_>Если хочется тормозное решение повышенной косвенности типа Java/C# то это делается элементарно — shared_ptr. При этом мы даже получим полноценный RAII с детерминированными задержками. Однако для мира C++ это всё равно не эффективное решение. А если хочется реальной эффективности, то надо чуть постараться и реализовать поддержку семантики перемещения. Тем более, что во всех классах из стандартной библиотеки это уже реализовано.
Вот тут то и выплывает, что если хочется энтерпрайзно С++ не так уж и хорош, а том и речь, что бери shared_ptr. А если хочется быстро, то уже нужны мозги.
_>>>2. У нас есть объект, инкапсулирующий в себе некое соединение по сети и пустой массив такого же типа. Мы хотим положить этот объект в массив. Естественно мы хотим, чтобы при удаление массива все соединения закрывались. 1>>Ну вот как-то совсем не вкурил разница между Java/C# и C++ тут в чем будет? Пример кода управляемого и нет можно? _>Как на Java/C# получить автоматическое закрытие всех соединений сразу после удаления массива? На C++ это будет просто закрытие соединение в деструкторе объекта обёртки.
На Java/C# это будет просто закрытие соединений в деструкторе объекта обертки? Я вообще потому и прошу пример кода, что в упор не вижу разницы.
Re[19]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, 11molniev, Вы писали:
1>Собственно на этом можно заканчивать...
Ну т.е. в итоге так и записываем: лямбды в C# не сравнимо слабее по функциональности C++ реализации.
_>>Главный оверхед сборки мусора проявляется не таким тривиальным образом. А запретом на реализацию действительного эффективного кода и плюс недетерминированными задержками. 1>Эффективность определяется в первую очередь руками. И на счет эффективности и насчет Stop world — это никак не отменяет, что именно в приведенном примере эти эффекты наблюдать не будут. Ты привел именно тот крайний случай когда все будет близко к паритету, но поскольку не знаком с особенностями строк, работой менеджеров памяти Java/C# и их GC считаешь иначе. Ну или у меня сложилось впечатление, что не знаком.
Stop world шёл у меня отдельным пунктом (недетерминированные задержки). А неэффективность появляется в других местах: повышенная косвенность (это критично для современных процессоров, т.к. данные начинают идти не из кэша), невозможность нормальной работы с указателями (т.е. недоступны самые эффективные техники типа арифметики указателей и SIMD) и т.д. и т.п.
1>Вот тут то и выплывает, что если хочется энтерпрайзно С++ не так уж и хорош, а том и речь, что бери shared_ptr. А если хочется быстро, то уже нужны мозги.
А с этим никто и не спорил.
_>>Как на Java/C# получить автоматическое закрытие всех соединений сразу после удаления массива? На C++ это будет просто закрытие соединение в деструкторе объекта обёртки. 1>На Java/C# это будет просто закрытие соединений в деструкторе объекта обертки? Я вообще потому и прошу пример кода, что в упор не вижу разницы.
Ну так а в какой момент будет вызван этот самый деструктор? )))
Здравствуйте, lpd, Вы писали:
lpd>Слышал но не видел, что у Java удобные системы сборки. В любом случае make несколько стар.
Так что с легаси-то делать? lpd>Если один программист будет использовать эти фичи в проекте, то остальным прийдется их учить. Что имхо невыносимо ибо на бесполезно, т.к. С++14/11 добавляют в С++ примерно тоже количество новых синтаксических конструкций, которое было в исходном С++; при этом мало в чем реально помогая. C++14 может и красив, но только для ценителей языков программирования.
То же самое про старые плюсы: если один программист будет использовать многоэтажного Александреску...
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, lpd, Вы писали:
lpd>>Слышал но не видел, что у Java удобные системы сборки. В любом случае make несколько стар. Ops>Так что с легаси-то делать?
Главное перевести библиотеки для постепенного перевода проектов. А make можно продолжать поддерживать, как и текущий stl.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[20]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, alex_public, Вы писали:
1>>Собственно на этом можно заканчивать... _>Ну т.е. в итоге так и записываем: лямбды в C# не сравнимо слабее по функциональности C++ реализации.
Ага. Лямбды в C# не позволяют получить разный результат на выходе программы в зависимости от компилятора.
Ты кстати так и не смог объяснить что должно быть на входе, что на выходе. Код ради кода.
_>Stop world шёл у меня отдельным пунктом (недетерминированные задержки). А неэффективность появляется в других местах: повышенная косвенность (это критично для современных процессоров, т.к. данные начинают идти не из кэша), невозможность нормальной работы с указателями (т.е. недоступны самые эффективные техники типа арифметики указателей и SIMD) и т.д. и т.п.
JIT убивает повышенную косвенность. C# no safe нормально работает с сырыми указателями, адресной арифметикой и неуправляемой памятью. Не говоря о том, что часть этих вещей работает и сама по себе через JIT. То, что языки с управляемой памятью и JIT имеют свои проблемы ну никак не отменяет того, что ты привел крайне неудачный пример, в котором они незаметны.
Пойми я же ничего не имею против, того что C#/Java не в меру жрут память и могут подтормаживать, но блин, ты привел именно тот случай когда этого не будет. Вот и всё.
_>>>Как на Java/C# получить автоматическое закрытие всех соединений сразу после удаления массива? На C++ это будет просто закрытие соединение в деструкторе объекта обёртки. 1>>На Java/C# это будет просто закрытие соединений в деструкторе объекта обертки? Я вообще потому и прошу пример кода, что в упор не вижу разницы. _>Ну так а в какой момент будет вызван этот самый деструктор? )))
Если под удалением массива ты имеешь в виду область видимости, то в момент выхода из using.
Если динамическое управление, то IDisposable, и в терминах C# не деструктор, а финализатор.
Здравствуйте, Ops, Вы писали:
SVZ>>Да, есть нагруженный софт. К нему и требования не такие, как к ERP. Ops>Угу. ERP — это электронное перекладывание бумажек, и это далеко не всегда основное занятие бизнеса.
Зато очень распространенное и там Шарп/Ява очень уместны.
SVZ>>Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону). Ops>Либу — только за, при условии низкой связности модулей. 100500 велосипедов, раскиданных по разным крупным библиотекам, реально задалбывают, и часто вынуждают писать свои велосипеды под проект. Но тут другая сложность, в отличие от явы с дотнетом, здесь мы имеем неповоротливый комитет и кучу формалистики, для подобной библиотеки такой подход нежизнеспособен. Да, есть буст, который развивается по гораздо лучшей модели, но там уже начинается коллективное безответственное с поддержкой некоторых библиотек. Ну и до сих пор слышу про его категорическое неприятие и запрет в некоторых проектах, из которых процент аргументированных в окрестностях 0.
С библиотекой тут получается интересное. С одной стороны хочется иметь всё "из коробки", а с другой стороны всегда будет ситуация, когда вроде бы инструмент есть, а по каким-то критериям не подходит. Вроде бы и надо велосипед писать, а западло — есть же "стандартный"
Сейчас проще — либо буст, либо велосипед (свой или чужой)
С запретом Буста я сталкивался в двух проектах, оба были связаны с кривыми компиляторами С++ на специфических платформах (HP-UX, z/OS). Там не то что буст, стандартную-то либу можно было использовать с оглядкой.
SVZ>>Моё ИМХО — нет, не выиграет. Только инструмент (С++) будет испорчен. Ops>С чего вдруг он будет испорчен? При всех его минусах, библиотекой с ним ничего не сделаешь.
Ну библиотекой, наверное, не испортишь. В конце концов никто не заставляет использовать только стандартную библиотеку.
А вот если попытаться впихнуть в язык что-то невпихуемое, то запросто.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>С библиотекой тут получается интересное. С одной стороны хочется иметь всё "из коробки", а с другой стороны всегда будет ситуация, когда вроде бы инструмент есть, а по каким-то критериям не подходит. Вроде бы и надо велосипед писать, а западло — есть же "стандартный" SVZ>Сейчас проще — либо буст, либо велосипед (свой или чужой)
Ну так и со стандартной библиотекой так же, она тоже не всегда подходит, но в большинстве случаев годится, при этом дает хорошую переносимость и единообразность там, где не надо выжимать такты или делать что-то специфичное. Ничего не мешает ее расширить исходя из такого подхода, сразу намного легче станет. Причем это делается, добавляют библиотеки из того же буста. Только вот очень медленно, и при этом развитие включенных в стандарт библиотек замораживается.
SVZ>С запретом Буста я сталкивался в двух проектах, оба были связаны с кривыми компиляторами С++ на специфических платформах (HP-UX, z/OS). Там не то что буст, стандартную-то либу можно было использовать с оглядкой.
Ну вот даже на форуме часто пишут "буст не предлагать", в т.ч. для распространенных платформ. Почему-то многие его воспринимают как что-то монолитное, исключительно на многоэтажных шаблонах, вдобавок считают, что и для использования придется их писать. А ведь и с твоими компиляторами наверняка можно было что-то использовать практически искаропки.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[21]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, 11molniev, Вы писали:
_>>Ну т.е. в итоге так и записываем: лямбды в C# не сравнимо слабее по функциональности C++ реализации. 1>Ага. Лямбды в C# не позволяют получить разный результат на выходе программы в зависимости от компилятора. 1>Ты кстати так и не смог объяснить что должно быть на входе, что на выходе. Код ради кода.
Данный нюанс не имеет никакого отношения к лямбдам, а является всего лишь следствием особенностей данного конкретного кода. Если есть желание, то можем и его обсудить. Для начала начнём с вопроса о том, в каких языках с наличием функции map (или аналога) в стандарте закреплена очерёдность обхода элементов. Потом можем обсудить особенности использования нечистых функций (типа вывода на консоль) в функциях типа map и т.д. и т.п. Но к лямбдам это не будет иметь никакого отношения — всё тоже самое касается и обычных функций, причём в любых языках.
_>>Stop world шёл у меня отдельным пунктом (недетерминированные задержки). А неэффективность появляется в других местах: повышенная косвенность (это критично для современных процессоров, т.к. данные начинают идти не из кэша), невозможность нормальной работы с указателями (т.е. недоступны самые эффективные техники типа арифметики указателей и SIMD) и т.д. и т.п. 1>JIT убивает повышенную косвенность. C# no safe нормально работает с сырыми указателями, адресной арифметикой и неуправляемой памятью. Не говоря о том, что часть этих вещей работает и сама по себе через JIT. То, что языки с управляемой памятью и JIT имеют свои проблемы ну никак не отменяет того, что ты привел крайне неудачный пример, в котором они незаметны.
1>Пойми я же ничего не имею против, того что C#/Java не в меру жрут память и могут подтормаживать, но блин, ты привел именно тот случай когда этого не будет. Вот и всё.
Так весь фокус в том, что мы не можем (в Java/C#) использовать для данного нюанса сборщик мусора, а для всего остального что-то другое, более эффективное. Т.е. для того, чтобы у нас появилась возможность автоматического решения в данном нюансе, мы автоматически накладываем ограничение по тормозам вообще на всё приложение.
_>>Ну так а в какой момент будет вызван этот самый деструктор? ))) 1>Если под удалением массива ты имеешь в виду область видимости, то в момент выхода из using. 1>Если динамическое управление, то IDisposable, и в терминах C# не деструктор, а финализатор.
Вот про using и IDisposable речь и идёт — это и есть рукопашный код в стиле C.
Здравствуйте, lpd, Вы писали:
lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков для разработки корпоративных приложений(вроде Spring, Struts) и серверов приложений на C++.
Вот с этим явовским "корпоративные приложения", можете оставаться в яве по уши. На С++ можно писать
любые приложения, решающие любые задачи. Хоть корпоративными их можно назвать хоть некорпоративными.
В чём вообще проблема? Не только на C++, хоть на Lisp написать можно что угодно, хоть корпоративное хоть
некорпоративное. А если для любого чиха прогеру обязательно нужен набор функций с длиннющими названиями, корпоративными,
то это технология деградации, а не технология развития.
Здравствуйте, lpd, Вы писали:
lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков для разработки корпоративных приложений(вроде Spring, Struts) и серверов приложений на C++.
Главное, не на чем писать, а что.
Если вы пишете скучную корпоративную хрень, то лучшее ее вообще не писать, ни на java, ни на C++
Здравствуйте, alex_public, Вы писали:
_>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...
Где, кому и зачем может потребоваться это лютое говно?
Какие реальные задачи оно решает или может решить?
Здравствуйте, lpd, Вы писали:
lpd>Если в терминологии wikipedia{C++11}{C++14}: lpd>lamda-выражения считаю бесполезными — если мне надо вызвать несколько функций, я их вызову без lambda. lpd>Alternative function syntax — зачем? lpd>User-defined literals — бесполезно. lpd>Function return type deduction — ужас lpd>Variable templates — бесполезно
Ты на С++ писал, как на Си, только с классами, да?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, AlexRK, Вы писали:
_>>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса... ARK> ARK>Где, кому и зачем может потребоваться это лютое говно? ARK>Какие реальные задачи оно решает или может решить?
Это демонстрация возможностей лямбд в C++. Конкретно этот код на практике не нужен. Хотя бы потому, что в стандартную библиотеку уже и так входят готовые кортежи (реализованные не через лямбды). Однако он очень хорошо демонстрирует сами возможности языка, а уж где их применить с пользой, думаю и так очевидно.
Здравствуйте, lpd, Вы писали:
lpd>Возможно, в некоторых случаях ламбды сокращают код. Но любую программу можно написать без них (вроде Тьюринг еще доказывал).
Любишь писать тетрисы на Брейнфаке? Он тоже тьюринг-полон.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, alex_public, Вы писали:
_>1. У нас есть отдельные строки (по гигабайту каждая, для остроты ощущений) и пустой массив строк. Мы хотим положить одну строку в массив. Но чтобы при этом естественно не происходило копирования гигабайта. Ну и само собой при удаление массива все строки в нём должны удаляться. _> — C: можно наколбасить руками эффективную реализацию _> — Java/C#: работает автоматически, но не эффективно (сборщик мусора со всеми печальными последствиями из этого) _> — C++: работает автоматически и эффективно _> — так какой там язык давно имел эффективное автоматическое решение данной проблемы?
Дельфи?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[18]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, T4r4sB, Вы писали:
_>>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? ) TB>Нефиг делать, как только я пойму, что в нём вообще происходит. А с этим хреново. Пожалуй, этот код демонстрирует недостатки лямбд и вариадиков.
Там создают полноценные кортежи и функции работы с ними (map и т.п.) из лямбд.
С удовольствием посмотрю на аналогичную реализацию на Java/C#. Особенно с учётом того, что в .net вообще не осилили нормальные кортежи (ограничение на 8 элементов — это же смешно) даже просто классами, а не лямбдами.
Re[19]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, alex_public, Вы писали:
_>С удовольствием посмотрю на аналогичную реализацию на Java/C#. Особенно с учётом того, что в .net вообще не осилили нормальные кортежи (ограничение на 8 элементов — это же смешно) даже просто классами, а не лямбдами.
Да хоть на чистой сишке. Понятно, что придётся каждый частный случай вручную расписывать. Но теоретически расписать можно. Главное — это подождать, когда хотя бы компиляторы определятся, как же понимать этот код
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
_>>С удовольствием посмотрю на аналогичную реализацию на Java/C#. Особенно с учётом того, что в .net вообще не осилили нормальные кортежи (ограничение на 8 элементов — это же смешно) даже просто классами, а не лямбдами. TB>Да хоть на чистой сишке. Понятно, что придётся каждый частный случай вручную расписывать. Но теоретически расписать можно. Главное — это подождать, когда хотя бы компиляторы определятся, как же понимать этот код
Там дело всего лишь в неопределённом порядке argument evaluation, это вообще ортогональная тема. Если нужен жёсткий порядок — то без проблем форсится.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если нужен жёсткий порядок — то без проблем форсится.
Да, можно завести временные переменные и явно всё расписать. Я боюсь, если в этом коде всё явно расписать, то он потеряет всю свою загадочность.
Возможно, есть какой-то трюк, чтобы заставить параметры функции выполняться в верном порядке, и без временных переменных. Только пожалуйста, не показывайте его, мне на сегодня кода с лямбдами хватило.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
_>>С удовольствием посмотрю на аналогичную реализацию на Java/C#. Особенно с учётом того, что в .net вообще не осилили нормальные кортежи (ограничение на 8 элементов — это же смешно) даже просто классами, а не лямбдами. TB>Да хоть на чистой сишке. Понятно, что придётся каждый частный случай вручную расписывать. Но теоретически расписать можно. Главное — это подождать, когда хотя бы компиляторы определятся, как же понимать этот код
Здравствуйте, T4r4sB, Вы писали:
EP>>Если нужен жёсткий порядок — то без проблем форсится. TB>Да, можно завести временные переменные и явно всё расписать. Я боюсь, если в этом коде всё явно расписать, то он потеряет всю свою загадочность. TB>Возможно, есть какой-то трюк, чтобы заставить параметры функции выполняться в верном порядке, и без временных переменных. Только пожалуйста, не показывайте его, мне на сегодня кода с лямбдами хватило.
Ещё раз повторяю: прежде чем делать этот жёсткий порядок, в начале покажите мне пример строго определения очерёдности обхода функцией map коллекции.
Здравствуйте, T4r4sB, Вы писали:
TB>>>Дельфи? _>>Не знаком (подробно), не знаю. ) TB>Строки и динмассивы через счётчик ссылок, строки коровьи (COW, то есть при записи копируются), но мы ж вроде писать в них не собираемся?
Подсчёт ссылок — это тоже не эффективно в большинстве случаев.
Здравствуйте, T4r4sB, Вы писали:
_>>Что за лямбды в C? ) TB>Лямбда — это просто структура с методом (). В сишке это будет структура Lambda1337 и функция TB>
Здравствуйте, alex_public, Вы писали:
_>Ещё раз повторяю: прежде чем делать этот жёсткий порядок, в начале покажите мне пример строго определения очерёдности обхода функцией map коллекции.
Я для начала не понимаю, что тут мап делает. Возвращает какую-то функцию, возвращающую функцию, которая...
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, T4r4sB, Вы писали:
TB>>>>Дельфи? _>>>Не знаком (подробно), не знаю. ) TB>>Строки и динмассивы через счётчик ссылок, строки коровьи (COW, то есть при записи копируются), но мы ж вроде писать в них не собираемся?
_>Подсчёт ссылок — это тоже не эффективно в большинстве случаев.
Любой жёсткий алгоритм на все случаи жизни будет неэффективен в большинстве случаев, ты вроде про какую-то конкретную задачу говорил.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
EP>>Если нужен жёсткий порядок — то без проблем форсится. TB>Да, можно завести временные переменные и явно всё расписать. Я боюсь, если в этом коде всё явно расписать, то он потеряет всю свою загадочность.
Я к тому что это не баг, а фича. Даже если не брать в расчёт особенность порядка evaluation аргументов в C++ — то всё равно map'у обычно соответствует произвольный порядок, точнее для map порядок не важен. Если важен, то это выражается через другие примитивы — foldl, for_each.
Кстати, например std::transfrom не гарантирует порядок, а std::for_each гарантирует.
TB>Возможно, есть какой-то трюк, чтобы заставить параметры функции выполняться в верном порядке, и без временных переменных.
Да, помимо прямого способа есть трюк.
TB>Только пожалуйста, не показывайте его, мне на сегодня кода с лямбдами хватило.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, lpd, Вы писали:
lpd>>Если в терминологии wikipedia{C++11}{C++14}: lpd>>lamda-выражения считаю бесполезными — если мне надо вызвать несколько функций, я их вызову без lambda. lpd>>Alternative function syntax — зачем? lpd>>User-defined literals — бесполезно. lpd>>Function return type deduction — ужас lpd>>Variable templates — бесполезно
TB>Ты на С++ писал, как на Си, только с классами, да?
Даже если усложнить C++ еще парой десятков вариадиков и лямбд, для фреймворков его использовать больше не будут. А в каком случае будут, и далеко ли до этого, — вопрос этого топика.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, AlexRK, Вы писали:
ARK>Какие реальные задачи оно решает или может решить?
Например есть набор разнотипных объектов поддерживающих одинаковую функцию draw. Эти объекты нужно где-то хранить и делать обход с вызовом draw.
Если решать через наследование с виртуальными функциями, положив всё в один массив — то получаем overhead от косвенных вызовов, лишних индерекций, аллокаций и т п.
Альтернативный вариант — класть объект каждого типа в свой отдельный массив соответствующего типа. А при обходе обрабатывать массивы по-очереди — сначала первый массив, потом второй и т.п. — в этом случае не будет ни косвенных вызовов, ни лишних индерекций и т.п.
Вручную выписывать каждый контейнер, а потом выписывать каждый вариант обхода, да ещё и следить за изменением списка типов не удобно. Вот как раз для автоматизации всего этого и используются библиотеки подобного рода (например Boost.Fusion или Hana).
Здравствуйте, T4r4sB, Вы писали:
_>>Ещё раз повторяю: прежде чем делать этот жёсткий порядок, в начале покажите мне пример строго определения очерёдности обхода функцией map коллекции. TB>Я для начала не понимаю, что тут мап делает. Возвращает какую-то функцию, возвращающую функцию, которая...
Ну это особенность реализации кортежа через лямбды. Т.е. кортеж — это замыкание, которое принимает другую функцию (и применяет её к данным).
Но я говорил про другое. Что данный данная реализация кортежей в общем то корректна (хотя это всего лишь демо пример лямбд) и соответствует общепринятым техникам в функциональном программирование. Единственная небольшая некорректность там, это использование в map нечистой функции (вывода на консоль).
Здравствуйте, T4r4sB, Вы писали:
TB>>>Строки и динмассивы через счётчик ссылок, строки коровьи (COW, то есть при записи копируются), но мы ж вроде писать в них не собираемся? _>>Подсчёт ссылок — это тоже не эффективно в большинстве случаев. TB>Любой жёсткий алгоритм на все случаи жизни будет неэффективен в большинстве случаев, ты вроде про какую-то конкретную задачу говорил.
В данном конкретном примере тоже не эффективно (по сравнению с реализацией в современном C++).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Например есть набор разнотипных объектов поддерживающих одинаковую функцию draw. Эти объекты нужно где-то хранить и делать обход с вызовом draw. EP>Если решать через наследование с виртуальными функциями, положив всё в один массив — то получаем overhead от косвенных вызовов, лишних индерекций, аллокаций и т п. EP>Альтернативный вариант — класть объект каждого типа в свой отдельный массив соответствующего типа. А при обходе обрабатывать массивы по-очереди — сначала первый массив, потом второй и т.п. — в этом случае не будет ни косвенных вызовов, ни лишних индерекций и т.п.
EP>Вручную выписывать каждый контейнер, а потом выписывать каждый вариант обхода, да ещё и следить за изменением списка типов не удобно. Вот как раз для автоматизации всего этого и используются библиотеки подобного рода (например Boost.Fusion или Hana).
Проблему понял, хотя связь с приведенным лямбдовым кодом не вполне уловил.
Лично я, не будучи программистом экстра-класса (хотя и знаком с функциональными приблудами), однозначно предпочел бы видеть в проекте три или четыре руками написанных контейнера с разными объектами, чем нечитаемый (как минимум, лично мной) вышеприведенный говнокод с лямбдами. Если же число разнотипных контейнеров велико, то я бы задумался о применении нормальной — читаемой — кодогенерации (не на С++). Вот такое мое скромное мнение.
Здравствуйте, alex_public, Вы писали:
_>В данном конкретном примере тоже не эффективно (по сравнению с реализацией в современном C++).
Несколько раз счётчик лишний раз подёргать, это уже жёсткая оптимизация константы пошла, не встречал случаев, когда надо работу со строками оптимизировать до константы.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, lpd, Вы писали:
1>>И каких же базовых функций не хватает в связке C++11, Boost, Qt? lpd>Boost еще надо прилинковать — но он не очень и нужен допустим. Qt предлагает средства для UI и работы с lpd>Bluetooth, NFC и т.п., но эти средства скорее лишние для framework, зато вроде бы отсутствует HTTP. Не уверен, что в QT lpd>достаточные для web-приложений модули для работы с Web. Cписок модулей Qt, все там есть, и для работы с сетью и с БД и с xml, и с устройствами, проще перечислять чего там нету чем что там есть. Нехватает некоторых специализированных вещей, но это скорей проблема С++ а не Qt. Из фреймфорков в которых есть почти все можно еще упоминуть Poco.
Здравствуйте, T4r4sB, Вы писали:
_>>В данном конкретном примере тоже не эффективно (по сравнению с реализацией в современном C++). TB>Несколько раз счётчик лишний раз подёргать, это уже жёсткая оптимизация константы пошла, не встречал случаев, когда надо работу со строками оптимизировать до константы.
Нуу скажем если имеем массив таких сущностей, то будет же уже совсем не константа... )
