Этот путь ведет в никуда — вам не удастся «убедить» меня, что в Стандарте есть что-то, что там явно не написано. Да, «вроде бы» «по логике вещей» «должно быть вот так», но тем не менее — «ссылка на явное утверждение в Стандарте, или этого не было».
Еще раз посмотрел на планировку. Если общая площадь 5 тысяч квадратных метров, два одинаковых этажа один под другим, длина здания примерно вдвое превышает ширину, все равно длина кабеля от подстанции до потребителей не должна превышать двухсот метров, и это еще с запасом. Если у вас при этом потери около трех процентов, то в менее компактных сетях они должны быть значительно больше.
Насколько хорошим считается показатель в три процента? Это потери на нагрев проводов или есть какие-то еще компоненты?
Энергия напрямую от генератора (ТЭЦ-11) по двум независимым кабельным линиям
Это следует понимать как две независимые линии, обе из которых присоединены к распределительному устройству одной и той же ТЭЦ? Тогда они не такие уж и независимые.
Вы добавили квалификатор volatile не указателю на данные, а данным, на который указывает указатель.
Не самим данным (переменной), а l-value. Поменять объявление переменной невозможно, а именно наличие квалификатора volatile у самой переменной определяет, является ли она «volatile data», изменение которых относится к наблюдаемому поведению.
Даже если я неверно трактую Стандарт, то я его трактую слишком строго, а не слишком вольно, потому что я утверждаю отсутствие гарантии.
Применительно к обязательности перезаписи данных — Стандарт не дает никаких гарантий ни в одном из перечисленных случаев, потому что сам массив не имеет квалификатора volatile. Плюс в примерах с указателями у вас неопределенное поведение, потому что нельзя инициализировать указатель значением неинициализированного указателя.
А можно цитату из стандарта, где говорится о том, что volatile-ссылка на объект не гарантирует volatile-поведение?
В Стандарте именно такого требования нет, но из этого ровно ничего не следует. Например, в Стандарте не требуется, чтобы запись через неинициализированный указатель приводила к AV (или segmentation fault — кому как нравится).
Предположим, на начальном этапе вы убедились, что каналы действительно везде лежат в разных коллекторах. Вдруг этот самый экскаватор или какое-то другое происшествие серьезно повреждают один из каналов, оператор при восстановлении канала не может использовать старый маршрут (потому что там нужны длительные восстановительные работы) и укладывает небольшой участок канала по маршруту, который совпадает с другим каналом другого оператора. Кто и как это заметит?
Оптические каналы полностью дублированы, причем они прокладываются по разным маршрутам и разными операторами.
Как практически добиться, чтобы ни один погонный метр этих разных каналов разных операторов точно не оказался в одном и том же коллекторе и соответственно не сгорел одновременно при пожаре в этом коллекторе?
С сегодняшнего производится еще одно важное и долгожданное нововведение в то, как оплачиваются используемые виртуальные машины. Теперь плата за остановленную виртуальную машину не взымается.
Как я понимаю, этот пост основан на вот этом посте в блоге Windows Azure от 3 июня. Там явно упоминаются только виртуальные машины, но не cloud services. Портал управления даже сейчас предупреждает, что за остановленный deployment придется платить.
Пользователи начинали строить ассоциации, сопоставляя человечка с живыми людьми — родственниками и знакомыми, а после не могли понять, что образ этого человека делает на карте веб-сервиса.
Странно, вроде все «очень заняты», но почему-то находят мыслительные ресурсы на ассоциирование схематичного человечка с реальными людьми и потом еще попытки понять, что он делает на карте.
Как раз тогда auto обозначало, что переменная автоматическая (а раз тип не указан, то используется тип int), потом оно в этом значении перекочевало в C++, а уже потом в C++11 решили его использовать для других целей. Так что это просто совпадение.
Посыл статьи предельно простой: есть такой риск, заранее принять меры очень легко и вы сами выбираете — принять меры заранее или надеяться на поставщика сервиса. Это не непредвиденная ситуация, потому что все нужные данные постоянно на виду.
Вы так спрашиваете, как будто последнее утверждение всем очевидно. Обратите внимание, что истечения срока действия сертификатов Azure Storage в феврале можно было ожидать заранее, но тем не менее никто из пользователей ничего не заметил до момента, когда стало слишком поздно.
Насколько хорошим считается показатель в три процента? Это потери на нагрев проводов или есть какие-то еще компоненты?
Это следует понимать как две независимые линии, обе из которых присоединены к распределительному устройству одной и той же ТЭЦ? Тогда они не такие уж и независимые.
volatile T *ptr = new volatile T;Не самим данным (переменной), а l-value. Поменять объявление переменной невозможно, а именно наличие квалификатора volatile у самой переменной определяет, является ли она «volatile data», изменение которых относится к наблюдаемому поведению.
Даже если я неверно трактую Стандарт, то я его трактую слишком строго, а не слишком вольно, потому что я утверждаю отсутствие гарантии.
Как я понимаю, этот пост основан на вот этом посте в блоге Windows Azure от 3 июня. Там явно упоминаются только виртуальные машины, но не cloud services. Портал управления даже сейчас предупреждает, что за остановленный deployment придется платить.
Касается ли нововведение PaaS (cloud services)?