>А прикол в том, что рациональные люди при одних и тех же исходных данных не нуждаются в диалоге, чтобы договориться. Они могут точно предсказать действия друг друга.
Первое что пришло в голову это некое кодирование порядком карт на руках и Little endian vs Big endian проблема записи байт в данных во вполне рациональных спецификациях.
Странно что многие комментирующие воспринимают слово отпуск как синоним отдыха. Отпуск != отдых. Отпуск это просто временный отход от долговременных дел. Существует даже понятие творческий отпуск для таких случаев, как в статье
Может дело в объектном моделировании?
Можно сделать функцию open() не собственным методами сущности File, а фабричным методом (например фабрики FileManager), ответственного за открытие файла. close() можно совместить с деструктором или, если нет деструкторов, то чем-то вроде AutoClousable и try-with-resources в Java. Главное что сам объект файла не сможет существовать в неоткрытом состоянии и становится недоступен после вызова close().
Я, как и многие жители Украины, пользуюсь телефонным номером с авансовой оплатой без привязки к персональным данным потому что он банально дешевле контрактного. Такой номер при желании совсем несложно угнать, но для телефонной связи такой безопасности достаточно, потому что профита от его угона почти никакого. А вот когда номер становится (промежуточным) фактором аутентификации, то угон такого номера уже гораздо опаснее и привлекательнее для злоумышленника.
Библиотека OpenSSL содержит много оптимизаций. Часть из них задается при компиляции, а часть включается на основании определения поддерживаемых инструкций в рантайме
Еще треки стоит ранжировать по темпу, после этого задать мягкое правило выбора трека. Например один трек из каждого двадцатиминутного интервала будет медленным, а остальные быстрые.
Эфир с такими цикличными напряжениями и расслаблениями слушать приятнее
По-моему современные процессоры уже и не предоставляют возможности прямого исполнения программ в машинных кодах, соответственно и ассемблера. Система команд это уже некий уровень абстракции и программа, например на x86 системе команд, потом оптимизируется на аппаратном уровне и в реальности исполняет другую программу.
Все UB не от скудоумия авторов стандарта, а от стремления избежания лишних действий в рантайме.
Хотя можно было бы и разработать несколько подмножеств стандарта и, соответственно, режимов компиляции. Например «легкий» — то что сейчас и «строгий» — рантайм из-за проверок утяжеляется, но UB минимизируются
Собрать свой тулчейн дело не такое уж и хитрое. Но в этом случае нужно либо делать полностью статическую компоновку итогового исполнимого файла, что его сильно раздувает, либо использовать GLIBC и другие базовые зависимости, заведомо настолько старых версий, чтобы быть совместимым со всем ныне живущим. Кроме того некоторые NAS'ы добросовестно делают обновления безопасности. Обновления таких зависимостей как OpenSSL и самой GLIBC (вдруг кто-то из поставщиков привидения испугается и обновит) лучше бы делать независимо от обновления нашей программы, а не статически компоновать.
Как в своё время должен был быть разрушен Карфаген, так сегодня должны умереть все библиотеки и приложения, до сих пор не перешедшие на С++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 далеко не всегда выделяют много дискового места для программ.
Вобщем у программно-аппаратных комплексов время жизни намного больше чем хотелось бы для ускорения чисто программного прогресса. И пока он удовлетворительно выполняет свою основную функцию врядли у кого-то появится интерес обновлять железо ради нового ПО.
Великолепная штука для оценки времени рутинной части работы.
К сожалению так не учтешь сколько времени потрачено на обдумывание способов решения проблемы во время велосипедной прогулки, просто расхоживая по квартире, а так же делая наброски на бумажках или доске
Вообще подход «Текучий интерфейс» как таковой и переход от функций к функциональным объектам это неплохая альтернатива именованным параметрам (Fluent_interface). Да только вот объявление всего этого гораздо многословнее выходит
Первое что пришло в голову это некое кодирование порядком карт на руках и Little endian vs Big endian проблема записи байт в данных во вполне рациональных спецификациях.
«для компутеров» естественнее бинарный формат, а тут человекочитаемый текст «для человеков»
Можно сделать функцию open() не собственным методами сущности File, а фабричным методом (например фабрики FileManager), ответственного за открытие файла. close() можно совместить с деструктором или, если нет деструкторов, то чем-то вроде AutoClousable и try-with-resources в Java. Главное что сам объект файла не сможет существовать в неоткрытом состоянии и становится недоступен после вызова close().
Эфир с такими цикличными напряжениями и расслаблениями слушать приятнее
Хотя можно было бы и разработать несколько подмножеств стандарта и, соответственно, режимов компиляции. Например «легкий» — то что сейчас и «строгий» — рантайм из-за проверок утяжеляется, но UB минимизируются
Если бы все было так просто, как хотелось. Я поддерживаю клиентскую часть проекта облачного диска, который хранит файлы на Amazon S3 на С++. Основное предназначение это резервное копирование данных с NAS. Поддерживать нужно работу на устройствах около 10 поставщиков. В номенклатуре каждого 1-3 разных аппаратных архитектуры и каждый предоставляет кросс-тулчейн с GCC для сборки. Всего около 20 тулчейнов. Большая часть предоставляет GCC 4.2-4.7, т.е. С++ 98. Да что там говорить — на некоторых Linux операционках устройств ядро более-менее новое, а GLIBC настолько старая, что мне приходится компилировать со самописаным заголовочным файлом для Inotify и прямыми обращениями к сисиемным вызовам, т.к. GLIBC его не знает.
Да. Я могу скомпилировать новый GCC для каждого тулчена для перехода на С++11, но также потребуется распространять и C++ рантайм вместе с программой. Это будет еще больше раздувать дистрибутив, а на NAS далеко не всегда выделяют много дискового места для программ.
Вобщем у программно-аппаратных комплексов время жизни намного больше чем хотелось бы для ускорения чисто программного прогресса. И пока он удовлетворительно выполняет свою основную функцию врядли у кого-то появится интерес обновлять железо ради нового ПО.
К сожалению так не учтешь сколько времени потрачено на обдумывание способов решения проблемы во время велосипедной прогулки, просто расхоживая по квартире, а так же делая наброски на бумажках или доске