Здравствуйте, Слава, Вы писали:
С>Ну вот поэтому для mission-critical софт на C++ и не пишут. Используют либо Си, либо прочее такое, простое и сертифицированное.
Ага, и потом, спустя Х лет и Y команд разработчиков, сами не знают, с какой стороны подступиться, чтобы найти багу.
Здравствуйте, push, Вы писали:
S>>Про "увеличение производительности программиста на С" речи не было, т.к. сам C был взят исключительно из утилитарных соображений.
P>Ну я взял его книгу — в предисловиях он сам так пишет
Какую именно? В его книге "Дизайн и эволюция языка C++" подробно описывается как появилось решение делать C++ и какие цели при этом преследовались.
P>Тут я вообще никак не согласен, что для скорости. Да, старались делать максимально эффективно, но всё же делали язык общего назначения.
Это ваши личные проблемы и заблуждение. Например, заблуждение о том, что язык общего назначения не может быть "языком для скорости".
P>Нет никаких спецсредств/концепций для скорости.
Скорее в языке нет никаких спецсредств/концепций для замедления. В отличии от безопасных языков, в которых таковые есть в товарных количествах: начиная от проверок индексов в run-time, заканчивая сборщиком мусора.
P>Наличие остальных, противоположных скорости концепций подтверждает это.
Каких?
P>Да и сам автор пишет.
Вы уверены, что вы понимаете, что пишет Страуструп?
P>То, что получились ШАБЛОНЫ — тогда такое даже не закладывалось — делали просто шаблоны, а уже остальную мощь с удивлением обнаружили после.
Тогда -- это когда? Шаблоны появились в языке в 1990-ом, через 5 лет после публичного релиза языка. А работа над ними началась еще раньше.
S>>Язык общего назначения не может создаваться под ниши с повышенными требованиями к ресурсоемкости и производительности? OK.
P>Эммм, почему?
Это вы скажите почему. Вы же противопоставляете "язык для скорости" и "язык общего назначения".
S>>И что нужно было делать, GC в язык добавлять?
P>Нужно было развивать язык и инфраструктуру, чтобы они хотя бы не хуже остальных выглядели. P>А на счёт GC — это по желанию. Лично мне не нужен, но если большому количеству нужен, то не вижу проблемы добавить. Считай как отдельный мемори пул с продвинутыми мозгами.
Гы-гы-гы. Никогда не задумывались, насколько GC облегчает написание библиотек в других языках? Никогда не задумывались, насколько часто GC нужен при решении обычных задач, не требующих высокой производительности и низкого потребления ресурсов?
То, что GC сильно облегчает жизнь программистам, стало понятно еще в 50-е годы прошлого века. Но только в середине 1990-х компьютеры в массе своей стали обеспечивать должную производительность для языков с GC. И после этого C++ в массах без GC стал не нужен. Так что гонка с Java (а потом и с C# и с другими безопасными языками с GC) была проиграна сразу, как только RAM и CPU перестали быть ресурсом. И как бы не обеспечивали C++ библиотеками и инфраструктурой, все равно большинство бы ушло в безопасные языки с GC.
Здравствуйте, landerhigh, Вы писали:
L>Ага, и потом, спустя Х лет и Y команд разработчиков, сами не знают, с какой стороны подступиться, чтобы найти багу. L>Фильм ужасов, основанный на реальных событиях.
Много лет тому назад царь купил себе айпад
На си можно писать разборчиво, если хочется. А вообще, под простым и сертифицированным я подразумевал Ada, которую когда-то специально сделали для сложных и ответственных проектов. На мой взгляд, это самый пригодный для чтения язык общего назначения.
Здравствуйте, Слава, Вы писали:
L>>Фильм ужасов, основанный на реальных событиях.
С>Много лет тому назад царь купил себе айпад С>На си можно писать разборчиво, если хочется.
Можно. Только чуть чаще, чем всегда, разборчиво пишутся исключительно ручные реализации того, что в плюсах есть искаропки (с) вроде конструкторов и таблиц методов.
Здравствуйте, push, Вы писали:
P>Реально смешно. Туева хуча с++ библиотек по логгированию + чуть ли не каждый пятый пишет свою, чтобы не тянуть стороннюю библиотеку. Это только на плюсах такое, когда проще написать свой велосипед, чем тянуть стороннюю библиотеку.
Да, и у нас в плюсовом проекте тоже своя библиотека логгирования.
И не потому, что мы не видели других.
Видели много, даже слишком. Тем более видели из мира Джавы и Дотнета.
Но сценарии у нас слишком специфические.
Т.е. будь даже в стандарте уже встроено несколько технологий логгирования, они бы нам не подошли.
Потому что если бы со своим наивным подходом посмотрел, какой путь у нас совершают данные в нашем асинхронном логгере, у тебя бы сломался моск. )) Безблокировочность она такая, угу. Но это минимально затратно по тактам в целевом потоке обработки данных, а нам требуется именно такая минимальность.
P>И все они отличаются только синтаксисом и вкусовщиной (это ещё если отличаются) — в остальном братья-близнецы.
Они отличаются по архитектуре, потоковой модели и, соответственно, по политикам блокировок.
Просто ты пишешь из такого болота, где все эти вещи фактически не имеют смысла, поэтому, тебя интересует только внешний АПИ.
P>Или ты про тот 0.001% уникальных случаев?
Каждый случай, требующий эффективности — по-своему уникален.
Потому что не может абстрагироваться от конкретной потоковой модели происходящего.
V>>Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет. Конечно, на плюсах используют XML аж бегом, но не так упорото, как в Джаве и дотнете. Потому что малость другие подходы. Можно и парсер конфига нарисовать или свой текстовый или бинарный протокол. Это в духе нейтива, бо в нём удобно парсить и генерить строки. P>У тебя просто походу нет опыта работы с большими проектами (исходники больше 1 ГБ) и в больших компаниях (программеров больше 300).
С этой херней сразу в сад. Потому что и опыт есть и видел разного.
Де-факто, XML пихается повсеместно исключительно от нубства разработчиков-обезъянок.
Я ничуть не спорю с тем, что полно сценариев, когда XML вполне оправдан (декларативность/структурированность). Просто их раз в 10 меньше, чем фактических случаев использования. Потому что XML в Дотнете-Джаве часто используется вовсе дико — он используется ровно в тех сценариях, где надо описывать некие императивные действия. Т.е. в этом декларативном языке описывают AST неких императивных выражений. Во дичь-то! И это в 90% случаев использования XML. Даже если на первый взгляд система выглядит сугубо декларативной, типа как Ant/NAnt — нифига, 99% схемы этого документа описывает сугубо императивные действия, а на декларатив там оставлен жалкий 1% указания зависимостей.
Вот почему над вами ржут. Потому что вы не в состоянии ОБЪЕКТИВНО посмотреть как на свои инструменты, так и на собственные поделия. Вы живёте во лжи. Врёте себе и окружающим. Блин, ну если объективно нужна динамика — так бери динамику, какие проблемы, нахера брать XML? Существуют же кучи динамических языков. Абсолютно все из них идут в виде "движков", т.е. позволяют подключать эти движки в проект простым движением руки.
P>В таких случаях абсолютно все без исключений приходят к необходимости стандартизации и унификации.
Во-во. ))
XML не даёт стандартов на данные, он даёт стандарты для структурирования этих данных.
Поэтому, тебе всё-равно надо разрабатывать СХЕМУ документа.
Т.е. не брать некую стандартную/имеющуюся, а именно ВВОДИТЬ ее в проект, т.е. тебе в любом случае приходится СТАНДАРИЗИРОВАТЬ некий свой насос из пальца.
Ну и такой момент как читабельность. XML не читабелен от слова совсем. А ведь читабельность — это важная составляющая обслуживаемости, не?
P>Она ставится как цель номер один, иначе проект/компания утонет
Это всё нубские разговоры. По-факту в крупных компаниях процент проваленных проектов больше, чем в мелких. Посмотри сколько и каких мастабшных проектов ушло "в стол" в гугле или MS. Потому что мелкие компании не могут позволить себе нанимать толпы нубов (в том числе нубов-управленцев и архитекторов), а большие — могут. В больших компаниях большая текучка и низкий средний уровень программиста и управляющего персонала.
Поэтому, давай называть вещи своими именами — для трёхсот нубов требуются совсем другие внутренние стандарты на разработку, чем для пятидесяти профессионалов. И задача профессионалов в больших компаниях тоже отличается от задач профессионалов в небольших. Если во втором случае профессионалы непосредственно занимаются разработкой 100% времени, то в больших львиная доля профессионалов тратит своё рабочее время (и нервы!) на подтирание задниц нубам и уборкой за ними несметных туч г-на в архитектуре и непосредственно в коде.
P>Это номер раз почему "везде xml".
Да нет его "везде", уже отказываются, мода уже прошла.
Он есть только в вашем дотнете-джаве, но коробочные продукты на этих технологиях не покупаются.
Посмотри, например, на QML в QT.
Это даже не JSON, хотя близкая технология.
Какой-нить упоротый дотнечик или джавист непременнос лепил бы аналогичное на XML, а как же!
P>С xml легко работать, либы уже устоявшиеся, имеется куча утилит которые работают с xml. Не требуется иметь кучу парсеров/генераторов. Отсутствует головняк с разработкой и поддержкой кастомных парсеров/генераторов. Из-за наличия единообразия нет повышенной утомляемости, когда требуется всё время переключать контекст в мозгу. P>Рисовать мульён своих конфигов и протоколов — это и есть тот самый инженерный идиотизм.
Инженерный идиотизм — это не знать самых базовых правил инженерии. Например таких, что наиболее общее решение является наихудшим для конкретного случая. Поэтому, инженер всегда ищет решение в координатах противоречивых требований. И конкретное решение, его кач-во, зависит в том числе от навыков инженера, разумеется.
Просто ты живешь во лжи и не называешь вещи своими именами. А ни таковы, что из нейтива доступны произвольные либы парсинга и произвольные движки динамических языков с развитым АПИ, а у вас НИХРЕНА НЕТ. Поэтому, лишний раз подумаешь — то ли делать биндинг скриптового движка, то ли ну его нафик, давай опишем AST эквивалентных императивных выражений в виде XML!
P>Так же я думаю ты не в курсе, что на данный момент в реальной жизни всё происходит очень живо и для каждой предметной области никто сейчас не будут писать свой DSL и тратить кучу времени на его отладку, тестирование, поддержку.
Я прекрасно знаю как оно происходит в мире заказухи.
Слепил, втюхал, побежал дальше.
Сам активно фрилансил одно время или занимался заказной разработкой в рамках компаний.
Это свинское болото в большинстве случаев, потому что приоритеты другие — свинские.
Отсюда среднее качество решений в заказухе ниже плинтуса.
P>А xml позволяет достаточно просто и детально описать предметную область.
Нет не позволяет. Позволяет некая спека — схема документа.
И вот как посмотришь на некоторые спеки над XML, так начинаются вопросы из разряда — люди, вы чего творите-то? ))
P>Его очень легко использовать для кодогенерации.
Для кодогенерации легко использовать любое типизированное структурное представление, которое уже в памяти.
Представление в памяти XML в этом смысле — одно из самых неудобных.
Чтобы проводить по такому представлению кодогенерацию, это представление надо предварительно отобразить на некоторое типизированное и потом уже что-то такое пытаться делать.
P>С ним отсутствует большинство проблем, замечу ненужных проблем, которые решает парсеро/генераторо-писатель.
А кто мешает взять готовые решения?
А, ну да. Нет бинда под дотнет... Понимаю... ))
P>Это номер два почему "везде xml".
Потому что на безрыбье ты вынужден становиться раком и больше нипочему.
P>И пока познающие дзен размышляют как правильно спроектировать DSL или вообще сделать язык под предметную область — остальные уже запилили кодогенерацию на xml и продали.
Пипец...
За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком.
P>А ещё за счёт работы с БД
С БД в дотнете-джаве хуже.
P>и сетью
С сетью вообще хана.
P>и конфигами
Конфиги мы уже обсудили.
P>и плагинами
COM, WinRT — вполне компонентные технологии.
Нейтивные.
Собсно, чего-то аналогичному OLE/ActiveX ни дотнет ни джава так и не породил.
И оно востребовано в Офисных док-тах до сих пор и будет востребовано еще неизвестно сколько.
Лет 20 или больше аж бегом.
P>RPC
RPC отродясь возникло как нейтивное.
Учите матчасть.
P>асинхронность... wait, oh shit
Асинхронности в дотнете НЕТ. ))
Есть её муляж в таком зачаточном состоянии, что признать ЭТО за наличие асинхронности сложновато.
Если в нейтиве асинхронность ведёт к резкому увеличению пропускной способности, то в дотнете — к очень нерезкой.
Объект Task сам по себе настолько тяжеловесен вместе со всей инфраструктурой вокруг него, столько надо сделать процессору действий для банальной постановки задачи в очередь, что это получилась профанация асинхронности.
Ты хоть имеешь представление, почему в Task настолько тяжело приходится разбираться с SynchronizationContext?
Или никогда не интересовался?
Ну так поинтересуйся, потом приходи.
В итоге, максимум где полезна такая асинхронность а ля дотнет — сугубо в GUI, т.е. ы-ы-ы много раз.
Юзер тыкает по элементам управления максимум один раз в секунду, вот мы сейчас покажем тру асинхронность!!! )))
Тут следовало бы убиться апстену и не отсвечивать, как по мне.
P>Все проекты которые начинаются — заказывают на C#
Это в какой реальности такое?
Не, на C# заказывают довольно много проектов, согласен.
Но C# не входит даже в тройку языков по популярности в заказухе.
P>как раз из-за скорости разработки и отсутствия рисков по сравнению с плюсами.
От предметной области зависит.
Если надо нарисовать неспешный магазинчик, то C#, Java, PHP, RoR — очень даже неплохие решения.
А если биржу — то увы.
P>Всё, что заказывают сейчас на плюсах — это мелкие утилиты (причём требуют обязательно сделать ещё и интерфейс на шарпе) и драйвера.
Всё, на чём ты работает, ну т.е. вообще всё — оно писано на нейтиве.
Даже твой дотнет.
Даже твои БД.
Даже твои веб-сервера.
Какую-бу программу ты не запустил, какой бы девайс не взял в руки — там нейтив и только нейтив.
Даже в Андроиде основные проги — нейтивные.
А всякими свистелками и перделками народ лишь недолго балуется, но каждый день пользуется сугубо нейтивными приложухами — модулем звонков, камерой и видео. На андроидной жабке там лишь 2-3 кнопки нарисованы, т.е. 0.0001% от всего кода, составляющего эти модули.
V>>Коробочные дотнетные проги в нашей реальности НЕ ПРОДАЮТСЯ, за очень малым исключением. P>Во-первых покупаются,
Пример?
P>во-вторых — это ну очень маленький рынок по сравнению с частным бизнесом/корпорациями.
Бизнес ПО/Деловое ПО и заказное — это две большие разницы.
Например, Парус или 1С продают на 90% (грубо) коробочный продукт и на 10% конфигурируемый.
Так же есть нехилый рынок ПО, которое поставляет производитель оборудования в составе своих девайсов.
Простой пример — автомобильные системы, модули управления движком и т.д.
Там тоже почти всегда нейтив (на более чем 99% девайсов уж точно).
Так вот, если взять "чистую заказуху", т.е. которая не писана на какой-нить бизнес-платформе (которая сама по себе является коробочным продуктом/услугой), т.е. отбросить "мальчиков-1С-ников" и прочих т.н. value-added resellers, то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования. Более того, 90% этих денег и работы сегодня сосредоточены исключительно в вебе, где эти деньги тебе, как программисту, надо делить с дизайнерами сайтов, администраторами или хостерами. Итого, собственно программистам остаётся с гулькин нос. Именно поэтому в разработке под веб хороших денег нет. Потому что есть деньги в разработке ферм, виртуализации и прочем. Но, блин, там тоже получают свои большие денюжки нифига не дотнетчики и не джависты. ))
Здравствуйте, MTD, Вы писали:
MTD>>>Хорошо, что в комитете еще есть практики, которые с тобой не согласны. CC>>И кто же эти практики? MTD>Те которые, например, тредс таки протащили — огромное им спасибо.
Это которые начали разрабатывать их с 2000-го года? И которые трижды переписывали их реализацию?
Да еще за это время успешно сдохло несколько когда-то популярных платформ, т.е. задача резко облегчилась?
Здравствуйте, push, Вы писали:
P>- отсталость языка (о боже наконец-то вводят any, optional, variant и т.д. — и то либами, фу! Нет reflection, modules, ABI и т.д.).
Причем в C то ABI уже был и прекрасно работал. Только за один сломанный ABI Страуструп и комитетчики должны гореть в аду.
Здравствуйте, Lepsik, Вы писали:
AG>>Слоты и сигналы в Qt: AG>>https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html
L>Зачем это нужно в десктопных приложениях? Билдер и сейчас в ходу и в мелких и крупбых компаниях. Qt даже не тянет на близкую альтернативу.
Именно для настольных приложений это весьма актуально!
Теперь вопрос риторический: где в 2017-ом применяется Билдер и Делфи
Насчёт выделенного — крупных компаний — приведи, пожалуйста, примеры современных разработок!
Здравствуйте, MTD, Вы писали:
V>>Ты высказываешься в той ветке, где С++ ругают за недостаточную навороченность. MTD>Чего? Я начал эту тему и у меня наоборот претензии, что сейчас сообщество увлеклось переусложнением.
А я отвечал человеку в конкретной подветке.
V>>Индустриальных стандартов много, как и комитетов по стандартизации. V>>Разумеется, С++ такой же индустриальный стандарт. MTD>У тебя какая-то каша в голове. Например, никто их не стандартизировал
Кого "их"?
MTD>а на С++ сообщество не осилило сделать ничего такого же уровня.
На язык С++ есть целая сетка версий стандартов.
MTD>На обертки ты дал ссылки, а не на либы.
Обертка обертке рознь.
MTD>Вот я написал плюсовую обертку над openssl что мне теперь кричать, что я гуру криптографиии и внес огромный вклад?
Ну, я тоже написал именно под openssl.
Пару вечеров работы, и?
Под дотнет такая же по функциональности обертка могла занять рабочую неделю.
Всё-таки, это малость опрометчиво — сбрасывать со счетов непосредственную интероперабельность С и С++ кода.
V>>Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51 MTD>Для них нет компиляторов С++? Это что же ты так решил высказаться, что С++ отстой?
Так и дотнета под них нет.
Может, это просто такие специфические архитектуры, что под них даже реализация языка идёт С в сильно урезанном виде?
V>>За что его и ругают, кстате. V>>Отличный пример, спасибо. MTD>Конечно, у труЪ модерн С++ разработчиков, бомбит когда кто-то зарабатывает деньги и решает проблемы людей.
Да я не против. QT — это просто хороший пример того, что не всё зависит только от языка. Язык же не в вакууме живёт, а на конкретных аппаратных и программных платформах. Поэтому, тот же GTK+ сугубо сишный. Но ведь тоже мазохизм, не? Не зря же существует Vala?
V>>Ну ты бы сначала вопросом поинтересовался бы, потом выводы делал. MTD>Хочешь длиной меряться? Ну расскажи, что ты на С++ написал.
Какая прикладная область интересует?
V>>В С++ оборачивается обычно ничтожная часть АПИ любой сишной библиотеки. MTD>Это бессмысленное высказывание, оборачиваю всегда только внешний интерфейс.
Осмысленную часть ты скромно порезал:
Вот только те объекты, которые отвечают за ресурсы, те и оборачиваются, потому что ради RAII.
Но гораздо больше объектов никакого оборачивания не требуют.
Не требуют оборачивания структуры, перечисления, константы и т.д. и т.п.
А такие вещи обычно составляют более половины любой спецификации АПИ.
Здравствуйте, vdimas, Вы писали:
V>Потому что если бы со своим наивным подходом посмотрел, какой путь у нас совершают данные в нашем асинхронном логгере, у тебя бы сломался моск. )) Безблокировочность она такая, угу. Но это минимально затратно по тактам в целевом потоке обработки данных, а нам требуется именно такая минимальность.
Ага, ну то есть — нам нужна супер кастомная либа логгирования, но раз её не добавят в стандарт (потому что остальным нафиг не нужна) — то я за то, чтобы все остальные 99,9% разработчиков продолжали писать свои велосипеды?
V>Они отличаются по архитектуре, потоковой модели и, соответственно, по политикам блокировок.
Да в них всё нужное настраивается, а некоторые вещи, как "политики блокировок" в 99% случаях нафиг не нужны.
P>>Или ты про тот 0.001% уникальных случаев? V>Каждый случай, требующий эффективности — по-своему уникален. V>Потому что не может абстрагироваться от конкретной потоковой модели происходящего.
Ахахаха)))) Ты хочешь сказать, что все вещи _надо_ велосипедить? Ведь каждый случай по своему уникален. И получается что писать библиотеки вообще нет смысла? Ведь идеальных библиотек не бывает в принципе. Так или иначе каждая либа покрыват лишь некоторый процент случаев применения.
V>>>Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет...
Оххх, да-да, оно конечно, все "нубы". Но беда в том, что такое "нубское" решение рвёт на рынке любое кастомно-плюсовое как тузик грелку во всех отраслях, где может конкурировать.
Отвечу твоими же словами. С этой херней сразу в сад. Потому что и опыт есть и видел разного.
Реально влом пережевывать настолько очевидные вещи, ибо жевать придётся много.
V>Инженерный идиотизм — это не знать самых базовых правил инженерии. Например таких, что наиболее общее решение является наихудшим для конкретного случая. Поэтому, инженер всегда ищет решение в координатах противоречивых требований. И конкретное решение, его кач-во, зависит в том числе от навыков инженера, разумеется.
Конечно, но инженер в 99,9% случаев никогда не будет заново рассчитывать, создавать и испытывать базовые конструкции — когда достаточно типовых. Более того, в современном мире, в подавляющем большинстве случаев результат собирают из стандартных конструкций из каталога.
V>Пипец... V>За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком.
точно пипец, до чего можно договориться
V>С БД в дотнете-джаве хуже. V>С сетью вообще хана. V>Конфиги мы уже обсудили. P>>и плагинами V>COM, WinRT — вполне компонентные технологии. V>RPC отродясь возникло как нейтивное. V>Асинхронности в дотнете НЕТ. )) V>Есть её муляж в таком зачаточном состоянии, что признать ЭТО за наличие асинхронности сложновато.
OKAY
P>>как раз из-за скорости разработки и отсутствия рисков по сравнению с плюсами. V>Если надо нарисовать неспешный магазинчик, то C#, Java, PHP, RoR — очень даже неплохие решения. V>А если биржу — то увы.
О как, ну то есть только в отрасли криточной к ресурсам.
Напомни мне какое соотношение проектов уровня "неспешный магазинчик" и "биржа"? Один к миллиону, или это я слишком уж оптимистично оценил?
Хм, интересно, и почему же такой замечательный язык, с такой замечательной инфраструктурой (по твоим словам), с невероятно быстрой скоростью написания проектов так позорно сливает остальным языкам?
Все остальные дураки и мазохисты?
V>...то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования...
Частично верно, но ты забываешь один ньюанс — соотношение количества проектов на страиваемое ПО (и другое, критичное к ресурсам) и остальной заказухи, что на корню рушит твои выводы. Взять работу любой большой софтверной компании — на 2-3 проекта по встраиваемому ПО — десятки проектов по с/х, медицинскому, медиа, казуально-игровых, кастомных решений для бизнеса и другому ПО.
Здравствуйте, so5team, Вы писали:
S>Какую именно? В его книге "Дизайн и эволюция языка C++" подробно описывается как появилось решение делать C++ и какие цели при этом преследовались.
"Язык С++. Специальное издание." В предисловиях он описывает почему решил создать С++ и что хотел в нём видеть.
S>Это вы скажите почему. Вы же противопоставляете "язык для скорости" и "язык общего назначения".
оО Это я противопоставляю? Вообще-то это вы противопоставили. Я пытаюсь донести, что это не верно.
S>И как бы не обеспечивали C++ библиотеками и инфраструктурой, все равно большинство бы ушло в безопасные языки с GC.
Категорически не соглашусь. GC конечно помогает, но не до такой степени. Более того GC разных хватает и в плюсах. Более того, каждый может сам написать такой GC, который захочет — есть книги по шаблонным паттернам и трюкам, c подробным описанием и реализацией "шаг-за-шагом" своего GC.
Киллер-фича — это как раз стандартные библиотеки и инфраструктура. Когда я могу быстро и легко набросать приложение из "стандартных кирпичиков". То же самое можно, конечно, сделать и на плюсах, но это займёт несоизмеримо больше времени и трудозатрат.
А если нет разницы в конечном результате — то зачем платить больше?
Вот и получается, что шансов конкурировать на большей части рынка у С++ нет. И не потому, что есть какие-то фундаментальные проблемы или на С++ чего-то невозможно сделать, а потому что собственно нечем конкурировать.
И С++ не ужимается до естественных областей применения — он просто сдаёт позиции, как только в какой-то области появляется конкурент. Потому он сейчас и живёт только в тех областях, где ему (пока что) нет конкуренции.
Как это исправить? Ну для начала хотя бы перенять опыт других языков.
Здравствуйте, push, Вы писали:
S>>Какую именно? В его книге "Дизайн и эволюция языка C++" подробно описывается как появилось решение делать C++ и какие цели при этом преследовались.
P>"Язык С++. Специальное издание." В предисловиях он описывает почему решил создать С++ и что хотел в нём видеть.
Ну тогда перечитайте, а то есть ощущение, что вы чего-то не поняли. Не мог Страуструп в "Дизайне и эволюции" писать одно, а в "Язык программирования C++" -- другое.
S>>Это вы скажите почему. Вы же противопоставляете "язык для скорости" и "язык общего назначения".
P>оО Это я противопоставляю? Вообще-то это вы противопоставили. Я пытаюсь донести, что это не верно.
Конечно вы:
Если бы он создавался для скорости — то как минимум по умолчанию копирования небыло, не было бы и виртуальных функций, исключений, RTTI.
С++ позиционировался как язык общего назначения. Повторюсь, Старутруп сам пишет об этом в предисловии.
Вы же сами пишите, что C++ создавался не для скорости, а как язык общего назначения. Значит вы не можете себе представить, как это можно уместить в рамках одного языка. Вероятно, поэтому вы так феерически высказываетесь.
P>Более того GC разных хватает и в плюсах. Более того, каждый может сам написать такой GC, который захочет — есть книги по шаблонным паттернам и трюкам, c подробным описанием и реализацией "шаг-за-шагом" своего GC.
Простите, вы это сейчас серьезно?
P>Киллер-фича — это как раз стандартные библиотеки и инфраструктура.
Вы знаете, что в некоторых прикладных нишах использование STL (т.е. стандартной библиотеки C++) находится под запретом (либо целиком, либо частично)?
P>Как это исправить? Ну для начала хотя бы перенять опыт других языков.
Здравствуйте, push, Вы писали:
P>Ага, ну то есть — нам нужна супер кастомная либа логгирования, но раз её не добавят в стандарт (потому что остальным нафиг не нужна) — то я за то, чтобы все остальные 99,9% разработчиков продолжали писать свои велосипеды?
У остальных уже есть абстракция ostream и фреймворк фильтрации сверху в бусте.
V>>Они отличаются по архитектуре, потоковой модели и, соответственно, по политикам блокировок. P>Да в них всё нужное настраивается
В тех десятках, что я видел, нифига нужного не настраивается. Всё прибито гвоздями друг к другу на основе 3-4-х основных интерфейсов. Такие либы сделаны по принципу аналогичных либ из джавы и дотнета и выглядят, мягко говоря, идиотизмом. Ну и эффективность соответствующая.
P>Ахахаха)))) Ты хочешь сказать, что все вещи _надо_ велосипедить? Ведь каждый случай по своему уникален.
Тю...
Велосипедить можно по-разному. Можно самому распиливать трубы на рамы, варить их, покрывать защитными покрытиями, резать проволоку на спицы и т.д. А можно взять готовую первоклассную карбоновую раму от ведущего производителя карбоновых рам, самые подходящие под конкретный сценарий колеса (и на выбор шины к ним), затем цепь от самого лучшего в мире производителя цепей и т.д., и в итоге забацать отличный для конкретного сценария велик за смешное время. Так вот. Проблема дотнета в том, что когда в нём охота забацать велик, то приходится начинать фактически с распила труб. ЛЮБОЙ более-менее большой дотнетный проект содержит в себе еще несколько проектов (речь доходит до десятка-другого порой). Сугубо внутренних проектов, разумеется. С т.з. нейтива это давно уже дикость.
Поэтому, велосипедить в дотнете накладно, ес-но.
И глупо.
Однако ж, всё-равно велосипедят.
Потому что некуда деваться.
А в языках с хорошей выразительностью велосипедостроительство — это основной вид деятельности. Причём, замечательной приятной творческой деятельности. Вот как в функциональных языках или даже в Немерле (хоть я и не фанат). Вот где-то так же и в С++, особенно в последних стандартах. В нём сначала описывается некая предметная область, а затем программа выражается в терминах этой предметной области. На джаве/дотнете такой подход НЕ работает, увы. Там код всё-равно выходит я-ля ТурбоПаскаль — просто операторы, методы, ф-ии и мало смысла, привязанного к решаемой задаче. Потому что паттерн на паттерне сидит и паттерном погоняет. Такой подход нехило замыливает суть происходящего, разбрасывает внимание. А всё потому, что ничего друг с другом не совместимо. Там или жрите базовые интерфейсы или городите бесконечные паттерны на ровном месте. Т.е. шаг вправо-влево — считай расстрел.
P>И получается что писать библиотеки вообще нет смысла?
В языке, типа С++, нет смысла писать библиотеки all-in-one. Можно писать части библиотек.
Ты всё-время забываешь, что части различных библиотек прекрасно работают друг с другом.
Т.е. не обязательно выпускать готовые велосипеды, бо всем ты не угодишь.
Да чего уж там. Ты не угодишь даже половине. ))
Но можно выпускать отдельно номенклатуру колёс, отдельно цепей, рам и т.д.
P>Ведь идеальных библиотек не бывает в принципе. Так или иначе каждая либа покрыват лишь некоторый процент случаев применения.
МО-ЛО-ДЕЦ!
Наконец до тебя дошло.
Именно поэтому развитый базис, позволяющий комбинировать готовые "кирпичики", намного ценнее некоторого конкретного решения, которое практически невозможно на эти кирпичики разобрать.
[...]
V>>...то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования... P>Частично верно, но ты забываешь один ньюанс — соотношение количества проектов на страиваемое ПО (и другое, критичное к ресурсам) и остальной заказухи, что на корню рушит твои выводы. Взять работу любой большой софтверной компании — на 2-3 проекта по встраиваемому ПО — десятки проектов по с/х, медицинскому, медиа, казуально-игровых, кастомных решений для бизнеса и другому ПО.
Как-то ты странно считаешь.
Сейчас номенклатура устройств, в которых работает какое-либо ПО, резко превышает кол-во тех самых "бизнес-сайтов", на которых, собсно, тру-программисты и могут заработать. Сейчас в пересчёте на каждого человека приходится примерно один проц общего назначения (в ноуте, десктопе или планшете) и порядка двух десятков процов во всех устройствах вокруг него. В общем, рынок встраиваемого ПО обогнал по денежной ёмкости рынок "чистой заказухи" еще более 5-ти лет назад. Более того. Тенденции рынка чистой заказухи все последние 15 лет хреновые — её доля продолжает ужиматься. А, скажем, в РФ, с 2012-го года ужимается не только доля чистой заказухе, но и абсолютный объем этого рынка! За счёт доли value-added resselers, ес-но. Т.е. это нормальный процесс унификации самого понятия "кастомизация ПО".
В сегодняшней реальности всё больше денег достаётся дизайнерам сайтов, бизнес-аналитикам/консультантам, администраторам и т.д.
А собственно разработчикам ПО — всё меньше.
Потому что всё уже разработано.
Так шта, бойтесь своих желаний, как грится.
Как только разработают ВСЕ библиотеки (как ты настаиваешь), так лично ты станешь не нужен.
Потому что стоит к таким либам потом протянуть ср-ва их предметно-ориентированного комбинирования (назовём так) и усё. Грамотный бухгалтер или инженер обойдутся и без тебя.
Общий объем рынка заказной разработки сайтов по оценке CMS Magazine в 2016 году — 16,4 млрд рублей. Тот же показатель в 2012 году — 17,73 млрд рублей.
На лицо — сжатие рынка.
Среди основных причин можно особо выделить следующие:
— Общая экономическая ситуация;
— Расширение возможностей коробочных CMS и, как следствие, уменьшение объема программирования в типовых проектах;
— Снижение спроса на заказную разработку небольших сайтов в пользу SaaS и расширенного функционала соцсетей;
— Увеличение количества компаний, предпочитающую внутреннюю разработку.
И если 1-й и 2-й пункты зависят много от чего, т.е. могут гулять туда-сюда, то п. 2 и 3 — они фундаментальные. Это то, куда всё движется.
Поэтому, всё более нужны именно те, кто разрабатывает библиотеки/платформы. Собсно, это и есть программисты. Все остальные будут как "мальчики-1С" — т.е. "настройщиками".
===========
Тут еще стоит учесть падение стоимости рубля, т.е. вообще полная ж-па получается.
Не, я все эти годы постоянно слышал, что рынок заказухи падал, ОК.
Но даже не представлял насколько, оказывается, глубоко сие падение.
Здравствуйте, push, Вы писали:
V>>За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком. P> точно пипец, до чего можно договориться
Кстате, да.
Это ведь расхожее заблуждение в мире дотнетчиков, что в нейтиве ситуация сегодня такая же, как в 2000-м году, верно?
Т.е. твой моск, смотрю, пока еще изо всех сил борется с тем фактом, что огромный пласт задач (даже сугубо прикладных) сегодня на С++ решается заметно быстрее и проще, чем даже на C# 7.0.
Здравствуйте, vdimas, Вы писали:
V>Это которые начали разрабатывать их с 2000-го года? И которые трижды переписывали их реализацию? V>Да еще за это время успешно сдохло несколько когда-то популярных платформ, т.е. задача резко облегчилась?
ОМГ, какая дичь. POSIX существует с незапамятных времен, а в нем есть описание семафора — это такой примитив на котором элементарно строятся любые конструкции и который в С++ до сих пор не осилили. В лохматых 200х годах уже за это можно было бы петь хвалебные песни комитету. А то, что на каком-то утюге нет потоков, так просто на утюге не было бы файла thread.
Здравствуйте, vdimas, Вы писали:
MTD>>а на С++ сообщество не осилило сделать ничего такого же уровня.
V>На язык С++ есть целая сетка версий стандартов.
И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии?
V>Обертка обертке рознь.
MTD>>Вот я написал плюсовую обертку над openssl что мне теперь кричать, что я гуру криптографиии и внес огромный вклад?
V>Ну, я тоже написал именно под openssl. V>Пару вечеров работы, и?
Сложности с пониманием написанного? Давай на пальцах, для чтобы даже до самых-самых дошло:
1. На С есть библиотеки, де-факто ставшие стандартом в предметной области, на С++ аналогов нет
2. Ты утверждаешь, что есть и приводишь ссылки на обертки над С либами
3. Я говорю, что написать обертку не большое достижение
4. Ты говоришь, что сам писал обертку за пару вечеров и спрашиваешь "и?"
Друг, как у тебя самочувствие?
V>Под дотнет такая же по функциональности обертка могла занять рабочую неделю.
Чего? Во-первых, дотнет — не язык, а платформа. Ты собрался сразу в байткоде писать? Во-вторых, можешь привести пример, где на C# что-то сделать сложней, чем на С++? Вычисление факториала на этапе компиляции не считается. В-третьих, писать обертки, а потом обертки над обертками — традиционная забава С++ разработчиков, в C# уже есть System.Security.Cryptography
V>>>Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51 MTD>>Для них нет компиляторов С++? Это что же ты так решил высказаться, что С++ отстой?
V>Так и дотнета под них нет.
У тебя проблемы с дотнетом? Я его нигде не упоминал, а у тебя он все чешется.
V>Может, это просто такие специфические архитектуры, что под них даже реализация языка идёт С в сильно урезанном виде?
С теперь тоже отстой? Итого, руководствуясь твоей логикой, выбрасываем С++, выбрасываем С, оставляем только ассемблер, потому, что на некоей сферической платформе в вакууме нет полноценных компиляторов С и С++.
V>QT — это просто хороший пример того, что не всё зависит только от языка. Язык же не в вакууме живёт, а на конкретных аппаратных и программных платформах.
Глубокомысленно. Что сказать хотел?
V>Поэтому, тот же GTK+ сугубо сишный.
Почему?
MTD>>Хочешь длиной меряться? Ну расскажи, что ты на С++ написал.
V>Какая прикладная область интересует?
Любая, чем больше всего гордишься?
V>Не требуют оборачивания структуры, перечисления, константы и т.д. и т.п.
Конечно требуют. Дефайны из С просто необходимо обернуть в неймспейсы и засунуть в перечисления.
Здравствуйте, MTD, Вы писали:
MTD>Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal?
Этот бред еще продолжают обсуждать и на него еще продолжают ссылаться? OMG
Во-первых, часть библиотек специально разрабатывается на чистом C, поскольку:
a) язык C присутствует на большем количестве платформ, чем какой-либо другой язык (включая C++);
b) язык C упрощает использование библиотеки из других языков программирования, т.к. Perl, Python, Ruby, Erlang, PHP и пр., что гораздо сложнее сделать с библиотеками на C++.
Уже из-за этих двух факторов разработчики библиотек вынуждены выбирать чистый C, даже если они сами бы предпочли использовать вместо C какой-нибудь другой ЯП (и не обязательно это будет C++). Но есть и еще один фактор, а именно:
c) наличие уже существующей библиотеки на C делает ненужным повторение ее функциональности на C++, ибо сишные библиотеки являются родными для C++. Соответственно, нет смысла переписывать zlib на C++, если zlib уже без дополнительных телодвижений доступна для C++.
В принципе, разумным людям все это и так понятно, но поскольку все это приходится объяснять персонально господину MTD, то специально для MTD нужно указать один простой факт: в попытке натянуть сову на глобус вы включили в список чисто сишных библиотек библиотеку ICU, которая написана на C++. Так что сам этот список и попытки апелляции к нему уже можно спускать в /dev/null.
Здравствуйте, MTD, Вы писали:
MTD>ОМГ, какая дичь. POSIX существует с незапамятных времен, а в нем есть описание семафора — это такой примитив на котором элементарно строятся любые конструкции и который в С++ до сих пор не осилили.
Реализаций семафоров куча разных.
И ты не понял о чём речь.
Библиотеку Boost.Thread пилят с 2000-го года и на сегодня это уже 4-я её версия.
Все версии м/у собой не совместимы.
MTD>А то, что на каком-то утюге нет потоков, так просто на утюге не было бы файла thread.
Беда, беда.
Т.е. ты даже не понял, о чём тебе говорили.
ЛЮБОЙ более-менее большой дотнетный проект содержит в себе еще несколько проектов (речь доходит до десятка-другого порой). Сугубо внутренних проектов, разумеется. С т.з. нейтива это давно уже дикость.
