Comments 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. Их пакет мало весит, но при установке выкачивает все из сети.
UFO just landed and posted this here
Ну вот и скажите мне, любители выражений вроде «С++ слишком сложен и избыточен» — чем это хуже Java или Python?Необходимостью вручную управлять использованием памяти на свой страх и риск?
Sign up to leave a comment.
C++ SDK для Amazon Web Services