LINUX.ORG.RU

Обзор инструментов для C/C++, поставляемых с FreeBSD

 , ,


1

0

Оригинал статьи на форониксе, ниже — вольный перевод.

На прошедшем в минувшие выходные FOSDEM в аудитории, посвящённой BSD, David Chisnall дал оценку поддержки стандартов C11 и C++11 во FreeBSD. Большая часть работ над поддержкой последних стандартов ведётся разработчиками компиляторов, а проект FreeBSD ищёт удачное применение улучшениям и новым возможностям.

Для тех, кто не следит за стандартами ISO, сделаем краткий обзор новых возможностей C11 (некоторые расширения сделаны опциональными из-за плохой поддержки C99 в компиляторе Microsoft):

  • static assert
  • стандартизированная поддержка многопоточности (_Thread_local и _Atomic, <threads.h> и <stdatomic.h>)
  • стандартизированная поддержка юникода (<uchar.h>)
  • выравнивание данных (спецификатор _Alignas, оператор alignof, функция aligned_alloc и <stdalign.h>)
  • косметические улучшения, такие как типизация в макросах с помощью _Generic

В свою очередь C++11 предоставляет:

  • static assert
  • стандартизированные умные указатели
  • потоки, атомарные переменные и TLS (хранилище переменных, видимых только в пределах потока).
  • улучшенную поддержку локалей
  • множество косметических и иных изменений

В данный момент проект FreeBSD поставляет GCC версии 4.2.1 (последняя версия, не перелицензированная под GPLv3) и объявил об отказе от него в будущем, поэтому статус поддержки C++11 в GCC в данном случае не имеет значения. LLVM/Clang, используемый во FreeBSD как системный компилятор, уже начал реализацию обоих стандартов (см. таблицу состояния C++11 в различных компиляторах). Clang в целом заменил GCC, оставшиеся доработки будут сделаны достаточно скоро. В качестве стандартной библиотеки используется libc++ (и libcxxrt), которая также является частью LLVM. Кроме того, есть некоторые специфичные для FreeBSD вещи

Файл sys/cdefs.h абстрагирует прежние расширения GNU, теперь ставшие частью C11. Также он:

  • воспроизводит имена C11, но не заменяет имена, если они предоставленны компилятором
  • может быть использован прямо сейчас для любого диалекта C/C++
  • используется остальными заголовочными файлами FreeBSD

Многопоточность в C11/C++11:

  • стандартный API управления потоками реализован для C++, но не для C
  • атомарные операции готовы (и в компиляторе, и в стандартной библиотеке)
  • TLS реализовано для C через ключевое слово __thread, в C++ проблемой остаются типы с нетривиальными конструктором/деструктором
  • _Noreturn готов
  • сохранение исключений в переменные (с возможностью передачи в другой поток) — готово, часть стандартной библиотеки.

Также к незавершённым вещам можно отнести поддержку юникода (<uchar.h> для C и <uchar> для C++) и даже некоторые функции <math.h> из C99. К завершённым — улучшения локалей из C++11 и POSIX 2008.

>>> Подробности

★★★★

Проверено: anonymous_incognito ()
Последнее исправление: quiet_readonly (всего исправлений: 3)

Ответ на: комментарий от Sharezil

Поведаете же нам, о просветлённый - как работает «функция cout»?

anonymous
()
Ответ на: комментарий от niXman

есть все еще конторы, в которых программисты компиляют код в рабочее время?

O_o

Да, еще есть такие.

tailgunner ★★★★★
()
Ответ на: комментарий от niXman

или есть все еще конторы, в которых программисты компиляют код в рабочее время?

Конечно, не все же пишут на современном бейсике с отступами.

Reset ★★★★★
()
Ответ на: комментарий от niXman

никогда не понимал тех, кто говорит о скорости компиляции. или есть все еще конторы, в которых программисты компиляют код в рабочее время?

А когда его прикажете компилировать? в выходные?

mono ★★★★★
()
Ответ на: комментарий от Sharezil

В плюсовых проектах, которые начинались 20 лет назад до stl существует по 100500 классов строк и подобных дублирующихся велосипедов, поэтому включение стандартных вещей в стандартую библиотеку это хорошо. Но если ты внимательно почитаешь изменения, то увидишь, что расширяется не только библиотека.

Reset ★★★★★
()
Ответ на: комментарий от annulen

В clang же это есть, precompiled preamble называется

Большое. Человеческое. Спасибо.

yurkis
()
Ответ на: комментарий от Sharezil

читани Айзик Азимов Чуство силы (20 мин) - и продолжиш .

