void (*)(int)

[Lesshardtofind]

Hey,

I got an error I couldn't google. Following a tutorial I tried to roll the GLUT menu capabilities into a class that I could use in other programs later.

cannot convert ‘GlutMenu::MenuEvents’ from type ‘void (GlutMenu::)()’ to type ‘void (*)(int)’

Best I can tell in english it means can't convert GlutMenu void to a void pointer int.

I am not sure I know what a void pointer int is. The error was -fpermissive, but I stay away from doing that if I don't know why I'm doing it.

Should I try typecasting?

Thanks for your time!

[laserlight]

Basically, it looks like you are trying to convert a member function pointer to a pointer to a function that takes no arguments and returns void. This is most likely a mistake, and typecasting would probably just hide the error rather than fix it.

[Lesshardtofind]

Yea it looks like the required function takes a different number of parameters than I set.

6.1 glutCreateMenu

The documentation that came with freeglut3-dev didn't show this page. I always look for something for 20 minutes then the answer shows up like 5 min after I post. ;o/

Just to make sure I learn something out of this though does the compiler saying
void (*) (int)
mean it is a pointer to a void function that expects an int as an argument?

[laserlight]

Just to make sure I learn something out of this though does the compiler saying
void (*) (int)
mean it is a pointer to a void function that expects an int as an argument?

Yes

[Elysia]

Remember that OpenGL is a C API. It knows nothing about C++ features such as classes and member functions!

[Lesshardtofind]

Yea I found out about that from a book I was reading. I want to do 3d graphics, but in no way do I want to start over with learning C. So I started setting up SFML (Simple and Fast Multimedia Library) which is written in c++ supports a lot of OOP concepts and still has much of the functionality of GLUT and SDL, but it is not as well established is the downside.

You pointed out some of the ugly in SDL last week, and I would have to agree there are some downsides as it is written in C as well, it is not longer being updated and it comes with a lot of overhead. The hard thing to walk away from is its maturity. SDL with open GL will run on nearly anything from Windows to Wii.

At this point I am experimenting with a lot of frameworks. To find out what I like and what I don't. I spent the last two days on glut only to find out you can't pass an argument to its render function so all draw coordinates have to be global variables or you have to have a global pointer that knows where everything else is. I really don't like either solution so I am going to test SFML.

Thanks for the info Elysia.

[dwks]

I usually wrap the SDL in a few of my own classes. It's not very hard. Also, libraries like SFML are likely based on the SDL, so if SDL is supported and there's a C compiler, SFML should work as well. But check the documentation about this, I don't know whether SFML is built entirely on the SDL or not.

If you really want to use glut you can take pointers to static member functions, with a simple extern "C" wrapper that just calls the static function if you're having trouble with C/C++ linkage. This works well for C APIs like bullet that don't have many callbacks, I guess it would be somewhat painful but usable with glut.

The nice thing about the SDL is you can use as much or as little of it as you want. A basic SDL program is very small and straightforward. When you want to do something like receive keyboard input it's just an extra switch statement... C++-ified however you prefer.

[phantomotap]

Also, libraries like SFML are likely based on the SDL, so if SDL is supported and there's a C compiler, SFML should work as well.

O_o

That doesn't make any sense.

Why would any library likely be based on SDL?

And no C++ library, without a C wrapper obviously, will work with only a C compiler regardless upon any libraries it may be built.

Soma

[Lesshardtofind]

SFML is a c++ library SDL is a C library. SFML is not built on top of SDL. SFML is slightly faster (up to 10x for some graphics operations) but lacks the maturity (not supported by near as many platforms), but is constantly updated and its lead developer maintains a forum to assist with the library. There are downsides and upsides to both.

Just google SDL vs SFML.

[stahta01]

After 5 minutes of Goggling

Looks like SFML may be based partly on GLEW.

And, GLEW was likely influenced by GLX and SDL.

Did not see SFML being based on SDL. But, did not look very deep.

Edit: Think I found the source of the confusion from http://www.sfml-dev.org/features.php

Can be used as a minimal, portable package to replace GLUT or SDL for windowing and input with OpenGL

Tim S.