Как стать автором
Обновить

Комментарии 8

Еще хотелось бы clang увидеть рядом, конечно.
судя по тестам, у меня складывается ощущение, что gcc не подключил (или не использовал) сопроцессор.
по времени компиляции для случая gcc можно попробовать указать системе сборки использовать параллельную компиляцию (make -j8 например), если это возможно.

табличку тяжело изучать, так как в 1/3 случаев для случаев второго места — нет процентажа.
GCC сопроцессор подключил это можно увидеть в листинге ассемблера. В проекте все вложено.
Сборка была из KDS, ничего другого не тестировалось.
Таблица такая уж получилась. Не хотелось еще загромождать цифрами.
Во-первых, в каждой из сред Keil, IAR, GCC будет своя библиотека кучи и не хотелось тратить время на исследование особенностей каждой из них
Какая-то полумера. Нет, обоснование понятное: поставить в равные условия. Но ведь тогда нужно не использовать и libc, всякие libgcc, startfiles (серия опций -nostdlib -nostartfiles у GCC), предоставив единую реализацию. А то правильно, рантайм Kail, IAR заточен на embedded, а GCC всё же копилятор с более широким спектром поддерживаемых платформ. В нашем проекте пришлось выкидывать стандартный рантайм, т.к. весил очень много и писать свою функциональность, минимально-необходимую (по принципу: «что вылезет на линковке»). Сэкономили почти 100кБ (из 300 доступных, C++11). Хотя это и аффектит только последние два пункта. Но всё же. В остальном интересно размышление Elvish в geektimes.ru/post/264558/#comment_8934830. Ровно как и сборка вне IDE.

ЗЫ традиционный риторический вопрос: это же про программирование, это же тематика хабра, не?
Нужна была библиотека работы с heap со способностью регистрировать утечки и расход памяти.
К штатным пришлось бы к каждой писать свою обертку.

Не-не-не, я это как раз понимаю и поддерживаю. Вопрос — почему остальной рантайм не унифицирован?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.