qulinxao ★★☆
()
Ответ на: комментарий от anonymous

Ты идиот, или просто тупица?

тебе виднее.

надо парсить

я говорил о парсе? это первое. второе - компиляция и разбор - как теплое и мягкое.

думаю, очевидно, кто идиот/тупица.

niXman ★★★
()
Ответ на: комментарий от anonymous

одна из причин создния языка Go - это то, что у гугла много кода на C++ и компилится это дело долго.

это ложь. и/или маркетинговый ход. я-то знаю.

niXman ★★★
()
Ответ на: комментарий от seg-fault

Есть конторы где кода _много_ :)

не знал, что есть конторы, в которых проекты разрабатываются как монолитные «куски». но, судя по остальным комментариям, таких контор все же большинство %) и, что-то мне подсказывает, что такое может происходить в конторах, размещаемых на пост-советских территориях =)

niXman ★★★
()
Последнее исправление: niXman (всего исправлений: 1)
Ответ на: комментарий от qulinxao

т.е тебе не понятно , почему гуглу оказалось полезно запиливать для себя GO . ok.

очевидно для задач, где «проседание» в 8-10 раз по скорости не критично, т.е. это хорошая замена популярным скриптовым ЯП, которые не в меру переусложнены и медлительны

П.С. а сам ЯП скорее всего запилили Just for fun

wota ★★
()
Ответ на: комментарий от Reset

конторы, в которых программисты компиляют код в рабочее время?

Конечно, не все же пишут на современном бейсике с отступами.

Если что, этот «современный бейсик» тоже компилируемый.

tailgunner ★★★★★
()
Ответ на: комментарий от niXman

я говорил о парсе? это первое. второе - компиляция и разбор - как теплое и мягкое.

Вмешаюсь и скажу, что я говорил о парсинге. С IDE и C++ ситуация чем-то напоминает претензии к анимациям (=свистелкам), из-за которых, мол, всё тормозит.

В идеале IDE должна разбирать код с точностью компилятора, и на этой задаче стоковый clang тормозит (2-5 секунд на среднем файле в проекте openmw). Пауза, незаметная для пользователя - это 0.1 - 0.2 секунды, и встроенный парсер QtCreator/KDevelop в это время укладывается, тогда как clang очень быстро садится из-за препроцессора, который разворачивает файл из 1.000 строк в файл из 100.000 строк. Если кратко: тормоза = препроцессор * (шаблоны + куча объявлений).

С анимациями в ВМах та же ситуация - их появление выявило кучу узких мест, из-за которых композитинг при тех или иных условиях начинает тормозить независимо от усилий авторов ВМ. Также вангую сложности с профилированием, по разным причинам.

К сожалению, типичным ответом на

  • вопрос по избавлению анимированного композитинга от тормозов будет «не используйте анимации».
  • вопрос по борьбе с тормозами анализа C++ будет «плюсы убогие, юзайте C», хотя препроцессор пришёл как раз из C
  • предложение внести модули в стандарт будет «извините, некоторым майкрософтам итак много нового сделать придётся, давайте лучше ещё увеличим размер шаблонов
quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от quiet_readonly

Вмешаюсь и скажу, что я говорил о парсинге.

Для C++ даже сам по себе парсинг невозможен без семантического анализа. А это уже добрая половина компиляции получается.

хотя препроцессор пришёл как раз из C

С C++ как правило теплейты источник тормозни, а не препроцессор. Интерпретатор темплейтов во всех современных реализациях очень тормозной и глупый. До компиляции темплейтов они пока не додумались, и еще не скоро додумаются.

anonymous
()
Ответ на: комментарий от tailgunner

В любом. *.pyc - это результат компиляции. PyPy - это JIT в машинный код.

Там слишком много вещей определяется в рантайме, включая наличие метода с данным именем у объекта. Хотя в имени, вообще-то, очень легко опечататься.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от anonymous

С C++ как правило теплейты источник тормозни, а не препроцессор. Интерпретатор темплейтов во всех современных реализациях очень тормозной и глупый. До компиляции темплейтов они пока не додумались, и еще не скоро додумаются.

Ещё раз, тормоза = препроцессор * (шаблоны + куча объявлений). И препроцессор как-то менее важен, в реальном коде он используется для #ifdef и очень редко, да и не во всех проектах - для устранения повторений кода.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от quiet_readonly

Там слишком много вещей определяется в рантайме, включая наличие метода с данным именем у объекта.

Ну да. Но это не мешает Python имет в своем составе компилятор.

tailgunner ★★★★★
()
Ответ на: комментарий от quiet_readonly

