Здравствуйте, Pzz, Вы писали:
Pzz>Я серьезно. Обычно этого достаточно.
Это не серьезно. И недостаточно. По целому ряду причин. Начиная от того, что документацию не всегда читают (а даже когда читают, она не всегда достоверна и актуальна). И заканчивая тем, что документации может вообще не быть. Опять же из недавнего: сейчас нужно задокументировать большой объем кода, который получился в результате длительных экспериментов. Пока эксперименты шли не было ни смысла ни времени писать документацию, слишком сильно и кардинально все менялось. Тем не менее компилятор был в состоянии бить по рукам за неправильное использование функций.
Pzz> Проблемы вылезают в более сложных случаях, и попытка защититься от них детальным описыванием контрактов на неуклюжем языке системы
Конструктивнее было бы рассматривать конкретные примеры, а не ваши образные сравнения. И еще конструктивнее было бы увидеть, чем чистый C в этих случаях лучше C++.
Pzz>Я против того, чтобы к программе прилагать еще в два раза больше кода, написанного на загадочном языке, с единственной целью — описать правила игры, по которым осуществляются проверки.
А там не будет много кода. А там где кода много, там помогает постепенное изменение языка. Например, введение в язык variadic templates драматично сократило объем кода для случаев с переменным количеством аргументов. А добавление в C++20 концептов сделает и другие случаи гораздо компактнее и понятнее.
S>>Или вот вы видите прототип функции: S>>
S>>Как вы поймете где можно передавать NULL, где нельзя? Как вы поймете, кто отвечает за удаление чего?
Pzz>Никак не пойму, если в документации не написано. Чем мне станет легче, если синтаксически передавать NULL нельзя, а что в параметрах писать, мне все равно не понятно?
А вы просто сравните показанный выше прототип вот с таким:
Здравствуйте, so5team, Вы писали:
S>>>Здесь нет противоречия. После достижения некоторого уровня владения C++ в привычной для тебя предметной области C++ перестает вызывать серьезные сложности. Т.е. выстрелы в ногу все еще случаются, но редко.
Pzz>>
Если вас трамвай задавит,
Pzz>>вы конечно вскрикнете,
Pzz>>раз задавит, два задавит,
Pzz>>а потом привыкнете.
S>Что бы это значило?
Ну ты говоришь, в защиту C++, что ко всему можно привыкнуть. А я отвечаю, что на эту тему, что ко всему можно привыкнуть, даже стишок классный написан.
S>Если сравнивать C++ с чистым C, то есть достаточно простой выбор:
S>* использовать C++, тратить время на обучение сотрудников и получать кодовую базу более-менее приемлемого размера, в которой, местами, качество и безопасность будет обеспечиваться средствами самого языка; S>* использовать чистый C, тратить время на обучение сотрудников и получать гораздо более объемную кодовую базу, в которой безопасность и качество вообще ничем не обеспечивается кроме честного слова.
Это ложная дилема. C++ не обеспечивает, сам по себе, "кодовую базу более-менее приемлемого размера, в которой, местами, качество и безопасность будет обеспечиваться средствами самого языка". C не обеспечивает сам по себе "гораздо более объемную кодовую базу, в которой безопасность и качество вообще ничем не обеспечивается кроме честного слова".
В целом, в проекте на C++ может быть меньше кода за счет более широкого использования сторонних библиотек и фреймворков (которые зачастую проще найти, годные, для C++, чем для C), но если говорить о написании нового, оригинального кода, а не об интеграции посторонних библиотек, код на C получается компактнее. Что до надежности безопасности, за C++ говорит несколько большая способность компилятора статически проанализировать программу, а за C говорит куда как большая простота языка, и отсутствие скрытой магии. Какая из тенденций окажется сильнее, зависит не от языка, а от людей, которые им пользуются.
S>Поэтому, когда речь заходит о коммерческих проектах, в которых сроки и бюджеты не резиновые, C++ уже много десятилетий уверенно обходит чистый C. Сдаются даже разработчики эбмедеда, которые сопротивляются вытеснению чистого С сильнее всего.
Если бы индустрия выбирала языки за их языковые достоинства, вряд ли бы javascript получил такое широкое распостранение. В целом, ссылаться на опыт индустрии, как на критерий качества языка, бессмысленно.
В коммерческих проектах обычно заложен куда как больший бюджет, чем в опенсорсных. Иногда пытаются за счет бюджета сократить время, с переменным успехом.
S>А в OpenSource чистый C продолжает жить. И мнение Торвальдса выносят на знамена, хотя вряд ли кто-то сможет перечислить коммерческие проекты Торвальдса, выполненные в рамках бюджетов, сроков и в соответствии с жестко заданными требованиями.
Торвальдс снес золотых яиц для мировой буржуазии пожалуй больше, чем любой другой. Как-то глупо его обвинять, что он несет эти яйца не по заранее утвержденному менеджерами расписанию.
Здравствуйте, Pzz, Вы писали:
S>>Что бы это значило?
Pzz>Ну ты говоришь, в защиту C++, что ко всему можно привыкнуть. А я отвечаю, что на эту тему, что ко всему можно привыкнуть, даже стишок классный написан.
Речь не про привыкнуть, а про то, что после изучения нескольких фич C++ использование C++ для конкретного разработчика перестает быть проблемой. Тут дело не в привычках, а в знаниях и опыте.
Pzz>Это ложная дилема.
Нет.
Pzz>C++ не обеспечивает, сам по себе, "кодовую базу более-менее приемлемого размера, в которой, местами, качество и безопасность будет обеспечиваться средствами самого языка".
Сам по себе нет. Но у него есть для этого хотя бы некоторые возможности.
Pzz>C не обеспечивает сам по себе "гораздо более объемную кодовую базу, в которой безопасность и качество вообще ничем не обеспечивается кроме честного слова".
А вот тут обеспечивает как раз таки. Целиком и полностью. Ибо возможностей для разработки своих абстракций или выражения ограничений нет от слова совсем.
Pzz>В целом, в проекте на C++ может быть меньше кода за счет более широкого использования сторонних библиотек и фреймворков (которые зачастую проще найти, годные, для C++, чем для C), но если говорить о написании нового, оригинального кода, а не об интеграции посторонних библиотек, код на C получается компактнее.
Нуждается в доказательствах.
Pzz>а от людей, которые им пользуются.
Тогда нужно определиться с предметом обсуждения: либо обсуждаются свойства языка, которые могут быть использованы при должном уровне подготовки разработчика. Либо обсуждаются сами разработчики.
S>>А в OpenSource чистый C продолжает жить. И мнение Торвальдса выносят на знамена, хотя вряд ли кто-то сможет перечислить коммерческие проекты Торвальдса, выполненные в рамках бюджетов, сроков и в соответствии с жестко заданными требованиями.
Pzz>Торвальдс снес золотых яиц для мировой буржуазии пожалуй больше, чем любой другой. Как-то глупо его обвинять, что он несет эти яйца не по заранее утвержденному менеджерами расписанию.
Вы не поняли. Достижения Торвальдса не ставятся под сомнение. Упор делается на то, что разработка ядра Linux-а или git-а принципиально отличается от коммерческой разработки под заказ или коммерческой разработки коробочного продукта. Поэтому то, что хорошо работало для Торвальдса не обязательно должно работать для условных "Рогов и Копыт".
Я бы передавал параметры логически по значению, потому что как-то глупо открывать устройство без указания параметров, а технически по константной ссылке, чтобы избежать лишнего копирования (хоть это и смешная экономия на фоне открытия устройства), и сделал бы у класса device_params_t конструктор, который все абсолютно необходимые параметры (имя девайса, к примеру) требует явно, а остальные заполняет осмысленными значениями по умолчанию. А зачем там обязательный timeout_handler, понять вообще невозможно, и почему именно timeout заслужил такого особого обращения, в отличии от всех прочих возможных ошибок.
S>А еще лучше вот с таким: S>
Здесь от обилия умных слов и угловых скобок уже настолько рябит в глазах, что теряется смысл.
И тем не менее, в этой конструкции не написано, кому принадлежит объект params после возврата из функции. Например, можно ли его завести на стеке, можно ли его потом изменить и еще раз использовать, или где-то там на него сохранилась ссылочка, и это приведет к катастрофе.
Т.е., C++ позволил учесть некоторые типичные ошибки, но полной ясности не внес. При этом я полагаю, что вы — очень опытный плюсовый программист, но все равно всего не учитываете. А вот уровень сложности возрос многократно. Стоила ли овчинка выделки?
Здравствуйте, Pzz, Вы писали:
Pzz>Я бы передавал параметры логически по значению
Вот этот вот "я бы" смогло появиться именно потому, что более богатые прототипы функций дают вам больше информации, чем скудные прототипы функций в чистом C.
Все остальные рассуждения поскипаны поскольку не имеют отношения к предмету разговора. Отметим лишь, что timeout_handler передается не для того, чтобы обрабатывать ошибку, а для того, чтобы иметь возможность отсчитать тайм-аут, чтобы не пришлось делать внутри явный вызов Sleep/sleep/usleep или еще чего-то.
S>>А еще лучше вот с таким: S>>
Pzz>Здесь от обилия умных слов и угловых скобок уже настолько рябит в глазах, что теряется смысл.
Это лирика. Или неосиляторство.
Pzz>И тем не менее, в этой конструкции не написано, кому принадлежит объект params после возврата из функции.
Скорее неосиляроство. Поскольку unique_ptr явно передает владение объектом в вызываемую функцию. И прототип функции об этом недвусмысленного говорит знающему C++ разработчику.
А когда разработчик C++ не знает, то можно какие угодно мифы о C++ рассказывать.
Здравствуйте, Masterspline, Вы писали:почему".
M>IMHO, если в команде бардак, то либо исполнители не хотят, не умеют, не знают, что они должны делать, либо между ними не налажено взаимодействие.
Запросто бывает так, что в команде — ни следа бардака, всё отлично налажено, все всё знают, и взаимодействие налажено. А продукт всё равно отстой.
Ну, например потому, что дизайнер не знает, как устроен HTML, а умеет только рисовать картинки.
Фронтендер не понимает, как работает бэкенд, поэтому лепит топорный UI, думая "ну вот такие мне дали методы в API".
Бэкендер тем временем не в курсе, что там в UI, поэтому говорит "я сделал все методы, как просил фронтендер". Зато с DBA у них хорошо налажено взаимодействие, и запрошенную им табличку "номера заказов, сгенерированные для клиентов" создали по первому реквесту — бэкендер-то не в курсе про sequences в выбранной СУБД, он джавист, а для деталей есть DBA.
M>Альтернативный вариант — объяснить исполнителям конечную цель всей команды, зону ответственности каждого и с кем и как взаимодействовать, если задача выходит за пределы твоей зоны ответственности. Рулевой влезает только когда что-то пошло не так. В результате думать будет сильно больше одной головы, каждый замотивирован рулить с своей зоне ответственности, у каждого квалификация сильно выше, чем у "избранного". Минусы — тимлид не будет чувствовать себя богом, ибо порулить почти не получится — многие задачи решатся без его участия.
S>>Привыкайте, камрады — грядёт эпоха смежных специальностей. M>Насколько это грядет не знаю, возможно в сферах, где один "бох" сможет рулить смердами ниже среднего и большой текучкой.
Вы рассказываете вовсе не про смежные специальности, а про звёздную болезнь. Одно к другому отношения не имеет.
Смежные специальности — это по-прежнему командная работа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, so5team, Вы писали:
S>Речь не про привыкнуть, а про то, что после изучения нескольких фич C++ использование C++ для конкретного разработчика перестает быть проблемой. Тут дело не в привычках, а в знаниях и опыте.
Никакая конкретная фича C++ не является сама по себе проблемой. Проблемой является невероятная сложность, необъятность и запутанность языка в целом.
S>А вот тут обеспечивает как раз таки. Целиком и полностью. Ибо возможностей для разработки своих абстракций или выражения ограничений нет от слова совсем.
Обстракции, хм. Для обстракциев языку не помешало бы иметь алгебраические типы, паттерн матчинг, лямбда-функции и замыкания. Этого всего нету ни в C, ни в C++, ни в моем любимом Go. В Go, впрочем, немножко есть, но в очень уж зачаточном виде.
Отсутствие в языке абстракций не очень заметно, когда пишется какая-нибудь хрень, типа драйвера устройства, но когда надо делать нетривиальные операции с нетривиальными данными (например, написать оптимизирующий кодогенератор для компилятора), то их отсутствие становится очень заметным.
Pzz>>В целом, в проекте на C++ может быть меньше кода за счет более широкого использования сторонних библиотек и фреймворков (которые зачастую проще найти, годные, для C++, чем для C), но если говорить о написании нового, оригинального кода, а не об интеграции посторонних библиотек, код на C получается компактнее.
S>Нуждается в доказательствах.
Ну какие тут могут быть доказательства? Могу лишь сослаться на свой собственный опыт, но кто ж его примет в качестве доказательства?
Pzz>>а от людей, которые им пользуются.
S>Тогда нужно определиться с предметом обсуждения: либо обсуждаются свойства языка, которые могут быть использованы при должном уровне подготовки разработчика. Либо обсуждаются сами разработчики.
Это взаимосвязанные вещи. Языком пользуются люди, люди имеют свои ограничения, глупо их не учитывать. В общем и целом, человек не способен удерживать в голове слишком сложную конструкцию, язык (и прочие инструменты) должен способствовать упрощению вещей, а не наоборот.
S>Вы не поняли. Достижения Торвальдса не ставятся под сомнение. Упор делается на то, что разработка ядра Linux-а или git-а принципиально отличается от коммерческой разработки под заказ или коммерческой разработки коробочного продукта. Поэтому то, что хорошо работало для Торвальдса не обязательно должно работать для условных "Рогов и Копыт".
Единственное принципиальное отличие, которое вижу я, заключается в том, что линуксоиды не могут просто так взять и потратить несколько миллиардов долларов на разработку очередной версии ядра. Поэтому в ядре линиха около 300 системных вызовов, а не несколько тысяч, как в менее ограниченных в бюджете операционных системах.
Здравствуйте, Pzz, Вы писали:
Pzz>Никакая конкретная фича C++ не является сама по себе проблемой. Проблемой является невероятная сложность, необъятность и запутанность языка в целом.
Ну так вам как раз и говорят о том, что мало кому нужно знать C++ в целом. Достаточно некоторого подмножества, изучение которого, хоть и не простое и не быстрое дело, но более-менее возможное.
S>>А вот тут обеспечивает как раз таки. Целиком и полностью. Ибо возможностей для разработки своих абстракций или выражения ограничений нет от слова совсем.
Pzz>Обстракции, хм. Для обстракциев языку не помешало бы иметь алгебраические типы, паттерн матчинг, лямбда-функции и замыкания. Этого всего нету ни в C, ни в C++, ни в моем любимом Go.
Лямбда-функции в C++ есть с C++11 прямо на уровне синтаксического сахара. С учетом capture list для лямбд можно говорить и про замыкания.
АлгТД и паттерн-матчинга не хватает. В C++17 из коробки можно пользоваться std::variant и std::visit (вместе с трюком overloaded). В последующие стандарты могут и паттерн-матчинг завезти. Предложения для этого формируются.
Так что даже из вашего списка в C++ гораздо больше инструментов, чем в чистом C.
S>>Нуждается в доказательствах.
Pzz>Ну какие тут могут быть доказательства? Могу лишь сослаться на свой собственный опыт, но кто ж его примет в качестве доказательства?
Можно привести какой-то пример кода. Не обязательно своего.
Здравствуйте, so5team, Вы писали:
Pzz>>Я бы передавал параметры логически по значению
S>Вот этот вот "я бы" смогло появиться именно потому, что более богатые прототипы функций дают вам больше информации, чем скудные прототипы функций в чистом C.
Дают, я не спорю. Гляжу я на плюсовый прототип, и точно знаю, куда можно передавать NULL, а куда — нельзя.
Но самая интересная информация находится внутри структуры device_params_t, и я уверен, что в ее описании половина важных деталей упущена. А еще интересно знать, в какой момент могут позвать timeout_handler, и с контекста какого потока, и какие там ограничения возникают на вызовы других функций. А об этом тоже наверняка забыли упомянуть.
А вот можно ли передавать NULL в качестве параметров, это маловажное знание. Потому что даже если я ошибусь в этом месте, то я быстро узнаю правду, и долгоиграющих последствий от такой ошибки не будет.
S>Все остальные рассуждения поскипаны поскольку не имеют отношения к предмету разговора. Отметим лишь, что timeout_handler передается не для того, чтобы обрабатывать ошибку, а для того, чтобы иметь возможность отсчитать тайм-аут, чтобы не пришлось делать внутри явный вызов Sleep/sleep/usleep или еще чего-то.
Т.е., это некоторый сложный волшебный объект, которых умеет отсчитывать время, и получать нотификацию из недр open_device, что пора просыпаться, не дожидаясь истечения времени?
Pzz>>Здесь от обилия умных слов и угловых скобок уже настолько рябит в глазах, что теряется смысл.
S>Это лирика. Или неосиляторство.
Ну нет, конечно. Здесь слов много, а сказано мало.
Pzz>>И тем не менее, в этой конструкции не написано, кому принадлежит объект params после возврата из функции.
S>Скорее неосиляроство. Поскольку unique_ptr явно передает владение объектом в вызываемую функцию. И прототип функции об этом недвусмысленного говорит знающему C++ разработчику.
Ну я не знаток C++, могу и не знать этих ваших новомодных оберток над указателями, которых в последнее врямя кучу наплодили.
А зачем эти параметры неприменно надо на куче заводить?
S>А когда разработчик C++ не знает, то можно какие угодно мифы о C++ рассказывать.
Незнание бывает разное. Если человек понимает, на каких идеях язык основан, знание контретного синтаксиса или конкретного названия конкретной финтифлюшки не принципиально.
Здравствуйте, so5team, Вы писали:
Pzz>>Никакая конкретная фича C++ не является сама по себе проблемой. Проблемой является невероятная сложность, необъятность и запутанность языка в целом.
S>Ну так вам как раз и говорят о том, что мало кому нужно знать C++ в целом. Достаточно некоторого подмножества, изучение которого, хоть и не простое и не быстрое дело, но более-менее возможное.
Пятый раз повторяю, что это не сработает, потому что нет способа запретить "лишним" конструкциям попадать в проект.
Pzz>>Обстракции, хм. Для обстракциев языку не помешало бы иметь алгебраические типы, паттерн матчинг, лямбда-функции и замыкания. Этого всего нету ни в C, ни в C++, ни в моем любимом Go.
S>Лямбда-функции в C++ есть с C++11 прямо на уровне синтаксического сахара. С учетом capture list для лямбд можно говорить и про замыкания.
Их там технически нет, видимость одна. То, как в C++ устроено управление памятью, не позволяет в общем случае при замыкании прихватить любую переменную из локальной области видимости.
Здравствуйте, Pzz, Вы писали:
Pzz>Дают, я не спорю. Гляжу я на плюсовый прототип, и точно знаю, куда можно передавать NULL, а куда — нельзя.
В этом и суть. Но знающий разработчик получает не только эту информацию.
Все остальные рассуждения -- это попытку увести разговор в сторону.
Pzz>А вот можно ли передавать NULL в качестве параметров, это маловажное знание. Потому что даже если я ошибусь в этом месте, то я быстро узнаю правду, и долгоиграющих последствий от такой ошибки не будет.
Это заблуждение, что в общем случае правда вскроется быстро. Может быть вскроется через полгода после запуска в эксплуатацию.
S>>Скорее неосиляроство. Поскольку unique_ptr явно передает владение объектом в вызываемую функцию. И прототип функции об этом недвусмысленного говорит знающему C++ разработчику.
Pzz>Ну я не знаток C++, могу и не знать этих ваших новомодных оберток над указателями, которых в последнее врямя кучу наплодили.
Это лишний раз подчеркивает, что к вашим рассуждениям о возможностях и применимости C++ нужно применять некий коэффициент достоверности. Не очень большой.
Pzz>А зачем эти параметры неприменно надо на куче заводить?
Зависит от задачи. Но это, опять же, попытка увести разговор в сторону. Важно, что один только прототип в C++ даст разработчику кучу информации.
Pzz>Незнание бывает разное. Если человек понимает, на каких идеях язык основан, знание контретного синтаксиса или конкретного названия конкретной финтифлюшки не принципиально.
Логика работы unique_ptr -- это как раз одна из основных идей языка со времен C++11.
Здравствуйте, Pzz, Вы писали:
Pzz>Пятый раз повторяю, что это не сработает, потому что нет способа запретить "лишним" конструкциям попадать в проект.
В принципе, есть. Начиная от code-review, заканчивая использованием специализированных автоматических инструментов (вроде как PVS-Studio может проверять код на соответствие MISRA C и MISRA C++).
Pzz>Их там технически нет, видимость одна. То, как в C++ устроено управление памятью, не позволяет в общем случае при замыкании прихватить любую переменную из локальной области видимости.
Тем не менее, они есть (в отличии от C) и позволяют делать разные полезные штуки, вроде Go-шных defer или D-шных at_scope_exit.
И это мы еще не рассматривали такие мощные инструменты для создания абстракций, как классы и шаблоны. Например, как вы в чистом C выразите абстракцию "значение в заданном диапазоне", которая на C++ делается влет простым шаблоном вроде:
template<class T, T Left, T right>
class constrained_value {
T v_;
public:
explicit constrained_value(T v) : v_(v) {
if( !(v_ >= Left && v_ <= Right) )
throw ...; // Или вызов abort.
}
operator T() const { return v_; }
};
using my_range = constrained_value<short, -500, 500>;
my_range get_current_value() {...}
Причем для написания такой примитивной версии не нужно больших познаний в языке. Они потребуются если захочется сделать constrained_value более универсальным и способным работать с разными типами, в том числе и не такими тривиальными, как short или long.
Здравствуйте, Marty, Вы писали:
M>Оченно прошу — расскажите, где вы работаете. И нет, не то, что вы подумали — давайте обойдемся без говна с оскорблениями и пр. — я к вам резуме посылать не буду, как раз и хочу избежать этого шага — нет смысла — и вам тоже проще
L>int calculateDistance(int a, int b) {
L> return a - b;
L>}
L>
L>Тупой единственный тест обеспечит 100% покрытие кода... но все ли сценарии покрыты?
И на таком рано или поздно валятся все: забыли, недосмотрели, жесткие дедлайны, программист устал, человек ушел в отпуск и кусок кода выкатывает другой человек...
B0FEE664, правда, свято верит, что где-то есть сферовакуумные программисты, которых проверяют специальные сторонние организации, которые пишут 100% тестов по 100% сценариев.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>>>Компиляторы точно на С++ писать не стоит. CC>>Так стоит или не стоит? CC>>По факту и на деле — видим что стОит. НС>В общем случае — не стоит. Конкретно для С++ — стоит.
Ну начинается виляние...
НС>При том что разговор был именно об этом. Но почему то стадо С++ решило, что я сказал, что написать на С++ компилятор вообще нельзя.
Нет, это просто ты решил быть категоричным, а теперь начинаешь отмазываться, причём оскорбляя тех, кто не купил имплант ясновидения и потому не догадался что под "Компиляторы точно на С++ писать не стоит" ты имел в виду ещё туеву хучу уточнений и оговорок.
Минус за "стадо".
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pzz, Вы писали:
Pzz>В комментарии к функции написать.
Бугага!!!
Pzz> Я серьезно.
Сколько ты лет работаешь в команде?
Pzz> Обычно этого достаточно.
Машине, но не людям.
Pzz>Ты пойми меня, пожалуйста, правильно. Я за статический анализ кода, я за то, чтобы компилятор проверил все, что возможно. Я против того, чтобы к программе прилагать еще в два раза больше кода, написанного на загадочном языке, с единственной целью — описать правила игры, по которым осуществляются проверки.
Откуда ты вытащил "в два раза больше кода"?
На плюсах как раз получается писать в разы меньше чем на С
Pzz>Никак не пойму, если в документации не написано.
Сишник?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Kolesiki, Вы писали:
K>А я бы копал в очевидную сферу C#+WPF+serices. Забацал трёхзвенку, налепил форм — щщастье! И главное — любой UI постоянно требует улучшений, которые тянут ещё и улучшение сервисов. Работы — непочатый край, в идеале — in house (потому что писать для "чужих" — отстой).
Забавно. ) А я бы таким не стал заниматься ни за какие деньги. )))
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>если С++ на помойку то на чем тогда писать ОС компиляторы и системыне утилиты НС>Компиляторы точно на С++ писать не стоит.
Нуу тут всё зависит от того, насколько принципиальна скорость сборки проекта. Если не особо, то я тут с тобой соглашусь.
Более того, я бы сказал, что это как раз одна из тех редких областей, где прямо напрашивается применение языка типа Хаскеля (по сути компиляция — это чистая трансформация). Вот только почему-то не видно его доминирования в данной, прямо напрашивающейся, области. Хотя фанаты Хаскеля утверждают о его применимости чуть ли не вообще везде (например в GUI и т.п.). Но при этом почему-то не могут обеспечить приемлемого присутствия даже в казалось бы естественной нише.
А так, сейчас наверное большинство компиляторов написаны на C++. Я это не считаю однозначно правильным, но такова жизнь...
Вот для создания различных виртуальных машин (типа JVM, CLR, CPython и т.п.) понятно что альтернативы C++ просто нет (ну точнее в будущем весьма возможно Rust сможет, но пока ещё он слишком не развитый) по вполне понятным причинам. Но компиляторы и т.п. действительно интереснее было бы писать на чём-то типа Хаскеля...
Здравствуйте, smeeld, Вы писали:
S>Отклонившись от темы, скажу, что крупнейшие проекты "промышленного" юзерспайсового софта, всевозможные сервисы, СУБД, прокся, написанные на C++-это всё не настоящий C++ в понимании здешних адептов C++, там тот самый Cи c классами. Это почти Cи c очень немногочисленными вещами из C++ времён раннего Страуструпа. Это говорю как чувак, много лет провозившийся с тоннами кода таких систем.
Тебе приходится много лет возиться с тоннами legacy кода? Даже не могу выразить всю степень своего сочувствия... Наверное на такое могут сподвигнуть только очень тяжёлые жизненные обстоятельства...
