Комментарии 11
Честно говоря, смущает скрещивание быстрого C++ и медленного облака.
Если вы делаете что-то критичное к производительности, то обычно это уж совсем системные вещи, а если нет, то зачем использовать C++ в тех местах, для которых он не предназначен?
Если вы делаете что-то критичное к производительности, то обычно это уж совсем системные вещи, а если нет, то зачем использовать C++ в тех местах, для которых он не предназначен?
Есть большая программа на С++, которой понадобилась функция "сохранить в облако". Нанимать программистов на других языках программирования? Или следить, чтобы в штате хоть кто-то знал этот другой ЯП? Писать интерфейсы в другой ЯП/библиотеку? Зачем такие сложности ради 20 строк кода на С++?
- Игра на мобильном приложении (сама на С++ ради производительности, использует облако как сервис хранения данных).
- Приложения на С++, которые и так уже работают на амазоновских серверах и им нужно общаться между собой или с инфраструктурой Амазона.
- Платформы, где кроме как на С++ писать сложно (какой-нибудь мини-датчик в умном доме, который хочет репортить статус на Амазон).
С++ прекрасно подходит и для "медленных" облаков. Что статья наглядно и продемонстрировала. Ну и да — это же SDK, тоесть библиотека, реализующая некоторый интерфейс взаимодействия. И выбирают язык SDK исходя из того, на каком языке написано приложение. Amazon свое SDK предоставляет не только на C++
Как в своё время должен был быть разрушен Карфаген, так сегодня должны умереть все библиотеки и приложения, до сих пор не перешедшие на С++11. Им просто не место в современном мире. Со слезами на глазах я читаю посты вроде этого о библиотеках, которые «чтобы расширить аудиторию — стараются обходиться без C++11».
Если бы все было так просто, как хотелось. Я поддерживаю клиентскую часть проекта облачного диска, который хранит файлы на Amazon S3 на С++. Основное предназначение это резервное копирование данных с NAS. Поддерживать нужно работу на устройствах около 10 поставщиков. В номенклатуре каждого 1-3 разных аппаратных архитектуры и каждый предоставляет кросс-тулчейн с GCC для сборки. Всего около 20 тулчейнов. Большая часть предоставляет GCC 4.2-4.7, т.е. С++ 98. Да что там говорить — на некоторых Linux операционках устройств ядро более-менее новое, а GLIBC настолько старая, что мне приходится компилировать со самописаным заголовочным файлом для Inotify и прямыми обращениями к сисиемным вызовам, т.к. GLIBC его не знает.
Да. Я могу скомпилировать новый GCC для каждого тулчена для перехода на С++11, но также потребуется распространять и C++ рантайм вместе с программой. Это будет еще больше раздувать дистрибутив, а на NAS далеко не всегда выделяют много дискового места для программ.
Вобщем у программно-аппаратных комплексов время жизни намного больше чем хотелось бы для ускорения чисто программного прогресса. И пока он удовлетворительно выполняет свою основную функцию врядли у кого-то появится интерес обновлять железо ради нового ПО.
Понимаю весь геморрой с NAS'ами и их тулчейнами. Все больше и больше склоняюсь к сборке своего тулчейна. Таким путем пошли в Symform, там собрали свой тулчейн, и своим тулченом собрали Mono.
Со своим тулчейном можно ограничится x86-64(пока еще не было потребности в x86), ARMv5, PowerPC
Со своим тулчейном можно ограничится x86-64(пока еще не было потребности в x86), ARMv5, PowerPC
Собрать свой тулчейн дело не такое уж и хитрое. Но в этом случае нужно либо делать полностью статическую компоновку итогового исполнимого файла, что его сильно раздувает, либо использовать GLIBC и другие базовые зависимости, заведомо настолько старых версий, чтобы быть совместимым со всем ныне живущим. Кроме того некоторые NAS'ы добросовестно делают обновления безопасности. Обновления таких зависимостей как OpenSSL и самой GLIBC (вдруг кто-то из поставщиков привидения испугается и обновит) лучше бы делать независимо от обновления нашей программы, а не статически компоновать.
Я в курсе этого геморроя. Для устройств QNAP у меня нет статической компоновки и я кладу весь необходимый runtime. В итоге не сильно и раздуто получилось. При этому смотрю на производителей стороннего софта для NAS, люди просто кладут все необходимое. Некоторые тащат свой Perl/Python и не парятся. Ограничение на размер всегда можно обойти выкачиванием бинарей при установке, как например сделали ребята из Symform. Их пакет мало весит, но при установке выкачивает все из сети.
НЛО прилетело и опубликовало эту надпись здесь
Ну вот и скажите мне, любители выражений вроде «С++ слишком сложен и избыточен» — чем это хуже Java или Python?Необходимостью вручную управлять использованием памяти на свой страх и риск?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
C++ SDK для Amazon Web Services