в реальном коде он используется для #ifdef и очень редко

Глянь хотя бы то, во что разворачивается BOOST_FOREACH и за сколько шагов препроцессора.

kamre ★★★
()
Ответ на: комментарий от tailgunner

Тогда вопрос к вам, как к опытному питонисту: насколько легко использовать питон для создания разделяемой библиотеки или исполняемого файла, при условии что готовых биндингов к коду на C++ нет и прокинуть их надо будет самостоятельно?

В общем-то можно попробовать использовать и libpython, но не знаю, возможно ли избежать всех задержек больше 10 мс, в частности не парсить вызываемыйй из C++ скрипт перед каждым вызовом.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от quiet_readonly

насколько легко использовать питон для создания разделяемой библиотеки или исполняемого файла

Имеется в виду автономный бинарь? Можно создать бинарь интерпретатора с привязанными к ниму библиотеками байткода (а-ля древний FoxPro), но, наверное, это не то, что тебе надо. Про разделяемую библиотеку не понял - ты хочешь сделать ее на чистом Python? AFAIK, это невозможно. Обертку написать можно, но трудоемко. Известные мне интеграции Python-программ делаются через CLI или сетевой протокол (или что-то такое: http://mercurial.selenic.com/wiki/CommandServer).

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от mr_doug
% pkg_info -R boost-libs-1.52.0_1
Information for boost-libs-1.52.0_1:

Required by:
gnash-0.8.10_4
iZEN ★★★★★
()
Ответ на: комментарий от quiet_readonly

Ещё раз, тормоза = препроцессор * (шаблоны + куча объявлений)

А почему умножение? Препроцессор выполняется до всего остального, и по большому счёту ему глубоко фиолетово, что внутри: шаблоны, классы, функции, спагетти.

sjinks ★★★
()
Ответ на: комментарий от sjinks

А почему умножение? Препроцессор выполняется до всего остального, и по большому счёту ему глубоко фиолетово, что внутри: шаблоны, классы, функции, спагетти.

В языках без препроцессора при парсинге используется закешированная таблица импорта, так что увеличение деклараций в два раза вызовет увеличение таблиц в ~2 раза, но почти не скажется на скорости парсера.

Препроцессор заставляет заново распарсить и проанализировать значительную часть деклараций (в предкомпилированный заголовок не всё удастся запихнуть), так что и скорость парсера падает в 2 раза. Да и таблицы импорта по размеру выйдут куда меньше, чем полный контекст препроцессора и парсера + AST, как в предкомпилированном заголовке.

Иначе говоря, увеличение размера всего кода в n раз вызовет замедление в ~n раз для языков с импортом и в ~n^2 раз для языков с препроцессором.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от niXman

никогда не понимал тех, кто говорит о скорости компиляции. или есть все еще конторы, в которых программисты компиляют код в рабочее время?

ну например у меня сборка с нуля всего барахла, написанного конторой самостоятельно или натыренного из BSD проектов, занимает 1-2 часа, в зависимости от ОС и процессора

Harald ★★★★★
()
Ответ на: комментарий от quiet_readonly

Пауза, незаметная для пользователя

а откуда возникает вопрос про паузы? ведь у вас там разбор в отдельном потоке ведется, правда?

anonymous
()
Ответ на: комментарий от Reset

Всё, что сейчас происходит с C++ называется раздуванием до максимальных размерах, единственное полезное, что я увидел в последних его изменениях - включения стандарта потоков и не более. Осталось только включить поддержку по-умолчанию X сервера и звуковых драйверов, чтобы в конец C++ превратился в java.

Sharezil
()
Ответ на: комментарий от niXman

не знал, что есть конторы, в которых проекты разрабатываются как монолитные «куски». но, судя по остальным комментариям, таких контор все же большинство %) и, что-то мне подсказывает, что такое может происходить в конторах, размещаемых на пост-советских территориях =)

ЛЮБОЙ проект, включающий в себя тяжелые темплейты будут билдится долго. Плюс даже побитый на либы проект нужно линковать. Плюс в почти в каждую такую либу в течении дня делается по пару комитов. Плюс кто- то иногда комитит в общие заголовочные файлы (например поменять тип данных, интерфейс). Я сейчас описал вполне себе рядовой процесс создания ПО на С++. Если знаете как не компилировать (или почти не компилировать) сложный проект на плюсах- напишите.

PS Только не надо писать про выделенную билд машинку. Она обычно не для того.

yurkis
()
Ответ на: комментарий от anonymous

а откуда возникает вопрос про паузы? ведь у вас там разбор в отдельном потоке ведется, правда?

