Обновить
129
0
Григорий Демченко@gridem

Software Engineer

Отправить сообщение
Да, точно, т.к. принимается шаблонный указатель. Т.е. такие строчки будут вызывать корректное освобождение памяти даже без виртуального деструктора в A:

std::shared_ptr<A> a = std::make_shared<B>();
std::shared_ptr<A> a(new B());
Прикол в том, что документацию обычно никто не читает. Ну или не читают так, как читают статьи на хабре. Но я подумаю над этим.
Если быть точнее, то в реализации связки shared_ptr + make_shared.
Да, я старался. Времени ушло на подготовку статьи — уйма. Учитывая то, что я ее начинал делать в начале этого года. Потом конференции, потом еще… Надеюсь, время тратил не зря.
Да, который при портировании вызывает адскую попоболь…
Надо понимать, что в статье приведен модельный пример, который раскрывает использование многих примитивов. В частности, иногда хочется получить результат параллельно из нескольких источников. Это может быть как получение данных из памяти и диска, а может быть из двух дисков: один — SSD, другой — обычный. SSD быстрый, но много не влезет, а HDD медленный, но влезает сильно больше. Но оба они не сказать, чтобы быстрые, поэтому в такой постановке это будет иметь больше смысла. В другом случае могут быть удаленная база данных и локальный кеш на диске.

В общем, сути это не меняет. Хочется параллелить операции по получению данных, и хочется делать это наиболее простым способом. Как? Показано в статье.
Ага. Теги как бы намекают…
Вот вам еще одна ошибка, которая невозможна при явном локе
Т.е. так нельзя написать:

v.lock()->x = foo(f.lock()->x)
?

А вообще, когда я писал про возможности, то имел в виду, что разработчик может оставить в своем проекте только те возможности, которые ему нужны. И в данном случае я считаю, что иметь выбор лучше его отсутствия. Более того, если посмотреть мою презентацию, то там я рассказываю про то, как можно избегать дедлоков при работе сразу с несколькими мьютексами, а здесь вообще про это ничего не сказано. Далее: при работе с разделяемым объектом не синглтоном возникает вопрос о времени жизни со всеми вытикающими. Как такие объекты класть в контейнер? Как изменять? Как работать сразу с несколькими объектами из разных контейнеров? Тут не очень понятно.
У моего подхода больше возможностей: можно как явно, так и неявно. А любую из этих возможностей при желании можно отрубить. Так что идеологически — более полноценный подход.
По-моему, вы заново изобрели умные мьютексы, которые были описаны в моей статье: Полезные идиомы многопоточности С++. Только у меня еще круче: можно также реализовать RW locks через длинную стрелку --->. Еще предлагаю посмотреть видео видео со встречи C++ User Group в Санкт-Петербурге.
Вы это серьезно?
Мы называем её скоростью света и даже посчитали её приблизительное значение.

Небольшое уточнение: на данный момент скорость света известна абсолютно точно с математической точки зрения!

Мы тут с коллегами посовещались и решили, что, конечно, ввести ИСО со скоростью света можно, только никаких внятных физических следствий вывести будет невозможно. А всё потому, что всё вокруг будет двигаться со скоростью света, а значит время перестает играть какую-либо роль, т.к. оно замрет. Таким образом, нет никакого физического смысла вводить такую систему отсчета.
Это ваш постулат? Или он откуда-то следует? Если я правильно понял ваш ответ, то ИСО не может двигаться со скоростью света, потому что не может двигаться со скоростью света.
А почему? Какие законы нарушаются?
В данном случае мы всегда говорим о фотонах, т.е. о частицах света.
Вы не ответили на мой вопрос о том, можно ли выбирать ИСО, движущуюся со скоростью света перпендикулярно движению фотона.
Хорошо. Вот я взял ИСО, движущуюся со скоростью света перпендикулярно движению фотона. Какие законы при этом нарушаются? Скорость движения фотона в этой ИСО будет равна скорости света, ведь так?
Ну тут тоже есть огрехи в рассуждениях. Например, я же могу ввести систему отсчета, которая движется со скоростью света, но немного в другом направлении? Вроде как да. Ведь в таком случае фотон будет иметь скорость света, и все будет логично и без противоречий. Теперь я начинаю потихоньку выравнивать направление моей инерциальной системы отсчета и направление движения фотона. В момент, когда они выравняются, такая система отсчета будет навалидной из-за надвигающегося противоречия.

Т.е. получается, все инерциальные системы валидны, кроме тех, что направлены по движению какого-либо фотона в нашей вселенной. Что, в общем-то, звучит несколько бредово. Поэтому логичным условием введения инерциальной системы отсчета был бы запрет на скорость движения, равной (или больше?) скорости света. Но такого условия я не встречал. Поправьте, если я ошибаюсь.
Верно, отрицательной температура быть не может. А вот эффективная температура — может. Например, если приписать инверсной заселенности (см. лазеры) температуру, то она как раз и получится отрицательной. Но это верно только для эффективной температуры, т.е. как если бы можно было ввести понятие температуры. Но там нет равновесия по соответствующим степеням свободы, а потом температуру в таких системах ввести невозможно. А там, где ее можно ввести, там она всегда будет неотрицательной.
Да, заявить подобное можно, но хочется услышать аргументацию, почему это не имеет смысла. Чуть выше я привел доводы, которые, на мой взгляд, не лишены смысла. А суть в том, что автор заранее хочет избежать неудобных вопросов, из-за которых его «стройная» теория рассыпается в прах.

Однако стоит отметить, что приведенные в статье рассуждения довольно интересны сами по себе. И хотя это не является общепринятым взглядом на вопрос, нельзя не отметить оригинальность идеи.

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность