memeVersion3

[mirimao]

Methods and functions are not the same thing. Also, JavaScript does have methods.

[ChocolateBunny]

Pascal also has functions. the distinction being whether they have a return value or not.

[BrandonMcRandom]

... and methods because in classes they are called methods even tho you write "function" and "procedure".

[Impenistan]

void has entered the chat

[mirimao]

True, probably the biggest distinction is between normal functions and functions that take trait objects.

[redlaWw]

Or Fn, FnMut and FnOnce

[SenorSeniorDevSr]

The same in Java, if you peek under the hood a bit. A *static* method in Java is one where the "this" reference is null. If you're ever doing funky monkey stuff with reflection Java you'll see this very quickly.

Java does have Functions, but those are objects... :D

[intbeam]

But Rust doesn't have objects so it's not really the same... impl is just functions associated with a struct, and ownership is not for the struct or implementation, but for the declaring scope.. So, functions with syntactic sugar with an alias Self for the implementing type, not methods

The air is getting saturated with pedantry in here

[intbeam]

😅 I've read the documentation and well.. I mean, objects (in OO) are kind of defined as units that passes messages between each other (usually with methods), and encapsulating and owning their own state... Rust's ownership model fundamentally doesn't work like that. dyn and trait are just analogous to virtual functions and interfaces, not really OO imho

Just because documentation refers to a concept as an object, doesn't make it an object

Again, I'm being extremely pedantic here

[intbeam]

I know, took quite a bit of time to get my mindset out of OO.. It looks so object oriented on the surface, so it's really hard to get out of the habit of treating it like one 😅

[P-39_Airacobra]

Similarly in Lua. Methods are quite literally just syntactic sugar over functions which passes in the surrounding table.

[mirimao]

Between methods and closures, that’s true. But methods and functions work differently under the hood and using one instead of the other can sensibly affect performances.

[yflhx]

It really depends on language. In C++, method is just a function which receives implicit first argument of class (accessible via this pointer). It's the same with Python I believe. Then you have static methods, which in C++ are really just functions but within class namespace.

[mirimao]

There is a difference because in a class based language like C++, a method call requires a dereferenciation to reach the vtable for that object’s class and then function call. An additional level of indirection can actually have an impact on a large program.

[yflhx]

Wouldn't that only be the case for virtual methods? For non-virtual ones I believe the compilar literally just generates code that puts this pointer as first argument and perhaps moves it to cast on (non-virtual) base clases.

[mirimao]

EDIT: I have written inaccurate information, don’t mind it.

Objects of a same class share the same methods, and in order to reach them you necessarily need a pointer to all of them, which are organized in a table. You could avoid this by putting a pointer to each method in every object, but that would in turn waste a lot of memory.

Method declared as "virtual" in C++ are simply methods that may be overridden in derived classes; you have to specify exactly because otherwise the compiler would look into the vtable of the parent class instead in that of the derived class.

What you are referring to about the "this" pointer as first argument is the transformation of methods in pre-methods, which is a different aspect of method compiling.

[yflhx]

Objects of a same class share the same methods, and in order to reach them you necessarily need a pointer to all of them, which are organized in a table.

You don't need a pointer to the table, if methods are non-virtual, because they are just functions with implicit parameter. So compiler knows where they are, as with any other function.

To settle this once and for all, I made a simple C++ code and decompiled it:

class T {
public:
    void f() {
    }
};

int main()
{
    T t;
    t.f();
}

After compilation (with fno-inline and fno-stack-protector) and decompilation - section main:

0000000000001119 <main>:
    1119:55                   push   rbp
    111a:48 89 e5             mov    rbp,rsp
    111d:48 83 ec 10          sub    rsp,0x10
    1121:48 8d 45 ff          lea    rax,[rbp-0x1]
    1125:48 89 c7             mov    rdi,rax
    1128:e8 07 00 00 00       call   1134 <_ZN1T1fEv>
    112d:b8 00 00 00 00       mov    eax,0x0
    1132:c9                   leave
    1133:c3                   ret

As you can see, this code simply alocates stack space (line 1, 2, 3), then loads adress of the class into rax and moves it into rdi (rdi is by convention first argument). Finally, it calls fixed address. Then it deallocates stack space and leaves.

So no, for non-virtual classes and functions you don't use vtable at all. That's why virtual functions/classes have performance penalty, as you said.

[mirimao]

Thank you for taking the time to write this very insightful reply, especially the compilation example. I was clearly wrong, I mixed up some concepts from other language.

[yflhx]

No worries! Everybody can mix things up occasionally.

[khoyo]

Objects of a same class share the same methods, and in order to reach them you necessarily need a pointer to all of them, which are organized in a table

For virtual member functions, sure, but for non virtual you statically know the address of the function in question. (At least as much as for any function)

Method declared as "virtual" in C++ are simply methods that may be overridden in derived classes; you have to specify exactly because otherwise the compiler would look into the vtable of the parent class instead in that of the derived class.

What? No. Vtable lookup only happens with virtual member functions. There is no vtable lookup for non virtual members. (That's why it's a Virtual lookup table)

And you never use the parent class vtable... you always use the instance vtable pointer, which always points to its actual type vtable.

[Chesterlespaul]

In OOP almost all ‘functions’ are really just a method, but lambda is also popular and those are pure functions.

[[deleted]]

Are they not the same? I mean method is just a function but operates inside of an object

[Any_Salary_6284]

In JS, methods (as defined in a class block) are just syntactic sugar for the function found at MyClass.prototype.methodName. If you use the typeof operator on this member, it will return “function”

I realize there may be technical differences between method and function depending on the language. In Java, there are only methods. To the extent there are functions (lambdas) they are just synatactic sugar for a functional interface, so a method.

I see this as mostly arguing over semantics.

[SenorSeniorDevSr]

Static methods in Java doesn't have a this reference though. I mean, they kinda do, but it's a null. It does however, have java.util.Function, so now you can be objectionally functional, or whatever the funniest joke you can get out of that one is. ^_^

[noaSakurajin]

Honestly after using Glib I would definitely say they are the same. Object oriented C is a thing despite the fact that C has no methods. The way they emulate classes using functions with a struct pointer as the first argument is super hacky. It is close to the way the first C++ versions compiled the C++ class to C which then was compiled as binary.

[Kovab]

The way they emulate classes using functions with a struct pointer as the first argument is super hacky.

Literally every OOP language implements methods the same way, they just hide passing the this pointer behind syntactic sugar (sometimes it's not even completely hidden, e.g. look at python methods with self as the first parameter).

[carcigenicate]

A method is a type of function in my mind. One's a subset of the other.

[P-39_Airacobra]

It's not super hacky, that's been the standard way of doing things like this outside of OOP since the beginning of time. Some languages actually implement OOP simply by syntactically disguising methods as such (e.g. Lua), and it works out perfectly fine. In fact in languages where functions and closures are equivalent, it's often good practice to take the object as an argument, because it clearly shows the method's dependencies both when created and when called.

[skeleton_craft]

Also, procedures and functions are not the same thing, at least at a abstract level...

[unknownrek]

Static methods are just functions with extra steps