В отдельном потоке, более того, после ввода точки можно продолжать набирать имя (метода или поля), парсинг будет отменён только при наборе символа вроде ; или (, который не может встретиться в результатах автодополнения.

С учётом асинхронности удобная пауза 0.1 - 0.2 секунды, без асинхронности я бы вовсе завысил свои хотелки до 1-10 мс.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от yurkis

я говорил о том, что программисты пишущие код, его не компилят на рабочей машине. и очень редко, они вообще что-либо компилят. но, похоже, большинство контор, эту модель разработки так и не внедрило. от чего, страшно представить, сколь низкая производительность разработки в подобных конторах %)

niXman ★★★
()
Ответ на: комментарий от quiet_readonly

вообще ничего не понял.

код начинает парситься что ли только тогда, когда требуется автодополнение?

чем тогда ide занимается в оставшееся время?

anonymous
()
Ответ на: комментарий от quiet_readonly

В идеале IDE должна разбирать код с точностью компилятора, и на этой задаче стоковый clang тормозит (2-5 секунд на среднем файле в проекте openmw).

а в Xcode проверял? у меня с ним проблем с тормозами нет - и это в виртуалке, т.е. как минимум они умеют грамотно скрыть эти тормоза предварительными индексированиями

wota ★★
()
Последнее исправление: wota (всего исправлений: 1)
Ответ на: комментарий от quiet_readonly

В языках без препроцессора при парсинге используется закешированная таблица импорта

объясни о чем речь, или дай пруф. а то уж больно похоже на бред.

Препроцессор заставляет заново

«заново», после чего? из-за чего?

(в предкомпилированный заголовок не всё удастся запихнуть)

во-первых - PCH дает прирост ~2%. так что смысла вообще нет. во-вторых - приведи пример ситуации ,когда хоть что-то не может попасть в PCH.

таблицы импорта по размеру выйдут куда меньше

что в данном контексте означает «таблицы импорта»? и как их наличие исключает AST?

niXman ★★★
()
Ответ на: комментарий от niXman

Альтернатива? Выделенная билд машинка с заливкой через vcs? И что значит «и очень редко, они вообще что-либо компилят»?

yurkis
()
Ответ на: комментарий от yurkis

Альтернатива? Выделенная билд машинка с заливкой через vcs?

более того, этим занимается вообще отдельный отдел. кодеры-реализаторы пишут реализацию и тесты. но не компиляют код. синтаксические и другие машинные ошибки правятся в отделе сборок и тестирования. реализатору, его код может вернуться только в том случае, если его реализация нереально бажит, или вообще выполняет не то, что должна =)

я говорю о своем опыте работы в кодопроизводственных зарубежных крупных кампаниях. а там время/деньги считать умеют ;)

niXman ★★★
()
Ответ на: комментарий от anonymous

В clang автодополнение делается путём повторного парсинга.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от wota

а в Xcode проверял? у меня с ним проблем с тормозами нет - и это в виртуалке, т.е. как минимум они умеют грамотно скрыть эти тормоза предварительными индексированиями

Я в XCode не гонял проекты с такими тяжёлыми заголовками, да и pch там по дефолту создаётся. В коде QtCreator автодополнение занимает 0.3 - 0.5 секунд, без pch.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от niXman

Ok. Пусть у нас есть выделенный билд менеджер. Пусть даже выделенная команда сборщиков. Но свой код тоже как- то дебажить надо. Да и не могут программисты (по крайней мере те что обеспечивают базовую функциональность приложения) комитить малыми безбажными кусками.

Описанный Вами случай- скорее типичен для отечественно (Украинского, по крайней мере) аутсорса когда команда пилит пофиксы одним глазом смотря в код, другим- в джиру. То есть: вот вам cosmetic bug, вот от вас комит на 5 строк и смена статуса в джире.

Я имел счастье поработать и так и эдак. И в чисто продуктовой компании (т.е. там где вся архитектура своя и вообще своя багодельня и проект новый) гораздо проще купить девелоперам по Core I7 3700K с SSD. А билд машинку иметь чисто для подстраховки и артефактов ради. Да, есть билд менеджер. Но он ответственен только за билд инфраструктуру и за артефакты которые идут наружу. Потому как часто на старте проекта и вплоть до feature freeze оперативность внесения изменений (и подчас масштабных) и оперативность проверки и интеграции этих изменений вполне себе решает. Тут, конечно distcc/incredibuild помогают. Но это не совсем то что Вы предлагаете. А вот в случае с legacy кодом, Ваш подход вполне себе.

