Порой даже названные своими именами значения, уложенные в правильные контейнеры требуют комментариев.
А что касается js файла, далеко не везде есть возможность исполнять js. Если проект, например, на C++, то гораздо логичнее использовать JSON парсер, поддерживающий комментарии.
Серьезно, это IMHO, но лично мне Yaml кажется настолько человекочитаемым, что его становится сложно читать. Вот уже лет пять, как знаю об этом формате, но до сих пор не понимаю его. А вот JSON, тем более, с комментариями, не вызывает никаких трудностей.
Один мой знакомый достаточно точно выразился. Yaml — для любителей python, а JSON — для тех, кто любит C и жить не может без скобочек.
Думаю, это делается для обеспечения правильного натяжения бумаги во время всего процесса печати. Если просто тянуть бумагу, ее можно порвать, смять, растянуть, и вообще всячески деформировать.
А почему такие серьезные требования к железу? (8GB RAM)
Atlassian Stash для подобных задач требует 768MB, ваши же YouTrack и TeamCity тоже не сильно прожорливы. Мне было очень удобно развернуть их на cubietruck-ах для маленькой команды. Уже давно присматриваюсь к Upsource EAP, кажется, что в связку youtrack-teamcity он должен вписаться лучше, чем stash, но останавливает именно это требование к памяти.
Мое сообщение, больше посыл к упоминанию автора о том, что он привязал это действие к cmd+shift+l. И да, тут имхо, дело вкуса, мне как человеку, у которого обычно обе руки на клавиатуре, и дефолтный хоткей удобен. Единственная проблема, с которой я сталкивался — о нем написано чуть больше, чем нигде, именно поэтому многие перевешивают его сторонними средствами.
Как-то это костыльно… Имхо, на доступе к объектам через unique_ptr, хранящийся в векторе, можно потерять больше, чем на переаллокациях в этом векторе. То есть гнаться за Relocatable только ради Relocatable — это странно. А судя по фразе «Если вы не сделаете этого, fbvector не скомпилируется с BOOST_STATIC_ASSERT.» Бравым ребятам из фэйсбука без этого никак.
Да, при изменении размера вектора указатели на его элементы могут стать не валидными. Но умные указатели никак не решают эту проблему.
Разве что вы сделаете конструкцию
std::vector<std::unique_ptr<T> >
. Но это не решает проблемы того, что указатели и ссылки на сами умные указатели все равно будут битыми после изменения размера вектора, просто потому что умный указатель — это тоже объект. То есть, такими методами вы добьетесь неизменства указателя на объект класса T, но в такой схеме этот объект уже никакого отношения к вектору не имеет, и проблему вы не решили, а обошли.
Вы не можете написать:
class A {};
std::vector<std::unique_ptr<A> > vector;
std::unique_ptr<A>& ptr = vector[i];
vector.push_back(...);
ptr.reset(new A()); // ссылка ptr может быть битой.
Каюсь, видимо я уже настолько привык использовать scoped_ptr/unique_ptr, что простой указатель внутри объекта для меня уже стал сущностью, которой явно владеет какой-то другой объект. В таком случае да, согласен, простое копирование вносит путаницу в понимание, кто владеет указателем. С другой стороны, в данной статье речь о перемещении, а не о копировании, а с перемещением такой проблемы не стоит.
Во втором случае умные указатели не решают проблему того, что при перемещении объекта нужно поправить все указатели на этот объект. Банально, если в стеке во время перемещения есть вызов метода этого объекта, то после возврата в этот метод станет невалидным указатель this, а значит, при доступе к любым данным объекта, программа свалится.
Объекты первого типа всегда могут быть переделаны с минимальными затратами. Объекты второго типа не должны создаваться оператором new и удаляться оператором delete — они должны быть управляемы умными указателями и никаких проблем не будет.
Кажется, что если объект имеет указатели на другие объекты, то это не делает его неперемещаемым — простое побитовое копирование не меняет состояние объекта. А значит затрат нет вообще никаких.
По поводу второго типа вообще не понятно. Интересно, как же это так создать объект и управлять им с помощью умного указателя без оператора new… Вдобавок возникает вопрос, как умный указатель решает проблему неперемещаемости объекта, на который есть указатели.
Емнип, хабр поддерживает svg, если подставлять их через тег img. Но svg не поддерживает habrastorage. В последний раз я укладывал svg в публичную папку на дропбоксе и вставлял в пост, используя публичные ссылки.
На самом деле, тупиковый путь. Основной минус интеграции git в sublime text заключается в отсутсвии в сублайме возможности связывать команды в цепочки. Если проект большой, то git достаточно много времени тратит на коммит (особенно если где-нибудь в хуках висит скрипт, проверяющий стиль кода). Гораздо оптимальнее — писать маленькие функции-хелперы в .bashrc. и вызывать их.
А что касается js файла, далеко не везде есть возможность исполнять js. Если проект, например, на C++, то гораздо логичнее использовать JSON парсер, поддерживающий комментарии.
Один мой знакомый достаточно точно выразился. Yaml — для любителей python, а JSON — для тех, кто любит C и жить не может без скобочек.
Atlassian Stash для подобных задач требует 768MB, ваши же YouTrack и TeamCity тоже не сильно прожорливы. Мне было очень удобно развернуть их на cubietruck-ах для маленькой команды. Уже давно присматриваюсь к Upsource EAP, кажется, что в связку youtrack-teamcity он должен вписаться лучше, чем stash, но останавливает именно это требование к памяти.
Разве что вы сделаете конструкцию . Но это не решает проблемы того, что указатели и ссылки на сами умные указатели все равно будут битыми после изменения размера вектора, просто потому что умный указатель — это тоже объект. То есть, такими методами вы добьетесь неизменства указателя на объект класса T, но в такой схеме этот объект уже никакого отношения к вектору не имеет, и проблему вы не решили, а обошли.
Вы не можете написать:
Во втором случае умные указатели не решают проблему того, что при перемещении объекта нужно поправить все указатели на этот объект. Банально, если в стеке во время перемещения есть вызов метода этого объекта, то после возврата в этот метод станет невалидным указатель this, а значит, при доступе к любым данным объекта, программа свалится.
Кажется, что если объект имеет указатели на другие объекты, то это не делает его неперемещаемым — простое побитовое копирование не меняет состояние объекта. А значит затрат нет вообще никаких.
По поводу второго типа вообще не понятно. Интересно, как же это так создать объект и управлять им с помощью умного указателя без оператора new… Вдобавок возникает вопрос, как умный указатель решает проблему неперемещаемости объекта, на который есть указатели.
К слову, у них достаточно равномерно подборка на категории разбита: yadi.sk/i/TrH2SS9DbXZZ6
Имхо, не стоит настолько похожие тексты постить с разницей меньше чем сутки.
Реальный пример:
Набрав такую команду можно пойти налить чаю и вернуться к тому моменту, когда все закончится.