Pulling an Argument from a Method

Hey, I'm writing a program that converts the English language into a fictional language I am developing for a video game. One of the things I'd like to do is be able to pull an argument from a method. Likewise:

englishToCud("This is a test.");

I want to pull "This is a test." from the argument and be able to use it without having to use a variable... unless this is impossible. Any hints?
This is impossible.
Without an explicit variable, but with a temporary, like this?
 
cout << englishToCud("This is a test.");
Asdf blah hee bloop.


I'm not sure we understand the question here...
without having to use a variable


What? Why can't you use a variable?
Why would you want to do that!?

Anyway, I don't know of a way to do this in c++ but you can do it if you know some assembly.
example:
1
2
3
4
5
void func(const char* str){}
void func2(int v, const char* str){}

int main(){
    func("it's alive!");

to use it in another function where the string is the last argument:
1
2
3
4
5
    __asm{
        sub esp, 4
        push 5 //push all the necessary arguments..
        call func2
    }

if it is not the last argument, you could still do it, but that would be a lot more messy..
to assign it to char* :
1
2
3
4
5
6
7
    char* string;
    __asm{
        sub esp, 4
        pop dword ptr[string]
    }
    return 0;
}


Using assembly in your code is usually a bad idea. It's not portable..
Also, I'm not sure if the syntax I use here is standard. It works on vc++ but I think it should really be something like asm("sub esp, 4");
Last edited on
@hamsterman:
There is, of course a psuedo-variable there. It's called the stack.

x86 GAS assembly is fairly portable, just not across all microprocessors. Across all processors that support the x86 instruction set, it is with a few exceptions. The use of system interrupts will void its portability; not using system-specific features will not.

@OP:
As PanGalactic said, what most of us are thinking is that the task is impossible. However, what about passing by reference?
func2(char location[]);


-Albatross
Last edited on
There is, of course a psuedo-variable there. It's called the stack.

Yeah, I know...

Now, about portability. I know assembly itself is portable. I am not sure if, for example, I can be sure that all compilers will push function arguments backwards and stuff like that.
I'm rather curious as to why you want to do this?
@hamsterman
Push is a very specific instruction, or at least the last time I checked, that always pushes all other elements of the stack down by one and add whatever is being pushed onto the top. If you know of any common assemblers that don't do this, please inform me so that I might strangle their writers.

@ALL
What about passing by reference?

-Albatross
Well, I suppose this need to not use variables unless necessary stems from my knowledge of MSL (mIRC Scripting Language). Although I'm experienced in other languages, that particular language has kinda "reprogrammed" me into thinking variables are bad, as I hate having to type the "%" before each variable name.

I see where you all are going with this; I've just been using MSL lately to program an IRC bot, and I decided to learn C++ in order to create a more functional bot, which obviously has a completely different syntax. I have been able to use a variable all along; it's just MSL kinda screwed with my thinking. Probably another reason to learn a more powerful language such as C++, and more reliable one at that.

Anyway, thanks for your cooperation. The more you know-er, reknow? :s
Last edited on
@Albatross
You misunderstood me. I know what push does..
What I meant was that, function arguments are pushed in backwards order. That is, the last argument is pushed first. However this doesn't have to be that way. Perhaps some compilers push function arguments is normal order. Then the assembly code I wrote wouldn't work..
@hamsterman
Ah. I see what you meant.

Somehow, I think it depends on the subroutine in question.

-Albatross
It depends entirely upon the compiler. C (and C++) do not prescribe argument passing order. What usually happens is that the system's usual method is used. The only notable exception is on x86 hardware, where multiple calling conventions coexist.
Hmm... something doesn't add up here. I would think it depended on the library (whether you consider that to be part of the library or not is strictly relevant) (although my skills in assembly are... still improving).

-Albatross
Topic archived. No new replies allowed.