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

Move, simply

herbsutter.com

Post reply on HN
Print view View original

91–96 of 96 posts

Re: Move, simply

#91

Post by codr7 »

lioeters wrote: post #89
codr7 wrote: post #29

And this is about the point where I finally gave up on C++, I just wish I could get the time I spent learning all the rules and all their exceptions back. It has now morphed into a language where today's optimal code looks horribly inefficient by yesterday's standards. Which adds another layer of uncertainty to what was already a pretty serious mess of a language. Calling this simple is about as silly as it gets. Tha…

@codr7 - By chance I was just browsing your projects yesterday! g-fu ¹, a Lisp dialect in Go, is a marvel. Other languages you've been creating (gfoo, cfoo, lila) are tastefully done too. So I'm in total agreement with you about the monstrosity that is modern C++. Nobody would have designed such a language from scratch. It seems to be a common fate of popular and long-lived languages (or projects, companies even), th…

I'm glad you enjoy them, writing and using these languages floats my boat but it's always nice to get confirmation that I'm not alone in here :)

The biggest issue with g-fu is that it currently expands macros on evaluation. What can I say, it was the first time I implemented quasi-quoting which twisted my brain in exotic ways. That's also why it's so close to Lisp, because it's the only decent macro system I have experience from.

g-foo is definitely a cleaner design, but more Forth than Lisp which may not be everyone's cup.

Agreed, and Bjarne said so himself; that there's a cleaner, more consistent language hidden deep inside C++. C compatibility has been a blessing and a curse. I think Stepanov is a better designer though; if it wasn't for the STL, I would have given up a long time ago.

Re: Move, simply

#92

Post by codr7 »

richard78459 wrote: post #83
codr7 wrote: post #29

And this is about the point where I finally gave up on C++, I just wish I could get the time I spent learning all the rules and all their exceptions back. It has now morphed into a language where today's optimal code looks horribly inefficient by yesterday's standards. Which adds another layer of uncertainty to what was already a pretty serious mess of a language. Calling this simple is about as silly as it gets. Tha…

But the world is built on C++ and there are no alternatives for it. C is too low level and Rust has garbage collector which may not be fit for the domain C++ is suitable for. No alternatives in the domains where C++ shines.

There is definitely more C than C++ running under the hood on most computers. C is the language where there are no alternatives if you ask me. Go is garbage collected and C++/Rust are both infinitely more complicated.

Re: Move, simply

#93

Post by [deleted] »

Joker_vD wrote: post #90
richard78459 wrote: post #85

Earlier quoted context omitted.

But the language is garbage collected, that's not desirable in the domain c++ operates

Rust completely dropped GC support in 0.12 — which was released on 9th October, 2014. That happened more than 5 years ago.

[deleted]

Re: Move, simply

#94

Post by dragontamer »

Someone wrote: post #79
dragontamer wrote: post #47

Earlier quoted context omitted.

std::move has been part of the language for 9 years. It is no longer reasonable to change std::move. To satisfy the programmer, there probably should be a std::dmove(x), which would be a compiler-enforced notation that would make use of x illegal after the use of std::dmove. std::dmove(x) would be implemented as std::move, followed by a destructor, and then the compiler removes variable x from the scope. Pointers and…

But the whole point of std::move is to avoid calling, possibly expensive, destructors. The standard example is template void swap(T& x, T& y) { T z = std::move(x); x = std::move(y); y = std::move(z); } ... std::string a[1000]; ... std::swap(&a[2], &a[7]) If std::move copy-constructs and destroys, that last line would do three allocations and three frees (recoverable by a significantly advanced compiler, but who has t…

A good point.

So clearly the way std::move works now is great for that situation. But there's a 2nd situation, with Herb Sutter's IndirectInt, which calls for a different behavior.

Re: Move, simply

#95

Post by gumby »

roca wrote: post #75
gumby wrote: post #71

Earlier quoted context omitted.

Rust can do this for an arbitrary element of a dynamically allocated array?

No. You can't move an element out of an array in Rust. What Ollie said is true for local variables, and collections generally support some kind of "move element(s) out of the collection" API (e.g. Vec::pop(), T::into_iter()).

So rust can do it in a subset of cases, such that it can make a stronger assertion; C++ can do it in the general case, and is therefore unable to make the stronger assertion.

Neither is correct vs the other, rather they reflect different choice points in the language possibility space.

Re: Move, simply

#96

Post by roca »

gumby wrote: post #95
roca wrote: post #75

Earlier quoted context omitted.

No. You can't move an element out of an array in Rust. What Ollie said is true for local variables, and collections generally support some kind of "move element(s) out of the collection" API (e.g. Vec::pop(), T::into_iter()).

So rust can do it in a subset of cases, such that it can make a stronger assertion; C++ can do it in the general case, and is therefore unable to make the stronger assertion. Neither is correct vs the other, rather they reflect different choice points in the language possibility space.

You can do a C++ style "swap object with a placeholder" move in Rust, easily, with std::mem::replace(). There's no advantage for C++ here.
Post reply on HN