Здравствуйте, 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++ я не встречал. Скорректирую исходный пост.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Имел ввиду именно фреймворки для корпоротивных приложений вроде Spring, Struts — таких на C++ я не встречал. Скорректирую исходный пост.
Та ведь С/С++ — это базис, а Java и фреймворки — надстройка (одна из). Надстройка, как правило, решает сугубо частные проблемы, наиболее подходящие по сфере задач и эффективности сопровождения, а базис обслуживает надстройку (надстройки). Ближайший аналог C/C++ в плане доступности, компетентности в применении в прикладных фреймворках — язык Go, но он пока не сильно популярен в силу того, что есть "унаследованный груз кода", который нужно сопровождать. А на это нужны людские ресурсы, а не только деньги.
Здравствуйте, lpd, Вы писали:
lpd>Ну вот я и пытаюсь выяснить, что это, в действительности, за причины.
Тут уже написали почему: разработка и поддержка корпоративных приложений на плюсах дороже. Причём в разы, а возможно даже на порядок.
lpd>Но список причин получается короткий и сомнительный.
А зачем этому списку быть длинным? Достаточно одной веской причины.
Здравствуйте, 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, Вы писали:
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, Вы писали:
_>Это полная ерунда. Я бы разделил изменения в стандарте 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>Тогда почему именно дороже и как 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, Вы писали:
_>Здравствуйте, 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 в этом не помогает.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
lpd>>Любую программу, которую вы напишете с помощью лямбд, я напишу без них. И ни мне, ни другим программистам не прийдется запоминать синтаксис лямбд или мелких улучшений языка.
_>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? )
Мда. Надеюсь в реальном коде такое никогда не встретится.
А ведь когда-то над укушенными Александреску глумились
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, 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++.
Здравствуйте, Stanislav V. Zudin, Вы писали:
_>>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? ) SVZ>Мда. Надеюсь в реальном коде такое никогда не встретится. SVZ>А ведь когда-то над укушенными Александреску глумились
))) Вообще то это вполне нормальный код из мира ФП. Просто на C++ его раньше было проблематично записать. А теперь без проблем.
Здравствуйте, alex_public, Вы писали: _>Тут фундаментальное непонимание и даже не одно:
_>1. Цена разработки определяется не величиной зарплаты программистов. _>2. Зарплата программистов определяется не уровнем квалификации.
Это перевод вопроса в экономическую плоскость. Причины начинаются в технических особенностях C++.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Надеюсь в реальном коде такое никогда не встретится.
