Но потом возникла идея продемонстрировать как сложно в цепепе заставлять делать компилятор то, что хочется
А потом я показал на static_assert как это просто, ага. Тебе что надо - рабочий код писать или пытаться на С++ писать как на лиспе, причем без всякой надобности? Это совсем другой язык, местами примитивный, местами опасный, местами костыльный. Да все знают его огромное кол-во недостатков, зачем пытаться их нарочно усугублять? Логично поступать наоборот.
Громко сказано, в «промышленном» (с) Firefox нет ни одной строки на Rust, но есть попытка неудачников разрабов на Rust, которые провалили все сроки по Servo, приклеиться к успешному проекту, чтоб поезд не ушел без них.
А потом я показал на static_assert как это просто, ага.
До того, как ты показал на static_assert - я его уже попробовал, на что gcc выдал мне не внятную ошибку, и я подумал, что использование static_assert - это хак сродни тому, который когда-то демонстрировал Степанов с sizeof для отбраковки недопустимых классов в качестве параметра шаблона :-) Потом этот трюк повторял Александреску :-)
Да все знают его огромное кол-во недостатков, зачем пытаться их нарочно усугублять? Логично поступать наоборот.
Чтобы обратить внимание на другие языки, чтобы не становились жертвами пропаганды «безальтернативному» цепепе :-) Это не так :-)
Чтобы обратить внимание на другие языки, чтобы не становились жертвами пропаганды «безальтернативному» цепепе
Так показывай примеры на других языках, это будет гораздо эффективнее. Создавай топики по лиспу и пр. А так как раз и создается впечатление безальтернативности, что вот все обсуждают С++, худо-бедно находят различные решения, а остальное даже не стоит смотреть. Ну а ты в данном случае выглядишь как обычный хейтер, которого вообще нет смысла слушать, т.к. хейтеры люди неадекватные.
если не секрет, что за cерверный софт вы разрабатываете и какие данные он молотит?
Самый что ни на есть обычный разобычный :-) Как-то ночью посетила мысль, пруф которой обнаружил в книге про построение микросервисов Сэма Ньюмана :-) Вот такого типа серверный софт :-) Кстати, книжку рекомендую :-) Называется «Building Microservices» :-)
Скорость рендеринга, количество ошибок на единицу кода и т.п.
вы не видите сферу применения для C++.
Поправка: я не вижу сферы где C++ в нынешних условиях был бы лучше любого другого инструмента. Единственная причина его популярности - куча легаси кода и легаси программистов, которые считают, что ничего кроме C++ в мире не существует. Как раз те самые «программисты на одном языке», да.
Скорость рендеринга, количество ошибок на единицу кода и т.п.
По-моему мнению, это все ерунда, поскольку:
- ценность представляет конечный браузер с GUI, интеграцией с различными системными и сетевыми сервисами, с плагинами и пр.
- движок Servo написан с нуля, с учетом опыта движка Gecko. Т.е. сравнивается новый код с очень старым. Неизвестно, какого качества был бы новый движок, если бы его начали с нуля делать на C++11 или C++14.
я не вижу сферы где C++ в нынешних условиях был бы лучше любого другого инструмента
Не вижу в этом никакой проблемы. Как же, впрочем, как и вашего влияния на развитие индустрии разработки ПО. Без обид, ничего личного, но ни вы, ни я своим мнение на LOR-е ничего не меняем.
сравнивается новый код с очень старым. Неизвестно, какого качества был бы новый движок, если бы его начали с нуля делать на C++11 или C++14.
Это не имеет значения. Тот же Webkit тоже был начат практически с нуля намного позже Gecko, но страдает от тех же болезней. Если мы возьмём отчёты CVE о дырах в Gecko и Webkit, то где-то 70% уязвимостей вызваны неправильной работой с памятью (buffer overflow, read after free, etc. http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?vendor_id=452 график по типам справа внизу). То есть, количество ошибок можно было бы сократить на 70% одним только использованиям языка с автоматическим управлением памятью. C++11/14 в этом плане абсолютно ничего не меняют.
Меняют. Move-semantic, unique_ptr/shared_ptr из коробки (а так же выбрасывание auto_ptr), range-for и даже автоматический вывод типа переменной увеличивают надежность кода. Да и просто повышение уровня абстракции за счет тех же move-semantic и variadic-templates позволяет писать меньше, а значит больше уделять внимания качеству кода.
Кроме того, Servo выглядит круто пока его взламывать не начали. Ибо нечего пока еще взламывать.
PS. Еще лямбды забыл упомянуть, так же сильно жизнь упрощают.
Mozilla code only uses a subset of C++. Runtime type information (RTTI) is disabled, as it tends to cause a very large increase in codesize. This means that dynamic_cast, typeid() and <typeinfo> cannot be used in Mozilla code. Also disabled are exceptions; do not use try/catch or throw any exceptions. Libraries that throw exceptions may be used if you are willing to have the throw instead be treated as an abort.
RTTI и исключения сильно упрощают код и увеличивают его надежность. Посмотрите на примеры кода выше по обсуждению и попробуйте переписать их так, чтобы в них исключения не использовались.
Разве одна из рекламируемых фич C++ не в том, что ненужные части языка можно отключить?
Не знаю, про что вы говорите. Знаю про лозунг «не платите за то, что не используете». Но из этого лозунга не следует, что отказавшись от фичи X разработка на C++ вам будет обходиться дешевле, а результат будет получаться лучше.
Кстати, стандарт ведь не запрещает менять буфер строки через &str[0]?
Если это только не пустая строка, где еще не был выделен буфер. Старый стандарт ЕМНИП в этом случае допускал UB и ты даже на чтении мог упасть. В новом тебе вернут валидный указатель, но он может быть на константу, одну для всех экземпляров строк. И если ты сделаешь &s[0]=0 (что смысла обычно не имеет), то можешь получить креш.
После модификации содержимого строки a через operator[] не должен меняться указатель возращенный перед этим методом data() (если других модифицирующих операций не было).
Ну расскажите, как добиться этого бага в реальной программе, где тип size_type покрывает все доступное программе адресное пространство и, следовательно, ни одна строка не может иметь такой длины.
Ну расскажите, как добиться этого бага в реальной программе, где тип size_type покрывает все доступное программе адресное пространство и, следовательно, ни одна строка не может иметь такой длины.
Это уже другой вопрос :-) А баг там есть :-) Так же как и баг из-за отсутствия проверки на NULL от malloc :-) В реале это тоже маловероятно и сложно, но возможно :-)