На самом деле, на сегодняшний день уже вообще нет особого смысла использовать голые/сырые указатели (raw pointers).
Core Guidelines с вами не согласен.
Passing a smart pointer transfers or shares ownership and should only be used when ownership semantics are intended. A function that does not manipulate lifetime should take raw pointers or references instead
Вообще, я бы вам рекомендовал не пытаться изобретать велосипеды, а потратить силы на перевод того, что уже хорошо написано и неплохо обосновано, от этого будет больше пользы.
Это было наверное ну ОЧЕНЬ давно. Начал учить плюсы году в 2011-м. Везде и всегда писали "куча" и уже точно никто и нигде не употреблял англицизмы в тексте) В речи да, до сих пор говорят "в хипе", но в текстах уже 100500 лет пишут "куча".
Как обладатель пикселя 5а не понимаю, в какой момент появятся хоть сколько-нибудь заметные признаки выгорания дисплея. Правда пользуюсь я им всего года 2 получается.
Я принципиально не хожу на собеседования в места, где гоняют по алгоритмам. Проблем с работой не испытывал ни разу.
Причем причина проста - я вообще не разбираюсь в этих алгоритмах. Я их не знаю и мне совершенно лень их учить.
Тем не менее на практике ещё не было ни одного случая, когда бы я не разобрался в каком-то алгоритме, когда это было нужно для задачи. Сел, почитал денёк, понял.
С учётом количества справочниклв по теме, зачем мне хоть что-то учить всё никак в толк не возьму.
С моей колокольни знание архитектуры ЭВМ значительно важнее алгоритмов. Что толку от всех этих математических оценок сложности, когда в итоге в 99,99% случаев ты упираешься в те или иные кэши, и по сути вся задача сводится к перекладыванию байтиков так, чтобы кэш сказал спасибо. Никакого математического обоснования, кстати, не потребуется)
Ну, в принципе, когда там в соседней ветке говорили о программистах, которые за константу принимают то, что раньше даже в самом страшном сне не приводилось бы - говорят о вас. Я просто обобщил принцип на всех людей, а не на программистов :)
Раньше определенео было не такое наплевательство отношение к потребителю) И ничего, общество успешной функционировало десятилетиями. Вся эта история про "сам виноват" и "ты ничем не владеешь" - это веяние последних десятилетий)
Смотрите в чём прикол: я был бы не против "девятка яиц". Да что уж там, я бы и поштучно покупал. Проблема в том, что продают 9 яиц по цене десятка. Вот в чём проблема. И ведь покупают) Про принтеры я даже говорить не буду. Они из простых и удобных устройств за последние 15 лет превратились в неудобные, тормозные, глючные ящики, которые от тебя хотят одного: "плати".
Личная собственность практически мертва. Мы не можем вкрывать, что купили, не можем ремонтировать, не можем разлочить загрузчики, не можем запустить софт без интернета, не можем играть в игры, которые купили. Да мы из себе даже скачать де факто не можем. Не можем смотреть кино, которое оплатили и т.д. и т.п.
Люди предпочитают гавно конфеткам и радуются, что оно удобное) И я такой же, ведь я человек)
На моей памяти такого никогда не случалось (я имею ввиду, чтобы в погоне за чистотой, случился ООМ).
Написание кода в функциональном стиле - это хороший подход в очень многих ситуациях, я крайне его рекомендую и всячески пропагандирую. В более или менее приличных языках, имеющих хоть какую-то внятную (не обязательно хорошую) систему типов, компилятор способен оптимизировать оверхед.
Тем не менее функциональные языки мне не нравятся, на них жутко неудобно писать обработку ошибок и просто поразительное количество костылей нужно, если хочется повозиться с состоянием.
Поэтому мой совет - во всём нужно знать меру) Второй совет - используйте языки, позволяющие смешивать императивщину и функциональщину и будете счастливы)
почему эта функция не может сама установить этому объекту значение свойства oven
Потому что функция хочет быть чистой. Чистые функции предсказуемы и крайне надёжны. Но от этого эпизодически страдает производительночть.
Если из самого объекта oven, то почему мы не можем сделать то же самое без вызова этой функции
Потому что это модификация состояния, что не всегда требуется.
Де факто, код справа переписан в функциональном стиле (хотя и не очень удачно), что позволяет получить определенные преимущества, особенно в контексте асинхронной/параллельной обработки пиццы.
Однако чтобы понять суть этих преимуществ, нужно хотя бы поверхностно окунуться в функциональные языки, на этом конкретном примере продемонстрировать их не получится.
Только вот люди — они не совсем дурные, и они куда более склонны платить деньги за продукты, действительно удовлетворяющие их потребности. А от того через такие продукты самовозрастание капитала как-то лучше идёт.
Это в корне неверное заблуждение. Если бы это так было, многие из наблюдаемых на рынке явлений бы просто не сработали. Чипированные принтеры, запланированное устаревание во всём, что нас окружает, молоко 0.843 литра и девяток яиц, реклама в телевизорах за 2000$, онлайн регистрация в single player играх, и прочее и прочее.
Люди, массе своей (я не исключение), совсем дурные, и вместо покупки товаров, решающих их проблемы, покупают по принципу, чтобы было "покрасивше" и "подешевле" (ну или подороже, но постатуснее). Люди поразительно плохи в анализе рисков и стоимости владения вещами. Многие даже слов таких не знают, как "стоимость владения".
В общем, ничто не ново под луной, как и мой комментарий
Ну и если уж подняли тему невалидных указателей, то имеет смысл и поднять тему инвалидации итераторов, потому как это чуть ли не самая важная штука.
Штош :) Рекомендую вам ознакомиться с интересной статьёй на тему указателей на методы класса)
Pointers to member functions are very strange animals
Ну или хотя бы заглянуть в этот топик на Stackoverflow. Вас ждёт сюрприз :)
Core Guidelines с вами не согласен.
Вообще, я бы вам рекомендовал не пытаться изобретать велосипеды, а потратить силы на перевод того, что уже хорошо написано и неплохо обосновано, от этого будет больше пользы.
Это было наверное ну ОЧЕНЬ давно. Начал учить плюсы году в 2011-м. Везде и всегда писали "куча" и уже точно никто и нигде не употреблял англицизмы в тексте) В речи да, до сих пор говорят "в хипе", но в текстах уже 100500 лет пишут "куча".
В который раз?
Между "я знаю что есть алгоритмы делающие Х за O(logN)" и "я могу в live-режиме запилить вам алгоритм, делающий Х за O(logN)" таки есть разница.
И если первое у меня проблем не вызывает, то второе... Ну, скажем так, я даже не считаю нужным знать без явной необходимости.
Но на собесах-то спрашивают всегда второе, хотя на самом деле важным является первое)
Я вот прямо сейчас в полной темноте проверил: никаких, даже малозаметных пятен нет. Ну, или я просто не знаю, что надо увидеть.
Могу, конечно, предположить, что причина ещё может быть в том, что я пользуюсь темными темами абсолютно везде.
Как обладатель пикселя 5а не понимаю, в какой момент появятся хоть сколько-нибудь заметные признаки выгорания дисплея. Правда пользуюсь я им всего года 2 получается.
Какие у минцифры делать такие заявления? К слову, какие у них вообще полномочия? Чем они занимаются-то?
Я принципиально не хожу на собеседования в места, где гоняют по алгоритмам. Проблем с работой не испытывал ни разу.
Причем причина проста - я вообще не разбираюсь в этих алгоритмах. Я их не знаю и мне совершенно лень их учить.
Тем не менее на практике ещё не было ни одного случая, когда бы я не разобрался в каком-то алгоритме, когда это было нужно для задачи. Сел, почитал денёк, понял.
С учётом количества справочниклв по теме, зачем мне хоть что-то учить всё никак в толк не возьму.
С моей колокольни знание архитектуры ЭВМ значительно важнее алгоритмов. Что толку от всех этих математических оценок сложности, когда в итоге в 99,99% случаев ты упираешься в те или иные кэши, и по сути вся задача сводится к перекладыванию байтиков так, чтобы кэш сказал спасибо. Никакого математического обоснования, кстати, не потребуется)
Ну, в принципе, когда там в соседней ветке говорили о программистах, которые за константу принимают то, что раньше даже в самом страшном сне не приводилось бы - говорят о вас. Я просто обобщил принцип на всех людей, а не на программистов :)
Раньше определенео было не такое наплевательство отношение к потребителю) И ничего, общество успешной функционировало десятилетиями. Вся эта история про "сам виноват" и "ты ничем не владеешь" - это веяние последних десятилетий)
Смотрите в чём прикол: я был бы не против "девятка яиц". Да что уж там, я бы и поштучно покупал. Проблема в том, что продают 9 яиц по цене десятка. Вот в чём проблема. И ведь покупают) Про принтеры я даже говорить не буду. Они из простых и удобных устройств за последние 15 лет превратились в неудобные, тормозные, глючные ящики, которые от тебя хотят одного: "плати".
Личная собственность практически мертва. Мы не можем вкрывать, что купили, не можем ремонтировать, не можем разлочить загрузчики, не можем запустить софт без интернета, не можем играть в игры, которые купили. Да мы из себе даже скачать де факто не можем. Не можем смотреть кино, которое оплатили и т.д. и т.п.
Люди предпочитают гавно конфеткам и радуются, что оно удобное) И я такой же, ведь я человек)
Как я и сказал - реализация и дизайн - оч плохи. Я бы предпочел код слева тому, что справа. Но задумка была в этом)
Тот гений, что это придумал - просто безумный фанатик)
На моей памяти такого никогда не случалось (я имею ввиду, чтобы в погоне за чистотой, случился ООМ).
Написание кода в функциональном стиле - это хороший подход в очень многих ситуациях, я крайне его рекомендую и всячески пропагандирую. В более или менее приличных языках, имеющих хоть какую-то внятную (не обязательно хорошую) систему типов, компилятор способен оптимизировать оверхед.
Тем не менее функциональные языки мне не нравятся, на них жутко неудобно писать обработку ошибок и просто поразительное количество костылей нужно, если хочется повозиться с состоянием.
Поэтому мой совет - во всём нужно знать меру) Второй совет - используйте языки, позволяющие смешивать императивщину и функциональщину и будете счастливы)
Потому что функция хочет быть чистой. Чистые функции предсказуемы и крайне надёжны. Но от этого эпизодически страдает производительночть.
Потому что это модификация состояния, что не всегда требуется.
Де факто, код справа переписан в функциональном стиле (хотя и не очень удачно), что позволяет получить определенные преимущества, особенно в контексте асинхронной/параллельной обработки пиццы.
Однако чтобы понять суть этих преимуществ, нужно хотя бы поверхностно окунуться в функциональные языки, на этом конкретном примере продемонстрировать их не получится.
Это в корне неверное заблуждение. Если бы это так было, многие из наблюдаемых на рынке явлений бы просто не сработали. Чипированные принтеры, запланированное устаревание во всём, что нас окружает, молоко 0.843 литра и девяток яиц, реклама в телевизорах за 2000$, онлайн регистрация в single player играх, и прочее и прочее.
Люди, массе своей (я не исключение), совсем дурные, и вместо покупки товаров, решающих их проблемы, покупают по принципу, чтобы было "покрасивше" и "подешевле" (ну или подороже, но постатуснее). Люди поразительно плохи в анализе рисков и стоимости владения вещами. Многие даже слов таких не знают, как "стоимость владения".
В общем, ничто не ново под луной, как и мой комментарий
https://2k.livejournal.com/520078.html
Как человек, работавший и с нейронками, и с эллиптической криптографией, могу сказать, что нейронки по ощущениям на 1-2 порядка сложнее)
getOvenTemp(oven) тестировать легче, чем oven.GetTemp().
Но сама по себе функция имеет плохое имя и дизайн, тут согласен)
Врагу не пожелаю писать код в проекте, состоящем из функций в 7-12 строк :D