В оригинале то же самое: The template by no means guarantees any operations will actually be atomic though. И следующая фраза объясняет, в каком случае это может произойти: если аппаратной поддержки не хватает, то идёт откат на mutex, и операции хотя и остаются thread-safe, но уже не atomic.
Не пробовали сделать trie с выделением памяти под узлы из фиксированного пула, а не при помощи системного malloc? boost::object_pool или вообще вручную, создав большой массив узлов и используя индекс в нём вместо указателей.
"напишите нам такую систему чтобы наш саппорт мог посмотреть пароль пользователя и зайти под его кредами от его лица."
"Вы реально доверяете своим саппортам, набраным из трехкопеечных студентов по объявлению, пользовательские пароли? Тех самых пользователей, половина которых для вас и своего онлайн-банка один пароль использует?" Ну серьёзно, если заказчик такого хочет - от него лучше убежать побыстрее и подальше. На следующей неделе он предложит закладки в парке раскладывать.
Но отсутствует самый полезный совет: чтобы не лезть во все эти дебри, для обзаведения детьми лучше использовать подходящую инкарнацию subprocess (Python, C++, Rust и т.д.).
Base обычно поднять нереально. А вот signup bonus и стоки вполне торгуются, можно накинуть.
Кстати, я не знаю как оно сейчас и в Европу, но в прошлом десятилетии при переезде в США была возможность взять вместо билетов/перевозки вещей/временного жилья/местных консультантов просто деньги. Если ехать одному и есть какие-то знакомые на месте, которые помогут сориентироваться, то выходит заметно выгоднее.
У автора достаточно единственной ошибки в коде восстановления, и при любой длине кода сообщение будет повреждено.
Это не так. Коды коррекции ошибок позволяют восстановить сообщение после порчи какого-то символов в любом месте закодированного сообщения, неважно попадут они в данные или в сам код коррекции. Иначе от них было бы мало пользы: редко когда у нас есть ненадёжный канал для данных, и при этом надёжный канал для кодов коррекции.
Примерную программу обучения уж точно можно было изучить до поступления.
Изучить можно, но какой смысл? Выбрать нельзя и не из чего, жри что дают. Максимум можно выбрать ВУЗ с примерно одними и теми же философиями, политологиями и химиями в программе. Техникум же с приличным образованием вряд ли удастся найти, качества и в российских ВУЗах-то ещё поискать.
В США, например, большая часть предметов набирается студентами по своем усмотрению. Есть граф зависимостей, есть какие-то обязательные требования, дальше решай сам. При этом даже специализация выбирается ближе к третьему курсу, когда уже хоть что-то понимаешь.
Дело не в том, кого готовят, а в том, какие предметы при этом будут изучаться. Думается, в той же Бауманке сейчас всем преподают какие-нибудь философию и историю.
Я как раз об этом: "мы готовим всесторонне развитых учёных, а не каких-то там рабочих муравьёв для индустрии", а потом искреннее удивление, что и выпускники, и индустрия их недолюбливают. Будет интересно при случае спросить кого-нибудь из профессоров MIT, что про такой тезис подумают тамошние преподаватели. Из того что я лично наблюдал, там специально привлекают людей из индустрии проводить студентам code review, чтобы те заранее привыкали к эциху с гвоздями. Ожидается, что большая часть выпускников к станку пойдёт, а не науку двигать будет.
PS. Я попытался найти текущую программу обучения на ИУ7 в Бауманке, хоть посмотреть насколько она изменилась за 25 лет. Не смог. Нашёл только расписание, со знакомыми фамилиями по многим предметам, храни господи нынешних студентов. И сайт iu.bmstu.ru, ссылка с которого на iu7.bmstu.ru выдаёт 502 от nginx. Факультет айтишников, кафедра программистов, товар лицом :-/
Речь как раз шла о том, что Вам нужен был не ВУЗ. Всё-таки высшее образование предполагает определённый кругозор, фундаментальную подготовку и теоретизированность. Если человек хочет исключительно освоить профессию, то он идёт в техникум.
Это достаточно типичное мнение в России: ВУЗ-де готовит учёных, а инженеры пусть учатся в техникумах. После указания на институт, готовящий инженеров по системам водоснабжения и водоотведения, или апгрейдят до "университет готовит учёных", или предлагают разжаловать ВУЗ в техникумы. После указания на Бауманку её тоже обычно предлагают разжаловать обратно в "училище".
Я бы назвал это зазнайством. "Ты чё, пёс, я учёный"
В России скорее всего легален или был легален: аналогичный договор был между Яндексом и Microsoft лет десять назад.
В США это вполне может попасть под антимонопольные законы, с крайне неприятными последствиями. И это помимо того, что надо иметь изрядное ЧСВ, чтобы так поступать: если есть выбор между компанией с такими соглашениями, и примерно такой же без соглашений, то работа во второй гораздо привлекательнее.
А в вашей компании нет правила, что даже если кандидат полностью провалился, то у него всё равно надо оставить о компании, интервьюере и процессе хорошее впечатление? Потому что он может через несколько лет подкачаться, а прямо сегодня у него могут быть толковые друзья, которых не стоит отпугивать.
Компанию с несколькими инженерами можно собрать из уникальных, талантливых и необычных людей. Компанию с несколькими тысячами инженеров - нельзя. Нужна стандартизация.
Абстракции неплохие, но до предела ещё далеко. В математике множество с ассоциативной бинарной операцией и нейтральным элементом называется моноид, и если уж абстрагироваться, то надо написать этот интерфейс. Реализовать его смогут и Int (разными способами для сложения и умножения, так что в Java придётся какие-то дополнительные обёртки вводить), и большая часть контейнеров из стандартной библиотеки, например List, HashMap, Set.
Более того, моноид должен быть унаследован от полугруппы, в которой есть только операция, но необязателен нейтральный элемент. Если кто-нибудь напишет класс для непустых списков (всегда имеющих хотя бы один элемент), то он будет реализовывать полугруппу, а моноид не сможет.
Для моноида и полугруппы можно будет написать свои функции свёртки, отличающиеся наличием стартового элемента: моноиду он не нужен, возьмём нейтральный. А чтобы было интереснее, на вход они будут принимать не список, а что-нибудь с интерфейсом Foldable. В конце концов, почему бы дерево не свернуть или хэш-таблицу: нам же только перебор элементов нужен, неважно как он внутри устроен.
А любители Haskell знают, откуда я всё это содрал :)
Все эти проблемы у автора потому что он пытается писать библиотеку поддержки корутин самостоятельно. Разумеется это сложно, попробуйте в том же питоне написать asyncio самостоятельно или даже понять что там написано. Если же взять готовую библиотеку, то становится гораздо легче и писать, и разбираться.
Какие-то несёт. Как минимум на аллокации invocation record (того, что у корутин вместо стека) и переключения туда-сюда. Многое зависит от того, насколько хорошо написана библиотека поддержки корутин.
Но корутины не будут заменять обычный линейный код, это бессмысленно. Они будут заменять или FSM, или код с мешком коллбэков, или futures. Тут есть неплохая вероятность получить ускорение за счёт более внятного кода. Если сравнивать folly::Future и корутины оттуда же, то мы получили небольшое ускорение за счёт того, что future всегда запускается асинхронно, а корутина может выполниться синхронно если проскочить мимо всех co_await.
Что-то я очень сомневаюсь в ежедневном посещении StackOverflow среднестатистическим IT-шником. Ну что там делать-то каждый день, продираться через сотни вопросов, из которых 90% новичковые, а 9% непонятные? Надоедает быстро.
Design pattern это библиотека, которую невозможно написать, потому что язык не позволяет (c) не_мой
Это проблема не перевода, а оригинала. Автор оригинала явно использует atomic как синоним lock-free, и это достаточно популярное толкование.
В оригинале то же самое: The template by no means guarantees any operations will actually be atomic though. И следующая фраза объясняет, в каком случае это может произойти: если аппаратной поддержки не хватает, то идёт откат на mutex, и операции хотя и остаются thread-safe, но уже не atomic.
Не пробовали сделать trie с выделением памяти под узлы из фиксированного пула, а не при помощи системного malloc?
boost::object_pool
или вообще вручную, создав большой массив узлов и используя индекс в нём вместо указателей."Вы реально доверяете своим саппортам, набраным из трехкопеечных студентов по объявлению, пользовательские пароли? Тех самых пользователей, половина которых для вас и своего онлайн-банка один пароль использует?" Ну серьёзно, если заказчик такого хочет - от него лучше убежать побыстрее и подальше. На следующей неделе он предложит закладки в парке раскладывать.
Под этот хэш подходит слишком много паролей, чтобы перебирать их все на хабре.
Впечатляюще, про некоторые подробности я не знал.
Но отсутствует самый полезный совет: чтобы не лезть во все эти дебри, для обзаведения детьми лучше использовать подходящую инкарнацию subprocess (Python, C++, Rust и т.д.).
Я бы смог представить себе фразу типа "'этот мОлодо-зЕленый человечек вообще ничего не понимает".
Base обычно поднять нереально. А вот signup bonus и стоки вполне торгуются, можно накинуть.
Кстати, я не знаю как оно сейчас и в Европу, но в прошлом десятилетии при переезде в США была возможность взять вместо билетов/перевозки вещей/временного жилья/местных консультантов просто деньги. Если ехать одному и есть какие-то знакомые на месте, которые помогут сориентироваться, то выходит заметно выгоднее.
Это не так. Коды коррекции ошибок позволяют восстановить сообщение после порчи какого-то символов в любом месте закодированного сообщения, неважно попадут они в данные или в сам код коррекции. Иначе от них было бы мало пользы: редко когда у нас есть ненадёжный канал для данных, и при этом надёжный канал для кодов коррекции.
Изучить можно, но какой смысл? Выбрать нельзя и не из чего, жри что дают. Максимум можно выбрать ВУЗ с примерно одними и теми же философиями, политологиями и химиями в программе. Техникум же с приличным образованием вряд ли удастся найти, качества и в российских ВУЗах-то ещё поискать.
В США, например, большая часть предметов набирается студентами по своем усмотрению. Есть граф зависимостей, есть какие-то обязательные требования, дальше решай сам. При этом даже специализация выбирается ближе к третьему курсу, когда уже хоть что-то понимаешь.
Я как раз об этом: "мы готовим всесторонне развитых учёных, а не каких-то там рабочих муравьёв для индустрии", а потом искреннее удивление, что и выпускники, и индустрия их недолюбливают. Будет интересно при случае спросить кого-нибудь из профессоров MIT, что про такой тезис подумают тамошние преподаватели. Из того что я лично наблюдал, там специально привлекают людей из индустрии проводить студентам code review, чтобы те заранее привыкали к эциху с гвоздями. Ожидается, что большая часть выпускников к станку пойдёт, а не науку двигать будет.
PS. Я попытался найти текущую программу обучения на ИУ7 в Бауманке, хоть посмотреть насколько она изменилась за 25 лет. Не смог. Нашёл только расписание, со знакомыми фамилиями по многим предметам, храни господи нынешних студентов. И сайт iu.bmstu.ru, ссылка с которого на iu7.bmstu.ru выдаёт 502 от nginx. Факультет айтишников, кафедра программистов, товар лицом :-/
Это достаточно типичное мнение в России: ВУЗ-де готовит учёных, а инженеры пусть учатся в техникумах. После указания на институт, готовящий инженеров по системам водоснабжения и водоотведения, или апгрейдят до "университет готовит учёных", или предлагают разжаловать ВУЗ в техникумы. После указания на Бауманку её тоже обычно предлагают разжаловать обратно в "училище".
Я бы назвал это зазнайством. "Ты чё, пёс, я учёный"
В России скорее всего легален или был легален: аналогичный договор был между Яндексом и Microsoft лет десять назад.
В США это вполне может попасть под антимонопольные законы, с крайне неприятными последствиями. И это помимо того, что надо иметь изрядное ЧСВ, чтобы так поступать: если есть выбор между компанией с такими соглашениями, и примерно такой же без соглашений, то работа во второй гораздо привлекательнее.
Кто не добавлял к if (cond) goto fail; ещё одну строчку, забыв при этом поставить скобки, тот ещё добавит.
(почему goto: https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/)
А в вашей компании нет правила, что даже если кандидат полностью провалился, то у него всё равно надо оставить о компании, интервьюере и процессе хорошее впечатление? Потому что он может через несколько лет подкачаться, а прямо сегодня у него могут быть толковые друзья, которых не стоит отпугивать.
Компанию с несколькими инженерами можно собрать из уникальных, талантливых и необычных людей. Компанию с несколькими тысячами инженеров - нельзя. Нужна стандартизация.
Абстракции неплохие, но до предела ещё далеко. В математике множество с ассоциативной бинарной операцией и нейтральным элементом называется моноид, и если уж абстрагироваться, то надо написать этот интерфейс. Реализовать его смогут и Int (разными способами для сложения и умножения, так что в Java придётся какие-то дополнительные обёртки вводить), и большая часть контейнеров из стандартной библиотеки, например List, HashMap, Set.
Более того, моноид должен быть унаследован от полугруппы, в которой есть только операция, но необязателен нейтральный элемент. Если кто-нибудь напишет класс для непустых списков (всегда имеющих хотя бы один элемент), то он будет реализовывать полугруппу, а моноид не сможет.
Для моноида и полугруппы можно будет написать свои функции свёртки, отличающиеся наличием стартового элемента: моноиду он не нужен, возьмём нейтральный. А чтобы было интереснее, на вход они будут принимать не список, а что-нибудь с интерфейсом Foldable. В конце концов, почему бы дерево не свернуть или хэш-таблицу: нам же только перебор элементов нужен, неважно как он внутри устроен.
А любители Haskell знают, откуда я всё это содрал :)
Все эти проблемы у автора потому что он пытается писать библиотеку поддержки корутин самостоятельно. Разумеется это сложно, попробуйте в том же питоне написать asyncio самостоятельно или даже понять что там написано. Если же взять готовую библиотеку, то становится гораздо легче и писать, и разбираться.
Какие-то несёт. Как минимум на аллокации invocation record (того, что у корутин вместо стека) и переключения туда-сюда. Многое зависит от того, насколько хорошо написана библиотека поддержки корутин.
Но корутины не будут заменять обычный линейный код, это бессмысленно. Они будут заменять или FSM, или код с мешком коллбэков, или futures. Тут есть неплохая вероятность получить ускорение за счёт более внятного кода. Если сравнивать
folly::Future
и корутины оттуда же, то мы получили небольшое ускорение за счёт того, что future всегда запускается асинхронно, а корутина может выполниться синхронно если проскочить мимо всех co_await.