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

21–30 of 46 posts

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

#21

Post by blub »

marvy wrote: post #14
mappu wrote: post #7

I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method calls in lua, and extension methods from C# &c. I think this debate is a small part of a larger one about unified namespaces, and for functions in particular. There's no good reason for a named function to coexist with a like-named function variable. Javascrip…

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 structures with the same syntax affordances and performance characteristics makes it easy to jump in and hard to make progress if you hit a wall with the built-ins.

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

#22

Post by hellofunk »

>C++ provides two calling syntaxes, x.f(y) and f(x,y)

I have to shamefully admit, I have no idea what this is referring to. In the second one, is this talking about the implicit "this" pointer that is passed to member functions?

I've never seen or written code like the second form -- if in fact f() is defined as taking only a single argument, I've never seen it called with 2 arguments.

My guess is that this is a discussion about the implementation of member functions, can anyone confirm?

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

#23

Post by kamac »

hellofunk wrote: post #22

>C++ provides two calling syntaxes, x.f(y) and f(x,y) I have to shamefully admit, I have no idea what this is referring to. In the second one, is this talking about the implicit "this" pointer that is passed to member functions? I've never seen or written code like the second form -- if in fact f() is defined as taking only a single argument, I've never seen it called with 2 arguments. My guess is that this is a disc…

I think they're referring to OO style (a member function) and imperative style (loose functions).

But unifying those makes no sense to me.

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

#24

Post by eru »

eco wrote: post #10
blt wrote: post #8

Ahh I'm sad. I really wanted x.f(y) to find f(x,y). Then std::algorithm and ranges would combine to make sweet linq-like filter/map operations.

Yeah, I'm really disappointed. It's one of my favorite things about D. I guess f(x,y) finding x.f(y) is better than nothing but the other way around makes for some beautifully composable code.

Looks like poor man's partial application (and currying) to me?

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

#25

Post by efaref »

hellofunk wrote: post #22

>C++ provides two calling syntaxes, x.f(y) and f(x,y) I have to shamefully admit, I have no idea what this is referring to. In the second one, is this talking about the implicit "this" pointer that is passed to member functions? I've never seen or written code like the second form -- if in fact f() is defined as taking only a single argument, I've never seen it called with 2 arguments. My guess is that this is a disc…

Under the covers, `x.f(y)` is actually something like `_ZN1X1fEi(&x, y)`, where the mangled name indicates the class of X and the type of y. The implicit 'this' pointer is actually explicit in the implementation. Similarly, a call to `f(&x, y)` would actually be a call to `_Z1fP1Xi(&x, y)`, with similar reasoning.

The author is proposing that writing

  f(x, y)
Which would normally only bind to the second mangled function, would bind to the first mangled function if the second is not available.

The additional proposal, that:

  x.f(y)
would work in the other direction was rejected. That's a bit of a shame, as this kind of duality is powerful in languages that support it (e.g. scala).

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

#26

Post by akavel »

hellofunk wrote: post #22

>C++ provides two calling syntaxes, x.f(y) and f(x,y) I have to shamefully admit, I have no idea what this is referring to. In the second one, is this talking about the implicit "this" pointer that is passed to member functions? I've never seen or written code like the second form -- if in fact f() is defined as taking only a single argument, I've never seen it called with 2 arguments. My guess is that this is a disc…

Based on the rest of the original paragraph, I understand he refers to the fact that you have to choose either one when desigining a library, and then you're stuck with it (and its various consequences) in your API for better or worse -- and your library users are stuck with it too.

In other words: if you design a polygon clipping library, do you design your API so that users would write `polygon1.clip(polygon2)`, or `clipper::clip(polygon1, polygon2)`?

edit: also, from reading further down, I understand the discussed issue is that after you define the API as `polygon1.clip(polygon2)`, you can't easily use the 'clip' method in places where a f(a,b) would be required, although it's effectively equivalent. And it's impossible the other way round too.

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

#27

Post by roel_v »

hellofunk wrote: post #22

>C++ provides two calling syntaxes, x.f(y) and f(x,y) I have to shamefully admit, I have no idea what this is referring to. In the second one, is this talking about the implicit "this" pointer that is passed to member functions? I've never seen or written code like the second form -- if in fact f() is defined as taking only a single argument, I've never seen it called with 2 arguments. My guess is that this is a disc…

std::function works like the second syntax.

    struct Foo { void Bar(int) {} };
    std::function  f = &Foo::Bar;
    int i;
    Foo foo;
    f(foo, i);
Which is confusing - you'd expect it to work like maybe 'foo.f(i)' or maybe 'foo.*f(i)' or something like that. Well the whole discussion (from what I understand) is what that 'something' should be (well I don't mean to imply that this is about how std::function should work; rather that this is one explicit manifestation of an issue that shows in several places).

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

#28

Post by pjmlp »

kamac wrote: post #23
hellofunk wrote: post #22

>C++ provides two calling syntaxes, x.f(y) and f(x,y) I have to shamefully admit, I have no idea what this is referring to. In the second one, is this talking about the implicit "this" pointer that is passed to member functions? I've never seen or written code like the second form -- if in fact f() is defined as taking only a single argument, I've never seen it called with 2 arguments. My guess is that this is a disc…

I think they're referring to OO style (a member function) and imperative style (loose functions). But unifying those makes no sense to me.

Quite a few languages do OOP f(self, args), not every OOP language does self.f(args).

Ada, Common Lisp and Dylan come to mind.

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

#29

Post by Ono-Sendai »

mappu wrote: post #16
Ono-Sendai wrote: post #15

Earlier quoted context omitted.

In my language f.g(x) is syntactic sugar for g(f, x). Prefixing with the typename of f is not needed due to function overloading. (Which basically does the same thing I guess)

Interesting! Do you have separate symbol tables for functions and variables, then? I've taken the major design decision that there's only one symbol table for variables, so every function is a functor. I'm not sure it's possible to reconcile this with function overloading (Go/Javascript don't) EDIT: i suppose you could have a different symbol table for each variable type , incorporating function arities.

I don't really use symbol tables in the compiler. But with function overloading, binding needs to be done by name and type, yes. It does complicate the binding process significantly.

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

#30

Post by daemin »

efaref wrote: post #25
hellofunk wrote: post #22

>C++ provides two calling syntaxes, x.f(y) and f(x,y) I have to shamefully admit, I have no idea what this is referring to. In the second one, is this talking about the implicit "this" pointer that is passed to member functions? I've never seen or written code like the second form -- if in fact f() is defined as taking only a single argument, I've never seen it called with 2 arguments. My guess is that this is a disc…

Under the covers, `x.f(y)` is actually something like `_ZN1X1fEi(&x, y)`, where the mangled name indicates the class of X and the type of y. The implicit 'this' pointer is actually explicit in the implementation. Similarly, a call to `f(&x, y)` would actually be a call to `_Z1fP1Xi(&x, y)`, with similar reasoning. The author is proposing that writing f(x, y) Which would normally only bind to the second mangled functi…

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.
Post reply on HN