В 2016 году Google полностью отказались от поддержки GCC в Android NDK из-за слишком плохой поддержки стандартов и слишком свободного следования стандартам C++. В этот момент GCC стал неконкурентоспособным относительно оставшихся двух самых широко используемых трансляторов.
Clang же, наоборот, сегодня считается, буквально, бастионом идеального следования стандартам C++. Clang точно поддерживает стандарты во всех деталях, максимально быстро интегрирует изменения и добавления стандартов, позволяет в самых первых рядах поиграться с функциональностью из драфтов следующего стандарта C++.
Clang обладает обширной системой статической и динамической проверки кода: богатый статический анализ, возможность подключения санитайзеров, поддержка C++ Core Guidelines, очень качественные отчеты об ошибках трансляции, хорошая скорость трансляции.
GCC дополнительными опциями то же можно заставить строже относиться к стандартам. Так что не вижу тут большой разницы, конечно могут быть нюансы в разных местах и разные трактовки тонких мест стандарта.Полагаю, гугл выкинул gcc не из-за того, что не смог разобраться в парочке опций компилятора.
такой контейнер я могу создать разными способами на основе разных образов, но вот добиться следов выполнения заданий по cron - я никак не могу. Cron вроде как оказывается запущенным, но ожидаемых результатов от работы - нет :(Хотелось бы увидеть что конкретно вы уже пробовали сделать. Приведите пример Dockerfile и docker-compose.yml, с вашими экспериментами с кроном.
security:
authorization: enableddb.updateUser(
"graylog",
{
authenticationRestrictions: [
{
clientSource: ["10.223.223.223", "10.223.223.224"]
}
]
}
)
pavel_the_man, я видел много rest api, где параметрами можно влиять на вывод. Добавляешь в запрос, условно,
extended_info=1и получаешь чуть более подробный ответ. Или при генерации какого-либо отчёта передаешь список интересующих полей и отчёт содержит только их. Концептуально то же самое, только graphql более гибкий.А так есть какой-то "максимальный" объект, который может вернуть хоть rest api, хоть graphql, и есть возможность его фильтровать входящими параметрами. И вот этот объект - он не обязан повторять структуру какой-либо таблицы а базе. Может даже вообще никакой связи с базой не иметь.
Хотя никто не мешает мапить поля в базе на api ответ один к одному, но это плохая практика, так как жизненный цикл базы и api различен.
База может и будет эволюционировать, менять свою структуру по мере развития проекта.
А вот api должно быть стабильным. Клиентам вряд ли понравится каждый раз переделывать интергацию с вашим api каждый раз как на вашу базу будет накачена миграция.