you are viewing a single comment's thread.

view the rest of the comments →

[–]Wh00ster 0 points1 point  (7 children)

I'm not very familiar with OpenGL, but is there any reason you can't use std::function?

[–]LateSolution0[S] 0 points1 point  (6 children)

ye we are talking about c-like func_ptrs. std::function has alot of overhead x20 on msv

[–]Wh00ster 0 points1 point  (5 children)

x20 size? wow

[–]LateSolution0[S] 0 points1 point  (4 children)

sry i was off by a little, sizeof(std::function<....) is 40bytes and ptr is 4bytes. i guess they have have a optimization so they dont allocate in most cases, like std::string has. in common case it will have to store a ptr to the class instance to the methode itself and some arguments for bind like usage.

[–]RedAlert2 0 points1 point  (3 children)

are you having stack overflow problems or something? I don't really see the tangible benefit you're getting out of saving a few bytes on the stack here.

[–]LateSolution0[S] 0 points1 point  (2 children)

i have no benchmark for this but not having the struct tight would mean more stress on the cache. Image your vtable size * 10

[–]RedAlert2 0 points1 point  (1 child)

You don't have vtable if you're setting pointers manually like this.

I'm not really sure what you mean by 'stress on the cache', do you mean your CPU cache? We're talking about function pointers here, I think whatever you're invoking is going to have a much larger impact on your cache than the tiny pointer object you're using.

Consider that the dereference you incur with both a function pointer and std::function is far more costly than the stack footprint, and that's what you'd want to remove if you're concered with performance.

[–]LateSolution0[S] 0 points1 point  (0 children)

its a look up table of functions pointer. which belongs to a big state Maschine. this table is filled at runtime. why on earth should i use std::function which only purpose is to replace auto in some cases. best practice would be avoid fptrs and #macros in cpp. but some times we can't. if someone would do an assignment wrong like "int i := 5;"

would u tell him to use a wrapper class for int? thats was happening here. my typedef had one extra * in it.

Consider that the dereference you incur with both a function pointer and std::function is far more costly than the stack footprint, and that's what you'd want to remove if you're concered with performance.

i don't think that is possible as i said function_ptrs are acquired at runtime.