Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ill-Advised C++ Rant, Part 2

codersnotes.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Ill-Advised C++ Rant, Part 2

#61

Post by cousin_it »

Manishearth wrote: post #60
cousin_it wrote: post #59

Earlier quoted context omitted.

About higher order functions: putting effects in the type forces you to make a distinction between map and mapM. You can't unify them because one takes a -> b and the other takes a -> m b. Same for any other higher order function, you have to write two versions (or more if you don't have HKT). About memory safety: can you give an example where a naive implementation of catchable exceptions would break memory safety?…

> forces you to make a distinction between map and mapM. You can't unify them because one takes a -> b and the other takes a -> m b. You have the same distinction in exceptions? One map would bubble the exception, the other would internally catch and exclude. You don't have to write two versions, map still works for cases with and without Result, but it will not have the additional behavior of excluding errors. You w…

Well, that example doesn't use catch, so it doesn't really tip the scales on catchable vs uncatchable exceptions. It does show that you have to be extra careful when making function calls from unsafe blocks, and that destructors are especially error prone. I agree with all that :-)

Re: Ill-Advised C++ Rant, Part 2

#62

Post by Manishearth »

cousin_it wrote: post #61
Manishearth wrote: post #60

Earlier quoted context omitted.

> forces you to make a distinction between map and mapM. You can't unify them because one takes a -> b and the other takes a -> m b. You have the same distinction in exceptions? One map would bubble the exception, the other would internally catch and exclude. You don't have to write two versions, map still works for cases with and without Result, but it will not have the additional behavior of excluding errors. You w…

Well, that example doesn't use catch, so it doesn't really tip the scales on catchable vs uncatchable exceptions. It does show that you have to be extra careful when making function calls from unsafe blocks, and that destructors are especially error prone. I agree with all that :-)

Recover is basically catch, it shows how a panic can leave something in a invalid and unsafe state, which can be accessed after recovery (without recover you wouldn't be able to access it). :)

Re: Ill-Advised C++ Rant, Part 2

#63

Post by cousin_it »

Manishearth wrote: post #62
cousin_it wrote: post #61

Earlier quoted context omitted.

Well, that example doesn't use catch, so it doesn't really tip the scales on catchable vs uncatchable exceptions. It does show that you have to be extra careful when making function calls from unsafe blocks, and that destructors are especially error prone. I agree with all that :-)

Recover is basically catch, it shows how a panic can leave something in a invalid and unsafe state, which can be accessed after recovery (without recover you wouldn't be able to access it). :)

You can see the invalid state even without catch/recover, e.g. from destructors that are called during unwinding.

Re: Ill-Advised C++ Rant, Part 2

#64

Post by Manishearth »

cousin_it wrote: post #63
Manishearth wrote: post #62

Earlier quoted context omitted.

Recover is basically catch, it shows how a panic can leave something in a invalid and unsafe state, which can be accessed after recovery (without recover you wouldn't be able to access it). :)

You can see the invalid state even without catch/recover, e.g. from destructors that are called during unwinding.

Ah, I see. Right, that works in this case, but it doesn't work in all -- you can come up with a situation where the destructor is fine but the recovery can lead to arbitrary unsafe things.

Re: Ill-Advised C++ Rant, Part 2

#65

Post by wund »

Who forgets to break in switch statements? I mean yea, there was a time when I started programming I did this once or twice but not for a quite long time. Seems to me more like a request for sloppy programmers than anything else.

Also don't forget [Duff's device](https://en.wikipedia.org/wiki/Duff's_device) for how it could actually be expressive.

Re: Ill-Advised C++ Rant, Part 2

#66

Post by BuckRogers »

lotsoflumens wrote: post #39
berkut wrote: post #34

Earlier quoted context omitted.

As someone trying to learn/experiment with Rust, the syntax is pretty complex. Now granted it comes with some benefits, and I realise there are a limited number of characters available to use (at least that everyone in the world has on their keyboards), but stuff like the lifetime char ' are IMO way too easy to mistake when quickly glancing at code for strings. But maybe that's just me.

No, it's not just you. The more I look at Rust, the less I like. -- leaving off the semicolon on the last statement causes that to be the return value of a function. -- functions can't capture free variables in lexical scope. They need an entirely different type and syntax for that (closures). -- try reading some non-trivial Rust code that uses generics - it's just as incomprehensible and unmaintainable as C++. It's…

> -- try reading some non-trivial Rust code that uses generics - it's just as incomprehensible and unmaintainable as C++.

That's not entirely that surprising due to the types of problems Rust tries to solve.

Post reply on HN