Casting type int to const void*

[moomanfl]

Greetings,

I finally got around to trying to learn C++ in the last week. I have a good grasp on some of the fundamentals, but I am having trouble in some code I am writing.

I have a two functions, one that returns an int, and one that takes a const void* as an argument. I need to cast the int from the first function so that I can use it as an argument for the second function.

I have looked around and can't seem to find any information on how to do this. Any help with this is appreciated.

[Banfa]

The fact that you have got into a situation of having to cast an int to a const void * suggests poor program design (or possibly direct access to memory mapped peripherals as you might find in an embedded project).

In fact any use of void * in C++ tends to suggest poor design or that you are using the C like aspects of C++ rather than the full range of C++ programming techniques.

However if you must cast int to const void * then look up reinterpret_cast<...>(...) in you C++ book.

[moomanfl]

Well, as I said, I am new to C++ (just started last week),,,, however I really didn't see a choice in this instance. Although that could be just lack of experience.

The situation is, I am writing a plugin for a game compiler (DarkBASIC Professional). The functions have to be listed in a string table along with what types they accept as arguments and what type they return... but it is limited in the case where your function needs to be able to accept any type.

Overloading is a real pain to get to work in this instance because I need to be able to accept 1 to 10 arguments of any allowed type in any combination. That would be literally thousands of overloaded functions. However, they do have a string table indicator for const void*... so that was my choice, and it works.

Thanks for the tip... I am going to look up your suggestion now.

[oler1s]

but it is limited in the case where your function needs to be able to accept any type.

Bad design. Your function should be not be having to deal with "any possible kind of input". If you can't create functions that are fixed on certain types of arguments, it's because you didn't design your system properly.

[moomanfl]

Ok... I intend this non-sarcastically: How do you you suggest I structure a function that is to be provided as a command in another programming language that lets someone send a function call with arguments.... but you don't know the types of the arguments that they are going to have to send in advance? The could send an int, a string, a float, etc. And my function has to be able to accept it no matter what... up to 10 arguments like that in any order and in any number (up to 10).

Seriously... I would like a better design on this, but I can't make 10,000 different overloaded functions to handle all the possible combinations.

What I settlled on was 10 overloaded functions with 1 to 10 const void* arguments as the parameters. Since I am simply passing them off later to another function (usually unmodified) this has worked just fine, but I am open to suggestions.

[oler1s]

There is a better way. I wasn't mocking you when I told you your design is flawed. Exponential growth in variations is a sign of bad design.

How do you you suggest I structure a function that is to be provided as a command in another programming language that lets someone send a function call with arguments.... but you don't know the types of the arguments that they are going to have to send in advance?

First ask yourself, even though they technically could send any type of argument, what types does your programming logic encompass? For example, a function that takes a base to a power, and is open to user input, could technically "take any form of input", but the only meaningful type of input is a numerical value. Furthermore, this could be constrained to floating point types.

Since you're struggling with the design, why don't you describe what your function logically does with the arguments?

In any case, the best way to deal with user input might be to accept everything as a giant string, or a series of string arguments. Then attempt to tokenize or parse into appropriate data types as appropriate.

Again, I want to steer you away from the "any input type possible" situation, and I ask that you make an effort to avoid it as well.

But if all fails, I would advise you to look at getopt or boost.program_options. They are used to work with program command line arguments, which means any type of input that must eventually be sorted into appropriate data types like strings, integers, and floating point.

[moomanfl]

Well in this case I am making an ad-hoc event raising/handling system for a BASIC style language.... I take the arguments they want to pass with their event, store it in a queue, then at the DoEvents() command I pass them off to a command in yet another person's DLL that sends the arguments to the appropriate function in the BASIC code.

The arguments can literally be of any type. If they have a function that they need a string as a value for, they send a string with their event... if their handler function needs 2 strings and 3 integers they are going to send that.

The job of my function is just to organize everything and pass it along at the appropriate time without worrying about the types involved.

Since I don't have control over, or access to, the code for the BASIC compiler or the plugin DLL that I have to hand the values off to, I am a bit limited in how I can deal with them.

My code does the above flawlessly. The hang-up came when I wanted to introduce some hard coded events... like an OnMouseMove where I send the X and Y of the mouse position with the event... those are sent back by the function I use as type int.... since my event queue is geared towards storing values of type const void*, I was needing to convert the values for storage in the event queue.

[Laharl]

You might want to look at variadic functions, which can have any input of any type in any amount. They're a little tricky to work with, but they might help you.

[moomanfl]

Thanks, that sounds REALLY interesting. Always willing to pick up a new trick as long as I have something to search for. :-)