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

A bit of background for the unified C++ call proposal

isocpp.org

Post reply on HN
Print view View original

41–46 of 46 posts

Re: A bit of background for the unified C++ call proposal

#41

Post by makecheck »

kibwen wrote: post #40
makecheck wrote: post #37

One of the silly things about member functions is the effect that they have on argument ordering when ordering is not supposed to matter. For example, consider "operator +", which can have in-object or function implementations. The ridiculous thing is that, for any two types in an expression like "+", you can't tell from observation if it will compile! Is it only available as a member function? If so, then any primit…

> One of the silly things about member functions is the > effect that they have on argument ordering when ordering > is not supposed to matter. This isn't a problem with member functions, free functions have this problem as well. And not just in C++, commutativity just isn't a first-class concept in any programming language that I've ever seen.

My main point is that there is no way for something like "2 + object" to do the right thing when member-function syntax is expected, whereas there is at least a way for a free function to do so; and the language could have avoided this problem.

I believe this is also the entire reason that recent C++ standards introduced free-function forms of things like begin(thing)/end(thing)/etc. because it was just too hard for something like a template to operate on a value when it couldn't tell whether or not object syntax would work.

Re: A bit of background for the unified C++ call proposal

#42

Post by blt »

twoodfin wrote: post #39
daemin wrote: post #30

Earlier quoted context omitted.

This is also why functions can work on a null object and not crash, as long as they do not access instance data. Though at that stage they should be static or external.

AFAIK, this is still undefined behavior, so "can work" means "you got lucky this time, your next compiler upgrade may turn this into a crash, security vulnerability, or utterly confounding Heisenbug".

Ugh, I remember seeing null `this` values used on purpose in some old Windows MFC program, or maybe it was COM...

I imagine the author was an old-school C programmer who understood well how the C++ object veneer maps down to equivalent C code / assembly. From that perspective, dealing with null `this` pointers is just another way to get the compiler to spit out the assembly instructions you want, and maybe enables some elegant patterns in client code... but it's exactly the kind of thing that makes newcomers hate C++.

Re: A bit of background for the unified C++ call proposal

#43

Post by marvy »

blub wrote: post #21
marvy wrote: post #14

Earlier quoted context omitted.

C++ tries to make the same guarantees that the Go 1 compatibility promise makes. (Or at least very similar; they are different languages after all.) Basically: old code should keep working possible, but they have the right to invent new features. The real difference is that C++ is feature-philic (new feature: want!), while Go is feature-phobic (new feature: avoid!) Of course, if you want to make specific predictions…

There are several dictionary types in C++, but each has different performance characteristics and they all have good support. Thanks to the efforts to make built-in types and UDTs equal, Qt's map was for instance implemented as a skip list and was just as usable as the standard library types. Nowadays it's a RB Tree. Go's strategy of picking hash maps and not offering the mechanisms of building your own data structur…

Yep. I guess they're counting on that being so rare that it's worth paying the price in occasionally having to rewrite (and uglify) large chunks of code, in exchange for having a simpler language.

Re: A bit of background for the unified C++ call proposal

#44

Post by [deleted] »

DrDimension wrote: post #32
lholden wrote: post #5

>> I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think the concern is that a class "owns" its methods either directly or through inheritance. Therefor, the interface is expressed by this namespace and it can't be "invaded" or modified. From that…

I'm going to have to pose an educated disagreement. According to the classic C++ article, "What's in a class?" by Herb Sutter ( http://www.gotw.ca/publications/mill02.htm ) - The Interface Principle suggests - For a class X, all functions, including free functions, that both (a) "mention" X, and (b) are "supplied with" X are logically part of X, because they form part of the interface of X. So yes, f(x) is part of x'…

[deleted]

Re: A bit of background for the unified C++ call proposal

#45

Post by lholden »

DrDimension wrote: post #32
lholden wrote: post #5

>> I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think the concern is that a class "owns" its methods either directly or through inheritance. Therefor, the interface is expressed by this namespace and it can't be "invaded" or modified. From that…

I'm going to have to pose an educated disagreement. According to the classic C++ article, "What's in a class?" by Herb Sutter ( http://www.gotw.ca/publications/mill02.htm ) - The Interface Principle suggests - For a class X, all functions, including free functions, that both (a) "mention" X, and (b) are "supplied with" X are logically part of X, because they form part of the interface of X. So yes, f(x) is part of x'…

"I'm going to have to pose an educated disagreement."

A little awkward to read in response to my comment.

An educated disagreement to what? I guess you are disagreeing with their argument? I agree with your comment.

Or maybe it's a disagreement with what I think their argument is? This is why I am asking. :)

Re: A bit of background for the unified C++ call proposal

#46

Post by 72deluxe »

byuu wrote: post #33

What a shocker. Allowing f(x,y) to find x.f(y) is nearly useless; and allowing x.f(y) to find f(x,y) is scrapped. Even though D can do the latter just fine. I can already write all my class functions as f(x,y) functions, if I want my code to look like C. The whole point of UFCS is to work around the obnoxious fact that classes are closed after their initial definitions(＊). Only the latter can help with that. So when…

I know they don't have algorithms are part of the string class in C++ but that's because you can just treat it as any other container and run functions against it, like you would on a vector etc.

That's how I saw the string class anyway?

Post reply on HN