Сегодня нечто не может быть 2 Gb, а завтра — вполне. Вот прямо сейчас разработчики OpenMPI в списке рассылки разгребают проблемы, связанные с тем, что там размеры объектов в int вычисляются. А ведь раньше такие огромные сообщения «нормальным кейсом» не были.
Qt использует int для размеров и создаёт этим кучу проблем для кода, который в остальных местах использует size_t. По-моему очень спорное решение, не ясно какая была мотивация.
setjump/longjump (SJLJ) — это медленный способ реализации исключений.
В zero-cost способе в случае исключения у нас будет поиск нужного обработчика по таблицам и это может быть не быстро. Но для установки обработчика не нужно производить сложных действий. Поэтому если исключения нет — то мы за обработчики не платим.
> А можно показать это на псевдо-коде? Очень же интересно.
На основе таблиц. Погуглите, до меня хорошо расписано в сотнях источников.
> Я бы не стал заносить Intel и TI в эту категорию.
Qualcomm для Hexagon пилят backend (open source!) для llvm. Автоматически получают все самые свежие возможности C++. Они любят своих пользователей.
> То есть: просто включение поддержки исключений привело и к увеличению объёма конечного бинарного файла
Существенная деталь: в вашем трансляторе (суть которого — костыль для процессоров, разработчики которых не любят своих пользователей). В большинстве современных трансляторов используются zero-cost exceptions.
Проблема с исключениями для embedded и real-time в том, что очень сложно реализовать throw так, чтобы для вызова соответствующего catch была оценка времени сверху.
Над *проектом* не получится, а над исходниками — должно получиться. Хотя clang не поддерживает всех Microsoft расширений, если вы найдёте что-то неподдерживоемое, сообщите, пожалуйста, в список рассылки cfe-dev.
> Ну знаете, библиотеки — несомненно важная вещь, но они не язык.
Я говорил о другом. Из упомянутых 1300 страниц C++11 больше половины — STL. Сравнивать со спецификацией на C# по объёму нужно ту часть стандарта, которая описывает язык — а их там остаётся как раз около 500.
> Более того, от книги страуструпа у меня остался такой осадок, что примерно 40-50% информации — описание и способы избежания возможных ошибок.
А у D есть спецификация, при составлении которой дотошно рассмотрена каждая возможная комбинация фич языка? Продуманы undefined behaviors? Есть наработки по статическому анализу? Если нет — то мы просто не знаем, какие паттерны в D являются склонными к ошибкам, поэтому и в книгах об этом не пишут.
> Судите сами: стандарт только на C занимает около 500 станиц, C++ – около 800, C++11 – около 1300. Если сравнить объем технической документации – этот язык по сложности явно превосходит миксер, швейную машинку и автомобиль, приближаясь скорее к самолётам. Для сравнения, стандарт C# 4.0 занимает всего 505 страниц.
Давайте сделаем честное сравнение. Приложите к спецификации на C# спецификацию на его библиотеки.
Ну вот… Начало хорошее, но дальше Википедии вы не дошли и получился не соответствующий стандарту Unicode велосипед. Почему? Например, потому что вы позволяете кодировать в UTF-8 старшие и младшие суррогаты. Также неправильно обрабатываются overlong sequences и ошибочные последовательности. Эти все вещи должны заменяться на специальный кодпоинт и производиться восстановление после ошибок строго так, как написано в стандарте.
Можете проверять свой декодировщик на тесте: www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
Не используйте qsort(), разве что когда пишете на чистом Си. Используя qsort() вместо std::sort() вы препятствуете инлайнингу и методично отбрасываете всю ту информацию о типах, которая изначально была.
Глупости. Все знают, что при UB ваша программа отсылает боссу письмо с ругательствами.
Qt использует int для размеров и создаёт этим кучу проблем для кода, который в остальных местах использует size_t. По-моему очень спорное решение, не ясно какая была мотивация.
В zero-cost способе в случае исключения у нас будет поиск нужного обработчика по таблицам и это может быть не быстро. Но для установки обработчика не нужно производить сложных действий. Поэтому если исключения нет — то мы за обработчики не платим.
При условии правильной реализации исключений в трансляторе.
На основе таблиц. Погуглите, до меня хорошо расписано в сотнях источников.
> Я бы не стал заносить Intel и TI в эту категорию.
Qualcomm для Hexagon пилят backend (open source!) для llvm. Автоматически получают все самые свежие возможности C++. Они любят своих пользователей.
Существенная деталь: в вашем трансляторе (суть которого — костыль для процессоров, разработчики которых не любят своих пользователей). В большинстве современных трансляторов используются zero-cost exceptions.
Проблема с исключениями для embedded и real-time в том, что очень сложно реализовать throw так, чтобы для вызова соответствующего catch была оценка времени сверху.
Я говорил о другом. Из упомянутых 1300 страниц C++11 больше половины — STL. Сравнивать со спецификацией на C# по объёму нужно ту часть стандарта, которая описывает язык — а их там остаётся как раз около 500.
> Более того, от книги страуструпа у меня остался такой осадок, что примерно 40-50% информации — описание и способы избежания возможных ошибок.
А у D есть спецификация, при составлении которой дотошно рассмотрена каждая возможная комбинация фич языка? Продуманы undefined behaviors? Есть наработки по статическому анализу? Если нет — то мы просто не знаем, какие паттерны в D являются склонными к ошибкам, поэтому и в книгах об этом не пишут.
Давайте сделаем честное сравнение. Приложите к спецификации на C# спецификацию на его библиотеки.
И получите следующую картинку (Going Native 2012, keynote day 2): www.habrastorage.com/images/zzz.png
Рабочая группа WG21 должна объснить, применимо ли это исправление к C++11 или нет. Так что всё ещё может поменяться.
Можете проверять свой декодировщик на тесте:
www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt