Я рекомендую вот эту статью глянуть, т.к. там автор задался той же идеей - реализацией гошной хешмапы через дженерики. И уперся в тот факт, что Go'шный хешер не экспортирован для работы с неизвестными типами. Экспортировать можно через unsafe, мапу, и каст к нужному типу. Возможно имеет смысл попробовать с стандартным хешером который использует AES, вдруг будет быстрее?
Каким образом умение поиска по коду поможет найти место возникновения ошибки во внешней библиотеке?
А чем отличается поиск кода в своих проектах и поиска кода в чужих? В Go все довольно просто — ищите где создается ошибка с нужным вам текстом и как она прокидывается.
прикрепить к ошибке несколько байт дебаг-символов — дорогая операция?? с чего вы это взяли? Где бенчмарки?
Стектрейс — единственный способ точно установить где именно возникла ошибка.
Вы, простите, поиском по коду пользоваться умеете?
Стектрейс есть в любом уважающем себя рантайме в исключениях.
Убирая тот факт, что захват фрейма не самая дешевая операция (хотя может быть и дешевой, если компилятор языка умеет преобразовывать вызовы в константные выражения), то развертка стека (в случае исключения) операция по определению недешевая.
В Go стек динамического размера, что делает исключения еще дороже. Вы предлагаете пожертвовать скоростью ради сомнительной выгоды.
нет стектрейса — это грёбаный стыд и феерический косяк разработчиков голанга
В первых версиях errors стектрейс был, но его убрали как раз по той самой причине что а) стектрейс на каждую ошибку это довольно дорого б) непонятно как настроить инспекцию, ведь далеко не всегда нужен стектрейс, а достаточно вывода самой ошибки. Можете глянуть /x/xerrors — там стектрейс до сих пор остался.
Стандартными средствами — нет, так как агрегирование (когда функция одновременно возвращает множество ошибок) хоть и обсуждалось, но придти к единому решению пока не смогли. Но можно быстро накидать самому, например. Однако и у этой реализации есть минусы/особенности — так, например, если функция возвращает две ошибки одного типа (например оба os.Open вернули *os.PathError) то errors.As/Is позволит посмотреть только одну из них. Способы решения для этой проблемы то-же есть — либо добавить к типу multiError итератор, либо завести собственный тип реализующий ошибку, для функции someFunc у которого тонко настроить As/Is. Если хотите, могу через личку уточнить как сделать оба подхода.
Вы, простите, пейперы наискосок читаете? Или комитет, за которым последнее слово, у вас просто так, для красоты?
Я вам пример приведу из пейпера
This work is the result of collaboration of researchers in industry and academia, including CppDes Microsoft
group and the WG21 study group SG1. We wish to thank people who made valuable contributions within
and outside these groups, including Jens Maurer, Artur Laksberg, Chandler Carruth, Gabriel Dos Reis, Deon
Brewis, Jonathan Caves, James McNellis, Stephan T. Lavavej, Herb Sutter, Pablo Halpern, Robert Schumacher,
Michael Wong, Niklas Gustafsson, Nick Maliwacki, Vladimir Petter, Shahms King, Slava Kuznetsov,
Tongari J, Lawrence Crowl, and many others not named here who contributed to the discussion
Все эти люди безусловно работают в Microsoft и\или получают оттуда деньги. А как иначе?
Структуру комитета и глав его подразделений вы можете посмотреть вот здесь. Обратите внимание на главу SG1.
Есть понятие formal proposal — без полного обоснования нового функционала и его реализации и концептов, с вами общаться никто не будет. Сами же эти бумаги после внедрения в стандарт становятся собственностью ISO C++. О каких разработках вы говорите, я не понимаю.
Поведение плюсов стандартизировано. Вне зависимости от компилятора. Все что не входит в стандарт и не является частью TS не поощряется в использовании, в любом виде.
Вы пока не привели ни одного аргумента кроме
await был сделан для WinRT. WinRT плохой, следовательно и await плохой.
У вас есть опыт работы с Boost.Coroutine? Ограничения которые он накладывает? Спецификации того как он работает? И тот факт, что вариант Кристофера не решает проблему с блокировкой не подготовленных методов?
vector тоже плохой — это не повод убивать шаблонный класс vector как сущность.
Для каких целей? Managed С++ никогда не предлагался на рассмотрение, это extension который работает под свою платформу. У GCC и Clang такие тоже есть. И?
await это стандарт работы с асинхронным кодом. А теперь объясните где вы видите связь между стандартом и расширением? Или это ненависть к MS?
Там битва настоящая идет, между конкурирующими пейперами. Комитет чуть не "подрался" после очередного заседания по концептам. Очень накаленная беседа была.
Одни сторонники "лучшее враг хорошего" включая Бьерна. Другие постоянно ищут способ, как сделать плюсы еще более мощными (читай сложными) для реализации. Больше функционала! И ведь хорошие идеи все, да только сложность языка растет все выше и выше(куда уже еще то?!).
std::for_each сейчас лучше заменить Range-based for loop — компилятор его порой намного лучше понимает. Со вторым примером соглашусь, но я думаю целесообразнее было бы на вход уже генератор подавать — если мы говорим про асинхронность.
Вариант с переключением контекста как предлагает Кристофер потребует O(n) доп памяти. Причем неявно. Плохо согласуется с zero cost abstractions.
Хорошее обсуждение вот тут. Если вкратце это предположительный вариант (по мнению одного из членов комитета) о том, что войдет в C++17. Интересно, что про корутины там не слова.
Сейчас вообще интересный момент — часть людей считает, что многие из бумаг не готовы. Особенно неприятная ситуация выходит с Concepts TS — но я надеюсь, что комитету удастся наконец принять решение в пользу принятия этого предложения. Больше 10 лет обсуждения — надоело уже.
Честно говоря читая пэйпер, у меня возник вопрос — а ваша реализация то где? Во вторых, я соглашусь с тем, что текущий вариант обладает недостатками — но вариант с переключением контекста вручную (yield\longjmp) мало того, что создаст дорогу для кода который будет провоцировать баги, так еще и усложнит работу создателей компилятора, который будут вынуждены писать код под каждую платформу. Лично я против включения корутин в виде явного переключения контекста, в стандарт. Он не решает проблем, которые высказаны выше, а еще и своих добавляет.
Передачу управления нужно делать явно — собственно этим сейчас и занимается Boost ASIO внутри с помощью асинхронных примитивов ОС. Вроде есть ASIO на корутинах, но я не смотрел.
STL 2 скорее всего, все равно будет — range v3 Эрика Найбера и концепты. Однако я не понимаю связи между алгоритмами и сопрограммами. Возможность параллелизации алгоритмов скорее Parallelism TS и Concurrency TS. Которые планируются пока скорее к C++20.
Я рекомендую вот эту статью глянуть, т.к. там автор задался той же идеей - реализацией гошной хешмапы через дженерики. И уперся в тот факт, что Go'шный хешер не экспортирован для работы с неизвестными типами. Экспортировать можно через unsafe, мапу, и каст к нужному типу. Возможно имеет смысл попробовать с стандартным хешером который использует AES, вдруг будет быстрее?
Ну вообще комментатор выше неправ. Такое поведение будет работать только если возврат именованный.
Обычный: https://play.golang.org/p/VwbT6W1FxRf
Именованный: https://play.golang.org/p/7nOVAje_FNH
А чем отличается поиск кода в своих проектах и поиска кода в чужих? В Go все довольно просто — ищите где создается ошибка с нужным вам текстом и как она прокидывается.
https://play.golang.org/p/xo3FBPqm1AK 600 ns против 20 ns.
Почитайте про stack unwinding и как работает panic/recover/defer и что конкретно за вас делает рантайм, чтоб у вас не утекали ресурсы.
Вы, простите, поиском по коду пользоваться умеете?
Убирая тот факт, что захват фрейма не самая дешевая операция (хотя может быть и дешевой, если компилятор языка умеет преобразовывать вызовы в константные выражения), то развертка стека (в случае исключения) операция по определению недешевая.
В Go стек динамического размера, что делает исключения еще дороже. Вы предлагаете пожертвовать скоростью ради сомнительной выгоды.
В первых версиях errors стектрейс был, но его убрали как раз по той самой причине что а) стектрейс на каждую ошибку это довольно дорого б) непонятно как настроить инспекцию, ведь далеко не всегда нужен стектрейс, а достаточно вывода самой ошибки. Можете глянуть /x/xerrors — там стектрейс до сих пор остался.
Хотя в оригинале имелось введу про умеренность — не стоит выжимать из вещей их предел. Соблюдай баланс. Дао Дэ Цзин полон таких мыслей.
Я вам пример приведу из пейпера
Все эти люди безусловно работают в Microsoft и\или получают оттуда деньги. А как иначе?
Структуру комитета и глав его подразделений вы можете посмотреть вот здесь. Обратите внимание на главу SG1.
Есть понятие formal proposal — без полного обоснования нового функционала и его реализации и концептов, с вами общаться никто не будет. Сами же эти бумаги после внедрения в стандарт становятся собственностью ISO C++. О каких разработках вы говорите, я не понимаю.
Поведение плюсов стандартизировано. Вне зависимости от компилятора. Все что не входит в стандарт и не является частью TS не поощряется в использовании, в любом виде.
А обсуждение подобного функционала шло еще в 2013 когда был предложен концепт.
И ресерч датируемый 2011 годом.
Вы пока не привели ни одного аргумента кроме
await был сделан для WinRT. WinRT плохой, следовательно и await плохой.
У вас есть опыт работы с Boost.Coroutine? Ограничения которые он накладывает? Спецификации того как он работает? И тот факт, что вариант Кристофера не решает проблему с блокировкой не подготовленных методов?
vector тоже плохой — это не повод убивать шаблонный класс vector как сущность.
await это стандарт работы с асинхронным кодом. А теперь объясните где вы видите связь между стандартом и расширением? Или это ненависть к MS?
Одни сторонники "лучшее враг хорошего" включая Бьерна. Другие постоянно ищут способ, как сделать плюсы еще более мощными (читай сложными) для реализации. Больше функционала! И ведь хорошие идеи все, да только сложность языка растет все выше и выше(куда уже еще то?!).
Вариант с переключением контекста как предлагает Кристофер потребует O(n) доп памяти. Причем неявно. Плохо согласуется с zero cost abstractions.
Сейчас вообще интересный момент — часть людей считает, что многие из бумаг не готовы. Особенно неприятная ситуация выходит с Concepts TS — но я надеюсь, что комитету удастся наконец принять решение в пользу принятия этого предложения. Больше 10 лет обсуждения — надоело уже.
Честно говоря читая пэйпер, у меня возник вопрос — а ваша реализация то где? Во вторых, я соглашусь с тем, что текущий вариант обладает недостатками — но вариант с переключением контекста вручную (yield\longjmp) мало того, что создаст дорогу для кода который будет провоцировать баги, так еще и усложнит работу создателей компилятора, который будут вынуждены писать код под каждую платформу. Лично я против включения корутин в виде явного переключения контекста, в стандарт. Он не решает проблем, которые высказаны выше, а еще и своих добавляет.