У меня своя система оплаты контента: качаю фильм с торрентов, и если он понравился — покупаю в google playstore в пару кликов.
Так что «будущее телетрансляций» заключается в том, что снимать и сочинять треш станет не выгодно.
они бы использовались, если бы деструктор вызывался бы сразу, а не в сборщике мусора.
с Dispose вот только using { } для меня избыточный код, поэтому лучше вообще без него.
В каждых новых версиях Unity меня несколько напрягают баги в ранее работающих системах и фичах (последний ахтунг например был в рендере world canvas в render texture).
Изначально плохая архитектура Unity?
Как с этим дела в UE?
Когда я пробовал MS Azure в бесплатном пробнике, не удавалось открыть входящий порт для теста своего севрера, в поддержке тоже ничем не помогли. Пришлось уйти от них.
Раз уж тема про Tor.
Объясните пожалуйста, почему Tor не даёт сделать exit node на динамическом IP, а только relay ??
В чём вообще проблема exit node на динамическом IP?
В случае static IP для exit node (как сейчас), более защищены оказываются relay, т.к. они коннектятся к статическому exit node. Но зачем защищать relay, если они только пересылают данные между собой.
Логичнее было бы сделать exit node на динамических IP: тогда их количество бы возросло в разы, любая домохозяйка сможет запустить exit node Тор на сотовом интернете. В этом случае понадобились бы relay со static IP, но и тут имеем более охотное жертвование интернета со static IP для relay, т.к. физических выходов в сеть с этих релеев не происходит, а только пересылка между собой.
Если у меня уже отлаженная парадигма классов в сервере, зачем мне добавлять новые классы с непонятным извне поведением, которое приведет к ССЗБ?
Весь этот огород с move semantics, когда однозначно не понятно, в каких случаях класс копируется, а в каких перемещаются кишки, и тогда старая переменная не валидна для использования, потому что внутренний хендл переместили. И что тогда в каждую функцию File добавлять проверку на валидность хендла? Адская избыточность. Зачем эти усложнения?
В той хабра статье уповают только на использование динамической памяти там, где она мол не нужна.
Какие сейчас проблемы с памятью? У меня на сервере свой MM, предвыделенные чанки (расширяются автоматически) от 8 байт до 32кбайт с шагом по экспоненте, в неблокирующем ring buffer'e.
Выделить 8-32кбайт на хендл затрат проц времени для ММ около нуля, зато получаем более управляемый код. Это я имею ввиду использовать хендл в обвязке умного указателя.
Сейчас тенденция везде использовать умные указатели для управляемости и читабельности, и я не понимаю смысла ввода move semantics в виду этой тенденции, чтобы ворочать сырыми указателями в не обвязанных классах, создавая неопределенное поведение классу для пользователя извне, не знакомому с внутренней работой класса.
Простота с STL не увеличивается, когда мультишаблонный тип занимает полэкрана в объявлении переменной.
boost'у это можно простить, потому что они выжали максимум средствами языка, но бюро стандарта сделали эти костыли стандартом.
Предлагают заменять на auto — тогда каждый раз нужно лезть в подсказку и узнавать что это за тип, теряется концепция быстрого чтения кода.
Move semantics прочитал здесь. «гениально», стреляем себе в ногу дальше. Теперь каждый раз нужно лезть в класс, и смотреть, а нет ли у него move semantics внутри, чтобы знать, что этот класс нельзя использовать после копирования foo&.
Объясните мне,
— что теперь каждые 3 года, когда вводят новые фишки в C++, миллионы строк кода готовых оттестированных кодобаз (библиотеки, игровые движки) должны кинуться обновлять свои сорсы под эти фишки, рискнув стабильностью своих продуктов?
так и представляю: миллионы коммитов в древних не тронутых файлах, где меняется самое простое допустим xx::yy::zz::iterator на auto.
— или эти новые фишки задумываются под новые проекты?
но подождите, какие новые проекты, если уже всё изобретено. Пропагандируется же: не изобретай велосипед, бери и пользуйся готовым.
— или предполагается совмещение стилей С++03 с новыми стандартами в одном продукте?
т.е. листаешь ты сорсы, в одном файле xx::yy::zz::iterator, в другом — auto. Очень всё лаконично же и в одном стиле, не код, а загляденье.
Так что «будущее телетрансляций» заключается в том, что снимать и сочинять треш станет не выгодно.
glfw и прочее это прошлый век, никто сейчас не теряет на это время.
с Dispose вот только using { } для меня избыточный код, поэтому лучше вообще без него.
в вашем ареале обитания?
Пытаться это совместить — можно получить выгорание и конец как у Джобса.
Изначально плохая архитектура Unity?
Как с этим дела в UE?
Объясните пожалуйста, почему Tor не даёт сделать exit node на динамическом IP, а только relay ??
В чём вообще проблема exit node на динамическом IP?
В случае static IP для exit node (как сейчас), более защищены оказываются relay, т.к. они коннектятся к статическому exit node. Но зачем защищать relay, если они только пересылают данные между собой.
Логичнее было бы сделать exit node на динамических IP: тогда их количество бы возросло в разы, любая домохозяйка сможет запустить exit node Тор на сотовом интернете. В этом случае понадобились бы relay со static IP, но и тут имеем более охотное жертвование интернета со static IP для relay, т.к. физических выходов в сеть с этих релеев не происходит, а только пересылка между собой.
Или я чего-то не понимаю?
Весь этот огород с move semantics, когда однозначно не понятно, в каких случаях класс копируется, а в каких перемещаются кишки, и тогда старая переменная не валидна для использования, потому что внутренний хендл переместили. И что тогда в каждую функцию File добавлять проверку на валидность хендла? Адская избыточность. Зачем эти усложнения?
В той хабра статье уповают только на использование динамической памяти там, где она мол не нужна.
Какие сейчас проблемы с памятью? У меня на сервере свой MM, предвыделенные чанки (расширяются автоматически) от 8 байт до 32кбайт с шагом по экспоненте, в неблокирующем ring buffer'e.
Выделить 8-32кбайт на хендл затрат проц времени для ММ около нуля, зато получаем более управляемый код. Это я имею ввиду использовать хендл в обвязке умного указателя.
Сейчас тенденция везде использовать умные указатели для управляемости и читабельности, и я не понимаю смысла ввода move semantics в виду этой тенденции, чтобы ворочать сырыми указателями в не обвязанных классах, создавая неопределенное поведение классу для пользователя извне, не знакомому с внутренней работой класса.
boost'у это можно простить, потому что они выжали максимум средствами языка, но бюро стандарта сделали эти костыли стандартом.
Предлагают заменять на auto — тогда каждый раз нужно лезть в подсказку и узнавать что это за тип, теряется концепция быстрого чтения кода.
Move semantics прочитал здесь. «гениально», стреляем себе в ногу дальше. Теперь каждый раз нужно лезть в класс, и смотреть, а нет ли у него move semantics внутри, чтобы знать, что этот класс нельзя использовать после копирования foo&.
— что теперь каждые 3 года, когда вводят новые фишки в C++, миллионы строк кода готовых оттестированных кодобаз (библиотеки, игровые движки) должны кинуться обновлять свои сорсы под эти фишки, рискнув стабильностью своих продуктов?
так и представляю: миллионы коммитов в древних не тронутых файлах, где меняется самое простое допустим xx::yy::zz::iterator на auto.
— или эти новые фишки задумываются под новые проекты?
но подождите, какие новые проекты, если уже всё изобретено. Пропагандируется же: не изобретай велосипед, бери и пользуйся готовым.
— или предполагается совмещение стилей С++03 с новыми стандартами в одном продукте?
т.е. листаешь ты сорсы, в одном файле xx::yy::zz::iterator, в другом — auto. Очень всё лаконично же и в одном стиле, не код, а загляденье.