Красноглазые пионеры прыгали, бегали и стояли на ушах с этим Go, затем прошли "грабли" точно такие же как и в случае с Си, и в итоге приходят к аналогичным С++ концепциям.
Кто бы мог подумать
Не знаю какого цвета у тебя глаза и на чем ты стоишь но на C++ это не похоже. Просто сахар для проверок. Эти check/handle по сути тот же if но специализированный.
Здравствуйте, eskimo82, Вы писали:
E>Красноглазые пионеры прыгали, бегали и стояли на ушах с этим Go, затем прошли "грабли" точно такие же как и в случае с Си, и в итоге приходят к аналогичным С++ концепциям.
Неверно. Это С++ становится Go: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
GIV>Не знаю какого цвета у тебя глаза и на чем ты стоишь но на C++ это не похоже. Просто сахар для проверок. Эти check/handle по сути тот же if но специализированный.
Да ну. Ты и в правду сравниваеш концепции только по отличиям синтаксиса ?
Напоминаю про существование Microsoft Research и haskell. А также про огромнейший зоопарк железа, где винда работает и не требует настройки. В отличие от.
C>>>Неверно. Это С++ становится Go: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf E>>Ну микрософты за всю свою историю еще ничего продуманого не предлагали и не делали, одни только костыли для костылей.
С>А также про огромнейший зоопарк железа, где винда работает и не требует настройки.
Всё это железо сковали в Майкрософт и написали к нему драйвера?
Здравствуйте, eskimo82, Вы писали:
GIV>>Не знаю какого цвета у тебя глаза и на чем ты стоишь но на C++ это не похоже. Просто сахар для проверок. Эти check/handle по сути тот же if но специализированный. E>Да ну. Ты и в правду сравниваеш концепции только по отличиям синтаксиса ?
А теперь убери из кода на go check — что изменилось?
Или сделай несколько вложенных вызовов — как далеко исключение прокинется в примере на go?
check/handle это синтаксический сахар кодов ошибок, исключения — немного другая штука.
E>Да ну. Ты и в правду сравниваеш концепции только по отличиям синтаксиса ?
Здравствуйте, eskimo82, Вы писали:
m2l>>А теперь убери из кода на go check — что изменилось? E>Зачем ? Я могу и try/catch из C++ кода убрать, только это будет уже совсем другое.
Нет. В Go это просто синтаксический сахар для if err ! = nil { return err; }. Причём обратно совместимый.
E>try/catch — это синтаксический сахар исключений... Нет ?
Исключения в С++ — это фундаментальная фича, которая не может быть реализована без поддержки компилятора и рантайма. Go check — это просто сахар.
Здравствуйте, eskimo82, Вы писали:
E>try/catch — это синтаксический сахар исключений... Нет ?
Ликбез. Синтаксический сахар — альтернативный способ записи уже имеющейся в языке синтаксической конструкции (более краткий, удобный, и т.д.)
То, что handle/check синтаксический сахар в go тебе продемонстрировали сообщением выше, приведя эквивалентный код без них.
Покажи нам, пожалуйста, для каких конструкций C++ является синтаксическим сахаром try/catch?
E>>try/catch — это синтаксический сахар исключений... Нет ? C>Исключения в С++ — это фундаментальная фича, которая не может быть реализована без поддержки компилятора и рантайма. Go check — это просто сахар.
Исключения могут быть реализованы даже на Си, все остальное — это удобный сахар от компилятора и рантайма
m2l>Ликбез. Синтаксический сахар — альтернативный способ записи уже имеющейся в языке синтаксической конструкции (более краткий, удобный, и т.д.) m2l>То, что handle/check синтаксический сахар в go тебе продемонстрировали сообщением выше, приведя эквивалентный код без них.
m2l>Покажи нам, пожалуйста, для каких конструкций C++ является синтаксическим сахаром try/catch?
Ликбез: Например для sjlj (setjmp/longjmp)
Здравствуйте, eskimo82, Вы писали:
m2l>>Покажи нам, пожалуйста, для каких конструкций C++ является синтаксическим сахаром try/catch? E>Ликбез: Например для sjlj (setjmp/longjmp)
У-у как грубо... Навскидку: извраты с setjmp/longjmp не позволят вызвать деструкторы, необходимые для сохранения RAII при выходе из областей видимости внутри try...
Так что за синтаксический сахар в С++ они не засчитываются.
Здравствуйте, eskimo82, Вы писали:
E>Красноглазые пионеры прыгали, бегали и стояли на ушах с этим Go, затем прошли "грабли" точно такие же как и в случае с Си, и в итоге приходят к аналогичным С++ концепциям.
Да! С++ божественный язык, грабель нет, концепции идеальны!
В go до исключений правда ещё на доросли (см. выше) — но так ему и не 35 лет ещё, со временем может и дойдут.
m2l>У-у как грубо... Навскидку: извраты с setjmp/longjmp не позволят вызвать деструкторы, необходимые для сохранения RAII при выходе из областей видимости внутри try... m2l>Так что за синтаксический сахар в С++ они не засчитываются.
Возможность атоматически вызывать деструкторы при выходе за scope является другим сахаром.
Здравствуйте, eskimo82, Вы писали:
C>>Исключения в С++ — это фундаментальная фича, которая не может быть реализована без поддержки компилятора и рантайма. Go check — это просто сахар. E>Исключения могут быть реализованы даже на Си, все остальное — это удобный сахар от компилятора и рантайма
Исключения не могут быть реализованы в С++ остальными средствами языка. Поэтому они не являются сахаром, в отличие от check/handle.
Здравствуйте, eskimo82, Вы писали:
m2l>>У-у как грубо... Навскидку: извраты с setjmp/longjmp не позволят вызвать деструкторы, необходимые для сохранения RAII при выходе из областей видимости внутри try... m2l>>Так что за синтаксический сахар в С++ они не засчитываются. E>Возможность атоматически вызывать деструкторы при выходе за scope является другим сахаром.
...прыгали, бегали и стояли на ушах...
Но написать код демонстрирующий, что try/catch это синтаксический сахар — ты не можешь
C>>>Исключения в С++ — это фундаментальная фича, которая не может быть реализована без поддержки компилятора и рантайма. Go check — это просто сахар. E>>Исключения могут быть реализованы даже на Си, все остальное — это удобный сахар от компилятора и рантайма C>Исключения не могут быть реализованы в С++ остальными средствами языка. Поэтому они не являются сахаром, в отличие от check/handle.
Ты неоднократно заливал мне что делал это самолично
подменяя стандартный рантайм. C>Ну так, значит, несложно показать, как именно сделать исключения средствами С++.
По ссылке выше чуть далее все расписано.
подменяя стандартный рантайм. C>>Ну так, значит, несложно показать, как именно сделать исключения средствами С++. E>По ссылке выше чуть далее все расписано.
Ты ж даже не понял что там написано. Впрочем я не удивлён.
Там не про "сделать исключения средствами С++" а про "написать support routines для поддержки обработки исключений на платформе, для которой не было уже готового runtime"
E>>По ссылке выше чуть далее все расписано. CC>Ты ж даже не понял что там написано. Впрочем я не удивлён.
Еще бы ты не был бы удивлен. Попробуй наконец научится читать.
CC>Там не про "сделать исключения средствами С++" а про "написать support routines для поддержки обработки исключений на платформе, для которой не было уже готового runtime"
Не все ли равно откуда они будут дергаться — из хвостиков try/catch/throw или напрямую. Особой разницы нет.
Здравствуйте, eskimo82, Вы писали:
E>Не все ли равно откуда они будут дергаться — из хвостиков try/catch/throw или напрямую. Особой разницы нет.
Там принципиальная разница: реализация runtime library хелперов никак не поможет если компилятор не построит таблиц для вызова деструкторов для всех фреймов — ты просто не будешь знать что вызывать.
Можно конечно реализовать это всё врукопашную, вместо компилятора, но ты просто умрёшь уставшим, банально от объёма boilerplates.
Уж проще будет положить на исключения болт и писать в стиле error = Foo (...); if (error) ...
Здравствуйте, eskimo82, Вы писали:
GIV>>Не знаю какого цвета у тебя глаза и на чем ты стоишь но на C++ это не похоже. Просто сахар для проверок. Эти check/handle по сути тот же if но специализированный. E>Да ну. Ты и в правду сравниваеш концепции только по отличиям синтаксиса ?
Концепции совершенно разные.
E>
E>>Не все ли равно откуда они будут дергаться — из хвостиков try/catch/throw или напрямую. Особой разницы нет. CC>Там принципиальная разница: реализация runtime library хелперов никак не поможет если компилятор не построит таблиц для вызова деструкторов для всех фреймов — ты просто не будешь знать что вызывать.
Это все тот же сахар, причем как побочный эффект от контроля времени жизни в scope. Кстати этот контроль вполне реализуем автоматически на Си в некоторых компиляторах.
CC>Можно конечно реализовать это всё врукопашную, вместо компилятора, но ты просто умрёшь уставшим, банально от объёма boilerplates.
Это спокойно реализовывается на чистом Си, проблема действительно в том, что можно посинеть при написании прикладного кода, но ограничений в принципе никаких нет.
CC>Уж проще будет положить на исключения болт и писать в стиле error = Foo (...); if (error) ...