I mean, if you change the name to "BufferPool::get_record" and you use an implicit this pointer instead of your "pool" argument, you have a method. It seems like you're fighting the paradigm more than you need to.

You're not wrong but for some reason this style is easier for me to work with

I know logically/semantically they're equivalent. The v-table function generated if the method is moved inside the class/struct winds up being identical.

Dunno what it is, some kind of familiarity bias with the way the code is laid out I guess, not coming from OOP languages

Note: it wouldn’t generate a vtable entry unless the method was declared virtual.

Ahh, what do you call the method table thing for non-virtual classes?

There is no table if no ‘virtual’ is involved.

To be more clear, when no "virtual" method is declared, then no table is generated because none is needed.

In this case, the addresses of all the methods are known at compile time and the compiler knows which to choose when anyone is invoked in the source code, based on the type of the object and on the types of the method arguments.

When there is at least one "virtual" method and you have a pointer to an object, the type of the object cannot be known at compile-time, so the compiler cannot determine which method to invoke.

That is why the compiler needs to create a table with pointers to the virtual methods for each class with such methods, and each object of those classes must include a pointer to the corresponding vtable, so that the correct method to invoke can be determined at run time (from the index of the virtual method).

C++ uses name mangling to give names to non-virtual methods. They are no different than a C function that takes a pointer, except they may use a different calling convention.

Even if the method is virtual, C++ compilers make an effort to call methods directly without indirection through a vtable wherever possible.

The interesting thing is that you can't call the "function that takes a pointer". Accessing it as a method is the only thing which works.

A long term ambition for C++ and more specifically for Bjarne has been UFCS, Universal Function Call Syntax, which a few other languages have. But C++ can't do this today.

Yeah, UFCS remains illusive, but tantalizingly close. It's pretty easy to make

``` struct foo { void bar(); }

bar(foo* i) { assert(i != nullptr); i->bar(); } ```

work, but there's enough syntactic complexity in the language that it isn't as easy as it should be.

It's a 1-liner with std::mem_fn

Indeed.

std::mem_fn will effectively give you the underlying function that takes a pointer. Strictly speaking mem_fn is defined to generate the wrapper function, but in practice the optimizer is just going to strip that away and call the name-mangled function directly.

Example: https://godbolt.org/z/6Y1raxMce

You can just use member function pointers without the wrapper. The syntax for calling them is a bit uglier though.

Yup, but then the call syntax is different so it fails to achieve the "Universal Function Call Syntax" that OP was asking for which std::mem_fn provides.

Whoa, this is really cool, thanks for posting

Only classes with one or more virtual functions have virtual method table. Objects of such classes are called polymorphic objects and they (and only they) have hidden pointer to virtual method table.

https://en.cppreference.com/w/cpp/language/object#Polymorphi...

> The v-table function generated if the method is moved inside the class/struct winds up being identical.

Unless you add some additional semantics/keywords, it's not going to create a vtable.

> Dunno what it is, some kind of familiarity bias with the way the code is laid out I guess, not coming from OOP languages.

I'm sure that's what it is.

FWIW, structs and classes are largely identical in C++ , with the exception of public/private defaults.

So using one over the other doesn’t really change anything with regards to data oriented design.

Aye, as opposed to D where structs are value types and classes are reference types

It's just a small annoyance to have to put "public:" at the top of every data-class definition

So I use structs everywhere but you're completely right, no real difference

Yeah I do the same as you since I write a ton of Swift (which does the same delineation as D).

It’s mostly just a mental marker for myself that I want to treat one as a value type.

If I was code reviewing this I would strongly suggest std::array instead of those raw array;) I’m also curious why you have page_id_to_frame_idx[] without a size. If you are using that paradigm to read off the end of the struct then it needs commenting heavily, if it’s a typo then std::array would have caught it.

I do understand that it’s just a snippet of code to show a style, so ignore this pedant!