Предоставить запрошенные банком документы. Возможно, в некоторых случаях какое-нибудь хитро составленное юридическое письмо по правильному адресу может ускорить процесс, но это сильно зависит от страны, банка и точных формулировок.
то кто (и как) потом компенсирует штрафы, убытки и т.д?
По умолчанию никто и никак. Но если есть убытки, то наверняка можно попробовать пойти в суд. Впрочем, если действия банка полностью в легальном поле (а не "массовые блокировки из-за ошибки сотрудника"), то не факт, что можно что-нибудь взыскать.
Надо снять заранее сумму, достаточную на несколько месяцев проживания
Можно ещё держать несколько счетов в разных банках и распределять деньги между ними. Частая конфигурация по слухам: зарплата приходит на счёт в high street ("старом") банке, а регулярные траты - с какого-нибудь необанка с удобным приложением. Тогда при блокировке любого из них можно а) перевести зарплату в другой; б) не остаться без средств.
.. в 2.5 раза быстрее C. «Как же так? Не верю! Что происходит!? В Debian-версии GCC отключены какие-то оптимизации? Надо включить всё.» - вертелось у меня в голове.
Так у вас же исходный код на Scheme перебирает только простые делители до n/2, а не все подряд до n/2, как на остальных языках? Простых чисел до n примерно n/ln(n), у вас алгоритм на Scheme выполняет примерно в 6 раз меньше операций.
Осторожно, LeaseWeb нынче работает только с юридическими лицами. На странице регистрации просят Business Information не просто так, может прилететь Know Your Customer (KYC) запрос с требованием предоставить документы о регистрации юрлица/ИП/фрилансера (без понятия, как это может выглядеть): https://www.leaseweb.com/legal/customer-verification
> Потом, правда, наступает осознание печальной серой действительности, где еда не появляется сама я слишком тупой, так что это всё неконструктивно.
Это вы по каким-то объективным показателям выяснили? Я не знаю ни одной метрики, по которой можно однозначно сделать вывод "у меня не получится X", где X - что-нибудь интеллектуальное.
Предлагаю вам посмотреть, не хотите ли вы начать решать задачу "перестать чувствовать себя тупым" - мне кажется, такое ощущение может сильно мешать что-то делать. Обращаю внимание, что это не то же самое что "стать умным" или "понять темы", это именно "перестать чувствовать себя тупым". Если хочется на что-то заменить, то можно заменить на "чувствовать, что могу разобраться, если захочу".
К тому же наверняка "понимать темы A" и "сделать что-то прикольное в теме A'" можно гнуть так, чтобы подошло под свои возможности.
Похоже, эта функция не может зависеть от одних лишь эмоций, потому что наиболее эффективный способ её максимизировать — забить на фидбек из окружающего мира
Почему же не может? Мне кажется, может, я так и максимизирую. А вот эмоции как раз от фидбэка из окружающего мира очень даже зависят. Когда напрямую, когда косвенно: получилось что-то сделать в окружающем мире, получил ачивку, появились эмоции.
получать однозначный фидбек о корректности своих потуг там существенно проще.
Да, однозначного фидбэка про свои эмоции по умолчанию нет. Да и в среднем не бывает, как я понимаю. Меня такое состояние дел раздражает, но что поделать. В состоянии "раздражает, но я понимаю, что происходит" мне приятнее, чем в "не понимаю, что происходит".
> Это не только интересный, но и очень сложный вопрос.
Безусловно. Но обычно локальный ответ вполне можно получить, если потренироваться, мне кажется. Даже если ответ окажется "хочу лежать на диване, чтобы не надо было ничего делать, никто не беспокоил, а еда сама волшебным образом появлялась".
Это, в принципе, тоже допустимая стратегия, но есть некоторый риск либо потом уронить корону, а это будет очень больно, либо не уронить корону, но просто существенно потерять в возможном качестве жизни (но тут вылезают другие философские вопросы).
Мне кажется, эмоции слишком плохо предсказываются => в принципе не получится придумать себе надёжный план изменения. Будет риск в любом случае. Неприятно, конечно, обычно-то можно много как застраховаться, а тут пока не попробовал - не узнаешь. Я вот сейчас с этой мыслью смиряюсь, она мне кажется реалистичной.
Я бы засыпался уже на этом этапе.
Я тоже. Но тренировка лично мне помогает. Рекурсию-то вы наверняка тоже не мгновенно поняли, или циклы с переменными. А потихоньку, с простых примеров.
Конечно, в начале получится отмапить только что-нибудь совсем очевидное: "текут слёзы => грусть", "хочется ударить => злость". А дальше уже можно в нюансы лезть и обнаружить несколько эмоций в разных пропорциях.
Это ж от момента времени зависит, как минимум.
Да. Но для начала хочется научиться понимать хотя бы в текущем моменте. Чтобы была метрика "что я чувствую", которую потом можно рациональным (или любыми другими) методами оптимизировать. В моменте понимать моментальный эмоции, как ни странно, гораздо проще, чем когда они пройдут. Потому что в моменте можно обратить внимание на кучу признаков, которые просто исчезнут через час. Анализировать эти признаки можно уже потом, конечно, но мониторить надо в моменте.
Насколько эта эмоция адекватна, насколько адекватна моя интерпретация своего состояния, и что с этим делать, как реагировать на эту эмоцию? Я действительно делал фигню, и мне надо сделать выводы? Или к вечеру от работы мозгом истощилась всякая химия в этом мозгу, и надо эти эмоции делить на десять?
А зачем вообще думать, "адекватна ли реакция"? Если поиграть со словами - то чему она должна быть адекватна и почему? Вопрос риторический.
Мне кажется, гораздо интереснее вопрос "что в итоге делать" или хотя бы "что я хочу чтобы происходило". Например, вызывается фейспалм: мне с этим нормально жить или я этого не хочу? Может, достаточно просто будет просто избегать этого? Или я прям ночами не сплю и беспокоюсь, что со мной что-то не так, если мне стыдно из-за старого кода, и чувство никуда не девается? Или просто пугает неопределённость: "нормальный я или нет", а стыд - это просто повод, который стриггерил?
Скажем, пусть адовый стыд вечерами всё-таки мешает и хочется, чтобы не мешал. Может показаться разумным понять, почему стыд всё-таки возникает. Тогда можно пойти понаблюдать, нет ли каких-то предшествующих этому стыду состояний, даже если они исходно кажутся "нелогичными" (эмоции-то всё-таки не всегда логичным образом возникают). И дальше уже с этими состояниями пытаться разбираться.
Куда нажать, чтобы выработать необходимый инструментарий?
Мне лично очень помогал регулярный вопрос: "а что вы чувствуете, а не думаете или считаете?". То есть в начале вообще не въезжал, как отвечать и куда смотреть. Пробовал перебирать названия и примерять на себя: "не, это вообще не грусть, стыд похож, бессилие есть, может, злоба? А как я ощущаю злость? В смысле никак не ощущаю?". Потом и какие-то ощущения начал замечать, и связь между наличием этих ощущений и, например, продуктивностью и возможностью вылезти из листания лент и пойти работать. Потом какие-то паттерны стали проявляться. Теперь можно их заранее предвидеть и понять, например, что на задачу X конкретно мне надо пять минут рабочего времени и шесть часов перед этим выть на стену, потому что у неё есть свойства Y и Z, которые мне почему-то на данный момент мешают. Да, чёткого рационального объяснения нет, всё должно получиться за пять минут, но закономерность хорошо прослеживается.
Расширенная версия: "что хочется сделать/сказать, кому?", "что хочется, чтобы ответили?". Именно с акцентом на вот эту часть, которой почему-то хочется чего-то нерационального.
Вот и инструментарий. Из технических моментов могу порекомендовать вести дневник с концентрацией на своих ощущениях от событий и историй (а не чётком фактчекнутом описании), плюс нарабатывать словарный запас для описания своих ощущений. Например, слова можно выбрать из какого-нибудь круга эмоций. А конструкции, наверное, прочитать в художественной литературе, но я так не пробовал.
Свои можно, постфактум. Если научиться отличать состояния "что-то мне плохо" от "мне весьма хорошо", что может быть на удивление нетривиально. Мне кажется, если хотеть максимизировать именно вот это своё непонятное ощущение "мне хорошо", то придётся научиться его хотя бы измерять. А это точно к рациональности никакого отношения не имеет.
Дальше можно уже рациональность при желании примешивать, строить модели, пользоваться. Например, замечать, что "если я сделал X - дальше мне хорошо" или "если я делаю Y прямо сейчас, то наверняка мне плохо, просто я ещё не заметил". Но проверять модели наверняка в 99% случаев придётся всё ещё иррациональными методами вроде "посмотреть на себя и почувствовать, что происходит", а не расшифровкой ЭЭГ.
Не автор, но частично отвечу: списывания на онлайн-соревнованиях много. А это в том числе и обычные олимпиады из-за COVID-19, например, школьный этап всероссийской олимпиады. Там совершенно чудесные истории про списывание, когда копировали код с номерами строк и это работало: https://codeforces.com/blog/entry/96490
И эти тривиальные части одинаковы у разных людей.
Похожи - да. Но не одинаковы и почти всегда что-нибудь сделать либо "через одно место", либо у кого-то свой хитрый трюк. По моему опыту решения и просмотра глазами решений в задаче на >= 50 строк кода два участника просто не могут получить одинаковое решение (даже с точностью до небольших преобразований). Да даже в задаче на пять строк и две формулы это маловероятно (хоть и случается): кто-то напишет всё в одну строчку, кто-то вынесет все промежуточные вычисления в отдельные переменные, кто-то только часть, а ещё про оператор % вспомнит только половина, а вторая половина напишет `a - a / b * b`.
А тупого списывания на уровне "немного переименовали переменные, поменяли for на while" очень много: его просто сделать и ничего не сломать. Даже что-нибудь в функцию переносить - уже появляется риск сломать.
Это как автомобиль - мотор впереди, багажник сзади, руль на первом ряду сидений. Это я сам придумал, или у меня плагиат?
Но смотрим-то мы при поиске списывания не на "общую идею решения"/"алгоритм", а именно на конкретный код. Провода от задних фар у вас идут сбоку, сверху или обматываются вокруг мотора два раза по часовой и два раза против часовой, "чтобы помехи компенсировать"? Аккумулятор слева от руля в салоне или в багажнике? Обивка на сиденьях одинаковая?
На победу или хотя бы top-100 99% участников (цифра с потолка) в онлайн-соревнованиях не рассчитывают. А заиметь какой-то определённый рейтинг может быть нужно по каким-то причинам. Поэтому читерство цветёт и процветает, вот чудесный пост на Codeforces про то как автор контеста пошёл ловить читеров в их чаты: https://codeforces.com/blog/entry/95415
А вот про списывание на школьном этапе всероссийской олимпиады: https://codeforces.com/blog/entry/96490 . Общего рейтинга нет, но плюшки за проход на региональный этап могут выдавать в зависимости от школы, начиная от "можно не делать домашку".
Шаблоны, но отличается: в первом примере у вас типы аргументов могут не совпадать, а тип возвращаемого значения выводится автоматически по правилам для тернарного оператора. Во втором примере сначала выводится тип аргументов (должен быть один для двух аргументов), а потом он же становится возвращаемым типом.
Мне кажется, что проблема скорее в том, что метод createResource() по своей сигнатуре возвращает некоторый тип T, единственное ограничение на который со стороны самого метода createResource() — он должен реализовывать Resource. Не очень понятно, как такое вообще трактовать.
Например, если считать, что generic-методы — это методы, которые работают для какого-то выбранного T, то есть вопрос: а кто "выбирает" тип T?
Если тип T выбирает сам метод (как сейчас по факту и происходит: для набора параметров возвращается какой-то конкретный тип T), то вызывающий код не имеет права пользоваться никакими знаниями про тип T, кроме того, что он реализует Resource. Такая конструкция в языке Java уже есть: просто ставим возвращаемый тип Resource без всяких extends.
Если тип T выбирается вызывающим кодом, то получается, что метод должен уметь возвращать экземпляр произвольного типа T. Вызывающий код выбрал, какой T ему нужен (например, одновременно реализующий Resource и List<> — такие теоретически существуют), а метод должен этому удовлетворить. Что, разумеется, некоторый абсурд: метод даже не знает, что за T выбрал вызывающий код. Именно поэтому внутри тела метода приходится делать небезопасное преобразование к типу T — компилятор абсолютно правильно не может доказать, что FileResource является каким-то произвольным T.
> Если уж два указателя равны, так они таки равны. И либо оба можно использовать, либо оба нельзя использовать.
Так они же не "равны", они "compare equal", если я правильно понял. То есть верно `p == q`. А то, что их можно при этом одинаково использовать, вроде нигде не написано?
В чистом Haskell, мне кажется, нельзя, там типы нельзя передавать в качестве аргументов функций. Или получаем зависимые типы (dependent types) и какую-нибудь Agda.
from typing import TypeVar
T = TypeVar('T')
def foo(a: T) -> T:
return a
x: int = foo(20) # ok
y: str = foo('x') # ok
z: str = foo(20) # incompatible types in assignment
Автоматический вызов деструкторов может приводить к нежелательным эффектам. Например, есть следующие стандартные аргументы (мне, впрочем, автоматический вызов всё равно нравится больше альтернатив):
За } теперь может скрываться сколь угодно сложная операция, работающее произвольное время и потребляющая произвольное количество ресурсов. Обычно, конечно, небольшое, но может и взорваться. Это же, кстати, стандартный аргумент против перегрузки операторов (с которым тоже можно вести холивары).
В частности, если мы пишем какое-нибудь владеющее дерево/список, то при наивной реализации (через unique_ptr и сгенерированные деструкторы) для его уничтожения требуется стек размера с глубину этого дерева. Можно случайно переполнить стек и даже не догадаться: рекурсии-то мы нигде явно не писали, она скрыта.
Деструкторы провоцируют писать логику для закрытия/сброса буферов именно в деструкторах. Создаётся ложное ощущение, что это безопасно, хотя на самом деле ошибки при закрытии (диск отвалился => не удалось файл записать) тут либо полностью игнорируются, либо приводят к падению приложения. Если же, например, есть явный вызов close(), который надо делать абсолютно всегда (либо под угрозой назальных демонов, либо чего-нибудь попроще), то за его наличием следить проще и привычнее.
Насколько я помню он же фактически заменяет одну последовательность символов другой на каком-то из начальных этапов компиляции.
Ровно этим и хуже (помимо указанного выше). По крайней мере, пока не привыкнуть обходить его острые углы. Вы хотите константу объявить, а не замену символов произвести. Классический пример из олимпиадного программирования:
#define MAXN (int)1e6 + 1
int data[2 * MAXN]; // int data[2 * (int)1e6 + 1];
Хотели объявить массив размера два миллиона и два элемента, а получили массив размера два миллиона и один элемент.
Чинится легко — добавляем вокруг каждой такой макроконстанты круглые скобки.
А дальше выбираем в своём проекте: ничего с этим не делать, забанить #define для констант, разрешить и форсить наличие круглых скобок (только где обязательны или вообще везде — отдельный вопрос) на code review/автоматически/не форсить вообще и разгребать редкие последствия.
Конечно, если много раз писал #define, то скобки наверняка на автомате ставишь. Вот и холивар: кому-то это вообще риском не кажется, просто "надо уметь писать", а кому-то риском кажется. Потом скатываемся в стандартный спор на тему "нужны ли code style", "какой code style использовать"...
А что такое 1+1? Много где при обсуждении турецких квартир видел количество комнат в формате X+Y.
Предоставить запрошенные банком документы. Возможно, в некоторых случаях какое-нибудь хитро составленное юридическое письмо по правильному адресу может ускорить процесс, но это сильно зависит от страны, банка и точных формулировок.
По умолчанию никто и никак. Но если есть убытки, то наверняка можно попробовать пойти в суд. Впрочем, если действия банка полностью в легальном поле (а не "массовые блокировки из-за ошибки сотрудника"), то не факт, что можно что-нибудь взыскать.
Можно ещё держать несколько счетов в разных банках и распределять деньги между ними. Частая конфигурация по слухам: зарплата приходит на счёт в high street ("старом") банке, а регулярные траты - с какого-нибудь необанка с удобным приложением. Тогда при блокировке любого из них можно а) перевести зарплату в другой; б) не остаться без средств.
Так у вас же исходный код на Scheme перебирает только простые делители до n/2, а не все подряд до n/2, как на остальных языках? Простых чисел до n примерно n/ln(n), у вас алгоритм на Scheme выполняет примерно в 6 раз меньше операций.
Потом, конечно, алгоритм уже везде одинаковый.
Осторожно, LeaseWeb нынче работает только с юридическими лицами. На странице регистрации просят Business Information не просто так, может прилететь Know Your Customer (KYC) запрос с требованием предоставить документы о регистрации юрлица/ИП/фрилансера (без понятия, как это может выглядеть): https://www.leaseweb.com/legal/customer-verification
К уже существующим клиентам вроде тоже относится.
> Потом, правда, наступает осознание печальной серой действительности, где
еда не появляется самая слишком тупой, так что это всё неконструктивно.Это вы по каким-то объективным показателям выяснили? Я не знаю ни одной метрики, по которой можно однозначно сделать вывод "у меня не получится X", где X - что-нибудь интеллектуальное.
Предлагаю вам посмотреть, не хотите ли вы начать решать задачу "перестать чувствовать себя тупым" - мне кажется, такое ощущение может сильно мешать что-то делать. Обращаю внимание, что это не то же самое что "стать умным" или "понять темы", это именно "перестать чувствовать себя тупым". Если хочется на что-то заменить, то можно заменить на "чувствовать, что могу разобраться, если захочу".
К тому же наверняка "понимать темы A" и "сделать что-то прикольное в теме A'" можно гнуть так, чтобы подошло под свои возможности.
Почему же не может? Мне кажется, может, я так и максимизирую. А вот эмоции как раз от фидбэка из окружающего мира очень даже зависят. Когда напрямую, когда косвенно: получилось что-то сделать в окружающем мире, получил ачивку, появились эмоции.
Да, однозначного фидбэка про свои эмоции по умолчанию нет. Да и в среднем не бывает, как я понимаю. Меня такое состояние дел раздражает, но что поделать. В состоянии "раздражает, но я понимаю, что происходит" мне приятнее, чем в "не понимаю, что происходит".
> Это не только интересный, но и очень сложный вопрос.
Безусловно. Но обычно локальный ответ вполне можно получить, если потренироваться, мне кажется. Даже если ответ окажется "хочу лежать на диване, чтобы не надо было ничего делать, никто не беспокоил, а еда сама волшебным образом появлялась".
Мне кажется, эмоции слишком плохо предсказываются => в принципе не получится придумать себе надёжный план изменения. Будет риск в любом случае. Неприятно, конечно, обычно-то можно много как застраховаться, а тут пока не попробовал - не узнаешь. Я вот сейчас с этой мыслью смиряюсь, она мне кажется реалистичной.
Я тоже. Но тренировка лично мне помогает. Рекурсию-то вы наверняка тоже не мгновенно поняли, или циклы с переменными. А потихоньку, с простых примеров.
Конечно, в начале получится отмапить только что-нибудь совсем очевидное: "текут слёзы => грусть", "хочется ударить => злость". А дальше уже можно в нюансы лезть и обнаружить несколько эмоций в разных пропорциях.
Да. Но для начала хочется научиться понимать хотя бы в текущем моменте. Чтобы была метрика "что я чувствую", которую потом можно рациональным (или любыми другими) методами оптимизировать. В моменте понимать моментальный эмоции, как ни странно, гораздо проще, чем когда они пройдут. Потому что в моменте можно обратить внимание на кучу признаков, которые просто исчезнут через час. Анализировать эти признаки можно уже потом, конечно, но мониторить надо в моменте.
А зачем вообще думать, "адекватна ли реакция"? Если поиграть со словами - то чему она должна быть адекватна и почему? Вопрос риторический.
Мне кажется, гораздо интереснее вопрос "что в итоге делать" или хотя бы "что я хочу чтобы происходило". Например, вызывается фейспалм: мне с этим нормально жить или я этого не хочу? Может, достаточно просто будет просто избегать этого? Или я прям ночами не сплю и беспокоюсь, что со мной что-то не так, если мне стыдно из-за старого кода, и чувство никуда не девается? Или просто пугает неопределённость: "нормальный я или нет", а стыд - это просто повод, который стриггерил?
Скажем, пусть адовый стыд вечерами всё-таки мешает и хочется, чтобы не мешал. Может показаться разумным понять, почему стыд всё-таки возникает. Тогда можно пойти понаблюдать, нет ли каких-то предшествующих этому стыду состояний, даже если они исходно кажутся "нелогичными" (эмоции-то всё-таки не всегда логичным образом возникают). И дальше уже с этими состояниями пытаться разбираться.
Мне лично очень помогал регулярный вопрос: "а что вы чувствуете, а не думаете или считаете?". То есть в начале вообще не въезжал, как отвечать и куда смотреть. Пробовал перебирать названия и примерять на себя: "не, это вообще не грусть, стыд похож, бессилие есть, может, злоба? А как я ощущаю злость? В смысле никак не ощущаю?". Потом и какие-то ощущения начал замечать, и связь между наличием этих ощущений и, например, продуктивностью и возможностью вылезти из листания лент и пойти работать. Потом какие-то паттерны стали проявляться. Теперь можно их заранее предвидеть и понять, например, что на задачу X конкретно мне надо пять минут рабочего времени и шесть часов перед этим выть на стену, потому что у неё есть свойства Y и Z, которые мне почему-то на данный момент мешают. Да, чёткого рационального объяснения нет, всё должно получиться за пять минут, но закономерность хорошо прослеживается.
Расширенная версия: "что хочется сделать/сказать, кому?", "что хочется, чтобы ответили?". Именно с акцентом на вот эту часть, которой почему-то хочется чего-то нерационального.
Вот и инструментарий. Из технических моментов могу порекомендовать вести дневник с концентрацией на своих ощущениях от событий и историй (а не чётком фактчекнутом описании), плюс нарабатывать словарный запас для описания своих ощущений. Например, слова можно выбрать из какого-нибудь круга эмоций. А конструкции, наверное, прочитать в художественной литературе, но я так не пробовал.
Свои можно, постфактум. Если научиться отличать состояния "что-то мне плохо" от "мне весьма хорошо", что может быть на удивление нетривиально. Мне кажется, если хотеть максимизировать именно вот это своё непонятное ощущение "мне хорошо", то придётся научиться его хотя бы измерять. А это точно к рациональности никакого отношения не имеет.
Дальше можно уже рациональность при желании примешивать, строить модели, пользоваться. Например, замечать, что "если я сделал X - дальше мне хорошо" или "если я делаю Y прямо сейчас, то наверняка мне плохо, просто я ещё не заметил". Но проверять модели наверняка в 99% случаев придётся всё ещё иррациональными методами вроде "посмотреть на себя и почувствовать, что происходит", а не расшифровкой ЭЭГ.
Не автор, но частично отвечу: списывания на онлайн-соревнованиях много. А это в том числе и обычные олимпиады из-за COVID-19, например, школьный этап всероссийской олимпиады. Там совершенно чудесные истории про списывание, когда копировали код с номерами строк и это работало: https://codeforces.com/blog/entry/96490
Похожи - да. Но не одинаковы и почти всегда что-нибудь сделать либо "через одно место", либо у кого-то свой хитрый трюк. По моему опыту решения и просмотра глазами решений в задаче на >= 50 строк кода два участника просто не могут получить одинаковое решение (даже с точностью до небольших преобразований). Да даже в задаче на пять строк и две формулы это маловероятно (хоть и случается): кто-то напишет всё в одну строчку, кто-то вынесет все промежуточные вычисления в отдельные переменные, кто-то только часть, а ещё про оператор
%вспомнит только половина, а вторая половина напишет `a - a / b * b`.А тупого списывания на уровне "немного переименовали переменные, поменяли for на while" очень много: его просто сделать и ничего не сломать. Даже что-нибудь в функцию переносить - уже появляется риск сломать.
Но смотрим-то мы при поиске списывания не на "общую идею решения"/"алгоритм", а именно на конкретный код. Провода от задних фар у вас идут сбоку, сверху или обматываются вокруг мотора два раза по часовой и два раза против часовой, "чтобы помехи компенсировать"? Аккумулятор слева от руля в салоне или в багажнике? Обивка на сиденьях одинаковая?
На победу или хотя бы top-100 99% участников (цифра с потолка) в онлайн-соревнованиях не рассчитывают. А заиметь какой-то определённый рейтинг может быть нужно по каким-то причинам. Поэтому читерство цветёт и процветает, вот чудесный пост на Codeforces про то как автор контеста пошёл ловить читеров в их чаты: https://codeforces.com/blog/entry/95415
А вот про списывание на школьном этапе всероссийской олимпиады: https://codeforces.com/blog/entry/96490 . Общего рейтинга нет, но плюшки за проход на региональный этап могут выдавать в зависимости от школы, начиная от "можно не делать домашку".
Любопытно, что даже на русском не очень много материалов с описанием произошедшего: пост на VC, статья на РБК, пост на Хабре, да и вроде всё.
А вот на английском вообще ни одного материала не вижу. У кого-нибудь получилось найти?
Шаблоны, но отличается: в первом примере у вас типы аргументов могут не совпадать, а тип возвращаемого значения выводится автоматически по правилам для тернарного оператора. Во втором примере сначала выводится тип аргументов (должен быть один для двух аргументов), а потом он же становится возвращаемым типом.
Считайте, что C++ - надмножество Си и писать надо почти так же.
Следуйте рекомендациям с https://twitter.com/affectivecpp , например:
Так как UB используется компиляторами для оптимизаций, убедитесь, что в вашем коде как можно больше UB, чтобы программа быстрее работала.
Мне кажется, что проблема скорее в том, что метод
createResource()по своей сигнатуре возвращает некоторый типT, единственное ограничение на который со стороны самого методаcreateResource()— он должен реализовыватьResource. Не очень понятно, как такое вообще трактовать.Например, если считать, что generic-методы — это методы, которые работают для какого-то выбранного
T, то есть вопрос: а кто "выбирает" типT?Если тип
Tвыбирает сам метод (как сейчас по факту и происходит: для набора параметров возвращается какой-то конкретный типT), то вызывающий код не имеет права пользоваться никакими знаниями про типT, кроме того, что он реализуетResource. Такая конструкция в языке Java уже есть: просто ставим возвращаемый типResourceбез всякихextends.Если тип
Tвыбирается вызывающим кодом, то получается, что метод должен уметь возвращать экземпляр произвольного типаT. Вызывающий код выбрал, какойTему нужен (например, одновременно реализующийResourceиList<>— такие теоретически существуют), а метод должен этому удовлетворить. Что, разумеется, некоторый абсурд: метод даже не знает, что заTвыбрал вызывающий код. Именно поэтому внутри тела метода приходится делать небезопасное преобразование к типуT— компилятор абсолютно правильно не может доказать, чтоFileResourceявляется каким-то произвольнымT.> Если уж два указателя равны, так они таки равны. И либо оба можно использовать, либо оба нельзя использовать.
Так они же не "равны", они "compare equal", если я правильно понял. То есть верно `p == q`. А то, что их можно при этом одинаково использовать, вроде нигде не написано?
В чистом Haskell, мне кажется, нельзя, там типы нельзя передавать в качестве аргументов функций. Или получаем зависимые типы (dependent types) и какую-нибудь Agda.
Кажется, должны помочь type variables/generics? Например:
Автоматический вызов деструкторов может приводить к нежелательным эффектам. Например, есть следующие стандартные аргументы (мне, впрочем, автоматический вызов всё равно нравится больше альтернатив):
За
}теперь может скрываться сколь угодно сложная операция, работающее произвольное время и потребляющая произвольное количество ресурсов. Обычно, конечно, небольшое, но может и взорваться. Это же, кстати, стандартный аргумент против перегрузки операторов (с которым тоже можно вести холивары).В частности, если мы пишем какое-нибудь владеющее дерево/список, то при наивной реализации (через
unique_ptrи сгенерированные деструкторы) для его уничтожения требуется стек размера с глубину этого дерева. Можно случайно переполнить стек и даже не догадаться: рекурсии-то мы нигде явно не писали, она скрыта.Деструкторы провоцируют писать логику для закрытия/сброса буферов именно в деструкторах. Создаётся ложное ощущение, что это безопасно, хотя на самом деле ошибки при закрытии (диск отвалился => не удалось файл записать) тут либо полностью игнорируются, либо приводят к падению приложения. Если же, например, есть явный вызов
close(), который надо делать абсолютно всегда (либо под угрозой назальных демонов, либо чего-нибудь попроще), то за его наличием следить проще и привычнее.А
gotoв нужную точку в хвосте функции для освобождения не помогает, как в ядре Linux часто делают? Или ресурсы часто не так линейно вкладываются?Ровно этим и хуже (помимо указанного выше). По крайней мере, пока не привыкнуть обходить его острые углы. Вы хотите константу объявить, а не замену символов произвести. Классический пример из олимпиадного программирования:
Хотели объявить массив размера два миллиона и два элемента, а получили массив размера два миллиона и один элемент.
Чинится легко — добавляем вокруг каждой такой макроконстанты круглые скобки.
А дальше выбираем в своём проекте: ничего с этим не делать, забанить
#defineдля констант, разрешить и форсить наличие круглых скобок (только где обязательны или вообще везде — отдельный вопрос) на code review/автоматически/не форсить вообще и разгребать редкие последствия.Конечно, если много раз писал
#define, то скобки наверняка на автомате ставишь. Вот и холивар: кому-то это вообще риском не кажется, просто "надо уметь писать", а кому-то риском кажется. Потом скатываемся в стандартный спор на тему "нужны ли code style", "какой code style использовать"...