Здравствуйте, lpd, Вы писали:
lpd>В распозновании речи важен алгоритм, а не тулзы. Потому что оптимизировать будут именно его(при необходимости), а не лепить мув-семантику везде где попало.
Было бы проще, если бы вы поделились своей болью: чем современный C++ вас так обидел, что вы не можете не бросить в него камень?
Хотя move-semantic -- это C++11, какой это уже современный C++?
Тот код и мой, и не мой. Изначально автор не я, но им тогда занимался (и занимаюсь), на мне его поддержка и развитие. К тому же, в том куске набросок правки, скопипащенный прямо с редактора, в комменте об это написано.
S>>В разработке софта, собственно, тоже самое. Распознавание речи в реальном времени -- одно, CRUD приложения для сервиса с 1000 уников в день -- другое. lpd>В распозновании речи важен алгоритм, а не тулзы. Потому что оптимизировать будут именно его(при необходимости), а не лепить мув-семантику везде где попало.
Согласен. Распознавании речи инструмент — это не язык программирования С++. Это математика, модели, алгоритмы. Непростые такие инструменты.
Здравствуйте, so5team, Вы писали:
S>Было бы проще, если бы вы поделились своей болью: чем современный C++ вас так обидел, что вы не можете не бросить в него камень?
Уже обсуждал здесь не раз, в том числе с кем-то из ваших.
Если кратко:
Я бы предпочел опциональную сборку мусорам возне с умными указателями(циклические ссылки, выбор shared_ptr/weak_ptr).
Еще большим злом считаю добавление в C++ move-семантики и rvalue-ссылок. Они только усложняют язык. В 98% случаях копирование объектов незначительно замедляет программу. В оставшихся 2% hot-path кода я предпочел бы написать метод MoveTo() явно вручную, а не использовать переусложненную move-семантику. Некоторые доходят до того, что везде где можно вставляют move — это вообще абсурд.
Ну процессоры сейчас в 100 раз быстрее чем в 90х, поэтому эффекты скорости от move-семантики, шаблонов, и прочей экономии на спичках, про которую тут часто говорят, уже не так полезны, как 30 лет назад. Сейчас базы данных на Java пишут, очнитесь.
С недостатками неавтоматического освобождения спорить сложно. Однако
— вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.
— если время жизни объекта неизвестно, то в этом случае shared_ptr может помочь. Но на мой взгляд опциональный сборщик мусора был бы удобнее, чтобы не заботиться о круговых ссылках.
Ну потому, что С++-98 и C++-17 — это совсем разные языки. Общее у них только имя, да частично легаси-синтаксис. И появись фичи C++-17 в каком-нибудь редком языке, а не С++, массовым бы этот редкий язык они не сделали.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, уважаемый sergey2b, Вы писали:
S>они есть на озоне на русском
Я в курсе
S>если вы правы почему в США на 50 вакансий С++ приходиться только 2 мак 3 на АНСИ С
Потому, что низкоуровневый ANSI C не очень удобен для промышленной разработки ПО
Это прежде всего потому, что требует больших трудозатрат, внимательности и квалификации разработчика, нежели современный C++.
Хотя, и на C++ вполне можно "отстрелить_себе_башку".
В то же время, ANSI C и C++ это инструменты одной ниши.
А вот JS, Java, и C# — совсем другая ниша.
Это сложно назвать объяснением того, чем вас современный C++ обидел. Скорее это список того, чего вы бы хотели видеть в некотором гипотетическом языке. Из чего можно сделать вывод о том, что C++ вас обидел именно тем, что не стал таким гипотетическим языком. Ну так уж повернулась история, здесь ничего не поделать.
lpd>— вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.
?
S>Тот код и мой, и не мой. Изначально автор не я, но им тогда занимался (и занимаюсь), на мне его поддержка и развитие. К тому же, в том куске набросок правки, скопипащенный прямо с редактора, в комменте об это написано.
В итоге: на C++ вы продолжаете говнокодить не смотря на заветы святого для вас Торвальдса. ЧТД.
Здравствуйте, AlexGin, Вы писали:
AG>Почему же? AG>Тот факт, что человек пишет код отлично уже говорит о наличии и мозгов, и навыков. AG>Что же мешает подтянуть элементарные (ИМХО — глубоких то и не надо) знания предметной области?
Мешает отсутствие у сабжа желания? Не раз видел чуваков, предпочитающих мести направо, или налево, остальное его не колбасит и ни о чём более знать не хочет. Кстати, для C++ников ну очень характерно. Ходят, зубрят всяких Майерсов, а некоторые зубрять стандарт и считают, что это есть та самая высокая квалификация программиста. Твердят, что в предметке пусть аналитики разбираются, они же должны клепать код по спеке, написанной аналитиками, и не более.
Здравствуйте, so5team, Вы писали:
S>В итоге: на C++ вы продолжаете говнокодить не смотря на заветы святого для вас Торвальдса. ЧТД.
Тем более, что Си c классами, С++ без всех тех костылей и подпорок, вроде виртуальных функций, такого же наследования, RAII, шаблонов, плясок с auto, и всего прочего мусора, очень даже нормальный ЯП.
Здравствуйте, Denis Ivlev, Вы писали:
У>>1) С чего ты решил, что я буду сувать виртуальные функции везде?
DI>Так ты сам сказал. Речь шла про подмножество С++ в ядре ОС, ты туда предложил добавить ВФ
Здравствуйте, Denis Ivlev, Вы писали:
S>>И при этом они окажутся магическим образом лишены вышеперечисленных недостатков?
DI>Конечно нет, просто разработчик будет понимать, сколько это стоит и не использовать без серьезной необходимости, а не топить за ВФ в ядре ОС, как один неофит рядом.
Понимаю, навык чтения утрачен. Видимо из-за того, что вся жизнь потрачена на реализацию ВФ на сишных указателях и шаблонов на дефайнах
Здравствуйте, smeeld, Вы писали:
S>>В итоге: на C++ вы продолжаете говнокодить не смотря на заветы святого для вас Торвальдса. ЧТД.
S>Тем более, что Си c классами, С++ без всех тех костылей и подпорок, вроде виртуальных функций, такого же наследования, RAII, шаблонов, плясок с auto, и всего прочего мусора, очень даже нормальный ЯП.
В C++ не платишь за то, что не используешь. Жаль, что до тебя, как и до вашего главного пингвина, это не доходит
Здравствуйте, smeeld, Вы писали:
S>Тем более, что Си c классами, С++ без всех тех костылей и подпорок, вроде виртуальных функций, такого же наследования, RAII, шаблонов, плясок с auto, и всего прочего мусора, очень даже нормальный ЯП.
Можно предположить, что в прочий мусор вы отнесли ссылки, перегрузки операторов, перегрузки функций, аргументы по умолчанию, исключения, enum class, nodiscard и deprecated, пространства имен...
Здравствуйте, CreatorCray, Вы писали:
CC>И хрен с ней, с STL библой CC>С++ то тут при чём?
А разве STL (namespace std) это не интегральная, неотъемлемая часть C++
Вроде как стандартные библиотеки...
CC>Это всё решается на уровне библиотек и требований к стилистике кода. Функционал языка же остаётся.
Как бы функционал языка это IMHO как сами по себе операторы языка, так и библиотеки, стандартоно поставляемые с ним.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, smeeld, Вы писали:
S>>Тем более, что Си c классами, С++ без всех тех костылей и подпорок, вроде виртуальных функций, такого же наследования, RAII, шаблонов, плясок с auto, и всего прочего мусора, очень даже нормальный ЯП.
S>Можно предположить, что в прочий мусор вы отнесли ссылки, перегрузки операторов, перегрузки функций, аргументы по умолчанию, исключения, enum class, nodiscard и deprecated, пространства имен...
S> Ссылки
Это такая хрень, которую создавали чтоб облегчить и упростить разработку, чтоб разрабы не делали ошибок при работе с указателям, чтоб не сегфолтились. Но получили, как и всегда в C++, в разы более сложные и в разы более неочевидные проблемы, по сравнению с типичными проблемами работы с указателями. А потом, как и водится в C++, нагородиили кучу костылей и подпорок разной степени уродливости, чтоб эти проблемы нивелировать, и объявили эту кучу костылей невпендюренным развитием ЯП. Всё как и водится в C++.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, smeeld, Вы писали:
S>>Всё как и водится в C++.
S>Да почему же вы на этом .......... пишете-то до сих пор?
S>Неужели из-за денег?
Причины самые разные, и "ради денег" среди них нет. В треде уже писал, что в нишах, занимаемых C++, деньги средние и ниже того.
Здравствуйте, smeeld, Вы писали:
S>Тем более, что Си c классами, С++ без всех тех костылей и подпорок, вроде виртуальных функций, такого же наследования, RAII, шаблонов, плясок с auto, и всего прочего мусора, очень даже нормальный ЯП.
- А видел ли слона? Каков собой на взгляд! Я чай, подумал ты, что гору встретил?
— Да разве там он?
— Там.
— Ну, братец, виноват: Слона-то я и не приметил.
Задумайся над словами из басни Крылова слона то я и не приметил в контексте C++...
Да даже не только C++
ВЕСЬ МИР ООП, включая такие популярные языки как:
C#
Java
Прошёл мимо тебя
Вот ты оглянулся назад — и стало грустно за прожитые годы...
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, smeeld, Вы писали:
AG>Да даже не только C++ AG>ВЕСЬ МИР ООП AG>C# AG>Java
AG>Прошёл мимо тебя
Бро, с какого дуба рухнул? Где в том коменте про ООП? Я и на чистых Сях ООП реализовываю влёт, это, кстати, проще чем на C++ (чтобы туту "гуру" не вещали). Загляни в исходники любого ядра на Сях, там везде такой ООП, до которого любому известному проекту на C++ как раком до Пекина.
