Мне кажется, что ВУЗ, кроме образовательных выполняет ещё несколько важных функций:
1) Умение самому получать и усваивать необходимые знания. В какой-то мере, проводить исследовательскую работу.
2) Общение с большим количеством людей, которые работают/собираются работать в той же области. Этот опыт не стоит недооценивать. Это даёт человеку понимание основ будущей профессии, изучение этики, сленга и тд. Происходит обмен опытом, человек начинает хотя бы немного понимать рынок, на который он собирается выйти.
3) Высшее учебное заведение это ступенька на пути к самостоятельности человека. Место, где человек может набраться уверенности в себе и своих силах, выбрать себе направление деятельности по душе, научиться самостоятельно принимать решения. Согласитесь, многим из нас было бы довольно сложно пойти работать сразу после школы. И дело не только в отсутствии профессиональных навыков.
Всё вышесказанное относится, конечно же, только к хорошим, правильным ВУЗам. Ну и, конечно же, всё на правах ИМХО.
Тоже не люблю блум. И на приведённой вами картинке ясно видно почему: картинка с блумом начинает выглядеть как изображение, снятое на камеру. Человек так не видит. Не знаю как вам, но мне не нравиться видеть сцену в игре так, будто я смотрю на неё через экранчик видеокамеры. Раздражает ужасно, особенно пересвеченные области. Хотя, конечно же, это всё дело вкуса.
Возможно выскажу непопулярное мнение, но сама идея, что нужно платить за чужой труд кажется мне очевидной логической ошибкой. Хотя звучит, конечно, хорошо.
Покупатель платит вовсе не за труд — он платит за товар. Как покупателю, мне абсолютно плевать сколько труда кто и во что вложил, если товар получился плохой, то я его не куплю даже если это дело всей жизни автора, и речь не только о программах.
Чтобы продавать товар он должен быть нужным, а не трудозатратным.
При текущем состоянии копирайта, правообладатели чаще всего пытаются продавать воздух, то, что никому не надо потому что это что-то есть везде и бесплатно. Информацию нельзя продавать много раз, потому что будучи единожды проданной она быстро и легко распространяется и цена её резко падает до нуля. Процесс стихийный и пытаться бороться с ним — всё равно что бороться с ветряными мельницами.
И нужно чётко осознавать, что когда речь заходит о «нужно платить, чтобы поддержать автора», то речь идёт уже не о товаре и не в экономическом русле. Тут уже вы предлагаете покупателю взять на себя роль мецената. А он часто не хочет быть меценатом, ему просто нужен определённый товар, который по законам рынка, не стоит ничего. Но вы предлагаете ему купить его за большие деньги, но не объясняете, почему он должен это делать. Он отказывается и он полностью прав, потому что быть меценатом — дело добровольное.
1) Если и можно, то я о таких способах не знаю.
2) О том и речь, что в стандартной библиотеке реализована проверка на поддержку исключений и в большинстве случаев при отключенных исключениях вызывается abort() вместо выброса исключения. Проблема в том, что в разных компиляторах эта проверка, опять же, реализуется по разному. А значит опять лишние проблемы с тестированием и поддержкой компиляторо-зависимого кода.
Всё это справедливо и для моего Accessor'а кроме выбрасывания исключений. Я обдумал вариант с исключениями и решил не выкидывать исключения по нескольким причинам:
1) Лишняя проверка при простых операциях типа разыменования, которые должны быть максимально быстрыми. Конечно, ущерб от этого можно свести к минимуму с помощью likely/unlikely, но это лишние проблемы с портируемостью, так как это компиляторные атрибуты.
2) Исключения в С++ не всеми используются и не всегда включены, что тоже требует дополнительной обработки.
3) Результатом разыменования nullptr на практике почти всегда будет падение, хоть это и UB формально.
4) Падение — это хорошо в данном случае. Такие исключения, ИМХО, обрабатывать не стоит в любом случае. Однако я согласен, что остановка программы с исключением — гораздо правильнее и удобнее чем без него.
Одним словом, поддержку исключений можно сделать, и даже нужно. Но это не элементарная задача, в ней есть свои нюансы, поэтому я решил, что вынесение подобных вещей в статью только усложнит её для понимания и отвлечёт от сути. В репозитории я попробую реализовать нормальную поддержку исключений.
Да, это легко сделать с вектором или любым другим контейнером, или классом, для которого пустое состояние ожидаемо и часто встречается на практике. Но что делать с классами типа std::thread или, например, std::future при перемещении? Заметьте, это классы стандартной библиотеки. У std::future в описании прямым текстом написано
move constructor
The constructed object acquires the shared state of x (if any).
x is left with no shared state (it is no longer valid).
Источник
Так что можно считать, что предложенный мною подход вполне соответствует практике.
На самом деле не совсем. Речь идёт о постоянном объекте (ресурсе), который защищён мьютексом, но не освобождается в случае выхода из блока кода. Но за подход спасибо, взял на заметку )
Похоже, вы правы. Хотя некоторые отличия всё-таки есть, но суть одна, согласен. Признаюсь, я с самого начала не надеялся, что изобрёл что-то принципиально новое. Целью было скорее обратить внимание на неплохую, ИМХО, идиому тех, кто раньше про неё не слышал. Ну и ещё я надеялся, что кому-нибудь из новичков, возможно, будет полезно почитать про пошаговый процесс разработки класса с желаемой функциональностью, где более-менее понятно описано, почему при разработки используются те или иные решения. Видео обязательно посмотрю, как доберусь домой, спасибо.
Это правда, что поделать, C++ всё-таки не Rust. Это просто попытка сделать свой C++ код хотя бы немного безопаснее в ожидании релиза Rust'а. Именно поэтому и есть раздельчик про то, чего делать с этим классом нельзя. Было бы классно, если бы был способ переложить хотя бы часть этих проверок на компилятор, но нам, плюсовикам, приходиться контроллировать такие вещи самим, к сожалению.
Согласен. Но лично я не смог придумать, как можно переместить данный класс без того, чтобы его больше нельзя было использовать. Поэтому и пришлось добавить метод проверки и этим, как бы, признать подобное состояние валидным, просто не пригодным к дальнейшему использованию. Так же устроены многие move-конструкторы для многих классов стандартной библиотеки, например std::thread.
Спасибо за вопросы
1) Честно говоря не обдумывал такой сценарий. Возможно это действительно имеет смысл. Не подскажете, в каких случаях это могло бы быть полезно, чтобы подумать, как лучше реализовать?
2) Я думал об этом, но тогда, по-хорошему, нужно использовать не мьютекс а read-write lock и соответствующим образом лочить его при получении Accessor'а. Но в стандартной библиотеке их нет, а вносить лишнии зависимости, усложняя статью не хотелось. Оставить просто mutex и сделать ConstAccessor просто для поддержки константности можно и даже нужно. Спасибо за подсказку, честно говоря, просто забыл об этом.
P.S. Подпишусь под каждым словом вашего первого поста в ветке.
1) Умение самому получать и усваивать необходимые знания. В какой-то мере, проводить исследовательскую работу.
2) Общение с большим количеством людей, которые работают/собираются работать в той же области. Этот опыт не стоит недооценивать. Это даёт человеку понимание основ будущей профессии, изучение этики, сленга и тд. Происходит обмен опытом, человек начинает хотя бы немного понимать рынок, на который он собирается выйти.
3) Высшее учебное заведение это ступенька на пути к самостоятельности человека. Место, где человек может набраться уверенности в себе и своих силах, выбрать себе направление деятельности по душе, научиться самостоятельно принимать решения. Согласитесь, многим из нас было бы довольно сложно пойти работать сразу после школы. И дело не только в отсутствии профессиональных навыков.
Всё вышесказанное относится, конечно же, только к хорошим, правильным ВУЗам. Ну и, конечно же, всё на правах ИМХО.
Покупатель платит вовсе не за труд — он платит за товар. Как покупателю, мне абсолютно плевать сколько труда кто и во что вложил, если товар получился плохой, то я его не куплю даже если это дело всей жизни автора, и речь не только о программах.
Чтобы продавать товар он должен быть нужным, а не трудозатратным.
При текущем состоянии копирайта, правообладатели чаще всего пытаются продавать воздух, то, что никому не надо потому что это что-то есть везде и бесплатно. Информацию нельзя продавать много раз, потому что будучи единожды проданной она быстро и легко распространяется и цена её резко падает до нуля. Процесс стихийный и пытаться бороться с ним — всё равно что бороться с ветряными мельницами.
И нужно чётко осознавать, что когда речь заходит о «нужно платить, чтобы поддержать автора», то речь идёт уже не о товаре и не в экономическом русле. Тут уже вы предлагаете покупателю взять на себя роль мецената. А он часто не хочет быть меценатом, ему просто нужен определённый товар, который по законам рынка, не стоит ничего. Но вы предлагаете ему купить его за большие деньги, но не объясняете, почему он должен это делать. Он отказывается и он полностью прав, потому что быть меценатом — дело добровольное.
2) О том и речь, что в стандартной библиотеке реализована проверка на поддержку исключений и в большинстве случаев при отключенных исключениях вызывается abort() вместо выброса исключения. Проблема в том, что в разных компиляторах эта проверка, опять же, реализуется по разному. А значит опять лишние проблемы с тестированием и поддержкой компиляторо-зависимого кода.
1) Лишняя проверка при простых операциях типа разыменования, которые должны быть максимально быстрыми. Конечно, ущерб от этого можно свести к минимуму с помощью likely/unlikely, но это лишние проблемы с портируемостью, так как это компиляторные атрибуты.
2) Исключения в С++ не всеми используются и не всегда включены, что тоже требует дополнительной обработки.
3) Результатом разыменования nullptr на практике почти всегда будет падение, хоть это и UB формально.
4) Падение — это хорошо в данном случае. Такие исключения, ИМХО, обрабатывать не стоит в любом случае. Однако я согласен, что остановка программы с исключением — гораздо правильнее и удобнее чем без него.
Одним словом, поддержку исключений можно сделать, и даже нужно. Но это не элементарная задача, в ней есть свои нюансы, поэтому я решил, что вынесение подобных вещей в статью только усложнит её для понимания и отвлечёт от сути. В репозитории я попробую реализовать нормальную поддержку исключений.
Источник
Так что можно считать, что предложенный мною подход вполне соответствует практике.
1) Честно говоря не обдумывал такой сценарий. Возможно это действительно имеет смысл. Не подскажете, в каких случаях это могло бы быть полезно, чтобы подумать, как лучше реализовать?
2) Я думал об этом, но тогда, по-хорошему, нужно использовать не мьютекс а read-write lock и соответствующим образом лочить его при получении Accessor'а. Но в стандартной библиотеке их нет, а вносить лишнии зависимости, усложняя статью не хотелось. Оставить просто mutex и сделать ConstAccessor просто для поддержки константности можно и даже нужно. Спасибо за подсказку, честно говоря, просто забыл об этом.