yurkis
()
Ответ на: комментарий от niXman

во-первых - PCH дает прирост ~2%. так что смысла вообще нет. во-вторых - приведи пример ситуации ,когда хоть что-то не может попасть в PCH.

PCH обычно один на папку, другие файлы из папки не попадут в PCH. Кроме того, PCH хранит весь контекст, необходимый для восстановления состояния парсера/препроцессора, и AST (часть семантических проверок этого AST придётся делать заново). Это несколько отвращает от включения всего подряд.

что в данном контексте означает «таблицы импорта»? и как их наличие исключает AST?

IDE видит, что есть объект os с пачкой методов и типом «модуль». Она не парсит заново код методов и не собирает объект из AST, а использует всё заранее вычисленное. Т.е. если вначале файла написано import os, то результат разбора модуля os от содержимого текущего файла не зависит.

В случае C++ это не так

// formats.inl
FORMAT(PNG, "png", "--enable-png"),
FORMAT(JPEG, "jpg", "--enable-jpeg"),
FORMAT(TGA, "tga", "--enable-tga"),

// formats.h
#define FORMAT(a, b, c) a
enum Format {
#include "formats.inl"
};
#undef FORMAT

#define FORMAT(a, b, c) b
const char *spelling[] = {
#include "formats.inl"
};
#undef FORMAT

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 2)
Ответ на: комментарий от yurkis

свой код тоже как- то дебажить надо.

нет, реализатор не дебажит код. этим занимается отдел, идущий после отдела реализаторов, т.е. отдел тестирования/сборок.

не могут программисты (по крайней мере те что обеспечивают базовую функциональность приложения) комитить малыми безбажными кусками.

очень даже могут, малыми кусками. касательно багов - да, бывает. если любопытно, погуглите про то, как писалось ПО для марсохода куриоусити. штрафы сильно стимулируют писать качественный код. и это не издевательство над кодерами, это суровая необходимость которую я полностью поддерживаю.

niXman ★★★
()
Ответ на: комментарий от niXman

Твой опыт - говно, и работал ты в быдлоконторках-соковыжималках.

Microsoft, Intel, IBM и прочие подобные работают совсем не так. Ну да тебе, быдлокодеру, никогда не светит даже узнать, как пишут код в серьезных компаниях.

anonymous
()
Ответ на: комментарий от niXman

нет, реализатор не дебажит код. этим занимается отдел, идущий после отдела реализаторов, т.е. отдел тестирования/сборок.

Ну я и говорю - ты ничтожество и быдлокодер. Небось всякое CRUD-говно херачишь, да?

Посмотрел бы я на разработчиков, например, Visual Studio, которые «не дебажат код».

anonymous
()
Ответ на: комментарий от niXman

кодеры-реализаторы пишут реализацию и тесты. но не компиляют код

Вслепую пишут в vim/emacs, код проверяется не компилятором а только в голове «кодера-реализатора»? А за ошибки компиляции при коммите в vcs к нему приходят и бьют розгами, чтобы не повадно было?

Какие-то не реально жесткие условия для разработки. То ли дело на Java, когда все компилируется инкрементально при сохранении файлов и сразу готово к запуску/отладке, можно еще и тесты успеть прогнать пока там плюсовый код с boost собирается. Чем быстрее цикл edit/compile/test тем удобнее разработка.

kamre ★★★
()
Ответ на: комментарий от niXman

очень даже могут, малыми кусками. касательно багов - да, бывает. если любопытно, погуглите про то, как писалось ПО для марсохода куриоусити. штрафы сильно стимулируют писать качественный код. и это не издевательство над кодерами, это суровая необходимость которую я полностью поддерживаю.

Мы сайчас об общем случае говорим а не об экзотике.

я говорю о своем опыте работы в кодопроизводственных зарубежных крупных кампаниях. а там время/деньги считать умеют ;)

Или Вы писали код для марсохода?

нет, реализатор не дебажит код. этим занимается отдел, идущий после отдела реализаторов, т.е. отдел тестирования/сборок.

Повторю: В общем случае до полного feature freeze необходимость оперативности внесения изменений превалирует и практически исключает предложенную Вами модель. И, кстате, гм... стимулирование кодеров это вобще отдельный разговор.

yurkis
()
Ответ на: комментарий от kamre

Вслепую пишут в vim/emacs, код проверяется не компилятором а только в голове «кодера-реализатора»? А за ошибки компиляции при коммите в vcs к нему приходят и бьют розгами, чтобы не повадно было?

ИМХО для Индии вполне себе работоспособно могло бы быть....

yurkis
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.