Абсолютно верно. Вероятнее всего в случае, если reset вызван не будет, ничего страшного не произойдет, но если это вдруг окажется важным для корректного функционирования, то потенциально это может стоить часов отладки.
Абсолютно согласен с тем, что нету ничего плохого в тестах с реальной сетью, файловой системой и базой данных. Проблема в том, что многие справедливо заметят, что это уже Интеграционные а не Модульные тесты. Не вижу ничего плохого в том, чтобы иметь разные типы тестов ( вплоть до силениумных ) и пользоваться ими всеми. Вопрос стоит во времени исполнения. Я считаю, что именно Модульные тесты должны запускаться в процессе сборки ( а не отдельно).
Хороший совет про RamFS. Когда я налаживал тесты с реальной БД на PgSQL, то разница во времени исполнения достигала порядков при различных типах ФС ( ext3/ext4 ) и различных типах физических дисков.
Кстати на моем проекте у нас есть слой, который скрывает построение запросов для БД и мы очень эффективно смогли решить проблему тестирования, написав бэкенд для SQLITE, который может работает только в оперативной памяти.
Мне было интересно. Заказывал разные товары, но косяков не было. Всегда интересует опыт про то «что делать, если пришло не то чего ждал».
Я бы прошелся по тексту и сократил раза в два — выглядит как «поток мысли». Но это личное мнение: «на вкус и цвет...»
1) Ну если я заплатил за телефон, то как вы предлагаете поступить, если на каком-то этапе разработке денег не хватило?
2) Я не думаю, что это что-то изменило бы. Почти половина денег была собрана в первый день. Сомневаюсь, что еще за месяц можно было бы выжать даже еще миллион. Сужу по тенденциям
3) Я бы не хотел, чтобы деньги за мой телефон были распределены голосованием
Я и не знал, что можно получать подменный товар. Сдавал несколько раз ноутбуки в ремонт и не задумывался об этом. Впрочем было на чем работать. Теперь буду знать. Скажите, а на что нужно ссылаться при требовании получить подменную технику?
Очень расстроен тем, что они не собрали 32 ляма. Почти половина всей собранной суммы была собрана в первый день компании — закон 80/20 в действии. Я был почти уверен, что Марк докинет из своих. Будем надеяться, что Убунту для телефонов выйдет в октябре — очень хочу посмотреть на нее в работе.
Позволю себе высказать мнение как сотрудника. То что Вы описали замечательно в теории, но на практике в начале своей карьеры я покинул одну компанию только по той причине, что меня раз в три месяца кормили «маленькими конфетками», и намеками на то что «подумают, но пока не готовы» к более серьезным шагам. С другой стороны Вы правы — лишние пол года меня продержали.
При этом прощу заметить, что для квалифицированного специалиста повышение зарплаты на несколько тыс рублей и вовсе может выглядеть как оскорбление.
Но это моя личная точка зрения на вопрос, а для принятия решения любая точка зрения важна )
1) Потому что тогда на один объект будет заведено два счетчика
Эквивалентно
Widget* p = new Widget;
shared_ptr<Widget> a( p );
shared_ptr<Widget> b( p );
При выходе второго объекта из области определения будет попытка освобождения уже освобожденного объекта
2) intrusive_ptr содержит встроенный счетчик и поэтому такая конструкция
Widget* p = new Widget;
intrusive_ptr<Widget> a( p );
intrusive_ptr<Widget> b( p );
Уже не приведет к ошибке, т.к. у них остается общий счетчик (встроенный) и при выходе первого объекта(a) из области определения он только уменьшит счетчик, но не удалит объект.
Поэтому для intrusive_ptr валидной является конструкция
Порядок выполнения действительно не может быть нарушен в том плане, что
1) bar будет вычислен раньше foo
2) new object1 будет вычислен раньше bar
3) new object 2 будет вычислен раньше foo
В остальном как повезет.
То есть Вы хотите сказать, что выглядит так, будто постулируется, что все операции для всех экземпляров, указывающих на объект, должны выполняться под локом?
Завтра утром внесу правки, если придумаю. Боюсь разбухания текста. Сокращал, а получилось все равно очень много.
Это публикация ориентирована на тех кто начал (начинает) работать с данной технологией (как описано во вступлении). Сомневаюсь, что для Гуру она будет полезна. Я не претендую на совершенный разбор «неизведанных глубин».
Вы справедливо заметили, вся эта информация есть в документации и частями в различных публикациях. Я лишь хочу облегчить путь для тех, кто им еще не ходил, чтобы сэкономить им часы отладки. Ведь не все люди никогда не совершают ошибок.
В любом случае, спасибо за Ваше мнение, ведь не получить хотя бы одного негативного отклика было бы подозрительно.
Спасибо за комментарий! Это мой первый опыт в таких публикациях. Я решил нужным упомянуть об этой проблеме, т.к. в действительности не все программисты знают в каких случаях атомарный счетчик уберегает от проблем. Я думаю, что мог выразить мысль не совсем внятно. А как именно вы предлагаете изменить часть про многопоточность?
Речь в статье про один и тот же экземпляр shared_ptr. Если shared_ptr скопировать, то внутри одного потока его можно свободно использовать и копировать дальше. Атомарный счетчик именно этой цели и служит. Реализация с мутексом была бы очень тяжелой по производительности.
А как строят судоку существующие компьютерные программы вы не разбирали? Таким же способом?
Хороший совет про RamFS. Когда я налаживал тесты с реальной БД на PgSQL, то разница во времени исполнения достигала порядков при различных типах ФС ( ext3/ext4 ) и различных типах физических дисков.
Кстати на моем проекте у нас есть слой, который скрывает построение запросов для БД и мы очень эффективно смогли решить проблему тестирования, написав бэкенд для SQLITE, который может работает только в оперативной памяти.
Я бы прошелся по тексту и сократил раза в два — выглядит как «поток мысли». Но это личное мнение: «на вкус и цвет...»
2) Я не думаю, что это что-то изменило бы. Почти половина денег была собрана в первый день. Сомневаюсь, что еще за месяц можно было бы выжать даже еще миллион. Сужу по тенденциям
3) Я бы не хотел, чтобы деньги за мой телефон были распределены голосованием
При этом прощу заметить, что для квалифицированного специалиста повышение зарплаты на несколько тыс рублей и вовсе может выглядеть как оскорбление.
Но это моя личная точка зрения на вопрос, а для принятия решения любая точка зрения важна )
Эквивалентно
При выходе второго объекта из области определения будет попытка освобождения уже освобожденного объекта
2) intrusive_ptr содержит встроенный счетчик и поэтому такая конструкция
Уже не приведет к ошибке, т.к. у них остается общий счетчик (встроенный) и при выходе первого объекта(a) из области определения он только уменьшит счетчик, но не удалит объект.
Поэтому для intrusive_ptr валидной является конструкция
www.boost.org/doc/libs/1_54_0/libs/smart_ptr/shared_ptr.htm
начиная с «Best Practices».
Там есть ссылка на Сартара
Порядок выполнения действительно не может быть нарушен в том плане, что
1) bar будет вычислен раньше foo
2) new object1 будет вычислен раньше bar
3) new object 2 будет вычислен раньше foo
В остальном как повезет.
Завтра утром внесу правки, если придумаю. Боюсь разбухания текста. Сокращал, а получилось все равно очень много.
Вы справедливо заметили, вся эта информация есть в документации и частями в различных публикациях. Я лишь хочу облегчить путь для тех, кто им еще не ходил, чтобы сэкономить им часы отладки. Ведь не все люди никогда не совершают ошибок.
В любом случае, спасибо за Ваше мнение, ведь не получить хотя бы одного негативного отклика было бы подозрительно.