Я думаю, это ответ Гугла на действия Microsoft: линк. Например, HTC платит 5 баксов за каждый проданный андроид. Если предположить среднюю стоимость девайса 200 баксов, то получится 2.5% за каждый проданный девайс, что соразмерно с тем, что просит Гугл.
В каком-то смысле, от того, откроется код или нет, качество кода не зависит. Но мы же говорим о процессе, так? Для этого можно вспомнить разновидности тестирования кода: black box, gray box и т.д. Все они важны, но когда знаешь, как объект тестирования устроен, тогда можно написать более интересные тесты на выявление проблем. Так и с открытым кодом. Есть немало энтузиастов, которые могут помогать проекту, выявлять ошибки и критические проблемы. Это делать гораздо проще, если проект отрытый.
Я не хочу сказать, что это — краеугольный камень качества. Самое главное — это толковые программисты высокого уровня. Но тем не менее, открытость может помогать. Однако если не реагировать на ошибки, о которых заявляют сторонние разработчики, то тогда открытость может и мешать, т.к. позволяет (теоретически) обнаружить больше багов, которые можно использовать в качестве уязвимостей в случае, когда их фиксят неоперативно.
Надо не останавливаться на этом. Далее надо будет ввести «принципы» ответственности тем, кто печатает газеты и журналы, за то, что они могут нарушать копирайт. Затем ввести поправки, чтобы сотовые операторы несли ответственность за разжигание межнациональной розни при разговоре по телефону. Ну и под занавес ввести наказание на производителей туалетной бумаги за то, что на ней можно написать неприличное слово.
Считаю, что кастомеру ничего не понравится. Ему локализация бага неинтересна, он уже теряет деньги на этом баге. Ему интересно, когда он перестанет их терять. Поэтому тут все несколько сложнее. По хорошему, ассерты должны быть продублированы правильным «еррор-хендлингом», т.е. обработкой ошибок. Именно так рекомендуют делать для серьезных программ.
На мой взгляд, статья не полностью покрывает весь спектр того, что стоит использовать при программировании в энтерпрайзе. Вот представим, что у нас продукт, который стоит у сотни тысяч кастомеров и одна ошибка будет дорого стоить. Что тогда? Согласны ли вы, чтобы ваш любимый софт иногда падал с ассертом в каком-то специфическом сценарии. Да, конечно, с точки зрения прогаммиста все пучково — есть баг, ассерт его поймал вовремя, вот колстек, вперед. Попробуйте это объяснить кастомеру. А кастомер этот какой-нибудь крупный банк или страховщик. Что он скажет? Скажет: вот ассерт у вас тут сработал, вот вам колстек, коредамп, молодцы мужики, что не оставили неопределенное поведение. Да? Сомневаюсь. С точки зрения программиста ассерты — это добро, с точки зрения кастомера — зло. Поэтому правильный подход — использование исключений и тотальный контроль и обработка ошибок. Любой ассерт должен быть продублирован обработкой ошибок. А самые классные ассерты — это те, которые кидают исключение при срабатывании. Но для этого необходимо транзакционное поведение на любом уровне. Вот этого я, к сожалению, не увидел в статье.
Забавно, что график уязвимости в браузерах не соответствует таблице:
Например, для хрома почему-то берутся суммы для разных версий, причем если посмотреть сумму уровня «высокий», то получится 177, а не 197, как на графике. Для эксплорера сумма почему-то не считается, а берется от балды число 20 для того же уровня «высокий». Далее, я не уверен, что для хрома считались разные уязвимости для разных версий, т.е. вполне возможно, что одна и та же уязвимость попала одновременно в разные версии. В общем, есть ложь, большая ложь и статистика.
Имелось ввиду описание языка и его поддержка со стороны компиляторов. Конечно, auto и лямбды — это все отлично, но вот лямбды могут быть вложенные, переменные могут в первом случае браться по ссылке, во втором: по значению. И это все надо описывать.
Да, такая идея мне по душе. Т.е. обладать полной совместимостью, но при этом иметь другой синтаксис, более удобный. А также иметь возможность, скажем, преобразовывать хедера из C++ в новый язык. Но такого никто не будет делать. Для ентерпрайза это все равно очень обременительно. В компании, где я работаю, GCC не обновляли 10 лет. 10 ЛЕТ!!! А вы говорите.
Речь не про то, что можно или нельзя. Конечно можно. Вопрос в том, стоит ли на основании этой трансляции делать выводы о производительности. На мой взгляд ответ — нет. Более того, это даже неправильно, т.к. на производительность могут влиять многие достаточно тонкие эффекты и вещи.
В момент вызова метода process компилятор однозначно понимает, какую функцию нужно позвать. Почему бы не использовать это знание? Более того, компилятор msvc так и делает. Я тут не вижу проблем.
Ну я бы не сказал, что она была общей. Она была вообще про другое: как старый преобразователь поганит код C++ при переходе к C. Ничего общего к проблеме исключений это не имеет. И взяв этот преобразователь говорить о нечто общем — это несколько странно. Тут скорее взят некий очень частный случай, не имеющий с реальной жизнью ничего общего.
Прикол в том, что некоторые вещи сложно показать на псевдокоде. Вообще, это странная постановка вопроса: компилятор преобразует код С++ в байты, грубо говоря ассемблер. При этом непонятно, при чем тут С? Не каждый код может быть легко и непринужденно лечь на код С. Это иллюзия, что С++ со своими конструкциями сводится к С.
Я ожидал в статье увидеть разбор того, как генерируются исключения на современенных компляторах и платформах, когда происходит zero overhead, генерируются таблицы и по ним и колстеку происходит раскрутка. Например, компилятор msvc x64 добавляет nop операции и использует это при генерации исключений. Ничего подобного, что описано в этой статье, к данному случаю не имеет. Таким образом статья получилась как сферический конь в вакууме. Автору стоит внимательней изучить матчасть современных компиляторов.
вход платный/бесплатный?
сколько по времени будет длиться это мероприятие?
будет ли раздача слонов?
Я не хочу сказать, что это — краеугольный камень качества. Самое главное — это толковые программисты высокого уровня. Но тем не менее, открытость может помогать. Однако если не реагировать на ошибки, о которых заявляют сторонние разработчики, то тогда открытость может и мешать, т.к. позволяет (теоретически) обнаружить больше багов, которые можно использовать в качестве уязвимостей в случае, когда их фиксят неоперативно.
Например, для хрома почему-то берутся суммы для разных версий, причем если посмотреть сумму уровня «высокий», то получится 177, а не 197, как на графике. Для эксплорера сумма почему-то не считается, а берется от балды число 20 для того же уровня «высокий». Далее, я не уверен, что для хрома считались разные уязвимости для разных версий, т.е. вполне возможно, что одна и та же уязвимость попала одновременно в разные версии. В общем, есть ложь, большая ложь и статистика.
BBBBB b1;
b1.process();
В момент вызова метода process компилятор однозначно понимает, какую функцию нужно позвать. Почему бы не использовать это знание? Более того, компилятор msvc так и делает. Я тут не вижу проблем.
Я ожидал в статье увидеть разбор того, как генерируются исключения на современенных компляторах и платформах, когда происходит zero overhead, генерируются таблицы и по ним и колстеку происходит раскрутка. Например, компилятор msvc x64 добавляет nop операции и использует это при генерации исключений. Ничего подобного, что описано в этой статье, к данному случаю не имеет. Таким образом статья получилась как сферический конь в вакууме. Автору стоит внимательней изучить матчасть современных компиляторов.